推测解码（Speculative Decoding）：更快回答，且不损失质量

一个小型草稿模型提前猜测多个 token，大模型再整块进行验证——同样的答案生成速度明显更快。

基本问题

语言模型通常是逐个生成 token，每一个 token 都需要模型完整地运算一遍。对于大模型来说，这样一次运算的代价很高——响应时间直接随 token 数量增长。

背后的思路

推测解码（Speculative Decoding）使用一个小型、快速的“草稿模型”（Entwurfsmodell），一次性提出多个候选 token。随后，大型目标模型在一次运算中一并验证这些候选 token，而不是逐个单独生成每个 token。

为什么这样能提速却不改变质量

如果草稿模型和目标模型的判断一致，就可以一次性采纳多个 token——大模型的一次运算就能产出多个 token，而不只是一个。如果草稿有偏差，目标模型会丢弃错误的 token，并在该位置自行生成正确的 token。最终结果在数学上与大模型独自生成的结果完全一致——只是达成结果的路径被并行化了。

真正改变的是什么

只有响应时间会缩短，通常缩短 2 到 3 倍。输出本身与不使用草稿模型时的结果完全相同——推测解码是一种纯粹的服务端加速手段，不是提示词技巧，也不涉及质量上的取舍。

示例

不使用推测解码：大模型逐个 token 生成，每个都单独验证并生成——20 个 token 需要 20 次完整的运算。使用推测解码：一个小型草稿模型一次性提出 5 个 token（“法”、“国”、“的”、“首都”、“是”），组成“法国的首都是”。大型目标模型在一次运算中验证全部 5 个，全部认可，并直接自行生成第 6 个 token（“巴黎”）——只需大模型完成一次完整运算就能得到 6 个 token，而不是六次单独运算。

🛠️ 练习——自己动手试试

查明你所使用的模型环境是否采用了推测解码，并观察其对响应时间的影响。

查阅你的服务商或推理服务器（例如 vLLM、TensorRT-LLM）的文档，了解推测解码是否可以配置、以及如何配置。
如果可以切换该功能，就用同一个较长的请求分别在开启和关闭推测解码的情况下各测试一次。
比较两次运行所测得的响应时间。
逐字符比较两次回答的内容。

✅ 自查清单

☐ 开启推测解码后，响应时间是否明显更短？
☐ 两次回答的内容是否真的完全一致，正如理论所预测的那样？
☐ 你能解释为什么一个匹配度不高的草稿模型会降低加速效果吗？

小测验

为什么推测解码能产生与大模型单独生成时完全相同的输出，只是速度更快？