MiniMax H3 Turbo LoRA（step600 EMA）とは｜ComfyUIの置き場所・推奨ステップ数と速さをRTX 5080/5060 Tiで実測

本記事の実測値は、測った回ごとに条件が違う。倍率・画質・VRAM の各表は2026年8月9日から10日にかけて、RTX 5080とRTX 5060 Ti (いずれもVRAM 16GB) で、pruned形式向けのComfyUI変換版を euler + beta で測ったもの。「焼き込み済みの単一ファイル」の節は2026年9月5日に RTX 5060 Ti で、res_multistep + simple・別の起動オプション・別のベース重みのファイルを測った独立の5条件で、前半の表と秒数を比べることはできない。12GBのRTX 4070 SUPERの節は、その5条件と同じサンプラーとスケジューラ (res_multistep + simple) で2026年9月9日に測った別の回になる。いずれも専用カスタムノードを使う経路とは設定も前提も異なる。2026年9月25日にPyTorchのcu130版で測り直した回は、すぐ下の「追記・訂正」にまとめた。

先に結論: 速くなる倍率は尺と解像度で変わる

MiniMax H3向けのTurbo LoRAについて、配布元は通常およそ20ステップかかるところを最短4ステップで生成でき、サンプリングがおよそ5倍速くなると説明している。この5倍はサンプリング部分に限った説明であり、生成1本にかかる総時間についての数字ではない。

総時間を実際に測ると、倍率は条件で大きく動いた。1344×768・192フレーム(8.00秒)では4.18倍、同じ解像度でも56フレーム(2.33秒)なら3.34倍、864×480・56フレームでは2.49倍にとどまる。いずれもLoRAなし20ステップを基準にLoRAあり4ステップと比べた値で、比較相手をLoRAあり8ステップに変えると864×480では1.47倍まで下がる。

倍率だけを単独で受け取っても判断材料にならない。尺・解像度・比較相手のステップ数の3点に加えて、PyTorchの版も添えて初めて、手元の用途に当てはめられる数字になる（ここに挙げた倍率はcu128版での値で、LoRAの上乗せはPyTorchの版で大きく動く）。

この記事は、同じ機材と同じワークフローで MiniMax H3 本体を測ったMiniMax H3をVRAM 16GBで動かす｜ComfyUIでの導入手順とRTX 5080・5060 Ti実測の続きにあたる。前回扱ったのは、VRAM 16GB のカードで H3 を動かすまでの手順と、そのとき制約になるメモリ側の前提だった。今回はそこに Turbo LoRA を1つ足し、ステップ数だけを変えて同じ測定系で回している。比較の基準にしている「LoRAなし 20ステップ」も、過去の値を引き写さず今回あらためて測り直した。

Turbo LoRAとは何か、誰が作ったものか

MiniMax-H3 Turbo LoRAは、larryvrhがHugging Face上で公開したコミュニティ製のLoRAで、MiniMax本体からのリリースではない。ライセンスはApache 2.0。MiniMaxが2026年8月3日にMiniMax H3のオープンソース化を発表してから、数日のうちに登場している。

配布元はこのLoRAをプレビュー段階と位置づけており、音声と激しい動きの下での挙動を改善中だと明記している。2026年9月11日時点の案内では、ほとんどの用途で v4 の step600 EMA 版を使うこと、4ステップを推奨最小・4〜8ステップを実用域とし、6〜8ステップのほうが目に見えて良いこと、8ステップを超えると頭打ちで過度にシャープな副作用が出ることがあると書かれている。例外は4ステップで動きの激しい映像を作る場合で、そこだけは旧 v1 系（~850）のほうが無難な選択になりうる、とされている。チェックポイントの更新間隔も短く、測定に使ったファイルがそのまま残り続ける前提では読めない。

同じ「4ステップ化」を狙った別系統のLoRAが、lightx2v (ModelTC) からも公開されている。ファイル名はminimax_h3_fl2v_turbo_4step_v0.1.safetensorsで、ライセンスは同じくApache 2.0。ただしこちらはLightX2V側のMiniMax H3推論実装で使うことを想定した配布で、ComfyUIが扱うpruned形式で動くかは確認できていない。この記事では未検証のため、以降で扱うのはlarryvrhの系統だけになる。なお現在は lightx2v 側から ComfyUI 向けの新しい版も公開されており、drbaph もそれを取り込んだ変換版を配布しているが、この記事では測っていない。

drbaph版なら1ファイル追加で済む

larryvrh 系の Turbo LoRA を使う導入経路は2つで、推奨値はそれぞれ別になっている。混ぜると設定が噛み合わない (このほかに、別系統の LoRA を重みへ焼き込んだ単一ファイルを使う配布物もある。後述する)。

1つは、larryvrhが配布する専用のカスタムノードを使う経路。MiniMax-H3のフル形式 (bf16 / int8_convrot) とpruned形式 (pruned_int8 / pruned_fp8) の両方を扱え、pruned形式のベースを自動判別して実行時にtime-conditioningを入れ直す仕組みが入っている。この経路の推奨は、4ステップを推奨の下限として実用域は4〜8ステップ、strengthは1.0のまま、スケジューラはsimpleのまま使う、という内容になっている。8ステップを超えると効果が頭打ちになり、過度にシャープな副作用が出ることがあるとも書かれている。

