什么是推测解码及其在本地大模型推理中的加速原理

什么是推测解码

推测解码，英文通常称为 speculative decoding，是一种面向自回归大语言模型的推理加速方案。它的核心思想是：用一个体积更小、运行更快的草稿模型先“猜”出若干个后续 token，再由完整的主模型对这些候选 token 进行一次性验证。如果草稿模型猜得准确，主模型就可以在一次前向计算中接受多个 token，从而减少串行解码次数，提升整体生成速度。

从使用视角看，推测解码没有改变主模型的参数，也不改变最终输出的语义分布。它只是在解码流程中增加了一个辅助模型，用“先猜后验”的方式降低主模型的调用频率。因此，它更适合被视为一种推理工程优化，而不是模型能力本身的提升。

从技术视角看，推测解码解决的是大语言模型生成速度受限于“逐 token 串行输出”的问题。主模型每生成一个 token 都需要完整计算一次，上下文越长、模型越大，单次计算成本越高。推测解码通过并行验证多个候选 token，把部分串行成本转化为并行成本，从而在特定条件下显著提高吞吐。

为什么需要推测解码

本地部署的大语言模型在推理时面临一个典型矛盾：模型参数越大，生成质量通常越好，但解码速度也越慢。尤其是在没有独立数据中心级加速硬件的消费级或工作站设备上，大型模型的 token 生成速率可能只有每秒几个到十几个，难以满足代码补全、交互式问答等场景的实际需求。

传统加速手段包括模型量化、算子优化、上下文缓存等。量化可以降低显存占用和计算量，但可能带来一定的精度损失；算子优化依赖具体硬件和推理框架；上下文缓存主要减少重复前缀的计算，对长对话有效，对全新任务帮助有限。

推测解码提供了一条相对独立的优化路径。它不改变主模型权重，不需要重新训练，也不要求用户接受量化带来的质量折中。它通过与主模型协同工作的草稿模型，试图用更少的串行步骤完成相同长度的文本生成。对于已经完成量化的本地模型，推测解码仍然可以叠加使用，因此在实际部署中具有较高的工程吸引力。

推测解码的核心组成

一个典型的推测解码流程包含三个关键部分。

主模型：负责最终文本生成的目标大语言模型。它是质量与准确性的基准，所有候选 token 都要经过它的验证。主模型可以保持原有精度，也可以已经经过量化处理。

草稿模型：一个小型语言模型，参数量远小于主模型，运行速度快，但生成质量相对较弱。草稿模型的任务不是输出最终答案，而是为主模型提供“可能正确”的候选序列。草稿模型通常使用同一词表，以便候选 token 可以被主模型直接验证。

验证与接受机制：主模型收到草稿模型生成的候选 token 后，会进行一次带完整上下文的前向计算，得到每个位置的概率分布。通过对比草稿模型与主模型的概率分布，系统决定接受多少个候选 token。接受标准通常基于随机采样或贪婪匹配。被接受的 token 直接写入输出序列，未被接受的位置则从主模型的分布中重新采样。

这三个部分共同构成一个闭环：草稿模型负责快速试探，主模型负责质量把关，验证机制负责在速度与正确性之间取得平衡。

推测解码的工作流程

理解推测解码的最好方式是把它拆成四个步骤。

第一步，草稿模型根据当前上下文生成一个候选序列。这个序列通常包含若干个 token，例如 4 到 8 个。由于草稿模型规模小，这一步可以在很短的时间内完成。

第二步，主模型接收“原始上下文 + 候选序列”，执行一次前向计算。这次计算的输出不是单个 token，而是候选序列中每个位置的概率分布。

第三步，系统按照一定策略验证候选 token。常见的做法是逐个比较草稿模型与主模型在该位置的采样结果。如果一致，则接受该 token；如果不一致，则停止接受，并从主模型的概率分布中重新采样当前 token。这样既能保证输出质量不偏离主模型，又能在草稿模型预测准确时一次性接受多个 token。

第四步，将接受的 token 追加到输出序列，更新上下文，进入下一轮推测。如果草稿模型连续猜中，单轮就可以推进多个 token；如果猜不中，则退化为接近普通解码的效率。

可以用一段伪代码表示这个流程：

while 未达到最大输出长度:
    draft_tokens = draft_model.generate(context, max_draft_len)
    logits = main_model.forward(context + draft_tokens)
    accepted = []
    for i, token in enumerate(draft_tokens):
        if verify(token, logits[i]):
            accepted.append(token)
        else:
            accepted.append(resample(logits[i]))
            break
    context = context + accepted

这个流程的核心价值在于：主模型的一次前向计算可以验证多个候选 token，而不是只生成一个。当草稿模型命中率高时，单位时间内生成的 token 数就会成倍增加。

为什么加速效果因任务而异

推测解码的性能提升高度依赖草稿模型的“猜测准确率”。如果草稿模型能频繁猜中主模型接下来会生成的 token，推测解码就能一次接受多个 token，显著降低主模型的前向计算次数。反过来，如果草稿模型频繁猜错，验证过程虽然仍在进行，但大部分轮次只接受一个甚至零个 token，整体速度反而可能因为额外的草稿模型开销而略有下降。

