ProVe解码：大模型当提案者，投机解码反着来

投机解码（Speculative Decoding）通常让一个小模型快速起草token，再由大模型并行验证，从而加速自回归（AR）生成。但一项名为ProVe的新研究把这个角色分配反了过来：让大模型自己当提案者，一次前向预测未来多个token，再用额外一次前向完成验证。这个看似简单的反转，在32B模型上实现了2.5倍的平均吞吐提升，且无需训练额外的草稿头。

核心思路：反转投机解码的角色

传统投机解码依赖一个独立的、较小的草稿模型来串行生成候选token，然后由大模型并行验证。这种方法虽然有效，但需要额外训练和维护一个草稿模型，增加了工程复杂度。ProVe则直接从标准的AR检查点出发，将大模型微调成一个“提案者”（Proposer），使其能在单次前向传播中预测一个未来token块。随后，再用一次额外的前向传播来验证这个提案块。

验证者可以是另一个较小的AR模型，也可以就是提案者自身。后者被称为ProVe-lossless，因为它能精确复现提案者的贪心AR解码结果。这意味着在完全无损的情况下，依然能获得可观的加速。

自回归（AR）生成是当前大语言模型的标准推理方式：模型每次前向传播只预测下一个token，然后将该token追加到输入序列中，再执行下一次前向传播。这种串行过程导致每个token都需要一次完整的前向计算，推理延迟与生成长度成正比，成为吞吐量的主要瓶颈。

草稿头（draft head） 指附加在模型上的轻量预测模块，通常经过单独训练，用于在投机解码中快速生成候选token。传统方法需要额外训练和维护一个独立的草稿模型或草稿头，增加了工程复杂度和部署成本。ProVe通过微调大模型自身来预测token块，从而避免了这一额外组件。

性能表现：2.5倍吞吐与可控权衡

研究者在六个基准测试上评估了ProVe。使用32B提案者时，ProVe-lossless达到了平均2.5倍的AR吞吐量，且无需训练单独的草稿头。提案块本身已经提供了足够的加速空间：当块大小为16时，在GSM8K数据集上，提案块与AR解码的平均匹配前缀长度为6.6个token。

如果追求更高的速度，可以引入一个3B的小验证者，此时ProVe达到平均2.7倍吞吐量，但代价是在六任务平均准确率上比AR低2.6个百分点。这提供了一个可控制的权衡：用户可以根据应用场景在速度和精度之间灵活选择。

匹配前缀长度是衡量投机解码加速效果的关键指标：它指提案块中从开头起连续与目标模型（或AR解码）输出一致的token数量。匹配前缀越长，验证阶段能一次性接受的token就越多，加速比越高。在ProVe中，块大小为16时GSM8K上的平均匹配前缀为6.6个token，意味着平均每次提案-验证循环可接受约6.6个token，而非传统AR的1个token。

吞吐量（throughput） 通常指单位时间内模型生成的token数量（tokens/s），是衡量推理效率的核心指标。2.5倍吞吐提升意味着在相同硬件条件下，ProVe每秒生成的token数是标准AR解码的2.5倍，直接降低了单位token的推理成本。

技术细节与意义

ProVe的关键创新在于将大模型本身转化为提案者，而不是依赖外部的草稿模型。这避免了训练独立草稿头的开销，也简化了部署流程。微调大模型使其具备块级预测能力，是该方法的核心。验证阶段则保持标准的并行验证逻辑，确保输出质量可控。

从更广的视角看，ProVe展示了投机解码框架的灵活性：提案者和验证者的角色并非固定不变，通过重新分配角色，可以在不增加额外模型的情况下获得加速。这对于希望降低推理成本、又不想引入复杂草稿模型体系的团队来说，提供了一条新路径。

当然，ProVe-lossless的加速比受限于提案块与AR解码的匹配程度。在GSM8K上平均匹配6.6个token，意味着仍有提升空间。如何进一步提高提案块的命中率，将是后续优化的方向。

ProVe-lossless中的“无损”指验证者与提案者为同一模型时，最终输出分布与提案者的标准贪心AR解码完全一致，不会引入任何精度损失。其原理是：验证阶段对提案块中的每个token进行并行评分，只接受与提案者自身AR预测一致的前缀，从而保证输出序列与逐token贪心解码相同。

小验证者（3B） 则是一种有损加速模式：验证者是一个独立的小模型，其评分标准与提案者不完全一致，因此可能接受提案者不会选择的token，导致输出分布偏移，表现为准确率下降（六任务平均低2.6个百分点）。这种设计允许用户在可接受的精度损失范围内换取更高吞吐。