MiniMax H3 の動画生成を約2倍速くする(RTX3060[12GB]+RAM32GB) ― EasyCache + SageAttention 2 実測レポート

はじめに

以前、MiniMax H3用に自作WebUI「H3 Studio」を作った話という記事を書きました。動くには動いたものの、RTX 3060(VRAM 12GB)環境では5秒の動画1本に約13分かかっており、正直かなり遅いと感じていました。

そこで「品質を落とさずに速くできないか」を実測ベースで検証しました。結論から言うと、追加のモデル変換やダウンロードなしで約2倍速にできました。この記事はその過程と実測値の記録です。

まず「何がボトルネックか」を疑うところから始めた

ネットで調べると、「12GB VRAMに対してモデルが約40GBあるので、RAM⇔VRAM間の転送がボトルネック」という前提の最適化案(高速ディスク優先読み込みなど)をよく見かけました。もっともらしく聞こえたので、最初はそれを信じかけました。

ただ、実際にサンプリング中のnvidia-smiを250ms間隔でサンプリングしてみると、様子が違いました。

項目	実測値
GPU使用率	80サンプル中76回が99%
消費電力	133〜160W(TDP 170W)
SMクロック	1860MHzに張り付き
VRAM使用量	7968 / 12288 MiB(4.3GB余裕あり)

サンプリング中はほぼ純粋にGPU計算がボトルネックで、VRAM容量にも転送速度にも余裕がありました。 さらに手元の環境ではモデルの置き場所がHDD(7200RPM)だったため、「高速ディスク優先」系のオプションはむしろ悪化させる可能性が高いことも分かりました。

教訓: 汎用的な最適化Tipsを鵜呑みにせず、まず自分の環境で何がボトルネックになっているか実測すべき。 今回はこれでコールドロード(モデル読み込み)対策と、サンプリング自体の高速化を切り分けて考えることにしました。

試したもの

サンプリングがボトルネックと分かったので、「1ステップあたりの計算を減らす/軽くする」方向で2つを試しました。どちらもComfyUI本体の標準機能か公開されているオープンソースパッケージのみで、モデルの再変換や追加ダウンロードは不要です。

① EasyCache(ComfyUI標準ノード、追加インストール不要)

ComfyUIにはcomfy_extras/nodes_easycache.pyとしてEasyCacheノードが標準搭載されています。前のステップの出力変化量を見て、変化が小さいと判断したステップはTransformerの計算そのものをスキップし、キャッシュを再利用する仕組みです。

コード上、[video, audio]のようなリスト型の潜在変数(LTX2のAVペア想定のコメントあり)にきちんと対応しており、H3のvideo_x, audio_x = x[0], x[1]という構造ともそのまま噛み合いました。UNETLoaderの出力をEasyCacheノードに通してからBasicScheduler/BasicGuiderに繋ぐだけで使えます。

UNETLoader → EasyCache → BasicScheduler
                       → BasicGuider

設定は既定値(reuse_threshold=0.2, start_percent=0.15, end_percent=0.95)のまま使いました。

② SageAttention 2(要インストール)

Attention計算(QKᵀ・PV)を量子化して高速化するカーネルです。H3のAttentionはhead_dim=128・56ヘッド・マスクなしという、SageAttentionが最も得意とする形に合致していました。

導入は2パッケージのインストールのみで完了しました(コード変更なし)。

# torch 2.13.0+cu130 / Python 3.10 の場合
pip install "https://github.com/woct0rdho/SageAttention/releases/download/v2.2.0-windows.post6/sageattention-2.2.0%2Bcu130torch2.10.0andhigher.post6-cp310-abi3-win_amd64.whl"
pip install triton-windows

ComfyUI起動時に--use-sage-attentionを付ければ、グラフ側の変更なしで全Attentionに自動適用されます。

python main.py --port 7821 --use-sage-attention

起動ログにUsing sage attentionと出れば有効化成功です。

実測方法

条件を揃えるため、既存の生成動画に埋め込まれたComfyUIワークフローのメタデータ(ffprobeで抽出可能)から、同一プロンプト・同一パラメータを復元して使いました。