代码生成是推测解码表现突出的典型场景。程序代码具有高度结构化的特征，关键词、控制流、变量命名和缩进模式重复出现。例如，当模型已经生成了 if 和条件表达式，下一步很可能是冒号、换行和缩进后的代码块；当看到 for，后续往往跟着迭代变量和 in。草稿模型即使规模不大，也能在这些结构上保持较高的预测准确率。主模型因此可以频繁地一次性接受多个 token，解码吞吐成倍提升。

开放域聊天、文学创作、创意写作等场景则不同。这些任务中的每一句话都带有较高的信息熵，用户的下一句回复、情绪转折、用词风格都可能大幅偏离前面的模式。草稿模型很难稳定预测主模型会生成什么。此时推测解码的命中率下降，验证机制频繁中断，大部分轮次只能接受一个 token。再加上草稿模型本身的前向耗时，最终速度可能与不使用推测解码时相差无几，甚至略有波动。

因此，评价推测解码的加速效果，不能只看某个单一数据，而必须结合任务类型、输入分布和草稿模型与主模型的匹配程度。网络上传播的“数十 token 每秒”的成绩，往往来自代码补全或其他高结构化任务。如果用户的主要负载是闲聊或文案创作，则不应期待同等幅度的提升。

推测解码适合哪些场景

推测解码并不是对所有本地推理任务都有效的万能加速器，它的适用场景可以从几个维度判断。

代码生成与补全：这是推测解码最典型的高收益场景。函数定义、条件分支、循环结构、异常处理等代码模式具有强规律性，草稿模型容易预测。开发者在本地进行代码补全时，推测解码可以带来明显的速度提升。

结构化文本生成：包括 JSON、YAML、配置模板、表单数据、SQL 查询等格式固定的文本。这些内容同样具有大量可预测的结构与关键词，草稿模型的命中率通常较高。

翻译与摘要等有约束任务：当输出格式和用词范围相对受控时，草稿模型更容易猜中主模型的生成结果。例如，在术语固定、句式有限的领域翻译中，推测解码可能获得一定收益。

低结构化创作与开放聊天：这类场景的加速收益通常有限。用户在本地主要进行角色扮演、创意写作、随机问答时，推测解码的草稿模型命中率较低，整体速度提升不明显，甚至可能因为额外开销而略低于直接解码。

长文本续写：如果续写内容本身具有明显的风格延续和结构复现，草稿模型可能有一定命中率；但如果续写方向发散、主题跳跃，则加速效果会明显下降。

与相关概念的区别

推测解码常被拿来与批量推理、早退机制和模型蒸馏比较，但它们解决的问题不同。

批量推理是通过并行处理多个请求来提高吞吐，适用于服务端同时服务大量用户的情况。推测解码则主要优化单条请求的生成延迟，对本地单用户场景更有意义。

早退机制是指模型在中间层提前输出结果，减少计算深度。它改变的是单次前向的计算量，可能对模型质量产生影响。推测解码不改变主模型结构，只在验证阶段减少主模型的调用次数，输出质量理论上与主模型直接解码保持一致。

模型蒸馏是训练一个小模型去模仿大模型的行为，用于部署时替代大模型。推测解码则保留大模型作为最终决策者，小模型只作为辅助猜测器。蒸馏是模型层面的替代，推测解码是推理流程层面的协作。

使用推测解码需要注意的问题

在实际部署中，有几个方面值得关注。

草稿模型的选择：草稿模型与主模型需要使用相同的分词器和词表，否则候选 token 无法被主模型直接验证。同时，草稿模型的规模需要足够小，才能保证其前向开销不会抵消验证带来的收益。草稿模型过大，猜得准但跑得慢；过小，跑得快但猜不准。需要在速度与命中率之间找到平衡。

显存占用：推测解码需要同时加载主模型和草稿模型，会增加额外显存。对于显存紧张的设备，这可能成为限制因素。实际部署时需要确认总显存是否足够容纳两个模型及其推理时的激活值。

验证策略的实现：不同的验证策略会影响接受率和输出一致性。严格匹配策略可以保证输出与主模型完全一致，但接受率较低；基于采样的验证策略接受率更高，但输出分布可能与主模型略有差异。用户需要根据自己对输出一致性的要求选择合适方案。

任务类型的预判：在决定是否启用推测解码之前，应先分析自己的主要使用场景。如果以代码和结构化任务为主，推测解码大概率会带来明显收益；如果以开放聊天为主，则需要实际测试，避免为了一个无效的加速模块增加显存和运维复杂度。

量化模型的兼容性：推测解码可以叠加在量化模型上，但草稿模型是否量化、采用何种精度，也会影响整体速度与显存占用。不同精度的组合需要在实际硬件上进行基准测试，而不是直接套用网络上的单一数据。

总结

推测解码是一种通过草稿模型预测加主模型验证来降低自回归解码串行成本的推理优化方法。它的本质不是让模型“思考得更快”，而是让模型在容易预测的内容上“少跑几步”。在代码生成和结构化文本任务中，草稿模型命中率高，加速效果显著；在开放聊天和创意写作中，命中率低，加速收益有限。

理解推测解码，关键在于理解“猜测命中率”这一变量。它不是恒定的性能倍增器，而是一个与任务类型、草稿模型选择和验证策略强相关的工程方案。对于本地大模型使用者而言，是否启用推测解码，应当基于自己的真实工作负载来判断，而不是仅凭某个场景下的峰值速度做决定。