SGLang 集成多 Token 预测（MTP），DeepSeek V3 输出吞吐最高提升 60%

TL;DR

SGLang 现在支持这些高级功能的平滑组合：多 Token 预测（MTP）、大规模专家并行（EP）以及预填充-解码分离。这一集成通过新的解码范式、更好的并行性和更高效的资源利用，在不牺牲生成质量的前提下，实现了高达 60% 的输出吞吐量提升。如果你正在服务模型，例如 DeepSeek V3，SGLang 现在支持将 MTP 作为即插即用功能，带来即时的性能提升。你可以在这里找到复现说明。

SGLang 的推理框架运行在 NVIDIA GPU 上，使 AI 从业者能够轻松实现大规模推理，赋能终端用户“智能思考”，并以最高性能利用最先进语言模型的推理能力。

引言

尽管大语言模型的能力持续增长，其逐 Token 解码过程本质上仍是串行的，这为推理吞吐量带来了关键瓶颈。这一局限在高需求应用中尤为明显，在这些场景中，最大化 GPU 利用率对于实现高性能和成本高效的部署至关重要。

为解决这一问题，SGLang 将多 Token 预测（MTP）引入开源推理生态。这是一种先进的推测解码技术，通过轻量级草稿模型预测多个草稿 Token，并使用完整模型的一次前向传播并行验证它们，从而加速生成。在我们的基准测试中，MTP 为 DeepSeek V3 带来了高达 60% 的输出吞吐量提升，且没有任何生成质量损失。随着 MTP 现已完全集成，SGLang 继续推动开源 LLM 服务的边界，提供此前仅限于专有系统的先进解码能力，并使其可访问且可用于生产。

什么是多 Token 预测（MTP）？

传统的自回归解码一次生成一个 Token，并依赖于所有先前的 Token。这种串行过程限制了并行性和速度。

MTP 是一种推测解码技术，通过使用轻量级草稿模型快速提出多个未来 Token，然后由完整的目标模型在一次前向传播中并行验证它们，从而加速生成。

MTP 的工作方式是将生成分为两个阶段：

-草稿阶段：轻量级草稿模型在一次快速前向传播中预测一个或多个由 n 个 Token 组成的短序列候选。这里我们以一个序列候选为例。
(1) “Today is a sunny” 是目标模型生成的当前前缀。
(2) “day”首先由目标模型的扩展/预填充阶段生成。
(3) “and”是草稿模型的扩展/预填充阶段生成的第一个草稿 Token。
(4) “it’s so hot”是草稿模型解码迭代生成的三个额外草稿 Token；在此示例中，“and it’s so hot”的 n=4。

-验证阶段：完整的目标模型随后并行验证所有 n 个草稿 Token，接受与其自身输出匹配的最长前缀，并在需要时重新采样其余部分。
让我们通过一个 n = 4 的示例来逐步说明：

• 目标模型首先在扩展/预填充阶段后生成初始 Token：
  → “day”
• draft model 随后在 extend/prefill 之后推测下一个 token，并在自回归解码后再推测 3 个 token：
  → “and it’s so hot”
• target model 验证整个序列：
  → 它同意 “and it’s”
  → 它拒绝 “so hot”，并改为重新采样 “very”

为什么 MTP 快

MTP 提速的关键在于并行性。至关重要的是，验证步骤在 GPU 上完全并行化，用一次并行验证替代 n 次顺序解码步骤。

MTP 的有效性取决于每个验证步骤接受多少 draft token，这一指标被称为 接受长度。例如，平均接受长度为 2.4 意味着平均每次跳过 2.4 个解码步骤，从而在长序列中带来显著的累积加速。

MTP 不会在生成质量或确定性上妥协。每个推测 token 仍由同一个完整模型验证和批准，确保输出与标准解码完全一致，没有任何近似或微调。

这一新能力已与 SGLang 的高级特性完全集成，包括：

• 数据并行注意力（DP Attention）
• 专家并行负载均衡器（EPLB）
• DeepEP MoE
• 双批次重叠
• Prefill-Decode（PD）分离
• CUDA Graph
• 多种注意力后端

性能评估

我们使用 DeepSeek V3 模型作为测试平台，对将 MTP 完全集成到 SGLang 服务框架中所带来的性能提升进行了全面评估。该分析包含两个案例研究，旨在突出小规模和大规模部署场景下的改进。

部署场景与设计动机

