投机解码的生产真相：batch size 为 1 时是甜点，批量上去之后可能变成负收益

投机解码在 2026 年已经从研究论文变成了推理框架的标配功能。原理不复杂：用一个小模型快速生成若干草稿 Token，大模型一次并行验证，接受的部分直接保留，拒绝的部分重新生成。宣传口径通常是“2 到 2.5 倍加速”。但生产环境的调优经验给出的图景比这个数字细得多。

vLLM 的文档对适用条件写得很直接：投机解码减少的是 inter-token latency，适合中低 QPS、memory-bound 的工作负载。这句话的每一个限定词都很关键。在 batch size 为 1 时，GPU 的算力大量闲置，瓶颈在显存带宽——每生成一个 Token 都要把全部权重和 KV Cache 搬一遍。投机解码用“一次验证多个草稿”的方式，把多次显存搬运合并成一次，用闲置的算力换减少的搬运次数，这个交易是划算的。

但当 batch size 上去之后，GPU 逐渐从 memory-bound 转向 compute-bound，算力不再闲置。这时候投机解码“用更多计算换更少解码步数”的交易就开始变贵。草稿模型本身也要消耗计算，验证被拒绝的草稿也要消耗计算，如果接受率不够高，这些额外计算会直接变成吞吐损失。在生产调优中，一个常见的错误是看到 benchmark 里的单请求加速比，就把投机解码开到所有流量上，结果高并发时段的吞吐反而下降。

Together AI 的生产实践给出了另一个维度的补充：他们使用专门训练的推测模型，2026 年的 Aurora 进一步利用线上推理轨迹持续调整推测模型，以适应真实流量的变化。这说明草稿模型的质量不是一次训练决定的，而是需要持续对齐生产分布。一个在通用语料上训练得很好的草稿模型，如果生产流量是大量结构化的 JSON 或代码，接受率会明显下降，因为草稿模型不擅长这种分布。

vLLM 的 DSpark 走的是自适应路线：用一个 confidence head 给每个草稿 Token 打分，预测它通过验证的概率，然后根据置信度动态调整草稿预算。这个思路的工程含义是：与其全局调一个固定的草稿长度，不如让系统按请求、按 Token 动态决定“猜多远”。对于高置信度的片段多猜，对于不确定的片段少猜或不猜。

一个可操作的落地顺序是：先确认你的瓶颈确实是 decode 延迟而不是 prefill 或排队；再确认 batch size 和 QPS 落在投机解码的甜点区间；然后评估草稿模型在你的生产分布上的接受率，而不是通用 benchmark 上的数字；最后才开启并监控“接受率”和“有效吞吐”两个指标。接受率低于某个阈值时，投机解码就是负收益。它不是“开了就快”的开关，是一个有适用区间的交易。