💬 NLP

LogitSpec: Accelerating Retrieval-based Speculative Decoding via Next Next Token Speculation

LogitSpec 是一种无需训练、即插即用的基于检索的推测解码方法，它通过利用最后一个 token 的 logits 来推测“下下个” token，从而扩展检索范围，实现高达 2.61 倍的加速和更高的 token 接受率。

原作者： Tianyu Liu, Qitan Lv, Hao Li, Xing Gao, Xiao Sun, Xiaoyan Sun

发布于 2026-04-30

📖 1 分钟阅读☕ 轻松阅读

原作者： Tianyu Liu, Qitan Lv, Hao Li, Xing Gao, Xiao Sun, Xiaoyan Sun

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

想象你是一位主厨（即大型语言模型，或 LLM），正试图撰写一份复杂的食谱。旧有的方法非常缓慢：你想出一个词，写下来，等待计算机检查它是否正确，然后想下一个词，如此循环。这就像一次只写一个字母地写信，每写一个字母都要等待一个批准印章。

推测解码（Speculative Decoding）是一种加速此过程的新方法。你不再一次只写一个词，而是雇佣一名副厨（一个草稿模型）来为你猜测接下来的几个词。然后你快速检查副厨是否猜对了。如果猜对了，你就一次性接受所有这些词。如果猜错了，你就直接扔掉错误的猜测并重新尝试。这节省了大量时间。

然而，雇佣副厨存在一些问题：

你必须专门为你的厨房培训他们（昂贵且困难）。
他们会在你的厨房中占用额外空间（内存）。
如果你更改了主食谱，你就必须重新培训副厨。

“检索”（图书馆方法）的问题

一些研究人员试图通过解雇副厨并改用图书馆来解决这个问题。计算机不再由人来猜测，而是查看你已经写下的内容，并在一个庞大的过往食谱数据库中搜索匹配的短语。

缺陷：这就像试图通过查看紧邻的前一个词来寻找句子中的下一个词。

你的句子：“圆的面积是多少……"（原文："What is the area of the..."）
图书馆的猜测：它看到“的”（the），心想：“哦，‘的’通常和‘三角形’（triangle）搭配！”（因为它找到了一句过去的句子：“三角形的面积是多少？”）。
现实：你实际上想说“圆的面积是多少？”（"What is the area of the circle?"）或者“田地的面积是多少？”（"What is the area of the field?"）。
结果：图书馆因为只关注直接上下文而非整体构思，而卡在了错误的词上。

解决方案：LogitSpec（“水晶球”主厨）

这篇论文的作者 LogitSpec 意识到，主厨（LLM）实际上拥有一个它不够经常使用的隐藏超能力。

当主厨预测下一个词时，它对于紧随其后的那个词也有某种“感觉”（在数学上称为logits）。尽管主厨本应只说出下一个词，但它的大脑已经在低语：“在那之后，很可能是‘圆’（circle）。”

LogitSpec 利用这种低语来修正图书馆的搜索。

以下是它的工作原理，分步说明，并使用了生动的类比：

1. “水晶球”步骤

LogitSpec 不再仅仅查看最后一个词（“的”），而是问主厨：“如果你必须猜测两步之后的词，那会是什么？”

主厨查看其内部的“感觉”并说：“我敢打赌‘的’之后的词是'圆'。”
这就是下一个下一个词推测（Next-Next Token Speculation）。

2. “超级搜索”步骤

现在，LogitSpec 不再仅仅搜索“的”，而是搜索短语"圆"。

旧方法（普通检索）：搜索“的”。找到“三角形”、“天空”、“狗”。（错误！）
LogitSpec 方法：搜索“圆”。找到“朋友圈”、“生命之圆”、“田地之圆”。（准确得多！）

3. 验证

计算机将这些更准确的猜测与主厨进行核对。由于这些猜测现在准确得多，主厨会更频繁地接受它们。

为什么这很重要？

无需额外训练：你不需要雇佣或培训新的副厨。你只需利用主厨已有的“感觉”（logits），它们原本就在那里。
即插即用：它适用于任何现有的语言模型，无需更改其代码或权重。
速度：在他们的测试中，这种方法使计算机撰写文本的速度提高了 2.6 倍。这也意味着计算机平均每次可以接受 3.28 个词，而不仅仅是一个。

核心结论

将 LogitSpec 想象成一名侦探，他不仅仅通过查看犯罪现场（最后一个词）来猜测接下来发生了什么。相反，侦探利用一种心理直觉（logit）来猜测下一个犯罪现场，然后利用这种直觉在图书馆中找到完美的证据。

通过向前看两步，该系统不再被外观相似的词所迷惑，而是能更快地找到正确的词，从而使 AI 在无需任何额外训练或昂贵硬件的情况下显著加快文本生成速度。

以下是论文《LogitSpec：通过下一词元推测加速基于检索的推测解码》的详细技术总结。

1. 问题陈述

大型语言模型（LLM）由于自回归解码（即每次前向传播仅生成一个词元）而遭受高推理延迟。**推测解码（SD）**通过使用小型“草稿”模型提出多个词元，并由目标模型并行验证来解决这一问题。

然而，现有的 SD 方法面临两个主要局限：

基于草稿模型的 SD： 需要训练和部署额外的草稿模型（例如 Medusa、Eagle）。这引入了显著的内存开销、复杂的部署挑战以及训练成本。
无草稿模型（基于检索）的 SD： REST 或 PLD 等方法无需草稿模型，而是从上下文或外部数据库中检索草稿词元。然而，它们依赖于一种经常失效的匹配范式。如果当前上下文在参考数据中没有精确的 n-gram 匹配，检索就会失败，导致接受率低下。正如论文所示，在某些场景下，标准检索方法在超过 30% 的解码步骤中无法找到匹配的词元。