もう1つは、drbaphが配布するpruned形式向けのComfyUI変換版を、ComfyUI標準のLoRAローダーで読む経路。カスタムノードを追加せずファイル1つで済む。こちらの推奨設定はminimax_h3_turbo_v4_step600_ema_pruned_comfyui.safetensorsを6〜8ステップ・eulerサンプラー・betaスケジューラ・strength 1.0で使うこと。6は速度と品質の折衷、8は品質・動きの一貫性・音声の安定を優先するときの推奨として案内されている。配布ページはワークフローの記載を6〜8ステップとする一方、サンプリングの指針と既存のpruned形式向けワークフローの開始点としては8ステップを挙げており、ページ内で書き方が揃っていない。スケジューラがsimpleではなくbetaになっている点が、先の経路とのはっきりした違いになる。今回測ったdrbaph版は、larryvrh版を第三者がpruned/curve-form向けに互換変換したもので、ライセンスはApache 2.0。

置き場所はどちらの経路でもComfyUIのmodels/lorasで、ワークフロー上はモデルを読み込むノードとサンプラーの間にLoRAを適用する段を挟む。ComfyUI側の導入手順そのものや、VRAM・システムRAMの前提はMiniMax H3をVRAM 16GBで動かす｜ComfyUIでの導入手順とRTX 5080・5060 Ti実測で扱っているため、ここでは繰り返さない。

実測: 8秒のクリップは22分51秒から5分28秒になった

本命の条件から見ていく。RTX 5080 16GB、ComfyUI 0.31.1、モデルはminimax_h3_fl2va_pruned_fp8_scaled、テキストエンコーダはqwen3vl_32b_minimax_h3_nvfp4_awq、eulerサンプラー+betaスケジューラ、LoRA strength 1.0、1344×768・192フレーム(8.00秒)。

1本あたり最短で5分28秒、最長で22分51秒かかるため、この表は各条件1回のみの測定になっている。3回計測した短いクリップに比べ、値の揺れを潰せていない点は割り引いて読む必要がある。

この記事の前半 (2026年8月9日から10日) の測定で記録しているのは次のとおり。ComfyUI 0.31.1 (Python 3.12.10・PyTorch 2.9.1+cu128・comfy-kitchen 0.2.28) を、--reserve-vram 1.5 --bf16-unet --bf16-text-enc の起動オプションと、環境変数 PYTORCH_CUDA_ALLOC_CONF (garbage_collection_threshold:0.8・max_split_size_mb:128) で動かした。所要は ComfyUI の実行イベント (execution_start から execution_success まで) で取っていて、キュー待ちは含まない。ComfyUI は入力が変わらないノードを前の実行の結果で済ませるので、テキストエンコードが毎回の所要に入っているとは限らない (当時のログを確かめられた回では、前の回とプロンプトも解像度も同じときはテキストエンコーダを読み込む行が出ていなかった)。seed は 12345・12346・12347 (1回だけの条件は 12345、RTX 5060 Ti の 1344×768 は 12345 と 12346) で、LoRA あり・なしで同じ seed を使っている。条件の間で ComfyUI の再起動やモデルの解放はしておらず、56フレームの組では最初に捨て回を1本入れた。192フレームは各1回で捨て回を入れておらず、組の最初の1本 (8ステップ) にだけテキストエンコードが入った可能性がある。1344×768 の LoRAなしのうち、56フレームの 8・6・4ステップと、192フレームの 8・4ステップは、翌日に同じ起動オプションで ComfyUI を立て直して追加で測っている。この日も捨て回を入れたのは56フレームの組の最初で、192フレームの組には入れていない。GPU ドライバの版と、手元のモデルファイルの digest は記録していない。

56フレームの短いクリップでは倍率が下がった

今回測った3条件では、同じLoRAでも尺か解像度を下げた条件ほど倍率が目に見えて縮んだ。次は56フレーム(2.33秒)での測定で、いずれもseedを変えて3回実行した中央値。

864×480・56フレーム

1344×768・56フレーム

いずれも同一機・同一プロンプトでの測定で、プロンプトや素材を変えると値は動く。実行ごとに1回あたり数秒の揺れが出たため、範囲を併記している。

同じステップ数で比べるとLoRAありのほうが遅い

配布元が説明している高速化は、必要なサンプリングのステップ数を減らすことによるものだ。ステップ数を揃えてLoRAの有無だけを変えると、所要時間はむしろ増える。864×480・56フレーム、seedを変えて3回実行した中央値。

今回の総時間でも、同じステップ数に揃えるとLoRAありのほうが遅く、1ステップあたりが軽くなる結果は出なかった。今回は3つの設定すべてでLoRAあり・なしの両方を測っているため、設定を変えたときに上乗せがどう動くかまで実測として並べられる。

時間だけの比較。画質は同一とは限らず、今回の定性評価では4ステップでLoRAありのほうが明確に細部が残った。56フレームは各3回の中央値、192フレームは各1回。

