💻 computer science

Accepted Prefixes Are Not All You Need: A Negative Result on PEFT-Based Block-Diffusion Drafting

本文表明，尽管 LoRA 等参数高效微调（PEFT）方法能生成较长的接受前缀，但由于执行启用适配器（adapter-enabled）的草拟模型（drafter）的计算成本仍与全量验证器（verifier）相当，从而违反了草拟模型必须显著更廉价运行这一基本要求，因此这类方法无法为投机采样（speculative decoding）提供实际的加速。

原作者： Abdurrahman Javat, Allan Kazakov

发布于 2026-07-15

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Abdurrahman Javat, Allan Kazakov

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你正试图为一个聪明但动作极慢的机器人朋友写一个故事。这个机器人（验证者/Verifier）非常博学，但它一次只能输入一个词。如果你想写一个长篇故事，那将耗费大量时间。

为了提高速度，你雇佣了一个廉价且快速的实习生（草拟者/Drafter），让实习生去猜测接下来的几个词，供机器人检查。如果实习生猜对了，机器人只需说一句“做得好！”，然后继续下一步，从而节省大量时间。这被称为投机采样/推测解码（Speculative Decoding）。

这个研究的核心思想是：“如果这个实习生不是另一个人，而只是同一个机器人戴上了一顶小巧、廉价的帽子呢？”

“帽子”实验

研究人员尝试了一种叫做 PEFT-BD 的方法。他们没有雇佣一个全新的、更小的机器人，而是给原本的主机器人戴上了一个轻量级的适配器（就像一顶 LoRA 帽子）。这顶帽子被训练用来扮演一个“块扩散（block-diffusion）”机器人的角色。

你可以这样理解：机器人通常一次只打一个字母。但在戴上帽子后，机器人会尝试像变魔术一样，在检查对错之前，一次性猜出整整一个词块（16 个词）。

研究人员希望这能实现双赢：

无差异： 因为是同一个机器人，所以“词表（tokenizer）”是完美的。
组件更少： 他们不需要在内存中加载第二个机器人。
帽子很小： 这顶帽子只增加了极少量的额外参数进行学习。

大惊喜：帽子太重了

转折来了：它失败了。 事实上，它让速度变得更慢了。

研究人员发现，尽管这顶帽子是“参数高效（parameter-efficient）”的（它拥有的额外设置很少），但它并不是“计算高效（compute-efficient）”的。

想象一下戴着帽子的机器人。为了猜出那 16 个词，机器人仍然必须运行其整个庞大的大脑（完整的骨干网络）从头到尾跑一遍。然后，为了检查猜得对不对，它又必须在不戴帽子的情况下，再次运行其整个庞大的大脑。

这就像是你雇了一个快速的实习生，但实习生在回来见你之前，必须步行走到图书馆，读完整部百科全书，然后才写下答案。与此同时，名为“FastMTP”的方法（另一种成功的方法）则像是那个不需要走路、瞬间就能知道答案的实习生。

数据不会撒谎

研究人员在 Qwen3-0.6B 模型上进行了这项实验。结果如下：

“帽子”方法 (PEFT-BD)： 它平均每次能猜中更长的词列表（每轮接受 2.88 个 token），但整个过程极其缓慢。它的速度仅为 34.05 tokens/s。
“快速”方法 (FastMTP)： 它猜中的词较少（每轮接受 1.51 个 token），但它快如闪电，达到了 188.01 tokens/s。

尽管“帽子”方法猜对的词更多，但由于猜测的成本太高，总速度比另一种方法慢了五倍。

他们的教训

论文以一个简单而深刻的教训结束：仅仅获得更多的“接受词数”，并不意味着你更快。

为了让投机解码奏效，“猜测”步骤的运行成本必须显著低于“检查”步骤。在这个实验中，“猜测”步骤的成本几乎与“检查”步骤完全相同，因为机器人仍然需要完成所有的繁重工作。

研究人员使用分析工具进行了仔细测量，发现“草拟（猜测）”所花费的时间与“验证（检查）”所花费的时间几乎一致。他们甚至进行了一次模拟，假定“猜测”部分是免费的；即便如此，该方法也只能达到 67.셈.9 tokens/s，仍远不及成功的基准线 188.01 tokens/s。

总结

这并不是对“帽子”理念本身、或块扩散技术、或使用小型适配器的否定。这是针对这一特定设置的一个警告。

如果你想加速一个大型语言模型，你不能只是给它戴上一顶小帽子并寄希望于好运。你必须确保“猜测”部分确实比“检查”部分更轻量、更快速。如果“猜测者”所做的重体力活与“检查者”一样多，那么你并不是在节省时间，你只是在做两倍的功，却只得到了同样的结果。

