前回のベンチマーク記事で、MiniMax H3の5秒動画がRTX 5090なら72秒で出る、と書きました。あれから私はすっかり気を良くして、H3の本命機能である「参照画像から動画を作る」Ref2VAで、上限の15秒を回すようになりました。そして気づきました。15秒は11分かかる。 5秒の9倍です。尺は3倍なのに。
原因はアテンションです。フレームが3倍になるとトークンも3倍、アテンションの計算量はその二乗で9倍。170万円の自宅AI環境の主砲であるRTX 5090が、1本の動画に11分かけて唸り続ける。しかも標準ワークフローに付いている「Turbo」モードを使うと、音が割れる。バリスタの声がビリビリ言う。私はTurboを封印し、11分待つ生活をしていました(震え声
そこで今回はClaudeと一緒に、2026年8〜9月に一気に出てきたH3の高速化手法を洗い出し、「素の公式ワークフロー」対「高速化スタック」を同じ条件で実測しました。結論から言うと、11分16秒が2分32秒(4.5倍)になり、音割れの犯人も分かりました。
まず結果をどうぞ
同じ参照画像2枚、同じプロンプト、同じシード(424242)で、960×544・15秒(362フレーム)のRef2VAを回したものです。まずは4.5倍速い方から。
こちらが素の公式ワークフロー。11分16秒です。
| 構成 | 総時間 | 対ベースライン | サンプリング | VAEデコード | VRAMピーク |
|---|---|---|---|---|---|
| 01 素の公式ワークフロー(20 step) | 675.9秒(11分16秒) | 1.00× | 645.1秒(32.2秒/step) | 24.7秒 | 31.7GB |
| 02 高速化スタック(Turbo 8-step + Sparse + INT8 VAE) | 151.5秒(2分32秒) | 4.46× | 129.2秒 | 16.5秒 | 31.8GB |
| 03 品質寄り(LoRAなし14 step + Sparse + EasyCache + INT8 VAE) | 218.3秒(3分38秒) | 3.10× | 191.5秒 | 21.0秒 | 31.7GB |
数字は2回目(ウォーム)の実行です。1回目(モデル・キャッシュを全解放してからの実行)もほぼ同じで、01が679.0秒、02が155.7秒、03が220.7秒でした。128GBのメインメモリのおかげで、21GBのモデルはOSのキャッシュから一瞬で戻ってきます。
音割れの犯人は「4 step」だった
先に犯人を書きます。H3は映像と音声を1本のシーケンスで同時にデノイズしますが、映像はshift 12、音声はshift 3と別々のスケジュールで動いています。ところが以前のComfyUIのサンプラーは両方を1本のスケジュールで進めていました。20 stepなら誤差で済んでいたものが、標準テンプレのTurboモード(4 step)では音声側を大きく踏み外す。それがあのビリビリの正体です。
対策は3つで、今回のスタックには全部入れています。
- ComfyUI本体の修正: v0.31以降、音声を別クロックで進める
ModelSamplingAVが入っています(Kijai氏のPR #15243)。私の環境は0.35.0 - 8-stepのLoRAを使う: 標準テンプレに同梱されているのは
ref2v_turbo_4step_v0.1(544p学習)。9月4日に出たref2v_turbo_8step_v1.0_768pに差し替えました - SigmaShiftをLoRAの学習値に合わせる: この8-step LoRAはvideo 6 / audio 3で蒸留されています。標準テンプレのTurbo経路にはSigmaShiftノード自体が無く、既定の12/3のまま動いていました
さらにBlock Sparse Attentionのsink_conditioningをexact_kv_and_rowsにして、音声のクエリ行だけは常にdense(全結合)で計算させています。本体ノードの説明文にも「生成音声を無傷に保つ」と書いてある設定です。
使った高速化手法
今回のスタックは、2026年8〜9月に出揃った手法を「層」ごとに1つずつ選んだものです。
| 層 | 選んだもの | 効き方 |
|---|---|---|
| ステップ蒸留 | lightx2v/ModelTCのRef2VA Turbo 8-step v1.0 768p LoRA(9月4日公開) | 20 step → 8 step |
| アテンション | ComfyUI 0.35で本体に入ったBlock Sparse Attentionノード、方式はsol-attn(NVIDIAのSol-Attn。訓練不要でクエリブロックごとに重要なキーブロックだけ厳密計算) | 1 stepが32秒 → 10秒 |
| VAE | Kijai氏のINT8 ConvRot Video VAE | デコード24.7秒 → 16.5秒 |
| キャッシュ(03のみ) | 本体のEasyCache、end_percent 0.70 | 14 step中2 stepをスキップ |
| 量子化 | 公式テンプレ既定のINT8 ConvRotモデル+NVFP4テキストエンコーダ(ベースラインと共通) | ─ |
sol-attnは「序盤20%のstepはdense、残りをsparse」という既定(start_percent 0.2)のまま使いました。ノイズだらけの序盤で構図を決める間は全結合、絵が固まってからは間引く、という思想です。
ベースライン(01)は公式テンプレートvideo_minimax_h3_r2vをそのまま、解像度を0.5MP(960×544)、尺を15秒、シード固定にしただけです。02と03はそのテンプレートからPythonで生成し(差分が追えるように)、フロントエンドのgraphToPromptでAPI形式に変換して投入しました。
参照画像とプロンプト
参照画像はQwen-Image-2512で作った2枚です。1枚目がバリスタの女性、2枚目が雨の夜のコーヒー屋台。(画像はQwen-Image-2512で生成したイメージ図)
プロンプトは英語で、前半6秒は屋台の引き画、後半9秒はバリスタがケトルで注いでカメラに向かって日本語で「いらっしゃいませ。今日は寒いですね。ホットコーヒー、お作りしますね。」と言う、という指示です。雨音・注ぐ音・小さなラジオのローファイジャズも入れています。日本語のセリフ・効果音・音楽が同時に鳴るので、音声のストレステストとしてはそこそこ意地悪です。
ステップごとの秒数を見ると、何が効いたか分かる
今回はWebSocketで進捗イベントを拾い、1 stepごとの秒数を記録しました。これが一番面白いグラフです。
- ベースライン: 20 stepすべて32.2秒。ぶれません
- 02 高速化: step 1〜2がdense(32.5秒、12.7秒)、step 3以降がsparseで10.3〜10.4秒
- 03 品質寄り: step 1〜3がdense、以降10.3秒。EasyCacheが2 step分をスキップ
つまり4.5倍の内訳は「step数が20→8で2.5倍」×「sparseで1 stepが約3分の1」で、その積が丸ごと出ていません。dense に残した序盤2 stepが、02のサンプリング129秒のうち約64秒を食っているからです。ここを削れば(start_percent 0.1など)さらに30秒縮む計算ですが、構図が決まる前に間引くので品質とのトレードオフになります。次回の宿題です。
VRAMはどの構成もピーク31.7GB前後で、32.6GBのRTX 5090がほぼ満杯です。ピークはdense区間で出るので、sparseにしてもピークは下がりません。1152×640に上げるとこのPCではシステムRAMに溢れて激遅になる、という報告があり、今回は960×544から動かしていません。
品質:絵はどうか
同じシードで3本を並べたものです。
- 03(LoRAなし14 step + sparse + EasyCache)はベースラインとほぼ同じ絵です。8フレームの平均でSSIM 0.648、PSNR 18.2dB。構図・カット割り・表情まで揃っていて、細部が少し違う程度。「ベースラインの絵を3.1倍速く出す」のがこれです
- 02(Turbo 8-step)は別の絵です(SSIM 0.354)。蒸留LoRAは同じシードでも軌道が変わるので、これは劣化ではなく仕様。カウンターの小物が増えて暖色寄りになり、バリスタの同一性は保たれています。「4.5倍速で、同じ質感の別テイク」と思えば実用的です
- 参照画像への忠実度は3本とも高く、黄色いエプロン、ホーローのケトル、ボブの髪、屋台の提灯と黒板はすべて出ました
品質:音はどうか
ここが今回の本題でした。6本の出力(3構成×2シード)を数値で見ます。
| 出力(シード) | true peak(dBTP) | LUFS | クリップ標本数 | 「ホットコーヒー」の発音 |
|---|---|---|---|---|
| 01 ベースライン(424242) | -0.36 | -15.2 | 0 | コーキー |
| 01 ベースライン(424243) | -0.11 | -15.4 | 0 | コーキー |
| 02 高速化(424242) | -0.26 | -14.5 | 0 | コーキー |
| 02 高速化(424243) | +0.22 | -14.3 | 4 | コーキー |
| 03 品質寄り(424242) | -0.27 | -15.6 | 0 | コーヒー |
| 03 品質寄り(424243) | -0.32 | -14.7 | 0 | コーキー |
- 6本すべてでセリフは通りました。 Whisper(large-v3-turbo)の転写は6本とも「いらっしゃいませ、今日は寒いですね、ホット○○お作りしますね」まで一致。ただし「コーヒー」の「ヒ」が「キ」寄りに発音されるクセがあり、6本中5本は私の耳でもWhisperでも「コーキー」。きちんと「コーヒー」と言えたのは03のシード424242だけでした。素の20 stepでも「コーキー」なので、高速化のせいではなくH3の日本語の癖です。セリフに「ヒ」が入るときは要注意
- 4 stepで起きていたビリビリは消えました。 クリップした標本は採用シードで0
- ただしTurbo(02)は素より0.6〜1.1dB音が大きく、シード424243ではtrue peakが+0.22dBTPで4サンプルがクリップしました。聴いて分かるレベルではありませんが、ベースラインからして-0.1〜-0.4dBTPという「元々ギリギリ」の音量なので、Turboで少し押し上げられるとはみ出す。音を最終納品に使うなら、02よりも03(LoRAなし)の方が安全です
速度以外のトレードオフ:動きの激しいシーンと、プロンプト追従
ここまでの結果を見て、「これだけ速くなると、画質・音質以外にも何か削れているのでは」と思いました。疑ったのは2つ。動きの激しいシーンでの破綻と、プロンプト追従性の低下です。同じ参照画像・同じシード(424242)で、意地悪なプロンプトを2本追加して3構成を回しました。
- motion: バリスタが雨の路地を全力疾走してカメラに向かってくる、手持ちカメラが後ずさりしながら揺れ、ホイップパンで追い、大きな水たまりをジャンプ。屋台の前で急停止して「間に合った!」
- adherence: 固定カメラで、5つの指示を順番どおり。(1) 右手で3本指を立てる → (2) 赤いマグを持って画面左に置く → (3) 黒猫が右から乗って座る → (4) 猫を指さして「あ、常連さんだ。」→ (5) 提灯が一瞬消えて点き、見上げる
動き:Turboはジャンプで壊れた
- 01 ベースライン: 疾走 → 水たまりを蹴る脚の寄り → 屋台で急停止 → 髪を振って両手を顔に → 笑顔。一貫しています
- 02 高速化(Turbo 8-step + sparse): 走り出しは良いのに、ホイップパンとジャンプが重なる7〜10秒で画面全体がぼやけて崩れ、その後10.7秒から何事もなかったように復帰します。動画で見るとこの3秒だけ別世界です
- 03 品質寄り(LoRAなし + sparse + EasyCache): ベースラインと同じようにジャンプを描き切っています
つまり破綻はsparse attention単独では起きず、Turbo LoRAを入れた構成で起きました。02と03のsparseの設定(sol-attn、tau 1.3、序盤20%はdense)は同じなので、犯人は8 stepへの蒸留の方です。ノイズから絵を決める序盤の余裕が少ないぶん、カメラも被写体も大きく動く区間では軌道を見失うのだと解釈しています。
プロンプト追従:落ちていない。Turboはむしろ従順
| 指示 | 01 ベースライン | 02 高速化 | 03 品質寄り |
|---|---|---|---|
| (1) 右手で3本指 | ○ | ○ | ○(5〜6秒にもう一度出す) |
| (2) 赤いマグを持って左に置く | △(持ち上げるが置き場所が不明瞭) | ○(左端に置かれる) | △(同左) |
| (3) 黒猫が右から乗って座る | ○ | ○ | ○ |
| (4) 猫を指さして「あ、常連さんだ。」 | ○(手を向ける。セリフ○) | ○(はっきり指さす。セリフ○) | ○(セリフ○、鳴き声まで出た) |
| (5) 提灯が一瞬消えて、見上げる | ○/✗(消えるが見上げない) | ○/○ | ○/✗ |
| 合計 | 4/5 | 5/5 | 4/5 |
- 追従性は落ちていません。 3構成とも5つの指示を順番どおりにこなし、日本語のセリフも3本とも通りました(Whisperの転写: 01「じょうれんさんだ」、02「あ、常連さんだ。」、03「あ、常連さんだ! ニャー!」。03は猫の鳴き声まで拾われています)
- 02(Turbo)が一番従順でした。指さしが最もはっきりしていて、赤いマグもきちんと左に置いています。蒸留LoRAはガイダンスの効き方を重みに焼き込むので、指示にはむしろ強く反応する傾向があるようです。代わりに背景が参照画像の路地から少し離れて、屋台の後ろに白い車が見えます。従順さと参照への忠実さは、少し引き換えになっている
まとめると、プロンプト追従は心配しなくてよく、動きの激しいカットだけTurboが苦手。走る・話す・物を置くくらいなら02で十分で、ジャンプやホイップパンのような「カメラも被写体も大きく動く」カットは03(LoRAなし)で出す、という使い分けになります。
人間がやったこと、AIに任せたこと
| 人間(私) | Claude |
|---|---|
| 目的と条件を決めた(Ref2VA、960×544、15秒、音質は落とさない) | 2026年8〜9月の高速化手法を調査し、層ごとに整理 |
| 「標準のTurboは音が割れるので使っていない」という経験を伝えた | 音割れの原因(4 stepと単一クロックのサンプラー)を特定し、3つの対策を組み込んだ |
| モデルのダウンロードと、GPUを1時間占有することを許可した | 公式テンプレートからワークフロー4本を生成するスクリプトを書き、配線を自動検証 |
| ブログの運用ルール(リポジトリ)を示した | 参照画像の生成、ベンチ用ハーネス(WebSocketで1 stepごとの時間、nvidia-smiでVRAM)、12本の実行、集計、グラフ、Whisper転写、この原稿 |
| 「速度以外のトレードオフ(動きの破綻、追従性)があるはず」と疑って、検証を追加させた | motion / adherenceの意地悪プロンプトを設計し、フレーム間差分と5指示の○×で評価 |
| 音を聴いて「コーキー」が本当にそう発音されていると指摘した(Claudeは当初Whisperの誤りと決めつけていた) | 記事を訂正 |
私がやったのは条件出しと許可出しだけで、GPUが唸っている間はコーヒーを淹れていました(本物の
正直、気になっていること
- 序盤のdense 2 stepが重い。 02のサンプリング129秒のうち約64秒。start_percentを0.1にすれば1 step分(32秒)縮むはずですが、構図が固まる前に間引くことになるので要検証
- sol-attn以外の方式を試していない。 Block Sparse Attentionノードには
sla(固定割合のtop-k。SLA蒸留LoRA向け)とvsa(FastVideo)もあります。8-step LoRAとsla10%の組み合わせは「40%速く、音のディテールがむしろ良い」という報告があり、次の候補 - dense区間のバックエンドはPyTorch SDPAのまま。
comfy kitchen attention(INT8)に切り替えればdense区間も速くなるはずですが、品質への影響が未検証 - 1シード1本の実測。 傾向は2シードで揃っていますが、統計的な話をするには本数が足りません。motion / adherenceも1本ずつなので、02のジャンプの崩れが「毎回」なのか「このシードで」なのかは未確認
- 4-step v0.1のLoRAは今回あえて回していません。音割れの再現より、直った構成を出すのを優先しました
まとめ
- RTX 5090でMiniMax H3 Ref2VAの15秒動画は、素の公式ワークフローだと11分16秒。 5秒の9倍で、原因はアテンションの二乗特性
- Turbo 8-step + Block Sparse Attention(sol-attn)+ INT8 VAEで2分32秒(4.46倍)。 品質の基準に近い絵が欲しければ、LoRAなし14 step + sparse + EasyCacheで3分38秒(3.10倍)
- 音割れの犯人は「4 step × 単一クロックのサンプラー」。 ComfyUI 0.31以降+8-step LoRA+SigmaShift 6/3で解消。ただしTurboは素より1dB近く音が大きくなるので、音を大事にするならLoRAなしの03構成
- sparse attentionは長尺ほど効く。 1 stepが32秒→10秒。dense に残す序盤の割合が次の調整点
- プロンプト追従は落ちない、激しい動きだけTurboが壊す。 5つの順序指示は3構成とも守り、Turboはむしろ従順。ホイップパン+ジャンプは02で3秒溶けた。そういうカットはLoRAなしの03で
H3の15秒生成が「PCから離れる前に仕込むもの」から「コーヒーを淹れている間に出るもの」になりました。同じ悩みを抱えている方は、まずref2v_turbo_8step_v1.0_768pとSigmaShift 6/3、それからBlock Sparse Attentionノードの3点から試してみてはいかがでしょうか。
2分半なら、短気な五十路でも待てる。
コメント