vLLM の Muse Spark Open デイ 0 サポート: 816B-A42B MoE、DSpark 投機的デコード、LoRA RL

vLLM と Meta Superintelligence Labs は、長期的なエージェント型コーディングワークフロー向けに構築された、合計 816B パラメータ、トークンあたり 42B アクティブなオープンウェイトのスパース混合エキスパートモデルである Muse Spark Open に対するデイ 0 サポートをリリースしました。このリリースが重要なのは、これまでで最も高性能な米国のオープンウェイトモデル(Muse Glimmer 30B の生成元となったモデル)を、ウェイトが公開されたその日に、Nvidia、AMD、TPU ハードウェア上の本番稼働対応サービングスタックで利用できるようにするためです。

Muse Spark Open とは

Muse Spark Open は、長期的なエージェント型コーディングワークフロー向けに設計された、オープンウェイトのスパース混合エキスパート(MoE)モデルです。vLLM はこれをこれまでで最も高性能な米国のオープンウェイトモデルと説明し、Muse Glimmer 30B がこれから蒸留されたと述べています。

主な仕様は次のとおりです。

アーキテクチャ: 合計 816B パラメータ、トークンあたり 42B アクティブ、1M コンテキストウィンドウ。
量子化: Meta はモデルを BF16 と NVFP4 の両方でリリースしました。MXFP4 ウェイトは AMD からリリースされました。
マルチモーダル: Muse Glimmer で使用されているのと同じ Perception Encoder によるネイティブな画像およびビデオ認識。オーディオサポートも追加されています。
並列処理: Nvidia と AMD の両方で Tensor 並列処理と Pipeline 並列処理。Nvidia では Expert 並列処理(EP)、TEP、DEP、PD 分離。TPU での初期サポートも利用可能です。
投機的デコード: vLLM チームによってトレーニングされた DSpark ドラフトモデル。CUDA と ROCm の両方でサポートされ、SPEED ベンチでテストされています。

実行方法

両ベンダー向けのプリビルドイメージが利用可能です。

Nvidia: vllm/vllm-openai:muse-spark-open
AMD: vllm/vllm-openai-rocm:muse-spark-open

このモデルは、PR #61879 のコードがレビューおよびマージされた後にのみ、ナイトリーピアスホイールで利用可能になります。vLLM によると、これには通常約 1 週間かかります。

推奨されるサービングコマンドは Rust フロントエンドを使用し、エキスパート並列処理、1M トークンの最大モデル長、Muse 推論およびツール呼び出しパーサー、DSpark 投機的デコードを有効にします。

# Rust フロントエンド推奨
エクスポート VLLM_USE_RUST_FRONTEND=1

vllm serve meta-models/Muse-Spark-Open-816B-A42B-NVFP4 \
    --tensor-parallel-size 8 \
    --enable-expert-parallel \
    --max-model-len 1048576 \
    --reasoning-parser muse \
    --tool-call-parser muse \
    --enable-auto-tool-choice \
    --speculative-config '{"method":"dspark","model": "Inferact/Muse-Spark-Open-DSpark","num_speculative_tokens":7,"draft_sample_method":"probabilistic","rejection_sample_method":"block","enable_adaptive_verification":true}'

プレーンテキストリクエストでは、reasoning_effort を xhigh に設定できます。

curl http://localhost:8000/v1/chat/completions \
    -H 'Content-Type: application/json' \
    -d '{
      "model": "meta-models/Muse-Spark-Open-816B-A42B-NVFP4",
      "messages": [{"role": "user", "content": "このモジュールをリファクタリングしてください。"}],
      "reasoning_effort": "xhigh"
    }'

マルチモーダルリクエストでは、単一のメッセージ内で画像、ビデオ、オーディオのコンテンツ部分を受け入れます。

curl http://localhost:8000/v1/chat/completions \
   -H 'Content-Type: application/json' \
   -d '{
     "model": "meta-models/Muse-Spark-Open-816B-A42B",
     "messages": [{"role": "user", "content": [
       {"type": "image_url", "image_url": {"url": "https://example.com/screenshot.png"}},
       {"type": "video_url", "video_url": {"url": "https://example.com/demo.mp4"}},
       {"type": "audio_url", "audio_url": {"url": "https://example.com/clip.wav"}},
       {"type": "text",      "text": "ここで何が起こっていますか、そしてそれはいつですか?"}
     ]}]
   }'

