MiniMax H3 FastH3 使用 vLLM-Omni 實時服務

MiniMax H3 現在可實時提供服務：vLLM‑Omni 的系統級優化搭配 FastVideo 的四步驟 FastH3 學生模型，將端到端延遲降低至低於媒體持續時間，進而在 8× B300 GPU 節點上實現不到 10 秒的 MP4 生成。

為何 MiniMax H3 服務是系統級問題

MiniMax H3 可從文字、圖片、影片與音訊參考生成同步的影片與音訊，過程中需經過大型 Qwen3‑VL 編碼器、長序列音訊影片 DiT、獨立的影片與音訊 VAE，最後再構建 H.264/AAC MP4。每個階段都有獨特的運算、記憶體與配置需求，因此僅優化 DiT 仍會在編碼器、VAE 解碼、資料傳輸與 MP4 多路複用階段留下大量延遲。

vLLM‑Omni 中的系統級優化

vLLM‑Omni 重構了整個常駐流程：

  • 長序列注意力與通訊 – 結構化序列優化移除了填充，rank‑local 边界限制了資料移動，而 Fast Ulysses 使用 NCCL SymmetricMemory 避免額外的 all‑to‑all 重排。
  • 融合的 DiT 操作 – RMSNorm、RoPE、調製、歸一化與 SwiGLU 被融合為更少的核函式啟動，降低每次前向傳播的開銷。
  • 平行且融合的 VAE 解碼 – 影片 VAE 解碼以分塊方式分散至八張 GPU，並融合 Q/K 歸一化與 SwiGLU；音訊 VAE 也遵循相同路徑。
  • GPU 輸出準備、傳輸與 MP4 構建 – 解碼後的 FP32 幀僅轉換一次為連續的 uint8，透過 pinned D2H/IPC 傳輸，並由持續平行轉換器直接輸入 H.264，無需重建交錯的 RGB 缓衝區。

這些變更將完整回應延遲從 82.239 秒（Diffusers）降低至相同 8× B300 硬體上的 56.917 秒，減少 30.8 %（1.445× 加速）。

FastH3：四步驟學生模型降低主要的 DiT 迴圈

FastVideo 的 FastH3 將基礎 MiniMax H3 排程中的 49 次 DiT 前向傳播，減少至僅五個 sigma 位置上的四次前向傳播。其成果是載入時融合的學生模型（完整秩差異加上低秩適配器），由 vLLM‑Omni 進行驗證、分片與服務，並與優化的注意力、VAE 及 MP4 路徑並行運作。

FastH3 服務設定

CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6,7 \
VLLM_WORKER_MULTIPROC_METHOD=spawn \
VLLM_OMNI_VIDEO_SYNC_TIMEOUT=1800 \
vllm serve "$H3_MODEL" --omni \
  --host 127.0.0.1 --port 8095 --trust-remote-code \
  --task-type fl2va --served-model-name MiniMaxAI/MiniMax-H3 \
  --num-gpus 8 --usp 8 --ring 1 --ulysses-a2a-permute \
  --text-encoder-tp-size 8 \
  --vae-patch-parallel-size 8 --vae-parallel-mode tile --vae-use-tiling \
  --diffusion-attention-backend TRTLLM_ATTN \
  --lora-path "$FASTH3_DIR/dense-datafree/adapter_model.safetensors"

單一 FastH3 副本可處理 10 秒、1344×768、24 FPS 的請求，種子為 1101。

B300 上的實時 FastH3 結果

在八 GPU 的 B300 節點上測量的關鍵路徑如下：

階段 時間（秒）
編碼器（FP32→uint8） 0.052
DiT 總計（4 次前向） 5.532（每次 1.383）
影片＋音訊 VAE 解碼 1.247
傳輸與 CPU MP4 多路複用 1.749
乾淨的端到端 8.678 – 8.710

生成的 10 秒影片播放持續時間為 10.125 秒，因此客戶端實時因子（RTF）為 0.86，即完整 MP4 比播放還快完成。

持續時間掃描

請求持續時間 乾淨 E2E（秒） 客戶端 RTF 實時因子
5 秒（124 幀） 4.602 – 4.396 0.889 – 0.849 1.125 – 1.177
10 秒（243 幀） 8.678 – 8.710 0.857 – 0.860 1.163 – 1.167
15 秒（362 幀） 14.177 – 14.059 0.940 – 0.932 1.064 – 1.073
所有六次執行均滿足 RTF ≤ 1.0，確認在 5、10 與 15 秒影片上均實現實時生成。

質量與相容性注意事項

  • FastH3 是專為 T2VA 設計的學生模型；不支援 FL2VA、Ref2VA 或請求時間 LoRA 適配器。
  • FastH3 無法與 Distributed Layerwise Offload（DLO）或編碼器拆分併用，因為學生模型的權重在載入時已融合。
  • 媒體驗證檢查包括正確的幀數、H.264 影片、32 kHz 立體 AAC 音訊、非零影片變異數與音訊 RMS。相同種子的重複執行中觀察到位元完全相同的輸出。
  • 匹配的基礎模型 vs FastH3 多種子品質比較尚未完成；不宣稱品質對等。

超越 FastH3 設定的擴展

vLLM‑Omni 也支援：

  • 分散式層級卸載（DLO） – 從主機記憶體流式傳輸 DiT 層，以降低 GPU 記憶體需求，僅帶來輕微延遲成本。
  • 拆分式編碼器 – 將 Qwen3‑VL 編碼器作為獨立階段運行，允許獨立擴展編碼器容量。
  • 量化路徑 – 在線 FP8 可減少峰值 HBM 約 39 %，並帶來 5 % 的延遲提升；SVDQuant（NVFP4 W4A4）可用，但缺乏融合核函式。
  • 稀疏與量化注意力 – TRTLLM_ATTN SAGE FP8 與 Skip‑Softmax 在基礎 H3 流程上可提供最高 1.24× 加速，品質影響（LPIPS）輕微。

這些選項與 FastH3 互相獨立，需分別評估；未納入報告的 FastH3 延遲數值中。

生產建議

需求 推薦設定
完整任務覆蓋（T2VA、FL2VA、Ref2VA） 使用 vLLM‑Omni 系統級堆疊的基礎 MiniMax H3
請求時間適配器切換或四次前向速度的 FL2VA 建立獨立的 Turbo 服務（基於 LoRA）
T2VA 的最低已驗證延遲 如第 4 節所述的專用 FastH3 服務
記憶體受限部署 基礎 H3 搭配 DLO 或拆分式編碼器

切勿 在未重新驗證正確性與延遲的情況下，將 FastH3 與 DLO、VSA 變體或編碼器拆分混合使用。

授權與法律考量

MiniMax H3 依據 MiniMax H3 社群授權協議釋出。計畫進行商業或託管部署的運營者，必須與法律顧問共同審閱地域、署名、收入、可接受使用與保障條款。

參考資料

Sources