こんにちは、パレイド技術部です。
本連載では RTX4070（VRAM 12GB）環境で Wan2.2 を使った BGV 生成フローを構築してきました。ところが3月上旬、ComfyUI のアップデートを適用した途端にワークフローが不安定になり、原因の特定と回避に丸1日を費やすことになりました。
何が起きたか
3月2日、ComfyUI 開発チームが「Dynamic VRAM」機能をデフォルトで有効化するアップデートをリリースしました。
Dynamic VRAM は NVIDIA GPU 向けの新しいメモリ管理システムで、PyTorch のカスタム VRAM アロケーターとして動作します。モデルのウェイトをオンデマンドで GPU に読み込み、不要になったら即座に解放する仕組みです。公式ブログでは以下のメリットが謳われていました。
- VRAM 不足によるクラッシュの解消
- モデル読み込みと LoRA 適用の高速化
- 物理 VRAM を超える大規模モデルの実行
- システム RAM 使用量の大幅削減
画像生成ワークフローでは確かに恩恵がありそうな機能です。しかし、本連載で構築してきた Wan2.2 + WanVideoWrapper のワークフローでは、アップデート直後から問題が頻発しました。
発生した症状
連載第1回で安定動作を確認していた 736×480 / 81フレームの設定で、以下の症状が出ました。
| 症状 | 頻度 |
|---|---|
2回目以降の生成で CUDA error: invalid argument | ほぼ毎回 |
| VAE デコードが異常に遅い（通常の3〜5倍） | 高頻度 |
Expected all tensors to be on the same device エラー | 時々 |
| 生成中にシステム RAM が急増しフリーズ | 稀に |
特に厄介だったのが「1回目は成功するが2回目以降で壊れる」パターンです。生成のたびに ComfyUI を再起動すれば動くものの、パラメータ調整を繰り返す連載の検証作業には致命的でした。
原因：3つの最適化機能の競合
調査の結果、ComfyUI が NVIDIA GPU 向けにデフォルト有効化している 3つのメモリ最適化機能 が、WanVideoWrapper の独自メモリ管理（ブロックスワップ）と競合していることが分かりました。
1. Dynamic VRAM
モデルウェイトを仮想アドレス空間（VBAR）に配置し、必要な瞬間にだけ物理 VRAM を割り当てる仕組みです。画像生成モデルでは効果的ですが、Wan2.2 の動画生成ではテンソルが GPU と CPU に分散配置される問題が発生します。WanVideoWrapper がブロックスワップでウェイトを手動管理しているため、Dynamic VRAM のオンデマンド割り当てと衝突し、デバイス不一致エラーの原因になります。
2. Pinned Memory
モデルウェイトをページロックされたシステム RAM に配置し、GPU との転送を高速化する機能です。しかし Wan2.2 の14Bモデルはデュアルモデル構成（高ノイズパス＋低ノイズパス）で、2つのモデルを交互に GPU へ転送します。Pinned Memory でロックされた領域がモデル切り替え時に解放されず、システム RAM が枯渇してフリーズの原因になります。
3. Async Offload
ウェイトのオフロードを非同期ストリームで行う機能です。通常は2ストリームで動作しますが、WanVideoWrapper のブロックスワップが同期的にウェイトを移動するため、非同期オフロードとタイミングが競合し、CUDA error: invalid argument が発生します。
解決策：3つの起動オプションを無効化
ComfyUI の起動引数に以下の3つのフラグを追加することで、問題が完全に解消しました。
--disable-dynamic-vram --disable-pinned-memory --disable-async-offload| フラグ | 効果 |
|---|---|
--disable-dynamic-vram | 従来の推定ベースのモデル読み込みに戻す |
--disable-pinned-memory | ページロック RAM を使わない |
--disable-async-offload | ウェイトオフロードを同期実行に戻す |
ComfyUI Desktop の場合、Settings → Server Config から起動引数を設定できます。ポータブル版やコマンドライン起動の場合は、起動コマンドに直接追加します。
python main.py --disable-dynamic-vram --disable-pinned-memory --disable-async-offloadコミュニティでも多数の報告
この問題は筆者だけではありませんでした。GitHub の ComfyUI リポジトリおよび WanVideoWrapper リポジトリには、Dynamic VRAM 有効化後に同様の問題を報告する Issue が多数上がっています。
- DynamicVRAM breaks loading models (#12786) — テンソルのデバイス不一致エラー
- Dynamic VRAM slow generation times (#12927) — Wan2.2 での VAE デコード速度低下
- CUDA error after first generation (#12524) — 2回目以降の生成で CUDA エラー
- Wan2.2 causes physical crash (#1044) — システムフリーズ
- Always Run out of Memory (#1272) — RAM 枯渇
共通する回避策は --disable-dynamic-vram の追加で、多くのユーザーがこれで安定動作を取り戻しています。Pinned Memory と Async Offload の無効化も併せて推奨されるケースが多く見られます。
なぜ動画生成モデルで問題が起きるのか
画像生成モデル（Stable Diffusion, Flux 等）では、1つのモデルを GPU に載せて推論するシンプルな構造です。Dynamic VRAM のオンデマンド管理と相性が良く、実際にメモリ効率が改善します。
一方、Wan2.2 のような動画生成モデルは以下の点で構造が異なります。
- デュアルモデル構成（14B）: 高ノイズ・低ノイズの2モデルを交互に使用
- ブロックスワップ: WanVideoWrapper が独自にウェイトの GPU/CPU 間移動を管理
- 大量のフレームデータ: 動画のフレーム分だけテンソルが増え、メモリ管理が複雑化
- 長い推論時間: 数分にわたる推論中にメモリ状態が変動
ComfyUI 本体のメモリ管理と、カスタムノード側の独自メモリ管理が二重に動作することで、どちらが何を管理しているか分からなくなる状態です。
今後の展望
Dynamic VRAM は ComfyUI の進化として正しい方向性です。ただし、動画生成モデルのような複雑なメモリパターンへの対応はまだ発展途上といえます。
ComfyUI 開発チームは問題を認識しており、カスタムノードとの互換性改善に取り組んでいます。WanVideoWrapper 側でも kijai 氏がブロックスワップのメモリ管理を改善するアップデートを継続的にリリースしています。将来的にはこれらの起動オプションを無効化しなくても安定動作するようになるでしょう。
当面は、Wan2.2 で動画生成を行う場合は 3つのフラグを無効化 した状態で運用することをおすすめします。
まとめ
- ComfyUI の Dynamic VRAM（3/2デフォルト有効化）が Wan2.2 + WanVideoWrapper と相性が悪い
--disable-dynamic-vram--disable-pinned-memory--disable-async-offloadの3つを無効化で安定- 原因は ComfyUI 本体のメモリ最適化と WanVideoWrapper のブロックスワップの競合
- 画像生成では有効な機能でも、動画生成の複雑なメモリパターンには未対応
- コミュニティでも多数の報告があり、一時的な回避策として広く共有されている
コメント