8GBのグラボでMiniMax H3を動かした（実測値ぜんぶ）

前回まで、借りたGPU（RunPodの4090とRTX PRO 6000）でMiniMax H3を回した話を書きました。今回は「では自分のマシンで動くのか」です。

なぜそこにこだわるのか、先に書いておきます。

Seedance 2.0 や 2.5 は、モデルとしては本当に良いです。ただ、十分に予算が取れる案件でないと使いづらい。

試し撃ちができないんです。1本ずつ課金が気になって、納得いくまで回せない。「じゃあ無制限プランを」となるのですが、無制限は年間契約に紐づいていることが多い。

この「無制限」の三文字に、私は何度もやられています。気づけば、ほとんど使っていない年間契約がいくつも残っていました。契約した時点では、たしかに一番良いツールだったんです。

そう、そこが問題で——AIツールは進化が速すぎます。 数か月で、まったく別のツールのほうが優れている、ということが普通に起きる。1年先に自分が何を使っているか分からないのに、1年分を先に払うのは、筋が悪いと思うようになりました。

試したいだけなのに、年単位の判断を迫られる。 ここが行き止まりでした。

ローカルで回せるなら、この構造ごと抜けられます。

手元にあるのは RTX 3060 Ti、VRAM 8GB。H3のモデルは本体だけで19.5GBあります。どう考えても載りません。

結論から言うと 動きました。480p・15秒・音声つきまで通っています。さらにそのあと、720p相当（0.9MP）も通りました。続きを繋ぐ仕組みも動いて、10秒を2本繋いで20秒まで確認しています。

手元の8GBのカードで出したものです。 832×480で、静止画1枚から10秒・7カット。その続きの10秒を繋いで、20秒にしています。（音は別で作って乗せています。理由は後述します）

そこに至るまでに踏んだ罠と、測った数字を全部置いておきます。

この記事でわかること

• 8GBで動かすための構成（モデル4本・起動フラグ3つ・当てるパッチ）

• VRAMより効くのはシステムRAMという話

• 実測値（5秒/10秒/15秒 × turbo有無 × サンプラー別の時間とVRAM）

• 15秒を通す方法（VAEのPRを2ファイル当てるだけ）

• 720p相当が通ることと、1280×720がエラーになる本当の理由

• 続きを繋ぐ方法（20秒まで実測）と、そのときの色ズレ

• 効かなかったもの（EasyCache / SageAttention / 音の制御6通り）

• 借りたGPUとの使い分け

⚠️ 数字はすべて 2026年8月11日時点のものです。H3は公開から8日で、毎日のように新しいものが出ています（最後に触れます）。

環境

• GPU／RTX 3060 Ti 8GB（Ampere / SM86）

• ドライバ／591.86

• システムRAM／64GB

• ComfyUI／0.31.0（ポータブル版）

• Python／3.13.14

• PyTorch／2.13.0+cu130

• comfy-kitchen／0.2.28

• triton-windows／3.7.1.post27

すでに ComfyUI Desktop 版を画像生成に使っていて、カスタムノードが30個入っています。そこには一切触らず、別のドライブにポータブル版を新しく展開しました。モデルフォルダだけ extra_model_paths.yaml で共有しています。

🔴 効くのはVRAMより、システムRAMのほうです

「8GBで動いた」と聞いたとき、まず疑うべきはここだと思います。

19.5GBのモデルが8GBのカードに載るわけがありません。載っていないから動いているのです。ComfyUIが必要な部分だけVRAMに出し入れして、残りはシステムRAMに置いています。

つまり実質の制約は、VRAMではなくシステムRAMです。うちは64GB積んでいます。

そして起動フラグの --disable-pinned-memory が、ここに効きます。ComfyUIは既定でシステムRAMの大半をpin（固定）します。pinされた領域はOSが動かせないので、出し入れの余地が減って苦しくなります。このフラグで止めています。

32GBでも動くという報告は見ましたが、解像度か尺のどちらかで頭打ちになるようです。8GBのカードを持っている人は、VRAMより先に自分のRAMを確認したほうがいいと思います。

