# SGLang 集成 DSpark 推测解码：置信度驱动的可变长度验证

- 来源：LMSYS：Blog（Chatbot Arena 团队）
- 发布时间：2026-07-06 00:00
- AIHOT 分数：63
- AIHOT 标记：精选
- AIHOT 链接：https://aihot.virxact.com/items/cmr9h98co0470slsmqqc2ilv1
- 原文链接：https://www.lmsys.org/blog/2026-07-06-dspark-sglang

## 精选理由

DSpark 这版推测解码的工程落地比论文本身更有看头——SGLang 用 ragged CUDA Graph 和动态调度把 trimm 掉的计算按字节级回收，383 tok/s 的单请求速度对部署方是即时可用的性能增益。

## AI 摘要

SGLang 团队将 DSpark 推测解码算法集成到开源推理引擎中。该算法采用半自回归块起草器一次生成一组 token，并利用置信度头与顺序温度缩放（STS）为每个请求动态分配可变验证长度，从而在高负载下裁剪无效验证成本。SGLang 支持密集模型（如 Qwen3）和稀疏模型（如 DeepSeek-V4），通过全 CUDA 图处理不规则的每请求验证长度。提供三种验证模式：`static`（全长）、`compact`（生产路径）和 `cap-accept`（接受上限测量）。还引入了零开销调度、基于离线成本表的在线调度器、融合 Triton 核等优化。在 H200 上使用 DeepSeek-V4-Flash 的测试中，DSpark 在整个并发扫描范围内比 MTP 和非推测基线实现了更优的吞吐量-延迟权衡。

## 正文

推测解码用额外计算换取更少的解码步数，但随着负载增长，这种权衡会恶化：在批次大小 `B` 且推测 token 数为 `K` 的情况下，目标模型每步验证 `B * K` 个 token，而超过某个临界点后，验证成本会超过节省的成本。

DSpark 从两端着手——一个**半自回归块**草案模型（每次草案前向生成整个块，因此接受率保持高位）以及一个由草案模型自身置信度驱动的**每个请求可变验证长度**，它会停止验证那些工作负载不太可能接受的 token。

该算法及其收益均来自 DSpark 论文。

SGLang 现已支持在稠密和稀疏模型（例如 Qwen3 和 DeepSeek-V4）上使用 DSpark。

本文介绍该集成实现。

我们在开源推理引擎上复现了论文中收益的**形态**——每用户加速比，以及验证预算随负载上升而缩减——并描述了将这种调度转化为实际时间所涉及的**工程实现**：在非对齐的、按请求验证上实现完整 CUDA graphs（这样经过修剪的批次会重放一个真正更小的 graph，而非补零的 graph）；一个感知重叠的推测路径，将调度器隐藏在前向计算之后；一个成本表分析器，让调度器能够在线地为每个请求确定验证预算大小；以及针对接受上限的可观测性——否则修剪会掩盖这种上限。

硬件、推理引擎和流量均与论文不同，因此我们复现了机制和曲线，而非精确的数值，下文中所有“更快”的结论都是基于我们自身的对照实验——除推测配置外，其他条件完全相同。

与 MTP 及无推测情况相比的加速比

在 SGLang 中采用 DSpark

验证模式

完整 CUDA graphs 下的非对齐验证

可观测性

修剪下的接受上限估算

动态调度与固定调度的初步对比

混合流量下的按请求差异化

性能优化与零开销调度（ZOS）

成本表分析

后续计划

附录：复现方法

SGLang 中的 DSpark：基于置信度驱动的可变长度验证的推测解码

SGLang 团队 2026年7月6日

_图 1. 总吞吐量（y 轴） vs. 单用户解码速度（x 轴）；每条曲线从 batch 1 扫描至 256 的并发度，每条手臂对应一条曲线。越靠右上方越好。_

在图 1 示例中，DSpark 在整个并发扫描范围内提供了最佳的吞吐量/延迟权衡，明显领先于 MTP 和非推测基线。三条手臂均使用 DeepSeek-V4-Flash 在 H200 上运行，采用 DP-attention 分布在四个 rank 上，除推测配置外完全相同——非推测基线、MTP（EAGLE 风格基线，取每个 batch 大小下 1-1-2 与 3-1-4 配置中的最佳值）以及 DSpark。

