「MiniMax H3はVRAM 8GBでも動く」という情報がある一方で、100GBを超えるシステムRAMを用意した検証や、RTX 5090でもBF16の読み込みに失敗したという報告もあります。
これでは、自分のPCで使えるのか判断しにくいのも無理はありません。
結論から言えば、MiniMax H3の必要スペックはVRAM容量だけでは決まりません。
選ぶモデル形式、出力解像度、動画時間、T2V・I2V・R2Vの違い、CPUオフロード、システムRAM、SSD、GPU世代の組み合わせで、起動の可否と生成時間が大きく変わります。
さらに、「一度だけ生成に成功した」と「何度も設定を変えながら安定運用できる」は別の基準です。
本記事では、前者を最低動作、後者を実用と呼び分けます。MiniMax H3の概要やローカル導入手順、2K・音声同時生成の仕組みは、既存記事のMiniMax H3の機能とローカル導入方法で確認してください。
ここではPCスペック、モデル形式、メモリ、生成速度に絞ります。
MiniMaxもComfyUIも、2026年8月9日時点で「最低VRAMは何GB」とする保証値を示していません。
ComfyUIはDynamic VRAMオフロードと軽量モデルを組み合わせ、RTX 3060のようなGPUでも動かせると説明していますが、これは最低動作保証ではなく、最適化後の実行例です。
以下は、MiniMax公式モデルカード、ComfyUI公式ワークフロー、公式配布ファイル、公開された実機情報を基にした参考構成です。
PCを新規購入する場合は最低動作ではなく、「初心者向けの現実的な構成」以上を基準にしてください。
本記事では、配布元のモデルカード・ドキュメント・ファイル一覧を「公式情報」、個人が公開した結果を「実機報告」、両者から導いた構成を「編集上の目安」として区別します。
実機報告は条件が揃った範囲だけを記載し、不明な項目は推測で補いません。
16GB VRAMは「全部がGPUに収まる容量」ではありません。軽量構成でもダウンロード容量は約42.5GBあるため、Text Encoderや生成モデルの重みをVRAMとRAMの間で入れ替えながら処理します。
ただし、8GBや12GBよりVRAMへ置ける範囲が広く、設定変更と再生成を繰り返しやすくなるため、個人向けの現実的な基準になります。
MiniMax H3の中心には、33B（約330億パラメータ）のH3-Omni-Transformerがあります。
公式説明では約13BがAdaLN関連の分岐にあり、推論専用のpruned版ではこの部分を削減できます。
それでも、映像と音声の長い潜在表現を同じ生成処理で扱うため、一般的な画像生成モデルより計算量とメモリ転送量が大きくなります。
モデル本体だけをダウンロードしても動きません。
文章や参照素材を解釈するQwen3-VL-32B系Text Encoder、映像を圧縮・復元するVideo VAE、ステレオ音声を処理するAudio VAEが必要です。
ComfyUI公式の軽量構成では、生成モデルが21GB、Text Encoderが15.7GB、2種類のVAEが合計約5.8GBあります。
負荷は生成モードでも変わります。T2Vはテキストだけを条件にしますが、I2Vは開始画像や終了画像を追加で符号化します。
R2Vは最大9枚の画像、3本の動画、3本の音声を参照でき、参照素材の解像度や長さが増えるほど前処理とメモリ使用量が増加します。
R2VではT2V・I2V用のfl2vaとは別に、ref2va生成モデルも必要です。
動画はフレーム数が増えるほど処理対象が長くなります。ComfyUIの公式テンプレートは24fpsで、長さを17フレーム単位のブロックに合わせます。
解像度と動画時間を同時に上げると、画素数だけでなく処理するフレームも増えるため、必要メモリと時間が急増します。
図解候補2の挿入位置
「SSD上のモデルファイル → システムRAM／ページキャッシュ → VRAM → 生成中の映像・音声latent」という流れを示し、VRAM不足時にRAM、RAM不足時にSSD上の仮想メモリへ退避するほど遅くなる関係を図解する。
図解候補1の挿入位置
VRAM 8GB・12GB・16GB・24GB・32GB以上について、「試せるモデル形式」「現実的な解像度」「オフロード量」「用途」を一枚で比較する。
8GB VRAMでも生成した公開例はあります。
RTX 4070 8GB、RAM 64GBで832×640を920秒かけて生成した報告があり、別のRTX 4060 Ti 8GBユーザーからも成功例が出ています。
ただし、モデル形式、Steps、オフロード設定、動画時間の全条件が揃っていない報告も多く、公式推奨スペックにはできません。
8GBでは、21GBのpruned INT8モデルも15.7GBのText Encoderも単体でVRAMに収まりません。
Dynamic VRAMで必要な重みだけを順次VRAMへ載せ、残りをRAMやSSD側から供給するため、システムRAMとNVMe SSDの速度への依存が強くなります。
最初は0.4MP以下、3～5秒、参照素材の少ないT2VまたはI2Vに絞るのが安全です。
「一度完成した」ことと、プロンプトやseedを変えながら何十回も試せることは分けて考えてください。
1本に15～20分以上かかるなら、用途によってはAPIの方が安く、作業も早く終わります。
ComfyUI公式ブログは、軽量構成とDynamic VRAMを組み合わせればRTX 3060のようなGPUでローカル実行できると説明しています。
また、RTX 3060 12GB、RAM 32GB、NVMe SSD、8bit weights、832×480・124フレームで10分未満という開発段階の報告も共有されました。
もっとも、Stepsなどの条件が欠けているため、他のGPUと比較するベンチマークには使えません。
12GBはT2Vを試すには有力ですが、I2Vでは入力画像、R2Vでは画像・動画・音声の参照処理が加わります。
RTX 3060 12GBだから必ず生成できるわけではなく、ComfyUI、PyTorch、CUDA、ドライバーの組み合わせにも左右されます。
RAM 32GBは最低ラインと考え、増設できるなら64GBを選ぶ方が安定させやすい構成です。
16GBでは、ComfyUI公式のpruned INT8生成モデルとNVFP4/AWQ Text Encoderを使う構成が現実的です。
両方を同時にVRAMへ置くことはできませんが、Text Encoderでプロンプトを処理した後に生成モデルへ入れ替え、Dynamic VRAMで重みを段階的に読み込めます。
RTX 4070 Ti SUPER 16GB、RAM 32GBの実例では、pruned INT8と量子化Text Encoderを用い、約0.7MP・5.17秒・20 StepsのI2Vを5分14秒～5分58秒で生成しています。
一方、RTX 5070 Ti 16GB、RAM 48GBの別報告では、公式I2Vテンプレートの0.4MP・5秒・20 Stepsを155秒で完了しました。
後者はWindows環境のクラッシュを回避するため、--disable-async-offload --disable-pinned-memoryを付けた結果です。
GPUだけでなくソフトウェア構成でも速度と安定性が変わることが分かります。
768pは利用範囲に入りますが、最初から約1344×768・15秒・多数の参照素材を選ぶと、原因の切り分けが難しくなります。
5秒・0.4MPで一度通し、解像度、時間、参照数を一つずつ上げてください。
RTX 3090や4090の24GBは、量子化モデルでVRAMに置ける重みが増え、8～16GBよりオフロード回数を抑えやすい構成です。
ただし、pruned BF16生成モデルだけで40.2GB、full BF16は66.3GBあります。
Text EncoderのBF16版も51.5GBなので、「24GBならBF16を完全にGPUへ読み込める」とは言えません。
24GBでまず選ぶならpruned INT8またはFP8です。
BF16はRAM 128GB級を用意し、モデルロードとオフロードを含む検証として扱う方が安全です。
RTX 30世代とRTX 40世代では利用できる低精度演算のハードウェアが異なるため、容量だけでなくComfyUI、PyTorch、CUDA、量子化カーネルの組み合わせも確認してください。
RTX 5090 32GBは、量子化モデルやpruned BF16の一部をより多くVRAMへ置けるため、生成速度と設定の余裕を得やすいGPUです。
Blackwell世代はNVFP4をハードウェアで扱える点も利点になります。
ただし、full BF16生成モデル66.3GBとBF16 Text Encoder 51.5GBを同時に載せることはできません。
BF16をGPU中心で検証するなら、96GBのRTX PRO 6000 Blackwellや複数GPUが候補です。
それでも解像度、15秒のフレーム列、VAE、参照素材の中間データが加わるため、VRAM容量だけで上限は決まりません。
RTX 5090を選ぶ価値は「オフロードがゼロになる」ことではなく、退避量と待ち時間を減らせる点にあります。
MiniMax H3では、VRAMに収まらない重みをシステムRAMへ置き、必要な部分をGPUへ転送します。
さらに、OS、ComfyUI、モデルロード、ページキャッシュ、入力素材、VAEの処理、一時データもRAMを使います。
VRAMだけ増やしてもRAMが足りなければ、ページファイルやswapへ退避し、SSDへの読み書きで大幅に遅くなります。
実測例では、RTX 5070 Ti 16GBとRAM 125GBの環境で、pruned INT8構成のComfyUI RSSピークが通常起動で45.4GiB、システム全体では51.0GiBでした。
同じ処理に--fast-diskを付けるとComfyUI RSSは12.6GiBへ下がり、約41.5GiBがページキャッシュに回っています。
これは、RAMを不要にする設定ではありません。
再利用可能なページキャッシュへ重みを置き、メモリ圧迫時にOSが破棄してNVMeから読み直せるようにする仕組みです。
--fast-diskは2026年8月時点のComfyUIで利用できます。
高速なNVMe SSDがあり、RAM不足がモデルロードの障害になっている場合に候補になりますが、SSDからの再読込が増えれば速度は下がります。
--cache-noneはノード出力のキャッシュ設定であり、モデル重みの常駐量を直接減らす設定ではありません。
仮想メモリやWindowsのページファイルは、RAM不足時のクラッシュを避ける保険にはなります。
しかし、SSDはRAMより遅く、頻繁な退避が起きるとGPUがデータ待ちになります。
32GB RAM＋大きなページファイルを、64GBや128GBの物理RAMと同等とは考えないでください。
PC全体のVRAM・RAM・SSDの選び方は、ローカルLLM用PCのおすすめスペックも参考になります。
LLMと動画生成では負荷の中身が異なりますが、「ファイル容量」「実行時メモリ」「速度」を分ける考え方は共通しています。
ComfyUI公式が案内するT2V・I2V向けの最小構成は約42.5GBです。
R2Vを追加する場合は、FL2VAとは別の21GBのRef2VAモデルが必要になり、モデルだけで合計約63.5GBになります。
ダウンロード中の一時ファイル、ComfyUI本体、出力動画、ページファイル、キャッシュを考えると、T2V・I2Vだけでも空き70～100GB、R2V併用なら100～150GBを確保した方が扱いやすくなります。
R2Vは上記に加えて、参照する画像・動画・音声の保存容量を使います。
動画の読み込みや最終MP4への結合で、利用するノードやOS環境によってffmpegが必要になる場合もあります。
公式テンプレートが動かないときは、モデル不足だけでなく、ComfyUI 0.30.0以降、動画デコード環境、ffmpegのパス、入力形式も確認してください。
配布リポジトリ全体は465GBで、すべてをダウンロードする必要はありません。
用途と数値形式を決め、必要なファイルだけを取得します。
また、表示されるダウンロード容量はVRAMやRAMの必要量ではありません。
圧縮された重みを実行時に展開する処理や中間データがあるため、同じ数字にはならない点に注意が必要です。
以下はComfy-Org公式配布に含まれる生成モデルとText Encoderの全選択肢です。
サイズはHugging Faceが表示する10進表記で、保存先は生成モデルがComfyUI/models/diffusion_models/、Text EncoderがComfyUI/models/text_encoders/です。
MiniMax H3では、生成モデル本体とText Encoderに別々の量子化形式があります。
ComfyUI公式の初心者向け構成は、生成モデル本体にpruned INT8、Text EncoderにNVFP4＋AWQを使います。
「NVFP4版H3モデル」や「INT4版H3」と一括りにすると、どの部品を指すのか分からなくなります。
INT8とFP8はどちらも8bitですが、整数と浮動小数点で表現方法が異なります。
INT8 ConvRotはComfyUIがH3向けに用意したカーネルと組み合わせる構成です。
FP8はRTX 40シリーズのAda以降でハードウェア対応が強化されていますが、モデルの形状、カーネル、CUDA、PyTorch次第ではINT8より速いとは限りません。
NVFP4は4bit浮動小数点形式で、一般的なINT4とは別物です。2026年8月9日時点のComfy-Org公式配布には、H3生成モデル本体のINT4ファイルはありません。
NVFP4＋AWQはQwen3-VL-32B系Text Encoderを15.7GBへ抑えるための形式です。
RTX 50シリーズのBlackwellはNVFP4をハードウェアで処理できますが、ComfyUI公式情報ではNVFP4高速化にCUDA 13.0版PyTorchが重要とされ、環境が合わなければ動作してもFP8より遅くなる場合があります。
画質についても「INT8ならまったく低下しない」とは断定できません。
ComfyUIはpruned化した変調重みを機能的に等価なルックアップテーブルへ置き換え、出力品質を保つと説明していますが、量子化形式間の差はプロンプト、動き、顔、文字、seedによって見え方が変わります。
まず量子化版で構図を詰め、必要なカットだけBF16で再検証する使い方が現実的です。
VAEは、動画や音声を生成モデルが扱いやすい圧縮表現へ変換し、最後に人が見聞きできる形式へ戻す部品です。
MiniMax H3は映像と音声を同時に生成しますが、映像と音声ではデータの性質が異なるため、Video VAEとAudio VAEを分けています。
minimax_h3_video_vae_fp16.safetensorsは5.21GBあり、映像フレームを潜在表現へ変換し、生成後の潜在表現をフレームへ復元します。
T2Vでは主に復号、I2V・R2Vでは入力素材の符号化と出力の復号に関わります。
保存先はComfyUI/models/vae/です。
ファイル名のFP16は半精度浮動小数点を示します。
Video VAEは容量と計算量が大きく、デコード時にVRAMやRAMのピークが発生することがあります。
Windows環境では、pinned memoryやasync offloadとの組み合わせでVAE decodeがクラッシュしたIssueもあるため、最新版へ更新してから再現条件を確認してください。
minimax_h3_audio_vae_fp32.safetensorsは605MBで、32kHzステレオ音声の潜在表現を処理します。
FP32は32bit浮動小数点で、Video VAEのFP16より1要素当たりのデータ量が大きい形式です。
ただしモデル自体が小さいため、ファイル容量はVideo VAEより小さくなっています。
映像だけ欲しい場合でも、公式ワークフローでは生成中に映像と音声のlatentを一緒に扱います。
Audio VAEのデコードを省けば最終的な音声復元やmuxを省略できますが、H3本体の音声latent計算がすべて消えるとは限りません。
MiniMax H3のH3-EncoderはQwen3-VL-32Bの重みを使います。
ComfyUIではqwen3vl_32b_minimax_h3_nvfp4_awq.safetensorsをComfyUI/models/text_encoders/へ保存します。
生成モデルとは別ファイルであり、NVFP4/AWQ版でも15.7GBあるため、低VRAM環境ではText Encoder処理だけでVRAMをほぼ使い切る場合があります。
VAEを取り違えると、テンソル形状やdtypeの不一致、映像・音声のデコードエラー、ノイズ出力、クラッシュにつながります。まずファイル名と保存フォルダを確認し、それでも直らなければ不完全なダウンロードを疑います。Hugging Face表示のファイルサイズとローカルのサイズを比較し、可能ならSHA-256やsafetensorsの読み込み検証を行ってください。実際に、不完全なVideo VAEで末尾がゼロ埋めになり、再取得後に検証をやり直したGitHub報告があります。
次の表は動作保証ではありません。VRAMとGPU世代、公式配布形式、条件が確認できる公開報告を基に、「最初に選ぶ設定」を編集上の目安として整理しています。実機情報の条件が不足するGPUは、速度を推測で埋めていません。
RTX 4080やRTX 5080は演算性能が高くてもVRAMは16GBです。
RTX 4060 Ti 16GBより速く生成できる可能性は高い一方、どのモデルを丸ごと収められるかという容量上限は変わりません。
PC購入ではGPU名だけでなく、VRAM、RAM、NVMe SSD、CUDA環境を一組で確認してください。
MiniMax H3の生成時間は、GPU名だけでは比較できません。
解像度、フレーム数、Steps、T2V・I2V・R2V、量子化、SageAttention、音声デコード、オフロード、初回ロードか連続実行かで結果が変わるためです。
条件を比較的確認しやすい公開例を整理すると、次のようになります。
順位表ではなく、それぞれ独立した実行例として見てください。
SageAttentionはComfyUI公式ドキュメントで最大約2倍の高速化候補として紹介されていますが、すべての層が対応するわけではありません。
2026年8月にはBlackwellの一部カーネルで長いシーケンスがノイズ化するIssueも確認されています。
KJNodesでpv_fp16系の実装を選ぶ回避例はあるものの、速度だけを見てグローバル設定を追加せず、同じseedで映像と音声を比較してください。
EasyCacheなどStepsを飛ばす高速化も、映像が近く見えても音声の低域や音量が変化した報告があります。
H3は映像と音声を同時に扱うため、映像だけの類似度では品質を評価し切れません。
高速化前後で、口の動き、効果音の同期、会話、BGMまで確認する必要があります。
ローカル実行は、生成ごとのAPI料金を気にせず試せ、素材をPC外へ送らずに処理しやすい点が魅力です。
一方、42.5GB以上のモデル取得、ComfyUI更新、CUDA・PyTorch・カーネルの整合、ストレージ管理、長い生成時間を自分で引き受けます。
2026年8月9日時点の公式料金では、10秒動画は768pで0.80ドル、2Kで1.30ドルです。
768pから2KへのRegenerationは1秒0.05ドルで、元の入力素材が再課金される条件もあります。
料金は改定され得るため、公開前と利用前にMiniMax公式Pay as You Go料金を確認してください。
既に16GB以上のNVIDIA GPUと64GB RAMを持ち、毎週何十本も試作するなら、まずローカルを整える価値があります。
8GB GPUで1本ごとの待ち時間が長い、数本だけ生成したい、公式品質の2Kが必要、CUDAの不具合対応を避けたい場合はAPIが合理的です。
機密素材を扱う場合はローカルが候補になりますが、利用ライセンスと、使用するカスタムノードが外部通信しないかも確認してください。
MiniMax H3は、MITやApache 2.0ではなく、独自の「MiniMax H3 Community License Agreement」で公開されています。
適用地域は世界のうち除外地域を除く範囲で、米国、EU、英国、韓国は除外地域です。
日本は除外地域に含まれていませんが、利用目的、配布、商用サービス、表示義務、Acceptable Use Policyなどの条件は別途守る必要があります。
年間売上が2,000万米ドルを超える商用製品・サービスには事前の書面承認が必要とされ、商用サービスのUIへ「MiniMax H3」を目立つ形で表示する条件もあります。
生成物の利用を含め、公開前にMiniMax H3公式ライセンスの原文と更新日を確認してください。
これは法的助言ではありません。
ローカルで公開されているのはH3-BaseのFL2VAとRef2VAです。
H3-Context-IRは複数のホスト型モデルとサービスを使うため公開部分に含まれず、H3-Regenerate-2Kも2026年8月9日時点では未公開です。
公式と同じ2Kワークフローは、ローカルH3-BaseとMiniMax APIを組み合わせる構成か、API内で完結する構成になります。
各段階の役割は、既存記事のMiniMax H3の2K・音声同時生成の仕組みで解説しています。
ComfyUIは0.30.0以降が必要です。
NVIDIA GPUでもRTX 30・40・50シリーズで同じ速度やカーネルが使えるわけではなく、FP8、NVFP4、INT8 ConvRotの対応はGPU世代、PyTorch、CUDAに依存します。
MacやAMD GPUについて、ComfyUI自体はMetalやROCmに対応しますが、MiniMax H3の量子化カーネルと速度はNVIDIA CUDAと同条件ではありません。
AMD RX 7900 XTXで公式テンプレートがノイズ化したIssueもあり、購入判断にはまだ慎重さが必要です。
MiniMax H3の必要スペックは、VRAMの数字だけでは決められません。
初心者が最初に確認したいのは、pruned INT8生成モデルとNVFP4/AWQ Text Encoderを使えるか、RAM 64GBと空き100GB前後のNVMe SSDを用意できるか、5秒・0.4MPから試せるかの3点です。
8GBと12GBは生成例があるものの、強いオフロードと長い待ち時間を受け入れる最低動作寄りの構成です。
16GBはモデル全体を収める容量ではありませんが、個人が設定を変えながら使う現実的な出発点になります。
24GBや32GBでは量子化モデルが扱いやすくなる一方、full BF16一式をGPUへ完全常駐させられるわけではありません。
まず公式テンプレートを量子化モデル、低解像度、短時間で一度完走させ、解像度、秒数、参照素材を一項目ずつ増やしてください。
公式品質の2Kが必要、利用頻度が低い、PC更新費用や保守時間が見合わない場合は、API料金と比較してから判断する方が無理がありません。
.png){kind=logo}