小规模部署配置是根据一家知名生成式 AI 公司的生产需求选定的，该公司运营着一款对延迟敏感、面向开发者的产品。具体而言，该公司要求每个 rank 的最低持续输出达到 60.4 tokens/sec，以满足应用级服务级别协议（SLA）。这一需求指导了我们第一个案例研究中所使用的配置。为了评估更高负载下的可扩展性，我们还在大规模集群设置中评估了 MTP。

案例研究 1：小规模部署

在此场景中，我们跨总共 16 块 H200 GPU 部署两个解码节点，每个 rank 运行 2 个并发请求，输入序列长度为 65,536 个 token，输出序列长度为 4,096 个 token。作为基线，我们测试了无 MTP 且无重叠调度的情况，系统实现了每个 rank 51 tokens/sec 的输出吞吐量。仅使用重叠调度——SGLang v0.4 引入的一项特性——我们就达到了每个 rank 60.4 tokens/sec，无需 MTP 即可满足生产阈值。 启用 MTP 后，系统显著超越了这一基准：

• 使用 3-token MTP 窗口和 topk=1，系统实现了每个 rank 81.5 tokens/sec 的吞吐量，平均接受长度为 2.18 个 token。
• 使用 4-token MTP 窗口和 topk=1，吞吐量提升至每个 rank 82.0 tokens/sec，平均接受长度为 2.44 个 token。

这些结果表示，与基线（即无重叠调度和无 MTP）相比，输出吞吐量提升了 +60%。该案例表明，即使在并发水平适中的较小集群环境中，MTP 也能带来显著的性能提升，从而在受限的 GPU 资源预算内实现可扩展的性能。

案例研究 2：大规模部署

为了评估可扩展性，并展示 MTP 在大规模 EP 和 Prefill-Decode 分离下的支持，我们扩展到一个由 128 块 H200 GPU 组成的 16 节点集群，其中 4 个 prefill 节点和 12 个 decoding 节点，每个 rank 运行 128 个并发请求，输入序列长度为 2,000 个 token，输出序列长度为 100 个 token。在这个高吞吐量环境中，我们将 decoding 配置为 topk = 1、step size = 1 和 draft_token_num = 2。

将启用 MTP 的 decoding 与基线（即无重叠调度和无 MTP）进行比较时，我们观察到输出吞吐量增加了 +14.2%，这证实了即使在大规模、类生产工作负载下，MTP 也能提供可衡量的性能提升。

MTP 最佳实践

要在 SGLang 中开始使用多 Token 预测，请在配置中启用它，并将 draft_token_num 设置为 2，这是一个平衡、低风险的选择，可在大多数工作负载中提供可靠的性能提升。对于有可用 GPU 余量的设置，你可以将 draft_token_num 增加到 4 甚至更大，以进一步提升吞吐量，不过收益可能会递减，具体取决于系统维持 token 接受率的效果。另一方面，如果你的 GPU 已经在处理大批量或接近满载运行，将 draft size 保持在 2 或 3 通常更高效，并可避免引入额外负载。

你可以在日志中监控接受率，以随时间微调此参数。如果你看到平均接受长度持续高于 2，就有空间尝试更长的 draft。但如果接受率开始下降，请考虑将其调低，以保持在系统的舒适区内。

未来工作

-大规模优化 我们正在继续优化大规模 MTP 部署的性能，重点关注多节点系统中的调度效率和内存带宽利用率。

-重叠调度兼容性 当前的 MTP 实现尚不支持重叠调度。我们预计，一旦 MTP 和重叠调度集成，将带来额外的性能提升。该功能的开发正在进行中。

致谢

我们衷心感谢以下团队和合作者。特别是，我们诚挚感谢 NVIDIA DGX Cloud 团队提供强大的 GPU，以及他们在确保卓越运营方面给予的出色支持：

Eigen AI 团队 - Jinglei Cheng、Yipin Guo、Zilin Shen、Ryan Hanrui Wang、Wei-Chen Wang 以及许多其他人。

SGLang 团队与社区 - Kavio Yu、Ke Bao、Qiaolin Yu、Boxin Zhang、Shangming Cai、Jinfu Deng、Jiaqi Gu、Di Jin、Uill Liu、Junyao Zhang、Yineng Zhang 以及许多其他人。

xAI 团队 - Sehoon Kim、Ying Sheng、Lianmin Zheng、Sangbin Cho、Hanming Lu、Byron Hsu、Pranjal Shankhdhar、Cheng Wan 以及许多其他人。

NVIDIA 团队 - 来自 Enterprise Products 的 Pen Chung Li、Carl Nygard、Lee Ditiangkin、来自 DGX Cloud 的 Nathan Fisher 以及许多其他人。