**在 SGLang 中采用 DSpark**

DSpark 算法源自论文，包含三个草稿侧组件： **块草稿器**——一条密集线（例如 Qwen3）和一条稀疏线（例如 DeepSeek-V4）；一次前向传播生成一个 `gamma` token 块，并带有一个轻量级顺序头（Markov 或 RNN），使每个步骤以前一个 token 为条件，因此该块是半自回归的。 **置信度头**——为每个草稿 token 打分，评估其通过验证的概率；整个块的乘积即为该块的存活概率。 **顺序温度缩放（STS）**——对这些分数进行校准，使存活概率反映调度器预算分配的真实接受率。

在此基础上，SGLang 增加了服务支持层： **置信度调度器**——将每个块的存活概率转换为每个请求在每个步骤中的验证预算。 **每请求可变验证**——在同一个 batch 内，每个请求的验证长度可变（`static` / `compact` / `cap-accept`）。 **完整 CUDA graph**——针对可变长度验证进行捕获。 **可观测性**——在裁剪及其他指标下的接受上限。 **加性 SPS 成本表**——离线分析的步骤时间模型，由调度器在线读取。 **数据并行注意力**——与其他并行维度一同支持。 **零开销调度**——集成到 SGLang 的重叠调度器中，几乎无需专门针对 DSpark 的特殊处理。 **性能优化**——融合的 Triton 内核以及分片块草稿器矩阵乘法。 **验证模式**。

三种验证模式是本文后续内容围绕的核心。`static`（静态）模式每一步都验证整个草稿块（基线）。`compact`（紧凑）模式仅验证调度器选取的每个请求窗口——即生产路径。`cap-accept`（上限接受）模式验证完整块，但只提交到该窗口为止：输出结果与`compact`相同，同时暴露完整验证本应接受的内容——即我们如何衡量剪裁下的上限。

完全CUDA图下的参差不齐验证

每个请求的窗口并不适合固定形状的CUDA图：在一个批次中，一个请求验证两个token而另一个请求验证六个，并没有单一的查询长度，而将所有人填充到完整块宽度只会把剪裁重新填充回去。因此我们保持批次参差不齐，并将图的关键索引建立在_total_ token数量上——将可变长度的请求前端打包到一个紧凑缓冲区中，然后向上取整到最近的捕获层级。当预算被剪裁时，打包后的总数下降到更小的层级，DSpark会重放一个真正更便宜的图（更少的attention和MLP行，而非掩码的全宽度前向传播）；在DP attention下，各个rank共享一个层级（任何rank所需的最大层级）并一同降级。

打包后的缓冲区是一个`cu_seqlens`风格的可变长度输入，因此紧凑验证复用了后端已有的attention内核——在DeepSeek-V4上，模型自身的稀疏-MLA路径（`flash_mla`），无需新内核；每个受支持的后端只需在图重放时从打包的布局中重建其可变长度元数据。

_图2：将每个请求可变验证长度的批次适配到捕获的CUDA图中。固定形状图将每个请求填充到完整块宽度（N x W）；参差不齐路径将调度的token前端打包，并仅将总数向上取整到最近的捕获层级，对于相同数量的接受token，计算了远更少的填充单元。_

可观测性

剪裁会遮蔽上限：紧凑模式仅验证块的前几个位置——调度器的窗口——因此完整块验证在该步骤本应接受多少个token从未被观测到——而没有它，你就无法区分好的剪裁和有损的剪裁。`cap-accept`运行恢复了这一点：它验证完整块但只提交到窗口为止，因此它提交的恰好是紧凑模式提交的内容，同时暴露了上限。我们还展示每个请求的置信度和校准指标（例如ECE）以进行事后分析。

估算剪裁下的上限

一个专为生产运行或其他不希望额外伴随运行的场景设计的块接收估计器，能够直接在紧凑运行内部恢复估计的截断上限。它利用目标 token 在未来步骤中的对数概率，并假设裁剪轨迹与未裁剪轨迹中锚点 token 的属性相似性，来计算反事实尾部的估计区间。

动态调度与固定调度的初步对比

置信度调度器是一个初版、未经精细调优的实现——我们将其视为一个机制端到端可用的证明，而非高度调优的结果。我们在两个接收率不同的示例工作负载上，比较了 `compact`（每步的 SPS-argmax 预算）与 `no-trim`（沿相同不规则路径运行的 `static` 全块调度）的效果。

