投机解码加速的真相：瓶颈份额决定端到端收益
投机解码这几年的热度一直不降，从LLM推理服务到端侧部署，到处都能看到“xx倍加速”的宣传数字。但说实话，我日常接触到的很多项目，真正把投机解码大规模落地到生产环境，反而很少能复现出论文里的加速比。仔细追下去，答案往往不在模型本身，也不在草稿模型质量，而在一个很容易被忽略的指标——瓶颈份额。
所谓瓶颈份额，就是一次推理中真正能被投机解码优化的那部分时间所占的比例。加速比再漂亮，如果这个比例本身很小，最终端到端的提升就会很有限。这个道理说起来简单，实操中踩坑的人却不少。这篇文章就把投机解码的上限怎么算、瓶颈份额怎么测、实测中哪些地方最容易把加速比“吃掉”一次性讲清楚。
1. 先拆投机解码到底在优化哪一段
1.1 自回归解码的“串行墙”
要理解投机解码，得先从自回归生成的结构性瓶颈说起。LLM生成token的时候，本质上是一个逐token串行过程：拿到前n个token，算一次前向，得到第n+1个token的分布，采出一个token，再拼回去，继续算第n+2个。每一步都依赖前一步的输出，这个依赖关系是硬性的，无论GPU多快都无法绕过。算力利用率低的原因就在这里——每次前向都是一个小batch（通常batch size为1或很小），矩阵乘法的计算强度上不去，GPU大部分时间花在搬运权重和KV cache上，而不是真正做计算。
这就形成一个很现实的问题：你想提高吞吐，得把很多请求拼在一起batch化；但如果你在乎单用户的首token延迟和每token延迟，batch又不能太大。这中间的矛盾是推理优化里一个长期存在的核心矛盾。
投机解码的思路，就是打破这种串行依赖。核心想法很直白：用一个更小的模型（草稿模型）先快速预测后面几个token，目标模型一次性验证这些预测，如果预测对了，一个前向就能产出多个token。听上去就是“猜了再说，猜错的丢掉”，但实际上它能生效，依赖两个前提：第一，草稿模型预测得足够准，接受率高；第二，验证阶段的并行前向，成本要明显低于逐个生成。
1.2 投机解码加速的本质是“用算力换延迟”
很多解释把投机解码说成“用额外的小模型计算来降低延迟”，这句话对但不完整，真正被换掉的是时间维度上的串行步数。
举个例子：假设草稿模型一次猜4个token，目标模型并行验证4个位置。如果4个全部接受，那么这一步就相当于原来需要4次序列前向的生成，被压缩成了1次并行前向。中间损耗的是草稿模型额外跑的那几次小前向。对比单步前向时间，草稿模型的前向因为参数量小，通常只有目标模型的十分之一到几十分之一。这样一来，单步时间几乎被验证阶段的耗时主导，而验证耗时又不会比原来自回归的单步前向高出太多（因为batch从1变成了5，但主要瓶颈在带宽，batch增大带来的计算时间增量有限）。所以理论上收益的上限，是“平均每步产出的token数”。
但这里就出现了一个很多人忽略的问题：投机解码只能优化“前向计算”这一段。一次真实请求的完整时间线里，前向计算占多少，是由你的系统设计、显存带宽、框架开销、采样逻辑、甚至网络传输共同决定的。只要前向计算的占比不是100%，实际加速比就一定会小于理论加速比。
2. 为什么加速比会骗人，瓶颈份额才是最硬的指标
2.1 Amdahl定律在推理系统中的投影
很早之前的计算机体系结构课里，Amdahl定律就讲清楚了这个问题：系统加速比的上限，由无法被加速的部分决定。公式写作：
加速比 = 1 / ((1 - p) + p / r)
其中p是可优化部分占原始耗时的比例，r是这部分被优化后的加速倍数。投机解码这个场景里，p就是“能被投机解码优化的前向计算耗时占比”，r则是“投机解码带来的前向计算时间缩减倍数”。
这个公式能解释很多实际现象。比如你在benchmark里看到某模型投机解码加速1.8倍，觉得还不错，但部署到自己的服务上，发现只快了20%。差别往往不在草稿模型，而在于你的服务里p远低于benchmark环境。
想想看，如果p只有0.3，r就算到5，整体加速比也才1/(0.7+0.06)≈1.31。p一低，r再高也被稀释了。反过来，如果p在0.9，r只有2，整体加速比也有1.81。所以真正决定了一个投机解码方案值不值得做、能做多快的关键，并不是草稿模型选多好、加速比benchmark多高，而是目标系统里前向计算占比有多少。
2.2 benchmark加速比为什么普遍虚高
现在很多论文和开源仓库报告加速比的方式，是在理想化条件下测的。怎么个理想化法？典型的做法包括：固定batch size、关闭采样、忽略prefix cache命中、短序列，甚至直接在模拟环境里跑一个理想化的flops计算。这种情况下，系统overhead占比极小，p极其接近1，所以加速比数字非常好看。
到了生产系统里，状况完全不同。长上下文带来的prefill阶段会稀释decode阶段的收益；连续batching要求投机验证不能阻塞其他请求；采样器可能因为temperature和top-p设置导致接受率波动；甚至目标模型用了int8量化后，权重搬运时间变短，整体前向耗时变短，但投机解码额外开销不变，导致p反而下降。这些因素都在悄悄改变瓶颈份额。
我个人做过一次对比：同一个7B模型，短序列、单请求、固定batch场景下投机解码加速1.6倍；换成多轮对话、混合prefill和decode、动态batch的生产负载后，加速只剩1.15倍。差距不是模型变了，是p从差不多0.95掉到了0.6左右。这让我彻底认同一件事，任何不先分析瓶颈份额就声称“加速x倍”的结论，都值得打一个问号。
3. 瓶颈份额的实测方法与判断标准
3.1 用profiler把时间线拆开
那么瓶颈份额到底怎么测？不需要什么高深的工具，最直接的方式是在你的目标负载下跑一次完整请求，用profiler把时间拆开。我习惯用三种工具交叉验证：PyTorch Profiler、NVIDIA Nsight Systems、以及框架自带的事件日志。
重点看这么几段耗时：prefill阶段前向耗时、decode阶段前向耗时、采样耗时（包括从logits到token的整个后处理）、显存拷贝和宿主同步、KV cache管理、调度等待（比如因为batch slot不够而空转）。这些时间项里，“decode阶段前向耗时”才是投机解码理论上能吃到的部分。严格说，投机解码验证阶段的并行前向也会产生新的耗时，它替换掉的是“串行decode的多次前向”。所以计算p的时候，用decode前向总耗时除以单次请求总耗时，就是一个很好的近似。
实操步骤我一般这样走：
- 固定一个能代表线上负载的请求集，序列长度、batch大小、并发数都尽量贴近真实。
- 关闭投机解码，跑一次，记录端到端耗时和各个阶段占比。
- 算出decode阶段前向耗时占总耗时比例p。
- 开启投机解码，再跑一次，记录端到端耗时和实际平均接受token数。
- 把两组数据套进Amdahl公式，验证理论加速比和实际加速比是否对得上。
3.2 两个容易被忽视的修正项
第一个是采样器耗时。现在很多推理框架在后处理阶段要做logits mask、温度缩放、top-p过滤、重复惩罚重算，这些操作在batch变大之后耗时增长很明显。投机解码的验证阶段一次要处理草稿模型给出的多个token，后处理同样要处理多个候选位置，原始串行decode阶段只需处理一个位置。后处理开销会缩小你能省下来的时间，直接拉低p。很多人在分析瓶颈份额时只看前向占比，忽略了后处理也是一个“不可加速项”，误差就出在这里。
第二个是显存带宽的隐性变化。投机解码的验证阶段会把batch size从1变成n+1，这对计算密集型GPU来说影响不大，但如果你用的GPU是消费级或者带宽受限的推理卡（比如某些端侧NPU），batch扩大之后，激活和中间变量的读写量都会上升，前向单步时间可能比原来高出不少。有的场景下，验证阶段单步耗时是原来自回归单步耗时的1.5倍以上，这时候r就远没有预期那么高。如果遇到这种情况，缩小草稿长度、甚至关掉投机解码可能反而更快。
4. 影响瓶颈份额的三层因素，按重要性排个序
4.1 系统层面：连续batching和调度策略
第一层因素最容易被忽略，因为它不在你“投机解码”的视野范围里，而是你整个推理系统的架构决定的。
连续batching（也叫in-flight batching）会让GPU始终在处理多个不同进度的请求。当一个请求处于投机解码的验证阶段时，其他请求可能正在prefill，也可能在decode。GPU的工作是混合的，投机解码只优化单个请求内部的串行等待，但无法优化多个请求之间的调度博弈。极端情况下，如果你的系统把batch满作为最高优先级，投机解码带来的单请求延迟下降，会被下一个batch slot的分配等待时间吞掉。
我自己踩过的一个坑：当时为了压测吞吐，把max_batch_size调得很大，结果投机解码的加速比反而从1.5掉到1.2。原因就是请求多了以后，decode前向的GPU计算时间占比被调度等待和KV cache驱逐时间挤压，p大幅缩水。这不是投机解码的错，是系统的调度决策和它不匹配。分布式推理场景还有另一层问题：如果你把草稿模型和目标模型放在不同机器上，草稿token的通信延迟会成为新瓶颈；放入同机甚至同一进程，又可能挤占目标模型的显存和算力。这些都会体现在p的变化里，但不一定能直接从模型维度看出来。
4.2 模型层面：接受率和草稿模型选择的“剪刀差”
第二层因素是模型层面的，核心是接受率。接受率越高，平均一步产出的token数越多，r越大，但这只在p足够大时才有意义。另一个关键点是草稿模型的相对开销。
如果草稿模型太大，比如目标模型参数量的一半，它的前向耗时就会显著抬高总前向时间。很多人在选草稿模型时只盯着接受率，觉得接受率高就划算。实际上更合理的指标是“相对开销”：草稿模型前向时间 * 草稿长度 / 目标模型前向时间。这个值越小，投机解码的净收益越大。
举个例子：假设草稿长度是4，草稿模型每一步前向耗时是目标模型的1/8，那么单个草稿步的开销就是4 * (1/8) = 0.5倍目标模型前向耗时。如果接受率只有0.5，平均每步产出2.5个token，收益是2.5 / 1.5 ≈ 1.67倍。如果接受率提到0.7，平均产出约3.3个token，收益是3.3 / 1.5 ≈ 2.2倍。看起来接受率提升带来收益提升，但你会发现草稿模型大小的边际效益递减非常快，反而增加草稿长度或优化草稿模型的前向延迟，往往比单纯追接受率更容易提升收益。这个“剪刀差”不拉开，p再高，r起不来，整体加速比也就平了。
4.3 负载层面：prefill与decode的混合比例
第三层因素经常被benchmark掩盖，那就是prefill阶段和decode阶段的时间占比。投机解码只优化decode阶段的自回归前向，prefill阶段（长提示词的一次性计算）它帮不上忙。
长上下文场景现在很普遍，1K到4K输入token的请求已经很常见，有些RAG场景甚至到8K以上。prefill是计算密集型的，耗时可能占据单次请求总耗时的30%到50%。如果你服务的场景是“长输入、短输出”，decode阶段占比可能只有40%不到，那投机解码理论上限就只有1.6倍左右，再往上推也推不动了。
反过来，如果是多轮对话场景，每轮输入都不长，但输出很长，decode占比可能超过80%，这时候投机解码的收益空间就很大。所以同一套模型、同一个草稿模型，在不同负载画像下，加速比可以差出一倍左右。想判断你的场景值不值得上投机解码，先统计一下线上请求的平均输入长度和平均输出长度，算一算decode占比，比盲目跑benchmark靠谱得多。
5. 两轮实测记录：如何把瓶颈份额从0.55挖到0.8
5.1 第一轮：注意力全在草稿模型上，结果翻车了
我最近优化一个7B模型的在线推理服务，初始状态是单请求TTFT约380ms，单token延迟约60ms，decode阶段占总耗时约55%。这个p值意味着，就算投机解码把decode阶段做到绝对完美，加速比上限也只有1 / 0.45 ≈ 2.2倍。理论天花板就不高。
第一轮优化我犯了个典型的错误：花了大量时间提升草稿模型的接受率。把草稿模型从1亿参数换到3亿参数，接受率从0.45提升到了0.68，草稿长度从4拉到6，看起来r从2左右升到了3.5，理论上加速比应该能到2倍。实测端到端加速却只有1.3倍，远低于预期。一profile发现，decode阶段前向占比确实被优化到了45分钟左右的水平，但整体耗时里还有34%的调度等待和采样器开销，这部分完全没变。加快decode前向之后，瓶颈份额重新分配，那些原来被掩盖的“次要开销”变成了主角，p实际上进一步缩水了。这就是把注意力全放在草稿模型上的代价：局部优化了r，但p因为其他开销拖累没有同步提升。
5.2 第二轮：换个思路，先砍不可加速项
之后我调整策略，先砍“不可加速项”。砍调度等待：原来每个请求做完投机验证后会走一次框架的同步屏障，改成异步回调，把这个等待从25ms压到8ms。砍采样器开销：原来验证阶段对每个候选位置都算一遍完整的logits后处理，改成批量计算，这一项从18ms压到6ms。砍KV cache管理：原来的动态扩容策略在长上下文场景触发了很多次碎片整理，改成预分配，又把7ms省掉。
这几刀砍下来，decode前向耗时占比从55%升到了约80%，p一下子上来了。此时再回头优化草稿模型的接受率，投机解码的收益就开始明显体现：端到端单token延迟从60ms降到36ms，加速约1.67倍，接近于理论公式能给出的结果。整个过程里，草稿模型的优化方向和第一轮完全一样，区别只在于先把p顶上来了。
这个案例想说明的，其实特别朴素：你在优化一个系统时，先搞清楚哪些部分是你可以改变的，哪些部分是你改变不了的。投机解码只管decode阶段的前向计算，那你就先把这之外的耗时压到最低，然后你的加速比才有意义。
6. 常见问题速查：实操中经常踩的五个坑
第一个坑：只看平均接受率，不看分布。接受率0.6的平均值，可能是“某些位置接近1、某些位置接近0”的混合。真实分布越不均匀，投机解码的收益越不稳定。建议按token层次统计接受率分布，尤其要观察那些概率接近但被拒掉的token，它们决定了草稿长度能不能继续加长。
第二个坑：验证batch变大后，显存占用翻倍。草稿长度是4的时候，验证阶段同时跑5个位置的forward，激活显存和临时buffers都会涨。如果线上GPU显存已经快满了，强行开投机解码可能导致KV cache容量下降，触发更频繁的驱逐或重计算，反而拖慢整体。建议用nvidia-smi盯一下验证阶段显存峰值，预留10%余量。
第三个坑：投机解码和量化推理框架的兼容性。有些框架用了算子融合，验证阶段的并行前向不一定能完全复用原来的融合kernel，可能出现验证step比单步decode还慢的情况。建议在最底层kernel级别对比单步decode时间和验证step时间，如果比值超过1.3，就要重新考虑草稿长度或换更轻量的验证方式。
第四个坑：温度、top-p等采样参数对接受率的影响。低温、高top-p通常接受率更高，但如果你线上服务用的是高温采样或强化的重复惩罚，接受率可能比benchmark低30%以上。这直接击穿你根据benchmark做的r估计。建议在真实采样参数下测接受率，而不是用默认greedy参数。
第五个坑：只测了单并发。单并发下投机解码的加速比往往偏乐观，因为这时候没有其他请求抢占GPU资源。多并发时，草稿模型的前向和验证前向会和其他请求的计算竞争资源，加速比会明显回落。建议至少测4并发和8并发两个档位，看看加速比曲线怎么变化。
7. 一点个人经验总结
跑了这么久投机解码相关的优化项目，我的体会是，投机解码本身不是难点，难的是搞清楚它在你系统里的真实作用范围。很多团队一上来就调草稿模型、调草稿长度、调采样策略，盯着一堆加速比数字来回折腾，但忘了先算一算decode阶段前向在总耗时里占了多少。数字再漂亮，份额不够，一切都是空的。
反过来，只要先把瓶颈份额这个底数做大，你会发现后面很多决策都变得清晰了：草稿模型选多大、草稿长度设多少、批处理怎么配置，都能用公式推出来，而不是靠感觉。投机解码的上限，确实不在加速比数字里，而在你愿意花多少精力去抠那些“不可加速项”的琐碎时间里。每次做完一轮系统优化，我都习惯重新跑一遍p的测算，因为系统不是静止的，p会跟着负载、框架版本、显存分配策略悄悄变化。把瓶颈份额当成一个需要持续维护的指标，而不是一次性算完的数字，你就不会轻易被各种“加速x倍”的宣传带偏了。