4ステップと8ステップの間の傾きで見ると、どこが増えているか

総時間をステップ数に対して直線で結んだときの傾きを、4ステップと8ステップの2点から求めた値で並べる。傾きと差は、丸める前の値が残っている条件ではその値から求めている。そのため、上の表の小数1桁の値から計算し直したり、この表のLoRAありからLoRAなしを引いたりすると、末尾の桁がずれることがある (864×480・56フレームは丸める前が 5.035 と 2.9125 で、差は 2.1225)。

秒/ステップの差そのものは2.12→2.72→5.14秒/ステップと増えている。それでも上乗せの割合が+73%→+28%→+8%と薄まるのは、基準にしたLoRAなしの傾き (2.91→9.60→65.83秒/ステップ) の伸びのほうが大きいため。

なお、これはサンプラー単体の計測ではなく総時間から求めた値で、2点から引いた直線であるため途中のステップ数での挙動までは保証しない。LoRAありで傾きが大きくなる理由も、ここでは機構として断定しない。実測として言えるのは、4ステップと8ステップの間の総時間の傾きが、LoRAありのほうで大きかったというところまで。

画質を問わず時間だけで選ぶなら、LoRAなしでステップを落とすほうが速かった

時間短縮だけが目的なら、LoRAを入れずにステップ数を落とすほうが速い。1344×768・192フレーム(8.00秒)でLoRAなしのままステップ数を落とした場合を、LoRAあり4ステップと並べる (各1回。LoRAなしの8ステップと4ステップは、ComfyUI を立て直した8月10日に測った値)。

LoRAなし4ステップの306.2秒は、LoRAあり4ステップの327.6秒より速い。出力品質を問わず最短時間だけを優先するなら、このLoRAを入れる理由は残らない。導入の判断は画質側で決まる。参考までに、864×480での見え方ではLoRAなし4ステップは背景まで溶ける水準だった。

画質: 差がはっきり出たのは4ステップ

864×480・56フレームでseed 12345を固定し、同じプロンプトで生成した動画の中ほどのフレームを比べた定性評価。

6ステップと8ステップはLoRAなしでも細部が残る。LoRAの有無で見え方がはっきり違ったのは4ステップだけで、このLoRAの取り分は「4ステップまで削っても細部が残ること」に集約される。LoRAあり6ステップは8ステップとの差が見つけにくく、速度との折衷点になる。ただし1本のプロンプト・1つのシードでの見え方であり、被写体や構図が変われば印象は変わる。動画の音声は評価していない。

VRAMとComfyUIプロセスRAMのピークに、LoRAの有無で目立つ差は出なかった

全条件を通した最大値。RTX 5080 16GB。VRAMはnvidia-smiで読んだGPU全体の使用量 (MiB) で、読み取りの間隔は2秒以上。RAMはpsutilで読んだComfyUIプロセス単体の使用量 (psutil の rss。Windowsではワーキングセットにあたる) を、十進のGBで表している。

VRAMはComfyUIの--reserve-vram 1.5を付けた状態での値で、RAMはシステム全体ではなくプロセス単体。この表から言えるのは、今回の条件でピークの差が実質見えなかったところまでで、あらゆる構成で増えないという意味ではない。ディスク側には591.6MiBのファイルが加わる。記録したピークの粒度では、VRAMより先に ComfyUI プロセスの RAM が上限になるという前回の見立てを覆す差は見えなかった。小さな差まで判定できる測定ではない。必要なメモリ量そのものについては、MiniMax H3をVRAM 16GBで動かす｜ComfyUIでの導入手順とRTX 5080・5060 Ti実測で扱っている。

経路が違えば前提も変わる。larryvrh側の説明では、実行時にLoRAを当てる既定の動作ではピークVRAMが少し増えるとされている。low_vramを有効にすると重み側へ統合してピークVRAMは下がるが、量子化やpruned形式のベースでは結果が甘くなるとも書かれている。今回の測定は標準ローダー経路のため、この選択肢自体は使っていない。

同じLoRAでも2枚のカードで取り分が違った

RTX 5060 Ti 16GB (OCuLink接続) でも同じワークフローを回した。起動オプションはRTX 5080側と同一。864×480・56フレームはseedを変えて3回実行した中央値、1344×768は2回実行した値の平均 (2回の値は LoRAなし 20ステップが416.1秒と417.2秒、LoRAあり 8ステップが231.4秒と232.8秒、4ステップが126.0秒と128.0秒)。括弧内は同じカードの「LoRAなし 20ステップ」を1.00倍としたときの基準比。

同じステップ数どうしで2枚の所要時間を割ると、開きの出方がはっきりする。864×480・56フレーム、各3回の中央値どうしの比。

LoRAなしではステップ数を20から4まで振っても1.89〜1.99倍でほぼ動かない。一方でLoRAありでは2.14〜2.36倍に開く。ステップ数による変化では説明できず、今回の各3回の中央値では、LoRAを当てたときにカード間の比が大きくなった。

同じステップ数でLoRAの有無だけを変えたときの増分をカード別に並べても、同じ向きが出る。864×480・56フレーム。

