最近在部署一个推理服务时，我又遇到了那个熟悉的问题：随着并发请求的增加，吞吐量先是线性增长，然后突然停滞甚至下降。查看性能分析工具，发现瓶颈不在计算本身，而在验证阶段——每个批次中，每个请求都要验证固定数量的推测标记，当批次规模扩大时，这个验证成本开始吞噬掉推测解码带来的收益。

这让我想起了推测解码技术面临的一个核心矛盾：它本意是通过“猜测”后续标记来减少解码步骤，但当负载增长到一定程度，验证这些猜测的成本反而超过了它节省的时间。就在我思考如何突破这个瓶颈时，SGLang团队最近集成的DSpark推测解码方案引起了我的注意。

DSpark的独特之处在于它引入了“置信度驱动的可变长度验证”机制。简单来说，它不再对每个请求都验证相同数量的标记，而是根据草案模型自身的置信度，为每个请求动态分配验证预算。高置信度的请求验证更多标记，低置信度的则提前停止验证。这种看似简单的调整，实际上改变了推测解码的经济学模型。

1. 为什么传统的推测解码会在高并发下失效

要理解DSpark的价值，我们需要先看清传统推测解码的局限性。大多数推测解码方案（如EAGLE、MTP）都遵循一个固定模式：草案模型一次生成K个标记，目标模型然后验证这K个标记。在低并发时，这种模式效果显著，因为验证成本相对较低。

但随着批次规模B的增加，每个步骤需要验证B×K个标记。当B足够大时，验证阶段开始主导整个推理时间。更糟糕的是，固定K值的方案无法适应不同请求的特性——有些提示词引导的生成可预测性强，有些则充满不确定性，但传统方案对它们一视同仁。

DSpark通过两个关键创新解决了这个问题：半自回归的块草案器和置信度驱动的可变长度验证。块草案器一次生成一个完整的标记块（而是一个个生成），保持较高的接受率；置信度头部则为每个草案标记评分，评估其通过验证的概率。

2. DSpark如何实现真正的动态验证预算

DSpark的核心机制建立在三个组件上：块草案器、置信度头部和顺序温度缩放（STS）。块草案器可以是稠密模型（如Qwen3）或稀疏模型（如DeepSeek-V4），一次前向传递生成γ个标记的块。置信度头部评估每个草案标记的生存概率，而STS则校准这些分数，使其反映真实的接受率。

但真正让DSpark与众不同的是它的调度器。这个调度器将每个块的生存概率转换为每个请求的验证预算。在静态模式下，DSpark验证完整的草案块；在生产路径的紧凑模式下，它只验证调度器选择的每个请求窗口；在cap-accept模式下，它验证完整块但只提交到窗口位置，用于测量修剪下的上限。

这种动态调整的能力在面对混合流量时尤其重要。在测试中，当同时处理gsm8k（高接受率）、arena-hard（中接受率）和poetry（低接受率）三种不同类型的请求时，DSpark为它们分别分配了5.24、3.78和2.91个标记的验证窗口，同时保持了对上限的高利用率（0.88-0.97）。

3. 可变长度验证的工程实现挑战

将可变长度验证落实到生产中面临着重大的工程挑战。最直接的问题是：如何在不规则、每请求可变验证长度的批次上实现完整的CUDA图捕获？

传统固定形状的CUDA图需要统一的输入维度，但DSpark的每个请求可能有不同的验证长度。如果简单地将所有请求填充到最大长度，就失去了修剪的意义。SGLang的解决方案是采用前端打包策略：将可变长度请求打包到一个紧凑缓冲区中，然后向上取整到最近的捕获层级。

这种打包缓冲区的实现类似于cu_seqlens风格的变长输入，因此紧凑验证可以重用后端已有的注意力内核。在DeepSeek-V4上，模型使用自身的稀疏MLA路径（flash_mla），无需新内核。每个支持的后端只需在图形重放时从打包布局重建其变长元数据。

