MiniMax H3をVRAM 16GBで動かす｜ComfyUIでの導入手順とRTX 5080・5060 Ti実測

MiniMaxが公開したMiniMax H3は、テキスト・画像・動画・音声をひとつの文脈として読み、映像と音声を同時に生成する動画モデルである。2026年8月3日に重みが公開された。ただしH3-Omni-Transformerは33Bパラメータあり、公式リポジトリのBF16フル版は拡散モデルの重みだけで66.28GB。VRAM 16GBのカードとは二桁違う数字が並ぶ。

ところが実際に動かすと、VRAM 16GBのカード1枚で動く。RTX 5080では864×480・2.33秒の生成が約66秒、1344×768で8秒の動画を作っても約21分30秒だった。

一方で、公開時に測ったComfyUI 0.31.1で効いてきた制約はVRAMではなかった。重みはRAM側に保持されたまま必要な部分だけがVRAMへ運ばれる形になり、ComfyUIプロセスのメモリ使用量は約44 GiBまで増えた。VRAMが足りていても、ComfyUI 0.31.1で測った本記事の構成ではRAM 32GBでは足りない。本記事は、導入手順から最初の1本を出すまでの流れと、VRAM 16GBのカード2枚——RTX 5080とRTX 5060 Ti——で測った生成時間・メモリ消費をまとめたものである。

VRAM 16GB・メモリ64GB以上のスペックはここから比較できる。

MiniMax H3は何を出すモデルか

ここで扱う構造は、後述する「VRAM 16GBで動く理由」に直接つながる。パラメータの内訳と、どこがモダリティ固有かを先に押さえておく。

MiniMax H3の中核はH3-Omni-Transformerと呼ばれる33Bパラメータの単一ストリーム型トランスフォーマである。注意機構やフィードフォワード層にモダリティ別の構造を持たず、入出力層とAdaLN分岐だけがモダリティ固有のパラメータを持つ。位置表現には時間・縦・横の3次元に対応するMM-RoPE（多モーダルの回転位置埋め込み）を用いる。

映像側のVAEはf16t4d24と表記され、空間方向を16分の1、時間方向を4分の1に圧縮し、潜在チャンネル数は24である。トランスフォーマに入る時点での空間方向の実効圧縮率は32分の1になる。音声側のVAEはステレオの各チャンネルを独立に処理し、32kHzの音声を40Hzの潜在トークン列へ圧縮する。テキスト側はQwen3-VL-32Bの学習済み重みをそのまま使い、その第50層の隠れ状態をトランスフォーマへ渡す構成になっている。

出力仕様は24fps、長さ4〜15秒、既定の短辺は768px、音声は32kHzステレオである。会話音声は11言語に対応し、日本語も含まれる。映像と音声が別々のモデルの出力を後から合成したものではなく、同じ系列の中で一緒に生成される点がこのモデルの特徴になる。

公開の経緯は2段階だった。モデルとしての発表は2026年7月31日で、この時点では提供元のサービス経由でのみ使える形であり、重みは「近日中に公開する」とされていた。実際に重みが公開されたのは8月3日である。

重み公開の対象は2種類ある。ひとつはFL2VAで、画像を渡さないテキストのみの生成、最初または最後のフレームを1枚渡す生成、最初と最後の2枚を渡す生成のいずれにも対応する。もうひとつはRef2VAで、画像・動画・音声を参照として受け取る。2K出力を担うH3-Regenerate-2Kモジュールと前処理系のH3-Context-IRは公開対象外で、API経由でのみ利用できる。本記事が扱うのはFL2VAで、生成はすべて画像入力なし（テキストのみ）で実行している。

ローカルで動かす必要スペック（VRAM・システムRAM・ストレージ）

導入に入る前に、必要な条件を整理しておく。

この中で見落とされやすいのがRAMである。VRAMの要件だけを見て導入すると、モデルの読み込み段階で行き詰まる。理由は後述する。ComfyUIを動かす一般的な要件はComfyUI推奨スペックで整理している。

VRAMが16GB未満・24GB以上のカードについて言えること・言えないこと

測ったのは16GBのカード2枚だけである。それ以外の容量について、実測から言えることと言えないことを先に分けておく。

実測していないカードをどう見当づけるか

