投机解码让 LLM 推理快了两倍，但这个「有损验证」悄悄把质量降了——我把两种方案的坑全拆开了

用大模型推理，最怕的就是一个字一个字往外蹦。Speculative Decoding（投机解码）解决了这个问题——用一个小的 draft 模型猜测下一个词，大的 target 模型并行验证，速度能快上一倍。但最近几个月，很多团队在投机解码里加了一层”有损验证”，想再快一点，结果发现输出质量悄悄变差了，自己还不知道。

这篇论文（arXiv:2607.26627）把这件事彻底拆清楚了：所谓有损验证不是什么新魔法，本质上就两类，每类都有自己藏坑的地方。

投机解码是怎么工作的

正常推理时，LLM 一个字一个字生成，每一步都要跑完整模型，GPU 利用率其实很低。投机解码换了个思路：让一个小模型（比如 7B）先快速猜几个词，然后让大模型（比如 70B）并行验证这几个词。对上了就接受，没对上就丢弃重来。字面意义上”多快好省”。

但问题来了：如果大模型发现小模型猜的词概率不够高，要做”截断”——这时生成质量就开始悄悄变动了。

有损验证的两条路：截断式 vs 协作式

论文把目前所有有损验证方案分成两类。

截断式验证（Truncation-based Verification）：当 draft 模型的置信度低于某个阈值时，直接截断，不让大模型验证。这一步听起来很合理——跳过明显不对的候选，节省计算力。但问题在于：截断会系统性地改变整个输出的概率分布，导致最终生成的文本和标准贪婪解码（greedy decoding）完全不同，有时候甚至比随机采样（random sampling）还差。论文做了一个很扎心的实验：把有损截断的结果和真实截断采样（true truncation sampling）对比，发现前者经常显著落后于后者。

协作式验证（Collaborative Verification）：draft 模型和大模型一起协作验证。听起来更优雅，但论文发现了它的致命原则——必须控制 draft 概率相对于 target 概率的”过冲”（overshoot）程度。如果 draft 模型太自信，把不该接受的词也推过去了，最终质量就会崩。简单说：draft 模型和 target 模型之间的概率差距必须管住，否则加速换来的是输出不稳定。

实用结论：要不要用有损验证？

这篇论文给出的建议很明确：

对于 truncation-based 方法：除非你能精确控制概率分布偏差，否则老老实实用标准 speculative decoding，别加截断。质量损失可能是非线性的——有时候快 30%，但输出已经开始说胡话了。

对于 collaborative 方法：核心控制参数是 draft/target 概率过冲率（overshoot ratio）。如果你在实际部署，建议在离线数据上先跑一遍论文提供的诊断框架，确认你的参数没有越界。

对于工程团队：如果你现在用的是 vLLM 或类似推理框架，它们的 speculative decoding 默认配置大多属于 collaborative 类。检查一下 draft model 和 target model 的温度参数，以及是否触发了截断逻辑。

代码和诊断框架

论文开源了诊断框架：https://github.com/ZhouYuxuanYX/Fast-HSD

如果你在自研推理引擎，或者想理解你家生产环境里 speculative decoding 的真实表现，这个框架值得跑一遍。里面有针对两类方法的 benchmark，可以定位你的系统到底踩了哪类坑。

一句话总结

投机解码是个好想法，但”有损验证”这个优化方向目前还不够成熟——两类方案都有自己藏质量坑的地方，最稳妥的方案仍然是老老实实用标准版，别为了省那点计算力把输出质量悄悄卖掉。