ノートPCのRTX 4060 8GBでローカル動画生成はやれるのか FramePack F1実走でVRAMでなくRAMの壁に当たった
目次
きっかけはFastWanだった。FastVideoが出しているWan系（Wanはオープンな動画生成モデル）の高速化版で、数ステップで動画が出る。出力にかかる時間が大きく縮むなら試す価値はある。それくらいの軽い動機で、手元のノートPCで動かせるのか調べはじめた。
マシンはRTX 4060 Laptop（VRAM 8GB）/ メモリ32GB / Windows 11。AI動画生成機としては非力な構成だ。このマシンでローカル動画生成がどこまでやれるか。
FastWanの速さは4060では出ない
まずFastWanの速さの正体を確かめた。鍵はVSA（Video Sparse Attention）。通常のdense attention（全フレーム総当たりで注意を計算する方式）は計算量がフレーム数の約2乗で増えるが、VSAは総当たりをやめて疎に計算することでこの2乗を緩める。これで速くなる。
ところがVSAの対象GPUはH100 / A100 / 4090で、4060は入っていない。8GBでは結局dense attention + オフロードに落ちるので、VSAの速度は出ない。FastWanの売りは、手元のハードでは活きない。
速さで選ぶ理由がなくなったので、狙いを変えた。短いクリップを速く出してもおもしろくない。品質を多少落としても、長めの動画を現実的な時間で出せる方が手元では価値がある。その方向で噛み合うのが FramePack（lllyasviel製、HunyuanVideo 13Bベース）。Wanとは設計思想が逆だ。
| 特性 | Wan/FastWan(dense) | FramePack |
|---|---|---|
| 時間 vs 長さ | 約2乗（長尺で爆発） | 線形（長さに比例するだけ） |
| VRAM vs 長さ | 長さで増える→OOM | 一定（長さに依存しない） |
| 最小VRAM | - | 6GB |
| 方式 | クリップ生成 | next-frame予測(i2v) |
長さに対してメモリが一定で、時間が線形。最小6GBなので8GBなら余る。i2v（画像から動画）なので、前回やったかなちゃんのi2vワークフローとも地続きだ。長さを狙うならこれ、ということでFramePackのF1版（前方向に1フレームずつ予測していく改良版）を選んだ。
VRAMの心配は元々していなかった。前回 WAN 2.2をRTX 4060（VRAM 8GB）のComfyUIで動かす で、22GBあるWan 14B Rapidを--lowvramで8GBに押し込み、4step / 111秒で回せている。8GB VRAMでも、オフロードさえ使えれば大きめのモデルは載る。今回もそのつもりでいた。
セットアップとモデル40GB
導入は迷う余地がない。FramePackは公式がWindows向けワンクリックパッケージ（framepack_cu126_torch26、CUDA 12.6 + PyTorch 2.6を同梱）を配っている。展開して、update.bat相当のgit pullで最新コードに上げると、F1版の起動スクリプトdemo_gradio_f1.pyが手に入る。
重いのはモデルの初回ダウンロードで、合計約40GB。3つのリポジトリから落ちてくる。
| リポジトリ | サイズ | 中身 |
|---|---|---|
| hunyuanvideo-community/HunyuanVideo | 約16GB | Llama系 テキストエンコーダ + CLIP + VAE |
| lllyasviel/FramePack_F1_I2V_HY_20250503 | 約26GB | 13Bトランスフォーマー（bf16） |
| lllyasviel/flux_redux_bfl | 約0.8GB | SigLIP画像エンコーダ |
この時点で違和感がある。VRAMの話が一度も出てこない。問題になるのはディスクと、このあと詰まるRAMだ。
起動した瞬間に落ちる（WinError 1455）
ダウンロードが終わって起動すると、生成に入る前のモデル読み込みで落ちた。
OSError: ページング ファイルが小さすぎるため、この操作を完了できません。 (os error 1455)ページングファイル（仮想メモリ。物理RAMが足りない分をディスクで肩代わりする領域）が小さすぎる、というエラー。起動スクリプトは テキストエンコーダ → VAE → 本体のトランスフォーマー の順にモデルをCPUのRAMへ読み込んでいくが、テキストエンコーダ（16GB）を載せたまま トランスフォーマー（26GB）を読むので、ピークで約43GBのRAMを要求する。検証機は物理32GB、ページファイルは自動管理で7GBしか確保されておらず、両者を足したコミット上限が約39GB。43GBは入らず、safetensorsの読み込みがMemoryErrorで死ぬ。
ここで最初の前提に戻る。VRAM 8GBは余裕で足りている。FramePackは6GB下限で、DynamicSwap（モデルの重みはCPU RAMに置いたまま、推論のたびに必要なレイヤだけGPUへ送って、終わったら戻す方式）で動くので、GPUには一度に数GB分しか乗らない。詰まっているのはGPUではなく、CPU側のメモリだった。「6GB VRAMで動く」の裏で、CPU側に20GB超の常駐を要求している。公式の謳い文句からは読み取れない部分だ。
最初はロード順の工夫で逃げられると思った。Gradioの画面を介さず生成処理だけをスクリプトから直接呼ぶ形にして、テキストエンコーダでプロンプトを処理したら即解放し、それからトランスフォーマーを読む、と順序を変えた。16GBと26GBが同時に常駐しなければピークは下がる。
テキストエンコーダの段は通るようになった。だがトランスフォーマーの読み込みでまた落ちる。理由はDynamicSwapの設計そのものだった。トランスフォーマーの26GBは、ロード時だけでなく推論のあいだずっとCPU RAMに常駐していないといけない。ロードのピークを削っても、最終的に26GBが残る事実は変わらない。物理32GBからOSや常駐アプリの使用分（実測で十数GB）を引いた実質は約19GB。26GBはどうやっても入らない。
つまり32GB RAM機では、小細工ではなく仮想メモリそのものを増やすしかない。GUIのrun.batを回すだけの人も、32GBならこのWinError 1455を踏むはずだ。「8GB VRAMは余裕なのにRAMで落ちる」が、今回いちばんの詰まりだった。正攻法の対処は次のとおり。
| 対処 | 内容 | 代償 |
|---|---|---|
| ページファイル増設 | 仮想メモリを手動で大きく（例: 初期24GB / 最大40GB） | ディスクを圧迫する。管理者権限＋再起動が要る |
| 物理RAM増設 | 64GB以上にすればページファイル不要 | ハード投資 |
| 量子化モデル | fp8/GGUF版をComfyUI FramePackWrapperで | 公式パッケージから外れる。別検証 |
設定をいじらずに通す
正攻法はページファイル増設だ。ただ、動画を作りたいだけなのに、管理者権限を出して仮想メモリを設定して再起動して、というのは面倒くさい。動画生成ごときでそこまでやる気にならず、設定を触らずに済む2つの手で押し通した。
ひとつめは、ディスクを空けること。自動管理のページファイルは、空きディスクがある分だけ必要に応じて大きくなる。使っていない旧モデルを消して空きを約54GBまで広げ、広がる余地を作った。
ふたつめが本命で、ページファイルの事前ウォームアップ。本体モデルを読む前に、Pythonから256MB刻みでメモリを確保しては解放する処理を挟んだ。突発的に26GBを要求すると、自動ページファイルの拡張が間に合わずプロセスが即死する（トレースバックすら出ずexit 5で落ちる）。が、小刻みに少しずつコミットを上げてやると、ページファイルが滑らかに大きくなる。十分に大きくしてから本番の読み込みに入れば、26GBは既にできた余裕に収まる。
この2つで、仮想メモリの設定を一切触らずに最後まで回せた。とはいえ動かすための応急処置でしかなく、速度の問題はそっくり残る。
5秒に56分
かなちゃんの正面ピース画像（1024×1024）を起点に、F1のデフォルト設定（25 steps、distilled CFG 10、TeaCache有効、640解像度バケット）で5秒ぶんを生成した。出てきた数字がこれ。
| 項目 | 実測 |
|---|---|
| 出力 | 4.83秒 / 145フレーム / 608×640 |
| 総時間 | 3363秒（56分） |
| 実効速度 | 23.2秒/フレーム |
| セクション毎 | 806 / 794 / 764 / 1000秒（ほぼ一定＝線形） |
| peak VRAM | 5.75GB（予約）/ 4.42GB（割当） |
公式が挙げるノート向けの参考値（3060 / 3070ti laptop）は1.5〜2.5秒/フレーム。今回はその約10倍遅い。peak VRAMは5.75GBで、8GBに対してまだ2GB以上余っている。VRAMを使い切って遅いのではない。
なぜ10倍遅いのか
生成中にnvidia-smiを覗くと、答えがはっきり出ていた。GPU使用率は2〜12%、VRAMの使用も8GB中3〜4GB。GPUはほとんど動いていない。
理由はメモリだ。26GBのトランスフォーマーが物理RAMに収まらず一部がページファイル（ディスク）に追い出されていて、DynamicSwapが毎ステップ全レイヤを読み出すたびに、その追い出された分をディスクから読み直している。GPUは次のレイヤが届くのを待っているだけで、計算する時間より待つ時間の方が長い。だから使用率が一桁のまま上がらない。
FramePackの「線形コスト・低VRAM」自体は嘘ではない。セクション毎の時間はほぼ一定で、確かに長さに線形だし、VRAMも6GB級で足りている。ただし32GB RAMでは、その線形の傾きが桁違いに大きい。5秒で56分なら、1分の動画は単純計算で約11時間。「長尺を実用速度で」という当初の狙いは、このメモリ構成では成立しない。
品質は崩れない
速度は厳しいが、出てきた絵は良かった。
145フレームを通して、かなちゃんの顔も髪も服も保たれている。F1は前方向に予測を重ねる方式で、長くなるほど絵が元から離れていくドリフトが起きにくい。その触れ込み通り、終盤まで破綻していない。動きも自然で、ピースから手を下ろし、頬に手を添える、という一連がなめらかに繋がる。一枚の静止画を渡しただけで、ここまで動く。
で、ノートPCでやれるのか
やれる。品質も良い。ただし遅い。これが4060 Laptop 8GB / 32GB RAMでの答えだ。
押さえておきたいのは、ボトルネックがVRAMではなくRAMだったこと。8GBのVRAMは最後まで余っていた。詰まったのは、26GBのモデルを丸ごと載せておけない物理メモリの方だ。公式の速度域（1.5〜2.5秒/フレーム）に乗せたいなら、モデルをディスクへ追い出さずに済むだけのRAM、実質48〜64GBが要る。32GBだと、数秒の実験クリップが我慢の限界で、分単位の長尺は現実的でない。
「6GB VRAMで動く」は本当だ。ただし真の必要条件はGPUではなくCPU側のメモリで、ノートPCで動画生成を検討するなら、VRAMより先にRAMの容量を見たほうがいい。次に詰めるなら、RAMを64GBに積むか、ComfyUI向けのFramePackWrapperでfp8/GGUF版を使い、CPU常駐量そのものを削る方向になる。
参考
- FramePack — 長尺・低VRAM動画生成
- lllyasviel/FramePack — 公式リポジトリ・ワンクリックパッケージ
- FastWan blog (Hao AI Lab) — H200/4090ベンチ・VSAの解説