本記事の実測では、2枚の生成時間の差はPCIeの8倍差とは一致せず、メモリ帯域と演算性能の比と同じ桁に収まった（数値の対応は後述の「PCIeの帯域差は生成時間の差として現れなかった」を参照）。ただし対照測定をしていないため、どの要因が効いているかまでは分離できていない。未実測のカードを見当づける手がかりとしては、この2つの指標がRTX 5080とRTX 5060 Tiのどこに位置するかを見ることになる。

RTX 5070 Tiは16GB GDDR7・256-bit・CUDAコア8,960である（NVIDIA公式のスペック表）。メモリバス幅はRTX 5080と同じ256-bitだが、実効帯域はメモリクロックにも左右されるため、バス幅だけで帯域は決まらない。見当づけるなら、各カードの公称のメモリ帯域と演算性能を、後述の節に載せた本記事の2枚の値と並べて、どのあたりに位置するかを見ることになる。生成時間そのものは実測していないため本記事からは言えず、比例計算で秒数を割り出すこともしていない。

導入手順

1. ComfyUIをv0.30.0以降にする

MiniMax H3のノードはComfyUI v0.30.0（2026年8月3日公開）で追加された。それ以前のバージョンでは該当ノードが存在せず、ワークフローを読み込んでも赤いエラー表示になる。ポータブル版なら同梱の更新用バッチ、git管理なら該当タグへの切り替えとrequirements.txtの再適用で上げられる。なお本記事の計測は、追記・訂正の再測定（ComfyUI 0.37.1。864×480のFP8・INT8比較とメモリ、3つの解像度・56フレームでのGPU比較）を除きComfyUI 0.31.1で行っている。0.32.0以降でH3の高解像度・長尺の生成が大幅に遅くなるという報告が2026年8月16日に上がっている。報告で原因とされたのは、v0.32.0でメモリ使用のピークを抑えるために入った変更で、この変更はv0.35.0で「不要になった」として取り除かれた。ただし報告自体は2026年9月27日時点でも閉じられておらず、本記事もこの件が解消したかは確かめていない。生成時間を比べるときはComfyUI側のバージョンも合わせて確認したい。

更新後、ノード検索で「MiniMaxH3」と入力してMiniMaxH3ImageToVideoが出てくれば対応済みである。出てこなければバージョンが上がっていない。

2. モデルファイルを配置する

MiniMax公式リポジトリが配布するのはBF16の完全版で、量子化版はそちらには含まれない。ComfyUI向けに再パッケージされた配布物には、推論用に軽量化したものと精度違いの組み合わせで複数のファイルが用意されている。VRAM 16GB環境で選ぶのは次の4本である。

ファイル名にあるprunedは、推論時に読み込む必要がない重みを外した版という意味である。一般に言う枝刈り——重要度の低い重みを削って精度と引き換えに小さくする処理——とは中身が違い、こちらは外しても推論結果に影響しない部分を除いている。詳しくは後述する。

拡散モデルには推論用のFP8版とINT8版があり、どちらも約21GBでサイズはほぼ変わらない。この2つは速度が明確に違うため、後述の実測で比較している。テキストエンコーダはNVFP4のAWQ量子化版が15.69GBで、INT8版の27.14GB、BF16版の51.51GBに対して大きく小さい。

3. ワークフローを組む

ノード構成はComfyUI標準のテンプレートにも含まれているが、中身は次の流れになる。動画モデルのノード構成そのものに慣れていない場合は、LTX 1をComfyUIで動かすノード構成の全体像が同種の構成を扱っている。

• 読み込み：UNETLoaderで拡散モデル、CLIPLoaderでテキストエンコーダ（typeはminimaxを選ぶ）、VAELoaderを2つ置いて映像VAEと音声VAEをそれぞれ読み込む
• 条件付け：MiniMaxH3ImageToVideoにテキストエンコーダと映像VAEをつなぎ、プロンプト・幅・高さ・フレーム数を指定する。このノードが条件付けと空の潜在表現の両方を出す
• サンプリング：BasicScheduler・KSamplerSelect・RandomNoise・BasicGuiderをSamplerCustomAdvancedへ集約する
• デコード：サンプラーの出力をVAEDecode（映像VAE）とVAEDecodeAudio（音声VAE）の両方へ分岐させる。同じ潜在表現から映像と音声の両方が出てくるのがこのモデルの構成上の特徴で、片方だけつなぐと音声のない動画になる
• 出力：CreateVideoで映像と音声を束ね、SaveVideoで書き出す

