AI動画1本を21分から11分にした8つの実験｜効いた設定と効かなかった設定

速くする前に、どこに時間が消えているかを測りました。1本あたり約21分のうち、動画生成の工程はこう分かれていました。

サンプリングが支配的です。ここを削らない限り何をやっても誤差にしかなりません。

行列計算を fp8 の高速モードに切り替えました。GPU 世代が対応していれば、設定を 1 行変えるだけです。

1.41 倍。解像度もステップ数も動きの指定も変えていないので、画質への影響はほぼありません。

本命はこちらです。使っていた高速化用の追加モデルは、そもそも 4 ステップで動くように蒸留されたものでした。にもかかわらず 8 ステップで回していた。さらに CFG を 2.0 にしていたため、1 ステップあたり 2 回計算していました。

つまり実際には 8 × 2 = 16 回 計算していたところを、4 × 1 = 4 回 にできるはずでした。

77% 減、4.4 倍速。

事前に一番心配していたのは「ステップを減らすと動きが途中で止まるのでは」でした。そこで最も動きの大きいケースを選び、開始画像・プロンプト・seed を完全に固定して変更前後を比較しました。結果、動きは最後まで完遂し、画質も同等でした。

CFG を 1.0 にすると計算が半分になりますが、代償があります。

CFG は「指示に従った絵」と「指示を無視した絵」の差を強調する仕組みです。1.0 にするとその比較自体をやめるので、「これは出すな」という指定が動画工程で無効になります。

• 開始画像を作る工程のネガティブ指定は効いたまま
• 動画は開始画像の色や見た目を引き継ぐので、影響は限定的
• ただし動画工程で新たに出る破綻は、ネガティブでは抑えられない

残る無駄で最大のものは、毎回発生する約 150 秒でした。動画を作る前に画像をエンコードする工程で、メモリ不足に失敗して遅い迂回路に落ちているのが原因です。

調べて分かったのは、迂回路そのものが遅いということでした。通常の経路なら数秒で終わります。

本当の解は「通常の経路がメモリに収まるようにする」ことですが、この GPU は同じ GPU を使う別のワークロードと共有していて、こちらの都合だけで空きを確保できません。

見送りました。画質を落とすか環境を変えるかしかなく、前者は本末転倒です。

開始画像の生成時間が 20 秒から 756 秒まで大きく振れていました。設定を絞れば安定するのではないかと考え、測りました。

設定は悪くありませんでした。振れているのは同じ GPU を使う別のワークロードとの競合が原因で、実験1で見送ったのと同じ根っこでした。

縮められそうなレバーも検討しましたが、いずれも却下しました。ステップ数を減らしても削れるのは 4 秒で、その 4 秒のために全動画の元になる 1 枚の品質を落とすのは割に合いません。

4.4 倍速の設定をデプロイした直後、実際には古い設定のまま動いていました。

原因は 3 つ重なっていました。

1. コードを転送した後、実行中のプロセスが「もう起動している」と判断されて再起動がスキップされた
2. Python のキャッシュファイルが残っていて、古いコードが読み込まれ続けた
3. 稼働確認に使ったコマンドが、自分自身にマッチして「動いている」と誤判定した

以後は、確実に停止させ、キャッシュを消し、クリーンに起動し、ログに出るステップ数が実際に変わっていることを目で確認する手順にしました。設定値そのものより、反映されたかを確かめる方法の方が重要でした。

画質は落としていません。解像度もフレーム数も変えておらず、採用した設定は同種のサービスが本番で使っている標準的な値と一致していることも後から確認しました。

残っている無駄は約 150 秒で、これは共有 GPU が原因なので専有できる環境に移れば自動的に解決します。コードでやれることは出し切りました。

1. まず内訳を測る。支配的な工程が分からないうちに手を出すと、効果が数十秒しかない場所に労力を使うことになります。
2. リスクの小さい変更から順に。大きく変えて失敗すると、原因の切り分けができません。
3. 一度に 1 つだけ変える。開始画像・プロンプト・seed を固定しないと、速くなったのか設定のせいなのか分かりません。
4. 最悪のケースで検証する。平均的なケースで通っても意味がなく、一番厳しい条件で壊れないかを見ます。
5. 見送りも記録する。「試したが効かなかった」を残さないと、半年後に同じ実験を繰り返します。
6. 反映されたかを確認する。設定を変えたつもりで変わっていない事故は、設定そのものより高くつきます。