今回の2枚では、RTX 5060 Ti側の上乗せ率がRTX 5080より大きかった。原因は特定していない。2枚は接続形態も演算性能も違い、演算性能・メモリ帯域・接続形態を分離した測定にはなっていないため、言えるのは、今回の中央値でLoRAありのほうがカード間の比が大きかった、というところまでで、ほかのカードでも同じになるとは言えない。

焼き込み済みの単一ファイルを速さで選ぶかは、PyTorchの版で変わる

上乗せの話に戻る。この上乗せが、実行時に LoRA を当てているぶんのコストなのかどうかは、ここまでの測定では分けられていない。もしそうなら、最初から重みへ混ぜてしまえば付かないはずになる。その発想の配布物が実際にある。MATLOWAI/minimax-h3-fused-turbo-int8-convrot は、turbo 系の LoRA を重みへ焼き込んだうえで量子化まで済ませた単一ファイルで、カスタムノードなしに ComfyUI 標準の UNETLoader で読める。RTX 5060 Ti 16GB で回してみた。

864×480・56フレーム、1本ごとに ComfyUI を立て直して、seed を変えながら各セル3本を狙った。途中で3本落ちたので測り直し、試行34本・完走31本 (INT8 ConvRot・実行時適用の8ステップだけ完走が4本)。下の値は完走したぶんの中央値になる。実行時に当てた LoRA は、ここまでと同じ drbaph 変換版 minimax_h3_turbo_v4_step600_ema_pruned_comfyui で、5つとも UNETLoader に読ませるファイルを差し替えただけになる。

上乗せの割合も測定系ごとに動く。この5条件では、fp8_scaled に実行時で当てたときの増分は 8ステップで +43.8%、4ステップで +37.8% になり、euler + beta で測った +74%・+59% とは一致しない。割合そのものが設定で動くので、こちらも測定系ごとの値になる。PyTorchの版でも大きく動き、cu130版（ComfyUI 0.37.1）で同じ5条件を測り直すと、fp8_scaledへの上乗せは8ステップで+7.0%、4ステップで+6.5%まで小さくなった。

cu128版のPyTorchで測ったこの5条件から読み取れるのは、手に入るファイルの中では焼き込み版がいちばん速いわけではないということだった。焼き込み版は fp8_scaled に LoRA を当てた構成より 3.6秒 (4ステップ)・6.3秒 (8ステップ) 遅く、3本ずつの範囲も重なっていない。いちばん速いのは LoRA を当てていない fp8_scaled だった。出力品質を問わず最短時間だけを見ると LoRA を入れる理由が残らない、という結論はこの測定系でも同じ向きに出ている。

ただし、この並びはPyTorchの版で入れ替わる。cu130版のPyTorch（ComfyUI 0.37.1）で同じ5条件を測り直すと、4ステップ / 8ステップの所要は fp8_scaled 素が41.7秒 / 63.0秒、同・実行時適用が44.4秒 / 67.4秒、int8_convrot 素が34.7秒 / 49.0秒、同・実行時適用が37.0秒 / 52.9秒、焼き込み版が34.7秒 / 48.9秒で、焼き込み版は int8_convrot 素と並んでいちばん速かった。実行時に LoRA を当てた構成のうち速いほうの int8_convrot・実行時適用より2.3秒（4ステップ）・3.9秒（8ステップ）、fp8_scaled・実行時適用より9.7秒・18.4秒短い。LoRA なしの int8_convrot とは並ぶので、速さの面で焼き込み版を選ぶ理由があるのは、Turbo 系の LoRA を当てた状態で使いたい場合に限られる（RTX 5060 Ti・864×480・56フレーム・res_multistep + simple で測った範囲）。ただし焼き込み版はベース重みも混ぜた LoRA も別物なので、画質は別に確かめる必要がある。

焼き込み版と fl2va_pruned_int8_convrot は所要が近い値になったが (両ステップ数とも3本ずつの範囲が重なる)、この2つはベース重みが違うので、一致から焼き込みの効果を読むことはできない。実行時に当てるぶんのコストがいくらなのかは、この5条件からは分離できない。

なお fl2va_pruned_int8_convrot に LoRA を当てた条件だけは3本の振れが大きく (4ステップで 79.1〜95.3秒、8ステップで 129.0〜157.8秒)、中央値どうしの差を細かく読める精度ではない。この2条件を除けば、3本の幅は 0.4秒から3.2秒に収まっている。落ちた3本はいずれも実行時に当てた条件だったが、本数が少なく原因 (SamplerCustomAdvanced の RuntimeError: Fault failed: 2) も特定していないため、落ちやすさの差として読める材料ではない。

配布元の live-LoRA 比較で確認された差はメモリの量だった