テキストエンコーダを読み込むCLIPLoaderのtypeを取り違えると読み込み自体は通ってしまい、生成の途中で失敗する。minimaxを選ぶ点だけ注意したい。

最初の1本を出すまで

生成時に指定する値のうち、結果を大きく左右するのは解像度・フレーム数・ステップ数の3つである。

フレーム数は飛び飛びの値になる

フレーム数は任意の値を入れられるが、公式テンプレートは指定された秒数を5＋17の倍数という並びに丸める式を持っている。24fpsなので、実際に使える長さは次のようになる。

解像度は短辺768pxが既定

公称の既定は短辺768pxで、16:9なら1344×768にあたる。軽くしたい場合は縦横を32の倍数で下げていく。本記事では608×352・864×480・1056×608・1344×768の4通りを測っている。

実際に使ったプロンプト

本記事の測定は、条件を揃えるため全条件で次の同一プロンプトを使っている。seedは、RTX 5080で解像度とフレーム数を変えた一連の測定（6本）で12345に揃えた。それ以外の測定（RTX 5060 Ti、FP8とINT8の比較、8秒の1本）は、条件ごとに別のseedで生成している。

A calico cat sits on a wooden windowsill in soft morning light, slowly turning its head toward the camera, a gentle breeze moves the lace curtain, birds chirping outside, shallow depth of field, cinematic

8秒の生成では次のプロンプトを用いた。末尾で環境音を指定しているのは、このモデルが映像と音声を同時に出すためである。ただし音声側の指定がどこまで結果を左右するかは比較していない。

Rain-soaked Tokyo backstreet at night, glowing neon signs reflected in puddles, a person holding a transparent umbrella walks slowly toward the camera, steam rising from a ramen stall on the left, shallow depth of field, anamorphic lens flares, subtle film grain, cinematic color grading. Ambient sound: steady rainfall, distant city traffic, sizzling from the stall.

ステップ数とサンプラー

本記事の測定は全条件で20ステップ、サンプラーはres_multistep、スケジューラはsimpleに固定した。ステップ数を変えた場合の画質と時間の関係は測っていない。試行の段階では少ないステップで構図を確かめ、決まってから増やす進め方もある。ステップ数を落として生成を高速化する方法そのものは、この測定のあとに登場したTurbo LoRAを使い、同じ機材・同じワークフローのまま4〜8ステップで別途測っている（記事末に案内がある）。

初回は時間がかかる

モデルをディスクから読み込む初回は、読み込み済みの状態より時間がかかる。RTX 5080の864×480では、初回は80.1／81.9／82.1秒（3回）で、読み込み後の66秒前後に対しておよそ15秒の差があった。RTX 5060 Tiの同条件は初回142.3秒・読み込み後132.9秒で、差は約9秒だった。連続して生成する場合、この差は最初の1回にしか現れない。最初の1本が遅くても、設定を誤ったわけではない。

33Bのモデルが16GBのカードで動く理由

33Bのモデルが16GBのカードで動くのは、段階の違う2つの仕組みが直列に効いているためである。ひとつは配布ファイル自体を66GBから21GBへ縮める仕組み、もうひとつはその21GBを16GBのVRAMで回す仕組みである。

前者はモデル側の構造による。33Bのうち約13BがAdaLN関連の分岐にあり、MiniMaxの説明では、AdaLNの変調出力は事前計算してキャッシュできるため、推論だけを行う用途ではこの13B分の重みを読み込む必要がない。ファイル名のprunedが指しているのはこの部分で、BF16のフル版66.28GBに対して推論用のBF16版が40.23GBに収まっているのは、およそこの差に相当する。差の26.05GBを2バイトで割ると13.0Bになり、モデルカードの記述と配布ファイルのサイズが独立に整合する。

後者は実行側の仕組みである。ComfyUIはモデル全体をVRAMへ載せきる代わりに、必要な部分を随時VRAMへ運び込む動的な割り当てを行う。実行時のログでは拡散モデルが19,983MiB、テキストエンコーダが14,956MiBとして段階的な読み込みの管理対象に置かれる。これはファイルサイズそのもので、常時VRAMへ載っている量ではない。転送は非同期の2ストリームで行われる。

