DGX Spark 1台でMiniMax H3は動く？第三者の公開測定を検証
CHATGPT / AIChatGPTなどの生成AIを活用して運営・記事制作・更新を行っています。制作方針
MiniMax H3をDGX Spark 1台・2台で動かした第三者の公開測定を検証。FP8化とSM121互換修正、公式範囲内の4秒動画、範囲外の2秒smoke test、メモリ余裕、ライセンス制約を整理します。
先に結論
joeynyc氏の公開レポートには、MiniMax H3のFL2VA版をDGX Spark 1台で動かし、音声付き動画を生成・decodeした測定結果が記録されています。ただし、公式BF16 checkpointをそのまま載せる構成ではなく、online dynamic FP8、SM121向け互換patch、cuDNN attention、regional compileを組み合わせた結果です。公式仕様の4秒下限より短い検証用2秒requestのwarm平均は、full computeで約111.4秒、近似的なCache-DiT利用時は約80.6秒でした。動作報告は確認できますが、短時間で大量生成できる速度ではありません。
確認日時: 2026年8月9日（Asia/Tokyo）
検証区分: MiniMax公式model cardとlicense、第三者が公開した実行code・測定方法・集計値・検証scriptを照合した公開実測レポートの資料監査です。当サイト自身がDGX Sparkで実行した結果ではありません。生成media、frame、raw request logは公開repositoryに含まれず、出力を当サイトが独立確認したものではありません。
対象: MiniMax H3 Base FL2VA、DGX Spark 1台および2台、vLLM-Omniの固定runtime
適用外: Ref2VA、公式のhosted H3-Context-IR、2K再生成、別revision、別promptでの速度・品質保証
MiniMax H3は映像と音声を同時生成するモデル
MiniMax公式model cardによると、H3はtext、画像、動画、音声を理解し、4〜15秒・24fpsの動画と32kHz stereo音声を生成するomni-modal systemです。今回の実測対象であるH3 Base FL2VAは、textだけのT2VAに加え、最初・最後のframeを0〜2枚与えるFL2VAに対応します。
ただし、公開weightだけで公式serviceの全機能を再現できるわけではありません。複雑な入力を整えるH3-Context-IRと、768p結果を2Kへ作り直すH3-Regenerate-2Kは初期公開に含まれず、APIを使う構成です。H3 Baseの初期公開版もfull attentionで推論し、公式が説明するsparse attention実装は今後の公開予定とされています。
DGX Spark 1台の検証条件
根拠にしたMiniMax-H3-DGX-Spark公開repositoryは、集計結果に加えてcontainer image、patchの目的、固定request、測定・検証scriptを公開しています。一方、生成mediaとraw request logは含まれません。公開レポートが記載する主な条件は次のとおりです。
| 項目 | 公開された条件 |
|---|---|
| hardware | DGX Spark 1台、GB10、ARM64、SM121、128GB級統合memory |
| OS / driver | Linux 6.17.0-1029-nvidia / NVIDIA 580.173.02 |
| runtime | vllm/vllm-omni:minimax-h3をdigest固定 |
| PyTorch / CUDA | 2.11.0+cu130 / CUDA 13.0 |
| model | MiniMax H3 FL2VA、disk上で約135GiB |
| quantization | online dynamic FP8、精度に敏感な6つのprojection / output moduleは量子化対象外 |
| full-compute設定 | online FP8のままcuDNN attention + regional compile、Cache-DiTなし |
| service | localのOpenAI互換video API、出力をFFmpegで完全decode |
modelは13個のshardを読み込み、model memoryは89.1659GiBと記録されました。公開summaryではmodel loadが519〜543秒、最終imageの測定ではserviceのcold readinessが約589〜592秒です。つまり、起動してhealth checkが通るまでおよそ9〜10分を見込む構成です。
本稿のfull computeは、denoising stepをCache-DiTで近似省略しないという意味です。precisionはBF16へ戻らず、online FP8のままです。
検証用2秒動画はwarm状態で約81〜111秒
1台構成の測定記録では、同じpromptとseedを使い、768×448、24fps、2秒、20 inference stepsのT2VA requestを比較しています。これは公式model cardが示す4秒下限より短いruntime検証用smoke testで、正式な4秒生成の所要時間ではありません。最初のrequestはcompileやcache初期化を含むため、比較には後続2回のwarm平均が使われました。
| 1台のprofile | warm client平均 | 測定区分 | host peak used memory | peak host swap | 結果 |
|---|---|---|---|---|---|
| SDPA + eager、cacheなし | 152.911秒 | optimization sweepのbaseline | 113.92GiB | 4.04GiB | decode成功、OOM 0 |
| cuDNN + regional compile、cacheなし | 111.373秒 | 最終imageで再確認 | 113.01GiB | 3.98GiB | decode成功、OOM 0 |
| 上記 + Cache-DiT 0.10 | 80.579秒 | 最終imageで再確認 | 113.09GiB | 3.73GiB | decode成功、OOM 0 |
全出力はH.264の56frame、24fps、AAC-LC 32kHz stereo音声を含み、完全decodeに成功したと報告されています。2秒指定に対するcontainer上の長さは2.357秒でした。同じ最終image同士では、Cache-DiTがfull computeより27.65％短時間でした。memoryとswapはhost全体を1秒間隔で採った値で、swapをcontainerだけへ帰属させることはできません。
Cache-DiTは途中の計算結果を近似再利用するため、losslessな高速化ではありません。後述する4秒・50 stepsのmatched testでは、同じseedのfull-compute出力に対してvideo SSIM 0.881、PSNR 26.61dBでした。映像は破綻せず、音声もほぼ同じと報告されていますが、服の色や姿勢、足の位置には目視できる差がありました。
1344×768・4秒・50 stepsでは約19〜40分
より重いquality確認では、1344×768、24fps、4秒、50 steps、同一prompt・seedを固定しています。結果は次のとおりです。
| 1台のquality workload | client時間 | engine時間 | host peak used / swap | 出力 |
|---|---|---|---|---|
| full compute | 2,379.370秒（約39分39秒） | 2,301.339秒 | 112.22 / 3.71GiB | 107frame、4.482秒 |
| Cache-DiT 0.10 | 1,159.493秒（約19分19秒） | 1,091.862秒 | 112.99 / 3.87GiB | 107frame、4.482秒 |
いずれも映像とstereo音声のdecode、HTTP応答、model ID、OOMなしと報告されています。ただし、各profile 1回だけのmatched testであり、別promptや15秒動画へ比例計算できるbenchmarkではありません。MiniMax H3を1台で完走させた公開記録としては有用ですが、制作本数を見積もるには手元のprompt、長さ、解像度、stepsで再測定が必要です。
BF16のままではなくFP8と互換修正で載せた
128GBあるから公式checkpointがそのまま動いた、という実績ではありません。公開された失敗記録と採用判断は次の順です。
| 試した経路 | 確認された問題 | 採用判断 |
|---|---|---|
| BF16 + offload | 統合memory使用量が118〜119GiBへ近づき、request用余裕が不足 | 1台構成では不採用 |
| online INT8 | SM121でdispatch_scaled_mmがINT8非対応 | 不採用 |
| 最初のonline FP8 | weight loader、activation quantizer、AdaLNで互換問題 | 限定patchで修正 |
| FlashAttention-4 | H3のpacked sequence形状でCuTe kernel compile失敗 | SDPA / cuDNNへ変更 |
| online FP8 + cuDNN | load、生成、音声付きMP4 decodeに成功 | full-compute既定値に採用 |
最終のfull-compute再確認では、peak used memory 113.01GiB、minimum available memory 8.68GiBでした。Cache-DiT構成でもminimum availableは8.60GiBです。余裕は狭く、repositoryは起動前に110GiB以上のavailable memoryを推奨し、preflightは105GiB未満で停止します。別の大型modelとの同時実行を前提にできる余白ではありません。
DGX Spark 2台では同じ動画を分散生成できた
2台構成の公開repositoryでは、Rayが各Sparkへ1 rankを配置し、Ulysses sequence parallelismとNCCL / RoCEv2で同じ1本の動画を分散生成しています。2台で別々の動画を1本ずつ作る構成ではありません。このcustom executorの検証範囲は2台×1 GPU、同期request、batch size 1で、並行productionやupstreamの正式対応を示すものではありません。
| 2台構成・同じ検証用2秒smoke request | cold readiness | warm request | denoising時GPU稼働率 |
|---|---|---|---|
| full compute | 588.98秒 | 46.574秒 | 96％ / 95％ |
| Cache-DiT 0.15 | 584.91秒 | 30.578秒 | 96％ / 94％ |
両nodeでcontainer restartとOOMは0、Rayは2 node・2 GPUを正常と判定し、H.264映像とAAC音声の完全decodeも通過したと報告されています。この2秒設定も公式の4秒下限を下回るruntime smoke testです。1台の最終測定と同じrequest形状ですが、別の分散imageと実行回なので、表の差をそのまま一般的な2台scale率とは扱えません。それでも、2台のGB10が同じdenoising trajectoryへ参加し、1台より短い時間で完了したmulti-node動作記録ではあります。
再現するときの最短ルート
公開repositoryの既定値を使う場合も、modelとruntimeのrevisionを固定し、いきなり長い動画を生成しないことが重要です。modelは現在ungatedですが、download前にlicenseを確認してください。約135GiBのFL2VA checkpointに加えてcontainer build、cache、生成物を保存できる空きstorageが必要です。Docker Compose、NVIDIA Container Runtime、FFmpegも事前に用意します。大まかな流れは次のとおりです。
hf download MiniMaxAI/MiniMax-H3 \
--revision bfc8ed0353f5a9733be73e6b2c98ec0948195b86 \
--include "model_index.json" "FL2VA/*" \
--local-dir ./MiniMax-H3
git clone https://github.com/joeynyc/MiniMax-H3-DGX-Spark.git
cd MiniMax-H3-DGX-Spark
git checkout --detach 7bd148f133e95733bb4994350cb34869a243440c
cp .env.example .env
# MINIMAX_H3_MODEL_DIR=/absolute/path/to/MiniMax-H3/FL2VA
# HF_CACHE_DIRとlicense acknowledgmentも.envへ設定
make preflight
make build
make up
make status
# license上実行・表示できる地域だけで実行
make smoke
make verifymake statusでhealthとmodel IDを確認し、短いsmoke requestをFFmpegで完全decodeしてから、解像度・長さ・stepsを1項目ずつ増やします。APIは既定で127.0.0.1だけにbindされます。外部公開へ変更する場合はAPI keyとnetwork制限が必要で、認証なしのままInternetへ直接出さないでください。第三者へserviceを提供する場合はsecurity設定だけで完了ではなく、licenseが求める利用規約、安全対策、通報・対応手順も確認します。
ライセンスは実行前に地域まで確認する
MiniMax H3 Community Licenseは、2026年8月2日付の初期版で、米国、EU、英国、韓国をApplicable Territoryから除外しています。model本体だけでなくoutputの利用・複製・表示にも地域制限があります。対象外地域での利用は本Community Licenseでは許諾されず、modelをdeployする場合はMiniMaxへ別licenseを問い合わせる必要があります。日本は列挙された除外地域に含まれませんが、利用場所、公開先、商用条件、Acceptable Use Policyを含め、実行時点の原文を必ず確認してください。
Acceptable Use Policyは、生成物をpublic環境へ出す場合にmachine-generatedであることを明確かつ目立つ形で示すよう求めています。対象となるcommercial product / serviceの年商が2,000万米ドルを超える場合は事前の書面許諾が必要で、commercial UIには「MiniMax H3」の目立つ表示も必要です。
今回参照したrepositoryのApache-2.0は実行codeに対するlicenseで、MiniMax H3のweightやoutputへは適用されません。本記事もH3の生成動画を転載せず、測定条件と数値のみを紹介しています。
DGX SparkでMiniMax H3を選ぶ判断
今回の公開レポートから言えるのは、DGX Spark 1台が単なる容量見積もりではなく、FP8化したH3 Base FL2VAをloadし、音声付きMP4を最後まで生成したと報告されたことです。約135GiBのdisk上BF16 checkpointをload時にonline FP8化し、runtimeは89.1659GiBのmodel memoryを報告しました。128GB搭載機でgenerationまで完走する一方、host全体では約3〜4GiBのswapも観測され、containerへの帰属は不明です。
一方、4秒の1344×768動画にfull computeで約40分かかるため、速度だけを目的にDGX Sparkを新規購入する根拠にはなりません。すでにSparkを持ち、CUDA / ARM64 / SM121の互換性検証、local API化、model並列化を学びながら大容量video modelを試す用途には魅力があります。日常的な制作では、必要な1日あたり本数、許容待ち時間、近似cacheの品質差、2台化の費用まで含めて判断してください。
よくある質問
DGX Spark 1台だけでMiniMax H3は動きますか？
FL2VA版をonline dynamic FP8へ量子化し、公開repositoryのSM121互換patchを使った構成で、映像とstereo音声を含むMP4を生成・完全decodeした測定結果が報告されています。生成mediaやraw logを当サイトが独立確認したものではなく、公式BF16 checkpointを無修正で1台に載せた結果でもありません。
15秒・2K動画もlocalだけで作れますか？
公開weightだけで2Kを完結する構成は示されていません。H3 Baseのlocal出力は768pで、2Kはhosted H3-Regenerate-2K APIを使います。15秒は公式4〜15秒の範囲内ですが、対応範囲内の1台測定は4秒1組だけです。仕様外の2秒smoke値から15秒へ外挿できません。
Cache-DiTを常に有効にすべきですか？
時間は短くなりましたが、full computeと同じ映像にはなりません。まずcacheなしをreferenceとして保存し、同じprompt・seedでSSIMやPSNRだけでなく動画全体を目視比較します。構図、人物、商品形状などの再現性を優先する場合はfull computeを基準にしてください。
ComfyUIでも同じ速度になりますか？
同じ速度とは限りません。同じvLLM-Omni serviceへComfyUIをfrontendとして接続する場合はbackend条件を維持できますが、ComfyUI native workflowや別runtimeでは今回の数値を転用できず、別測定が必要です。
まとめ
第三者の公開レポートには、MiniMax H3をDGX Spark 1台へloadしただけでなく、T2VAの映像・音声生成とFFmpeg完全decodeまで通した測定結果が記録されています。実用構成の鍵はFP8化とSM121向け互換修正で、仕様外の2秒smoke requestはwarm状態で約111秒、近似cache利用時は約81秒でした。公式範囲内の1344×768・4秒・50 stepsは約19〜40分であり、容量面では成立しても速度には明確なtrade-offがあります。
再現時は、license、checkpoint、container digest、patch、prompt、seed、解像度、stepsを固定し、短いcanaryから始めてください。DGX Sparkの台数別のmodel容量を先に確認したい場合は、DGX Spark 1〜4台モデル比較、GB10搭載機の違いはDGX Spark互換機比較も参考になります。
参考資料
- MiniMaxAI：MiniMax H3 model card（license記載のrelease / license date 2026年8月2日、model card 8月6日更新、8月9日確認）
- MiniMax H3 Community License Agreement（2026年8月2日、8月9日確認）
- joeynyc：MiniMax H3 on one NVIDIA DGX Spark（commit
7bd148f、2026年8月9日確認） - Measured one-Spark results（2026年8月9日確認）
- joeynyc：MiniMax H3 on two DGX Sparks（public-release acceptance 2026年8月4日、8月9日確認）
- vLLM-Omni：MiniMax H3 recipe（2026年8月7日更新、8月9日確認）
- NVIDIA：DGX Spark Hardware Overview（2026年8月3日更新、8月9日確認）
