FramePackで動画生成を試す：WSLとホストで異なるCUDAバージョンでも動作するかを検証

🎬 FramePackとは？画像から動画を生成する次世代モデル

今回試したのは、画像から高品質な動画を生成できる先進的なフレーム予測モデル「FramePack」です。

これは、「次のフレーム（またはフレームセクション）を逐次予測する」アーキテクチャで、13Bモデルでも ノートパソコンのGPUで数千フレームを生成できる という驚異的な効率を誇ります。
学習や生成は、画像生成に近い感覚で操作でき、インタラクティブに結果が得られるのも魅力です。

💡 公式が求めるCUDAバージョンと注意点

Linux環境で利用する場合、FramePackのセットアップ手順では以下のコマンドを実行するよう指示されています：

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu126

これは、PyTorchのCUDA 12.6対応ビルドを明示的に指定しています。

🤔 しかし、環境によってCUDAバージョンにズレが？

このとき、ふと疑問が浮かびました。

「自分の環境はCUDA 12.6に合っているのか？」

そこで nvcc -V コマンドを使って確認してみたところ、以下のような結果が出ました。

PowerShellでは：

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Built on Wed_Jan_15_19:38:46_Pacific_Standard_Time_2025
Cuda compilation tools, release 12.8, V12.8.61
Build cuda_12.8.r12.8/compiler.35404655_0

一方、WSLでは：

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Fri_Jan__6_16:45:21_PST_2023
Cuda compilation tools, release 12.0, V12.0.140
Build cuda_12.0.r12.0/compiler.32267302_0

🤯 CUDAのバージョンが違う！？なぜ？

同じマシンで nvcc -V を実行しているのに、PowerShellではCUDA 12.8、WSLではCUDA 12.0と表示される。
これは一見不思議な現象ですが、実際によくある落とし穴なのです。

PowerShellでは12.8、WSLでは12.0？CUDAバージョンが異なる理由とその背景

CUDAを使って開発を進めていると、「ホストのWindowsとWSLでCUDAのバージョンが違う」という現象に出会うことがあります。
たとえば、以下のように nvcc -V を実行すると、結果がまったく違って見えることがあります。

🖥 PowerShellやコマンドプロンプトで以下を実行：

nvcc -V

出力例：

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2025 NVIDIA Corporation
Built on Wed_Jan_15_19:38:46_Pacific_Standard_Time_2025
Cuda compilation tools, release 12.8, V12.8.61
Build cuda_12.8.r12.8/compiler.35404655_0

🐧 一方、WSL内で同じコマンドを実行すると：

nvcc -V

出力例：

nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2023 NVIDIA Corporation
Built on Fri_Jan__6_16:45:21_PST_2023
Cuda compilation tools, release 12.0, V12.0.140
Build cuda_12.0.r12.0/compiler.32267302_0

なぜこのような違いが生まれるのか？

違いの理由は非常にシンプルですが、見落とされがちな「WSLとWindowsの役割の違い」にあります。

✅ Windows側（PowerShell・コマンドプロンプト）は、WindowsにインストールされたCUDA Toolkitを使用

nvcc の出力は、WindowsにインストールされたCUDAのバージョンそのものです。
このため、WindowsでCUDA 12.8をインストールしていれば、それに対応したバージョンが表示されます。

✅ 一方、WSL側は完全に別のLinux環境

WSLはLinuxのサブシステムであり、WSL内部にもCUDA Toolkitを別途インストールしない限り、最新版にはなりません。
たとえWindows側がCUDA 12.8でも、WSL内部には12.0が入っていたり、そもそもインストールされていなければ nvcc 自体が使えません。

💡 WSLのGPUサポートはホストのドライバに依存している

WSLでは nvidia-smi を実行しても、ホスト（Windows）のGPU情報をそのまま取得できます。
そのため、nvidia-smi では最新に見えても、nvcc の出力は古いままということが普通に起きます。

🧩 よくある誤解

• 「nvccのバージョンが古いのは、Python仮想環境のせい」
  → ❌ 仮想環境は関係ありません。nvccはシステムのCUDA Toolkitに依存します。
• 「ホストが12.8だからWSLも同じはず」
  → ❌ WSLは“別のOS”です。個別にインストールが必要です。

✅ 状況を確認するためのコマンドまとめ

