はい、MiniMax H3はローカルで動作します。オープンなH3-Baseのウェイトを使えば、自分のハードウェア上で動画とネイティブのステレオ音声を生成できます。コミュニティ製の実行環境では、24GB GPUや12~16GBのカード、さらには実験的な8GB構成での動作も実現しています。
注意すべき点は、「H3をローカルで実行する」ことが、現時点ではMiniMaxのホスト型パイプラインのすべての機能をオフラインで再現することを意味しない点です。H3-Baseはローカル推論に対応していますが、公式のH3-Context-IRオーケストレーション層とH3-Regenerate-2Kの工程は引き続きホスト型です。多くのホームAIユーザーにとって、H3は単にモデルをダウンロードするだけでなく、GPUメモリ、システムRAM、モデルの保存領域、ワークフローソフトウェア、さらにはNASやホームサーバーも関わるインフラの課題です。
MiniMax H3は本当にローカルで動作しますか?
はい。MiniMaxは2026年8月にH3をオープンウェイトのマルチモーダル動画モデルとして公開し、ローカルハードウェアに導入できるH3-Baseのチェックポイントを提供しています。
MiniMaxの公式H3リリースでは、テキスト、画像、動画、音声を組み合わせて理解し、ネイティブのステレオ音声とともに動画を生成できる汎用マルチモーダルシステムとして、このモデルを紹介しています。
ローカルのH3-Baseモデルは、次の機能に対応しています。
- 4~15秒の動画生成
- 24 FPS出力
- 32 kHzステレオ音声
- 音声付きテキスト動画生成
- 最初のフレームと最後のフレームによる条件付け
- マルチモーダルな画像、動画、音声の参照
- 16:9、9:16、1:1、4:3、21:9など、複数のアスペクト比
H3-Baseのデフォルト出力では、短辺が768ピクセルになります。この違いは重要です。よく宣伝されている「最大2K」の性能は、基本的な完全ローカルのワークフローだけでなく、H3システム全体の機能だからです。
MiniMax H3は完全にローカルで動作しますか?それともクラウドが必要ですか?
プライベートなH3環境を構築する人にとって、これが最も重要な違いです。
公式のH3ワークフローは、主に3つの部分で構成されています。
| コンポーネント | 機能 | 今すぐローカルで実行できますか? |
|---|---|---|
| H3-Context-IR | 複雑なテキスト、画像、音声、動画の参照を解釈し、構造化された生成指示に変換 | いいえ。公式実装はホスト型です |
| H3-Base | 動画とステレオ音声を生成 | はい |
| H3-Regenerate-2K | 元のマルチモーダルコンテキストを使い、ベースの結果を2Kで再生成 | いいえ。公式実装は現在ホスト型です |
MiniMaxはH3の公式リポジトリで、H3-Context-IRは複数のホスト型モデルとサービスに依存しており、現在のオープンリリースには含まれていないと明記しています。H3-Regenerate-2Kもまだオープンソース化されていません。
つまり、導入方法は大きく異なる2つのモデルに分かれます。
完全ローカルのH3
プロンプトまたはローカル参照メディア → H3-Base → ローカルで768pクラスの動画とステレオ音声を生成。
ソースファイル、生成プロセス、出力をすべて自分のマシン内にとどめることができます。これはローカルAI処理の根底にある、より広い原則と同じです。自分のネットワーク内にとどめる段階が増えるほど、プライベートデータやサービスへの依存関係をより細かく制御できます。
ハイブリッドH3
ホスト型Context-IR → ローカルにデプロイしたH3-Base → ホスト型Regenerate-2K。
この方法ならMiniMaxのワークフロー全体をより多く再現できますが、完全にオフラインかつプライベートな処理ではなくなります。
ローカル優先のAI環境を目指すなら、H3-Baseが最も重要なコンポーネントです。
MiniMax H3をローカルで実行するには、どんなハードウェアが必要?
MiniMax H3に必要なVRAM容量は一概には言えません。精度、量子化、モデルのプルーニング、オフロード、解像度、ワークフロー、実行環境によって大きく変わります。
ネイティブモデルは大規模です。H3は330億パラメーターの密なH3-Omni-Transformerを採用し、エンコーダーには事前学習済みのQwen3-VL-32Bの重みを使用しています。MiniMaxによると、トランスフォーマーのパラメーターのうち約130億はAdaLN関連の分岐に属し、その出力は推論時に事前計算してキャッシュできます。それでも、一般的な非量子化のコンシューマー向けモデルと比べて、必要なメモリ容量ははるかに大きいままです。
そのため、ローカル環境のエコシステムではプルーニングと量子化が重視されています。
| GPUクラス | 実用的なH3の実行方法 | 期待できること |
|---|---|---|
| 8GB VRAM | NF4 + CPU/RAMへの大規模なオフロード | 技術的には可能ですが、メモリが大幅に制約され、動作も遅くなります |
| 12~16GB VRAM | プルーニング済みGGUFまたはNVFP4モデル + 量子化エンコーダー + 軽量VAE | 大幅なオフロードを許容できれば、実験に活用可能 |
| 24GB VRAM | プルーニング済みINT8 H3 + 量子化テキストエンコーダー | コンシューマー向けのローカルH3環境として、はるかに現実的な選択肢 |
| 48GB以上のVRAM | 高精度または量子化を控えめにしたワークフロー | スワップが少なく、妥協も少ない |
| データセンター/マルチGPU | BF16、分散推論、SGLangまたはvLLM-Omni | 最高のスループットとネイティブ展開に最も近い構成 |
MiniMaxが管理するH3統合インデックスでは現在、8GBのDiffSynth NF4構成から、12~16GBの量子化ビルド、24GBのComfyUI構成まで、ローカルでの実行方法が紹介されています。
だからといって、8GB GPUがH3に適したマシンだというわけではありません。
VRAMが足りない場合、モデルの各コンポーネントをGPUメモリとシステムメモリの間で移動させて補うことになります。すると問題は「モデルを読み込めるか」から、「生成のたびにどれだけ待てるか」に変わります。
最低限必要なVRAMと、実用に使えるVRAMは別の問題です。 SSDやNASを高速化すればGPUメモリ不足を補えると思い込む前に、演算・メモリ・ストレージのボトルネックを切り分けることが大切です。
MiniMax H3はRTX 4090のような24GB GPUで動く?
はい。24GBは現在、本格的な家庭用H3環境として特に注目されている構成のひとつです。
コミュニティやComfyUI向けのビルドでは拡散モデルが大幅に軽量化されており、プルーニング済みのINT8 H3トランスフォーマーは20GB前後に収まります。テキストエンコーダーは別途量子化でき、必要に応じてモデルの各コンポーネントをオフロードできます。
重要なのは、H3は単一の重みファイルではないということです。
一連の生成ワークフローには、以下が必要になる場合があります。
- H3拡散トランスフォーマー
- Qwen3-VLベースのテキスト/ビジョンエンコーダー
- 動画VAE
- 音声VAE
- オプションのLoRAまたは高速化モデル
- 参照メディア
- 一時的な潜在表現とデコード用メモリ
そのため、「19GBのモデル」だからといって、5GBの空きがあるVRAM 24GBのGPUに問題なく収まるとは限りません。
実行時のメモリ管理は、チェックポイントのサイズとほぼ同じくらい重要です。
MiniMax H3はVRAM 16GBまたは12GBで動かせる?
はい。ただし、さらにコミュニティによる量子化に頼ることになります。
現在のエコシステムには、プルーニング済みGGUFおよびNVFP4拡散モデルと、強く量子化されたQwen3-VLエンコーダーの組み合わせがあります。これによりH3をVRAM 12~16GBのクラスで動かせますが、システムメモリとデータ転送の重要性が増します。
これは、頻繁な制作作業に最適な構成というより、H3を使えるようにする方法と考えるのが適切です。
短いクリップをたまに生成するだけなら、このトレードオフは十分許容できるかもしれません。H3を使って数十本のクリップを生成する自動コンテンツ制作ワークフローでは、モデルをVRAMに収めることよりもスループットがはるかに重要になります。
MiniMax H3は本当にVRAM 8GBだけで動かせる?
現在は8GBで動かす方法もありますが、この数値には背景があります。
DiffSynth-Studioには、VRAMの最低要件が8GBとされるNF4推論設定があります。ただし、この容量では大規模なオフロードが必要になり、処理の大部分がGPU上に常駐しなくなります。
したがって、8GBの構成で問うべきなのは、次のことではありません。
「H3は起動するか?」
それは次のとおりです。
「生成にかかる時間は、やりたいことに対して許容範囲か?」
H3のテストやワークフローの習得、ときどきクリップを生成する用途なら、8GBで試す価値があります。ローカルで動画を繰り返し生成するなら、より多くのVRAMが使いやすさを大きく向上させます。
FL2VAとRef2VA:どちらのMiniMax H3モデルを使うべき?
H3-Baseには、タスク別に設計された2つのバリアントがあります。適切なものを選べば、ストレージの消費とワークフローの複雑さをどちらも抑えられます。
H3-Base-FL2VA
FL2VAはテキストとキーフレームを中心とした生成に特化しています。
| 入力 | 結果 |
|---|---|
| テキストのみ | テキストから動画+音声 |
| 最初の画像 | 最初のフレームから動画へ |
| 最後の画像 | 指定した画像で終わるシーケンスを生成 |
| 最初と最後の画像 | 2つのキーフレーム間のトランジションを生成 |
一般的なテキストから動画、または画像から動画への生成が目的なら、通常はFL2VAのほうが手軽な出発点です。
H3-Base-Ref2VA
Ref2VAは、より豊かなマルチモーダル参照条件付けを目的に設計されています。
H3公式モデルカードによると、Ref2VAは最大で以下を受け付けられます。
- 画像9枚
- 動画クリップ3本
- 音声クリップ3本
- 参照ファイル合計12個
これにより、キャラクター参照、モーション転送、スタイル参照、音声参照、元動画の編集、複数のメディア形式の組み合わせなど、より興味深いローカルワークフローが可能になります。
ただし、これらの参照素材が不要であれば、2つ目の大容量チェックポイントをダウンロードして管理しても、ストレージを消費するだけで、シンプルなテキストから動画への生成ワークフローが必ずしも改善するわけではありません。
MiniMax H3をローカルで実行する最も簡単な方法は?
多くの個人ユーザーにとって、現時点で最も手軽に始められるのはComfyUIです。
MiniMaxは、Diffusers、SGLang、vLLMと並んでComfyUIをサポート対象のデプロイ方法として挙げています。またComfyUIは、H3への初日対応をリリースし、コンシューマー向けGPUを対象とした低メモリ版も用意しています。
ComfyUI H3のリリースによると、H3のモジュレーション重みの枝刈り、INT8量子化、カスタムカーネル、動的なVRAMオフロードにより、フル精度でのデプロイと比べてメモリ使用量を大幅に削減できます。
実用的なローカル環境は次のように構成できます。
- ComfyUIをインストールするか、アップデートします。
- MiniMax H3のテキストから動画、画像から動画、または参照画像から動画へのワークフローを選びます。
- 対応する拡散モデルをダウンロードします。
- 互換性のあるH3テキストエンコーダーをダウンロードします。
- 動画用と音声用のVAEを追加します。
- まずは768p程度の短い動画を生成します。
- GPUメモリとシステムRAMの使用量を両方確認します。
- その後で、生成時間、解像度、またはワークフローの複雑さを段階的に増やします。
この順序が重要です。長尺クリップ、最大数の参照画像、高解像度、積極的な拡張機能を同時に使いながらH3をデバッグすると、問題の原因がモデル、メモリ、ノード、ワークフローのどれなのか判断しにくくなります。
H3向け ComfyUI、Diffusers、SGLang、vLLM-Omniの比較
最適なランタイムは、ベンチマークスコアよりも、H3の使い方によって決まります。
| ランタイム | 最適な用途 | 理由 |
|---|---|---|
| ComfyUI | クリエイターとホームユーザー | ビジュアルワークフロー、コンシューマー向けGPUの量子化、再利用可能な生成グラフ |
| Diffusers | Python開発者 | カスタムスクリプトやアプリケーションとの簡単な連携 |
| SGLang | 専用H3サーバー | サービング、マルチGPUデプロイ、API形式の推論 |
| vLLM-Omni | AIインフラストラクチャとマルチモーダルサービング | OpenAI互換の動画サービングと分散デプロイの選択肢 |
H3が実験の段階を超えると、この違いが重要になります。
動画を1本ずつ手作業で制作するクリエイターに必要な構成は、複数のデバイスから1台の中央GPUマシンに生成ジョブを送る家庭やスタジオの構成とは大きく異なります。同じ分離の考え方は、実用的なコンピューティングとストレージの分離ガイドにも見られます。データを管理しているからといって、NASが最も負荷の高い推論まで実行する必要はありません。
MiniMax H3をローカル動画生成APIとして実行できる?
はい。
H3がデスクトップでの実験にとどまらず注目される理由の一つはここにあります。SGLangとvLLM-Omniを使えば、ユーザーがモデルのプロセスに直接アクセスする必要のないサービスとしてH3を提供できます。
たとえば、vLLM-Omni H3 レシピでは、OpenAIスタイルの/v1/videosインターフェースを通じて生成機能を利用できます。
これにより、家庭用AIの構成を変えることができます。
ノートパソコン / スマートフォン / 自動化 ↓ ローカル H3 API ↓ GPUサーバー ↓ 生成された動画 + 音声 ↓ ローカルストレージ
H3をこのように公開すれば、GPUワークステーションを、ユーザーがプロンプトを編集したり、プロジェクトを管理したり、完成したメディアを保存したりするためのマシンにする必要はなくなります。
計算処理とストレージは、それぞれ別のサービスとして運用できます。
MiniMax H3にはどれくらいのストレージ容量が必要?
H3の要件の中で、ストレージ容量は特に過小評価されがちです。
MiniMaxの公式H3リポジトリには、両方のタスク系統、Transformerの重み、Qwenベースのエンコーダー、VAE、Diffusers形式のファイル構成、および関連ファイルが含まれています。すべてをダウンロードすると、リポジトリ全体で数百GBを占めることがあります。
MiniMax H3の統合インデックスによると、元のリポジトリ全体の容量は現在、およそ464 GiBです。元のFL2VAおよびRef2VAのTransformer重みは、それぞれ低精度化や枝刈り版への切り替え前でおよそ62 GiBあります。
H3を実行するために、これらすべてをダウンロードする必要はありません。
適切なホーム環境では、代わりに次のものを分けて保存します。
- アクティブなチェックポイント
- 別の量子化モデル
- FL2VAおよびRef2VAの各バリエーション
- テキストエンコーダー
- VAE
- LoRA
- 参照画像と動画
- 生成済みの出力
- アーカイブ済みのプロジェクト
ローカルAI動画では、従来のデスクトップ向けAIアプリケーションというより、ストレージ主体のワークロードに近くなります。モデル、元のメディア、出力、バックアップをすべて恒久的に保存する場所が必要になったら、より包括的なローカルAIとファイルストレージの構成が役立ちます。
MiniMax H3のモデルはNASに保存すべき?
一部のファイルには有効ですが、推論中に使うすべてのデータに必要とは限りません。
実用的な構成は、ホットストレージと大容量ストレージを分けることです。
GPUマシンのローカルSSDに保存
- 現在使用中のH3チェックポイント
- アクティブなテキストエンコーダー
- 一時的な生成ファイル
- キャッシュ
- 推論時に繰り返し読み込むファイル
NASまたはホームサーバーに保存
- H3の別の量子化モデル
- 古いモデルバージョン
- FL2VAおよびRef2VAのアーカイブ
- 参照メディアライブラリ
- 完成した動画
- ComfyUIのワークフローのバックアップ
- プロジェクト素材
- 学習データまたはLoRAデータセット
この分担なら、モデルを読み込むたびにネットワークストレージが不要なボトルネックになるのを避けつつ、数百GBのAI素材でワークステーションがいっぱいになるのも防げます。
ZimaSpaceのようなホームラボでは、H3を次のように捉えるのが実用的です。GPUノードが生成を行い、ホームサーバーがAIの作業環境を整理して保管します。
MiniMax H3に10GbEネットワークは必要?
実際の生成処理ではありません。アクティブなモデルと入力データをGPUマシンに読み込んだ後のH3の推論は、ほぼ全面的にローカルでの計算とメモリ処理です。
NASとGPUノードの間で、大容量のチェックポイントや高ビットレートのメディアを繰り返し移動する場合、ネットワーク速度が重要になります。
たとえば、20~60GBのモデルを転送するのと、ローカルLLMのワークフローで5MBのドキュメントを読み込むのとでは、大きな違いがあります。
つまり、AI動画によって家庭内ネットワークの高速化の価値は変わります。
- 完成したプロジェクトの保存や、モデルのコピーをたまに行う程度なら、1GbEでも十分です。
- 大容量のモデルファイルを移動する際、2.5GbEなら作業がぐっとスムーズになります。
- NASが複数のAIワークステーション向けの中央モデルライブラリになっている場合や、未処理の動画素材を頻繁に移動する場合、10GbEの価値が高まります。
NASが10GbEだからといって、GPU自体が高速になるわけではありません。高速化するのは周辺のワークフローです。ネットワークがボトルネックになる場合は、実際のファイルサイズ、ストレージのスループット、クライアント、スイッチ、転送頻度に基づいて2.5GbEと10GbEのNASを比較するほうが役立ちます。
MiniMax H3は完全オフラインで動作する?
必要なすべての重み、依存関係、参照ファイルがローカルに揃っていれば、H3-Baseをオフラインのワークフローの一部として使用できます。
これには、ローカルでのテキストから動画への生成、キーフレームを条件とする生成、対応する参照画像駆動型のH3-Baseワークフローが含まれます。
ただし、公式のContext-IRとRegenerate-2Kサービスは現在ホスト型です。これらのコンポーネントに依存するワークフローは、完全なオフラインではありません。
この違いは、機密性の高い参照素材を扱う場合に特に重要です。画像、動画、音声、未公開の商用素材をローカルネットワークの外に一切出さないことが条件なら、公式H3スタック全体がオープンであると想定せず、H3-Baseとローカルでの前処理を軸にワークフローを構築してください。
同じ原則は完全オフラインのローカルAIワークフローにも当てはまります。主要モデルをローカルで実行するだけでは不十分で、認証、前処理、ストレージ、API、その他の必須工程がインターネットに依存していれば、完全にオフラインとは言えません。
MiniMax H3はローカルで2K動画を生成できる?
現時点では、公式の2Kパイプライン全体を使ってローカルで生成することはできません。
H3-Baseは、短辺768ピクセルのベース出力を生成します。MiniMax公式の2K出力にはH3-Regenerate-2Kが使われます。これはベース動画と元のコンテキストを組み合わせて、従来の超解像を行うのではなく、結果を再生成します。
MiniMaxによると、Regenerate-2Kはまだオープンリリースに含まれていません。
H3の出力にローカルのアップスケーリングやコミュニティ製のワークフローを適用できないわけではありません。ただし、こうした方法をMiniMax公式のH3-Regenerate-2Kパイプラインと混同しないようにしてください。
「MiniMax H3 ローカル 2K」などで検索する場合、単純な「はい」か「いいえ」よりも、次の違いを把握するほうが役立ちます。
ローカルでH3を生成できますが、公式のフル2K再生成工程はまだ完全にローカルでは実行できません。
MiniMax H3はApple Siliconで動作する?
ローカル環境の選択肢はNVIDIA GPU以外にも広がっています。
注目すべきコミュニティプロジェクトの一つが、Apple Silicon向けに設計されたMetalネイティブのH3推論実装、h3.cです。現在のエコシステムでは、テキストから動画・音声を生成する機能、最初と最後のフレームを使ったワークフロー、順序付きの参照入力への対応が進められています。
このため、ユニファイドメモリを搭載したMacはH3の実行環境として興味深い選択肢です。十分なメモリを備えたApple Siliconシステムなら、従来の専用VRAMの制約を、より大容量の共有メモリプールで補えるためです。
ただし、Apple Siliconのサポートは、MiniMaxの主要なリファレンス導入経路とは分けて考えるべきです。コミュニティ製ランタイムの進化に伴い、カーネルの成熟度、パフォーマンス、メモリ負荷、機能の同等性は急速に変化する可能性があります。
ローカル版MiniMax H3とクラウド版H3:どちらの構成が適している?
インフラを自分で所有することと利便性のどちらを重視するかによって、答えは変わります。
| 比較項目 | ローカルH3 | ホスト型H3 |
|---|---|---|
| ハードウェア | GPU、RAM、ストレージは自分で用意 | プロバイダーが計算処理を管理 |
| セットアップ | より複雑 | すぐに利用可能 |
| プライベートな元のメディア | H3-Baseのワークフローならローカルに保存可能 | メディアはホスト型サービスに送信される |
| 生成ごとのAPI料金 | ローカル推論ならAPI料金は不要 | 通常は使用量に応じた課金 |
| 電気代 / ハードウェア費用 | 費用がかかる | サービス料金に含まれる |
| ワークフローのカスタマイズ | 高い | プラットフォームによる |
| オフラインでの使用 | H3-Baseなら可能 | いいえ |
| 公式のフル2Kワークフロー | 現時点では完全なローカル実行ではない | ホスト型コンポーネント経由で利用可能 |
AI動画をたまに生成する程度なら、大型GPUを購入するよりも、クラウド推論の方がはるかに経済的な場合があります。
マシンをすでに所有している場合、生成量が多い場合、元のメディアに機密性がある場合、ワークフローを大幅にカスタマイズする必要がある場合、またはH3が同じハードウェアを共有する複数のローカルAIサービスの1つにすぎない場合は、ローカルでの導入がより魅力的になります。
そのため、ローカルAIとクラウドAIのコスト比較では、API料金とGPUの購入価格を単純に比べるのではなく、ワークロードの頻度や、すでに所有しているハードウェアを考慮する必要があります。
ローカルAI動画がホームサーバーの課題になりつつある理由
ローカル言語モデルの実行を通じて、ユーザーは主にRAMとVRAMに注目するようになりました。
動画モデルによって状況が変わります。
本格的なローカル動画環境では、次のものが蓄積されます。
- 数十〜数百GBのモデルの重み
- 同じモデルの複数の量子化バージョン
- 参照画像ライブラリ
- 参照音声
- 元の映像素材
- LoRA
- ワークフローファイル
- 一時的なレンダリングデータ
- 最終動画の複数のバージョン
そのため、長期的な問いはもはやこれだけではありません。
GPUでこのモデルを実行できるか?
ますます問われるのは、
ローカルインフラで、このAIメディアパイプライン全体を保存、提供、整理、バックアップし、繰り返し活用できるだろうか?
ローカルAIワークステーションとホームサーバーが互いを補完し始めるのは、まさにこの段階です。
ブラウザー / 編集用PC │ ▼ ComfyUIまたはローカルAPI │ ▼ GPU計算ノード │ ├── ローカルNVMe上のアクティブなH3モデル │ ▼ NAS / ホームサーバー ├── モデルアーカイブ ├── 参照メディア ├── ComfyUIワークフロー ├── 生成動画 └── バックアップ
GPUは引き続き、高価な計算エンジンです。サーバーは永続的なAI作業環境になります。
これは、AI NASアーキテクチャを理解するうえでも役立ちます。ストレージがGPUワークステーションに取って代わる必要はありません。その価値は、計算負荷の高いAIワークロードを支える安定したデータ、モデル、メディア、インデックス、バックアップのレイヤーを提供することにあります。
MiniMax H3はオープンソースですか?
MiniMaxは、H3をオープンソースとして公開し、H3-Baseモデルの重みと実装を公開しています。ただし、このモデルはApache-2.0やMITのような一般的な寛容なソフトウェアライセンスではなく、MiniMax H3 Community License Agreementの下でリリースされています。
商用展開、再配布、またはH3の製品への統合を行う前に、この違いを確認しておく価値があります。適用される利用規約は、公式モデルのリリースに掲載されています。
オープンなH3-Baseチェックポイントと、H3のサービススタック全体を混同しないことも重要です。H3-Context-IRとH3-Regenerate-2Kは、現時点のオープンリリースには含まれていません。
MiniMax H3をローカルで実行する価値はある?
H3がローカルAIにおいて特に興味深いのは、単なるテキストから動画を生成する別のチェックポイントではないからです。マルチモーダルな参照入力、動画生成、ネイティブなステレオ音声を1つのシステムに統合しています。また、オープンなH3-Baseの重みによって、ローカルコミュニティは十分なアクセスを得られ、独自のランタイム、量子化版、ComfyUIワークフロー、API、ハードウェア固有の最適化を開発できます。
しかし、H3はローカル生成AIの進む方向も示しています。
課題は、もはや1台のPCにモデルをダウンロードするだけではありません。実用的なH3環境には、GPUサーバー、高速なローカルSSD、数百ギガバイトのモデルストレージ、メディアライブラリ、ワークフローのオーケストレーション、リモートアクセス、永続的なネットワークストレージが必要になる場合があります。
一度だけ試すなら、ComfyUIと量子化したH3チェックポイントで十分かもしれません。
長期運用するセルフホスト型AI動画スタックでは、演算処理、使用中のモデルのストレージ、大容量メディアストレージ、ワークフローへのアクセスを分離する構成が、より実用的です。次のオープン動画モデルがランキング首位のH3に取って代わっても、この構成は引き続き役立ちます。
2026年11月更新:短時間のローカル動画生成向けHyperFlow H3 Flash
Video Rebirthは、約31Bのトランスフォーマーを約14Bのパラメーターに圧縮し、動画とステレオ音声の同時生成に対応した、MiniMax H3の派生モデルHyperFlow H3 Flashを公開しました。サンプリングステップは4、6、8から選べ、デフォルトは6です。リリースにはコード、セットアップガイド、ComfyUIワークフローが含まれています。

