Speculative Decoding 为什么能降低 LLM 解码延迟？

它让小模型先生成多个候选 token，再由大模型一次前向集中校验，接受率较高时可以减少大模型逐 token 串行前向的次数。

Speculative Decoding 会改变目标模型输出吗？

正确实现时，target model 仍负责验证和采样校正，目标是在保持目标模型输出分布一致的前提下提升推理速度。

它适合所有推理场景吗？

不适合。它更适合低 batch、长输出、draft model 足够快且接受率稳定的场景；高 batch 或极短输出场景收益可能较小。

Speculative Decoding 实战：为什么小模型草稿 + 大模型校验能降低 LLM 解码延迟

大模型推理慢，很多时候不是因为每一步都特别复杂，而是因为生成过程天然是串行的：模型先生成第 1 个 token，再把它放回上下文里生成第 2 个 token，如此循环。即使 GPU 很强，输出长文本时也会被一次次前向计算拖住。

Speculative Decoding（也称 Assisted Decoding）是一种很实用的推理加速思路：先让一个更小、更快的 draft model 猜出后面几个 token，再让大的 target model 一次性验证这些候选 token。验证通过的 token 直接进入输出，验证失败的位置再按目标模型的分布重新采样。这样既减少了大模型的串行前向次数，又尽量保持与原目标模型一致的输出分布。

一、为什么 LLM 解码会慢

训练阶段可以把大量 token 并行送进模型，但生成阶段不一样。自回归模型必须知道前一个 token，才能预测下一个 token。这个依赖链导致生成阶段很难简单地把所有输出 token 一次算完。

对于在线问答、代码助手、智能客服这类场景，用户最直接感受到的是两个指标：

指标	全称	含义
TTFT	Time To First Token	首 token 延迟
TPOT	Time Per Output Token	后续每个 token 的平均生成延迟

KV Cache 可以减少重复计算历史上下文，PagedAttention 可以改善显存管理，但它们并没有改变”逐 token 解码”的基本形态。Speculative Decoding 解决的是另一个问题：能不能让大模型一次前向验证多个候选 token，从而减少大模型的调用次数？

二、核心流程：draft → verify → accept / reject

Speculative Decoding 的基本流程可以拆成四步：

第一步：小模型 draft。 系统使用一个轻量 draft model，根据当前上下文快速生成若干候选 token，例如一次猜 4 个或 8 个。

第二步：大模型 verify。 target model 不再只验证一个 token，而是把 draft model 给出的多个候选 token 放到同一次前向计算里验证。

第三步：接受或拒绝。 如果候选 token 与 target model 的分布一致，或者满足采样校正规则，就接受这些 token；如果某个 token 不通过验证，则从该位置开始回退，并由 target model 按原始分布重新采样。

第四步：进入下一轮。 已接受的 token 成为新上下文，再继续下一轮 draft 和 verify。

这个流程的关键不是”小模型替代大模型”，而是”小模型提出草稿，大模型集中验收”。大模型仍然是最终裁判，因此在正确实现时可以保持目标模型的输出分布。

三、它为什么能加速

普通解码中，如果要生成 4 个 token，大模型通常要串行跑 4 次前向。Speculative Decoding 让小模型先快速生成 4 个候选 token，然后大模型用 1 次前向 验证这 4 个 token。

如果接受率较高，大模型的昂贵前向次数就会下降。比如 draft model 一次提出 4 个 token，其中 3 个经常被接受，那么系统平均每轮就能推进多个 token，而不是每次只推进一个 token。

加速收益主要来自三个条件：

draft model 足够快 —— 额外开销不能吃掉收益；
draft token 接受率足够高 —— 否则频繁回退会浪费计算；
请求 batch 较小或低延迟场景 —— 大模型串行解码瓶颈更明显。

这也是为什么很多推理框架会强调：Speculative Decoding 更适合低 batch、长输出、对延迟敏感的场景；在高并发大 batch 场景里，它未必一定比成熟的连续批处理更划算。

四、工程落地要看哪些指标

落地 Speculative Decoding 时，不建议只看平均 tokens/s。更实用的指标组合如下：