罠その1は、最初から回避されていた

事前に一番警戒していたのが「cu128 だと comfy-kitchen の最適化カーネルが丸ごと無効になる」でした。既存環境のログにはこう出ていました。

Found comfy_kitchen backend cuda: {'available': True, 'disabled': True, ...}

disabled: True は、最適化が効いていない状態です。

ところがポータブル版 0.31.0 は最初から torch 2.13.0+cu130 でした。起動すると3つとも disabled: False になります。

Found triton 3.7.1. Enabling comfy-kitchen triton backend.
  eager  : disabled: False
  triton : disabled: False
  cuda   : disabled: False

torchを入れ替える作業は要りませんでした。 一番怖かった工程が消えました。

nvfp4 が Ampere で動く

テキストエンコーダに nvfp4 量子化版（14.61GB）を使っています。「nvfp4 は Ada 世代以降でしか実証されていない」という話があったので不安でしたが、起動ログの cuda バックエンドの capabilities に

dequantize_nvfp4, scaled_mm_nvfp4, quantize_nvfp4

が並んでいて、実際に生成も通りました。Ampere（RTX 30系）で問題なく動きます。

モデル構成（実サイズ 39.55GB）

• 本体／ファイル minimax_h3_fl2va_pruned_int8_convrot ／ サイズ 19.53 GB

• テキストエンコーダ／ファイル qwen3vl_32b_minimax_h3_nvfp4_awq ／ サイズ 14.61 GB

• 映像VAE／ファイル minimax_h3_video_vae_fp16 ／ サイズ 4.85 GB

• 音声VAE／ファイル minimax_h3_audio_vae_fp32 ／ サイズ 0.56 GB

ダウンロードは4本で 7.3分（約95MB/s）でした。

起動フラグ

--enable-triton-backend --disable-pinned-memory --preview-method none --port 8188

• --enable-triton-backend … 既定オフ。付けないと triton が使われない

• --disable-pinned-memory … ComfyUI はシステムRAMの大半を既定でpinする

• --preview-method none … 生成中プレビューはVRAMを食う。8GBでは切る

🔴 8GBで15秒が通るようになった話

ここが今回いちばんの収穫です。

最初にぶつかった壁

尺を伸ばすとVRAMが足りなくなります。実測はこうでした。

• 124／尺 5.17秒 ／ VRAM 6,304 MiB

• 243／尺 10.12秒 ／ VRAM 7,286 MiB（上限8,192に対して残り906）

119フレーム増えるごとに約1.0GB増える計算です。15秒（362フレーム）だと 8.3GBほどになって上限を超える、というのがこの時点の見立てでした。

そして私はこう説明していました。

これは間違っていました。

原因はVAEのデコードだった

2026年8月9日、ComfyUIに PR #15446 がマージされました。Kijai氏によるもので、説明にこう書いてあります。

VAEのデコードを17フレームずつのストリーミングに変えた、という内容です。

当てて測り直した

ComfyUI 0.31.0 はgitのチェックアウトなので、この2ファイルだけ当てられます。

cd <ComfyUIのディレクトリ>
git branch backup-v0.31.0
curl -sL https://github.com/Comfy-Org/ComfyUI/commit/2a68ce33b4c9ea6ee4283e618a74560cefb32694.patch -o p.patch
git apply --check p.patch && git apply p.patch

変更は comfy/ldm/minimax/vae.py（+59/-45）と comfy/sd.py（+9/-0）だけです。0.32.0以降には最初から入るはずなので、そのときは不要になります。

結果です。

• 124／尺 5.17秒 ／ VRAM 6,304 MiB

• 243／尺 10.12秒 ／ VRAM 7,286 MiB ／ 増え方 +982（パッチ前）

• 362／尺 15.08秒 ／ VRAM 7,677 MiB ／ 増え方 +391（パッチ後）

増え方が2.5分の1になりました。 上限8,192 MiB に対して残り515 MiB で完走しています。