具体到性能优化，SGLang团队重写了小型操作集群为融合的Triton内核，包括紧凑散射、SWA页面索引、验证长度top-k调度和不规则窗口打包。块草案器的采样路径被折叠到融合内核中，其矩阵乘法也被分片。在一个示例分析中，目标验证之外的部分减少了1.7毫秒，而验证本身为7.3毫秒。

4. 零开销调度如何隐藏计算成本

DSpark无缝集成到SGLang的零开销（重叠）调度器中，几乎不需要DSpark特定的特殊处理。SGLang的spec-v2运行时已经在单独流上重叠下一阶段的调度与当前前向传递，DSpark作为一等工作者加入：前向输出作为异步未来返回，跨迭代排序利用运行时的设备端屏障，设备端页表意味着无需每步主机同步。

置信度中继使用相同的通道，读取两步之前的数据。这样，解码循环运行时没有每步气泡——比关闭调度器时紧凑约1.5倍。

这种调度器的效率很大程度上依赖于准确的成本表分析。DSpark使用加性成本模型来表达调度器对步长时间T(bs, K)的估计，其中K是批次的额外验证标记：

T(bs, K) = bias + alpha(bs) + theta(M), M = bs + K

这里alpha(bs)是请求缩放地板（草案传递加上部分注意力），不受修剪影响；theta(M)是目标的验证标记成本，是修剪唯一恢复的项。调度器的argmax在预期接受的标记与真实边际成本之间权衡，因此修剪空间只在theta较大时出现。

5. 可观测性：理解修剪下的真实性能

修剪虽然提高了效率，但也带来了可观测性挑战：紧凑模式只验证一个块的前几个位置——调度器的窗口——因此完整块验证在该步骤会接受多少标记从未被观察到。没有这些信息，就无法区分好的修剪和有损的修剪。

cap-accept运行恢复了这一信息：它验证完整块但只提交到窗口位置，因此它提交的内容与紧凑模式完全相同，同时暴露了上限。我们还提供每请求置信度和校准指标（如ECE）用于事后分析。

对于生产运行或其他不希望有额外伴随运行的情况，块接受估计器直接在紧凑运行内部恢复估计的审查上限。它通过利用未来步骤中的目标标记及其对数概率来实现，并计算反事实尾部的估计区间，假设修剪与未修剪轨迹中锚标记的属性相似性。

6. 实际部署中的考量与优化建议

从实际部署角度看，DSpark在SGLang中的集成为我们提供了几个重要启示。首先，动态预算的优势主要是高批次效应。在批次大小为1时，目标验证不会因更多标记而显著减慢，因此修剪节省很少，两种方案持平。随着并发增长和吞吐量开始稳定，修剪缩短了步骤时间，紧凑模式领先。

这一差距在低接受率示例上更大，且出现更早——低接受率留下更多尾部可修剪，正如成本模型预测的那样。但需要注意的是，当前的SPS（和校准）拟合是初步近似，可能尚未完全考虑步骤成本如何随上下文长度变化，因此调度器确定的确切操作点可能还有改进空间。

对于想要尝试DSpark的团队，我建议从以下步骤开始：

1. 环境准备 ：使用预构建镜像（docker pull lmsysorg/sglang:dev-dspark）或从源码构建（sgl-project/sglang#30261）

2. 基准测试 ：使用提供的脚本进行不同批次大小的测试，关注接受长度随工作负载的变化

3. 成本分析 ：通过性能分析运行建立成本表，理解你特定工作负载的验证模式

4. 混合流量测试 ：尝试不同类型提示词的混合，观察调度器如何差异化处理

最重要的是，不要一开始就追求极致的性能优化。先理解你工作负载的特性，再逐步调整参数。DSpark的真正价值不在于单次推理的速度，而在于它让推测解码在高并发环境下仍然保持经济性。

随着大模型推理从单次测试转向大规模服务，像DSpark这样能够动态适应工作负载特性的技术将越来越重要。它不仅仅是另一个推测解码变体，而是代表了推理优化思维方式的转变：从静态优化到动态适应，从一刀切到个性化处理。这种转变对于构建下一代高效、可扩展的推理服务至关重要。