DeepSeek DSpark 在真实高并发推理服务中，如何保证 Token 生成又好又快？

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 的输出做后处理让预测概率更接近真实接受率。这个设计说明在生产系统里置信度不只是一个辅助分数而是会参与资源调度的决策信号。它必须足够稳定、足够可信。