如果你最近在部署或调用大模型，大概率会有一种体感：模型能力越来越强，但推理速度依然是个硬约束。尤其在实时对话、代码补全、Agent 多步规划这类场景里，延迟每降低一点，产品体验就上一个台阶。而“推测解码”（Speculative Decoding）这两年被反复提及，核心原因很简单——它能在不牺牲输出质量的前提下，把推理速度提升到原来的2到3倍。更关键的是，这不是靠换更贵的硬件，而是靠改变“生成的方式”。
要理解它为什么有效，得先回到 LLM 推理的基本事实：自回归生成是串行的。每生成一个 token，模型都要完整跑一次前向计算，然后把新 token 拼回输入，再跑下一次。问题在于，大模型的前向计算中，绝大部分时间花在加载权重和访存上，而不是真正的矩阵计算。也就是说，GPU 的算力并没有被吃满，瓶颈在“内存带宽”和“串行依赖”。你花了大价钱买的显卡，大部分时间在等数据搬运。
推测解码的切入点非常巧妙：既然小模型跑得快，那就让它先“猜”几个 token，再让大模型一次性验证这些猜测是否正确。如果猜对了，大模型一次前向就能确认多个 token，相当于用一次大模型计算的成本，产出多个 token 的结果。如果猜错了，也没关系，大模型会在第一个错误位置纠正，并继续生成。整个过程在数学上保证输出分布与大模型单独生成完全一致——这不是近似，不是蒸馏，是无损加速。
这里的关键在于“验证”环节的并行性。传统生成是“生成一个、验证一个”，推测解码是“小模型草拟一串、大模型并行打分”。大模型的一次前向可以同时计算多个位置的 logits，因为验证时输入序列是已知的，不存在串行依赖。这就把原本空转的算力利用起来了。换句话说，推测解码不是让大模型算得更快，而是让大模型“一次算更多”。在硬件层面，这直接提升了 GPU 利用率和吞吐量，尤其在高并发场景下，效果更明显。
现代实现大致分几条路线。最早的是草稿模型方案：用一个小号 LLM 做 draft，大模型做 verify。优点是通用性强，缺点是额外显存开销和草稿模型本身的质量依赖。后来出现了 Medusa、EAGLE 这类“无草稿模型”方案，通过在大模型上挂轻量头来预测后续 token，减少了对独立小模型的依赖。再往后是 n-gram 缓存、检索式草稿等更轻量的做法，适合特定领域或重复性高的任务。不同方案的取舍点在于：草稿命中率、额外计算开销、显存占用、以及实现复杂度。没有绝对最优，只有场景匹配。
实际落地时，有几个经验值得注意。第一，推测解码的加速比高度依赖任务类型。代码补全、结构化输出、固定格式问答这类“可预测性强”的任务，草稿命中率高，加速明显；开放式创作、高温度采样则收益有限。第二，批处理大小会影响效果。小 batch 下延迟敏感，推测解码对首 token 延迟帮助有限，但对整体吞吐提升显著；大 batch 下则要平衡草稿开销。第三，不要忽视验证策略的工程细节，比如接受准则、草稿长度自适应、以及和 KV Cache 的配合，这些往往决定实际收益是 1.5 倍还是 3 倍。
从成本视角看，推测解码的意义不只是“快”。它让同等硬件能服务更多请求，直接拉低单位 token 的推理成本。对于自建推理服务的团队，这意味着更低的扩容压力和更高的资源利用率；对于调用 API 的产品，则意味着在同等预算下可以支撑更复杂的交互逻辑。更重要的是，它代表了一种思路转变：与其一味追求更大的模型，不如在推理路径上做文章，把已有模型的潜力榨出来。
当然，推测解码不是银弹。它增加了系统复杂度，需要调参和监控，草稿质量不稳定时甚至可能拖慢速度。但在推理成本依然高企的当下，它提供了一条确定性很强的优化路径。如果你正在做 LLM 应用或推理优化，建议至少跑一组对照实验：固定模型和硬件，对比开启推测解码前后的吞吐、延迟和输出一致性。数据会告诉你，你的场景到底能吃下多少红利。
你目前在推理部署中遇到的最大瓶颈是什么？是延迟、吞吐，还是成本？欢迎在评论区聊聊你的场景，我会挑典型问题做进一步拆解。如果这篇对你有帮助，也欢迎转发给正在折腾推理优化的同事。