MiniMax 日前發表新一代全模態影音生成模型 MiniMax-H3（即外界慣稱的 Hailuo 3.0），並於 8 月 3 日將權重上架 Hugging Face。它最大的賣點是「一次生成、原生有聲」，可以在單一 diffusion transformer 同時去噪影像與立體聲音訊 latent，不需要另掛音訊模型後製配音。
官方部署指南鎖定的是資料中心級硬體，SGLang cookbook 驗證清單上是 B200、B300、H200、H100、MI300X 與 RTX 5090，vLLM 官方 recipe 的最佳實務則以 4×B300 為基準，NVIDIA DGX Spark（GB10）則不在官方首波的驗證清單上。
那麼，一台小型的桌上型 AI 工作站、128GB 統一記憶體的 DGX Spark，到底跑不跑得動這顆模型的官方原版全權重？權重釋出後 48 小時內，我們在自己的 DGX Spark 上完成實測，答案是可以，但路徑跟官方文件寫的完全不同。 CyberQ 實作並記錄，以及說明官方原本預設的三條路在 GB10 上前兩條都是死路。
測試結果重點
單台 DGX Spark 可以跑 MiniMax-H3 官方 FL2VA 全權重（磁碟約 135 GiB），成功生成帶立體聲的 MP4。
可行路徑是 vLLM-Omni + 線上動態 FP8 量化 + SM121 相容性 patch（社群專案 joeynyc/MiniMax-H3-DGX-Spark），不是官方文件的 BF16 或 CPU offload 路線。
模型載入約需 89 GiB 統一記憶體，生成期間 worker 佔用約 93 GB，這台機器的 128GB 幾乎被吃滿，跑圖時不能執行其他大模型容器。
測試一支 768×448、24fps 的 T2VA 短片端到端約 160 秒。
想要更輕量的日常產出，CyberQ 也測試過，用 ComfyUI + Comfy-Org 量化 repack（約 42.5 GB）的共四個模型檔案的量化版本仍是更實際的選擇，全權重 FP8 路線的價值在於更接近官方品質基準。
MiniMax-H3 是什麼？為什麼值得在本地跑
H3 是 MiniMax Hailuo 影片產品線的第三代，架構上是 33.1B 參數的單流（single-stream）全模態 diffusion transformer，搭配 Qwen3-VL-32B 作為文字與視覺編碼器。它把過去拆散在「文生影片、圖生影片、首尾幀、主體參考、動作參考、影片編輯、配音」等多個專家模型的任務，全部收進同一個預訓練框架，讓文字、圖片、影片、音訊在同一個 context 內混合輸入，一次可生成最長 15 秒、24fps、原生 32kHz 立體聲的影片。
開源釋出的權重分成兩個獨立 partition：
| Partition | 對應任務 | 條件輸入 |
|---|---|---|
| FL2VA | t2va（純文字）、fl2va（首／尾幀） | 文字，或文字＋首尾幀圖片 |
| Ref2VA | ref2va（全參考） | 文字＋圖片／影片／音訊參考 |
一個 server 行程只能載入一個 partition。本文實測以 FL2VA 為主，它同時涵蓋文生影片與圖生影片兩種最常用情境。
以 BF16 計，單一 partition 的組件規模是，DiT 66.3 GB、Qwen3-VL 編碼器 51.5 GB、video VAE 約 10 GB、audio VAE 約 0.6 GB，合計約 128.4 GB。看到這個數字，只有單台的 DGX Spark 使用者應該已經知道不可行，得有不同模型的取捨。
官方三條路，GB10 上兩條暫時是死路
路線一：SGLang Diffusion。 這是 MiniMax model card 的示範引擎，但 cookbook 的驗證硬體清單不含 GB10，sgl-kernel 在 sm_121a 上需自行重編，diffusion extra 在該架構上仍需要驗證。
路線二：vLLM-Omni 官方單卡路徑（BF16 + CPU offload）。 官方 recipe 的單 GPU 配方靠 --enable-cpu-offload 讓編碼器與 DiT 不同時駐留 GPU，前提是「有足夠的系統 RAM 放被 offload 的組件」。這在獨立 VRAM＋系統 RAM 的工作站上成立；但 GB10 是統一記憶體架構，CPU 端與 GPU 端是同一個 128GB 池，offload 省不到。128.4 GB 的權重加上 OS 與 activation，帳面上就過不了。實測也印證了這點，BF16 在 Spark 上直接因記憶體餘裕不足失敗。
路線三：量化。 官方 recipe 明載「FP8 quantization is not supported yet」，transformer 端有已知 blocker，SGLang 的線上 FP8 也只在 B200／B300 驗證。INT8 checkpoint 則在 SM121 上撞到不支援的 kernel。表面上，量化這條路官方也還沒完全，近期應該就都會陸續和社群補完補強。
三條路看似不容易，所以我們選擇的突破口來自社群。
突破口：SM121 相容性 patch + 線上 FP8
有一位開發者 joeynyc 發布了 MiniMax-H3-DGX-Spark 專案，以官方 vllm/vllm-omni:minimax-h3 ARM64 映像為基底，加上一組聚焦的相容性 patch，讓線上動態 FP8 在 SM121 上真正跑起來。 patch 做了四件事：
在原生參數載入前，先正規化 checkpoint 中分組儲存的 QKV 權重列。
保留 vLLM 原生 weight-loader 簽名，讓線上 FP8 的載入流程不被破壞。
把 FP8 activation quantizer 綁定到 SM121 支援的原生 CUDA 運算，繞開會失敗的 compiled wrapper。
AdaLN 的線性層權重轉 FP8 後，activation 仍維持 BF16，保住數值敏感路徑。
另外，FlashAttention-4 的 CuTe 變長 kernel 在 SM121 上處理 H3 的 packed shape 會失敗，因此改用 PyTorch SDPA。六個數值敏感的 projection 層保持不量化。整套以 Docker Compose 打包，pinned base image digest，附 preflight 檢查與 fail-closed 測試。
實測過程
環境
| 項目 | 規格 |
|---|---|
| 硬體 | NVIDIA DGX Spark（GB10 Grace Blackwell、SM121、128GB 統一記憶體、aarch64） |
| 權重 | MiniMaxAI/MiniMax-H3 官方 FL2VA partition，hf download 取得，磁碟約 135 GiB |
| 執行環境 | joeynyc/MiniMax-H3-DGX-Spark（vllm-omni:minimax-h3 pinned image + SM121 補丁） |
| 量化 | 線上動態 FP8 |
部署流程只需把 .env 的 MINIMAX_H3_MODEL_DIR 指向 FL2VA 子目錄（絕對路徑），compose 會以唯讀方式 bind 進容器固定位置，宿主機權重放哪都不影響，以 CyberQ 的案例來說，這台機器的 SSD 只有 1TB，因此選擇把模型放在 QNAP NAS 上跑，透過10GbE 區域網路或 100GbE 區域網路來加速掛載，雖然要等待一段時間，但空間是值得的，整套官方二套工作流程的權重檔案總共要四百多 GB 容量呢：
bash
git clone https://github.com/joeynyc/MiniMax-H3-DGX-Spark.git
cd MiniMax-H3-DGX-Spark
cp .env.example .env && vi .env # 指定 FL2VA 路徑、確認授權旗標
chmod 600 .env
make preflight && make build && make up
make status # 冷啟動約 9 分鐘
make smoke && make verify # 生成 + ffprobe 驗證影音雙 streamCyberQ 設定的範例在 QNAP NAS 上，mount 過的目標目錄為
/mnt/nas/AIModels/MiniMax/MiniMax-H3
–local-dir /mnt/nas/AIModels/MiniMax/MiniMax-H3
執行下載模型權重指令：
hf download MiniMaxAI/MiniMax-H3 \
–include “model_index.json” “modular_model_index.json” “FL2VA/” “Ref2VA/” \
• 服務網址：http://0.0.0.0:8188 http://localhost:8188
• 結合 NAS 路徑：
• Input：/mnt/nas/comfyui/input
• Output：/mnt/nas/comfyui/output
• Models：/mnt/nas/models
preflight 有三個容易碰到的門檻要解決，我們在 cold start 前 MemAvailable 必須 ≥ 105 GiB（所以得先停掉既有在跑的 ComfyUI 等其他容器）、FL2VA/model_index.json 與 FL2VA/transformer/ 必須存在、預設只綁 127.0.0.1 的 fail-closed 網路策略。
參考測試資料
| 項目 | 實測1 | 實測2 |
|---|---|---|
| 模型載入 | 89.17 GiB / 532 秒 | 89.17 GiB / 657 秒 |
| 生成期間 worker 佔用 | 約 92,957 MiB | 約 95,205 MiB |
| T2VA 端到端（768×448） | 155 秒 | 185 秒 |
| 輸出格式 | H.264 + AAC 立體聲、24fps | H.264 + AAC 立體聲、24fps |
載入速度部分，89 GiB 的權重載入走本機 NVMe 約 9 分鐘，若權重放在 NAS 經 NFS 掛載直接餵，載入時間會再拉長，但還是可接受的範圍。建議可 rsync 一份到本機 NVMe，兩邊都可以跑測試。
與 ComfyUI 量化路線的對比
在全權重路線打通之前，我們已經先用 ComfyUI 路線在 NVIDIA DGX Spark GB10 上驗證過 H3，採用官方合作的 Comfy-Org 釋出 repack 權重（FL2VA pruned INT8 convrot 21.0 GB + Qwen3-VL-32B NVFP4 AWQ 文字編碼器 15.7 GB + 雙 VAE，合計約 42.5 GB）搭配 ComfyUI 原生節點，同樣能在單台 Spark 生成有聲影片。兩條路線的定位差異：
| ComfyUI 量化路線 | vLLM-Omni FP8 全權重路線 | |
|---|---|---|
| 權重來源 | Comfy-Org repack（pruned INT8 + NVFP4） | MiniMax 官方原版 checkpoint |
| 總佔用 | 約 42.5 GB，餘裕充足 | 載入 89 GiB、峰值約 93 GB，逼近極限 |
| 品質 | pruned 版靠預計算 adaLN 曲線表再砍 40% 體積，離基準較遠 | 線上 FP8，僅敏感層保留 BF16，較接近官方品質 |
| 介面 | 節點式工作流，適合創作迭代 | OpenAI 相容 /v1/videos API，適合服務化與自動化 |
| 適用情境 | 日常產出、快速試 prompt | 品質基準對照、正式管線、程式化批次生成 |
CyberQ 認為，創作用 ComfyUI，基準與服務化用 FP8 全權重。兩者可以共存在同一台 Spark 上，只是不能同時啟動。
延伸採用兩台 Spark 的模型平行
同一位作者還有 GB10 雙機版本 MiniMax-H3-2x-DGX-Spark，以 Ray 在兩台 Spark 各放一個 rank，DiT 走 two-way Ulysses 序列平行，NCCL collectives 跑在 RoCEv2 直連上。這是真正的模型平行，每一個去噪步驟都拆到兩台機器，不是兩個獨立任務。實測同一請求從單機 154.956 秒降到 64.9–68.8 秒（約 2.3 倍），warm 狀態搭配 cuDNN attention 與 regional compile 可到 46.6 秒，再開有損的 Cache-DiT 平衡檔可壓到 30.6 秒。
對於已經擁有二台 Spark 用戶來說當然用這樣來跑了，至於考慮添購第二台 Spark 的使用者，這組資料值得參考。
授權注意事項
MiniMax-H3 採 MiniMax Community License，目前明文排除美國、歐盟、英國與南韓，並限制模型輸出在適用地域之外的使用與展示。台灣不在排除清單內，但商用（尤其對外展示生成內容）前仍應詳讀 model card 的授權條款。
本文引用的兩個社群專案皆以 Apache-2.0 授權其程式碼，且刻意不含任何模型權重與生成媒體。
多方實作
CyberQ 認為，MiniMax-H3 全權重在 DGX Spark 上「官方說不行、社群 48 小時內做到」的過程，是本地 AI 生態一個很好的縮影，GB10／sm_121 這類高階消費級 Blackwell 架構不在任何方案的 day-0 驗證矩陣裡，但統一記憶體的容量優勢擺在那裡，缺的往往只是幾個聚焦的 kernel 相容性修正。對 128GB 統一記憶體的機器來說，89 GiB 的載入量與 93 GB 的執行峰值意味著這已經接近單機極限，H3 大概就是這一代 Spark 能跑的最大先進影音生成模型了。
下一步我們有同事計畫做同 seed 的品質對比：ComfyUI pruned INT8、標準 INT8 與 vLLM-Omni FP8 三種路線各生成同一組 prompt，比較 SSIM 與主觀觀感，屆時再另文分享。
常見問題（FAQ）
Q：DGX Spark 跑 MiniMax-H3 全權重需要什麼前置條件？ A：官方 FL2VA checkpoint（磁碟約 135 GiB）、Docker 與 NVIDIA Container Toolkit、啟動前至少 105 GiB 可用統一記憶體，以及確認你所在地域符合 MiniMax Community License。
Q：為什麼不能直接用官方的 BF16 或 CPU offload 指令？ A：單一 partition 的 BF16 組件合計約 128.4 GB，等於 Spark 的全部記憶體。而 GB10 的 CPU 與 GPU 共用同一個統一記憶體池，CPU offload 無法省下任何總量，因此官方單卡路徑在此架構上並無法實現。
Q：FP8 量化會犧牲多少品質？ A：此路線僅將可量化的線性層轉為線上動態 FP8，六個數值敏感的 projection 與 AdaLN activation 維持 BF16，理論上比 pruned INT8 更接近官方基準，精確的量化品質對比（SSIM／PSNR）我們將於後續文章以同 seed 實測呈現。
Q：一支影片要跑多久？ A：參考資料為 768×448、24fps 的文生影片端到端約 155 秒。更高解析度（如 1344×768、50 步）在單台 Spark 上需以數十分鐘計，雙 Spark 模型平行約可縮短至一半上下。
Q：ComfyUI 路線和這條路線衝突嗎？ A：不衝突，可共存於同一台機器，但因記憶體峰值逼近 128GB，兩者不能同時執行。日常創作建議用 ComfyUI 量化版，需要官方品質基準或 API 服務化時再切換到 FP8 全權重。
