こんにちは、パレイド技術部です。
前回は Wan2.2 の 5B モデルで環境構築と初回生成を確認しました。5B でも BGV 素材としての可能性は見えましたが、やはり上位の 14B モデルの品質が気になります。
しかし 14B モデルは素の状態では VRAM 30GB 以上を要求し、RTX4070（12GB）では到底動きません。今回は WanVideoWrapper というカスタムノード を使い、GGUF 量子化・VAE タイリング・BlockSwap を組み合わせて VRAM 12GB でも 14B T2V を安定動作させる 方法にチャレンジします。
なお前編の内容は公式の手順に沿っておらず不完全な画質となりますが、情報提供を目的とした記録として残してあります。後編でフォローアップしていますので、併せてご覧いただけましたら幸いです。
Claude Code + Chrome拡張で ComfyUI ワークフローにチャレンジ
今回の試行の前提として、EasyWan22 を利用して、同スペックの環境下でも Wan2.2 14B が動かせることは事前に確認済みでした。より厳しいVRAM容量でも動作が報告されており、動画作成自体が目的の場合は、EasyWan22 の利用がおすすめです。
EasyWan22 はワンストップで利用できる点が魅力ですが、高機能ゆえカスタムノードも多く、一般的な ComfyUI 環境で動かす難しい面もあります。今回は、自動化や拡張性を念頭に、シンプルなワークフローでの実験を試みます。WanVideoWrapper というカスタムノードを組み合わせれば自力でも実現できそうですが、Claude Code の Chrome 拡張に作成してもらう方向で進めます。
結論から言うと、ローカルで動作する ComfyUI の画面を Claude Code の Chrome 拡張に見せる形で対話を進めれば、十分に実用的なフローが組めました。今回は、Kijai氏のリポジトリや EasyWan22 という「正解」がある中での試行ではありますが、事前情報がなくとも Claude Code がトライ＆エラーで実装を進められたことは収穫です。以下の説明は、その過程で得られた知見をもとに構成しています。
14Bを12GBに収めるための3つの技術
14B モデルを低 VRAM 環境で動かすために、以下の3つを組み合わせます。
これらは WanVideoWrapper がカバーしている範囲の基本となっています。
1. GGUF 量子化
モデルの重みを FP16/BF16 から低ビット（Q4_K_S、Q5_K_S 等）に量子化し、モデルサイズと VRAM 消費を大幅に削減します。
- Q8: 品質はほぼ BF16 と同等。VRAM 削減効果は控えめ
- Q5_K_S: 品質と VRAM のバランスが良い。おすすめ
- Q4_K_S: 最大限の VRAM 節約。品質はやや低下するが実用範囲
2. VAE タイリング（Tiled VAE）
デコード時に動画全体を一度に処理するのではなく、タイルに分割して処理します。VAE のデコードで発生する VRAM のピーク消費を抑えられます。
3. BlockSwap（ブロックスワップ）
Transformer のブロックを GPU と CPU の間でスワップしながら推論します。全ブロックを GPU に載せる必要がなくなるため、12GB VRAM でも 14B モデルの推論が可能になります。
事前準備：WanVideoWrapper のインストール
ComfyUI にカスタムノードである WanVideoWrapper のをインストールします。
ComfyUI Manager 利用する手順を紹介していますが、最近の ComfyUI なら直接インストールも可能です。
Step 1: ComfyUI Manager からインストール
ComfyUI Manager を開き、以下のカスタムノードを検索してインストールします。
- ComfyUI-WanVideoWrapper（Kijai）
このノードパックに GGUF ローダー、BlockSwap、VAE タイリング対応のノードが含まれています。
ComfyUI-WanVideoWrapperは、個人開発者 Kijai 氏によって公開されているカスタム実装で、Wan2.2のGGUF量子化モデル対応やBlockSwapなどのメモリ削減機構を含んでいます。ComfyUI標準機能だけでは14Bモデルの動作は難しく、Kijai版の導入がRTX4070（12GB）環境で動かすための実質的な前提となります。MITライセンスとして配布されています。
Step 2: GGUF 量子化モデルのダウンロード
Hugging Face の Kijai リポジトリから GGUF 量子化済みモデルをダウンロードします。
また、QuantStack リポジトリではより幅広い量子化のバリエーションが利用可能です。
GGUF 量子化モデルは、RTX4070 の VRAM 12GB を目安に、Q5_K_S を起点として選びました。
VRAM不足でエラーが出る場合はQ4_K_Sを、逆に余裕があれば上のサイズも試してみます。
ComfyUI/
models/
diffusion_models/
wan2.2_t2v_14B_Q5_K_S.gguf ← 量子化済み14Bモデル
text_encoders/
umt5xxl_fp8_e4m3fn.safetensors ← 第1回と同じ
vae/
wan_2.2_vae.safetensors ← 第1回と同じテキストエンコーダー・VAE は第1回でダウンロード済みのものをそのまま使えます。
ワークフロー構築：ステップバイステップ
Kijai リポジトリのワークフローや EasyWan22 も参考に、14B T2V を動かすワークフローを組みます。
Step 3: ワークフローの読み込み
Kijai の GitHub リポジトリまたは ComfyUI Manager から EasyWan22 の T2V サンプルワークフローを読み込みます。主要なノード構成は以下の通りです。
[UNETLoader (GGUF)] → [BlockSwap設定] → [サンプラー] → [VAE Decode (Tiled)] → [出力]
↑
[テキストエンコーダー] → [プロンプト]Step 4: GGUF モデルローダーの設定
通常の「Load Diffusion Model」ではなく、WanVideoModelLoader ノードを使用します。
- unet_name:
wan2.2_t2v_14B_Q5_K_S.ggufを選択 - モデルが自動的に量子化状態で読み込まれ、VRAM 消費が抑えられます
Step 5: BlockSwap の設定
WanVideoBlockSwap ノードをモデルローダーに接続します。
- blocks_to_swap: 推奨値は
20前後（環境によって調整） - 値を大きくするほど VRAM 消費が減る代わりに生成速度が低下します
- RTX4070 12GB では
18〜22が安定動作の目安
Step 6: VAE Decode の設定
VAE デコードには WanVideo Decode ノードを使用します。
- tile_size:
256または320が安定 - 通常の VAE Decode ではデコード時に VRAM を多く必要とするため、必ずタイル版を使います
Step 7: サンプラーの設定
サンプラーは WanVideoSampler を使い、設定は公式の推奨値を設定します。値が大きなるとノイズが増えたり、画質が安定しません。steps は速度優先のために短めにしていますが、20 程度が品質の面ではよさそうです。また、BGV が用途のため安定を重視して cfg は 1.0 に設定しました。Wan は cfg に依存が少ないと言われていますが、3~7程度までが良いようです。
- steps: 6
- cfg: 1.00
- scheduler:
dpm++_sde
実際に生成してみると…（失敗例）
ここまでの設定で早速生成を試しました。動画の生成自体は問題なく完了し、14B の恩恵か構図やプロンプトへの追従は良好です。しかし出力された映像をよく見ると、画質がおかしいことに気づきました。全体的にノイズっぽく、ディテールが潰れている部分があります。
steps を増やしても改善せず、cfg を調整しても根本的な解決にはなりません。
そこでふと思い出しました。Wan2.2 のコミュニティでは、高ノイズ領域と低ノイズ領域でサンプラーを使い分ける手法が紹介されていたずです。確認してみると、今回のワークフローではサンプラーを1つしか使っておらず、この使い分けをまったくやっていませんでした。
長くなったので、続きは次回、サンプラーの2段階構成で画質を安定させる方法と、5B vs 14B の品質比較をお伝えします。
