推测解码：从零到DSpark

本文在Muse Spark的协助下起草、编辑和生成图表。所有错误均由它承担。

最近DeepSeek团队发表了一篇新论文《DSpark》，我想了解它在常规推测解码之外增加了哪些新内容。推测解码的基本技巧是：先廉价地草拟（draft）若干个token，然后用大模型一次通过验证这些token。DSpark在此基础上提出了两个改进：更好的长序列草拟，以及一种更智能的策略来决定在生产环境中验证多少个草拟token。

1. 解码为何缓慢

自回归模型每次前向传播生成一个token，每次前向传播都必须将每个权重矩阵从HBM（高带宽内存）流式传输到算术单元。对于一个70B参数、16位精度的模型，每个token大约需要读取140 GB的数据。相比之下，算术运算量极小：大致每次乘法-累加对应一个权重。一台H100每秒可执行约1015次乘法-累加，但读取速度仅为约3 TB/s。解码受限于内存带宽；乘法器空闲等待权重。

这个问题的突破口在于：权重读取是按前向传播次数计费，而非按token数量。如果你一次前向传播处理八个token位置，权重只读取一次，然后与八个向量相乘。内存流量几乎没有变化；额外的算术运算正好利用了原本空闲的计算能力。这就是我们熟悉的预填充/解码（prefill/decode）差距。解码无法像预填充那样进行批处理，因为token t+1在token t的前向传播完成之前并不存在；但如果有人能猜出接下来的八个token，那么大模型就可以像预填充一样，一次前向传播检查这些token。验证过程呈现预填充形态，而生成过程呈现解码形态。这正是推测解码的核心思想：将缓慢的生成转化为快速的验证加上一次廉价的猜测。

2. 循环过程及其无损特性

一个小型的草稿模型提出一个长度为γ的token块。目标模型一次性验证整个块，从左到右依次检查：接受、接受……直到第一个不一致的地方。好处在于，拒绝并非浪费，因为目标模型已经在那个位置计算了一个分布，并从中采样出一个修正token。如果全部接受，这一轮还会从块末尾之后的位置获得一个奖励token。

输出结果在分布上与目标模型独自生成的结果完全一致，这归功于拒绝采样规则：以概率min(1, pt(xk)/pd(xk))接受草拟token xk，若被拒绝，则从norm(max(0, pt − pd))中重新采样。一个很好的推论是，每个位置的接受概率等于1减去草稿模型与目标模型之间的总变分距离——DSpark后面把这个量当成了一个免费的训练标签。

每个token的延迟为(T_draft + T_verify)/τ，其中τ是每轮获得的token数。因此，你可以草拟得更快、草拟得更好（提高τ），或者验证得更聪明。DSpark瞄准了其中的两个方向。

3. 两种草稿模型家族及其并行方案的缺陷

自回归草稿模型（如EAGLE、DeepSeek的MTP）逐个生成草拟token。它们生成连贯，但T_draft与γ成正比，因此必须保持浅层（EAGLE仅一层）并使用较小的块。并行草稿模型（如Medusa、DFlash）一次完成所有γ个位置的填充。它们输入锚点token和掩码token，并在所有位置输出logits。正因如此，它们可以使用深层结构（DFlash使用了5层）和长块。

DFlash的核心技巧是KV注入：在预填充时，从目标模型的若干层中保存隐藏状态，投影到草稿模型的宽度，然后预置到草稿模型每一层的键和值中。草稿模型并不是靠自己的5层来理解对话，而是读取大模型的笔记！

但是并行草稿模型是独立预测各个位置的。在上下文“Sure,”中，目标模型喜欢“of course”和“no problem”；从每个位置的边际分布独立采样可能会产生一个问题：两个有效答案的片段拼接成垃圾。这种多模态碰撞（自非自回归机器翻译以来就已为人所知，Gu et al. 2018）表现为后缀衰减：条件接受概率随块中位置快速下降。

4. DSpark思路#1：在并行草稿模型上附加一个二元语法头

DSpark保留了昂贵的5层并行骨干网络，仅在几乎零成本的环节添加自回归：一个小型的顺序头从左到右遍历块，并添加一个依赖于刚刚采样的token的logits修正。默认头是一个学习的二元语法：一个V×V的修正表，以秩256进行分解存储，因此每个位置只需一次查找加上一次小型矩阵向量乘法。现在，当位置1采样到“of”时，二元语法会提升“course”的概率并抑制位置2的“problem”。

作者还尝试了一个RNN头，用于携带整个块内的前缀信息。但效果提升很有限。我认为这个近乎零的结果是论文中最有用的部分：后缀衰减主要是相邻token的不连贯性，而非缺失长距离信息。KV注入已经为每个位置提供了完整的对话上下文。

在Qwen3-4B/8B/14B上，DSpark的接受长度比Eagle3高出27–31%，比DFlash高出16–18%，而且2层的DSpark已经超越了5层的DFlash。