焼き込み済み経路と live-LoRA 経路の差は、配布元が条件を揃えて測っている。同じ Ref-Delta ベースの INT8 ConvRot に、同じ公開 LoRA 群 (lightx2v の Turbo 8-step v1.0 と Mystic v2.0) を実行時に積んだ構成と、焼き込み版とを、同一 seed・8ステップで比べたものになる。結果は壁時計が双方とも 103秒で、速度差は付いていない。確認された利点はメモリのほうで、ピーク 68.9GB が 47.8GB へ、常駐 64GB が 42GB へ下がったと報告されている。理由として、ComfyUI が LoRA を当てた重みについて元の値の控えを持つため、200 層を当てると控えだけでモデル1つぶんになる、と説明している。

この比較はベースも LoRA も揃っているので、焼き込みの効果として読める。ただし 96GB のカードでの値で、解像度もフレーム数も5条件とは別になる。

そのメモリの利得は、16GB のカードでは見えなかった。完走した31本の GPU 全体ピークは 14,914MiB から 15,908MiB の範囲で、16,311MiB のカードに対してどれも上限近くに張り付いた。条件ごとの最大値は fp8_scaled 素 15,588MiB / 同・実行時適用 15,780MiB / int8_convrot 素 15,588MiB / 同・実行時適用 15,908MiB / 焼き込み 15,620MiB で、焼き込み側が一貫して低いという並びにはならなかった。16GB ではモデルが丸ごと載らずシステムRAM 側から流し込みながら回るので、控えのぶんのコストがホスト側のどこに出たのかは GPU のピークからは特定できない。前半の別測定では ComfyUI プロセスの RSS ピークに LoRA の有無による差が見えなかったが、ベース・LoRA・GPU・測定系が違うため、配布元が説明する live-LoRA 時の控えのコストの所在を示す測定にはなっていない。配布元が挙げている 96GB カードでの数字を、そのまま 16GB の節約として読むことはできない。

もう1点、焼き込み版に入っているのは lightx2v の 8-step v1.0 と Mystic v2.0 で、この記事がここまで測ってきた drbaph 変換版とは別物になる。「同じ LoRA を焼き込んだらどうなるか」の比較にはなっていない。drbaph 変換版を焼き込んだ場合に何秒になるかも測っていない。

速さ以外を理由に選ぶ余地はある。ファイル1つで済んでローダーの設定が減ることと、配布元が測っている控えのぶんのメモリが要らなくなることの2つで、どちらもこの記事が測った所要時間には出てこない。速さの面の理由は、cu128版では出てこず、cu130版ではRTX 5060 Tiのこの5条件で、LoRAを当てた構成どうしを比べたときに出た。ただし中身の LoRA もベース重みも別なので、画質は drbaph 変換版で見た見え方をそのまま当てにできない。乗り換えを試すなら、所要だけでなく出力を見て決めることになる。

12GBのRTX 4070 SUPERでも完走した — 設定を揃えて比べられたのはLoRAを当てない2条件だけ

直前の5条件と同じ設定 (res_multistep + simple) のまま、2026年9月9日にカードだけVRAM 12GBのRTX 4070 SUPERへ差し替えて回した。12GBで完走したのはLoRAを当てない2条件 (fl2va_pruned_fp8_scaled と fl2va_pruned_int8_convrot) で、864×480・56フレーム・4ステップが40.6秒、生成中のVRAMピークは条件ごとの中央値で 11,268〜11,500MiB だった。

この記事の本題である「実行時にLoRAを当てたときの上乗せ」は、12GBでは測れていない。5条件を回そうとした回は1本も書き出さずに終わっており、どの条件のどこで止まったのかもエラーも控えていないので、12GBでLoRAを当てた構成や焼き込み版が動くかどうかは、この測定では分からない。上乗せの倍率も焼き込み版の所要も16GBでの値で、そのまま12GBへ持ち込むことはできない。12GBでTurbo LoRAを試すなら、まずLoRAなしの2条件が手元で完走することを確かめ、そのうえで1本回して実測するところからになる。

16GBのカードを使っている場合、この節から持ち帰るのは数字ではなく読み取り精度になる。同条件を別の日に測り直したときの再現幅は2秒前後 (約4%) で、それより小さい差は読まないほうがいい (詳細は節末)。

以下の秒数は手元の目安として読む値で、2枚の比較のほうは同じ負荷の下で同日に取っている。この日の測定はどちらのカードも、別のGPU (RTX 5080) を別の作業が13〜14GB使っている状態で取った。カードもリンクも別だが、CPU・システムRAM・PCIe・電源・冷却は共有しているので、GPU単体の性能を分離した比較ではない。

括弧内の「1ステップ」は、ComfyUIの進捗表示が出す1イテレーションあたりの秒数 (s/it) をそのまま読んだ値になる。この記事の前半で使っている「4ステップと8ステップの2点を直線で結んだ傾き」とは出どころが違うので、前半の秒/ステップと直接は比べられない。

12GBの余裕は654MiB

12本の実測でピークが最大 11,628MiB まで伸びており、12,282MiBのカードに対して最悪時の残りは654MiB。このカードに画面表示も繋いでいれば、そのぶんが削られる。この値はnvidia-smiで読んだGPU全体の使用量で、記事前半のVRAMピークと同じ種類の値だが、カードも設定も違うので並べて差を取ることはできない。