モデルアーキテクチャ: 816B パラメータの所在

Muse Spark Open は、テキストデコーダーを含む合計 816B パラメータの混合エキスパートモデルであり、それに加えて 2B のビジョンエンコーダーと小さなオーディオエンコーダーを備えています。デコーダーには 62 層あり、そのすべてが混合エキスパート層です。

ウェイトの予算は次のように分類されます。

パーツ	サイズ
層あたり 256 エキスパート	799 B
アテンション	13.5 B
MoE 潜在投影	4.2 B
埋め込みおよび出力層	3.3 B
ビジョンタワー(別)	1.9 B

アーキテクチャは Muse Glimmer に類似しており、理解しておく価値のある 3 つの設計上の選択肢があります。

サンドイッチ正規化

ほとんどのデコーダーは、各ブロックの前に 1 つの正規化層を配置し、x + F(norm(x)) を提供します。Muse Spark Open は、Muse Glimmer と同様に、ブロックの前後に 1 つずつ正規化層を配置します("ブロックを挟んでサンドイッチの 2 枚のスライスのように")。x + post_norm(F(norm(x))) を提供します。

潜在 MoE

すべての MoE 層には、その層の 256 すべてのエキスパートが共有する 2 つの追加マトリックスがあります。コードではこれらをプーラーとアンプーラーと呼びますが、どちらも通常の意味でのプーリングではなく、両方とも次元を圧縮および拡張する学習された投影です。プーラーは 8192 × 4096 のマトリックスで、各トークンの幅をエキスパートに到達する前に半分にし、アンプーラーはその後で全幅を復元します。したがって、エキスパートは 8192 ではなく完全に 4096 で動作し、2 つのエキスパート投影層で必要なパラメータ数を実質的に半分にします。

ハイブリッドスライディングウィンドウおよびフルアテンション

層は、フルアテンションとスライディングウィンドウアテンション(SWA)を 4 つの繰り返しサイクルで交互に繰り返します。3 つの層は 2048 トークンウィンドウに注目し、4 番目の層はコンテキスト全体を見ます。サイクルはスタックの最後に固定されているため、最後の層は常にフルアテンション層になります。62 層全体で、46 の狭い層と 16 の広い層が得られ、狭い層は最近の KV のみを保持します。1M トークンでは、これによりキャッシュは全フルアテンションが必要とする量のちょうど 4 分の 1 強になり、1M コンテキスト長を手頃なものにしています。

ビジョンおよびオーディオエンコーダー

Muse Spark Open は、Muse Glimmer と同じ Perception Encoder、つまり画像を正方形にリサイズするのではなくネイティブ解像度で読み取る 2B パラメータのタワーを使用します。ビデオも同じエンコーダーを通ります。フレームは、読み込み時に一連のサンプリングされたビデオフレームとしてサンプリングされ、タイムスタンプがプロンプトにトークン化されます。

オーディオは 24 kHz の生の波形として読み取られ、1920 サンプルごと(80 ミリ秒)が一連の変換を通じて 1 つのトークンになります。オーディオエンコーダー全体はわずか 118M パラメータです。ビデオのオーディオトラックは処理されません。モデルにクリップの画像と音声の両方を与えるには、ビデオと抽出されたオーディオを同じリクエスト内の 2 つの別々のコンテンツ部分として送信します。

DSpark 投機的デコード

vLLM 上で Muse Spark Open の推論を高速化するために、チームは DSpark を使用してスペキュレーターをトレーニングしました。DSpark は、ブロック拡散を使用して 1 回のパスで最大 7 つのドラフトトークンを提案する投機的デコードアルゴリズムです。信頼性ベースのスケジューリングは、投機的デコードが従来は収穫逓減をもたらすような大きなバッチサイズでも、大幅な高速化を維持するのに役立ちます。

スペキュレーターはまた、Muse Spark Open のスライディングウィンドウアテンションを使用して、1M トークンのコンテキストでもドラフトを軽量に保ちます。これらの選択により、幅広いバッチサイズとコンテキスト長にわたる本番稼働ワークロードに適しています。

DSpark はサーバー起動時に次のコマンドで有効になります。

--speculative-config '{"method":"dspark","model": "Inferact/Muse-Spark-Open-DSpark","num_speculative_tokens":7,"draft_sample_method":"probabilistic","rejection_sample_method":"block","enable_adaptive_verification":true}'

