動画1本の生成を80秒から43秒に：試したすべての手と実測値
高速化の過程をそのまま書きます。まず何を測るか、ボトルネックはどこだったか、変えた3点とその効果、そして「もっともらしいのに」あえてやらなかったことと、その理由。
2026-08-20 作者 William Hsu
測ってから変える
このモデルにはサンプリングのステップ数という調整項目があり、直感的には減らせば速くなりそうです。 測った結果はそうではありませんでした。
ComfyUIは実行中にWebSocketでノードごとの進捗を返してくるので、3秒の動画1本について各段階の時間を記録しました。
| 段階 | 所要時間 |
|---|---|
| 写真の内容を読み取る（テキスト／画像エンコーダ） | 約17.7秒 |
| サンプリング（実際に写真を動かす工程） | 約11秒 |
| VAEデコード（結果を画面に現像する） | 約11.4秒 |
| その他 | モデルの重みをカードへ運ぶ時間 |
サンプリングは全体の4分の1程度なので、ステップ数を削って浮く時間には限りがあります。
ボトルネックは30GBのモデルを16GBのカードに入れること
カードはRTX 5070 Ti、ビデオメモリ16GB。このモデルはテキストエンコーダと本体だけで30GBを超えるので入りきらず、 実行のたびに重みをカードへストリーミングすることになります。
消えている時間はデータの移動であって計算ではありません。以下の3つの変更はすべて 「運ぶものを小さくする」方向に向いています。
変更その1：ひとまわり小さいテキストエンコーダに交換
25.3GBを14.6GBの量子化版に替えると、毎回10GB以上運ぶ量が減ります。3つのうちこれがいちばん効きました。
量子化は理屈のうえでは画質を落とします。同じ乱数シードで前後を比較しました。 同じ写真、同じ動き、同じシードで並べても違いは分かりません。シードを固定するのは必須で、 固定しなければ2回の結果はもともと違うので、比べる意味がありません。
変更その2：サンプリングを6ステップから4ステップへ
手抜きに見えますが、使っている高速化LoRAはもともと4ステップ向けの設計です。6ステップにしても良くはならず、 時間が増えるだけ。このパラメータは別の設定から引き継いだもので、いまのモデルには合っていませんでした。
変更その3：使っていない音声デコードを外す
このモデルの標準ワークフローには音声デコードのノードが入っています。このサイトの成果物は音のないループ動画なので、 その計算結果は最初から最後まで誰にも使われていませんでした。
他人のワークフローを流用すると、こういうものが残ります。見つけ方はノード単位で測ること。 そして時間のかかるノードごとに「この出力は使われているのか」と問うことです。
結果
1本60〜80秒（最悪137秒）から安定して42〜45秒になりました。
ばらつきも収束し、137秒のようなことは起きなくなりました。利用者から見た違いは 「毎回43秒」対「平均60秒だがときどき137秒」です。
偶然の裏づけ
別の検証をしていたとき、同じパラメータで2回目を走らせたら17.2秒で終わりました。 ComfyUIが前回のエンコード結果をキャッシュしていて、あの17.7秒をまるごと飛ばしたからです。 上の表とぴったり一致します。
やらなかったこと
- モデルをビデオメモリに常駐させる 16GBに30GBは入りません。ハードウェアの制約で、カードを替えるしかない
- もっと激しい量子化 さらに圧縮すると画質の劣化が見えてきます。このツールの要点は 「同じ人だと分かること」なので、数秒と引き換えにする価値はない
- より小さいVAEデコーダ（TAEのようなもの） あの11.4秒はまだ圧縮の余地がありますが、 追加のノードが必要で、画質への影響も検証し直しになります。これはToDoのままで、 やり終えていないものを成果として書くつもりはありません
振り返り
覚えておく価値のあることが3つ。ノード単位で測っていなければ、私は全体の4分の1でしかないサンプリングステップに 労力を注いでいました。ビデオメモリが足りないときのボトルネックはデータ移動で、 最適化の方向も「運ぶものを小さくする」に変わります。そして前後比較では必ず乱数シードを固定すること。 そうしないと、画質の差が変更によるものか偶然によるものか区別できません。