2枚でピークが4,000MiB以上違うが、これを必要VRAM量の差とは読めない。少なくとも12GBのカードの利用可能VRAM内で完走しており、LoRAを当てない同じ2条件で16GBのカードが記録した最大15,588MiBを、固定的な必要VRAM量とはみなせない。ただし差が出た原因までは特定していない。空いている量に応じてGPU上に残す量を変えるComfyUIの挙動が説明としては有力だが、起動オプションを控えていないので、今回の差をその機構の結果だと確かめたわけではない。

観測できたのはここまでだ。16GBのカードでは15,588MiBまで使い、12GBのカードでは11,500MiBに収めて、記録上確認できる範囲では同じワークフロー設定・同じseed・同じ尺で書き出している。同じseedでも書き出したMP4の映像データ部のハッシュは2枚で別になる (ハッシュの一致・不一致は、映像の見た目が同じかどうかの判定には使えない)。

速さはVRAM容量では予測できなかった

別のGPUが同時に動いていたこの日の測定（9月25日に測り直すと、5060 Ti側の値はPyTorch cu128版のときに再現した）では、4条件とも中央値は4070 SUPERのほうが速く、5060 Ti側は 1.11〜1.22倍の時間がかかっている。ただしfp8_scaled・4ステップだけは両カードの3本の範囲が重なる (4070 SUPERが 40.4〜45.0秒、5060 Tiが 44.9〜50.1秒)。どちらのカードも観測順の1本目だけが遅かったが、GPUクロックもキャッシュもモデルのロード時間もログに出していないので、理由は特定していない。その1本ずつを除くと 40.4・40.6秒 対 44.95・44.95秒 に割れる。残り3条件は3本の範囲が分離している。INT8の2条件は、cu130版（ComfyUI 0.37.1）の5060 Tiでは4ステップ34.7秒・8ステップ49.0秒まで縮むので、cu130版で2枚の並びがどうなるかは分からない（4070 SUPERはcu130版で測っていない）。

この差を1つのスペックで説明することはできない。NVIDIAの公表値では、4070 SUPERが7,168 CUDAコア・568 AI TOPS・192bit GDDR6X、5060 Tiが4,608 CUDAコア・759 AI TOPS・128bit GDDR7で、CUDAコア数と AI TOPS は逆を向いている。世代もテンソルコアもメモリの種類も違うので、どれがどれだけ寄与したかはこの測定では分けられない。ここから言えるのは、VRAM容量ではこのワークロードの速さを予測できなかった、という点までになる。

所要の差 (1.11〜1.22倍) が1ステップ単価の差 (4.14秒 対 5.95秒 = 1.44倍) より小さいのは、どちらのカードにもほぼ同じ固定費が乗るためだ。サンプリングを除いた固定費は、どちらのカードでもおおむね21〜25秒だった (サンプリング時間が秒単位でしか記録されていないため、この引き算には1秒前後の丸めが乗る。0.1秒の差は読めない)。ステップ数が増えるほど単価の差が表に出るので、4ステップで1.11倍、8ステップで1.22倍と開く。

なおこの比較は、すでに手元にある2枚がどう振る舞ったかの記録で、これから買うカードの選定基準ではない。4070 SUPER は新品で選べる世代ではなく、12GB側ではLoRAを当てた構成が完走していない。

FP8とINT8はどちらで始めるか

この節の測定（9月9日）では、量子化の違いは2枚とも同じ向きで出ている。1ステップの単価 (= 1ステップあたりの秒数) はINT8がFP8の2.03倍 (4070 SUPER)・1.84〜1.85倍 (5060 Ti) で、どちらのカードでもINT8のほうが高かった。ただしcu130版のPyTorch（ComfyUI 0.37.1）でRTX 5060 Tiを測り直すと、1ステップの単価はFP8が5.33秒、INT8が3.58秒で、INT8のほうが約0.67倍と速くなり、向きが逆になった。同じComfyUI 0.37.1でPyTorchだけをcu128版に戻すとFP8 5.89秒・INT8 10.91秒（1.85倍）で、この節の値とほぼ同じになる。4070 SUPERはcu130版では測っていない。

容量側で有利かどうかも、この測定では分からない。生成中のピークはむしろ4条件ともINT8のほうが同じか高い (4070 SUPERで FP8 11,268 / 11,300MiB に対し INT8 11,468 / 11,500MiB)。ただしこのピークは前述のとおり必要量ではないので、容量の得失はこの数字からは判定できない。

なおFP8側は4070 SUPERで4・8・20ステップの3点を取っており、1ステップの単価は4.14〜4.15秒とほぼ動かなかった。INT8は4ステップと8ステップの2点しか取っていないので、言えるのは測った2点ではどちらも8.42秒だったことだけになる。

この12GB測定の条件と、記録していないこと

2枚で共通にしたのは ComfyUI 0.31.1・864×480・56フレーム・res_multistep + simple・各セル3本・同じseed列。加えて、1本ごとにComfyUIを立て直し、同じPCIeスロットに差し替えている。どちらのカードにも画面表示は繋いでいない (実行直前の他プロセスの占有は4070 SUPERで162MiB、5060 Tiで114MiB)。seedは3本とも 880000・880001・880002 で2枚とも共通。