あ、それから、WSL × VSCode の組み合わせは、Linuxの開発環境の快適さと、Windowsの操作性の良さを両立できる最強タッグです💪✨

🔧 WSL × VSCode の組み合わせが便利な理由

✅ 1. ネイティブLinux環境での開発が可能

• apt, pip, conda などLinuxツールがそのまま使える
• シンボリックリンクやUNIXパーミッションの動作も完璧

✅ 2. VSCodeがWSLにシームレスに接続

• ターミナルは自動的に WSL の bash/zsh に切り替わる
• .venv などの仮想環境も自動検出してくれる（Python拡張込み）
• GUIアプリケーションも wslg で起動可能（Ubuntu GUIなど）

✅ 3. ファイル操作も快適

• WindowsとWSL間のファイルコピーもエクスプローラー感覚
• /mnt/c/... のようにWindows側もマウント済み
• VSCode内でフォルダを開くと、Linux側のパスでアクセス

🧠 補足：Pythonプロジェクトとの相性も抜群

• .venv をWSL内で構築 → VSCodeが勝手に認識してくれる
• GPUのテスト（PyTorch, TensorFlowなど）も、WSL上のCUDAで確認可能
• VSCodeの「デバッグ」「Linter」「フォーマッタ」も全部WSL側で動作！

🎯 おすすめの使い方Tips（もしまだでしたら）

settings.json に以下の設定を追加すると .venv 自動検出率UP：

"python.venvPath": "${workspaceFolder}/.venv"

Remote-WSL 拡張機能は入れ忘れないように！

ここまで整理すると以下のような感じでしょうか。

🔧 状況整理（現環境）

• ホスト（Windows）CUDAドライバ：12.8
• GitHubのプロジェクトが要求：CUDA 12.6
• 環境構築場所：WSL2
• 目的：Python仮想環境内での動作検証

🎯 重要なポイント

① CUDAドライバ（ホスト） vs CUDAツールキット（WSL内）の違い

• ホスト（Windows）側のCUDAドライバ 12.8は、後方互換性があるため12.6も基本的にはサポートします。
• しかし、Pythonで動かす深層学習ライブラリ（PyTorchやTensorFlowなど）は、CUDA Toolkit 12.6に強く依存している可能性があります。
  • 特に torch は CUDA toolkit とバイナリ一致が求められる。

nvcc -V で 12.0 と出ていても、仮想環境に CUDA 12.6 対応の PyTorch を明示的にインストールしたことで、正しく動作したということです。

✅ 成功の背景まとめ

これは、PyTorchのビルド済みバイナリが自前のCUDAツールキットを必要とせず、パッケージに同梱されたランタイムで動作するからですね。

✨ ワンポイント解説（深堀り）

Python仮想環境でうまくいった理由：

• PyTorchの cu126 バージョンは、内部的にCUDAランタイムライブラリをバンドルしているため、
  ホストや nvcc が12.0であっても問題なく動作。
• nvcc はあくまでコンパイル時に使われるもの。PyTorchの動作は バイナリに同梱されたCUDAランタイムに依存している。

🧼 もし余裕があれば…

WSL内の /usr/local/cuda が 12.0 のままで問題ないですが、 将来的に nvcc を使ったプロジェクトをビルドする場合は、12.6のツールキットにしておくと一致性が取れて安心です。

必要ならこのコマンドで切り替えできます：

sudo update-alternatives --install /usr/local/cuda cuda /usr/local/cuda-12.6 1
sudo update-alternatives --set cuda /usr/local/cuda-12.6

🔍 WSLでは /usr/local/cuda が必ずあるとは限りません

理由：

1. WSL2では ホスト側（Windows）のCUDAドライバが共有されており、
2. 明示的に WSL内でCUDA Toolkitをインストールしていなければ、 → /usr/local/cuda は作成されません。

✅ 現在の私の状態（成功パターン）

🚫 何もしなくてOKなケース

• 私のように Pythonの仮想環境に cu126 バージョンを入れてうまく動いているなら、
  /usr/local/cuda がなくても全く問題ありません。

⚙ もし /usr/local/cuda が必要になるケース（将来的に）

• nvcc を使って独自に .cu ファイルをビルドするプロジェクト
• TensorRTやカスタムCUDA拡張を使う場合
• ある種のCMakeプロジェクトで find_package(CUDA) を使うもの

その場合は、CUDA Toolkit（例：12.6）をWSL内に手動インストールする必要があります。

