前回は、言葉で伝わらない動きを、Blenderで15秒の参照動画にしました。今回は、その参照動画を実際に使って生成した結果です。
先に結果を書きます。
- 手元のデスクトップ(RTX 5060 Ti 16GB)では、約23時間たっても1本も完成せず、止めました。
- クラウドで借りたRTX PRO 6000(96GB)では、1時間15分で完成しました。
- できた動画は、人物が正確に再現され、体の大きな動きと7つのカットの順番も、参照動画のとおりに出ました。一方で、背景の流れ方とワイヤーの出方に問題が残りました。
できた動画
連載の彼女が、某人気アニメ風の「ワイヤーで空を飛ぶ装備」で、廃墟の街を飛んで屋根に降りる15秒です。人物はAI生成です。衣装の一部には、ぼかしを入れています。
生成の条件は次のとおりです。
| 項目 | 内容 |
|---|---|
| 動画生成AI | MiniMax H3(量子化なしのbf16) |
| 大きさ・長さ | 1216×672・約15秒・24fps |
| ステップ数 | 20(高速化のLoRAは使っていません) |
| 渡した素材 | 人物と装備の画像3枚、前回の参照動画1本(1920×1080・15秒・無音) |
| 機材 | クラウドのRTX PRO 6000(96GB) |
参照動画は、どこまで伝わったか
上が参照動画、下が生成した動画です。同じ時刻のコマを並べました。
灰色の人形は連載の彼女に、箱の街は石造りの廃墟の街に置き換わりました。そして、7つのカットが、同じ順番で、近い構図で出ています。正面、見上げる、構えて引き金、後ろからの発進、前方からの飛行、屋根への着地、顔のアップ、の順です。
カットが切り替わる時刻も比べました。
| 切り替わり | 参照動画 | 生成した動画 |
|---|---|---|
| カット1→2 | 2.08秒 | 1.83秒 |
| カット2→3 | 2.88秒 | 2.50秒 |
| カット3→4 | 4.38秒 | 3.88秒 |
| カット4→5 | 5.83秒 | 5.71秒 |
| カット5→6 | 11.21秒 | 9.71秒 |
| カット6→7 | 13.00秒 | 12.71秒 |
ほとんどの切り替わりは、0.5秒以内のずれです。飛行から着地への切り替わりだけ、約1.5秒早くなりました。その分、飛んでいるカットが短くなっています。
前回の最後に「生成したら見る」と書いた4点は、次のようになりました。
| 見る点 | 結果 |
|---|---|
| ワイヤーが、細い2本のまま保たれるか | 2本のままでした。ただし、腰の射出装置から出ていません(次の節) |
| 撃った先と、飛ぶ方向が合っているか | 通りに沿って上がっています。ただし、ワイヤーが建物より高い所へ打ち出されていて、前へ進んでいるようにも見えません(次の節) |
| 顔と装備が保たれるか | 保たれました。人物は、7カットを通して正確に再現されています |
| 7カットが、どこまでそのとおりに出るか | 7カットとも、同じ順番で出ました。着地への切り替わりだけ約1.5秒早いです |
カットの並びと時刻を運ぶ役目は、参照動画が果たしたと見ています。
よかった点と、問題が残った点
当方の評価をまとめます。
よかった点は2つです。
- 人物が、正確に再現されている。 顔も衣装も装備も、参照の画像のとおりです。
- 体の大きな動きが、参照動画の指定どおりに出ている。 構える、引かれて上がる、屋根に降りる、という流れです。
問題が残った点は3つです。
- 背景の流れ方がおかしい。 飛んでいる間、人物が前に進んでいるように見えません。奥の突き当たりの建物の大きさが、ほとんど変わらないためです。
- ワイヤーが、建物より高い所へ打ち出されている。 建物の壁に固定して引かれる、という形になっていません。
- ワイヤーが、腰の射出装置から出ていない。 装置と線がつながって見えません。
原因は、まだ確かめていません。1つ目の背景については、候補を2つ考えています。
- 文章の側: 飛行カットの説明は「参照動画の動きに従う」という書き方でした。「通りに沿って前へ進む」「建物が次々に現れて、後ろへ遠ざかる」といったことは、具体的に書いていませんでした。
- 参照動画の側: 飛行カットのカメラは、人物と一緒に動きます。画面の中の人形はほぼ同じ位置にいて、動いているのは箱の建物だけです。箱には窓などの目印が無いので、「前へ流れている」手がかりが弱かった可能性があります。
2つ目と3つ目のワイヤーについては、参照動画の細い線と固定点が、生成の側でどう読まれたのかを、これから調べます。
どれを直すにしても、直しては生成する、を何度か繰り返すことになります。ここで、1回にかかる時間が問題になります。
手元の機材では、時間が合わなかった
最初は、手元のデスクトップで生成を始めました。
| 項目 | 手元のデスクトップ |
|---|---|
| 機材 | RTX 5060 Ti 16GB(1枚)、メモリ約64GB |
| モデル | 量子化したモデル(int8・約21GB)と、8ステップ用の高速化LoRA |
| 大きさ・長さ | 0.6MP(16:9)・15秒・24fps |
| ステップ数 | 8 |
| 渡した素材 | 画像3枚と、同じ参照動画1本 |
| 始めた時刻 | 10月8日 06時02分 |
| 止めた時刻 | 10月9日 05時00分に中断を指示(2分後の時点では、まだ止まりきっていませんでした) |
| 結果 | 約22時間59分で、完成した動画は0本 |
クラウドより軽い条件(量子化・小さい画面・8ステップ)です。それでも終わりませんでした。
止める直前の状態も残しました。GPUの使用率は100%、GPUのメモリは16,311MiBのうち15,765MiB(約97%)を使用。画面の進み具合の表示は13%でした(何の割合かは、記録では確かめられていません)。記録用のログは、始めて6分後の「モデルの準備ができた」という行が最後で、その後の進み具合は残っていません。
前日には、同じ量子化モデルと同じ高速化LoRAで、別の生成が約28分で終わっています。ただし、解像度や渡した素材がそろっているかは確かめていません。今回なぜここまで時間がかかったのかは、まだ確かめられていません。当方が考えている理由は、参照動画の大きさです。
前回、参照動画のワイヤーを細くしました(太さ20mm→3mm)。細い線が見えるように、参照動画の解像度をフルHD(1920×1080)にしました。この大きな参照動画が、生成のときにメモリを占めてしまった可能性があります。
測って確かめたわけではないので、仮説です。確かめるには、参照動画だけを小さくして、同じ条件で生成して比べる必要があります。
もう1台のM5 Mac(32GB)では、今回の条件は試していません。参考になる過去の実測があります。参照動画を使わず、画像2枚だけを渡した15秒(0.8MP・20ステップ・量子化なし)で、9時間23分かかりました。ここに15秒の参照動画が加わると、一晩で終わらない可能性が高いと見ています(見込みで、実測ではありません)。
クラウドのRTX PRO 6000に持っていった
そこで、クラウドGPUのRunPodで、RTX PRO 6000(96GB)を借りました。当方は商社勤務の会社員で、エンジニアではありません。環境づくりは、AIのエージェント(Codex)に画面とログを見てもらいながら進めました。
| 項目 | 記録 |
|---|---|
| 単価 | GPUが1時間2.09ドル。保存領域200GBを足して、1時間2.12ドル |
| 借りてから生成を始めるまで | 約1時間20分(環境づくり約35分。残りはワークフローの修正と素材の登録) |
| モデル一式のダウンロード | 約124GBが、画面の記録では2分あまり |
| 生成にかかった時間 | 1時間15分04秒(うち20ステップの計算が1時間10分27秒。1ステップ約211秒) |
| 借りていた時間 | 約2時間43分(破棄の少し前の表示) |
| 費用の目安 | 約5.75ドル(単価×時間の計算値。請求の確定額ではありません)。生成1回分だけなら約2.65ドル |
手元のデスクトップとは、条件がそろっていません。クラウドのほうが、モデルも画面も大きく、ステップ数も多い条件です。そのため「何倍速い」とは書けません。書けるのは、「手元では約23時間で0本、クラウドでは重い条件で1時間15分に1本」という事実だけです。
終わったら、動画とログを手元に落としてから、借りた機械を破棄しました。破棄すると中身は全部消えるので、落とすのが先です。
96GBでも、重みを全部は置かなかった
意外だったのは、96GBのGPUでも「余裕」ではなかったことです。生成が始まるとき、メモリの配分を自動で決める部品が、次のログを出しました。
[H3AutoReserve] keeping all 61.7 GB of weights resident would leave only -0.4 GB of slack over the pool's bare need - under the 8.5 GB driver headroom every clean run keeps (2026-08-21: that squeeze ran 22x slower than streaming). Reserving 40.5 GB and letting ~9.0 GB of weights stream.
[H3AutoReserve] driver headroom: raising the reserve 40.5 -> 49.0 GB so ~17.5 GB of weights stream instead of riding the last few percent of VRAM (that zone measured 2-12x slower).読み方は、こうです。
- モデルの重みは61.7GBあります。これを全部GPUに置いたままにすると、計算に使う分の余裕が足りません。
- そこで、計算用に49.0GBを確保し、重みのうち約17.5GBは、必要なときにGPUへ送る形にしました。
メモリ不足で止まったわけではありません。この配分のまま、最後まで完走しています。「重みが61.7GBだから、96GBなら全部載る」とは言えない、という記録です。計算に使う分と、余裕の分が別に要ります。
かっこの中の「22x」「2-12x」は、この部品の作者が過去に測った値です。当方の実測ではありません。また、参照動画なしの条件とは比べていないので、「参照動画を足したから載らなくなった」とまでは言えません。
参照動画の最後が切れる決まり
もう1つ、同じことをする方に役立ちそうな点です。
H3が扱うコマ数には、「17の倍数+5」という決まりがあります。15秒・24fpsの参照動画は360コマです。このまま渡すと、決まりに合う345コマに切りそろえられて、最後の15コマ(約0.6秒)が使われません。前回の参照動画では、最後の顔のアップの終わりにあたります。
対処として、ワークフローの中で、参照動画の最後のコマを2枚足して362コマ(17×21+5)にしました。元の動画ファイルは変えていません。
なお、できた動画は、音つきの版が358コマ(約14.9秒)、音なしの版が362コマでした。音の長さに合わせて映像を切る設定が入っていたためと見ています。
詰まった所
- 黒い画面(Web terminal)の接続が、途中で切れました。 つなぎ直すと、借りた機械もダウンロードしたモデルも残っていました。切れただけで作り直す必要はありません。
- ComfyUIを開くリンクを押しても、開きませんでした。 アドレスをコピーして、ブラウザに貼り直すと開きました。
- メモリの表示にだまされかけました。 黒い画面の表示では約1.5TBと出ますが、これは貸し出し元の機械全体の量です。借りた分は約179GBでした(ComfyUIのログの表示)。
- ログを流している最中に命令を打っても、実行されません。 いったんログの表示を止めてから打ちます。
まとめ: 強いクラウドGPUは「抑え」に取っておく
今回の記録から、当方はこう考えています。
- 参照動画つきの長い生成は、手元の機材では時間が合わない場面がある。
- 一度で決まることは少なく、文章や参照動画を直しては生成する、の繰り返しになる。
- その繰り返しには、1回が現実的な時間で終わる場所が要る。
ふだんの試作は手元で回し、手元で終わらない重い条件のときだけ、クラウドの強いGPUを借りる。最後の拠り所として、借り方だけは押さえておく。今回の1回は、生成の分だけなら約2.65ドルでした。
まだ分かっていないことも、書いておきます。
- 飛行カットの「前へ進む感じ」は、文章と参照動画のどちらを直せば出るのか。
- ワイヤーを、建物に固定して、腰の射出装置から出すには、何を直せばよいのか。
- 手元のデスクトップで、なぜ約23時間かかっても終わらなかったのか。フルHDの参照動画が原因なら、小さくして渡すと、時間と出来がどう変わるのか。
次は、飛行カットとワイヤーを直して、もう一度生成します。結果は、この連載で報告します。
連載の全体は記事マップに、機材ごとの所要時間は実測早見表に、これまでに出会った症状と対処はトラブル早見表にまとめています。
本記事の動画と画像の人物はAI生成です。衣装の一部に、ぼかしを入れています。数値は2026年10月8日〜9日時点の当方の記録に基づきます。クラウドの単価や画面は変わることがあります。費用は計算値で、請求の確定額ではありません。
コメント