Speculative Decoding

一句话解释

推测解码先用较便宜的方法提出多个候选 token，再由目标模型并行验证，以减少目标模型串行 decode 的步数。

仍需实测的变量

  • 解释接受与拒绝过程
  • 区分吞吐提升与单请求延迟提升
  • 对比 Draft Model、Medusa、EAGLE 与 MTP

接受/拒绝的最小流程

1
2
3
4
5
6
已有前缀
→ draft/proposer 生成 k 个候选
→ target model 一次并行验证
→ 按校正规则逐 token 接受或拒绝
→ 接受前缀 + 第一个拒绝位置的修正 token
→ 下一轮

拒绝不代表整段全部作废，通常在第一个不接受位置回退并使用目标模型分布继续；正确性来自验证规则，而不是 draft “看起来像” target。

为什么可能变快

因果链是：一次 draft 生成多个候选 → target 并行验证 → 若平均接受长度高，多个串行 decode 步被摊到一次权重读取 → TPOT/吞吐改善。若接受率低、draft 太慢、验证 kernel 不高效或 batch 太小，额外工作会超过省下的 target 调用，结果反而变慢。

方案 proposer 从哪里来 主要边界
Draft Model 独立小模型 维护模型/词表兼容与接受率
Medusa 目标模型附加预测 head 需要专门训练/权重
EAGLE 目标模型 hidden/features 的预测器 与模型架构和实现耦合
MTP 多 token prediction 训练头 依赖模型是否原生支持

评测要报告接受长度分布、draft/verify 时间、TTFT、TPOT P50/P99、端到端吞吐、显存和输出一致性。它向下依赖 Autoregressive Generation 与 KV Cache，向上影响 Inference Engine Selection。

采样参数会改变接受率

推测解码不是把 greedy decoding 简单换成多 token forward。draft 和 target 必须在 tokenizer、位置编码、词表和采样语义上对齐；temperature、top-p、top-k、repetition penalty 等改变目标分布后，接受/拒绝规则也必须保持一致。一个 draft 在 temperature=0 的贪心任务上接受率很高，不代表它在随机采样或代码任务上仍有收益。

k 也不是越大越好：k 增大可以减少 target 轮次，但会增加 draft 时间、候选 KV、验证 kernel 工作和拒绝回退的浪费。更实际的调参方式是按接受长度分布动态设置 k，并把 draft 时间和 target 验证时间分开记录；若平均接受长度只有 1～2，额外 proposer 往往只是在增加成本。

质量验收不能只看字符串相等

正确的 speculative decoding 应尽量保持 target 分布，但工程实现仍可能在 stop token、logits processor、tool/grammar constraint、batch padding 和 stream 拼接处引入差异。验证时用固定随机种子检查 token-level 分布或接受规则，再用代码、JSON、长文本和工具调用任务检查语义/格式失败率。性能报告要同时给 baseline target-only 与 speculative 的首 token、TPOT、每轮接受数、显存和取消请求浪费。

参考资料