跳转到主要内容

投机解码实战:那顿并非免费的午餐

阅读需 2 分钟Tian PanTian Pan

你的 700 亿参数模型在推理时大部分时间都在等待内存读取,而非进行计算。现代 GPU 每从内存读取一个字节就能执行数百次算术运算,但自回归 Transformer 解码每加载一个字节只进行寥寥数次运算。硬件在空转,而你的用户在等待。投机解码利用了这一差距:让一个小而快的模型提前起草多个 token,然后让大模型在一次并行传递中一并验证。承诺是延迟降低 2-3 倍,且输出质量在数学上完全一致。但现实远没有这么简单。

经过两年在 Google 搜索、编程助手和开源服务框架中的生产部署,投机解码已经从研究新奇事物毕业为标准优化手段。但"标准"并不意味着"即插即用"。该技术在草稿模型选择、批处理大小敏感性和内存开销方面有许多尖锐的边界条件,它们决定了你是获得 3 倍加速还是净减速。

投机解码的实际工作原理

核心思想借鉴自 CPU 分支预测。不是每次都从昂贵的目标模型逐个生成 token,而是先运行一个廉价的草稿模型向前推进 K 步,产生 K 个候选 token。然后目标模型在一次前向传递中处理所有 K 个候选——这大约与生成单个 token 的成本相同,因为瓶颈在于从内存加载权重,而非计算本身。

验证步骤使用了一种改进的拒绝采样方案。对于每个起草的 token,目标模型将自身的概率分布与草稿模型的进行比较。如果目标模型对该起草 token 赋予了相同或更高的概率,则接受。否则,以目标概率与草稿概率之比的比例接受,其余情况拒绝。当一个 token 被拒绝时,所有后续的草稿 token 都被丢弃,目标模型从调整后的分布中采样一个修正 token。

这种拒绝采样机制正是保证成立的关键:输出分布在数学上与目标模型独立生成的结果完全一致。你没有在近似或蒸馏。你生成的是完全相同的分布,只是更快。

每轮验证中预期接受的 token 数遵循一个简洁的公式,基于接受率 α 和投机 token 数 γ:τ = (1 - α^(γ+1)) / (1 - α)。当 α = 0.8、γ = 5 时,平均每轮大约接受 4.5 个 token。由于每轮大约消耗一次目标模型前向传递,这意味着昂贵的前向传递次数减少了 4.5 倍。

草稿模型选择难题

草稿模型的选择正是"免费午餐"说法站不住脚的地方。这个选择决定了你的接受率,而接受率决定了投机解码是帮助还是拖累。而且大多数人最初的直觉——选最小的但预测能力还不错的模型——是不完整的。

最近的大规模基准测试揭示了一个反直觉的发现:草稿模型的语言建模准确度(困惑度)与其对投机解码吞吐量的贡献几乎没有相关性。草稿模型的延迟才是端到端加速的更强决定因素。一个稍微不那么精确但运行快 3 倍的模型会胜过一个更精确但更慢的草稿模型,因为验证步骤本来就会捕获错误。

大小比例很重要。 在实践中,草稿模型应该是目标模型的 1/10 到 1/50。Llama 3.2-1B 为 Llama 3.1-70B 起草之所以效果很好,正是因为同系列模型共享分词和训练分布,比同等大小的通用小模型产生更高的接受率。

领域特异性比规模更重要。 现成的草稿模型往往在特定领域任务或超长上下文上表现不佳。在你的生产查询分布上微调草稿模型可以将接受率提高 20-40%。对于高流量工作负载,这项投资很快就能收回。生产团队的一个实用经验是:精心策划数据混合——平衡对话、指令跟随和代码领域——比单纯扩大数据集规模对草稿质量的影响更大。

接受率阈值大约在 0.55-0.60。 低于此值,验证开销会吞噬并行 token 生成带来的收益。当接受率达到 0.6 或更高且投机 token 数为 5 个以上时,你可以可靠地期望 2-3 倍的加速。低于 0.5 时,完全不使用投机解码可能反而更好。