指标	说明
TTFT	是否影响首 token 延迟
TPOT	每个输出 token 的平均延迟是否下降
acceptance rate	draft token 被 target model 接受的比例
accepted length	每轮平均接受多少个 token
draft overhead	draft model 本身带来的额外耗时
GPU utilization	target model 是否真的减少了空转和串行等待
memory overhead	同时加载 draft model 是否增加显存压力
quality parity	输出质量是否与不启用 speculative decoding 时保持一致

其中最关键的指标是 acceptance rate 和 draft overhead。一个很强但不够快的 draft model 可能会拖慢整体流程；一个很快但预测太差的 draft model 又会导致大量拒绝。工程上通常要在”快”和”准”之间找平衡。

五、draft model 怎么选

draft model 不一定越大越好。它的目标不是单独生成高质量答案，而是尽可能低成本地猜中 target model 接下来会接受的 token。

实践中可以优先考虑：

与 target model 使用相同 tokenizer，减少 token 对齐问题；
模型结构和训练语料尽量接近 target model；
延迟足够低，最好能明显快于 target model；
在目标业务语料上接受率稳定；
部署后不会显著挤占 target model 所需显存。

如果 tokenizer 不一致，候选 token 的对齐和重编码成本会增加，接受率也可能明显下降。Hugging Face 的 Universal Assisted Generation 尝试缓解不同 tokenizer 的限制，但常规工程落地中，优先选择 tokenizer 一致的 draft / target 组合仍然更稳。

六、常见误区

误区一：Speculative Decoding 一定会提速

实际收益取决于 draft model 延迟、接受率、batch size、输出长度和采样策略。短输出、高随机采样、高 batch 推理都可能让收益变小。

误区二：draft model 越强越好

强模型通常更慢，如果它的成本接近 target model，就失去了”低成本草稿”的意义。

误区三：它会改变模型能力

Speculative Decoding 本质是推理调度和采样校正方法，不是训练方法。它不让目标模型更聪明，只是让目标模型少做一部分串行工作。

误区四：只要 tokens/s 变高就够了

在线服务还要看 P95 / P99 延迟、显存占用、失败回退、监控和灰度策略，不能仅凭吞吐指标做决策。

七、适合的使用场景

适合的场景：

单请求或小 batch 的低延迟生成；
输出较长的问答、总结、代码生成；
target model 很大，而 draft model 很小且预测稳定；
可以接受额外加载一个 draft model；
有能力监控接受率和回退成本。

不太适合的场景：

极短输出；
已经通过高 batch 把 GPU 打满的吞吐型服务；
draft / target tokenizer 难以对齐的模型组合；
强随机采样导致候选 token 很难被接受的场景。

八、上线建议

如果要在生产系统里启用 Speculative Decoding，可以按下面路径推进：

阶段	目标	关键动作
第一阶段：离线评估	确认收益基线	选择真实业务 prompt，对比关闭和开启 speculative decoding 的 TTFT、TPOT、吞吐、接受率和输出一致性
第二阶段：小流量灰度	验证线上表现	只对低 batch、长输出、稳定任务类型启用，不要一开始全量打开
第三阶段：动态开关	精细化控制	按模型、任务类型、输出长度、服务负载决定是否启用 speculative decoding
第四阶段：持续监控	保障服务质量	重点监控 acceptance rate、draft overhead、P95 / P99 延迟、GPU 利用率和错误回退

常见问题 FAQ

Speculative Decoding 会不会降低回答质量？

正确实现时，target model 仍然负责验证和采样校正，因此目标是保持与原模型一致的输出分布。但工程实现、tokenizer 对齐和采样策略都需要认真验证。

它和 KV Cache 是替代关系吗？

不是。KV Cache 减少历史上下文重复计算，Speculative Decoding 减少 target model 的串行前向次数。两者可以同时使用。

为什么低 batch 场景更适合？

低 batch 时，大模型逐 token 解码的串行延迟更明显。高 batch 场景下，连续批处理本身已经能提升 GPU 利用率，Speculative Decoding 的额外收益可能被 draft 开销抵消。

draft model 要不要单独训练？

不一定。可以先用同系列小模型做 draft model。但如果业务场景固定，专门优化 draft model 可能进一步提升接受率和延迟收益。