刚刚过去的周末，DeepSeek 发布了一篇关于推理加速的新论文：《DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation》，内容聚焦在大模型推理服务中的一个具体问题：在真实高并发场景下，Speculative Decoding 如何既提升生成速度，又减少目标大模型的无效验证计算？
Speculative Decoding 是一种“轻量模型先生成草稿，目标大模型再批改确认”的加速方法。它的目标，是在尽量保持最终输出服从目标模型分布的前提下，让模型一次向前推进多个 token。
这条路线看起来很直接：草稿模型（draft model）多生成一些候选 token，目标模型一次性验证。如果草稿足够准确，就能减少逐 token 生成带来的等待。
但在真实服务中，问题会变复杂。Draft block 变长，不代表最终被目标模型接受的 token 更多；verification 可以并行，也不代表验证越多越划算。尤其在高并发的在线推理服务中，目标模型的 batch capacity 是有限资源，低置信度 token 的验证会直接影响整体吞吐。
所以，DSpark 关注的核心问题不是“如何让草稿模型（draft model）多猜几个 token”，而是：如何让 draft token 更容易被接受，同时让目标模型只验证更值得验证的 token。
围绕这个问题，DeepSeek 提出了两个设计：用半**自回归生成缓解并行 draft 的后缀质量衰减；用置信度调度，根据 token 被接受的概率和系统负载动态决定 verification length**。
接下来，我们先看 DSpark 要解决的两个关键问题。
为什么并行 draft 后面的 token 容易掉队？
在 Speculative Decoding 中，草稿模型（draft model）的作用是提前生成候选 token。为了提高草稿生成速度，一个直接思路是让草稿模型（draft model）一次生成更长的 draft block。
Draft block 可以理解为草稿模型（draft model）在一轮中提前生成的一整段候选 token。直觉上，draft block 越长，目标模型一次接受更多 token 的机会就越大。
但真正决定加速效果的，不在于 draft block 有多长，关键是 accepted length 能有多高。
Accepted length 指的是每一轮 Speculative Decoding 中，草稿 token 最终被目标模型接受的平均数量。它越高，说明模型每一轮可以向前推进更多 token，加速效果也越明显。现在的问题是长 draft block 并不天然带来更高 accepted length。
对于现有草稿模型（draft model），大体可分成两类。
第一类是 autoregressive drafter，也就是草稿模型自己也按顺序一个 token 一个 token 地生成。这样做的好处是，后面的 token 可以依赖前面已经生成的 token，所以序列更连贯；缺点也同样明显：草稿生成本身会变慢，block 越长，draft 的计算时间越长。
第二类是 parallel drafter，也就是一次性并行生成一整段候选 token。它的优势是快，因为所有位置的 token 可以在一次 forward pass 中同时生成。Forward pass 可以理解为模型完成一次从输入到输出的完整计算过程。
但并行生成也有一个结构性问题：每个位置的 token 是同时预测的，后面的 token 并不知道前面实际采样出了什么。
DeepSeek 举了一个很直观的例子。比如上下文后面既可以接 “of course”，也可以接 “no problem”。这两个续写本身都合理。但如果每个位置独立预测，模型可能把不同续写路径混在一起，生成 “of problem” 或 “no course” 这样的组合。
这类问题被称为 multi-modal collision，意思是“多个合理续写方向被混在了一起”。这会导致一个结果：draft block 越往后，token 越容易不连贯，也越容易被目标模型拒绝。这种现象也叫 suffix decay，可以理解为“后缀接受率衰减”。用一句话说，就是草稿越往后，越容易掉队。
如上图所示，重点看不同 draft position 上的 conditional acceptance。Conditional acceptance 可以理解为：在前面 token 都已经被接受的前提下，当前位置 token 继续被接受的概率。
这张图要说明的是：DFlash（上图蓝线）这类纯并行 drafter 在前几个 token 上有较强预测能力，但越往后，conditional acceptance 会明显下降。也就是说，它不是不能快速生成 draft，只是越往后越容易猜偏。
这正是并行 draft 的核心问题：它在猜一整段时，不知道自己前面到底猜中了哪条语义路径。
因此，DSpark 要解决的第一个问题是：能不能保留并行生成的速度，同时让后面的 token 感知到前面已经生成的内容。
为什么 verification 在高并发服务里不能无脑做长？
长 draft block 的另一个问题，是 verification 资源浪费。
Verification 可以理解为目标模型对草稿 token 的“批改确认”。在 Speculative Decoding 里，目标模型验证的是连续前缀。也就是说，只要中间某个 token 被拒绝，后面的 token 即使本身质量不错，也会被一起丢弃。
这就带来一个问题：如果草稿模型一次生成了很多 token，但后半段大概率会被拒绝，那么把这些 token 全部送给目标模型验证，就可能是在浪费算力。
在单个请求、低负载场景下，这种浪费也许不明显。但在真实高并发服务中，问题会被放大。
因为目标模型的 batch capacity 是有限的。Batch capacity 意思是同一轮推理中，GPU 能同时处理多少请求或 token 的计算额度。在高并发情况下，每多验证一个低价值 token，就可能挤占其他用户请求的计算资源。
这也是 DSpark 论文反复强调的工程背景：verification 不是免费的。
同样是草稿 token，代码、数学这类结构化任务通常更容易被接受；开放聊天这种自由度更高的任务，后缀 token 的不确定性更强，被拒绝的概率也更高。
系统低负载时，可以多验证一点；系统高负载时，就要更谨慎地使用验证预算。
所以，Speculative Decoding 的难点不是“能不能多猜”，而是：
草稿 token 是否足够靠谱；
这些 token 是否值得占用目标模型的验证资源。
DSpark 的两个核心设计，正是围绕这两个问题展开的。
DSpark 的第一步：给并行 draft 加一点顺序依赖
针对并行 draft 后缀容易衰减的问题，DSpark 的第一个设计是 Semi-Autoregressive Generation，也就是半自回归生成。
这个名字容易让人误解。它不是让 草稿模型（draft model） 完全回到一个 token 一个 token 的自回归生成，而是在并行生成的基础上，引入一层很轻的顺序依赖。
前面提到，parallel drafter 的优势是快：它可以在一次 forward pass 中生成一整段 draft block。但它的问题也来自这里：多个位置同时预测，后面的 token 不知道前面实际采样出了什么，因此容易出现 multi-modal collision 和 suffix decay。
DSpark 的处理方式是折中。它保留 parallel backbone，也就是负责主要计算的并行主干结构。这个部分仍然一次性处理整个 draft block，保留并行生成的速度优势。
在此基础上，DSpark 额外加入 lightweight sequential head，也就是轻量顺序模块。这个模块的作用，是在 draft block 内给后续 token 补充局部顺序信息，让它们能够参考前面已经采样出来的 token。
上图可以重点看两条路径。
第一条路径是 draft token 的生成。DSpark 先通过并行主干快速生成候选 token，再通过轻量顺序模块补上 block 内的局部依赖。
第二条路径是 confidence score 的生成。DSpark 在生成草稿的同时，也会估计每个位置的 token 有多大概率通过目标模型的动态调度提供依据。
所以，图片展示的不只是一个草稿模型（draft model） 结构，而是 DSpark 的完整解码循环：先生成候选 token，再估计其可接受性，最后决定交给目标模型验证多长的前缀。
在 sequential head 的实现上，DeepSeek 主要讨论了两种方案：Markov head 和 RNN head。
Markov head 是默认方案。它只看前一个已采样 token，用一个轻量的转移偏置来调整下一个 token 的概率分布。
继续用前面的例子理解：如果前一个 token 已经采样成 “of”，Markov head 就会让后续 token 更倾向于走向 “course” 这类更连贯的组合，而不是和另一条语义路径混在一起，生成 “problem”。
RNN head 可以记录更长的 block 内历史，理论上表达能力更强。但论文实验显示，相比 Markov head，它带来的收益有限，同时部署复杂度更高。因此，DSpark 默认采用 Markov head。
这个选择很有工程意味。对于生产级在线推理服务系统来说，额外模块不能只看效果提升，还要看是否足够轻、是否引入明显延迟、是否容易接入现有推理链路。Markov head 不是最复杂的方案，但它在效果、延迟和部署成本之间更均衡。
这里的关键判断是：DSpark 不是放弃并行生成，也不是把草稿模型（draft model）重新变慢，而是在并行生成之后补上一层轻量顺序修正。
DeepSeek 的实验也支持这一点。随着 proposal length 变长，纯并行 drafter 的后缀衰减会更明显，而 DSpark 通过引入局部顺序依赖，能在更长 proposal length 下保持更好的 accepted length。Proposal length 可理解为草稿模型（draft model）每轮尝试生成的候选 token 数量。
如图所示，可以关注这两个信息：一是 proposal length 变长时，DSpark 的 accepted length 优势更明显；二是 sequential head 带来的额外延迟较小。
这说明 DSpark 并不是用显著增加 draft 成本的方式换取接受率，而是用较小的顺序建模开销，补上 parallel drafter 在后缀一致性上的短板。
DSpark 的第二步：verification 不是越长越好，而是要动态调度
如果说半自回归生成解决的是“草稿 token 怎么更容易被接受”，那么 DSpark 的第二个设计，解决的是“哪些草稿 token 值得交给目标模型验证”。
这个设计叫 Confidence-Scheduled Verification，可以理解为基于置信度调度的验证。
它的核心组件是 confidence head，可以看作是一个轻量判断器，用来估计草稿 token 通过目标模型验证的概率。
更准确地说，DSpark 预测的是 prefix survival probability。它指的是：从第一个草稿 token 开始，连续通过验证并“活到当前位置”的概率。
为什么要预测这个值？因为 Speculative Decoding 的验证是前缀式的。如果第 2 个 token 被拒绝，第 3、第 4、第 5 个 token 即使本身质量不错，也会被一起丢弃。所以，第 5 个 token 是否值得验证，不只取决于它自己准不准，还取决于前面 1 到 4 个 token 能不能先通过。
这就是 prefix survival probability 的意义：它不是孤立地判断某个 token 好不好，而是判断这个位置之前的整段前缀有没有机会连续通过验证。
有了这个估计之后，DSpark 还需要决定每个请求本轮到底验证多长。这就是 verification length。
Verification length 指的是一轮 Speculative Decoding 中，每个请求有多少个 draft token 会被送给目标模型验证。
过去比较直接的做法，是设置一个固定长度，或者根据静态阈值决定是否验证。但在真实在线推理服务系统里，这样不够。
因为一个 token 是否值得验证，不只取决于它的置信度，还取决于当前系统负载。
低负载时，目标模型还有空余计算能力，多验证一些高置信 token 可能是划算的；
高负载时，batch capacity 更紧张，低置信 token 就应该尽早被剪掉，避免挤占其他请求的计算资源。
因此，DSpark 引入了 hardware-aware prefix scheduler。它可以理解为一个了解推理引擎吞吐表现和当前系统负载的调度器。
这个调度器会结合两类信息：一类是 token 层面的 prefix survival probability，另一类是系统层面的 engine throughput profile，也就是推理引擎在不同 batch size 下的吞吐曲线。然后，它会为每个请求动态选择更合适的 verification length，把目标模型的验证预算分配给预期收益更高的前缀 token。
这一步的核心变化是：verification length 不再是一个固定超参数，而是一个随请求质量和系统负载变化的调度决策。
这里还有一个细节很重要：confidence head 的输出必须经过校准。
如果模型给出的置信度只是“排序大致正确”，但概率本身不可信，scheduler 就可能误判某些后缀 token 的收益，继续把 batch capacity 浪费在低通过率 token 上。
所以，DSpark 使用 Sequential Temperature Scaling，也就是顺序温度缩放，对 confidence head 的输出做后处理，让预测概率更接近真实接受率。
这个设计说明，在生产系统里，置信度不只是一个辅助分数，而是会参与资源调度的决策信号。它必须足够稳定、足够可信。
这张图重点展示并发负载变化后，verification budget 如何变化。
Verification budget 可以理解为每个请求在一轮中获得的验证额度。并发较低时，scheduler 会分配更长的 verification budget，让目标模型多验证一些高价值 draft token；并发升高后，系统资源变紧，scheduler 会自动收紧 verification length，减少低置信 token 对 batch capacity 的占用。
这就是 DSpark 在 verification 侧的工程取向：有空闲算力时，多验证高价值 token；系统压力变大时，减少低收益验证，把有限的 batch capacity 留给预期收益更高的前缀。
实验结果怎么看？
DSpark 的实验可以分成两部分来看：离线 benchmark 和线上生产部署。
离线实验主要验证 draft 质量，也就是 DSpark 生成的草稿 token 是否更容易被目标模型接受。
线上部署则验证系统价值，也就是 DSpark 在真实流量和高并发的在线推理服务环境下，是否能改善吞吐和单用户生成速度之间的关系。
这两个实验回答的是两个不同问题：
离线 benchmark 关注的是：草稿本身是不是更好？
线上部署关注的是：这套机制放进真实在线推理服务系统后，是否真的更划算？
离线实验：DSpark 的草稿更容易被接受
论文在 Qwen3-4B、Qwen3-8B、Qwen3-14B 和 Gemma4-12B 等目标模型上做了离线评估，任务覆盖数学推理、代码生成和日常聊天。
对比对象包括 Eagle3 和 DFlash。可以简单理解为：Eagle3 代表自回归 drafter，DFlash 代表并行 drafter，而 DSpark 试图在两者之间取一个更适合 在线推理服务 的折中。
如上表所示，不要只看 DSpark 比哪个 baseline 高了多少，更要看它验证了哪个判断：DSpark 的 draft token 更容易被目标模型接受。
论文称，在 Qwen3-4B、Qwen3-8B、Qwen3-14B 上，DSpark 相比 Eagle3 的宏平均 accepted length 分别提升 30.9%、26.7%、30.0%；相比 DFlash 分别提升 16.3%、18.4%、18.3%。
这说明 DSpark 的收益不是来自“生成更多 token”本身，而是来自“生成出来的 token 更容易被接受”。换句话说，它确实缓解了并行 drafter 后缀不稳定的问题。
此外，DeepSeek 还观察到一个重要现象：不同任务之间的 accepted length 差异很明显。数学和代码这类结构化任务更容易获得较高 accepted length，而开放聊天任务更低。
这不是简单的模型优劣问题，而是任务分布本身不同。结构化任务通常有更明确的推理路径、代码模式或答案约束，draft token 更容易被目标模型接受；开放聊天的续写空间更大，token 不确定性更强，因此后缀 token 更容易被拒绝。
这个结果也反过来支持了 DSpark 的第二个设计：verification length 不应该固定。不同请求本身就有不同的可预测性，系统需要根据 token 的接受概率和当前负载，动态决定验证多长。
线上部署：DSpark 改善了吞吐与交互速度的关系
更值得关注的是，DSpark 不只做了离线 benchmark，还被部署到了 DeepSeek-V4-Flash 和 DeepSeek-V4-Pro 的生产级在线推理服务系统中。
论文把 DSpark 和 MTP-1 baseline 做了对比。MTP （Multi-Token Prediction ）可以理解为让模型一次预测多个后续 token 的方法；MTP-1 则是论文中用于生产部署对比的既有 baseline。
这里要注意，线上部署实验验证的不是“单个请求能不能更快”，而是整个 在线推理服务系统在真实流量下，能否在系统吞吐和用户可感知速度之间取得更好的平衡。
上面是理解 DSpark 工程价值的关键图。读这张图时，要同时看两个指标：throughput 和 TPS/user。
Throughput 可以理解为系统整体吞吐，也就是单位时间内整个系统能输出多少 token。TPS/user 则可以理解为单个用户看到的生成速度，也就是每个用户每秒能收到多少 token。真实服务中，这两个指标必须一起看。
只让单个用户生成更快不够，系统还要能同时服务足够多请求；只追求整体吞吐也不够，如果单个用户等待太久，交互体验仍然不好。
论文结果显示，在匹配吞吐水平下，DSpark 让 V4-Flash 的单用户生成速度提升 60%–85%，让 V4-Pro 提升 57%–78%。
这组数据的重点不是简单说明“DSpark 快了多少”，而是说明它改善了生产服务里的 throughput–interactivity frontier，也就是系统整体吞吐和单用户交互速度之间的性能边界。
在相同系统吞吐下，用户可以看到更快的生成速度；在更高交互速度要求下，系统仍然能维持更可用的并发能力。
论文中也有一些严格 SLA 点上的相对提升比例非常高，但这需要谨慎理解。SLA 可以理解为系统需要保证的服务体验要求，比如每个用户至少达到多少 token/s 的生成速度。在严格 SLA 下，MTP-1 baseline 已经接近能力边界，所以 DSpark 的相对提升比例会显得很大。
因此，这些数字不适合简单理解成“DSpark 稳定提升几倍”。更准确的理解是：DSpark 把系统原本难以达到的交互性区间往外推了一段，让较高单用户生成速度和可用系统吞吐可以同时成立。
前面的图也进一步解释了这种收益来自哪里：并发较低时，scheduler 会分配更长的 verification budget，让目标模型多验证一些高价值 draft token；随着并发升高，scheduler 会自动收紧 verification length，避免低置信 token 占用关键 batch capacity。
这说明 DSpark 的线上收益并不是只来自“draft 更长”，而是来自 draft 质量和 verification 调度的配合：轻负载时利用空闲算力扩大收益，重负载时减少无效验证保护吞吐。
这篇论文真正值得关注的地方
如果只看表面，DSpark 是一个 Speculative Decoding 框架。但从工程角度看，它的核心关注点更在于：它把大模型推理加速从单纯“生成更多 token”，推进到了“draft 质量 + verification 调度 + 系统负载”的联合优化。
过去我们很容易把推理加速理解成一个模型问题：换一个更快的 decoding 算法，或者设计一个更强的草稿模型（draft model）。但 DSpark 说明，在真实生产级大模型服务里，推理优化不只是模型结构问题，也是系统调度问题。
首先，草稿模型（draft model）不能只追求快。它生成的 token 必须足够容易被目标模型接受，否则长 draft block 只会带来更多无效候选。
其次，verification 不能只追求长。目标模型的计算资源是在线推理服务系统里最关键的资源之一，尤其在高并发场景下，低置信 token 的验证会直接影响系统吞吐。
最后，调度策略必须理解系统负载。同一个 token，在低负载时可能值得验证，在高负载时就未必划算。一个推理加速方法要进入生产环境，就必须和推理引擎的吞吐曲线、batch capacity、请求并发状态一起考虑。
DSpark 给出的答案是：用半自回归生成提升 draft token 的可接受性，再用置信度调度减少无效 verification，把推理加速从单点生成优化推进到系统级资源调度。
当然，DSpark 也不是所有推理加速问题的最终答案。
论文也提到，DSpark 仍然需要先通过 parallel backbone 生成初始 draft block。对于一些本身接受率较低、难度较高的请求，这部分 draft-side cost 可能无法完全回收。未来仍然可以探索 difficulty-aware early exiting，让低接受率请求尽早跳过不划算的 full-block drafting。
这个限制也提醒我们：DSpark 的价值不在于提供一个“一劳永逸”的推理加速方案，而在于给出了一个生产级推理优化样本。
它说明，在高并发大模型服务中，生成速度、草稿质量、验证成本和系统负载，需要放在一起优化。
另外，这篇论文也提供了一个评估推理加速方案的判断框架：以后看一个推理优化方法，不能只看单请求 token/s，也不能只看某个 benchmark 上的速度提升，更要看：
它生成的 draft token 最后有多少真的被接受；
它是否减少了无效 verification；
它在不同负载下是否还能维持系统吞吐；
它是否改善了用户可感知的生成速度；
它的收益是否在真实在线推理服务系统中成立。
这也是 DSpark 对理解生产级推理优化最有参考价值的地方。
论文文献
DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation（alphaxiv.org/abs/2026.dspark）
