DeepSeek 又给大模型推理上强度了：DSpark 不是更快，是更会分配算力

如果只看结论，DSpark 最吸引人的地方，是它把大模型推理里两个长期对立的目标同时往前推了一步：草稿生成更准了，验证也更省了。
如果只看数字，它在离线 benchmark 上提升 accepted length，在生产系统里把 per-user generation speed 提升到 60%–85%，而且不是靠“牺牲吞吐换速度”，而是在高并发场景下也能稳住系统表现。
但真正值得写进文章里的，不是这些数字本身，而是它背后的思路：DSpark 其实是在重新定义 speculative decoding 的优化对象——不再只是“把 draft 做快”，而是把 draft 质量、验证预算和系统负载 一起纳入设计。

先把问题说清楚

大模型的 autoregressive 解码有一个天然瓶颈：每生成一个 token，都要走一次 forward pass。
这意味着输出越长，等待就越长，GPU 利用率也越难拉满。
Speculative decoding 的出现，本来是想把这个问题拆开：先让轻量 drafter 猜一串候选 token，再交给 target model 一次性验证，从而把多个 token 的生成压缩到更少的 forward 次数里。

但传统方案很快遇到两个现实问题。

第一，纯并行 drafter 的后缀质量会掉得很快。
因为每个位置都独立预测，没有足够的 block 内依赖建模，越往后越容易出现语义冲突，导致 accepted length 迅速下降。
第二，固定长度验证并不总是划算。
在低负载下，多验几个 token 代价不大；可一旦到了高并发场景，不必要的验证会占用 batch capacity，反而拖慢整体吞吐。

这就是 DSpark 出手的地方：它不是只修一个点，而是把这两个问题一起处理。

DSpark 的核心思路

DSpark 其实只有两件事，但这两件事做得很到位。

第一件事：把纯并行草稿改成半自回归生成

DSpark 保留了一个高吞吐的 parallel backbone，但在它后面加了一个非常轻量的 sequential block，用来补 block 内 token 的局部依赖。
这相当于把“快”保住了，把“准”补上了。
Markov head 版本尤其值得注意，它只依赖前一个 token，结构足够简单，但对减少 suffix decay 已经很有效。

从工程角度看，这个设计很聪明。
因为如果你把 drafter 完全做成 autoregressive，它会变慢；但如果你完全做成 parallel，它又会在后半段越来越不稳。
DSpark 的半自回归结构，相当于用一个很小的顺序模块，换来后缀一致性的明显提升。

第二件事：把验证长度变成动态调度问题

DSpark 不再默认“验证越长越好”，而是让 confidence head 估计每个 draft token 的 survival probability，再结合当前系统负载，动态决定这一轮到底验证多少 token。
这件事的意义很大，因为它把 speculative decoding 从一个纯算法问题，变成了一个和系统吞吐联动的调度问题。
也就是说，DSpark 关心的不只是“这个 token 能不能被接受”，还关心“现在把算力花在它身上值不值”。

为什么它不是“又一个 speculative decoding 变种”

很多 speculative decoding 工作，其实都卡在一个老问题上：
要么 drafter 做得很快，但质量不够；要么 drafter 做得更稳，但速度掉得太多；要么 scheduler 设计得很聪明，但只适合离线或低并发场景。

DSpark 的不同之处在于，它同时处理了三个层面：

• 模型层：通过半自回归结构提升草稿质量。

• 概率层：通过 confidence head 估计 prefix survival probability。

• 系统层：通过 hardware-aware scheduler 把验证预算和负载挂钩。

这三层是连在一起的，不是独立堆起来的。
如果没有半自回归，confidence head 的价值会变弱，因为后缀太容易掉；如果没有校准，scheduler 会因为概率不准而做错预算；如果没有系统负载感知，验证长度即使选得“对”，也未必“划算”。

这就是 DSpark 看起来模块不算多，但整体效果很强的原因。

离线结果说明了什么

