ComfyUIとLTX-2でローカル動画生成 — RTX 5070 Tiで1080p・5秒動画を出すまで
いま、ローカルGPUで動く動画生成アプリを開発しています。クラウドの動画生成サービスは便利ですが、枚数を回すと費用がかさみますし、生成データを外部に出したくない場面もあります。手元のゲーミングGPUでどこまでやれるのか。その裏側を支えているのがComfyUIです。
この記事では、ComfyUIとは何か、開発中のアプリがどういうパイプラインを補助するのか、そしてVRAM 16GBのRTX 5070 Tiで1080p・5秒動画のネイティブ生成に到達するまでの過程をまとめます。
ComfyUIとは何か
ComfyUIは、画像・動画生成AIをノードベースで動かすオープンソースの実行基盤です。「モデルを読み込む」「プロンプトをエンコードする」「サンプリングする」「動画として書き出す」といった処理を1つずつノードとして画面に置き、線でつないでワークフローを組みます。
料理に例えると、レシピの工程表をホワイトボードに付箋で貼っていくイメージです。「材料を切る」→「炒める」→「味付け」という付箋(ノード)を矢印でつなぐと、全体の段取り(ワークフロー)になります。付箋を差し替えれば別の料理になる。この柔軟さがComfyUIの強みです。
もうひとつ重要なのが、ComfyUIはHTTP APIを持っているという点です。組んだワークフローをJSON形式で書き出し、外部プログラムから POST /prompt で投げ込めば、画面を触らずに生成を実行できます。つまりComfyUIは「GUIツール」であると同時に「動画生成サーバ」としても使えます。開発中のアプリはこのAPIを利用しています。
開発中のアプリが補助するパイプライン
動画生成モデルに日本語の台本をそのまま渡しても、良い結果は得られません。実際には次のような手順が必要です。
- 日本語の台本を書く
- 台本をシーン単位に分割する
- 各シーンを英語の動画生成プロンプト(いわゆる呪文)に変換する
- プロンプトを1本ずつComfyUIに投入し、5秒程度のクリップを順次生成する
- できたクリップをつないで1本の動画にする
これを手作業でやると、シーンが10個あれば10回の翻訳と10回の投入が必要で、正直かなり面倒です。開発中のアプリは、この一連の流れを自動化します。テキスト処理はLM Studio(ローカルでLLMを動かすツール)に任せ、日本語の台本を入れると自動でシーン分割と英語プロンプト化を行い、確認・編集を挟んでからComfyUIへ順次投入します。プロンプトは日本語と英語を並べて表示し、意図と違えば修正して再英語化できるようにしました。
動画生成モデルにはLTX-2(19Bパラメータ)を使っています。テキストエンコーダにGemma 3 12Bを使う大型モデルで、音声(BGM)付きの動画を一度に生成できるのが特徴です。
1080p・5秒をRTX 5070 Ti(16GB)で出す
ここからが本題です。最初の検証では、1920x1088(1080p)のネイティブ生成は約3秒(89フレーム)が上限で、4秒以上はOOM(メモリ不足)で落ちました。中間テンソルが31GBまで膨張するログを見て、私は一度「1080pの5秒は16GBでは原理的に不可」と結論づけ、仕様書にもそう書きました。
ところがこの結論は誤りでした。切り分けを続けた結果、真因は3つありました。
1. 蒸留LoRAがfp4モデルを30GBに展開していた。 LTX-2はfp4という4bit量子化版を使っていたのですが、高速化のための蒸留LoRAを適用すると、該当層がbf16に展開されて約30GBに膨らんでいました。16GBを超えた分はRAMとVRAMの間を往復し続け(スラッシング)、GPU使用率100%なのに消費電力70Wで激遅、という不可解な状態の正体がこれでした。
2. torchのバージョンでfp4高速カーネルが無効だった。 fp4のまま高速に計算するカーネル(nvfp4)はtorchのcu130ビルドが必須でしたが、環境はcu128でした。入れ直すとLoRA込みでも展開が起きず、1ステップ3.7秒と約50倍速になりました。
3. テキストエンコーダのGemma(27GB)が居座っていた。 プロンプトのエンコードが終わった後もGemmaがVRAMに残り、サンプリングの領域を圧迫していました。そこで、エンコード直後にモデルをRAMへ退避させる小さなカスタムノードを自作し、ワークフローに挿入しました。これでサンプリング時の空きVRAMが大きく確保できました。
結果、1920x1088・153フレーム(5秒・30fps)がVRAMピーク9.63GBで完走。所要時間は約9分です。3秒なら約3.5分。Gemmaの初回ロードに約9分かかりますが、ComfyUIを起動したままにすれば2本目以降は不要なので、連続生成なら実用的な速度です。
ちなみにこの過程でGGUF量子化版も試しましたが、依存パッケージの導入が引き金でPython環境が壊れ、ゼロから再構築する羽目になりました。検証前に pip freeze のバックアップを取っていたのが唯一の救いです。環境を変える前のスナップショット、本当に大事です。
まとめ
- ComfyUIはノードベースの生成基盤で、APIサーバとしても使える
- アプリは「台本→シーン分割→英語プロンプト→順次生成」のパイプラインを自動化する
- 「VRAM不足で原理的に不可」に見えても、真因は量子化の展開・カーネルの有効化条件・エンコーダの常駐だったりする
OOMのエラーメッセージだけを見て諦めず、どこでメモリを食っているかを一段ずつ切り分けたことが突破口でした。アプリは現在開発中です。公開できる段階になったら、またこのブログで報告します。