投机解码何时适得其反

该技术有一个明确的失效模式,直接映射到硬件利用率。投机解码用额外的计算来换取更少的内存传输。在低批处理大小(1-10 个并发请求)下,GPU 受内存带宽限制——在权重加载之间处于空闲状态——因此将计算花在起草-验证上纯粹是收益。但随着批处理大小增加,GPU 变成计算瓶颈,投机解码额外的验证工作开始争夺此时已成为瓶颈的算力资源。

生产基准测试的具体数据:

  • 批处理大小 1-10:2-3 倍加速,最佳区间
  • 批处理大小 10-30:收益递减,通常 1.3-1.8 倍
  • 批处理大小 32+:通常比标准解码更慢

这意味着投机解码非常适合交互式、对延迟敏感的应用——聊天机器人、代码补全、实时助手——在这些场景下你服务的是单个用户,关心的是首 token 时间和 token 间延迟。对于批量处理工作负载(如批量文档摘要或离线评估),它是适得其反的,因为你已经用大批量饱和了 GPU 算力。

还有一些场景也会适得其反:

  • 非常短的回复:如果你的典型输出不到 20 个 token,没有足够的生成量来摊销草稿开销。
  • 高温度的创意生成:高温度的随机采样产生的分布草稿模型很难预测,接受率暴跌。
  • 内存受限的部署:草稿模型的权重(1-8 GB)、其 KV 缓存以及验证张量分配都消耗 GPU 显存,这些显存本可用于更大的批处理或更长的上下文窗口。
会员专享

余下内容仅对会员开放。

会员可读完整内容 —— 每一个公开发布的观点背后,那些框架、决策与推理的全貌。

  • 完整文章,包含未公开存档的部分
  • 可落地的工作框架,附带权衡与决策依据
  • 新文章抢先看,先于公开发布

随时取消 · 一次订阅,畅读全部

参考资料

保持联系,关注我获取更多内容

阅读需 10 分钟

多模型推理服务的 GPU 显存计算:为什么大多数团队会过度配置 3 倍资源

在并发负载下,主导 GPU 显存的是 KV 缓存而非模型权重。本文将介绍容量规划的精确公式、量化权衡(AWQ vs GPTQ vs GGUF)以及装箱策略,让你在仅够运行 1 个模型的硬件预算下提供 4 个模型的服务。

insider
gpu-inference
阅读需 10 分钟

那个在 11 小时内烧光你季度推理预算的免费试用

针对人类注意力设计的试用上限,在程序化注册将智能体 (Agent) 对准端点的那一刻就会崩溃。这份实战指南旨在为实际注册的用户群体重新设计配额、检测机制和配额耗尽的交互体验。

insider
ai-cost
阅读需 12 分钟

对话中途耗尽的 Token 预算:为什么免费用户觉得你的模型变笨了

按用户分配的 Token 预算往往在对话中途咬人最狠——静默截断、丢弃工具调用、模型回退都会被用户读成质量退化,而升级转化的对话从未发生。

insider
ai-product
阅读需 13 分钟

你的 AI 功能需要一个无需部署的紧急开关 (Kill Switch)

一次标准的部署回滚需要 30 分钟;而一个表现异常的 LLM 仅需几秒钟就能向客户发送错误的输出。这里是你的 AI 功能在发生首次故障前所需的关闭原语——四种标志系列、触发它们的检测信号,以及确保其有效的测试规范。

insider
ai-engineering
阅读需 11 分钟

投机采样(Speculative Decoding)是一项流式传输协议决策,而非推理优化

投机采样(Speculative Decoding)承诺在保持模型输出一致的前提下实现 3-6 倍的加速,但这种保证仅限于离开推理引擎的 Token —— 而非已经展示给用户的字节。当你通过流式传输尚未验证的草稿 Token…

speculative-decoding
llm-inference