DSpark将昂贵的草稿计算保持为并行，然后添加一个廉价的顺序马尔可夫头来改善块内连贯性。

5. 服务化问题

以上都是单用户场景。在生产环境中，一个目标模型同时服务数百个并发请求，每次前向传播处理一个批次。这个批次是一种共享的有限资源：当批次较小时，前向传播受内存带宽限制，额外的token几乎免费；一旦超过某个大小，前向传播转为计算受限，每个额外的token都会拖慢所有人。每个推理引擎都有一条特征性的SPS曲线（每秒处理步骤数 vs. 批次大小），先平坦后下降。

每个提交验证的草拟token都会占用一个批次槽位，而被拒绝的token则浪费了其槽位。更糟的是，接受概率依赖于内容。数学问题上每轮约接受5.6个token，代码问题约5.1个，聊天约3.5个（Qwen3-4B）。这意味着没有固定的验证长度。正因如此，DeepSeek的生产系统尽管有多token草稿模型可用，却仍运行MTP-1（每轮一个草拟token）：更长的静态草拟在高并发时会损害总吞吐量。在γ=1时，加速比的上限大约是2倍。

当批次受内存带宽限制时，额外的验证token几乎免费，但一旦系统变为计算受限，它们就变得昂贵。

6. DSpark思路#2：根据预期吞吐量调度验证

调度器不采用统一的验证长度，而是为每个请求、每一步选择一个验证长度，以最大化预期的每秒token数：每批次输出的预期token数乘以在该批次大小下的SPS。

缺失的一环是每个草拟token的生存概率。为此，他们使用了一个置信度头——一个线性投影，作用于骨干网络的隐藏状态加上马尔可夫嵌入，预测每个位置的条件接受概率；通过链式法则将条件概率转化为生存概率。其训练标签是免费的：精确的接受概率（1−TV距离）在每次训练步骤中均可计算。然后通过对每个位置使用温度缩放进行校准，将预测与观察之间的差距从3–8%缩小到约1%。

由于单个请求内生存概率是单调递减的，一个贪心算法即可奏效：你需要汇集所有请求的所有候选扩展，按生存概率排序，从顶部开始接纳，直到吞吐量不再提高。轻负载时，调度器会验证较长（每个请求4–6个token）；当批次填满时，预算收缩。一个代码请求在置信度0.9时可以保持长验证，而一个聊天请求若置信度崩溃，则在位置2就被截断。

一个微妙之处：无损要求非预期性——是否接纳token k不能依赖于token k的值。对接纳路径进行朴素argmax会违反这一原则，因为位置k+1的置信度依赖于具体采样了哪一个xk，从而使输出偏向于具有自信延续的token。

7. 在真实引擎中运行

DeepSeek的实际引擎中会遇到两个问题。SPS曲线是锯齿状的（受内核tile边界影响），因此提前停止搜索会陷入局部最优。此外，在CUDA图形重放（CUDA-graph replay）机制下，下一批的大小必须在本轮前向传播完成之前固定下来，但调度器需要尚未产生的置信度分数。

他们的解决方法是：提前两步（基于旧的置信度分数）计算批次的token容量K，然后在最后一刻通过对活跃候选进行排序来填充这K个槽位。这同时也因构造而恢复了无损性，因为截断是在这一步的任何token产生之前就固定好的，并且排序过程从不查询token k或它之后的任何内容。同一个设计选择解决了流水线停顿和精确性证明问题；我猜测先有流水线限制，后来才注意到无损性论证。

在DeepSeek-V4-Flash和V4-Pro上，面对实际流量，与原有的MTP-1相比，在中等并发度下验证预算维持在每请求4–6个token，并随着负载增加自动缩减。

8. 真正需要记住的内容

早期的工作大多聚焦于如何构建更好的草稿模型：更廉价、更深、更准确。DSpark表明这只是故事的一半。在真实服务系统中，问题不在于“我能草拟多少个token？”而在于“当前哪些草拟token值得花费目标模型的批次容量？”一个半自回归的马尔可夫头使得长并行草拟更连贯；一个感知吞吐量的调度器则根据当前负载决定每个草拟需要验证多少。

开放问题： SPS表忽略了上下文长度混合；置信度头是在教师强制（teacher-forced）前缀上训练的，但在采样前缀上部署；校准是否能承受实时流量漂移尚未报告；而且草稿模型每次请求仍然要进行完整的γ块前向传播。

参考文献

• Cheng et al. (2026), DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation

• Chen et al. (2026), DFlash: Block Diffusion for Flash Speculative Decoding

• Leviathan et al. (2023); Chen et al. (2023) — speculative sampling

• Li et al. (2024, 2025) — EAGLE, EAGLE-3

• Cai et al. (2024) — Medusa

• DeepSeek-AI (2024), DeepSeek-V3 Technical Report (MTP objective)

• Gu et al. (2018) — non-autoregressive NMT, multi-modal collision

• Kwon et al. (2023) — vLLM; Zheng et al. (2023) — SGLang

• DeepSeek-AI DeepSpec repository