5.2秒のテキストから動画と音声を生成する例では、提供元はComfyUIのINT8構成で、RTX 5090では83秒、RTX 4090では152秒と報告しています。これらは記載されたワークフローと設定で提供元が測定した値で、引用されているComfyUIの処理時間には書き出し時間が含まれていません。15秒のクリップや、異なる参照モード、別のバックエンドでは、さらに時間がかかる場合があります。公平に比較するには、動画の長さ、解像度、音声、テキストエンコーダー、書き出しをすべて考慮する必要があります。
| 選択肢 | 評価するタイミング | 測定する項目 |
|---|---|---|
| ComfyUI INT8 safetensors | 提供元は、24GBおよび32GBのRTX GPUでの、サポート対象の実行方法と測定結果を公開しています。 | GPUのピークメモリ、一時的なディスク使用量、ワークフローの所要時間、出力品質。 |
| Q4KM GGUF | モデルカードには、9.1 GBの量子化済みTransformerファイルが記載され、GGUF構成も説明されています。 | エンコーダー、VAE、中間テンソルを含むパイプライン全体のメモリ使用量。 |
| より長いクリップ、または複数の参照入力 | 入力に適した、ドキュメント記載のタスクとワークフローを使用してください。 | 生成時間、ピークメモリ、音声同期、フレームの一貫性。 |
ディスク上にモデルファイルが収まるからといって、16GBのGPUでパイプライン全体を実行できるとは限りません。Video Rebirthのリリースには、16GBのGPUでのテスト結果は記載されていません。記録されている最小のクリップから始め、ワークフロー全体を固定して、一度に設定を1つだけ変更してください。
開発者はHyperFlowを派生モデルと明記しており、モデルカードではMiniMax H3 Community License Agreementを参照しています。ライセンスには、地域および用途に関する制限が記載されています。重みをダウンロードまたは使用する前に、ライセンスを読み、お住まいの地域と用途で許可されていることを確認してください。
MiniMax H3のローカル実行に関するよくある質問
MiniMax H3をローカルで無料で実行できますか?
対応ハードウェアがあれば、オープンなH3-Baseの重みを使って、生成ごとのAPI料金を支払わずに実行できます。ただし、ローカル推論にもハードウェア、ストレージ、電気代、メンテナンスの費用がかかります。利用目的に照らして、MiniMax H3 Community Licenseを確認してください。
MiniMax H3にはどれくらいのVRAMが必要ですか?
必要量は一律ではありません。現在、コミュニティの構成は、8GBでNF4とオフロードを使う方法から、12~16GBの量子化ビルド、さらに実用的な24GBのコンシューマー向けGPUでのワークフローまで幅があります。ネイティブ構成や量子化を控えめにした構成では、はるかに多くのメモリが必要です。
MiniMax H3には24GBのVRAMで十分ですか?
はい。現在のプルーニング済み・量子化済みH3構成は24GBのGPUで動作するため、ローカルH3環境として最も現実的なハードウェアクラスの一つです。ただし、実行時にはテキストエンコーダー、VAE、一時テンソル、システムメモリへのオフロードを管理する必要があります。
RTX 4090でMiniMax H3を動かせますか?
はい。ローカルのH3エコシステムには、量子化やメモリ節約の手法を用いた、RTX 4090を1基搭載する構成があります。4090は、元のBF16スタック全体を一度にVRAMへ読み込めるカードではなく、量子化したH3を動かすプラットフォームとして考えるべきです。
MiniMax H3はVRAM 8GBで動作しますか?
DiffSynth-Studioは、必要VRAMの下限を8GBとするNF4ワークフローを提供しています。オフロードに大きく依存するため、高速な本番環境向けというより、最低限動作させるための構成と考えるのが適切です。
MiniMax H3はComfyUIで使えますか?
はい。ComfyUIは、テキストから動画、画像やキーフレームから動画、参照素材を使った生成の各ワークフローに対応しており、メモリ要件を抑えるよう設計されたローカル量子化モデルの選択肢もあります。
MiniMax H3は音声をローカルで生成できますか?
はい。H3-Baseは動画とネイティブステレオ音声を同時に生成します。ローカルのワークフローでは、生成された音声の潜在表現をデコードするために、別途H3 Audio VAEを使用します。
MiniMax H3では参照動画や音声を使用できますか?
はい。Ref2VAモデルは、画像、動画、音声の参照を組み合わせて使用できます。公式のモデル仕様では、長さの制限内で、最大9枚の画像、3本の動画クリップ、3本の音声クリップを使用でき、参照ファイルの合計は12個までです。
MiniMax H3で完全オフラインの2K動画を生成できますか?
現時点では、MiniMaxの公式2Kパイプライン全体を通じてはできません。H3-Baseはローカルで実行できますが、公式のH3-Regenerate-2Kステージは現在ホスト型です。サードパーティ製のローカルアップスケーリングとH3-Regenerate-2Kは区別してください。
MiniMax H3用にどれくらいのディスク容量を確保すべきですか?
最適化された単一のワークフローなら、リポジトリ全体の一部だけで済む場合もあります。しかし、FL2VAとRef2VAの両方、複数の量子化モデル、エンコーダー、VAE、LoRA、参照メディアを試すユーザーは、すぐに数百ギガバイトを使用する可能性があります。使用中のチェックポイントは高速なローカルストレージに保存し、使用頻度の低いアセットは大容量ストレージにアーカイブしてください。
MiniMax H3のモデルをNASに保存できますか?
はい。NASは、モデルのアーカイブ、参照メディア、ワークフロー、出力、バックアップの保存に便利です。頻繁に読み込むチェックポイントは、通常、GPUマシンに接続したローカルNVMeドライブに保存し、必要に応じてNASと同期したり、NASから復元したりするのがおすすめです。
MiniMax H3はインストール後もインターネット接続が必要ですか?
H3-Baseは、モデルファイルとソフトウェア依存関係をダウンロードすれば、ローカルで実行できます。MiniMaxのホスト型Context-IRや公式のRegenerate-2Kサービスを使用するワークフローでは、引き続きネットワーク接続が必要です。
H3にはFL2VAとRef2VAのどちらが適していますか?
テキストから動画を生成する場合や、最初と最後のフレームを指定するワークフローにはFL2VAを使用します。より多様な画像、動画、音声の参照が必要な生成にはRef2VAを使用します。基本的なテキスト条件付けやキーフレーム条件付けだけであれば、より大規模な複数チェックポイント環境を維持する必要はほとんどありません。
MiniMax H3をホームネットワーク上の複数のデバイスに提供できますか?
はい。SGLangやvLLM-Omniなどのサービングフレームワークを使えば、H3をネットワークAPI経由で利用でき、ノートパソコン、ワークステーション、自動化アプリケーションから中央のGPUサーバーにジョブを送信できます。実際の同時実行数やスループットは、GPUメモリとサービングの設定によって異なります。
テクノロジー&AIハブ
続きを読む

DSpine搭載Qwen3.8-27B:ドラフトモデルによる推論の高速化
Qwen3.8-27B向けのTencentのDSpineドラフトモデルを理解し、ドラフトの受け入れ率を解釈して、エンドツーエンドのSGLang比較を設計しましょう。

Linumの2万1,000ドルのテキスト画像生成実験:20億パラメータのモデルで生成できるもの
Linumの2B P-JiT研究リリースが示す内容、画像トークンの圧縮方法、そして出力や学習コストに関する主張を理解するために必要な背景をご紹介します。

64 GBのRAMだけで、GPUなしにDeepSeek V4 Flash 284Bを本当に動かせるのか?
カスタム量子化、メモリ予算、デコード速度、実験の限界など、報告されている64 GBのCPUのみで実行したDeepSeek V4 Flashの実行結果を詳しく見てみましょう。