8GBで15秒。 音声つきです。

⚠️ ただし時間は伸びます。 243→362フレームで 605.7秒 → 2113.2秒（3.5倍）。フレーム数は1.49倍なのに時間は3.5倍です。Attentionの計算量がトークン数の2乗で効くので、尺を伸ばすと急激に高くつきます。

実測値

すべて 832×480（0.40MP）・24fps・音声あり・i2v・同じ入力画像・同じプロンプト・同じシード。1本ずつ単独で回して測っています（複数を並行させると順番待ちが混ざって無意味になります）。

10秒（243フレーム）での比較

• turbo（lightx2v）／ステップ 8 ／ サンプラー er_sde ／ 時間 605.7秒（10分06秒）

• turbo（Tutu）／ステップ 8 ／ サンプラー euler ／ 時間 725.8秒（12分06秒）

• 素／ステップ 20 ／ サンプラー res_multistep ／ 時間 1491.8秒（24分52秒）

• 素／ステップ 25 ／ サンプラー res_multistep ／ 時間 1677.0秒（27分57秒）

• turbo（lightx2v）・15秒／ステップ 8 ／ サンプラー er_sde ／ 時間 2113.2秒（35分14秒）

turbo 8ステップは2回測って 605.7秒と610.7秒。ぶれは0.8%でした。

5秒（124フレーム）での比較

• 素／ステップ 25 ／ コールド 625.8秒 ／ ウォーム 595.7秒

• turbo（lightx2v）／ステップ 6 ／ コールド 310.5秒 ／ ウォーム 185.5秒

📌 ステップ数を増やしても、時間はあまり増えない

20ステップ→25ステップは、ステップ数が1.25倍なのに時間は1.12倍でした。

8GBでモデルを出し入れしているぶんの固定費が大きいからだと思います。つまり 素で回すなら、20ではなく25にしても損が小さい。

サンプラーを変えるだけで、動きの表現が変わった

これは完全に想定外でした。

turbo版と素の版を比べていて「turboのほうが動きの表現が良い」という結果が出たのですが、よく見たらサンプラーも一緒に変えていました。

素の版    sampler = res_multistep
turbo版   sampler = er_sde        ← ここも違う

ステップ数とLoRAだけの差ではなかったわけです。そこで、素の20ステップのまま、サンプラーだけ er_sde に変えて回してみました。

• res_multistep + simple／時間 1491.8秒 ／ 動きの表現 基準

• er_sde + simple／時間 1451.8秒 ／ 動きの表現 ✅ 良くなった

時間はほぼ同じ（2.7%差）。サンプラーを変えるコストはゼロです。

推測ですが、er_sde は確率的なサンプラーで各ステップにノイズを注入します。res_multistep は決定的に近いので、ステップを重ねるほど予測の平均に寄って、動きが平坦になるのかもしれません。ここは確かめていません。

いまは既定を er_sde にしています。 素で回すときも、turboのときも。

turbo LoRA は「どこかを必ず削る」

高速化のためのturbo LoRAを、独立した3系統試しました。同じ画像・同じプロンプト・同じシードで比べています。

• QrusherZA（前回・RTX 4090で検証）／線・画質 🔴 荒れる

• lightx2v（Kijai変換）／線・画質 題材による（後述） ／ 動き 🔴 ぎこちない（歩行シーン）

• Tutu AudioVideo 20→8／線・画質 🔴 低下

3つ目の Tutu は「H3のネイティブなステレオ音声・対話・同期した効果音を保持する」と明言しているLoRAです。画質は明らかに落ちました。

なお音については、今回は判定していません。比較に使ったプロンプトがBGMを排除した効果音だけのもので、鳴っている音が少なすぎて比べられる素材ではありませんでした。 これは別途測り直します。

特に「動き」が削られるのは見落としやすい

前回の検証では、線と音しか見ていませんでした。今回、人物が歩くシーンで足の運びが明らかにぎこちなくなるのに気づきました。

