07. 推测解码
本篇导读
上一篇减少一轮计算的成本，本篇尝试让一次目标模型前向推进更多结果。像助手先写草稿、审核者再核对：以“先提交申请，再等待”为例，依次观察提出、验证和提交。读完应能解释错误以后为何要作废，以及“接受率高”为什么仍不保证更快。
普通自回归生成每次只确定一个新 token。假如便宜的模型先猜出四个，大模型能否一次检查完？这就是推测解码的基本方向：便宜地提议，目标模型验证，提交符合规则的前缀，拒绝处修正，再继续。
先提议，再验证确定性 greedy 教学模型
草稿候选候选候选候选
目标路径?????
已提交尚未提交
等待提出 4 个候选。
这演示的是 greedy 匹配，未模拟随机采样分布。精确随机推测采样还需要接受概率和拒绝后的修正分布，不能只比较两个模型的最高概率词。
为什么验证可以一起算
生成候选时，后一个 token 还未知，需要顺序提出。验证时，候选已经给定，目标模型可以像 prefill 一段已知输入那样，并行计算多个位置的条件分布。因果 mask 仍然保证每个位置只依赖此前的候选。
这没有消除目标计算，而是把多个位置组织到一次更有效率的前向中。能否省时间，要看一次验证成功推进多少 token，以及草稿和验证各花多少成本。
默认草稿第 3 个 token 错了。前两个可以接受，第 3 个改成目标给出的结果，第 4 个草稿必须作废，因为它是在错误历史之后产生的。把错误改为第 1 个，会看到几乎没有接受收益；改为全对，则可增加一个目标模型产生的额外 token。
Greedy 演示不等于随机采样算法
上面的实验只展示确定性 greedy 匹配。随机采样时，不能简单地“两个模型猜同一个词就收下”。经典精确推测采样利用目标分布 p 和提议分布 q，按相应规则接受或修正。
精确随机采样的关键条件
在线性提议的经典形式中，候选 x 的接受概率为 min(1, p(x) / q(x))。被拒绝时，从与 max(0, p(x) - q(x)) 成比例的修正分布采样。所有候选都接受时，还可以从目标模型的后续分布采样额外 token。
这里的 p 和 q 是对应条件历史下、经过相应采样变换的分布。树形候选、块状验证、greedy 和近似接受各有自己的条件。放宽阈值、跳过修正或换掉验证算法后，不能继续无条件宣称保持原目标分布。“分布等价”也不代表同 seed 下逐字一致。
草稿从哪里来
| 路线 | 如何提出候选 | 需要什么 |
|---|---|---|
| 小 draft 模型 | 较小模型顺序生成 | 配套模型、额外显存、足够相似的分布 |
| N-gram / prompt lookup | 从输入或历史里寻找可延续片段 | 复制、代码与重复模式，通常无需另存模型 |
| EAGLE 系列 | 从目标特征等信息产生草稿 | 与目标匹配的训练结果和验证后端 |
| MTP | 使用训练好的多 token 预测头 | 模型原生结构和引擎适配 |
| 块状草稿路线 | 一次提出候选块再验证 | 配套草稿、块验证和采样正确性支持 |
名称相同也不代表任意模型可用。词表、特征、权重版本、状态布局和后端需要匹配；不能下载一个随意的小模型就期待高接受率。
接受率高，为什么仍可能更慢
举一个纯教学算例：普通目标模型每步 20 ms；一次草稿耗时 8 ms，目标验证耗时 25 ms。如果平均推进 3 个 token，每 token 约 11 ms，有潜在收益；如果只推进 1 个，就是 33 ms，反而更慢。这些数字仅说明成本关系。
text
推测后的平均每 token 成本
≈（草稿耗时 + 目标验证耗时 + 管理成本）/ 本轮实际推进 token 数在高并发中，目标模型可能已通过 batch 高效运行；加入草稿权重和额外 KV 会挤压容量，验证 shape 也可能不理想。单请求提速不保证相同 GPU 下的在线 goodput 增加。
组合功能最容易暴露状态问题
推测被拒绝后，不仅要丢掉 token，还要恢复或调整 KV、递归状态、语法状态和已提交长度。混合模型、结构化输出和树验证一起开启时，状态管理更复杂。
验证应覆盖低接受率、长输入、EOS、stop、取消、schema、混合注意力和多轮任务。框架发布中的正确性修复说明这些组合必须实际测试，不能把每项“支持”打勾后就视为组合正确。
本篇回顾
- 已知候选可以一起验证，验证通过后提交前缀，拒绝处修正并丢弃后续候选。
- 草稿和验证都有成本；每轮实际推进的 token 越多，才越有机会摊薄成本。
- 草稿校对只是类比。随机采样要满足接受和修正规则，不能用简单逐词一致替代。
到这里，缓存、调度、精度和推测已经分别出现。下一篇把它们放进一套真正的引擎：vLLM 内部谁来组织这些工作？ 进入vLLM 的执行机制。