论文在 Qwen3-4B、8B、14B 和 Gemma4-12B 上都做了离线 benchmark。
结果很一致：DSpark 的 accepted length 在数学、代码、聊天三个领域都优于 Eagle3 和 DFlash，说明它不是只在某一个任务上有效，而是对不同类型的 token 分布都有稳定收益。

这一点很重要，因为 speculative decoding 的收益本来就强依赖任务分布。
结构化任务，比如代码和数学，通常更容易获得较高接受率；而开放式聊天更容易发生后缀不稳定。
DSpark 在这些领域都能保持优势，说明它的 sequential head 确实在改善 block 内一致性，而不是只做了一个表面上的“多 token 预测”。

为什么并行 drafter 还能赢过自回归 drafter

论文里有一个很有意思的分析：
看上去 autoregressive drafter 更“符合语言生成逻辑”，但在 speculative decoding 里，纯并行 drafter 有时反而能拿到更长的 accepted length。

原因不难理解。

在 block 的第一个位置，parallel drafter 往往更有容量优势。
因为它不用把计算成本摊到每一个 step 上，所以可以用更深的网络，第一步预测通常更强。
而 speculative decoding 是一个 prefix survival 过程，第一个 token 往往最关键，一旦第一步被拒绝，后面全作废。
所以并行 drafter 在前面位置的容量优势，会被放大成最终 accepted length 的优势。

但问题也出在这里：
并行 drafter 只在开头占优势，到了后面 token，它因为缺少依赖建模，很容易 suffix decay。
这也是 DSpark 必须加 sequential head 的根本原因。

半自回归到底补了什么

DSpark 的半自回归结构，真正补的是“块内一致性”。
并行 backbone 先把整个 block 的基础分布算出来，然后 sequential head 再根据前面已经采样出来的 token，修正后续 token 的 transition bias。
这样一来，后面的 token 不再只是“和 prompt 对齐”，而是也会“和前一个已采样 token 对齐”。

这个设计的效果在实验里很直观：
随着 drafter depth 增加，DSpark 的 accepted length 会稳步提升；随着 proposal length 增长，DSpark 相比纯并行 drafter 的优势还会进一步扩大。
换句话说，block 越长，DSpark 的相对优势越明显。
这说明它并不是只适合短 block 的小修小补，而是真的能把长 block speculative decoding 的收益吃出来。

置信度调度为什么比固定阈值更实用

如果只做一个固定阈值截断，其实已经能看到一些收益。
阈值越高，accepted rate 通常越高，因为低价值 token 被提前剪掉了。

但固定阈值的问题也很明显。
它只看 token 本身，不看系统负载。
而真实线上服务里，验证一个 token 的代价并不是恒定的：在低并发时它几乎不痛，但在高并发时，它可能正好挤占了别的请求的资源。

这也是 DSpark 选择做 hardware-aware prefix scheduler 的原因。
它不是简单地挑“置信度高”的 token，而是在当前负载下，挑那些对整体吞吐最有价值的 token。
这个思路非常适合生产系统，因为它让验证预算从“静态规则”变成了“动态资源分配”。

线上部署为什么更关键

真正能说明 DSpark 价值的，其实是线上部署。
论文把它放进了 DeepSeek-V4 的生产 serving 系统里，在真实用户流量下测了吞吐和 per-user generation speed。
结果显示，在匹配吞吐的条件下，DSpark 能明显提升单用户生成速度，而且还能在严格 SLA 下维持系统可用性。

这意味着 DSpark 不是只在“论文指标”上好看，而是真的在生产环境里改变了 throughput–interactivity 的前沿。
这点很重要，因为很多模型加速方法最终都死在一个地方：实验室里能提速，线上一上高并发就把系统拖垮。
DSpark 反过来做到了：它不仅提速，还能让系统在更严格的交互约束下继续工作。

如果你觉得这篇文章对你有帮助，也欢迎给我一个三连击：点赞、转发和在看；如果可以，再帮我点一个⭐️。谢谢你看到这里，我们下篇再见。