同じ仕組みは画像モデルでも働き、FLUX.2 Klein 9BをVRAM 16GBで実測では量子化とオフロードの組み合わせで公称値を下回る環境に載せている。結果として、GPU全体のVRAM使用量（ベースラインを含むnvidia-smiのmemory.used）は測定した全条件で15,046〜15,718 MiBの範囲に収まった。解像度を上げても長さを伸ばしてもこの値がほとんど動かないのは、16GBという上限まで使い切って残りをRAM側に置く制御が働くためで、負荷の増加はVRAMではなく時間の側に現れる。

解像度を上げると時間が伸びる

ここから実測に入る。計測はComfyUI 0.31.1、PyTorch 2.9.1+cu128、NVIDIAドライバ610.47の環境で2026年8月9日に実施し、時間はComfyUI自身が記録する実行時間を用いている。

モデルファイルは2026年8月9日に Comfy-Org/MiniMax-H3 から取得した。同じファイル名でも配布側が中身を差し替えると値は変わるため、実測に使った5本——上の4ファイルと、速度比較に使ったINT8版の拡散モデル——は取得時のSHA-256で特定できるようにしてある（値は検証環境ページに記載）。

まず56フレーム（2.33秒）・20ステップに固定し、解像度だけを変えて測った。56フレームは公称の出力長（4〜15秒）の下限より短く、解像度の効果だけを切り出すためのベースライン条件である。実用的な長さでの所要時間は次節を参照してほしい。

0.41MP以上の3点はほぼ一直線（1MPあたり約216秒）に乗る。（2026年9月25日訂正）公開時はここで、0.21MPの値だけがこの直線より約24秒高いことから、軽い条件ほど解像度に依存しない固定的な処理の比重が効いていると書いていた。だがRTX 5080の0.21MPの46.9秒はモデルの読み込みを含む1本目の値だった。9月に同じComfyUI 0.31.1で読み込み後の値を測り直すと28.7秒で、約24秒の上振れの大半は読み込みの分だった。ただし直線を引いた3点は8月の値で、同じ0.31.1の864×480の読み込み後も9月は60.3秒と、8月の66.4秒より1割ほど速かった。このため28.7秒をこの直線に重ねて、残りの差や増え方の違いを読むことはできない。

画素数との対応で見ると、864×480から1344×768は画素数で2.49倍だが、時間は3.01倍だった。画素数に比例するわけではなく、増加をやや上回る割合で伸びる。最も重い1344×768でも200秒で、16GBのカード1枚で1MP級の動画生成が現実的な時間に収まる。VRAMの余裕がこの種の作業でどう効くかはRTX 50 SUPER（24GB）を待つべきかでも扱っている。

長さを伸ばすと時間はさらに急に伸びる

フレーム数を変えた場合、前節の非線形性はさらに強く出る。

864×480ではフレーム数が1.91倍になったとき時間は2.51倍、1344×768では3.43倍のフレーム数に対して6.46倍になった。1フレームあたりの所要時間が長い動画ほど増えるため、短いクリップの実測値から長尺の所要時間を単純に比例計算すると、実際より短く見積もることになる。1344×768の場合、56フレームの200秒から8秒動画を比例で見積もると約686秒だが、実測は1291.6秒でおよそ倍の開きがあった。

この伸び方は、映像と音声の潜在表現をひとつの系列として注意機構に通す構成と整合する。系列長が伸びると注意計算の負荷は長さの2乗で増える一方、フィードフォワード層の負荷は長さに比例するため、全体としては比例と2乗の中間の伸び方になる。解像度を上げた場合も空間方向のトークンが同じ系列に加わるため、程度の差はあれ同じ傾向が現れる。フレーム数のほうが伸び方が急なのは実測どおりだが、解像度側だけが比例で済むわけではない。なお本記事はモデル内部の計算量そのものを測ったわけではなく、確認したのは生成時間の挙動である。

ComfyUI 0.31.1では、本当の制約はVRAMではなくシステムRAMだった

VRAMへ載せきれない構成では、重みはRAM側に置いたまま必要な分だけGPUへ運ぶ形になる。ComfyUI 0.31.1での実測は、超過分だけをRAM側に置く挙動ではなく、モデルの重みをRAM側に保持したままGPUへ運ぶ挙動と整合する。そのぶん実行中のRAM使用量は大きい。ComfyUIのプロセス単体の常駐メモリを、モデル未読み込みの起動直後と生成中で比較した。

