在大语言模型推理场景中，自回归解码（Autoregressive Decoding）一直是延迟的主要瓶颈。每生成一个 token，都需要等待完整的前向传播完成，这导致生成速度远低于模型本身的计算吞吐量。投机解码（Speculative Decoding）作为一种并行化推断技术，通过引入 draft 模型与 verify 模型的协作机制，能够在不损失输出质量的前提下实现 2 到 3 倍的延迟降低。本文将详细剖析这一技术的工程实现细节与关键参数配置。
投机解码的核心原理
投机解码的核心思想可以概括为「以量换速」：用一个参数量较小、推理速度更快的 draft 模型批量生成多个候选 token，然后交由参数量更大、生成质量更高的 verify 模型进行并行验证。如果某候选 token 通过验证，则直接接受；如果被拒绝，则由 verify 模型重新生成替代 token。这种模式本质上将串行的自回归过程转化为 pipeline 并行的多阶段协作。
该技术最早由 Google DeepMind 研究团队提出，其理论基础在于：draft 模型虽然单次生成质量略逊于主模型，但在大多数情况下能够正确预测后续 token。以典型的英语文本生成为例，draft 模型对下一个 token 的预测准确率往往可达 70% 到 90%，这意味着大量候选可以直接复用，无需主模型重复计算。
Draft 模型的候选生成策略
Draft 模型的选择与部署是整个系统设计的第一步，也是影响加速比的关键因素。在实际工程中，draft 模型通常是主模型的压缩版本，例如使用知识蒸馏训练的小模型，或者直接使用主模型在低精度量化状态下的版本。这种做法的优势在于两个模型的 embedding 空间高度一致，token 分布的兼容性更好，验证阶段的拒绝率会显著降低。
生成候选 token 时需要配置两个核心参数：speculation window（推测窗口大小，记为 K）和 temperature。推测窗口 K 决定了每次迭代中 draft 模型连续生成的 token 数量，常见取值范围在 4 到 8 之间。窗口过小会导致并行度不足，加速效果有限；窗口过大会增加验证失败的累积概率，后续需要更多重生成，反而可能降低效率。Temperature 参数控制输出的随机性，较低的 temperature（如 0.2 到 0.5）能够提高 draft 模型的预测确定性，减少被 verify 模型拒绝的概率，但同时会降低输出的多样性。
一个典型的候选生成过程如下：首先向 draft 模型输入当前上下文，采样得到第一个候选 token；然后将这个 token 追加到输入序列，再次调用 draft 模型生成下一个 token；如此重复 K 次，形成长度为 K 的候选序列。在这个过程中，draft 模型仍然采用自回归方式生成，但因其参数量小、推理速度快，整体耗时远低于主模型的一次前向传播。
Verify 模型的验证与重采样
Verify 阶段是投机解码实现加速的实质环节。当 draft 模型生成 K 个候选 token 后，verify 模型接收原始上下文与完整候选序列，进行一次性的并行预测。这里需要特别注意的是，verify 模型并非简单比对每个位置的 logits 最大值，而是通过比较 draft 模型与主模型在每个位置的 token 概率分布，来决定接受还是拒绝。
具体的验证算法通常采用拒绝采样（Rejection Sampling）机制。对于候选序列中的第 i 个 token，verify 模型计算该 token 在主模型分布下的概率，记作 q (i)，以及 draft 模型分布下的概率，记作 p (i)。以 q (i) 除以 min (q (i), p (i) 乘以调整系数 β) 作为接受概率，决定是否接受该 token。调整系数 β 通常设为 draft 模型与主模型的概率比值上界，用于保证采样结果的数学期望与主模型一致。
当某个 token 被拒绝时，后续的所有候选 token 也一并失效。此时 verify 模型会在被拒绝的位置重新进行自回归采样，生成正确的替代 token，然后继续完成剩余位置的验证。这个过程可以类比为一个流水线：draft 模型快速产生「猜测」，verify 模型检查并修正「错误」，两者并行工作，最大化 GPU 的计算利用率。
工程实现的关键参数
在实际生产环境中部署投机解码，需要关注以下工程参数：
批量大小与内存权衡：虽然投机解码的核心是单次推理的加速，但当需要处理批量请求时，batch size 的设置会影响 draft 模型与 verify 模型的内存占用比例。通常建议 verify 模型的 batch size 保持为 1，以确保验证阶段的低延迟，而 draft 模型可以适当增大 batch size 以提高候选生成的吞吐。
模型量化与混合精度：为了进一步降低 draft 模型的推理延迟，常采用 INT8 或 INT4 量化。有实验表明，在 draft 模型使用 INT4 量化、verify 模型使用 FP16 的组合下，整体延迟仍能保持约 2.1 倍的加速比，同时输出质量几乎不受影响。
动态窗口调节：部分实现会根据上下文难度动态调整推测窗口 K。例如在生成代码或专业术语时，draft 模型预测准确率下降，此时可以动态缩小 K 值以减少重生成开销；在生成常见词汇时可以适当增大 K 值以提高并行度。这种自适应策略需要根据具体业务场景进行调优。
性能收益与适用场景
根据已公开发表的实验数据，投机解码在多种模型规模和任务类型上均表现出稳定的加速效果。对于 70 亿参数的主模型配合 30 亿参数的 draft 模型，加速比通常在 2.0x 到 2.8x 之间；对于更大规模的模型组合（如 540 亿主模型 + 80 亿 draft），加速比可提升至 3.0x 以上。值得注意的是，加速效果与输出长度正相关：生成长度超过 100 个 token 的任务加速比明显优于短文本生成场景。
投机解码并非适用于所有场景。其主要限制包括：需要额外存储和运行一个 draft 模型，增加了部署成本；在某些领域特定任务上 draft 模型预测准确率较低，可能导致频繁拒绝；在需要严格 deterministic 输出的场景中，reject-resample 机制可能引入不必要的随机性。
总结与实践建议
投机解码为 LLM 推理延迟优化提供了一条切实可行的技术路径。其核心价值在于通过 draft-verify 双模型协作，将自回归解码的串行瓶颈转化为可并行处理的 pipeline 结构。工程落地时，建议从以下几个维度开始评估：首先分析当前推理延迟的瓶颈占比，确定优化优先级；然后选择与主模型兼容的小型化 draft 模型，可以通过知识蒸馏或直接量化获得；最后通过调节推测窗口 K 和 temperature 等参数，在加速比与输出质量之间找到业务可接受的平衡点。
随着模型蒸馏技术和硬件推理优化的持续进步，投机解码在生产环境中的收益有望进一步提升。对于追求极致用户体验的在线推理服务，这一技术值得纳入长期优化路线图。
资料来源：本文技术细节参考了 Google DeepMind 关于 Speculative Decoding 的原始论文与 Hugging Face 开源实现。