MiniMax H3をローカルで実行する：ハードウェア、ComfyUI、セルフホスト型AI動画環境

はい、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つの主要部分で構成されています。

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は1つに決まっていません。精度、量子化、モデルのプルーニング、オフロード、解像度、ワークフロー、ランタイムによって答えが大きく変わるためです。

ネイティブモデルは大規模です。H3は330億パラメータの高密度H3-Omni-Transformerを使用し、エンコーダーには事前学習済みのQwen3-VL-32Bの重みを使用します。MiniMaxによると、トランスフォーマーのパラメータの約130億はAdaLN関連の分岐に属しており、その出力は推論用に事前計算してキャッシュできますが、それでも一般的な非量子化のコンシューマーモデルのメモリフットプリントをはるかに上回ります。

そのため、ローカルエコシステムではプルーニングと量子化が大きく重視されています。

MiniMaxが管理するH3統合インデックスには現在、8GBのDiffSynth NF4構成から、12～16GBの量子化ビルド、24GBのComfyUI構成まで、ローカルでの実行方法が掲載されています。

これは、8GB GPUが優れたH3マシンだという意味ではありません。

ローエンドでは、不足しているVRAMをGPUメモリとシステムメモリの間でモデルコンポーネントを移動させて補う必要があります。これにより問題は「モデルを読み込めるか」から「生成のたびにどれだけ待てるか」へと変わります。

最低VRAMと実用VRAMは、別の問題です。そのため、高速なSSDやNASでGPUメモリ不足を補えると考える前に、計算、メモリ、ストレージのボトルネックを分けて考えると役立ちます。

RTX 4090のような24GB GPUでMiniMax H3は動くのか？

はい。24GBは現在、本格的な自宅H3環境を構築するうえで、特に興味深いターゲットの1つです。

コミュニティ製およびComfyUI向けのビルドでは、拡散モデルが十分に削減されており、プルーニングされたINT8 H3トランスフォーマーを約20GBに収められます。テキストエンコーダーは別途量子化され、必要に応じてモデルコンポーネントがオフロードされます。

重要なのは、H3が単一の重みファイルではないという点です。

完全な生成ワークフローには、次のものが必要になる場合があります：

• H3拡散トランスフォーマー
• Qwen3-VLベースのテキスト／ビジョンエンコーダー
• 動画VAE
• オーディオVAE
• オプションのLoRAまたは高速化モデル
• 参照メディア
• 一時的な潜在表現およびデコード用メモリ

そのため、「19GBのモデル」だからといって、24GBのGPUに5GBを残してきれいに収まるとは限りません。

ランタイムのメモリ管理は、チェックポイントのサイズとほぼ同じくらい重要です。

MiniMax H3は16GBまたは12GBのVRAMで動くのか？

はい。ただし、これはさらにコミュニティによる量子化の領域に踏み込むことになります。

現在のエコシステムには、プルーニングされたGGUFおよびNVFP4拡散モデルと、大幅に量子化されたQwen3-VLエンコーダーの組み合わせがあります。これによりH3を12～16GBクラスに収められますが、システムメモリとデータ転送の重要性が増します。

これは、頻繁な本番作業に理想的な構成というより、H3を利用可能にする方法と考えるのが適切です。

短い動画をたまに生成するだけなら、そのトレードオフは十分受け入れられるかもしれません。H3を数十本の動画を生成する自動コンテンツワークフローの一部として使うなら、モデルをVRAMに収めることより、スループットのほうがはるかに重要になります。

MiniMax H3は本当に8GBのVRAMだけで動くのか？

現在は8GBで動かす方法がありますが、この数字には文脈が必要です。

DiffSynth-Studioには、VRAMの下限を8GBとするNF4推論構成があります。ただしこのレベルでは、大規模なオフロードによって、ワークロードの大部分がGPU上に常駐しなくなります。

したがって、8GB構成で重要な問いは次のことではありません：

「H3は起動するか？」

それは次のとおりです：

「生成にかかる時間は、自分のやりたいことに対して許容できるか？」

H3のテストやワークフローの学習、たまに短い動画を生成する用途なら、8GBでの実験は有益です。ローカルで動画を繰り返し生成するなら、VRAMが多いほど使い勝手が大きく向上します。

FL2VAとRef2VA：どのMiniMax H3モデルを使うべきか？

H3-Baseは、タスク別に最適化された2つのバリアントとしてリリースされています。適切なものを選ぶことで、ストレージとワークフローの複雑さの両方を削減できます。

H3-Base-FL2VA

FL2VAは、テキストとキーフレームを基盤とした生成に重点を置いています。

従来のテキストから動画、または画像から動画への生成が目的なら、通常は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オフロードにより、フル精度でのデプロイと比べてメモリフットプリントを大幅に削減できると説明されています。

実用的なローカル環境は次のようになります。

1. ComfyUIをインストールまたは更新します。
2. MiniMax H3のテキストから動画、画像から動画、または参照画像から動画へのワークフローを選択します。
3. 対応する拡散モデルをダウンロードします。
4. 互換性のあるH3テキストエンコーダーをダウンロードします。
5. 動画用および音声用のVAEを追加します。
6. まずは768pクラスの短い生成から始めます。
7. GPUメモリとシステムRAMの使用量を両方監視します。
8. その後で、長さ、解像度、またはワークフローの複雑さを増やします。

この順序が重要です。長いクリップ、最大数の参照素材、高解像度、積極的な拡張機能を同時に使用しながらH3をデバッグすると、失敗の原因がモデル、メモリ、ノード、ワークフロー自体のどれなのかを見分けるのが難しくなります。

H3におけるComfyUI対Diffusers対SGLang対vLLM-Omni

最適なランタイムは、ベンチマークスコアよりもH3の使用方法に左右されます。