増分の約43 GiBは、読み込んだ4ファイルの合計42.47GB（約39.6 GiB）を上回る。VRAMに載った分だけRAMから消えるのではなく、モデルはRAM側に保持されたままGPUへ運ばれていることが、この数値からも読み取れる。どちらのGPUでもほぼ同じ値になったのは、保持先がシステムRAMであってGPU側の性能に依存しないためである。

この数字は環境要件として直接効いてくる。VRAMが16GBあっても、ComfyUI 0.31.1で本記事と同じ構成・設定ならシステムRAM 32GBでは足りない。OSと常駐アプリの分を差し引いた上で40GiB以上を1プロセスが確保する必要があるため、実質的には64GB以上が前提になる。ただしComfyUI 0.37.1で同じ4ファイル・同じ条件を測り直すと、プロセス単体の常駐メモリのピークは12.6〜15.9 GiBまで下がった。同じcu128版のPyTorchでも0.31.1では約44 GiB、0.37.1では約13〜16 GiBだったので、この差はPyTorchの版では説明できない。ただし0.31.1と0.37.1は起動環境（読み込むカスタムノードやGPUメモリの確保方式）も違うので、ComfyUI本体の版だけの効果とは切り分けていない。0.37.1のピークは4ファイルの合計（約39.6 GiB）を下回るので、重みの全体をプロセスのメモリに持ち続ける0.31.1の形とは違う。重みがどこに置かれているかまでは切り分けていない。0.37.1で32GBの環境が足りるかは測っていない。ローカルAI全般でのRAM消費の考え方はローカルAIにシステムRAMは何GB必要かで扱っている。

なお、システム全体のメモリ使用量を見るだけではこの値を切り分けられない。ブラウザや他の常駐プロセスの増減が混ざるため、モデルが使った量として読むにはプロセス単位で見る必要がある。

このプロセス単体のRAMは、本記事の測定のあとも条件を変えて記録を続けている。条件ごとの値と計測日、ComfyUIのVerは実測データベースにまとめている。

FP8とINT8はファイルサイズが同じでも速度が違う

推論用の拡散モデルにはFP8版（20.96GB）とINT8版（20.97GB）があり、容量はほぼ同じである。同じ条件で比較した。

このときの環境（ComfyUI 0.31.1・PyTorch cu128版）では、中央値で比較するとINT8はFP8のおよそ1.86倍の時間がかかった。5回とも重複しない範囲に分かれており、測定のばらつきで説明できる差ではない。

ただし、この順位はPyTorchの版で入れ替わる。ComfyUIのREADMEの手順どおりにcu130版のPyTorch（2.14.0+cu130）を入れ、ComfyUI 0.37.1で同じ条件を測り直すと、RTX 5080ではFP8が58.7秒、INT8が41.3秒（2回目以降の中央値）で、INT8のほうが速かった。RTX 5060 TiでもFP8が121.0秒、INT8が85.5秒で、向きは同じだった。同じComfyUI 0.37.1でPyTorchだけをcu128版に戻すと、INT8はRTX 5080で117.2秒、RTX 5060 Tiで232.2秒かかり、FP8（64.7秒・132.3秒）より遅い。cu128版ではComfyUIが量子化形式の計算に使うcomfy-kitchenの最適化CUDA処理を無効にするため、INT8はその処理を使わずに動いていた。この条件（864×480・56フレーム）で生成時間を比べる限り、cu130版のPyTorchではINT8版、cu128版ではFP8版が速かった。VRAM使用量とファイルサイズはどちらもほぼ同じである。

ただし比較したのは生成時間だけで、両者の出力品質は評価していない。量子化形式の違いが画質や音声に与える影響は本記事の測定範囲外である。量子化形式ごとの容量と精度の関係についてはローカルLLMの量子化フォーマットの選び方で言語モデルを対象に整理している。

PCIeの帯域差は生成時間の差として現れなかった

この節の結果は、外付けGPUを使う場合だけでなく、メインのGPUが帯域の狭いスロットに挿さっている構成にも関係する。今回の2枚は接続形態が異なり、RTX 5080はPCIe Gen5 ×16、RTX 5060 TiはOCuLink経由の外付けでPCIe Gen4 ×4である。理論帯域はおよそ63GB/sと7.9GB/sで、8倍の開きがある。

毎ステップ重みをシステムRAMから運び込む構成である以上、この帯域差がそのまま生成時間に出ると考えるのが自然に見える。だが実測はそうならなかった。

