RTX 5060 Ti 16GBでMiniMax H3をローカル実行してみた ― ComfyUI・NVFP4・音声付きT2V/I2V
検証日: 2026年8月23日
本記事では、入力に使った写真および生成動画そのものは掲載していません。設定、プロンプト、実測時間を中心にまとめます。
はじめに
MiniMax H3のオープンウェイト版を、RTX 5060 Ti 16GB搭載PCのComfyUIで試しました。
今回使ったのは、FL2VAのprunedモデルをBlackwell向けNVFP4へ量子化した第三者配布チェックポイントです。T2V（Text to Video）とI2V（Image to Video）の両方で、映像と音声を含む約5秒の動画を生成できました。
先に結論を書くと、次の構成で動作しました。
- GPU: RTX 5060 Ti 16GB
- RAM: 32GB
- PyTorch:
2.13.0+cu130 - ComfyUI:
0.33.0 - Diffusion model:
minimax_h3_fl2va_pruned_nvfp4.safetensors - 標準Attention、10 steps
- SageAttention、EasyCache、Turbo LoRAは未使用
640×384・124 framesのT2Vは約75秒、768×448では113.40秒でした。I2Vも生成できました。
MiniMax H3は何が違うのか
従来のローカル動画生成では、次のように工程を分けることが少なくありませんでした。
- 動画を生成する
- TTSで台詞を作る
- 効果音やBGMを追加する
- 必要ならリップシンクをかける
MiniMax H3は、映像とネイティブステレオ音声を同じ生成系で扱います。映像に加えて、台詞、環境音、効果音、音楽までプロンプトでまとめて指定できる点が大きな違いです。
MiniMax公式によると、H3は最大15秒、APIでは最大2Kの映像とネイティブステレオ音声を生成できます。オープンウェイトのローカル実行では、FL2VAとRef2VAという2系統のチェックポイントが提供されています。
| 系統 | 主な用途 |
|---|---|
| FL2VA | T2V、最初のフレーム、最後のフレーム、または両方を使った動画生成 |
| Ref2VA | 画像・動画・音声を参照した、人物・スタイル・声などの一貫性を重視する生成 |
今回検証したのはFL2VAです。Ref2VAは未検証です。
公式情報:
検証環境
| 項目 | 内容 |
|---|---|
| OS | Windows |
| GPU | NVIDIA GeForce RTX 5060 Ti 16GB |
| Compute Capability | 12.0（SM120 / Blackwell） |
| GPUメモリ | 16,311 MiB |
| NVIDIA Driver | 591.86 |
| RAM | 32GB |
| ストレージ | NVMe SSD |
| Comfy Desktop | 1.0.39 |
| ComfyUI | 0.33.0 |
| Python | 3.12.11 |
| PyTorch | 2.13.0+cu130 |
torch.version.cuda |
13.0 |
| comfy-kitchen | 0.2.31 |
| システムCUDA Toolkit / nvcc | 12.8 |
cu130とCUDA Toolkit 12.8が同居している理由
ここは少し混乱しやすいところです。
この環境でComfyUIが使うのは、PyTorchパッケージに対応したCUDA 13.0ランタイムです。一方、Windowsへ別途インストールされているnvccはCUDA Toolkit 12.8でした。
PyTorchのCUDAランタイムと、ローカルでCUDA拡張をビルドするときに使うCUDA Toolkitは別物です。今回の標準Attentionによる生成では、システム側のToolkitを13.xへ変更する必要はありませんでした。
Comfy Desktopでは、インスタンス選択画面のUpdateタブにPyTorchの選択欄があります。この環境では、そこでPyTorch 2.13.0+cu130を選択しました。Desktop本体の設定画面にある通常のUpdatesとは別の画面です。
使用したモデル
Diffusion modelは、coolthor/MiniMax-H3-pruned-NVFP4で配布されている第三者変換モデルです。MiniMaxまたはComfy-Orgが配布する原版そのものではありません。
| 種類 | ファイル名 | 実ファイルサイズ | 配置先 |
|---|---|---|---|
| Diffusion model | minimax_h3_fl2va_pruned_nvfp4.safetensors |
約11.67 GiB | ComfyUI/models/diffusion_models/ |
| Text encoder | qwen3vl_32b_minimax_h3_nvfp4_awq.safetensors |
約14.61 GiB | ComfyUI/models/text_encoders/ |
| Video VAE | minimax_h3_video_vae_fp16.safetensors |
約4.85 GiB | ComfyUI/models/vae/ |
| Audio VAE | minimax_h3_audio_vae_fp32.safetensors |
約0.56 GiB | ComfyUI/models/vae/ |
合計は約31.7 GiBです。
Text encoderと2種類のVAEはComfy-Org配布のファイルです。NVFP4版のモデルカードにも、この3ファイルをComfy-Org/MiniMax-H3から取得するよう記載されています。
なぜNVFP4版を選んだのか
RTX 5060 TiはBlackwell世代のGPUです。今回のpruned NVFP4版は、BlackwellのTensor Core向けブロックスケールFP4を使うweight-only量子化で、FL2VA transformerを約11.67 GiBに収めています。
ローカル環境では、ComfyUI起動時に次を確認しました。
- GPUがCompute Capability 12.0として認識される
-
comfy-kitchenのCUDA backendが有効 -
scaled_mm_nvfp4が利用可能 - NVFP4関連エラーや別経路へのfallbackが発生しない
したがって、「NVFP4ファイルを読み込めただけ」ではなく、Blackwell向けNVFP4経路が利用可能な状態で生成できたと判断しています。
なお、配布者によるRTX 5090の測定値を、そのままRTX 5060 Tiへ当てはめることはできません。本記事の生成時間は後述する手元の実測値です。
ComfyUI側の構成
最近のComfyUIにはMiniMax H3のネイティブ対応とworkflow templateが含まれています。今回の生成部分はComfyUI本体のノードを使い、MiniMax H3専用の生成custom nodeは追加していません。
公式チュートリアル:
基本的な流れは次のとおりです。
H3形式のプロンプト
↓
Qwen3-VL-32B Text Encoder
↓
MiniMax H3 FL2VA pruned NVFP4
↓
Video VAE ──→ 映像
Audio VAE ──→ 音声
↓
Create Video / Save Video
I2Vでは、これにLoad Imageとfirst frameの接続が加わります。
最初に使った生成設定
画質の追求よりも、まず最後まで正常に生成できることを優先しました。
| 項目 | 設定 |
|---|---|
| Mode | T2V |
| Resolution | 640×384 |
| Frames | 124 |
| FPS | 24 |
| 長さ | 約5.17秒 |
| Steps | 10 |
| Sampler | res_multistep |
| Scheduler | simple |
| Denoise | 1.0 |
| Batch | 1 |
| Attention | PyTorch標準 |
| Dynamic VRAM | 有効 |
| async weight offload | 有効 |
| SageAttention | OFF |
| EasyCache | OFF |
| Turbo LoRA | OFF |
このモデルはCFG-distilled weightsです。使用したworkflowはBasicGuider構成で、一般的なCFG値やnegative promptを設定する形ではありません。
124 framesを24 fpsで出力すると、約5.17秒になります。H3のフレーム数は17n + 5の並びになるため、変更するときは73、90、107、124などの値を使います。ただし、最初の基準生成では学習レンジに沿った124 framesを選びました。
H3のプロンプトは普通の文章と少し違う
MiniMax H3では、単なるキーワード列よりも、映像・音響・音楽を分けた構造化プロンプトが重要でした。
基本形は次の3フィールドです。
integrated_multimodal_description: [Shot 1] ...
overall_soundscape: ...
non_diegetic_music: ...
公式のprompt-writing skillでも、このフィールド名と順序を維持し、説明部分を英語で書き、台詞・歌詞・画面内テキストは元の言語を保持するよう案内されています。
例えば、日本語で次のように指定したいとします。
朝の湖畔に立つ若い女性。カメラに微笑み、自然にまばたきして
「おはよう。今日もいい天気だね。」と日本語で話す。
穏やかな風で髪が少し揺れる。音楽はなし。
H3へ渡す形は、概ね次のようになります。
integrated_multimodal_description: [Shot 1] A realistic cinematic medium close-up of a young woman standing beside a calm lake at sunrise. She looks gently toward the camera, smiles naturally, blinks, and says <d>[Japanese] おはよう。今日もいい天気だね。</d> A light breeze moves her hair while the camera makes a very slow push forward.
overall_soundscape: Her Japanese speech is clear and calm. Gentle water, a light morning breeze, and faint distant birds are heard in the background.
non_diegetic_music: N/A
実際の生成では、被写体、構図、動作、カメラ、台詞、環境音をもう少し具体的に記述しています。
日本語の自由文をOllamaで自動変換した
毎回この形式を英語で書くのは手間です。また、クラウドLLMをworkflowへ組み込むと、生成するたびにAPIクレジットを消費する可能性があります。
そこで、Ollamaのqwen3.5:4bを使い、日本語の依頼文をH3形式へ変換する小さなローカルノードを作りました。
使用モデル:
qwen3.5:4b- ダウンロードサイズ: 約3.4GB
- Ollama API:
http://127.0.0.1:11434/api/chat
workflow内の流れは次のようになります。
日本語で動画の内容を入力
↓
Ollama / qwen3.5:4b
↓
H3の3フィールド形式へ英語で整形
↓
フィールドと日本語台詞を検証
↓
MiniMax H3へ入力
ローカルノードでは、少なくとも次をチェックしています。
- 3つの必須フィールドが存在するか
-
「……」または『……』の台詞が欠落していないか - 日本語の台詞が翻訳・ローマ字化されず、そのまま残っているか
- T2Vで存在しない入力画像を参照していないか
- I2Vでは
<Picture 1>を0秒のfirst frameとして参照しているか
変換後はOllamaモデルを即時unloadし、動画生成側へVRAMを戻すようにしました。
これはMiniMax公式のH3-Context-IRを再現するものではありません。公式のprompt-writing guidanceを参考に、手元の用途に合わせて作った簡易的なローカル変換です。
実測結果
| Mode | Resolution | Frames / FPS | Steps | 生成時間 |
|---|---|---|---|---|
| T2V | 640×384 | 124 / 24 | 10 | 約75秒 |
| T2V | 768×448 | 124 / 24 | 10 | 113.40秒 |
| I2V | 1024×768 | 124 / 24 | 10 | 402.38秒 |
すべてRTX 5060 Ti 16GB、標準Attentionでの測定です。プロンプトや入力条件が異なるため、厳密な同条件ベンチマークではありません。
今回、peak VRAMとpeak RAMは継続的に記録していません。そのため数値は掲載しません。少なくとも、上記3条件ではCUDA OOMを起こさず、Video VAEとAudio VAEのdecode、動画保存まで完了しました。
640×384のT2Vでは、約5秒の動画が約75秒で生成できました。16GBクラスのBlackwell GPUで、音声付き動画をローカル生成できる点はかなり面白い結果です。
日本語の短い台詞も生成できました。ただし、発音の自然さや話者の声質は毎回完全に一定ではありません。
I2Vで一度失敗したこと
I2Vは「画像をfirst frameへ接続すれば、背景がそのまま固定される」とは限りません。
最初の試行では、室内写真を入力したにもかかわらず、生成途中で屋外のような背景へ変化しました。調べると、主に次の問題がありました。
- 画像を接続していても、プロンプト変換ノードのmodeがT2Vになっていた試行があった
- ローカルLLMへ画像自体を渡しておらず、文章だけから背景を推測させていた
-
<Picture 1>をfirst frameとして固定する指示が弱かった - 入力画像と出力動画のアスペクト比が異なっていた
- 5秒に対して、人物全員の移動など大きすぎる動作を指定した
対策として、I2Vのプロンプト先頭へ次のalignment instructionを入れました。
For the target video, at 0.00 seconds into the target video, <Picture 1> (from [Shot 1]) is fully referenced.
さらに、次のような制約を明示しました。
Keep the camera position, framing, lighting, walls, ceiling, furniture, and the entire background unchanged from <Picture 1>.
The background and all non-human objects remain completely static and unchanged; only the requested person moves.
Do not introduce a new location, outdoor scenery, windows, or a scene transition.
この修正後は、壁、天井、照明、家具、カメラ構図を概ね維持しながら、指定した人物だけを動かす生成に成功しました。
I2Vで分かったこと
I2Vでは、「何を動かすか」だけでなく「何を変えてはいけないか」も明示した方が安定しました。
特に人物だけを動かしたい場合は、次を具体的に固定するのが有効です。
- カメラ位置と画角
- 背景、壁、天井、床
- 家具と小物
- 照明
- 人数、顔、髪型、服装
- 動かさない人物
なお、今回のOllamaノードは画像tensorをローカルLLMへ渡していません。より堅牢にするなら、今後はQwen3.5の画像入力も使い、first frameの内容を実際に見せたうえでプロンプトを生成する方法が考えられます。
さらに高速化できるか
現状でもNVFP4とCUDA 13.0の組み合わせで十分高速ですが、まだ余地はあります。
安全側から試すなら、次の順番がよさそうです。
- Stepsを10から8へ下げ、品質を比較する
- 解像度を少し下げる
- 必要な長さに合わせてframesを減らす
- その後にTurbo LoRAを検証する
フレーム数の例は次のとおりです。
| Frames | 24 fpsでの長さ |
|---|---|
| 73 | 約3.04秒 |
| 90 | 約3.75秒 |
| 107 | 約4.46秒 |
| 124 | 約5.17秒 |
今回は基準となる安定動作を確認するため、SageAttentionとEasyCacheは使いませんでした。
SageAttentionは環境依存のビルドやBlackwell対応状況を確認する必要があります。最初から導入すると、H3本体、NVFP4、Attention拡張のどこに原因があるのか切り分けにくくなります。まず標準Attentionで成功させてから比較する方が安全です。
複数シーンを1本にする場合
H3で複数シーンを一度に書くこともできますが、16GB VRAM・32GB RAM環境では、各シーンを個別に生成して後から結合する方が扱いやすいです。
例えば次の流れです。
Scene 1を生成・保存
↓ 最終フレームを取り出す
Scene 2のfirst frameとしてI2V生成・保存
↓ 最終フレームを取り出す
Scene 3を生成・保存
↓
映像と音声を結合
最初はhard cutで結合するのが簡単です。映像だけcrossfadeすると、生成済み音声との同期がずれる可能性があるため注意が必要です。
注意点
1. 16GBで動くが、モデルは小さくない
今回必要だったH3関連ファイルは合計約31.7 GiBです。全モデルを常時VRAMへ置くのではなく、ComfyUIのDynamic VRAMとoffloadを使って実行しています。
RAM 32GBでは余裕が大きいとはいえません。pagefileを無効化せず、NVMe SSDに十分な空き容量を確保した方が安全です。高解像度化や長尺化を急に行うと、RAMやpagefileへの退避が増えて極端に遅くなる可能性があります。
2. NVFP4版は第三者変換
minimax_h3_fl2va_pruned_nvfp4.safetensorsは、MiniMax公式またはComfy-Org公式の原版ではなく、pruned weightsをNVFP4へ変換したものです。モデルカード、更新履歴、ハッシュ、配布元を確認して利用する必要があります。
3. ライセンスを必ず確認する
MiniMax H3はMiniMax H3 Community License Agreementで配布されています。利用可能地域、Acceptable Use Policy、商用利用、再配布、第三者へ生成機能を提供する場合の条件などがあります。
特に、ライセンス上の対象地域と除外地域が定められています。Hugging Faceのリポジトリもgatedになっており、利用前に条件への同意が必要です。本記事の記述だけで判断せず、利用時点の原文を確認してください。
4. 実写人物を入力するときは権利と同意に注意する
I2Vへ人物写真を使う場合は、本人の同意、肖像権、プライバシー、公開範囲を確認する必要があります。そのため本記事では、入力写真、人物の顔、生成動画を掲載していません。
まとめ
RTX 5060 Ti 16GBとRAM 32GBのWindows PCで、MiniMax H3 FL2VA pruned NVFP4をComfyUIから実行できました。
今回のポイントは次のとおりです。
- Blackwell世代のRTX 5060 TiでNVFP4経路を利用できた
- 640×384・約5秒・10 stepsのT2Vを約75秒で生成できた
- 768×448でも113.40秒で生成できた
- I2Vも動作し、背景固定の指示を強化すると安定した
- 映像と日本語台詞、環境音を1つのworkflowで生成できた
- Ollamaと
qwen3.5:4bを使い、日本語の自由文をH3推奨形式へローカル変換できた - SageAttentionなどを追加しなくても、標準Attentionでまず動作確認できた
単に「静止画を動かす」だけでなく、台詞や環境音まで含めてシーンを設計できるところに、これまでのローカル動画生成とは違う面白さを感じました。
一方で、I2Vの背景固定、構造化プロンプト、VRAMとRAMのoffload、第三者量子化モデルとライセンスの確認など、気を付ける点もあります。
次に試すなら、8 stepsとの品質比較、Turbo LoRA、複数シーンの連結、そして画像を実際に見せるvision対応のローカルprompt rewriterを検証したいと思います。