核心挑战： 如何在无需训练额外模型的情况下，特别是在精确上下文匹配稀缺时，提高基于检索的推测解码的准确性。

2. 方法论：LogitSpec

作者提出了LogitSpec，这是一个无需训练、即插即用的框架，它利用最后一个词元的 logits来推测下下个词元（ $x_{i+2}$ ），从而增强基于检索的 SD。

关键洞察

论文通过实证观察发现，当前词元（ $x_i$ ）的 logits 分布包含足够的信息，即使不进行微调，也能以高精度预测下下个词元（ $x_{i+2}$ ）。在超过 50% 的解码步骤中，真实值的下下个词元出现在最后一个词元 logits 分布的前 60 个条目内。

LogitSpec 工作流程

LogitSpec 在每个解码步骤中运行两个主要阶段：

推测与检索扩展：
- 步骤 1（下一个词元）： 模型正常预测下一个词元（ $x_{i+1}$ ）。
- 步骤 2（下下个词元推测）： 不在此停止，LogitSpec 从最后一个 logits 中选取前 $k$ 个条目（排除预测的 $x_{i+1}$ ）作为下下个词元（ $\hat{x}_{i+2}$ ）的候选推测。
- 步骤 3（双重检索）： 系统为下一个词元（ $x_{i+1}$ $x_{i + 1}$ ）和推测的下下个词元（ $\hat{x}_{i+2}$ $\overset{x}{^}_{i + 2}$ ）检索相关参考。
  - 查询 1： $g^{(1)} = (x_{i-m+2}, \dots, x_i, x_{i+1})$
  - 查询 2： $g^{(2)} = (x_{i-m+3}, \dots, x_i, x_{i+1}, \hat{x}_{i+2})$
- 这有效地扩展了检索搜索空间。即使未找到 $x_{i+1}$ 的精确序列匹配，模型也可能找到 $x_{i+1} + \hat{x}_{i+2}$ 序列的匹配，从而显著增加找到有效草稿词元的概率。
草稿树构建与验证：
- 检索到的词元被组织成草稿树，其中 $x_{i+1}$ 为根节点，分支对应不同的推测下下个词元。
- 应用树注意力掩码，允许目标模型并行验证所有分支。
- 剪枝策略： 为了控制计算成本，根据推测下下个词元的排名应用启发式剪枝策略。高置信度的推测（排名较低）保留更多检索到的词元，而低置信度的推测保留较少。

3. 主要贡献

新颖观察： 作者证明，最后一个词元的 logits 可以在各种模型（Vicuna、Llama、Qwen）和任务中稳健地预测下下个词元，无需微调。
LogitSpec 框架： 一种新的基于检索的 SD 方法，利用下下个词元推测作为引导锚点来扩展检索范围。它是无需训练且即插即用的。
性能提升： 大量实验表明，LogitSpec 实现了高达2.61 倍的加速，每个解码步骤平均接受3.28 个词元，显著优于现有的基于检索的基线方法（REST、PLD、Lookahead）。
鲁棒性： 与其他在低重复上下文（如翻译或复杂推理）中表现不佳的检索方法不同，LogitSpec 保持了高性能，因为推测机制弥补了精确上下文匹配的缺失。

4. 实验结果

作者在多样化的基准测试中评估了 LogitSpec，包括Spec-Bench（机器翻译、翻译、摘要、问答、数学、RAG）、HumanEval（代码）、GSM8K（数学）、MATH、AIME 和 LongBench。

加速比：
- Vicuna-7B： 在 CNN/DM 上实现了2.61 倍加速，在 HumanEval 上实现了2.47 倍加速。
- 平均值： 在所有基准测试中，LogitSpec 在 Vicuna-7B 上平均实现了2.26 倍加速，而 REST 约为 1.33 倍，PLD 约为 1.78 倍。
接受率：
- 在 CNN/DM 上实现了3.28的平均接受词元数（MAT），而 REST 为 1.64。
- 在 LongBench（长上下文）上实现了2.01 倍加速，证明了其在海量上下文窗口下的有效性。
检索成功率：
- 标准检索方法（PLD）在超过 30% 的步骤中未能找到匹配。
- LogitSpec 在 Spec-Bench 上实现了**97.76%**的成功检索率，这是由下下个词元引导带来的巨大提升。
开销：
- 由于采用了高效的基于哈希的实现，检索过程增加了微不足道的开销（总挂钟时间的**~1.17%**）。
- 该方法与现有框架（如 Hugging Face Transformers）兼容，且不需要额外的 GPU 内存来存储草稿模型。

5. 意义与影响

消除训练成本： LogitSpec 消除了训练或维护单独草稿模型的需求，使推测解码可立即用于任何预训练的 LLM。
解决“冷启动”检索问题： 通过利用模型自身的预测能力（logits）来引导检索，它克服了基于检索的方法在上下文重复率低时失效的根本局限。
可扩展性： 该方法在不同模型尺寸（0.5B 到 70B）和架构上表现良好，证明了“下下个词元”信号是现代 LLM 的基本属性。
实际部署： 作为即插即用方案，它可以轻松集成到生产推理引擎（如 vLLM）中，以加速 LLM 服务，而无需架构更改或重新训练。

总之，LogitSpec通过巧妙地重新利用模型内部 logits 来增强检索，实现了接近草稿模型的性能而无需相关成本，代表了高效 LLM 推理的重要一步。