864×480と1344×768の差は2.00〜2.09倍にとどまり、PCIeの8倍差とは一致しない（2026年9月25日訂正: 608×352の1.45倍は、RTX 5080側だけモデルの読み込みを含む値を並べた見かけだった。ComfyUI 0.37.1・PyTorch cu130版で両方とも読み込み後の値を測ると、608×352が2.20倍、864×480が2.06倍、1344×768が2.22倍だった。9月に同じ0.31.1で測り直したRTX 5080の読み込み後の28.7秒を8月のRTX 5060 Tiの68.0秒と並べると約2.4倍になるが、測定日の違う値どうしの比である）。2枚のVRAM帯域の比（960GB/s対448GB/s＝約2.14倍）や演算性能の比（FP32で56.3TFLOPS対23.7TFLOPS＝約2.38倍）と同じ桁の値である。今回はリンク幅を変えた対照測定も転送量の直接計測も行っていないため、どちらが効いているかまでは分離できない。言えるのは、PCIeの8倍差がそのまま生成時間の差としては現れなかったということまでで、両カードはGPU自体も違うため、接続帯域の寄与を単独では分離できない。外付けGPUでの2枚運用についてはAI用途にGPUは2枚必要かでも別のワークロードを測っている。

（2026年9月25日訂正）公開時はここで608×352の比が小さい理由を推測していたが、比が小さく見えたのは、上のとおり読み込みの有無が違う値を並べていたためだった。

テキストエンコーダをCPUへ逃がす選択肢

ComfyUIはテキストエンコーダの配置先をCPUに指定できる。VRAMを空けたい場合の選択肢になるが、この構成では代償が大きかった。864×480・56フレームで、テキストエンコーダをGPUに置いた場合が65.5秒、CPUに置いた場合が148.6秒（いずれも1回の測定値）で、2.3倍近い差がついた。

このときのGPU全体のVRAM使用量は15,274 MiBだった。ただしこの値は他の全条件（15,046〜15,718 MiB）と同じ帯に収まっており、上限まで使い切る制御が働く以上、この指標ではテキストエンコーダを外した効果は測れない。他のアプリケーションに回せる空きが実際に増えるかどうかは本記事では確認していない。生成時間が2.3倍に伸びる一方でVRAMの余裕がどれだけ増えるかは確認できていないため、VRAM 16GBで生成自体が通っている以上、積極的に選ぶ理由は乏しい。同じGPUで他の作業を並行させたい場合に検討する程度になる。

出力を見た所見

ここまでは生成時間とメモリ消費で、いずれも数値で測れる。出力そのものの良し悪しは数値化していないが、目視と試聴での所見を条件付きで記しておく。対象は8秒・1344×768の1本と、同一プロンプト・同一seedで解像度だけを変えた4本である。定量評価ではないため、以下は測定値と同じ強度では扱えない。

フレーム間の破綻は確認できなかった

8秒の生成でも、フレーム間の大きな不連続は確認できなかった。途中で被写体が入れ替わったり、つなぎ目のように見える箇所が現れることもない。

画質はこの解像度で見る分には成立する

1344×768のまま等倍で見る限り、画質は見られる範囲にある。ただし細部の粗さはそのまま残っているため、アップスケールして大きく表示すると粗さも一緒に拡大される可能性がある。アップスケール後の見え方は確認していない。拡大表示を前提にするなら、生成の段階でより高い品位を狙う設定が必要になる。

文字は判読できる形にならなかった

ネオンの看板を含む情景を指定した8秒の生成では、看板は文字らしい形にはなるものの、読める文字列にはならなかった。プロンプト側の指定が不足していた可能性もあり、モデルの限界によるものかどうかは切り分けていない。情景全体としては指定した雰囲気に沿っており、ネガティブプロンプト等での調整余地は残る。

環境音は違和感のない範囲にとどまる

音声はプロンプトで指定した環境音のみが生成され、台詞や音楽は含まれない。雨音や遠くの交通音は映像と大きく食い違うことなく、違和感のない範囲に収まっている。一方で実写映画の音響と比べると情報量は少なく、そこまでのリアリティには届かない。音声と映像の同期精度は定量的に測っていない。

つまずきやすい点