所要は壁時計ではなく、ComfyUIの実行イベント (execution_start から execution_success まで) で取っている。各回でモデルのロード要求とGPU常駐量 (4070 SUPERで10,468MiB) も記録していて、GPU上でモデルを実行していることは確認できる。

一方で、モデルのdigest、GPUドライバ、Python、PyTorch / CUDA の版は記録していない（9月25日に測り直すと、5060 Ti側の値はPyTorch cu128版のときに再現した）。--reserve-vramなどの起動オプションも測定の記録に残しておらず、2枚で同一だったことは示せない。測定に使ったのは2026年8月8日付のComfyUI 0.31.1で、2026年9月11日の確認時点では v0.35.0 (2026年9月9日) が出ている。そのリリースには「Remove now unecessary minimax memory workaround」などメモリまわりの変更が含まれるので、現行版では違う数字になりうる。

この節の数値は2026年9月9日の測定で、上の5条件の表 (2026年9月5日) とは別の回になる。同じ設定でも回を跨ぐと値は動く。5060 Tiのfp8_scaled・4ステップは9月5日が46.8秒、9月9日のカード差し替え前が47.0秒、差し替え後が45.0秒で、同条件の再現幅が2秒前後 (約4%) ある。上の表はこのうち差し替え後の組を使っており、差し替え前の組を使うと5060 Tiはさらに遅く出る (= 差が小さく出るほうを採っている)。カード間の差は表の中央値どうしで4.4〜19.1秒あり、この再現幅より大きいが、2秒に満たない差は読めないので、5条件の表との引き算はしない。

2枚のカードの取り分がどこまで散らばるかは、このLoRAだけでは決まらない。モデルと条件をまたいだ21組の比較は ローカル動画生成のハード要件ガイド にある。

この記事が測っていないこと

• PyTorch cu130版で測り直したのは、RTX 5060 Tiでの「焼き込み済みの単一ファイル」の節の5条件（res_multistep + simple・864×480・56フレーム）だけ。前半のeuler + betaの表（RTX 5080・RTX 5060 Ti）はcu128版での値で、RTX 4070 SUPERはcu130版では測っていない
• lightx2v版のLoRAは未検証。larryvrh系統との速度・画質の比較もしていない
• larryvrhの専用カスタムノードを使う経路 (フル形式ベース) は測っていない。記事前半の Turbo LoRA の実測値は標準ローダーと drbaph の変換版によるもの
• 配布元のリポジトリには、測定に使ったv4系より新しい実験版のファイル (experimental_v5_step_600.bin) も置かれているが、中身の性能は確かめていないため対象外
• 音声は聴いて確かめていない。配布元がプレビュー段階として挙げている改善中の項目にも音声が含まれる
• 1344×768の6ステップは、RTX 5060 Ti側のみ未計測
• 画質はseed 12345・1本のプロンプトで、動画の中ほどのフレームを比べた見え方に限る
• 焼き込みの効果そのもの。焼き込み済み単一ファイルはベース重みまで違うため、この記事の5条件では量子化・LoRA 系統・適用方法と分離できない
• 焼き込み済み単一ファイルの画質。Mystic v2.0 が 0.7 で混ざっているので出力そのものが別物になり、所要時間と VRAM しか比べていない
• 配布元が推奨している SLA 疎アテンションを使う構成と、reference-to-video や 2 パスの経路。いずれも別のノードパックが要るため測っていない
• drbaph 変換版の LoRA を焼き込んだ場合。焼き込み済みファイルに入っているのは別系統の LoRA になる
• 16GB で LoRA の控えを持つぶんのコストがホスト側にどう出るか。GPU のピークと ComfyUI プロセスの RSS ピークしか記録しておらず、システムRAM への流し込み量は測っていない

導入前に確認したい点

LoRA自体はApache 2.0だが、動かす相手はMiniMax H3の重みで、そちらにはMiniMax H3 Community License Agreementが重ねて適用される。MiniMaxは2026年8月3日にMiniMax H3のオープンソース化を発表しており、公開された重みにこのライセンスが適用される。

このライセンスは適用地域から欧州連合・英国・韓国・米国を除外しており、適用地域の外でMiniMax H3 Worksやその出力・結果を使用・複製・改変・配布・表示することを認めていない。日本はこの除外地域に含まれていない。ただしこの制限は出力・結果にも掛かる書き方になっている。日本で生成したものでも、除外地域から見られる場所に置いた場合にどう扱われるかまでは条文から読み切れない。公開範囲を絞れない媒体で商用に使うなら、ここはMiniMaxに確認しておきたい。

また、MiniMax H3またはMiniMax H3 Worksを使う商用の製品・サービスは、そのUIに「MiniMax H3」を表示する必要がある。加えて、あなたの商用の製品・サービスが年間2000万米ドルを超える収益を生む場合は、MiniMaxから別途書面での許諾を得る必要がある。表示義務のほうは条文が「MiniMax H3 または MiniMax H3 Works を使う商用の製品・サービス」と限定している。一方の収益条件にはその限定が付いておらず、条文は「あなたの商用の製品・サービス」の年間収益を基準としている。事業全体の売上を指すのか H3 を使う製品・サービス単体の売上を指すのかは本文だけでは読み切れないため、規模の大きい商用利用では MiniMax に確認する必要がある。