*图 3. compact（动态裁剪）与 no-trim（全块）对比，DP4 下 batch 1 到 256，在两个接收率不同的示例上。图形越靠右上方表示效果越好。*

动态预算的优势主要在高批量场景下体现。在 batch size 为 1 时，目标验证并不因 token 增多而显著变慢，因此裁剪节省的收益很小，两种方案几乎持平。随着并发程度增加、吞吐量开始趋于饱和，裁剪缩短了单步时间，`compact` 开始领先。在接收率较低的示例上，差距更大且更早出现——较低的接收率意味着更多的尾部可以被裁剪，这与成本模型的预测完全一致。

每个面板都是一次干净的 `compact` 与 `no-trim` 的 A/B 对比（面板内设置完全相同），但两个示例并非严格意义上的单变量对比：除了接收率不同，它们在设置上也有细微差异（提示词格式和每轮运行次数），因此我们关注的是趋势的变化，而非面板间的绝对数值。

这些预算的有效性也取决于其背后的成本表。当前我们的 SPS（及校准）拟合只是初步近似，可能尚未完全考虑步骤成本随上下文长度变化的情况——因此调度器最终确定的具体操作点很可能仍有改进空间。我们在此展示的是这一机制，而非一个经过调优的数字。

混合流量下的逐请求差异化

同质化的扫参测试掩盖了置信度调度的真正意义。同一批次中的两个请求，如果一个请求的可预测性远高于另一个，它们就不应该获得相同的验证窗口。混合流量才是这一机制大显身手的场景。

*图 4. 按工作负载划分的预算（左）与每步验证长度分布（右）。*

作为一个例子，我们按接受难度混合三种工作负载：gsm8k（高）、arena-hard（中）和诗歌（低）。窗口随难度收缩——5.24、3.78、2.91个模型token——而相对于上限（即区块在不修剪情况下能接受的长度）的利用率仍然很高（0.88–0.97）。调度器对每个请求单独调整大小，而不是应用一个批次的平均值。右侧面板逐步展示：约55%的gsm8k步骤填满了长度为6的完整窗口，而约80%的诗歌步骤仅使用3个或更少。

性能优化与零开销调度（ZOS）

两类工程工作将调度转换为实际时间：降低每个步骤的成本，以及将调度器隐藏在正向传播之后。两者结合，在DeepSeek-V4-Pro上，TP=8，B300，批大小为1时，达到了**约383.7 tok/s，接受长度约5**。

我们将小型操作集群重写为融合的Triton内核，例如紧凑散射、SWA页面索引、验证长度top-k调度以及不规则窗口打包。区块起草器的采样路径被合并到融合内核中，其矩阵乘法被分片。在一个示例剖析中，目标验证之外的环节缩短了1.7毫秒，而验证本身耗时7.3毫秒。

DSpark直接嵌入SGLang的零开销（重叠）调度器，几乎不需要特殊处理，仅增加了论文中提出的两步后向置信度中继。其中很少有专门针对DSpark的专属管线。SGLang的spec-v2运行时已经将下一个步骤的调度与当前的向前传播在独立流上重叠，而DSpark作为一等工作节点加入：向前传播的输出以异步未来（async futures）的形式返回，跨迭代的排序由运行时的设备端屏障控制，设备端页表意味着无需每个步骤的主机同步。置信度中继使用相同的通道，读取两个步骤前的数据。解码循环运行时没有步骤间的气泡——比关闭调度器时紧凑约1.5倍。

_图5. 批大小为1的解码，关闭重叠调度器（上）与开启重叠调度器（下）。开启时，`run_batch`迭代之间以及步骤内部区块草案生成与目标验证阶段之间均无气泡。_

剖析成本表

_图6. 加性成本模型——原始与拟合（a）及吞吐量（b）——以及步骤时间的预测值与实测值（c）。_

我们用一个加性模型来表示调度器对步骤时间 `T(bs, K)`（其中 `K` 是该批次额外的验证模型 token）的估计：`T(bs, K) = bias + alpha(bs) + theta(M), M = bs + K`，其中 `alpha(bs)` 是请求缩放基线（草稿通过加上注意力的一部分），不受修剪影响；`theta(M)` 是目标模型的验证 token…