最近在部署一个推理服务时我又遇到了那个熟悉的问题随着并发请求的增加吞吐量先是线性增长然后突然停滞甚至下降。查看性能分析工具发现瓶颈不在计算本身而在验证阶段——每个批次中每个请求都要验证固定数量的推测标记当批次规模扩大时这个验证成本开始吞噬掉推测解码带来的收益。这让我想起了推测解码技术面临的一个核心矛盾它本意是通过“猜测”后续标记来减少解码步骤但当负载增长到一定程度验证这些猜测的成本反而超过了它节省的时间。就在我思考如何突破这个瓶颈时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的团队我建议从以下步骤开始环境准备使用预构建镜像docker pull lmsysorg/sglang:dev-dspark或从源码构建sgl-project/sglang#30261基准测试使用提供的脚本进行不同批次大小的测试关注接受长度随工作负载的变化成本分析通过性能分析运行建立成本表理解你特定工作负载的验证模式混合流量测试尝试不同类型提示词的混合观察调度器如何差异化处理最重要的是不要一开始就追求极致的性能优化。先理解你工作负载的特性再逐步调整参数。DSpark的真正价值不在于单次推理的速度而在于它让推测解码在高并发环境下仍然保持经济性。随着大模型推理从单次测试转向大规模服务像DSpark这样能够动态适应工作负载特性的技术将越来越重要。它不仅仅是另一个推测解码变体而是代表了推理优化思维方式的转变从静态优化到动态适应从一刀切到个性化处理。这种转变对于构建下一代高效、可扩展的推理服务至关重要。