ステップ蒸留は、線や音だけでなく動きの滑らかさも削っています。「20ステップとあまり遜色ない」という報告も見かけますが、動きの少ない題材だった可能性があります。人物が歩く・走るような画では避けたほうがよさそうです。

🔴 ところが、題材によっては turbo のほうが良かった

ここまで書いておいて、ひっくり返す話をします。

星空に立つ二人の少女という別の絵で、素20 / 素25 / turbo(lightx2v) / turbo(Tutu) の4本を同じ条件で並べたところ、turboの2本のほうが映像が良いという判定になりました。（素20と素25の差は、ほとんど無し）

なぜか。ステップ蒸留は階調を削って、輪郭を硬くします。その代償が損害になるかどうかは、題材で決まります。

• 水面を歩く少女／絵柄 水のcaustics・光の滲み・歩行 ／ turboの評価 🔴 線が荒れ、歩き方がぎこちない

• 星空の二人／絵柄 黒＋発光する白＋星。フラットで高コントラスト ／ turboの評価 ✅ 素より良い

水面の絵では「荒れ」に見えたものが、セル画調のフラットな絵では「締まり」になる。そして素の25ステップは階調を細かく作るので、フラットな絵には余計なテクスチャを乗せているのかもしれません。

「ステップが多いほど良い」ではありませんでした。

⚠️ 1つの題材で1回判定しただけなので、まだ仮説です。別のフラットな絵でも同じ傾向が出るか、確かめる必要があります。

SageAttention の計測は失敗しました

SageAttention 2.2.0 を入れて測ったところ、ウォームで 766.4秒。素の 595.7秒より 28.7%遅いという数字が出ました。

ですが、この比較は信用できません。

SageAttentionを入れると同時に、プロンプトも短いもの（1カット）から長いもの（3カット）に差し替えてしまったからです。変数が2つ動いているので、遅くなった原因を切り分けられません。

長いプロンプトはテキストエンコーダ（14.6GB・8GBには載らないのでオフロードされる）の負荷を上げますし、25ステップ×124フレームの cross-attention にも効きます。どちらの可能性もあります。

条件を揃えて測り直すまで、この数字は使いません。

同じ理由で、途中で複数の生成を並行させて出た数字（1733.8秒など）も全部捨てました。ComfyUIの順番待ちが混ざっていて、生成そのものの時間ではないからです。

📌 その後、もっと根本的な原因が分かりました。そもそもSageAttentionは動いていませんでした。詳しくは後述の「SageAttention が測れなかった本当の理由」に書きます。

他の環境との比較

RTX 3060 12GB（@TlanoAI さんの実測）

• 画素数／3060 12GB 640×640 = 0.41MP ／ 3060 Ti 8GB（今回） 832×480 = 0.40MP

• ステップ／3060 12GB 25 ／ 3060 Ti 8GB（今回） 25

• SageAttention／3060 12GB あり ／ 3060 Ti 8GB（今回） なし

• EasyCache／3060 12GB あり ／ 3060 Ti 8GB（今回） なし

• 時間（ウォーム）／3060 12GB 5分19秒 ／ 3060 Ti 8GB（今回） 9分56秒

1.87倍の差がありますが、これをVRAMの差と読むのは誤りです。向こうは最適化2つ入り、こちらは素の状態。条件が違います。

借りたGPUとの比較

• RunPod RTX 4090／解像度 1344×768 ／ 尺 10秒 ／ ステップ 20 ／ 時間 475.8秒 ／ コスト 約8円

• RunPod RTX PRO 6000／解像度 1344×768 ／ 尺 10秒 ／ ステップ 20 ／ 時間 256.2秒 ／ コスト 約25円

• 手元の 3060 Ti／解像度 832×480 ／ 尺 10秒 ／ ステップ 20 ／ 時間 1491.8秒 ／ コスト 電気代のみ

解像度が違うので、そのまま並べられる数字ではありません。借りた側は 1.03MP、手元は 0.40MP。画素数で2.6倍の差があります。

使い分けが見えてきた