ライセンス本文に付属するAcceptable Use Policyには、もう1点ある。H3で作った情報や画像・コード・投稿・記事を公開の場に出すとき、それが機械生成であることを明確かつ目立つ形で開示しないまま出すことを禁じている。こちらは商用かどうかを問わない。ライセンス本文は重みの配布ページから読める。

よくある質問

まず何ステップから試すのが無難か

標準ローダーとdrbaphの変換版で始めるなら、推奨域は6〜8ステップ。配布ページは6を速度と品質の折衷、8を品質重視の推奨としている。ワークフローの記載は6〜8ステップ、開始点の案内は8ステップで、ページ内で書き方が揃っていない。ただし8ステップはLoRAなしでも細部が残る領域なので、そこだけを回してもLoRAによる差は判別しにくい。導入の可否を決めたいなら、4ステップをLoRAあり・なしの両方で1本ずつ出して見比べるのが早い。

短いクリップしか作らないが、入れる価値はあるか

PyTorch cu128版で測った範囲では、時間短縮を目当てにするなら取り分は小さい。864×480・56フレームでの倍率は最大でも2.49倍で、もともとの待ち時間自体が短いため、縮められる絶対量も限られる。短尺で価値が出るとすれば、同じ待ち時間の中でステップを削っても細部が残る側になる。cu130版ではLoRAの上乗せそのものが小さくなることを別の5条件で確かめているが、この倍率は測り直していない。

RTX 5060 Tiクラスのカードでも取り分はあるか

ある。PyTorch cu128版で測った値で、RTX 5060 Tiでも864×480・56フレームのLoRAあり4ステップで2.20倍、1344×768・56フレームでは3.28倍まで縮んだ。ただし同じステップ数で比べたときの上乗せ率は、cu128版で測った2枚ではRTX 5080より大きかった。原因は分離できていないため、他のカードへの一般化はできない。cu130版ではこの2枚の比較を測り直していない。

推奨設定が2種類あるのはどちらに従えばよいか

使う経路で決まる。ここでの2種類は larryvrh 系の Turbo LoRA を当てる場合の話で、焼き込み済み単一ファイルはさらに別の推奨値 (res_multistep / simple) を持つ。larryvrhの専用カスタムノードを入れるならスケジューラはsimple、strengthは1.0のまま、実用域は4〜8ステップ。ComfyUI標準のLoRAローダーでdrbaphの変換版を読むなら6〜8ステップ・eulerサンプラー・betaスケジューラ。値だけを片方から持ってきて組み合わせる使い方は想定されていない。

生成した動画を公開するときに必要なことは

Acceptable Use Policyが求めているのは、機械生成であることを明確かつ目立つ形で開示することで、これは商用かどうかを問わない。UIへの「MiniMax H3」表示義務について、ライセンス本文はH3を使う商用の製品・サービスに課している。完成した動画については、MiniMaxの担当者がHugging Faceのライセンス質問スレッドで、日本の個人がローカルで生成した動画を収益化したYouTubeで使う場合、別途のライセンスは要らないが、動画の冒頭か末尾でMiniMax-H3に触れる必要があると答えている (2026年8月13日)。別の質問への回答では、開示にはMiniMax H3の名前を入れる必要があり、エンドクレジットでの開示で足りるとしている (2026年8月6日)。いずれも掲示板での回答で、ライセンス本文の改定ではない。また、ライセンスは出力の使用・配布・表示も適用地域の中に限っているので、除外地域から見られる場所に出す場合は、上の「導入前に確認したい点」も合わせて確かめておきたい。年間2000万米ドルの条件のほうは条文上の対象範囲がそこまで明確ではないため、該当しうる規模の商用利用ではMiniMaxへの確認が要る。私的な投稿として出す場合と、事業として提供する場合とで確認すべき項目が変わる。

同じMiniMaxの音楽生成モデルを同じ16GB環境で測った記録はMiniMax Music 3をVRAM 16GBで動かすにある。こちらはPyTorch cu128版で測ったときは、ステップ数ではなく自己回帰の段が所要時間を決めていた（cu130版ではその段が約10分の1に縮む）。

参考資料

• MiniMax-H3 Turbo LoRA (larryvrh)
• MiniMax-H3 Turbo LoRA の ComfyUI 向け変換版 (drbaph)
• 別系統の Turbo LoRA (lightx2v)
• MiniMax H3 Community License Agreement
• ComfyUI-MiniMax-H3-Turbo (カスタムノード)
• MiniMax-H3 Fused Turbo (INT8 ConvRot) — 焼き込み済み単一ファイル (MATLOWAI)
• MiniMax H3 のライセンス質問スレッド (Hugging Face)
• GeForce RTX 4070 ファミリーの仕様 (NVIDIA)
• GeForce RTX 5060 ファミリーの仕様 (NVIDIA)