結論から先に言うと図のような理由でインストールは成功しました。

🧪 実際にFramePackをインストールして試してみる

ここからは、実際に FramePack をセットアップし、CUDAのバージョン確認や仮想環境構築を通して実践的に整理していきます。

🧾 プロジェクトのクローン

まずは、FramePack の公式リポジトリをクローンします。

git clone https://github.com/lllyasviel/FramePack

ここでは VSCode を使って進めます。
通常のターミナル操作（cd FramePack など）も可能ですが、VSCodeの場合は「ファイル → フォルダを開く」から FramePack フォルダを直接開くのが便利です。

ファイルや構成が視覚的に見えるので、プロジェクトの全体像が把握しやすくなります。

WSL上でCLIだけを使っている方は、cd FramePack で移動してもOKです。

🐍 Pythonバージョンの確認と仮想環境の準備

FramePack の公式は Python 3.10.x を推奨しています。
幸い、pyenv が導入済みであれば簡単に対応可能です。

pyenv についての詳細はこちらの記事でも解説しています：
👉 PyenvとVSCodeの連携
👉 pyenvの基礎と導入

まず、現在のPythonバージョンを確認してみましょう。

python -V

出力例：

Python 3.12.0

→ 現時点では、FramePackの推奨バージョン（3.10.x）ではありません。

📦 仮想環境の作成：なぜ必要か？

仮想環境を使う理由はいくつかあります：

• WSL環境が複数のプロジェクトで汚染されるのを防ぐ
• プロジェクトごとに Pythonのバージョンやパッケージ構成を完全に分離できる
• バージョンや依存関係のトラブルを未然に防止

とくにWSLを長く使っていると、環境が「ぐちゃぐちゃ」になることがあります。
そんな時に 仮想環境が“お掃除部屋”のような役割を果たしてくれます。

🖼 VSCodeで仮想環境をGUI感覚で作成する方法

VSCodeには仮想環境作成機能が組み込まれており、GUI的な操作で進めることができます。

1. 上部コマンドパレットで「>」を入力（または Ctrl + Shift + P）
2. Python: 環境の作成... を選択
   
3. Venv を選択
   
4. Python 3.10.6 を選択（pyenv経由）
   

この手順により、プロジェクト直下に .venv ディレクトリが作成され、仮想環境が初期化されます。

🧪 バージョン確認と仮想環境の有効化

仮想環境を作成した直後に python -V を実行しても、まだ以下のように表示されます。

Python 3.12.0

これは、仮想環境がまだ有効化されていないためです。

以下のコマンドで仮想環境を有効化しましょう：

source .venv/bin/activate

すると次のようにプロンプトが変わり、

(.venv) $

再度確認すると、Pythonのバージョンが仮想環境に切り替わっていることがわかります。

Python 3.10.6

なお、pyenv local などを使っていない限り、.python-version ファイルは自動的には作成されません。

🛠 CLI派の方へ：コマンドだけで仮想環境を作るには？

VSCodeを使っていない場合や、あえて手動で操作したい場合は以下でも同じ効果が得られます。

python -m venv .venv

その後は同様に source .venv/bin/activate で仮想環境を有効化してください。

🛠 FramePackを実際に動かしてみる（CUDAバージョンのギャップも検証）

ここからは、実際に FramePack をインストールし、動作確認を行います。
ホストがCUDA 12.8で、WSLがCUDA 12.0という状況でも動作することを実証しながら、仮想環境の有用性も改めて見ていきます。

① PyTorch（CUDA 12.6対応ビルド）のインストール

FramePack の公式リポジトリでは、以下のように CUDA 12.6 向けのPyTorchをインストールするように案内されています。

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu126

ここがとても重要なポイントです。

🔍 この指定により、CUDA 12.6 に最適化された PyTorch のバイナリがインストールされます。
たとえWSL側の nvcc が古く（CUDA 12.0など）ても、PyTorch内部に同梱されたCUDAランタイムが使われるため、動作には支障がありません。

この時点で、ホスト（Windows）がCUDA 12.8、WSLが12.0でも正常にセットアップできることが分かります。

② その他の依存パッケージをインストール

クローンしたFramePackのルートディレクトリに移動し、以下のコマンドで依存関係をまとめてインストールします。

pip install -r requirements.txt

⚠️ PyTorchとは別にGradioや画像処理系など多くのライブラリがインストールされます。最初の仮想環境作成時点でインストールしておくことで、システム環境を汚さずに済みます。