• ノードが見つからない：ComfyUIがv0.30.0未満だとMiniMax H3のノードが存在しない。更新前のワークフローを読み込むと未定義ノードとして赤く表示される
• 音声が入らない：サンプラーの出力を映像VAEにしかつないでいない場合に起きる。同じ潜在表現をVAEDecodeAudioにも分岐させ、CreateVideoで束ねる必要がある
• 読み込み中に止まる：RAMが足りていない可能性が高い。ComfyUI 0.31.1ではこの構成がプロセス単体で約44 GiBを確保するため、32GB環境では読み込み段階で行き詰まる。0.37.1ではピークが約16 GiBまで下がったが、32GBで足りるかは確かめていない
• 最初の1本だけ遅い：モデルの読み込みが加わるためで、864×480ではRTX 5080がおよそ15秒、RTX 5060 Tiが約9秒の差だった。2本目以降は短くなる
• 他の生成処理と同時に動かした場合：VRAM・RAMとも余裕が薄いため、同じGPUで別のワークフローを並行させると割り当てが競合しうる。本記事の測定は他の生成処理を止めた状態で行っている

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

本記事が扱ったのは生成時間とメモリ消費、および指定した条件で生成が完了するかどうかである。以下は測定していない。

• 出力品質の定量評価：目視・試聴での所見は前節にまとめたが、数値指標による評価は行っていない
• 量子化形式による画質差：FP8とINT8はseedを揃えずに測ったため、出力を並べても形式による差かseedによる差かを分離できない。生成時間のみの比較である
• プロンプト追従性や音声の同期精度：定量的な評価は行っていない
• アップスケール後の見え方：等倍での確認にとどまり、拡大処理を通した結果は見ていない
• ステップ数を変えた場合の挙動：全条件で20ステップに固定している
• 画像入力を使う生成：FL2VAは最初・最後のフレームを渡す生成にも対応するが、今回はすべてテキストのみで生成している
• 2K出力：2Kを担うモジュールは重み公開の対象外で、API経由でのみ利用できる
• 参照入力を使うRef2VA：画像・動画・音声を参照として渡す構成は測定していない

また、多くの条件は1回の測定値である。同一セッション内で複数回記録したのはRTX 5080の864×480の読み込み後（FP8・INT8とも各5回）と初回読み込み（3回）。RTX 5060 TiはComfyUIを立て直して2セッション測っており、表には後のセッションの値を出している。864×480はそのセッションの2本目132.9秒で、前のセッションは132.8秒。608×352は前のセッションが73.0秒（モデルの読み込み直しを含む回）、後が68.0秒（読み込み後の値）。1344×768は後のセッションの1本だけで、前のセッションでは同じ条件がVRAMの確保に失敗して止まっている（ログはメモリ不足によるものではないと記録している）。それ以外は単発の値として扱う必要がある。

導入前に確認したい点

MiniMax H3の重みはMiniMax H3 Community License Agreementの下で配布されている。このライセンスには他のオープンウェイトモデルであまり見ない条項がある。

第I条5項で「除外地域」を欧州連合・英国・韓国・アメリカ合衆国と定義し、第I条3項で許諾範囲をそれ以外の全世界としている。日本は許諾範囲に含まれる。ただし第V条4項は、モデルおよびその出力物を許諾範囲の外で使用・複製・改変・配布・表示することを認めていない。生成した動画を全世界へ公開する形で配信する場合、この条項の扱いを確認しておく必要がある。当サイトでも、検証のために生成した動画は公開していない。

商用利用については第IV条1項で、年間収益が2000万米ドルを超える製品・サービスに用いる場合に個別の書面許諾を求めている。個人が手元で生成を試す範囲であれば、この収益要件には該当しない。加えて第IV条2項は、H3を用いた商用の製品・サービスのユーザーインターフェースに「MiniMax H3」を目立つ形で表示することを求めている。第V条3項では、出力物を他のAIモデルの改善に使うことを禁じている。ライセンスは改定されうるため、利用前に配布元の最新の条文を確認するのが前提になる。

これから機材をそろえるなら

MiniMax H3が出たことで、VRAM 16GBのカード1枚でも映像と音声が同時に出る動画生成を手元で試せるようになった。ただしComfyUI 0.31.1での実測でつまずくのはVRAMよりシステムRAMのほうで、ComfyUIプロセス単体が約44 GiBを確保した（0.37.1では約13〜16 GiBに下がった）。生成時間も1344×768の8秒でRTX 5080が約21分半かかる。これから機材を用意するなら、VRAMの数字だけでなくRAMの容量と、その待ち時間を許容できるかを一緒に見ておきたい。

