推测解码是什么？为什么小模型先写草稿，能加快大模型生成？

知识点详解：写草稿增加了工作，为什么仍可能省时间？

普通生成在等什么？

假设目标模型要继续生成一段话。得到第一个 Token 后，才能把它放回前缀，继续决定第二个。这个前后依赖让生成阶段带有串行过程。

每一步还需要读取模型权重和历史缓存。尤其在某些小批量负载下，硬件并不一定被充分利用。

因此，减少目标模型必须串行推进的轮次，可能比单纯减少一点算术更有帮助。这个判断仍然取决于实际执行环境。

草稿模型先提供了什么？

草稿模型根据当前已确认的前缀，快速提出一小串候选。比如先提出 a、b、c、d。

目标模型读取这段已知候选前缀，就可以在一次前向计算里，得到各候选位置所需的预测分布。因果掩码仍然存在，每个位置只能读取允许的前缀，不是让后面的答案反过来提示前面。

“并行验证”说的是这次计算可以同时处理多个已给定的位置。最终能接受多少，仍然要按前缀顺序判断。

第三个被拒绝，为什么后面也要处理掉？

假设 a、b 被接受，c 被拒绝。草稿的 d 是在“前缀包含 c”的情况下生成的，而当前真实前缀已经不包含这个 c。

因此不能跳过 c，把 d 直接接上。系统先在拒绝位置产生纠正 Token，再基于新的已确认前缀进入下一轮。

当一整段草稿全部被接受时，经典算法还可以利用目标模型这轮已经算出的分布，增加一个后续 Token。不同推测解码实现有不同安排，不能只凭“草稿长度四”推断一轮固定输出四个。

怎样维持目标模型的分布？

在经典精确采样中，一个草稿 Token 的接受概率与目标模型概率 p 和草稿模型概率 q 有关，典型形式为 min(1, p/q)。拒绝时再从相应的纠正分布采样。

接受与纠正共同作用，才维持目标分布。如果简单选择“概率看起来够高”的草稿，或者随意改拒绝后的采样方式，就不再自动拥有这个保证。

具体推导可参考 推测解码原始论文。本文强调的是机制边界，不把所有标着“推测”的加速实现都说成同一种精确算法。

维持分布也不等于两次随机生成逐字一致，更不代表目标模型的答案一定正确。

草稿长度怎么选？

候选多一些，可能一次接受更多 Token；但也会增加草稿生成与验证工作。越往后的候选越可能依赖前面的偏差，被丢弃的工作也会增加。

如果每轮只接受很短前缀，就需要缩短草稿、换更匹配的草稿机制，或者直接停用。接受率很高也不能单独证明更快，还得看额外工作花了多少时间。

评测时应使用相同的目标模型、采样配置、输入与硬件，比较输出 Token 吞吐、整次请求延迟、接受长度、草稿开销和显存。长输出、小批量与高并发，值得分别测。

面试官继续追问

草稿一定是一个独立小模型吗？

不一定，工程实现还可能使用其他候选生成方式。标题用小模型解释常见方案，但关键仍是快速提议与目标验证的配合。

它能解决首个 Token 太慢吗？

主要收益通常落在后续生成过程。输入处理、调度等待和首个 Token 的耗时，还需要单独分析，不能统一归功于推测解码。

推测解码和量化，哪个更好？

优化对象不同。量化改变数值表示与执行成本，推测解码改变生成推进方式。是否组合，需要检查实现、质量和实际负载收益。

面试速记卡

• 快速草稿提出候选，目标模型保留最终采样决定。
• 多个候选位置可在一次目标前向计算中验证。
• 接受按前缀推进，拒绝以后不能随意接上后续草稿。
• 精确算法依靠接受与纠正共同维持目标分布。
• 分布不变，不等于随机输出逐字一样。
• 接受率、草稿开销与硬件负载共同决定加速。