vLLM-OmniによるMiniMax H3 FastH3のリアルタイムサービング

MiniMax H3がリアルタイムでサービング可能になりました。vLLM‑Omniのシステム全体の最適化とFastVideoの4ステップ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は、常駐パイプライン全体を再構築します：

  • 長シーケンスアテンションと通信 – パックされたシーケンスの改良によりパディングを排除し、ランクローカルの境界がデータ移動を制限し、Fast UlyssesがNCCL SymmetricMemoryを使用して余分なall‑to‑allの再配置を回避します。
  • DiTオペレータの融合 – RMSNorm、RoPE、変調、正規化、およびSwiGLUがより少ないカーネル起動に融合され、フォワードごとのオーバーヘッドが削減されます。
  • 並列および融合VAEデコード – タイル分割されたビデオVAEデコードは、融合されたQ/K正規化とSwiGLUを使用して8つのGPUに分散され、音声VAEも同じパスに従います。
  • GPU出力の準備、転送、およびMP4 – デコードされたFP32フレームは一度だけ連続したuint8に変換され、ピン留めされたD2H/IPCを介して転送され、インターリーブされたRGBバッファを再構築することなくH.264に供給する永続的な並列コンバータでエンコードされます。

これらの変更により、同じ8× B300ハードウェアでの完全な応答のレイテンシが82.239 s（Diffusers）から56.917 sへと低下し、**30.8 %**の削減（1.445倍の高速化）を実現しました。

FastH3: 支配的なDiTループを削減する4ステップのスチューデントモデル

FastVideoのFastH3は、ベースのMiniMax H3スケジュールの49回のDiTフォワードを、5つのシグマ位置に対するわずか4回のフォワードに置き換えます。この成果物はロード時に融合されたスチューデントモデル（フルランクのデルタと低ランクのアダプタ）であり、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レプリカが、シード 1101で10秒、1344×768、24 FPSのリクエストを処理します。

B300でのリアルタイムFastH3の結果

8つのGPUを搭載したB300ノードで測定されたクリティカルパスは以下の通りです：

ステージ 時間 (s)
エンコーダ (FP32→uint8) 0.052
DiT合計 (4フォワード) 5.532 (1フォワードあたり1.383)
ビデオ + 音声VAEデコード 1.247
転送およびCPU MP4マルチプレクス 1.749
クリーンなエンドツーエンド 8.678 – 8.710

生成された10秒のビデオの再生時間は10.125 sであり、クライアントのリアルタイムファクター（RTF）は0.86となります。つまり、完全なMP4は再生されるよりも速く準備されます。

再生時間のスイープ

リクエストされた再生時間 クリーンなE2E (s) クライアントRTF リアルタイムファクター
5 s (124 フレーム) 4.602 – 4.396 0.889 – 0.849 1.125 – 1.177
10 s (243 フレーム) 8.678 – 8.710 0.857 – 0.860 1.163 – 1.167
15 s (362 フレーム) 14.177 – 14.059 0.940 – 0.932 1.064 – 1.073
6回の実行すべてがRTF ≤ 1.0を満たしており、5秒、10秒、15秒のビデオ全体でリアルタイム生成が確認されました。

品質と互換性に関する注意事項

  • FastH3は専用のT2VAスチューデントモデルであり、FL2VA、Ref2VA、またはリクエスト時のLoRAアダプタはサポートしていません。
  • スチューデントモデルの重みはロード時に融合されるため、FastH3はDistributed Layerwise Offload (DLO)やエンコーダのディスアグリゲーションと組み合わせることはできません。
  • メディアの検証チェックには、正しいフレーム数、H.264ビデオ、32 kHzステレオAAC音声、ゼロでないビデオ分散、および音声RMSが含まれます。同じシードでの繰り返し実行において、バイト単位で同一の出力が観察されました。
  • マッチしたベースとFastH3のマルチシード品質比較は保留中であり、パリティの主張は行われていません。

FastH3プロファイルを超えたスケーリング

vLLM‑Omniは以下もサポートしています：

  • Distributed Layerwise Offload (DLO) – わずかなレイテンシのコストでGPUメモリを削減するために、ホストメモリからDiTレイヤーをストリーミングします。
  • ディスアグリゲーションされたエンコーダ – 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
リクエスト時のアダプタの切り替え、または4フォワードの高速化を伴うFL2VA 別個のTurboサービス (LoRAベース)
T2VAのために検証された最低レイテンシ セクション 4で説明されている専用のFastH3サービス
メモリ制約のあるデプロイメント DLOまたはディスアグリゲーションされたエンコーダを備えたベースのH3

新たな正確性とレイテンシの評価を行わずに、FastH3をDLO、VSAバリアント、またはエンコーダのディスアグリゲーションと組み合わせしないでください。

ライセンスと法的な考慮事項

MiniMax H3はMiniMax H3 Community License Agreementの下でリリースされています。商業またはホスティングされたデプロイメントを計画している事業者は、領域、帰属、収益、許容される使用、およびセーフガードの条項について法務顧問と確認する必要があります。

参考文献

Sources