• 解像度: 864×480 / 5秒(124フレーム)
• サンプラー: res_multistep / scheduler: simple / 20 steps
• モデル: minimax_h3_fl2va_pruned_int8_convrot.safetensors + qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors
• シードは全ケースで固定(ただしComfyUIのノードキャッシュにより完全に同一グラフを再送信すると計算をスキップして即終了してしまうため、比較用に再実行する際はシードを1つだけずらして回避)
• モデルは各回ともロード済み(ウォーム)の状態で計測(コールドロード分の数分は除外)
• 計測はComfyUIの/history APIが返すexecution_start〜execution_successのタイムスタンプ差分を使用(体感時間ではなく実測)

結果

5秒クリップ1本での比較です。

構成	所要時間	ベースライン比
ベースライン(何もなし)	782.3秒(13分2秒)	—
EasyCacheのみ	428.2秒(7分8秒)	-45.3%(1.83倍速)
SageAttentionのみ	509.7秒(8分30秒)	-34.8%(1.53倍速)
両方併用	399.7秒(6分40秒)	-48.9%(1.96倍速)

[VIDEO-1] ベースライン / EasyCache / SageAttention / 併用の比較動画

なぜ「1.83倍 × 1.53倍」にならないのか

併用時、単純な掛け算なら約2.8倍速(279秒)になる計算ですが、実際は約2倍(399.7秒)止まりでした。理由は仕組み上当然で、

• EasyCacheは「Attention計算そのものをスキップする」仕組み
• SageAttentionは「実行されたAttention計算を軽くする」仕組み

なので、EasyCacheがスキップしたステップにはSageAttentionの効きようがありません。両者の恩恵が重なるのは「EasyCacheが省略しなかったステップ」だけです。さらにVAEデコードやテキストエンコードなど、どちらの手法も触れない固定コストも残ります。

品質は落ちていないか

速度だけでなく、ここが一番気になる点だと思います。今回確認した範囲では、明確な破綻は見当たりませんでした。

• EasyCache版は出力ファイルサイズがベースライン比+26%になりましたが、目視・音声確認では問題なし
• 別途、剣戟シーンで3秒クリップを3パターン(異なる場面・異なるプロンプト)、EasyCache+SageAttention併用で生成し、特に懸念していた音声のタイミング・音質を確認 → 問題なし

[VIDEO-2] 剣戟シーン3秒版(併用構成)×3パターン

ただし正直に書くと、この検証はシード1つ・少数サンプルでの確認に留まっており、統計的に十分とは言えません。 本番用途で使う場合は、ご自身のプロンプト・シードで一度目視/耳で確認することをお勧めします。特にEasyCacheは「前ステップとの変化が小さい」という判定に基づいてスキップするため、動きの速いシーンや細かいディテール(指・目など)で影響が出る可能性はあります。

おまけ: 短尺だと思ったより速くならなかった

3秒(73フレーム)クリップは、5秒(124フレーム)の併用結果(399.7秒)とほぼ同じ370〜416秒かかりました。フレーム数が59%になったのに時間はほぼ変わらないのは想定外でした。考えられる理由は、

1. 今回使ったプロンプトが元のテストよりかなり長文(タイムライン指定+音響指示込み)で、テキストエンコード(Qwen3VL-32B)のコストが相対的に大きくなった
2. 短尺だとEasyCacheの変化量推定が"温まる"前にサンプリングが終わり、スキップできるステップ数自体が減っている

のどちらか(または両方)だと推測していますが、ここは未検証です。短尺を大量に作る用途では、この点を踏まえて実測することをお勧めします。

環境

• GPU: RTX 3060(VRAM 12GB) / RAM 32GB
• ComfyUI 0.30.0 / torch 2.13.0+cu130 / Python 3.10.6
• sageattention 2.2.0+cu130torch2.10.0andhigher.post6 / triton-windows 3.7.1.post27

まとめ

• MiniMax H3の生成がRTX 3060で遅い原因は(少なくとも自分の環境では)VRAM容量やディスク転送ではなく純粋なGPU計算時間だった
• ComfyUI標準のEasyCacheノードだけで、追加インストール一切なしで約45%短縮
• SageAttention 2 + triton-windowsの追加インストールで約35%短縮
• 両方併用で約49%短縮(ほぼ2倍速)、5秒クリップが13分→6分40秒に
• 品質面は簡易的な確認範囲では問題なし。ただし検証は限定的なので過信は禁物

モデルの量子化形式を変えたりせず、既存のComfyUI標準機能とオープンソースのAttentionカーネルだけでここまで縮まったのは嬉しい誤算でした。同じ12GB帯のGPUで動かしている方の参考になれば幸いです。