vLLM 实现 Muse Spark Open Day 0 支持：816B MoE 模型赋能长程智能体编码

vLLM 对 Muse Spark Open 的 Day 0 支持。我们很高兴能与 Meta Superintelligence Labs 合作，在 Day 0 将 Muse Spark Open 引入 vLLM。Muse Spark Open 是一款开源权重的稀疏混合专家（MoE）模型，专为长周期智能体编码工作流而构建。它是迄今为止功能最强大的美国开源权重模型，也是 Muse Glimmer 30B 模型的蒸馏源模型。

亮点

• 架构：总参数量 816B，每个 token 激活参数 42B，上下文窗口达 1M。
• 量化：Meta 发布了 BF16 和 NVFP4 两种格式的模型权重。AMD 发布了 MXFP4 权重。
• 多模态：通过相同的 Perception Encoder 实现原生的图像和视频感知，并额外支持音频。
• 并行策略：在 Nvidia 和 AMD 平台上均支持张量并行（Tensor Parallelism）和流水线并行（Pipeline Parallelism）。在 Nvidia 平台上支持专家并行（EP）、张量专家并行（TEP）、数据专家并行（DEP）以及 PD 分离部署。TPU 平台也已提供初步支持。
• 投机解码：我们训练了一个 DSpark 草稿模型，该模型在 CUDA 和 ROCm 上均受支持，可加速模型性能，并在 SPEED 基准测试中进行了验证。

使用方法

两家供应商均已提供预构建镜像：

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

请注意，只有在代码 (PR #61879) 经过审查并合并后，该模型才会在 nightly PyPI wheel 中可用，这通常需要大约一周的时间。

# Rust frontend is recommended
export 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}'

若要在纯文本场景下使用此模型：

  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": "Refactor this module."}],
      "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": "What is happening here, and when?"}
     ]}]
   }'

实现细节

模型架构

Muse Spark Open 模型架构

Muse Spark Open 是一个混合专家（Mixture-of-Experts, MoE）模型，包含文本解码器在内的总参数量为 816B，此外还配备了一个 2B 的视觉编码器和一个小型音频编码器。该解码器共有 62 层，每一层都是混合专家层。权重分布如下：

该模型架构与 Muse Glimmer 类似。对于尚未使用过 Muse Glimmer 的用户来说，此模型架构中有几个值得深入关注的点。

带有归一化和门控的注意力块

三明治归一化（Sandwich normalization）。 大多数解码器在每个块之前放置一个归一化层，形成 x + F(norm(x)) 的结构。Muse Spark Open 与 Muse Glimmer 类似，在块的前后各放置一个归一化层，就像三明治的两片面包夹着中间的馅料一样，形成 x + post_norm(F(norm(x))) 的结构。

潜在 MoE 池化器与反池化器

Latent MoE。每个混合专家（MoE）层都包含两个额外的矩阵，由该层中全部 256 个专家共享。代码中将它们称为 pooler 和 unpooler，尽管二者并非传统意义上的池化操作，而是用于压缩和扩展维度的可学习投影。Pooler 是一个 $8192 \times 4096$ 的矩阵，在 token 进入专家之前将其宽度减半；而 unpooler 则在之后恢复其完整宽度。因此，专家完全在 4096 维度而非 8192 维度上工作，这实际上将两个专家投影层所需的参数量减少了一半。

混合滑动窗口与全注意力机制

混合注意力（Hybrid Attention）。各层在全注意力和滑动窗口注意力（SWA）之间交替进行，遵循每 4 层为一个循环的模式：其中三层关注 2048 个 token 的窗口，第四层则查看整个上下文。该循环以模型堆栈的末端为锚点，确保最后一层始终是全注意力层。在 62 层网络中，这意味着有 46 个窄窗口层和 16 个宽窗口层，且窄窗口层仅保留近期的 KV 缓存。在 1M token 长度下，这将缓存大小降低至全注意力机制所需量的略高于 1/4。正是这一设计使得支持 1M 上下文长度成为可能。

视觉编码器（Vision Encoder）。Muse Spark Open 使用与 Muse Glimmer 相同的 Perception Encoder，这是一个拥有 2B 参数的塔式结构，能够以原生分辨率读取图像，而不是将其调整为正方形。视频也通过同一个编码器处理：帧在加载时被采样为一系列视频帧，并将时间戳作为 token 嵌入到 prompt 中。

