【VAE対策】Wan2.2+SVI 2.0 PROのAPI実行について【二重起動】

目次
私としては、動画作成にしても何にしても、基本バッチで処理できないと意味が無いと思っているのですが、Wan2.2+SVI 2.0 PROに関しては、配布されているワークフローがAPI化できないので試行錯誤した備忘録的な記事です。
ワークフローのAPI化?
皆さんどうされているか分からないんですが、ComfyUIと言うものは基本ブラウザ上でGUI使用されているのではないかと思います。それとは別にAPI利用と言う形で、コマンドラインからの制御で処理を行わせることが出来ます。この際には通常形式のワークフローとは異なる、API用のワークフローが必要となります。これは通常であればブラウザで一度ワークフローを開いて、API形式で保存すればいいのですが、SVI 2.0 PROを用いる場合、何故かノードの情報が失われる?のかうまく変換できないところからのスタートとなりました。
そもそもの話
私は他の記事でも書いていますが、全てClaudeCodeぶん投げ開発なので、ComfyUIの仕組みで有ったり、Wan2.2に関してもよく分かっていません。断片的な知識で作成していますので記事の中に間違っている内容や、足りない情報の為不完全な記事となっている可能性もあります。生暖かく見てください。
では進めていく
https://note.com/aiaicreate/n/n195e0ed2668c
こちらの記事をベースに進めていく。と言うのも、当方の環境(RTX 5060ti 16GB)ではFP16では大きすぎるし、GGUFモデルはなんかうまく行きませんでした。GGUFは設定しきらなかっただけなのか、モデル的にSVIと相性悪いのか分かりませんが、チャッピーに聞いたら無理だと思うと言われたのであきらめました。
具体的な進捗の話
これに関しては正直ClaudeCodeに丸投げなので、何をどうしたかもわからないし、どういうワークフローになっているかも把握できていません。ただ、上の記事をベースに、連結無しの単純な1セグメントの動画を作成し、多少試行錯誤しながらも連結の動画を作成するまではそれほど苦労しませんでした。ただし、この流れにたどり着くまでに他のスタートから作成しては消してを2回くらいやっています。
ただ、問題となるのはこれからです。ある程度の品質の長い動画を高速に作るのが難しい。今回の戦いはこれにつきます。遅くてもいいなら長い動画を作るのは苦労しません。無茶苦茶時間はかかりますが(とは言っても品質的に限度はあります。)。と言うことで、VRAMをどう使っていくかがポイントとなっていきます。
VRAMの詳しい話
まず、VRAMですが、上でも言いましたが5060ti16GBですので16GBあります。これに対して、今回使用しているWan2.2 FP8はフルロードに14GB程度必要としますので、他の実行を考えるとVRAM16GBではCPU領域に逃がすのが前提となります。
もちろん、VAEやテキストエンコーダーもCPUに逃がさないとVRAMが足りません。ブラウザでComfyUIを触っている方には当たり前なんだと思いますが、APIからだと指定してもうまく行かないこともあります。ここら辺分からずに設定しているからと言うのは否めない。
ではここら辺どうやっていい塩梅に調整するのかと言うと、いろんなパラメーターをあーでもないこうでもないといじるわけだが、ここで気を付けないといけないのは、UNET GPU(モデルのGPU側)、作業用領域、バッファ、余裕領域。
ここから先の認識は違っているかもしれません
OOMを防ぐには
ざっくりいうとフレーム数×解像度で使用量が決まるが、これが作業領域をオーバーするとOOMが発生する。
UNET FP8 load → dequantize: ❌ OOM
これはFP8はモデルは軽いが、計算時にFP16に戻す際に二重に(FP8+FP16)配置することになるのでそれでVRAMがあふれる。対策としては余裕メモリを設定するか、メモリを整理する。
何を言っているか分からないが、チャッピーに言わせると「latentサイズをVRAM境界内の“収まりの良いブロック”に調整し、
cudaMallocAsyncとoffloadでメモリ配置を整理すれば、
dequantize時のピークでもOOMしにくくなる。」
UNET GPUは多くとる
これは単純な話ですが、これが少ないと処理がCPU側に回ってしまうので出来るだけ多くとる。
そのうえでバッファを多くとる
実はこれが結構難しい。と言うのも、先ほどから話している各種設定はこまごまと設定できない。基本自動設定で決まる。細かく指定できるのは余裕メモリの量の設定で、VRAMをどのように使うかはざっくり設定。
変にいじくりまわすとこのバッファが少なくなる。これが少ないとGPUとCPUのデータのやり取りが目に見えて遅くなるので気を付けるポイントである。
ここまでの結論
ノーマルで配置したVRAMの中で実行可能なサイズで処理を行うのが現実的という当たり前の話。もちろん、設定をいじくりまわせはどうにかはなるかも知れないが、そもそもフルロードできていない時点で速度の低下は始まっているので、最低限の保持しないといけない画質などを確定したうえで、速度の低下をどう抑えるかが最優先となる。
ここからオプションと数値の最適化
解像度の話
Youtubeショート用の動画を作成するのだが、今の環境で作成するなら540×960で作成して、×2アップスケールすることになる。ここで問題となるのは人間側の都合で上の数字になっているが、AI側の都合で考えると544×960の方が収まりが良い。これは上で言っている「収まりの良いブロック」のサイズであり、最終的には×2アップスケールして、左右4Pixelずつカットして1080×1920に合わせることになる。
これに関しては一度試してみました。正直その一回で正解とは言えないと思うが、その一回ではむしろ結果が悪くなった。とは言っても、誤差と言えるレベルだったので問題は無いかと思う。どちらかと言うと、540×960だと540の計算誤差で丸めが起きてサイズが微妙に変わってしまう。これに関しては大した誤差ではないかもしれないが、アップロードする際にゆがみが出るので544で進める方が正解なのだと思う。
VAE処理がCPUで遅い話
こちらに関してはCPUなので遅いのかと思っていたが、たまたま調べてみたら普通に遅いだけでなく、スワップにあふれているのが判明。さすがにそれは問題なんだが、対策としてGPUが使えないか考えてみる。
VAEはGPUにロードするとVRAMが足りないのでCPUロードするしかない。
でも、VAEを実行する際にはGPU側で作業は行われていない。
と言うことは、GPUが忙しい時にはVAEが邪魔になるし、GPUが暇になってもCPUで処理しないといけない。
終了
VAEがどっちつかずでリソースがうまく活用できない。これはComfyUIとしては当たり前の話で対策なんてあるのだろうか。
ここで、今回のAPI処理が活きてきます。
ComfyUIからComfyUIへ引き継ぐ
チャッピーに聞いてみると、動画生成とVAE+結合処理を別のComfyUIで処理する可能性を提案された。確かに二つに分けてしまえばVAEの置き場に困ることもないし、VAEをGPUで高速処理できる。ただ、実際そんなことできるのかと試してみることに。
意外に問題なくできた。もう少し大変かと思ったが、latent方式でファイルをすんなり渡すことが出来たので、問題なくVAEをGPU処理できました。
https://youtube.com/shorts/dokuNxPZoaQ?feature=share
とりあえず動かすことを最優先としていたのでプロンプトは特に練っていません。動きはひどい。
詳細に関しては一番最後にAIでまとめた設計を載せます。
まとめ
これって、もっと大きいメモリがあれば全く苦労しないのだろうが、限られたメモリで処理を行うには必須の処理のような気がします。ただ、スクリプトでうまく処理をつながないといけないのでAIUI必須のような気がします。それと、結構ギリギリの数字を責めている感じなので、環境や設定次第で速度は結構変わると思います。
それとよく分からないが、ComfyUIをバージョンアップしたらメモリ管理が変わって使いにくくなったのでうちでは古いバージョンで固定してると、どのバージョンか調べようと思ったら何故だか分からないがデータが飛んだ。AIUIの恐ろしさだ。一応データは保管されているはずだが、復旧は面倒くさくなりそうだ。
以下AIによるまとめ
Wan2.2 SVI動画生成システム - 高速化改修レポート
概要
Latent分離アーキテクチャの導入により、VAEデコード処理を44分から1分に短縮(44倍高速化)。
全体処理時間は75分から32分へ57%削減。
改修前の問題
環境
GPU: NVIDIA GeForce RTX 5060 Ti (16GB VRAM)
問題
UNET (14B FP8) はフルロードできないが、GPU側モデル・作業用領域・バッファ・余裕領域を考えると、16GB VRAMにVAEを載せる余裕がない。そのため `--cpu-vae` オプションでVAEをCPU処理にしていたが、メインメモリも不足しスワップが発生。VAEデコードだけで44分かかっていた。
起動オプション(改修前)
comfyui --listen --port 8188 \
--normalvram \
--cpu-vae \
--async-offload \
--fast \
--reserve-vram 0 \
--cuda-malloc \
--fp8_e4m3fn-unet処理時間(改修前)
サンプリング: 約31分
VAEデコード: 約44分(CPU処理+スワップ)
合計: 約75分
改修内容: Latent分離アーキテクチャ
基本アイデア
ComfyUIをAPI経由で実行しているため、起動・終了・再起動が容易。
これを活かし、サンプリングとデコードを別々のComfyUIプロセスで実行する。
Phase 1: ComfyUIを起動してサンプリング実行、latent保存、ComfyUI終了
Phase 2: ComfyUIを別設定で再起動、latent読込、VAEデコード、動画出力
ComfyUIを一度終了することでVRAMが完全に解放され、Phase 2ではVAEだけがGPUを占有できる。
Phase 1: サンプリング
UNETがVRAMを使用。VAEDecodeは実行せず、latentファイルを保存して終了。
起動オプション(Phase 1)
comfyui --listen --port 8188 \
--normalvram \
--cpu-vae \
--async-offload \
--fast \
--reserve-vram 0 \
--cuda-malloc \
--fp8_e4m3fn-unetワークフロー
`phase1_sampling_544x960_4seg.json`
4セグメント × 81フレームのサンプリング実行
SaveLatentでlatentファイル保存(VAEDecodeなし)
処理時間: 約31分
Phase 2: デコード
UNETをロードしない。VAEがGPUをフル活用。
起動オプション(Phase 2)
comfyui --listen --port 8188 \
--normalvram \
--cuda-malloc`--cpu-vae` がないため、VAEはGPU処理。
ワークフロー
`phase2_decode_544x960_4seg.json`
LoadLatentで4セグメントのlatent読込
VAEDecodeをGPUで実行
ImageBatchExtendWithOverlapでセグメント結合(5フレームオーバーラップ)
処理時間: 約1分
処理時間比較
改修前: 75分(サンプリング31分 + VAEデコード44分)
改修後: 32分(Phase 1: 31分 + Phase 2: 1分)
改善: 43分短縮(57%削減)、VAEデコードは44倍高速化
出力動画仕様
解像度: 544×960 (9:16縦型)
フレーム数: 309
FPS: 16
長さ: 約19秒
セグメント構成: 4セグメント × 81フレーム(5フレームオーバーラップ)
解像度544は8で割り切れる(544÷8=68)ため、latent空間での端数丸めエラーを回避。
ファイル構成
ワークフロー:
`workflows/phase1_sampling_544x960_4seg.json` - Phase 1用
`workflows/phase2_decode_544x960_4seg.json` - Phase 2用
起動スクリプト:
`tools/start_phase1_sampling.sh` - Phase 1用
`tools/start_phase2_decode.sh` - Phase 2用
まとめ
Latent分離アーキテクチャにより:
VAEデコード44倍高速化: CPU+スワップ(44分) → GPU(1分)
全体処理57%削減: 75分 → 32分
VRAM競合の根本解決: ComfyUI再起動でUNET/VAEを別プロセス実行
16GB VRAM環境で544×960 4セグメント(約19秒)の動画を安定生成可能。
SwitchBot公式ページ
クーポン「AF-4903」で5%引き(アフィリエイトクーポンになりますのでご協力お願いします)
割引の詳しい仕組みに関してはこちらのページを参照ください。