一日回してみて、こういう分担に落ち着きました。

ローカル（無料・480p）  →  構成を決める
                            カット割り・演出・プロンプトを詰める
        ↓
RunPod（8円・1344×768）  →  決まったものを高解像度で本番生成

プロンプトを詰める作業が一番回数を要します。 そこを無料でやれるのが大きい。turboを使えば10秒が10分で出るので、1日に何十本も試せます。

画質が要るところだけ借りる。 これなら、借りるGPUの時間も最小で済みます。

おまけ：同じ環境で画像生成もできる

同じComfyUIに Krea 2（Krea.aiの12Bオープンウェイト画像モデル）も入れました。

• 本体／krea2_turbo_nvfp4 7.15 GB

• テキストエンコーダ／qwen3vl_4b_fp8_scaled 4.88 GB

• VAE／Qwen Image と同じもの（流用可）

• 生成時間／1024×1024 が36秒（モデルが載ったまま）

8ステップ・cfg 1で回ります。ライセンスは独自のものですが、年商100万ドル未満なら商用可、生成物の権利は自分のもの、画像を出すだけならクレジット表記も不要でした。

動画のH3と画像のKrea 2が同じ8GBのカードに同居しています。

ここから先は、記事を書いたあとに分かったこと

以下は、上の内容を書き終えたあとに測ったものです。「まだわかっていない」と書いていた項目が、いくつか埋まりました。

続きを繋げば、8GBのまま尺を伸ばせる

ここまでは「1本15秒が上限」という前提で書いてきましたが、その上限は外せました。実際に繋いだのは20秒までです。それ以上は時間の問題だけなので、後述します。

ComfyUI-MiniMaxH3-Contex-Loop というカスタムノードを入れます。前のクリップの末尾22フレームを、次の生成に文脈として渡すという仕組みです。参照画像として渡すのではなく、latent空間でフレームを固定してから続きを描かせるので、繋ぎ目のズレが小さくなります。

実際に測りました。

• 構成／Ref2VA w4a8（10.96GB）/ 832×480 / 243フレーム / 文脈22フレーム

• turbo／lightx2v 8ステップ・er_sde

• ピークVRAM／7,392 MiB / 8,192

• 時間／781.0秒（13分01秒）

15秒の単発（7,677 MiB）より、VRAMは低く収まりました。

10秒13分なので、1分にするなら6本で約78分という計算になります。⚠️ ここは計算で、まだ1分は作っていません。 実際に繋いで確認したのは20秒までです。ただ、時間をかければ届く範囲ではあります。夜のうちに回せば朝には上がる、という規模です。

この記事のいちばん上に貼った20秒が、それです。前半10秒と後半10秒を繋いでいて、10.1秒のところに繋ぎ目があります。

繋ぎ目は「見えない」とまでは言えません

最初に静止画を並べたときは、人物の位置も背景も一致していて感心しました。ところが動かして見ると、繋ぎ目で画がわずかに飛びます。

位相相関で、2枚をいちばん重ねられる平行移動量を測りました。

• 歩くだけの続き／縦のズレ -12 px ／ 横のズレ 0 px

• 振り向きを入れた続き／縦のズレ +7 px ／ 横のズレ 0 px

480pxの高さに対して12pxは2.5%。横は0で、縦だけ動いています。カメラの高さか画角がわずかに変わっていて、人物が上下にずれて見えます。

止め絵の比較では気づきませんでした。動画は動かして確認しないと分かりません。

音は消して繋ぐ

繋ぐときは -an で音を落として書き出します。 BGMは後から自分で入れるのが普通なので、ここで悩む必要はありません。

セリフや歌が要る場合は、ref_audios にクリップごとに音声ファイルを渡せます。渡した音に合わせて生成されるので、自分で用意した音がそのまま基準になります。歌詞つきのMVを作っている方は、曲のmp3を15秒ごとに分割して渡すという手順を取っていました。（⚠️ リップシンクの精度は未検証です）

繋いでも直らないもの が2つあります

