【VAE分離】ComfyUI動画生成におけるVRAM問題の本質とフェーズ分離による新しい運用アプローチ【API運用】

目次

1. VRAM問題の正体は「2種類のメモリを同時に収める必要があること」
2. 問題は「この合計を同時にGPUに載せなければならない」こと
3. VAEは「最大要因」ではないが「逃がせる要因」
4. VAEをCPUに出すことで得られるものと問題点
5. 強制される三択
6. 発想の転換：処理フェーズを分ける
7. フェーズ分離運用という解決策（API方式）
8. この方式の最大のメリット：設定妥協から解放される
9. API方式のデメリット
10. AIUI運用の危険性と注意点
11. まとめ

昨日の記事でどうしても邪魔になるVAE処理を別処理とすることで、単純に高品質動画と短時間処理を両立できるようになったことを書いたが、説明を分けてみようかと思いまして別記事を作成しました。

雑にAIに書かせていますので読みにくいかも知れませんがご勘弁を。ではどうぞ。

本記事は 動画生成に特化 した内容である。
画像生成については最適化が進み、現在ではVRAM問題は以前ほど深刻ではなくなってきている。

しかし動画生成では今なお、

VRAMが最大のボトルネック

である状況は変わらない。

---

VRAM問題の正体は「2種類のメモリを同時に収める必要があること」

動画生成におけるVRAM問題は、単に「重いから足りない」という話ではない。
本質的には、次の 2種類のメモリを同時にVRAMに収める必要がある という構造の問題である。

① ベースとなるデータ容量（固定的に必要なVRAM）

これは設定に関係なく、常に必要になる容量である。

• UNet や動画生成モデル本体

• ControlNet などの補助モデル

• Sampler関連のバッファ

• 精度設定（FP16 / BF16 など）

これらは、

何を生成するかに関係なく必ずVRAMを占有する「土台部分」

であり、動画生成では数GB単位になる。

---

② 作業容量（動画の画質・フレーム数で増えるVRAM）

もう一つが、生成内容によって変動する部分である。

• 解像度が高いほど増える

• フレーム数が多いほど増える

• 内部テンソル（latent / noise shape）が大きいほど増える

これは、

動画の画質・時間そのものがVRAMを直接消費する領域

と言える。

つまり動画生成では、

VRAM = ベース容量（モデル類） + 作業容量（画質・フレーム数）

という構造になっている。

---

問題は「この合計を同時にGPUに載せなければならない」こと

動画生成では、

• モデル（ベース容量）

• latentテンソル（作業容量）

• さらにVAE（場合によって）

を同時にGPUに常駐させる必要がある。

その結果、

少し画質を上げただけで
少しフレーム数を増やしただけで
一気にVRAMが限界を超える

という現象が起きる。

これが、

• OOM（Out Of Memory）

• デコード失敗

• 極端な低速化

の原因である。

---

VAEは「最大要因」ではないが「逃がせる要因」

よく

「VRAMを圧迫する最大要因はVAE」

と言われるが、これは正確ではない。

実際にVRAMを最も消費しているのは、

• latentテンソル

• UNet

• Sampler系処理

である。

しかしVAEには重要な特徴がある。

• 数GB単位のVRAMを消費する

• GPU常駐しやすい

• しかし CPUに逃がせる

• 品質自体には影響しない

つまりVAEは、

VRAMを空けるために動かせる数少ない要素

なのである。

---

VAEをCPUに出すことで得られるものと問題点

VAEをCPUに出すと：

• VRAMが空く

• より高解像度

• より長時間

• より高品質設定

を狙えるようになる。

これはつまり、

動画の「ランク」を一段階上げられる

ことを意味する。

しかし同時に重大な問題が生じる。

• latent → 画像変換が極端に遅くなる

• 動画では数十分〜数時間単位になる

• 実用性が大きく低下する

結果として、ユーザーは次の三択を迫られる。

---

強制される三択

① 品質を取る

VAEはCPU。高画質・長時間だが非常に遅い。

② 速度を取る

VAEはGPU。設定を落として品質を妥協。

③ バランスを取る

設定を細かく調整し、妥協点を探す。

これは本質的に、

VRAMという一つの箱にすべてを詰め込もうとする構造

が原因である。

---

発想の転換：処理フェーズを分ける

実際の処理は大きく2段階に分かれている。

フェーズ主な処理動画生成UNet + latentVAE処理latent → 画像

この2つを同時にGPUに載せる必要はない。

---

フェーズ分離運用という解決策（API方式）

筆者が採用したのは、

• 動画生成フェーズ：VAEをCPU

• VAE処理フェーズ：GPU

という形で、ComfyUI自体を起動し直して切り替える方式である。

API経由で：

1. 動画生成ジョブを送る

2. ComfyUI停止

3. 設定を変えて再起動

4. VAE処理ジョブを送る

という流れを自動化する。

---

この方式の最大のメリット：設定妥協から解放される

この方式の最大の利点は、

「速度か品質か」という選択をしなくてよくなる

点にある。

従来は：

• 解像度を下げる

• フレーム数を減らす

• stepsを減らす

• モデル精度を下げる

といった調整が必要だった。

しかしこの方式では、

単純に「最高画質」を目指せる

ようになる。

メモリ運用が整理されることで、

• VRAM調整ではなく

• 作品品質だけを考えればよい

状態になる。

正確にはVRAMのギリギリを攻める設定は必要だが、今までと比べると難しさは気にならない程度。

---

API方式のデメリット

ただし、この方法は万能ではない。

❌ ワークフロー変換が難しい

GUIワークフローをAPIワークフローに変換すると、
依存関係やファイル指定が崩れる場合がある。

❌ 修正が分かりにくい

GUIでは視覚的に修正できるが、APIではJSONやスクリプトになるため、

どこが悪いのか分かりにくい。

❌ 手動運用はほぼ不可能

API方式は本質的にコマンドライン処理であり、
人間が毎回手動で行うのは現実的ではない。

現実的には：

• スクリプトで自動化

• AIエージェント（AIUI）に任せる

必要がある。

---

AIUI運用の危険性と注意点

AIエージェントは強力だが危険も伴う。

筆者は先日、

ホームサーバーのデータの約7割を失う事故

を経験した。

これはAIが悪いというより、

雑に使ったことが原因

である。

重要なのは：

• AIに何を許可するか

• どこまで触らせるか

• どう監視するか

という運用知識が確立されていない点だ。

安全に使うための基本方針

• 作業ディレクトリを限定する

• 削除権限を与えない

• 本番データと分離する

• バックアップを必ず取る

• dry-runモードを使う

• ログを必ず残す

つまり、

AIは危険な作業員である前提で扱う

必要がある。

---

まとめ

動画生成におけるVRAM問題の本質は、

モデルなどのベース容量と、動画品質・フレーム数による作業容量を、同時にVRAMに収めなければならない構造

にある。

VAEは最大要因ではないが、

CPUに逃がせる重要な調整ポイント

であり、VRAMを作品品質に回せる。

しかしCPU VAEは極端に遅いという新たな問題を生む。

それを解決するのが、

処理フェーズを分離するAPI運用

である。

この方式により：

• メモリ運用が明確になる

• 設定妥協が不要になる

• 最高品質を単純に目指せる

• OOMが激減する

• 動画生成が安定する

という結果が得られる。

ただし、

• ワークフロー変換の難しさ

• 自動化の必須性

• AI運用の危険性

といったデメリットも存在する。

それでもなお、この方法は、

動画生成時代のComfyUIにおける新しい運用設計

として有効なアプローチである。