VRAM 16GB・メモリ64GB以上のスペックは、ここから比較できる。GPUと価格で候補を決めてから、32GBの構成を注文時のカスタマイズで64GBへ引き上げられるかを見ると、選べる幅は広くなる。

機材をどう見るかの順番は、動画生成のワークフロー全体で共通している。VRAM・システムRAM・GPUの速さがそれぞれ何を決めるかは ローカル動画生成のハード要件ガイド にまとめた。

よくある質問

RTX 5070 Tiなど、記事で測っていない16GBのカードでも動くか

実測したのはRTX 5080とRTX 5060 Tiの2枚だけなので、他のカードでの動作は確認していない。ただしGPU全体のVRAM使用量が上限付近で頭打ちになる挙動は、必要な部分だけをVRAMへ運ぶ実行側の仕組みによるもので、特定のGPU世代に固有の現象ではない。生成時間はGPUの性能に応じて変わる。スペック上どのあたりに位置するかの見当づけは、本文の「実測していないカードをどう見当づけるか」で整理している。

VRAM 12GBや8GBのカードでも動くか

本記事では16GBのカードのみを測っており、それ未満の環境は確認していない。GPU全体のVRAM使用量（ベースラインを含むnvidia-smiのmemory.used）が全条件で15,046〜15,718 MiBに収まっていたのは、16GBという上限まで使い切る制御が働いた結果であり、より少ないVRAMではVRAMに常駐できる量が減り、RAMとの転送やオフロード処理が増えると考えられる。ただし実測していないため、動作の可否は判断できない。

システムRAMは何GB必要か

ComfyUI 0.31.1で測った本記事の構成では、ComfyUIプロセス単体で約44 GiBを確保した。OSと他のアプリケーションの分を加えると32GBでは足りず、64GB以上が実質的な前提になる。0.37.1では同じ構成のプロセス単体のピークが12.6〜15.9 GiBまで下がったが、32GBの環境で足りるかは確かめていない。

生成した動画に音声は入っているか

入っている。映像と音声が同じ生成過程で作られるため、出力されるファイルには32kHzステレオの音声トラックが含まれる。後から音声を合成する工程は不要である。ただしワークフロー側で音声VAEへの分岐をつないでいないと、映像だけの出力になる。

8秒の動画を作るのにどれくらいかかるか

1344×768・20ステップの場合、RTX 5080で1291.6秒（約21分30秒）だった。解像度を落とせば短くなるが、フレーム数の増加に対して時間は比例以上に伸びるため、短いクリップの実測値からの比例計算は当てにならない。

FP8とINT8はどちらを選ぶべきか

生成時間はPyTorchの版で逆になる。ComfyUI 0.37.1・864×480・56フレームで測ると、READMEの手順どおりのcu130版ではINT8が速かった（RTX 5080で41.3秒対58.7秒）。公開時のComfyUI 0.31.1・cu128版（RTX 5080・864×480・56フレーム）ではFP8が速かった（INT8がFP8の約1.86倍かかった）。ファイルサイズはほぼ同じである。本記事は出力品質を比較していないため、品質を含めた判断材料は提供していない。

この記事の測定のあと、生成そのものを短縮するコミュニティ製のTurbo LoRAが登場した。同じ機材・同じワークフローでステップ数だけを変えて測った結果はMiniMax H3 Turbo LoRA（step600 EMA）とは｜ComfyUIの置き場所・推奨ステップ数と速さをRTX 5080/5060 Tiで実測にまとめている。

参考資料

• MiniMaxAI/MiniMax-H3（Hugging Face・モデルカード）
• MiniMax H3 Community License Agreement
• MiniMax H3: An Open Model Breaking the Boundaries Between Tasks and Modalities（MiniMax公式・2026年7月31日）
• Open General Intelligence: MiniMax H3 Is Now Open Source（MiniMax公式・重み公開）
• Comfy-Org/MiniMax-H3（ComfyUI向け再パッケージ版）
• ComfyUI v0.30.0 リリースノート
• ComfyUI v0.35.0 リリースノート
• ComfyUI Issue #15665: MiniMax H3 video generation ~4x slower since v0.32.0

同じMiniMaxのオープンウェイトでも、音楽生成のMiniMax Music 3は同じ16GB環境で別の測り方になる。そちらの実測はMiniMax Music 3をVRAM 16GBで動かすにまとめている。