① 繋ぐたびに、わずかに暗くなります。

境界の平均RGBを測ると、こうでした。

• 夜の水辺（暗い画）／境界での差（R / G / B） -8.3 / -11.0 / -9.1

• 真昼の海辺（明るい画）／境界での差（R / G / B） -13.7 / -12.6 / -10.7

• 真昼の海辺（音の文脈つき）／境界での差（R / G / B） -16.1 / -12.3 / -9.1

明るさも題材も違う3本で、どれも同じように暗くなりました。素材の性質ではなく、この繋ぎ方そのものの性質だと思われます。音の文脈を渡しても直りません（別の問題です）。

1本なら気づきませんが、繋ぐほど累積するはずです。6本繋いで1分にするなら、最後は目に見えて暗くなる可能性があります。長尺をやるなら、監視するか、繋ぐたびに明るさを戻す工程が要ります。

② 末尾フレームに写っていない角度は、繋がりません。

これも踏みました。1本目の最後は「後ろ姿で歩いていく」画で終わっています。そこに「振り返ってこちらを見る」続きを書いたら、振り返った瞬間に別人の顔になりました。

考えてみれば当然で、渡した22フレームは全部後ろ姿です。モデルは彼女の顔を一度も見ていません。だから作り直します。

そこで、ref_images に人物の参照画像を1枚渡して焼き直しました。渡したのは、そもそもの入力に使った絵（彼女の横顔が写っているもの）です。

これが効きました。 こめかみの編み込みが戻り、顔立ちも元の絵に近づきました。参照なしの版とは、明らかに別物です。

⚠️ ただし副作用があります。 参照画像に写っていた小物（ドリンク）まで一緒に戻ってきました。歩き去ったあとの場面なのに、また手に持っています。参照画像は「顔だけ」を渡したつもりでも、写っているもの全部が影響します。

きちんとやるなら、正面・3/4・側面・背面を同じ姿勢・同じ照明で並べたキャラクターシートを用意するのが本筋でしょう。余計なものが写っていないぶん、狙ったところだけが効きます。

いずれにせよ、「動きの続き」は繋げても、「見たことのない角度」は参照が要る。ここは押さえておく必要があります。

まとめると

1分の動画はローカルで作れます。 ただし条件が3つあります。

1. 音は消して繋ぐ（BGMは後入れ。セリフが要るなら音声ファイルを渡す）

2. 人物が出るなら、参照画像を一緒に渡す（小物が写っていると持ち込まれるので注意）

3. 繋ぐほど暗くなるので、色を監視する

4. 繋ぎ目で縦に10px前後飛ぶ。 カットを割る場所に繋ぎ目を置けば隠せます

音は、諦めました

H3は映像と音声を同時に生成します。波の音も、ストローで飲む音も、絵に合ったタイミングで鳴ります。そこは素直に良い。

問題は、頼んでいないBGMが勝手に乗ってくることでした。ピアノだったり、木琴のような音だったり。

プロンプトの書き方（否定形・肯定形・音楽関連語の全削除）、後処理でのダッキング、合成音への差し替え、音源分離——6通り試して、全部だめでした。

📌 Seedance 2.5 では消せた書き方も、H3では効きませんでした。先日Seedanceで検証したときは、「no BGM」と書いても音楽が乗ってきたので、melody / harmony / chords といった「音楽の中身」のほうを禁止したら消えました。同じ考え方をH3に持ち込んでも、BGMは止まりません。プロンプトの効き方はモデルごとに違うということだと思います。

結論は「音声トラックごと削除して書き出し、音は別で作る」です。

ffmpeg -i in.mp4 -c:v copy -an out.mp4

BGMは後から自分で入れるのが普通なので、実務ではこれで困りません。セリフや歌が要る場合は、クリップごとに音声ファイルを渡せます。

⚠️ 未検証の手が1つ残っています。 生成時に音声をリファレンスとして渡してしまえば、モデルが音楽を作る余地がありません。そちらはまだ試していません。

SageAttention が測れなかった本当の理由

