DSpark接入SGLang：用置信度驱动可变长度验证

Speculative Decoding 的核心思路，是用额外计算换取更少的解码步数。但当负载升高时，这笔账会变得不划算：在 batch size 为 B、每步草稿 token 数为 K 时，target model 每步需要验证 B * K 个 token。一旦并发继续增长，验证成本可能超过减少解码步带来的收益。

DSpark 针对这一问题从两端入手：一方面使用 semi-autoregressive block drafter，一次 draft forward 生成一个 token block，以维持较高接受率；另一方面根据 draft model 自身的置信度，为每个请求动态分配不同的 verify length，避免验证那些大概率不会被接受的尾部 token。SGLang 现在已支持 DSpark，并覆盖 dense 与 sparse 模型，例如 Qwen3 和 DeepSeek-V4。

DSpark 在 SGLang 中做了什么

这次集成来自 sgl-project/sglang#30261。SGLang 团队并不试图逐位复现论文数字，而是在开放 serving engine 上复现 DSpark 的关键机制和收益曲线：单用户速度提升、负载升高时 verify budget 收缩，以及这些调度策略如何转化为真实 wall-clock 性能。

DSpark 算法侧主要包含三个 draft-side 组件：

• Block drafter：支持 dense 路线（如 Qwen3）和 sparse 路线（如 DeepSeek-V4）。一次 forward 输出一个 gamma-token block，并通过轻量 sequential head（Markov 或 RNN）让每一步条件依赖前一个 token，因此属于 semi-autoregressive。
• Confidence head：为每个 drafted token 估计通过验证的概率，整个 block 的概率乘积可作为 block survival probability。
• Sequential Temperature Scaling（STS）：对置信度进行校准，使 survival probability 更接近真实 acceptance rate，方便 scheduler 做预算。

SGLang 在此基础上补齐了服务化所需能力，包括 Confidence scheduler、per-request ragged verify、full CUDA graph、acceptance ceiling 可观测性、Additive SPS cost table、Data-parallel attention、overlap scheduler 集成，以及 fused Triton kernels 和 sharded block-drafter matmul 等性能优化。

混合流量下：每个请求不该拿同样的 verify window

同质化 benchmark 容易掩盖 Confidence scheduler 的价值。在真实混合流量中，一个 batch 里可能同时包含高可预测性的数学题、开放式对话和诗歌生成；它们的 acceptance 难度不同，理应获得不同长度的 verify window。

上图展示了 gsm8k、arena-hard 和 poetry 三类 workload 在 cap-accept 模式下的 verify budget。左侧对比了 ceiling、scheduler window 与实际 delivered tokens，右侧展示每步 verify length 的分布。结果说明，DSpark 能根据不同 workload 的接受特性分配不同预算：高接受率任务可以保留更长窗口，而低接受或更不稳定任务则更早截断尾部，减少无效验证。

Overlap scheduler：把调度开销藏到 forward 后面

DSpark 的动态调度如果实现不当，会在 draft-generate 与 target-verify 之间引入额外气泡，抵消算法收益。SGLang 将 DSpark speculative path 集成进 overlap scheduler，使 scheduler 几乎不需要 DSpark-specific special-casing，并尽量把调度开销隐藏在 forward 执行之后。

图中可以看到，在 batch size 1 的 decode 场景下，关闭 overlap scheduler 时，run_batch 迭代之间以及 draft-generate 与 target-verify 两个阶段之间会出现明显空泡；开启后，相关阶段能够连续执行，从而更接近零额外调度开销。

SPS cost table：让 scheduler 在线选择 verify budget

Confidence scheduler 需要回答一个关键问题：每个请求本步到底验证多少 token 最划算？SGLang 使用离线 profile 得到的 Additive SPS cost table 来建模 step time，并在在线服务时由 scheduler 读取该成本表，为每个请求选择更合适的 verify budget。

在 DeepSeek-V4 + H200 上，SPS cost table 能拟合 raw step time，并预测 decode-step time。团队也指出，目前的 SPS 与 calibration 仍是第一版近似，可能尚未充分建模 context length 对 step cost 的影响，因此 scheduler 的最优工作点仍有提升空间。

总体性能：DSpark 同时领先 MTP 与 non-spec

在 DeepSeek-V4-Flash、H200、DP-attention 四卡并行的实验中，SGLang 对比了三条曲线：non-speculative floor、MTP（EAGLE-style baseline，在 1-1-2 与 3-1-4 配置中取每个 batch size 的最佳值）以及 DSpark。除 speculation config 外，三组设置保持一致。