③ スクリプト実行と初回起動

以下のコマンドでGUIを起動します。

python demo_gradio.py

④ 実行時の出力例（初回）

Currently enabled native sdp backends: [‘flash’, ‘math’, ‘mem_efficient’, ‘cudnn’]
Xformers is not installed!
Flash Attn is not installed!
Sage Attn is not installed!
Namespace(share=False, server=’0.0.0.0′, port=None, inbrowser=False)
Free VRAM 6.9326171875 GB
High-VRAM Mode: False

また、モデルのダウンロード（30GB以上） が始まるため、ネットワークとストレージに十分な空きが必要です。

❓ Xformers・Flash Attn・Sage Attnとは？

実行ログに登場するこれらのAttention最適化ライブラリについても触れておきましょう。

💡 結論として：FramePackはこれらが未インストールでも問題なく起動・生成可能です。
ただし、VRAMや生成速度を改善したい場合には、あとから導入して比較してみるのも良いでしょう。

🌐 GUIの起動とブラウザ表示

起動後、以下のように Gradio のUIが自動または手動で開けます。

• 自動でブラウザが開かない場合 → http://localhost:7860 にアクセス
• WSLの場合 → http://127.0.0.1:7860 で同様にアクセス可能

🎉 動作確認完了！

この実践により、以下のことが確認できました：

• ✅ ホストとWSLでCUDAバージョンが異なっていても、正しいPyTorchビルドを使えば動作する
• ✅ 仮想環境を使えば、依存関係やバージョンの汚染を防ぎながら安全に実行できる
• ✅ FramePackは、追加ライブラリがなくてもすぐに試せる状態で提供されている

🎬 動画は「1秒ずつ」作っている？いえ、「セクションごとに拡張」しています！

FramePackで初めて動画を生成したとき、多くの人が驚くのが「なかなか動画が完成しない」「1秒だけの動画が何度も出てくる」という現象です。

これは、FramePackの動画生成が特殊な仕組みで行われているためです。

🧠 FramePackの動画生成は「セクションごとに段階的に拡張」

FramePackは「next-frame-section prediction model」という構造を採用しており、
動画を数フレームずつ、セクション単位で少しずつ生成・拡張していく仕組みになっています。

📋 実際に実行したときのログ（抜粋）

以下は、実際に5秒動画を生成したときの python demo_gradio.py 実行中に表示されたログの一部です。

🔽 ターミナルに表示された実際の内容

