投机解码：突破 decode 一次只出一个 token 的限制

自回归 Decode 的硬约束是：下一个 token 依赖前一个 token，因此 Target Model 通常每步只确认一个位置。投机解码不改变这条依赖，而是让更便宜的 Drafter 先提出一段候选，再由 Target 批量验证并保留可接受的连续前缀。

它只有在“每轮推进的 token 数”足以覆盖草稿、验证与调度开销时才会加速。候选长度、接受率或某个方法名本身，都不是速度结论。

1. 一轮投机解码发生什么

设 Drafter 提出 γ 个候选：

context
  → Drafter 提出 [t1, t2, ..., tγ]
  → Target 一次计算这些候选位置的分布
  → 从左到右验证，接受最长合法前缀
  → 首次拒绝时由 Target 修正；其后的候选作废
  → 进入下一轮

这里有三个容易混淆的量：

量	含义	不能替代什么
γ / proposed length	Drafter 提出的候选数	不等于实际推进数
accepted prefix	首次拒绝前被接受的连续候选	不等于逐 token 独立命中数
τ / step advance	一轮最终推进的 token 数，口径可能包含修正或 bonus token	不说明这一轮花了多少时间

Target 验证可以沿 token 维度形成更大的计算形状，减少逐 token Target step，但它仍有真实计算、KV、调度和 Kernel 成本。不能把它简化为“读一次权重就免费得到 γ 个 token”。

2. 什么时候与 Target 输出分布等价

经典 Speculative Sampling 中，Drafter 和 Target 在候选 t_i 上分别给出概率 q(t_i) 与 p(t_i)：

$$P(\text{accept } t_i) = \min\left(1,\frac{p(t_i)}{q(t_i)}\right)$$

第一次拒绝时，不能直接从原始 p 随便重采样，而应从修正分布取样：

$$p'(t) = \operatorname{normalize}\left(\max(0, p(t)-q(t))\right)$$

若整段候选都被接受，Target 还可从下一位置分布生成一个 bonus token。严格按该接受/修正规则执行，并保持 token 空间、采样参数和随机语义一致时，输出分布才与直接从 Target 采样相同。

“无损”描述的是这个算法合同，不是所有叫 speculative decoding 的实现。Greedy、树状候选、近似验证或改写采样规则时，需要分别说明它保持的是确定性输出、目标分布，还是仅做质量近似。

3. 为什么平均接受长度不等于加速倍数

一轮成本可写成：

$$T_{\text{round}} = T_{\text{draft}}(\gamma) + T_{\text{verify}}(\gamma) + T_{\text{overhead}}$$

若一轮平均推进 E[τ] 个 token，则：

$$\mathrm{TPOT}_{\text{spec}} \approx \frac{T_{\text{round}}}{E[\tau]}$$

这个模型回答的是“收益够不够覆盖成本”，而不是预言固定倍数。至少要同时看：

• Drafter 是串行生成、并行预测，还是复用 Target 特征；
• 后缀的 prefix survival 是否快速衰减；
• Verify 的 shape 是否命中高效 Kernel；
• Batch 是否已让 Target 设备饱和；
• 变长前缀、KV 更新、CUDA Graph 和调度增加多少开销。

因此 γ 太小会限制单轮推进，太大又会增加低价值后缀和验证成本。最优长度是模型、请求内容、硬件、Batch 与 Runtime 的联合结果，不是固定常数。

4. Drafter 的几种设计

路线	候选从哪里来	主要收益	主要成本或边界
独立 Draft Model	同 token 空间的较小模型自回归生成	接入直观，可复用已有模型	额外显存、串行 draft 成本、分布可能不匹配
Feature Drafter（如 EAGLE）	读取 Target 特征的轻量模块	候选更贴近 Target，中间状态可复用	需要匹配的训练产物与 Runtime 支持
多预测头 / 树状候选（如 Medusa、MTP）	多个头并行预测未来位置或分支	降低串行 draft 成本	远位置误差、树状 Attention 与验证布局
Self-Speculative	Target 自身跳层或使用早退路径	不加载独立 Draft Model	跳层策略、状态复用和模型适配决定收益

这张表只比较控制点，不维护引擎支持矩阵。具体部署能力会随版本变化，应以锁定版本的文档、配置回读和 Trace 为准。

5. 哪些场景更值得实验

更有利的组合通常是：Target step 昂贵、Drafter 足够便宜、候选与 Target 高度匹配，并且当前负载下 Verify 还有高效计算空间。低并发延迟场景往往更容易满足这些条件。

以下情况应优先怀疑收益会消失：

• Target 已被大 Batch 吃满，额外 verification token 会占用其他请求容量；
• 接受前缀短，后缀候选大多被浪费；
• 独立 Drafter 占用的显存或算力影响 Target；
• Runtime 为变长候选付出 repack、同步、图切换或调度成本；
• 只优化用户侧 tok/s，却损害 aggregate throughput 或 SLO。

高并发并非绝对不能使用投机解码，但必须把验证预算当作共享资源。DSpark 如何把这一点做成置信度与硬件感知调度，见 DSpark 与 MTP。

6. 最小验收合同

一次可比较实验至少记录：

target: checkpoint, revision, tokenizer
drafter: type, checkpoint or head revision
sampling: temperature, top-p, seed semantics
speculation: proposed length, verification policy, bonus-token semantics
runtime: engine, version, kernel backend, hardware
workload: ISL, OSL, batch or concurrency
metrics: draft time, verify time, accepted length, TTFT, TPOT, throughput
baseline: same Target and workload without speculation

同时明确 accepted length、acceptance rate 和 backend step advance 的统计口径。missing、unsupported、运行失败与不可比较必须分开记录，不能补成零。

延伸阅读

• Speculative Decoding: How to Make LLMs 2-3x Faster — 直观的投机解码解释
• Speculative Decoding for LLM (MLOps) — 工程实践视角
• EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty — EAGLE 原始论文
• BentoML LLM Inference Handbook: Speculative Decoding — 实战手册

相关页面

• vLLM Async Scheduling — placeholder、EAGLE/MTP 状态归属与 accepted-count 同步
• DSpark 与 MTP — 长 Draft、置信度与硬件感知验证预算
• Compute-bound vs Memory-bound — 投机解码为何能在 memory-bound 的 decode 阶段挤出额外带宽
• 推理框架对比 2026 — 按版本核对 Serving Runtime 能力
• LLM 推理系统全栈地图 — 投机解码与量化、调度、KV Cache 的协同和边际收益