图中横轴为 per-user decode speed，纵轴为 aggregate throughput，每个点对应 batch size 1 到 256 中的一个并发设置，并取三轮平均。右上方代表更优。结果显示，DSpark 在整个并发扫描范围内提供了更好的吞吐与延迟折中，明显优于 MTP 和 non-spec floor。

三种 verify mode：static、compact 与 cap-accept

DSpark 在 SGLang 中的 verify mode 是理解后续工程设计的核心：

• static：每步验证完整 drafted block，是 full-block baseline。
• compact：只验证 scheduler 为每个请求选择的窗口，是生产路径。
• cap-accept：验证完整 block，但只提交窗口内 token；它与 compact 输出一致，同时能暴露 full verify 本来会接受多少 token，用于测量 trimming 下被遮蔽的 acceptance ceiling。

Ragged verify：让 CUDA graph 真正变小，而不是补齐再算

per-request verify window 与固定形状 CUDA graph 天然冲突：同一个 batch 中，一个请求可能只验证 2 个 token，另一个请求要验证 6 个 token。如果把所有请求都 pad 到完整 block width，等于把 trim 掉的计算又补了回来。

SGLang 的做法是保留 batch 的 ragged 结构，并以总 token 数作为 graph key：先把不同请求的可变长度 token front-pack 到一个 compact buffer，再将总数 round 到最近的 captured tier。这样，当预算被 trim 时，packed total 会下降到更小 tier，DSpark replay 的就是实际更便宜的 graph——减少的是 attention 和 MLP 的行数，而不是在 masked full-width forward 中空转。

这个 packed buffer 使用类似 cu_seqlens 的 varlen input，因此可以复用后端已有 attention kernels。以 DeepSeek-V4 为例，它可以直接走模型自身的 sparse-MLA 路径 flash_mla，无需新增 kernel。对于 DP attention，各 rank 共享同一个 tier，通常取任一 rank 所需的最大 tier，并同步下降。

动态调度 vs full-block：收益主要来自高并发

团队还将 compact（按步使用 SPS-argmax budget 的动态 trim）与 no-trim（通过同一 ragged path 执行的 static full-block schedule）进行了初步 A/B。这里的 scheduler 仍是第一版 vanilla 实现，重点是证明机制端到端可用，而不是展示完全调优后的最终数字。

趋势很清楚：动态预算的收益主要体现在高 batch 场景。batch size 1 时，target verify 随 token 数增加并不会明显变慢，因此 trim 节省有限，两条路径通常接近；随着并发提高、吞吐开始进入平台期，trim 能缩短 step，compact 逐渐拉开差距。对于 acceptance 更低的 workload，尾部可裁剪空间更大，因此收益出现更早、幅度也更明显。

可观测性：避免 trimming 遮蔽真实天花板

compact 的一个副作用是“删掉了观测”：它只验证 scheduler window 内的前几个位置，因此系统不知道如果完整验证整个 block，当步本可以接受多少 token。没有这个 ceiling，就无法判断一次 trim 是合理节省，还是损失了本可提交的 token。

cap-accept 正是为此设计：它验证完整 block，但只提交 window 内 token，所以提交结果与 compact 一致，同时暴露 full verify 的 acceptance ceiling。SGLang 还提供 per-request confidence、calibration 指标（如 ECE）等可观测性数据，方便离线分析。

对于不希望额外跑 companion run 的生产场景，SGLang 还实现了 block-accept estimator。它利用未来步骤中 target tokens 及其 logprobs，估计被 trim 掉的 counterfactual tail，并给出估计区间。该方法基于一个假设：trimmed 与 untrimmed 轨迹中的 anchor tokens 具有相似性质。

结论

DSpark 在 SGLang 中的价值不只是“更快的 speculative decoding”，而是把置信度驱动的可变长度验证落到了可服务化的系统实现上：semi-autoregressive block drafter 维持较高接受率，Confidence scheduler 控制每个请求的 verify budget，ragged CUDA graph 确保被裁掉的计算真的不再执行，overlap scheduler 与 SPS cost table 则把算法收益转化为端到端吞吐和延迟收益。

在 H200 + DeepSeek-V4-Flash 的测试中，DSpark 在吞吐/单用户速度曲线上优于 MTP 与 non-spec baseline；在高并发和低接受率 workload 中，动态 trim 的优势尤其明显。随着 cost model、calibration 与 scheduler 策略进一步调优，DSpark 在开放 serving engine 中仍有继续提升的空间。