この違いは、H3が実験の段階を超えると重要になります。

動画を一度に1本ずつ手動で制作するクリエイターと、複数のデバイスから1台の中央GPUマシンに生成ジョブを送信する家庭やスタジオとでは、必要なアーキテクチャが大きく異なります。同じ分離は、計算処理とストレージの分離に関する実用的なガイドにもすでに見られます。NASがデータを所有しているからといって、最も負荷の高い推論まで実行する必要はありません。

MiniMax H3はローカル動画生成APIとして実行できますか?

はい。

これが、デスクトップでの実験にとどまらないH3の魅力の1つです。SGLangとvLLM-Omniを使えば、ユーザーがモデルのプロセスを直接操作するのではなく、H3をサービスとして利用できます。

たとえば、vLLM-Omni H3レシピは、OpenAI形式の/v1/videosインターフェースを通じて生成機能を公開します。

これにより、別のホームAIアーキテクチャが可能になります:

ノートパソコン / スマートフォン / 自動化 ↓ ローカルH3 API ↓ GPUサーバー ↓ 生成された動画 + 音声 ↓ ローカルストレージ 

このようにH3を公開すれば、GPUワークステーションは、ユーザーがプロンプトを編集したり、プロジェクトを管理したり、完成したメディアを保存したりするマシンである必要はなくなります。

計算処理とストレージは、別々のサービスにできます。

MiniMax H3にはどれくらいのストレージが必要ですか?

ストレージは、H3の要件を過小評価しやすい項目の1つです。

公式のMiniMax H3リポジトリには、両方のタスクファミリー、トランスフォーマーの重み、Qwenベースのエンコーダー、VAE、Diffusersのレイアウト、サポートファイルが含まれています。すべてをダウンロードすると、完全なリポジトリの容量は数百ギガバイトに達する可能性があります。

MiniMax H3の統合インデックスによると、完全なオリジナルリポジトリの容量は現在およそ464 GiBです。オリジナルのFL2VAおよびRef2VAトランスフォーマーの重みは、それぞれ小さい精度やプルーニング済みのバリアントに移行する前で、およそ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は待ち時間や手間を大幅に減らします。
• 10GbEがより有効になるのは、NASを複数のAIワークステーションで共有するモデルライブラリとして使う場合や、大容量の動画アセットを常に移動する場合です。

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 local 2K」のような検索では、単純なイエス・ノーの回答よりも、この区別のほうが有用です。

ローカルH3生成は利用できますが、公式の完全な2K再生成ステージはまだ完全にローカル化されていません。

MiniMax H3はApple Siliconで実行できる？

ローカルエコシステムはNVIDIA GPU以外にも広がっています。

注目すべきコミュニティプロジェクトの1つは h3.cApple Silicon向けに設計されたMetalネイティブのH3推論実装です。現在のエコシステムでは、テキストから動画・音声への変換、最初と最後のフレームを使ったワークフロー、順序付き参照入力のサポートが追跡されています。

このため、統合メモリを備えたMacは興味深いH3プラットフォームです。十分に大容量のApple Siliconシステムなら、従来のディスクリートVRAMの制約を、より大きな共有メモリプールに置き換えられるからです。

ただし、Apple Siliconのサポートは、MiniMaxの主要なリファレンス展開経路とは分けて考えるべきです。コミュニティ製ランタイムの進化に伴い、カーネルの成熟度、パフォーマンス、メモリ負荷、機能の同等性は急速に変化する可能性があります。

ローカルMiniMax H3とクラウドH3：どちらのセットアップが適している？

インフラの所有権を重視するか、利便性を重視するかによって答えは異なります。

たまにAI動画を生成するだけなら、大型GPUを購入するよりもクラウド推論のほうがはるかに経済的です。

マシンがすでに存在する場合、生成量が多い場合、ソースメディアが機密性の高いものである場合、ワークフローに大幅なカスタマイズが必要な場合、またはH3が同じハードウェアを共有する複数のローカルAIサービスの1つにすぎない場合、ローカル導入はより魅力的になります。

そのため、ローカルAIとクラウドAIのコストは、API料金とGPUの購入価格を単純に比較するのではなく、ワークロードの頻度とすでに所有しているハードウェアを中心に評価すべきです。

ローカルAI動画がホームサーバーの課題になりつつある理由

ローカル言語モデルの実行を通じて、ユーザーは主にRAMとVRAMについて考えるようになりました。

動画モデルが状況を変えます。

本格的なローカル動画環境では、次のものが蓄積されます：

• 数十GB、あるいは数百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にとって特に興味深いのは、単なる別のテキストから動画へのチェックポイントではないからです。マルチモーダル参照、動画生成、ネイティブステレオ音声を一つのシステムに統合しており、オープンなH3-Baseの重みによって、ローカルコミュニティはH3を中心に新しいランタイム、量子化、ComfyUIワークフロー、API、ハードウェア固有の最適化を構築するための十分なアクセスを得られます。

しかしH3は、ローカル生成AIが向かっている方向も示しています。

課題は、単に1台のPCへモデルをダウンロードすることではなくなりました。実用的なH3環境には、GPUサーバー、高速なローカルSSD、数百GBのモデルストレージ、メディアライブラリ、ワークフローオーケストレーション、リモートアクセス、永続的なネットワークストレージが必要になる場合があります。

一度きりのテストであれば、ComfyUIと量子化H3チェックポイントだけで十分な場合があります。

長期的にセルフホストするAI動画スタックでは、コンピュート、アクティブなモデルストレージ、大容量メディアストレージ、ワークフローへのアクセスを分離する構成の方が有用です。次のオープン動画モデルがランキングのトップでH3に取って代わった後も、この構造は役立ち続けます。