先に「計測に失敗した」と書きましたが、そもそも動いていませんでした。

KJNodes を入れて SageAttention を有効にすると、生成の途中でこう落ちます。

tcc.exe ... cuda_utils.c ... returned non-zero exit status 1

triton が実行時に小さなCコードをコンパイルしようとして、失敗しています。中を見たら理由は単純でした。

• sageattention 2.2.0／状態 ✅ 入っている

• triton-windows 3.7.1／状態 ✅ 入っている

• python_embeded/Include（Python.h 等）／状態 ❌ 中身が無い

• python_embeded/libs/python313.lib／状態 ❌ フォルダごと無い

ComfyUIポータブル版の埋め込みPythonには、Cコンパイル用のヘッダとライブラリが同梱されていません。直すには CPython 3.13 から Include と libs を持ってきて置く必要があります。

Windowsのポータブル版で SageAttention が動かない方は、ここを疑ってみてください。

なお、他の方の実測（RTX 3070 Ti 8GB・ref2va・0.6MP・20ステップ）では素 45分13秒 → SageAttention＋メモリ効率パッチ 29分57秒（-34%）という報告があります。効けば大きいので、いずれ取りに行きます。

turbo LoRA をもう1つ試した

joyfox/MiniMax-H3-Turbo という4ステップのturbo LoRAが出ていたので、同じ画・同じシードで比べました。

• 時間／lightx2v 8ステップ 730.9秒 ／ joyfox 4ステップ 460.8秒（-37%）

• プロンプト追従／lightx2v 8ステップ 指定した「水面の反射だけ」のカットに灯籠が写り込んだ ／ joyfox 4ステップ 指示どおりになった

• 細部／lightx2v 8ステップ 紙の繊維と折り目が見える ／ joyfox 4ステップ 均一なグラデーションになった

• 音／lightx2v 8ステップ BGMが乗る ／ joyfox 4ステップ 広帯域のノイズになった

音が別の壊れ方をしたのが収穫でした。 8ステップでは構造のある音が出るのに、4ステップでは音の構造ごと崩れます。音声にはステップ数が要るということだと思います。

このLoRAには学習時のメタデータが埋まっていて、audio_loss_weight: 0.25 とありました。音声も蒸留の対象に入れているという主張は本当のようですが、それでも4ステップでは足りませんでした。

720pは「重くて通らない」のではなく、寸法で弾かれていた

「1280×720が通るか」を最後まで測っていなかったので、やってみました。

結果はエラー。ただし OOMではありませんでした。

shape '[1, 24, 1, 1, 22, 2, 40, 2]' is invalid for input of size 86400
RuntimeError

数字を追うと分かります。1280÷16=80、720÷16=45。エラーに出ている 22 と 40 は2倍して 44 と 80。幅80は割り切れるのに、高さ45は奇数なので22で切り捨てられ、辻褄が合わなくなっています。

つまり 解像度は32の倍数でないと受け付けません。

• 832×480（この記事で常用）／32で割ると 26 × 15 ／ ✅

• 1344×768（借りたGPUでの本番）／32で割ると 42 × 24 ／ ✅

• 1280×720／32で割ると 40 × 22.5 ／ ❌

これまで使ってきた解像度がたまたま全部32の倍数だったので、気づいていませんでした。「720pでエラーが出た→VRAM不足だ」と誤解して諦めるのは、もったいないです。

1280×704 なら通りました

32の倍数（32×22）に直して回し直したところ、通りました。

• 解像度／1280×704（0.90MP）

• 尺／5秒（124フレーム）・turbo 8ステップ

• ピークVRAM／7,655 MiB / 8,192（残り537MiB）

• 時間／861.0秒（14分21秒）

先に「5秒で約7.7GBという見込み」と書きましたが、実測7.65GB。ほぼ当たりでした。

8GBのカードで0.9MP、つまり720p相当まで出せます。480p（0.40MP）の2.25倍の画素で、時間も約2.3倍。素直にスケールしています。