简而言之：“接受的前缀（Accepted prefixes）”并不是你所需的一切。 如果猜测的成本与检查的成本相当，你就并没有赢。

技术摘要：仅有接受的前缀是不够的

问题陈述

自回归语言模型由于其逐 Token 顺序解码的特性，面临着高生成延迟的问题。投机采样（Speculative Decoding）通过使用一个“草拟者”（drafter）模型来提议多个未来的 Token，随后由较大的“目标”（target）模型进行验证，从而解决了这一问题。虽然这种方法减少了目标模型的顺序步骤数量，但其有效性依赖于一个关键的不对称性：草拟者的执行成本必须显著低于验证器。

现有的方法通常通过使用更小的草拟模型、专门的预测头或特征级草拟器来实现这种成本降低。然而，这些方法引入了服务复杂性，例如额外的模型权重、分词器不匹配以及对齐问题。本文研究了一种“同骨干网络”（same-backbone）方法——即在与验证器相同的骨干网络上使用参数高效的适配器（类似 LoRA）——是否能在避免上述开销的同时，仍然提供实际的加速。

方法论：PEFT-BD

作者提出了并评估了 PEFT-BD（参数高效微调块扩散，Parameter-Efficient Fine-Tuning Block-Diffusion），这是一种同骨干网络的投机采样方法，其设计如下：

架构： 验证器是原始的自回归模型。草拟器是附加在相同骨干网络上的类 LoRA 适配器。
机制： 该适配器通过使用块扩散目标（受 BD3LM 启发）从验证器进行蒸馏来训练。在推理期间，系统在两种模式之间切换：
1. 草拟（Drafting）： 启用适配器，模型执行单步去噪过程，以并行方式提出一个包含 $D=16$ 个未来 Token 的数据块。
2. 验证（Verification）： 禁用适配器，由基础自回归模型验证所提出的数据块。
动机： 该设计旨在消除分词器不匹配问题，无需单独的草拟模型，并在仅增加少量可训练参数的情况下实现并行生成多个 Token。

核心贡献

本文呈现了一个关于同骨干网络投机采样的聚焦型负面结果。主要贡献包括：

隔离失效模式： 作者证明，尽管 PEFT-BD 成功生成了非平凡的接受前缀，并与验证器共享分词器和骨干网络，但它未能提供实际的加速。
计算效率 vs. 参数效率： 研究隔离了这样一个条件：参数效率并不意味着计算效率。尽管适配器增加了极少的参数，但草拟过程仍然需要执行 Transformer 的全骨干网络前向传播。
成功的必要条件： 本文确立了这样一条原则：对于投机采样要产生加速效果，草拟器的计算成本必须低于验证器。当草拟计算量仍维持在验证器规模时，仅靠更长的接受前缀无法弥补损失。

实验结果

实验在 Qwen3-0.6B 指令微调模型上使用 TULU-3 数据集进行。

吞吐量： PEFT-BD 实现了 34.05 tokens/s 的平均吞吐量，显著低于 FastMTP 基准模型的 188.01 tokens/s。
接受前缀： 与“加速需要更少的接受 Token”这一直觉相反，PEFT-BD 产生的接受前缀实际上比 FastMTP（1.51 tokens/step）更长（2.88 tokens/step）。
延迟剖析： 性能分析显示，草拟过程（启用适配器）和验证过程（禁用适配器）具有几乎相同的延迟（~50ms）。草拟过程涉及完整的 Transformer 骨干网络执行，从而抵消了任何计算优势。
先验分析（Oracle Analysis）： 即使在一种乐观场景下——即将草拟成本降至零（同时保持验证成本和接受率固定）——PEFT-BD 的理论最大吞吐量也仅能达到约 67.9 tokens/s，仍远低于基准线。
消融实验： 增加去噪步数或使用锚定启发式算法并未解决瓶颈问题；事实上，额外的去噪进一步降低了吞吐量。

重要性与主张

本文得出结论：仅有接受的前缀对于成功的投机采样是不够的。这项工作的意义在于识别了同骨干网络适配器式草拟的一个结构性限制：

核心教训： “接受的 Token 并非免费的。”在 PEFT-BD 中，生成草拟内容的计算成本（一次全骨干网络前向传播）超过了更长接受前缀所带来的收益。
设计启示： 未来的同骨干网络投机方法必须专注于使草拟执行路径在计算上更轻量（例如，通过层跳跃、早期退出或轻量化头部），而不仅仅是优化参数效率或接受率。
范围： 作者明确指出，这并不是针对块扩散、PEFT 或通用轻量级草拟器（如 DFlash 或 EAGLE）的负面结果，而是专门针对那些草拟器需执行完整验证器骨干网络的方案。草拟器与验证器之间的计算不对称性仍然是实现加速的必要条件。