ハードウェアバックエンド: Nvidia、AMD、TPU

Nvidia

Nvidia チームは、FlashInfer と vLLM 全体で Muse Spark Open の推論を改善しました。融合正規化、ゲーティング、および残差カーネル。テンソル並列通信と RMSNorm を使用した融合 MoE ファイナライゼーション。新しい低レイテンシ BF16 GEMM 実装とコンパイルオーバーヘッドの削減。融合 MNNVL コレクティブによる TEP プーラー/アンプーラーシャーディング。norm の FP32 出力を供給する TF32 ルーター GEMM。データ移動、ハードウェアサポート、ランタイム信頼性の改善。

AMD

AMD チームのサポートにより、Muse Spark Open は AMD Instinct MI355X GPU で FP8 と MXFP4 の両方の量子化形式で動作し、推論パフォーマンスとデプロイ効率が向上します。ROCm は現在、Tensor 並列処理と Pipeline 並列処理の両方をサポートしています。

TPU

vLLM は、TorchTPU 上に Muse Spark Open サポートを追加しました。コードへのアクセスには、vLLM または Google への連絡が必要です。チームはまた、Muse Spark Open 用のメガカーネルを構築しました。DSpark 投機的デコードを受理長 6 で使用すると、4 つの TPU v7 チップで毎秒 650 トークン以上、8 つのチップで毎秒 960 トークン以上に達します。投機的デコードなしでも、それぞれ毎秒 270 トークン以上と 350 トークン以上を提供します。

vLLM での強化学習

vLLM は、Muse Spark Open で LoRA RL をデイ 0 からサポートし、Verl FSDP2 をトレーナーとしてロールアウトエンジンとして機能します。vLLM は元の NVFP4 チェックポイントに LoRA アダプターを適用して提供します。トレーナーは同じウェイトの BF16 逆量子化で実行され、アダプターのみを更新します(ランク 32、アルファ 64)。これには、アテンション、MoE 潜在投影、およびすべてのルーティングされたエキスパートが含まれます。また、ロールアウトの MoE ルーティング(R3)を再生し、各ステップ後にアダプターのみが vLLM に同期されます。

チームは、16 個の GB300 GPU で DAPO-Math-17K を使用して GRPO を 150 ステップトレーニングし、ステップごとに 32 プロンプトのそれぞれに対して 8 つの応答をサンプリングし、応答ごとに最大 4K トークンを使用しました。AIME-2024 の精度(mean@8)は、トレーニング前の 0.56 から実行終了時には 0.85 に向上しました。実行全体を通じて、トレーナーと vLLM のログ確率の間の k3 KL は 2×10⁻⁴ 付近で維持されました。詳細は Verl PR #8257 で入手できます。vLLM エコシステムでは、Titan RL も vLLM をロールアウトエンジンとして使用して、デイ 0 の RL サポートを提供します。

誰が構築したか

vLLM は、デイ 0 サポートに対して Meta Superintelligence Labs と vLLM コミュニティ、DSpark スペキュレーターのトレーニングと TPU 統合に対して Inferact、ハードウェア最適化に対して NVIDIA と AMD に感謝の意を表します。

発表に記載されているコントリビューター:

Inferact: Jie Li、Zifeng Mo、Zixi Qi、Jeff Ma、Ziqi Zhao、Dakai An、Ao Shen
Meta: Beto de Paola、Sidhartha Reddy Potu
Nvidia: Cyrus Chang、Duncan Moss、Marek Pikulski、Seong Hee Lee
AMD: Andy Luo、Hongxia Yang、Haichen Zhang

このリリースが重要な理由

デイ 0 サポートとは、サービングパス、量子化形式、並列処理戦略、投機的デコード、RL ロールアウト統合がすべて、ウェイトが公開された瞬間に存在することを意味します(数週間後ではありません)。816B パラメータの MoE に 1M トークンのコンテキストウィンドウを持つモデルにとって、ハイブリッドアテンション、潜在 MoE 圧縮、DSpark ドラフトの組み合わせにより、モデルが単に利用可能であるだけでなく、実際にデプロイ可能になります。Nvidia、AMD、TPU を同時にカバーすることで、モデルが単一のアクセラレータベンダーに固定されないことも意味します。