音频编码器（Audio Encoder）。音频以 24 kHz 的原始波形形式读取，每 1920 个样本（即 80ms）通过一系列变换生成一个 token。整个音频编码器仅有 118M 参数。请注意，视频的音轨不会被单独处理。若要让模型同时获取片段的画面和声音，需将视频和提取出的音频作为同一请求中的两个独立内容部分发送。

DSpark

为了加速 Muse Spark Open 在 vLLM 上的推理，我们使用 DSpark 训练了一个推测器（speculator）。DSpark 是一种推测解码算法，利用块扩散（block diffusion）在一次前向传播中提出最多七个草稿 token。基于置信度的调度策略有助于即使在大批量场景下也能维持显著的速度提升——而在这些场景中，传统的推测解码通常收益递减，如下方结果所示。

DSpark 性能结果

我们的推测解码器（speculator）同样采用 Muse Spark Open 的滑动窗口注意力机制，即使在处理 100 万 token 的上下文时，也能保持轻量级的草稿生成。这些设计选择相结合，使其非常适合涵盖各种批量大小和上下文长度的生产环境工作负载。

要启用该功能，请在服务器启动时添加以下配置：

--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

Nvidia 团队通过融合归一化、门控和残差内核，以及将 MoE 最终化与张量并行通信和 RMSNorm 融合，改进了 FlashInfer 和 vLLM 中的 Muse Spark Open 推理性能。此外，还引入了新的低延迟 BF16 GEMM 实现并减少了编译开销；实现了带有融合 MNNVL 集合通信的 TEP 池化/解池化分片；使用由归一化层 FP32 输出驱动的 TF32 路由 GEMM；并在数据移动、硬件支持和运行时可靠性方面进行了优化。

AMD

感谢 AMD 团队，我们已在 AMD Instinct™ MI355X GPU 上支持该模型，提供 FP8 和 MXFP4 量化格式，从而提升了推理性能和部署效率。请注意，ROCm 目前同时支持张量并行（Tensor-Parallel）和流水线并行（Pipeline-Parallelism）。

TPU

我们在 TorchTPU 基础上增加了对 Muse Spark Open 在 TPU 上的支持。如需获取代码访问权限，请联系我们或 Google。我们还为 Muse Spark Open 构建了 megakernels。结合 DSpark 推测解码（接受长度为 6），它们在 4 个 TPU v7 芯片上可实现超过 650 tokens/sec 的速度，在 8 个芯片上则超过 960 tokens/sec。即使不使用推测解码，它们仍分别能提供超过 270 和 350 tokens/sec 的性能。

vLLM 中的强化学习

vLLM 从第一天起就支持在 Muse Spark Open 上进行 LoRA RL（强化学习），作为 rollout 引擎，配合 Verl FSDP2 作为训练器。vLLM 服务原始的 NVFP4 检查点，并在其之上应用 LoRA 适配器。训练器基于相同权重的 BF16 反量化版本运行，仅更新适配器（rank 32, alpha 64），覆盖注意力机制、MoE 潜在投影以及所有路由专家。它还会重放 rollout 过程中的 MoE 路由（R3），并且在每一步之后仅将适配器同步回 vLLM。

我们在 16 块 GB300 GPU 上，使用 DAPO-Math-17K 数据集对模型进行了 150 步的 GRPO 训练。每一步针对 32 个提示词（prompts）各采样 8 条回复，每条回复最多包含 4K tokens。在 AIME-2024 基准测试上的准确率（mean@8）从训练前的 0.56 提升至训练结束时的 0.85。在整个训练过程中，trainer 与 vLLM 之间 log-probabilities 的 k3 KL 散度始终保持在约 2×10⁻⁴ 的水平。更多细节可参见 https://github.com/verl-project/verl/pull/8257。在 vLLM 生态系统中，Titan RL 同样采用 vLLM 作为其 rollout 引擎，以提供 Day-0 的 RL 支持。

Muse Spark Open LoRA RL 结果

致谢

我们衷心感谢 Meta Superintelligence Labs 团队以及 vLLM 社区在实现 Muse Spark Open 于 vLLM 上的 Day 0 支持过程中所进行的紧密协作。同时，我们也感谢 Inferact 在 DSpark speculator 训练及 TPU 集成方面的工作，以及 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