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秒だった。

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

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で、生成はすべて画像入力なし（テキストのみ）で実行している。

動かすのに必要なもの

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

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

導入手順

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

MiniMax H3のノードはComfyUI v0.30.0（2026年8月3日公開）で追加された。それ以前のバージョンでは該当ノードが存在せず、ワークフローを読み込んでも赤いエラー表示になる。ポータブル版なら同梱の更新用バッチ、git管理なら該当タグへの切り替えとrequirements.txtの再適用で上げられる。

更新後、ノード検索で「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は12345、解像度とフレーム数のみ条件ごとに変更）。

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に固定した。ステップ数を変えた場合の画質と時間の関係は測っていない。試行の段階では少ないステップで構図を確かめ、決まってから増やす進め方もある。

初回は時間がかかる

モデルをディスクから読み込む初回は、読み込み済みの状態より時間がかかる。864×480の場合、初回は80.1／81.9／82.1秒（3回）で、読み込み後の66秒前後に対しておよそ15秒の差があった。連続して生成する場合、この差は最初の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自身が記録する実行時間を用いている。

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

増え方は一定ではない。0.21MPから0.41MPは+19.5秒だが、0.41MPから0.64MPは+50.7秒で、傾きが2倍以上変わる。0.41MP以上の3点はほぼ一直線（1MPあたり約216秒）に乗り、最も軽い0.21MPだけがその直線より約24秒高い側にある。軽い条件ほど、解像度に依存しない固定的な処理の比重が効いている形である。

画素数との対応で見ると、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乗の中間の伸び方になる。解像度を上げた場合も空間方向のトークンが同じ系列に加わるため、程度の差はあれ同じ傾向が現れる。フレーム数のほうが伸び方が急なのは実測どおりだが、解像度側だけが比例で済むわけではない。なお本記事はモデル内部の計算量そのものを測ったわけではなく、確認したのは生成時間の挙動である。

本当の制約はVRAMではなくシステムRAM

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

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

この数字は環境要件として直接効いてくる。VRAMが16GBあってもシステムRAMが32GBの環境では、この構成のH3は成立しない。OSと常駐アプリの分を差し引いた上で40GiB以上を1プロセスが確保する必要があるため、実質的には64GB以上が前提になる。ローカルAI全般でのRAM消費の考え方はローカルAIにシステムRAMは何GB必要かで扱っている。

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

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

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

中央値で比較するとINT8はFP8のおよそ1.86倍の時間がかかった。5回とも重複しない範囲に分かれており、測定のばらつきで説明できる差ではない。VRAM使用量とファイルサイズはほぼ同じなので、この環境で16GBのカードに載せる目的ならFP8版を選ぶ理由がある。

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

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

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

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

差は1.45〜2.09倍にとどまり、PCIeの8倍差とは一致しない。2枚のVRAM帯域の比（960GB/s対448GB/s＝約2.14倍）や演算性能の比（FP32で56.3TFLOPS対23.7TFLOPS＝約2.38倍）と同じ桁の値である。今回はリンク幅を変えた対照測定も転送量の直接計測も行っていないため、どちらが効いているかまでは分離できない。言えるのは、PCIeの8倍差がそのまま生成時間の差としては現れなかったということで、少なくともこの負荷域では接続帯域が支配的な要因にはなっていないと読める。外付けGPUでの2枚運用についてはAI用途にGPUは2枚必要かでも別のワークロードを測っている。

負荷が軽い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が足りていない可能性が高い。この構成はプロセス単体で約44 GiBを確保するため、32GB環境では読み込み段階で行き詰まる
• 最初の1本だけ遅い：モデルの読み込みが加わるためで、864×480ではおよそ15秒の差だった。2本目以降は短くなる
• 他の生成処理と同時に動かした場合：VRAM・RAMとも余裕が薄いため、同じGPUで別のワークフローを並行させると割り当てが競合しうる。本記事の測定は他の生成処理を止めた状態で行っている

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

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

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

また、多くの条件は1回の測定値である。複数回記録したのは864×480の読み込み後（FP8・INT8とも各5回）と初回読み込み（3回）で、それ以外は単発の値として扱う必要がある。

導入前に確認したい点

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

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

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

よくある質問

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では1ステップあたりの転送量が増えて生成時間が延びる方向に働くと考えられる。ただし実測していないため、動作の可否は判断できない。

システムRAMは何GB必要か

本記事の構成ではComfyUIプロセス単体で約44 GiBを確保した。OSと他のアプリケーションの分を加えると、32GBでは足りない。64GB以上が実質的な前提になる。

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

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

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

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

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

生成時間だけで見ればFP8が明確に速く、ファイルサイズもほぼ同じである。ただし本記事は出力品質を比較していないため、品質を含めた判断材料は提供していない。

この記事の測定のあと、生成そのものを短縮するコミュニティ製のTurbo LoRAが登場した。同じ機材・同じワークフローでステップ数だけを変えて測った結果はMiniMax H3 Turbo LoRAは何倍速い？｜ComfyUIで4〜8ステップ・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 リリースノート