同じプロンプト・同じシードで、解像度だけ変えたものです。左（480p）では水滴が溶けて輪郭を失い、氷の面も潰れています。右（704p）は水滴が一粒ずつ立ち、氷の角と反射が残っています。

コップの寄りのようなカットでは、この差がそのまま伝わります。逆に言えば、引きの画や動きの確認だけなら480pで足ります。

（動きのあるものは、この記事のいちばん上に埋め込んだポストの2本目で見られます）

ただし5秒で14分なので、試し撃ちには向きません。構成を詰めるのは480p、決まったカットだけ704pで焼く、という使い分けになりそうです。借りるほどではないけれど画質が要る、という場面の選択肢が1つ増えました。

EasyCache は、turbo と併用しても効きませんでした

「EasyCache を足したときの短縮率」も測っていなかったので、やりました。

条件は完全に同一（832×480 / 243フレーム / 8ステップ / er_sde / turbo lightx2v）で、EasyCache の有無だけが変数です。

• EasyCache なし／時間 740.8秒

• EasyCache あり／時間 735.9秒

差は -0.7%。誤差です。

絵のほうも、同じ時刻のフレームを並べて見比べましたが、区別がつきませんでした。得も損もしていないという結果です。

理由はおそらく単純で、8ステップしかないからだと思います。EasyCacheは「前のステップと似た計算を省く」仕組みなので、省ける回数がそもそも無い。既定のしきい値（reuse_threshold 0.2）に一度も引っかからなかったのではないかと見ています。

turbo を使わず20〜25ステップで回すときには効く可能性があります。ただ、そもそもturboを使う理由が速度なので、「turboを外してEasyCacheを足す」構成に意味があるかは疑問です。

turboで回すなら、EasyCacheは付けても付けなくても同じ、というのが今日の結論です。

この記事の数字は「2026年8月11日時点」のものです

ここまで書いた構成は、今日いちばん良かった組み合わせにすぎません。

H3はオープンウェイトで公開（8月3日）されてから、まだ8日です。その8日、というより直近の2日だけで、こういうものが出てきました。

• テキストエンコーダを32Bから4Bに置き換える射影ノード（TE段が15.7GB→4.5GB）

• 本体のGGUF量子化版（19.5GB→11.6GB）

• 前のクリップを文脈として渡して繋ぐノード（この記事の追記で使ったもの）

• turbo LoRAが2種類（片方は音声も蒸留対象に入れたと明記）

• 映像を32×32で回して音声だけ取り出すTTSワークフロー

• 音声処理に特化した拡張（映像4ステップ／音声は多ステップ、など）

• ComfyUI本体にint8 attentionを入れるPR（20系・30系で速くなる）

• 静止画データセットでLoRAを学習するPR

1日に何本も増えています。 昨日「これがベスト」と思った構成が、今日には古くなっている。実際この記事も、書いてから公開するまでの間に4回書き直しています。

なので、ここに書いた組み合わせは固定の答えではなく、今日の観測記録として読んでください。私自身、もっと良い組み合わせを探し続けます。分かったことはまた書きます。

まだわかっていないこと

• SageAttention の正味の効果（埋め込みPythonにヘッダを入れてから測る）

• 音声をリファレンスとして渡したらどうなるか（BGM問題への最後の手）

• 繋いだときの色ズレが、何本目から目に見えるか

次に書く予定のもの

続きを繋いで1分にする工程は、まだ書き切れていません。今日わかっただけでも、こういう論点があります。

• 繋ぎ目で画が飛ぶのを、カット割りでどう隠すか

• 繋ぐたびに暗くなる色を、どこで戻すか

• 振り向いたら別人にならないための、キャラクターシートの渡し方

• 音をどの工程で入れるか

このあたりは別の記事にまとめる予定です。

*計測はすべて 2026-08-09〜10 に同一マシン・同一入力画像で実施。コールドとウォームを混ぜないよう、比較には必ずウォーム同士を使っています。並行実行で順番待ちが混ざった数字は、すべて破棄しました。*