如果你向做推理优化的工程师提一个问题：「投机解码的加速比怎么算？」大多数人会回答：每轮验证平均接受多少草稿 token，接受得越多越快。这个答案在过去几年几乎是行业公理。arXiv 2026 年 10 月 16 日提交的论文《Acceptance Is Not Speed: Length Inflation in Training-Free Lossy Speculative Decoding》（2610.23818，投 NAACL 2027 在审）用 360 组系统实验证明：在宽松验证规则下，这个公理是错的。
现象：接受率涨了，时钟却没少走
论文的核心发现可以压成一组对比数字。在每种规则最宽松的评估设置下：
- 每轮接受的 token 数：平均 1.34 倍（相对无损验证）
- 生成的补全长度：平均 1.54 倍
膨胀幅度超过了接受增益。也就是说，模型确实每轮多「白嫖」了几个 token，但它把省下的轮数全部用来生成了更多内容——其中大部分是更长的推理轨迹。端到端墙钟时间不降反升，加速比在报表上好看，在时钟上难看。
这不是个别规则的实现 bug，而是机制性的。研究者把现象命名为「长度膨胀」（length inflation），并在四种目标模型、八种专用草稿器加三种独立小语言模型组成的 12 对目标-草稿组合、6 个数据集（GSM8K、AIME24、HumanEval、LiveCodeBench、MT-Bench、LongBench-v2）、5 种免训练宽松规则上做了全因子扫描，共 360 个测试单元。运行环境为 vLLM 0.26.0、单张 NVIDIA H100、每轮草稿 6 个 token。
机制：低概率 token 如何绑架输出长度
宽松规则为什么必然拉长输出？论文的归因链有三层，每一层都有数据。
第一层：宽松规则只能接受「超调 token」。 无损验证的判据是接受任何草稿概率不超过目标概率的 token；宽松规则放宽这条线，因此它额外接受的 token 全部落在「目标模型认为不太可能」的区间。追踪运行显示，这些宽松独有 token 的中位目标概率只有 0.01 到 0.09，而两种规则都接受的 token 中位概率是 0.78 到 0.93。唯一的例外是 spec_casc_tok 规则——它额外接受的 token 中位概率 0.29，平均排名 0.9，基本就是目标模型的第一或第二选择。这也预示了后文的精度差异。
第二层：额外 token 主要流向思考，不流向答案。 在 GPT-OSS-20B 的 30 个单元中，25 个单元的分析通道拿到了九成以上的额外字符；Qwen3-8B 上中位数超过九成的额外字符出现在思考块内。模型在答案写完之后继续「想」，或者在离答案还远的地方绕圈子。AIME24 上的对比最刺眼：宽松运行到达答案的中位位置是第 3865 个 token，无损运行只要 1721 个——至少 59% 的额外 token 出现在答案之前，直接推迟交付。而在 GSM8K 这类答案较早出现的任务上，50% 到 82% 的额外 token 出现在参考答案之后，属于纯粹的浪费。
第三层：推理轨迹耗尽预算。 360 个单元中 208 个的「在生成预算处被截断」比例上升（中位 11% 对无损的 4%）。研究者做了个说明问题的实验：对 1132 个在预算阈值附近仍未闭合推理轨迹的宽松运行强制闭合轨迹，正确答案从 126 升至 439——335 个从错误变正确。Qwen3-8B 在 GSM8K 上，307 个强制运行的样本正确数从 56 涨到 225。这些答案本来就在模型脑子里，只是被无限延长的思考挤出了预算窗口。
还有个佐证机制的温度对照实验：把 GPT-OSS-20B 的采样温度从 1.0 提到 1.2（同样在提交低概率 token），GSM8K 输出变长 1.27 倍；提到 1.5，膨胀 3.9 倍且精度跌到 0.31。长度膨胀与「提交低概率内容」这一行为本身绑定，与具体实现无关。
精度：轮数省了，准确率没了
长度之外，激进规则还在精度上记账。在 300 个分级测试单元中，198 个精度下降：cactus 平均掉 0.19、r_fuzzy 掉 0.21、spec_casc_opt 掉 0.14，代码生成任务损失最大（HumanEval 中位掉 0.09、LiveCodeBench 掉 0.11）。两个典型案例：cactus 在 R1-Distill-Llama-8B 的 LiveCodeBench 上把验证轮数砍到 0.44 倍，精度从 0.58 崩到 0.02；在 Qwen3-8B 的 AIME24 上轮数 0.55 倍，精度从 0.70 跌到 0.23。
反过来，贴近目标模型的 spec_casc_tok 是唯一平均保持精度的规则（平均只掉 0.005），代价是接受增益最小（1.11 倍）且长度中位值 0.97（基本不变）。这个反差恰好说明：唯一「既不变长也不掉分」的规则，恰恰是更信任目标模型的规则。
方法论：论文留给行业的三条纪律
这篇论文最实用的产出不是某个数字，而是三条报告纪律。
纪律一：单轮接受长度不是速度的度量。 作者给出长度校正公式：宽松规则的真实加速约等于无损加速乘以补全长度之比的倒数，即只有单轮接受增益超过长度膨胀倍数时，墙钟时间才真的下降。用论文的数据说话：1.34 的接受增益打不过 1.54 的长度膨胀，净效果是变慢。
纪律二：比较要匹配接受长度，不是匹配参数。 五种规则的松弛参数含义互不相同（反向 KL 预算、正向 KL 预算、散度阈值、延迟代价、可信集宽度），跨方法比参数毫无意义，应该在各方法达到相同平均接受长度时比较。
纪律三：报告完整指标集。 补全长度、验证轮数、墙钟时间、任务精度，四项缺一不可。只报接受长度或每秒 token 数的论文和 benchmark 榜单，在宽松验证语境下都会系统性高估加速效果。
论文还指了一个未来方向：问题的解法不是「接受更多草稿 token」，而是「选择接受哪些 token」。spec_casc_tok 的表现支持这个判断——质量来自对目标模型分布的忠实，而非放宽。
工程启示：选型时多问三个问题
把论文翻译成选型行动清单。评估任何声称加速的推理方案时，问三个问题：一、加速数字是在无损还是宽松验证下测的？如果引擎默认开启宽松验证，把它关掉再测一遍墙钟。二、除了接受长度，有没有报告输出长度与轮数？没有就有理由怀疑数字被美颜。三、任务精度测了吗？宽松规则在代码任务上的损失中位超过 0.09，对生产环境不是可以忽略的噪声。
还有一个直接的缓解手段来自论文实验：在推理轨迹耗尽生成预算前强制闭合，可以挽回被截断的正确答案（126 到 439）。如果你的推理框架支持「检测到答案已形成即停止思考」，这个开关值得打开。
顺带一提，这篇论文与同周的 DLite（2610.23787）构成了一组有趣的对照：DLite 在无损口径下把智能体负载的接受长度从约 1.9 提到 3.15，走的是「让草稿更准」的路线；本文则证明「让验证更松」的路线会在长度上还回去。投机解码的下一个阶段的竞争焦点，已经从「每轮接受多少」转向「接受得对不对」。