Currently enabled native sdp backends: [‘flash’, ‘math’, ‘mem_efficient’, ‘cudnn’]
Xformers is not installed!
Flash Attn is not installed!
Sage Attn is not installed!
Namespace(share=False, server=’0.0.0.0′, port=None, inbrowser=False)
Free VRAM 6.9326171875 GB
High-VRAM Mode: False
Downloading shards: 100%|█████████████████████████████████████████████████████████████| 4/4 [00:00<00:00, 33091.16it/s] Loading checkpoint shards: 100%|█████████████████████████████████████████████████████████| 4/4 [00:00<00:00, 9.42it/s] Fetching 3 files: 100%|███████████████████████████████████████████████████████████████| 3/3 [00:00<00:00, 35645.64it/s] Loading checkpoint shards: 100%|█████████████████████████████████████████████████████████| 3/3 [00:00<00:00, 11.46it/s] transformer.high_quality_fp32_output_for_inference = True * Running on local URL: http://0.0.0.0:7860To create a public link, set `share=True` in `launch()`. Unloaded DynamicSwap_LlamaModel as complete. Unloaded CLIPTextModel as complete. Unloaded SiglipVisionModel as complete. Unloaded AutoencoderKLHunyuanVideo as complete. Unloaded DynamicSwap_HunyuanVideoTransformer3DModelPacked as complete. Loaded CLIPTextModel to cuda:0 as complete. Unloaded CLIPTextModel as complete. Loaded AutoencoderKLHunyuanVideo to cuda:0 as complete. Unloaded AutoencoderKLHunyuanVideo as complete. Loaded SiglipVisionModel to cuda:0 as complete. latent_padding_size = 27, is_last_section = False Unloaded SiglipVisionModel as complete. Moving DynamicSwap_HunyuanVideoTransformer3DModelPacked to cuda:0 with preserved memory: 6 GB 100%|██████████████████████████████████████████████████████████████████████████████████| 25/25 [05:01<00:00, 12.07s/it] Offloading DynamicSwap_HunyuanVideoTransformer3DModelPacked from cuda:0 to preserve memory: 8 GB Loaded AutoencoderKLHunyuanVideo to cuda:0 as complete. Unloaded AutoencoderKLHunyuanVideo as complete. Decoded. Current latent shape torch.Size([1, 16, 9, 64, 96]); pixel shape torch.Size([1, 3, 33, 512, 768]) latent_padding_size = 18, is_last_section = False Moving DynamicSwap_HunyuanVideoTransformer3DModelPacked to cuda:0 with preserved memory: 6 GB 100%|██████████████████████████████████████████████████████████████████████████████████| 25/25 [05:18<00:00, 12.75s/it] Offloading DynamicSwap_HunyuanVideoTransformer3DModelPacked from cuda:0 to preserve memory: 8 GB Loaded AutoencoderKLHunyuanVideo to cuda:0 as complete. Unloaded AutoencoderKLHunyuanVideo as complete. Decoded. Current latent shape torch.Size([1, 16, 18, 64, 96]); pixel shape torch.Size([1, 3, 69, 512, 768]) latent_padding_size = 9, is_last_section = False Moving DynamicSwap_HunyuanVideoTransformer3DModelPacked to cuda:0 with preserved memory: 6 GB 100%|██████████████████████████████████████████████████████████████████████████████████| 25/25 [05:16<00:00, 12.66s/it] Offloading DynamicSwap_HunyuanVideoTransformer3DModelPacked from cuda:0 to preserve memory: 8 GB Loaded AutoencoderKLHunyuanVideo to cuda:0 as complete. Unloaded AutoencoderKLHunyuanVideo as complete. Decoded. Current latent shape torch.Size([1, 16, 27, 64, 96]); pixel shape torch.Size([1, 3, 105, 512, 768]) latent_padding_size = 0, is_last_section = True Moving DynamicSwap_HunyuanVideoTransformer3DModelPacked to cuda:0 with preserved memory: 6 GB 100%|██████████████████████████████████████████████████████████████████████████████████| 25/25 [05:17<00:00, 12.69s/it] Offloading DynamicSwap_HunyuanVideoTransformer3DModelPacked from cuda:0 to preserve memory: 8 GB Loaded AutoencoderKLHunyuanVideo to cuda:0 as complete. Unloaded AutoencoderKLHunyuanVideo as complete.

🔍 ログから読み取れる「セクション拡張」の流れ

ログを読むと、次のような情報が確認できます。

Decoded. Current latent shape torch.Size([1, 16, 9, 64, 96]); pixel shape torch.Size([1, 3, 33, 512, 768])
...
Decoded. Current latent shape torch.Size([1, 16, 18, 64, 96]); pixel shape torch.Size([1, 3, 69, 512, 768])
...
Decoded. Current latent shape torch.Size([1, 16, 27, 64, 96]); pixel shape torch.Size([1, 3, 105, 512, 768])

• latent shape や pixel shape のフレーム数が 33 → 69 → 105 と増加していることがわかります。
• これは、少しずつ動画を長くしているということです。
• is_last_section = True と出たタイミングで、ようやく動画生成が完了します。

📈 表で見る生成の推移

💡 結論：「1秒動画を繰り返している」のではない

FramePackは「1秒の動画を何度も生成している」のではなく、1本の動画をセクションごとに拡張しているということになります。

この図では、FramePackの動画生成プロセスにおける「セクションごとの拡張」方式を視覚化しました。従来の「1秒ずつ作ってつなげる」方式とは根本的に異なる仕組みがわかります。

主なポイントは：

1. 最初のセクション：まず33フレーム（約1秒程度）の短い動画を生成します
2. 段階的な拡張：その後、既存のフレームを基に新しいフレームを追加し、69フレーム、さらに105フレームと拡張していきます
3. 一貫した流れ：動画は個別のセクションを作って後からつなげるのではなく、先行するフレームの文脈を考慮しながら連続的に拡張されます

この「next-frame-section prediction model」と呼ばれる方式により、動画全体の一貫性が保たれ、自然な流れの映像が生成されます。そのため、ユーザーからは「1秒だけの動画が何度も出てくる」ように見え、完成までに時間がかかるように感じるのです。

🎯 なぜこういう仕組みなのか？

この構造には、以下のような実用的な理由があります。

• ✅ VRAMが限られていても長い動画を作れる
• ✅ 途中段階でプレビューが可能
• ✅ セクション単位で最適化（メモリのオンオフロードなど）ができる

この段階的な生成によって、13Bの大規模モデルでもノートPCで5秒動画が生成可能という驚異の効率性が実現されています。

✅ 少ないGPUメモリでも動くが、多いほうが圧倒的に有利です

📈 理由をまとめるとこうなります：

🧠 FramePackの内部挙動（ログからもわかる）

たとえば先ほどのログでも：

Offloading DynamicSwap_HunyuanVideoTransformer3DModelPacked from cuda:0 to preserve memory: 8 GB

このように、「メモリを守るためにモデルをオフロード→オンロードを繰り返す」挙動が頻繁に出ていましたね。
これが「時間がかかる原因」そのものです。

🛠 ブラウザから変更できる生成設定の意味（Gradio UI解説）

FramePackでは、動画生成前にブラウザ上で直感的に設定を変更できます。
以下はその設定項目と意味を解説したものです（※画像参照）。

✅ 各項目の説明

💡 実践ポイント

長さは5〜20秒あたりがVRAM消費・生成時間のバランスが良い

まずは TeaCacheをONにして試す（結果が悪ければOFFにする）

Seedを固定すれば実験・比較が簡単になる

✅ nvcc は不要か？

この demo_gradio.py を見た限り、プロジェクトは：

• diffusers 系モデル（Hugging Face Transformers + Diffusers）
• PyTorch（torch) の from_pretrained() を通じてモデルを読み込み
• 推論中の計算（transformer(...) や vae_decode(...)）をGPU上で実行

という構成で、

⛔ 独自の CUDA カーネル（.cuファイル）を一切使っていません。

したがって：

• nvcc や /usr/local/cuda はこのスクリプトでは一度も参照されていません
• 必要なのは PyTorchがCUDA対応していることと、GPUドライバが正常に使えること

✅ 実行環境として本当に必要なもの

🔍 nvcc があった理由

WSLで nvcc -V が使えたのは、過去に nvidia-cuda-toolkit をインストールした可能性があります。
これは完全に 開発者向けであって、推論（inference）目的には不要です。

🧼 まとめ

• ✅ このプロジェクトは CUDA Toolkit 不要、nvcc も使わない
• ✅ PyTorch に CUDA バージョンがマッチしていれば問題なし
• ✅ 今の構成で動作しているなら そのままでOK
• ⛔ /usr/local/cuda がないことは気にしなくてよい

ただし、

「WSL側ではCUDA Toolkitは不要でも、Windowsホスト側にはCUDAドライバ（とそれに紐づくランタイム）は絶対に必要」です。

✅ 理由：WSL2はGPUを直接持っていない

WSL2では GPU を自分で制御していません。代わりに：

🧠 補足：必要なもの（ホスト側）

今回のように WindowsでCUDA 12.8 → WSL2でPyTorch cu126 のように設定すれば完璧です。

🔧 チェックリスト（Windows側に必要なもの）

# PowerShell などで確認
nvidia-smi

これでバージョンが表示されることが必須です（12.6以上ならPyTorch cu126に対応）。

✅ まとめ

• 🟢 WSL2では /usr/local/cuda や nvcc は不要
• 🟢 しかしWindowsホストには適切なバージョンの CUDAドライバが必要
• 🔧 ドライバが古いと WSL内からGPUが見えない／CUDAが使えない

⚠️ 注意：WSLでファイルを削除しても容量は回復しません

FramePackでは、モデルや中間ファイルで数十GBのデータを扱うことがあります。
一度インストールしたファイルを削除しても、WSL2ではディスク容量が自動的に戻らないという落とし穴があります。

とくに以下のような操作を繰り返していると：

• モデルを何度も再ダウンロード
• 動画ファイルを大量生成＆削除

…WSLの仮想ディスクが肥大化して、Cドライブを圧迫する危険性があります。

この対処法については以下の記事で詳しく解説しています：

👉 WSLの容量が減らない？.vhdxファイルを縮小する方法

さらにこれが出来ない方に送るWSLの余分なファイルを削除する自動スクリプトを以下の記事で紹介しております。

👉 WSLの容量が確保自動スクリプトの記事