推测解码完全指南

说明：本文整合自 Leonie Monigatti 的博客 How speculative decoding makes LLMs go brrr、Local AI Master 的博客 Speculative Decoding Complete Guide (2026)、Ryoma Sato 的博客 Speculative Decoding Explained、Modular 官方手册《LLM Inference Handbook》与 JarvisLabs 的博客 Speculative Decoding in vLLM，版权归原作者所有。

基于 Transformer 的大语言模型（LLM）以自回归方式生成文本。这意味着文本是一个 token 一个 token 地生成的，而每个 token 都需要模型做一次完整的前向传播。这种顺序依赖关系使推理延迟与输出长度成正比，因此生成很慢。对于延迟敏感的应用——如实时对话或多轮智能体（agentic）工作流——这在生产环境中是一个真正的瓶颈，而推测解码正是为克服这一瓶颈而生的。

推测解码是一种在保持输出质量不变的前提下降低解码延迟的推理优化技术。它由 Chen 等人（2023，DeepMind）[1] 和 Leviathan 等人（2023，Google）[2] 几乎同时独立提出。

什么是推测解码？

推测解码让 LLM 在单次前向传播中生成多个 token。它的工作方式是：将一个小型"草稿"模型与全尺寸的目标模型（即你真正想要服务的原始 LLM）配合使用。草稿模型运行成本低、速度快（通常只是一个 Transformer 块），承担繁重的自回归预测工作，预测出若干个 token。目标模型并行处理这些 token：对于每个 token，目标模型判断自己是否认同草稿的预测——如果拒绝某个 token，则丢弃序列的其余部分；否则将这些 token 纳入响应中。

这种方法有三个关键优势：

1. 它是一种精确（exact）方法，最终响应与单独使用目标模型时来自相同的分布，不会带来模型性能下降。
2. 目标模型能够并行验证多个 token。
3. 由于草稿模型很小，运行它通常只产生极小的开销。

总而言之，这可以将模型延迟降低 2-3 倍，从而显著加快生成速度。

痛点：解码为什么一开始就很慢

在自回归 Transformer 中，每个 token 都必须顺序生成：计算 logits、采样或选择 token、追加、再次计算，如此循环。这种顺序依赖在每一步都引入了延迟。即使有了 GPU 这样的并行硬件，解码速度也受限于这种序列化流程。

推测解码正是针对这一瓶颈：与其等待目标模型逐 token 生成，不如让一个廉价的草稿模型快速提出多个 token，再利用目标模型的并行验证能力来确认它们。

关键的一点是：并非每个 token 都同样难以预测。很多下一个 token 很容易预测（例如补全常见短语或闭合括号），小模型也能像目标模型一样猜对；相比之下，涉及特定事实或生僻词的 token 更难预测，需要更强大的模型。推测解码正是利用这种不平衡——用轻量的草稿机制廉价地处理简单 token，而把那些需要目标模型充分判断的困难 token 留给验证阶段来处理。

为什么推测解码有效：带宽瓶颈

LLM 推理的每 token 成本由两部分组成：

• 计算（Compute）：约 $2\times \text{params}\times \text{batch}\times \text{tokens}$ FLOPs
• 内存带宽（Memory bandwidth）：将所有权重从 HBM 加载到计算单元（每次前向传播约 $\text{params}\times \text{bytes\_per\_weight}$）

以 70B BF16 模型为例，为单个用户逐个生成 token 时：每步必须有 140 GB 的权重从 HBM 移动到 SM。在 H100（3 TB/s HBM）上，这意味着无论你生成多少个 token，都有 47 ms 的下限。实际的矩阵乘法耗时不足 1 ms。因此在单次前向传播中生成 1 个 token 与生成 5 个 token 的墙钟时间大致相同——带宽主导了一切。

推测解码正是利用这一点：用廉价的过程推测 $K$ 个 token，让目标模型在 $K+1$ 个位置上一次性前向传播，并接受与目标模型本会生成的 token 相匹配的前缀。若接受率为 $\alpha$，则每次目标模型前向传播可生成约 $1+\alpha K$ 个 token，而不是 1 个。自回归生成是内存受限（memory-bound）而非计算受限的，每一步都重新加载权重并同步内存，GPU 的并行计算能力被闲置——推测解码恰恰把这些闲置算力转化成了额外的 token。

核心循环：快速草拟，并行验证

固定一个参数 $\gamma$，即每次提出的草稿 token 数量。草稿模型生成 $\gamma$ 个 token：$x_1,x_2,\dots ,x_{\gamma }$，然后目标模型并行验证这些 token。

接下来是让一切运转起来的接受/拒绝逻辑：

• 如果 $x_1,\dots ,x_i$ 被接受，但 $x_{i+1}$ 被目标模型拒绝，则确认 $x_1,\dots ,x_i$ 以及目标模型产生的第 $(i+1)$ 个 token $x_{i+1}^{\prime }$。
• 如果全部 $x_1,\dots ,x_{\gamma }$ 都被接受，则确认 $x_1,\dots ,x_{\gamma }$ 以及目标模型产生的第 $(\gamma +1)$ 个 token $x_{\gamma +1}^{\prime }$。

生成过程以已确认的前缀为条件（例如 $x_1,\dots ,x_i,x_{i+1}^{\prime }$）继续，并重复同样的模式。

这里的"接受"并非简单的完全匹配，而是一种概率规则——拒绝采样（rejection sampling）。它的精确形式、为何能保持目标分布不变，将在下一节的推测采样算法中给出。

推测采样：从目标分布精确采样

现在深入下去，介绍一种具有代表性的技术——推测采样（speculative sampling） [1] [2]。

记目标模型的分布为 $p_t$，草稿模型在续写上的分布为 $q_d$。目标是高效地从目标模型的分布 $p_t$ 中采样。

给定草稿模型的输出 $x_1,\dots ,x_{\gamma }\sim q_d$，你可能会尝试最朴素的验证策略：也独立采样 $x_1^{\prime },\dots ,x_{\gamma }^{\prime }\sim p_t$，并且仅当 $x_i=x_i^{\prime }$ 时才接受 $x_i$，否则拒绝。

然而，即使草稿模型是完美的，这种策略也会灾难性地失败。假设：

$$p_t(x)=q_d(x)=\text{Unif}(\{1,\dots ,100\}).$$

这里 $q_d$ 与 $p_t$ 完全一致。然而，如果你独立地从 $p_t$ 采样，$x_i=x_i^{\prime }$ 的概率只有 1%。这意味着 99% 的时间都在拒绝。如此高的拒绝率使得朴素方法无法产生任何有意义的加速。

那该怎么办呢？可以设计一种验证规则：当 $q_d$ 接近 $p_t$ 时接受率很高，当 $p_t=q_d$ 时全部接受。这正是推测采样给出的方案。

推测采样的接受规则

首先从草稿模型中采样 $\gamma$ 个 token：$x_{:\gamma }\sim q_d(x_{:\gamma })$。然后把这些 token 输入目标模型，并（并行地）计算条件概率 $p_t(x_i\mid x_{:i-1})$，其中 $i=1,\dots ,\gamma +1$。由于 $x_{:\gamma }$ 已经齐备，这些条件概率可以并行计算。

对每个位置 $i$，按照以下规则决定是否接受草稿 token $x_i$：

1. 如果 $q_d(x_i\mid x_{:i-1})\le p_t(x_i\mid x_{:i-1})$，则接受 $x_i$。
2. 否则，采样 $r\sim \text{Unif}(0,1)$，若满足下式则接受 $x_i$：

$$r<\frac{p_t(x_i\mid x_{:i-1})}{q_d(x_i\mid x_{:i-1})}.$$

3. 如果 token 未被接受，则它被拒绝，并从以下分布中采样一个新 token $x_i^{\prime }$：

$$\text{normalize}(max(0,p_t(x_i\mid x_{:i-1})-q_d(x_i\mid x_{:i-1}))).$$

如果被接受，就继续处理 $i+1$。如果被拒绝，过程停止，生成流程以草稿模型为驱动、以截至该点的已确认 token 序列为条件继续。

根据 token 被接受还是被拒绝，一个循环会有不同的结束方式：

• 如果所有草稿 token 都被接受，目标模型会追加一个奖励 token（bonus token），该 token 在验证前向传播中生成。
• 如果某个草稿 token 被拒绝，它及其之后的所有草稿 token（即使它们可能是正确的）都会被丢弃，目标模型从残差分布重新采样来纠正被拒绝的 token。

换句话说，草稿 token 只有在其被目标模型接受时才会保留，被拒绝的 token 及其后续草稿一律丢弃——不会损失任何准确性。

为什么这是精确的：分解视角

直觉上，接受/拒绝规则对应一种概率质量的分解。可以严格验证：被接受的 token 分布恰好等于 $p_t$。

要理解这一点为何严格成立，可以把目标的概率质量分为两部分：与草稿分布 $q$ 重叠的部分，以及目标比草稿更想要该 token（$p>q$）的剩余部分。被接受的草稿 token 覆盖了重叠部分，因为这些是两个模型一致认同的 token；剩余部分则由重采样步骤覆盖——每当草稿被拒绝时，就从中抽取修正 token。被接受与重采样的 token 合在一起，精确地重构了目标分布 $p$，这正是推测解码不引入质量损失的原因。

定义集合：

$$\mathcal{D}=\{x\mid q_d(x_i\mid x_{:i-1})>p_t(x_i\mid x_{:i-1})\}.$$

现在考虑两种情况。

对于 token $x_i\in \mathcal{D}$：该 token 以概率 $q_d(x_i\mid x_{:i-1})$ 由草稿模型生成，并根据规则 (2) 以概率 $\frac{p_t(x_i\mid x_{:i-1})}{q_d(x_i\mid x_{:i-1})}$ 被接受。因此接受概率为：

$$q_d(x_i\mid x_{:i-1})\cdot \frac{p_t(x_i\mid x_{:i-1})}{q_d(x_i\mid x_{:i-1})}=p_t(x_i\mid x_{:i-1}).$$

对于 token $x_i\notin \mathcal{D}$：该 token 以概率 $q_d(x_i\mid x_{:i-1})$ 由草稿模型生成，并根据规则 (1) 总是被接受。此外，当草稿模型生成一个属于 $\mathcal{D}$ 的 token 时，它被拒绝的概率为：

$$C={\int }_{\mathcal{D}}(1-\frac{p_t(x_i\mid x_{:i-1})}{q_d(x_i\mid x_{:i-1})})\text{d}{x}_i$$

并根据规则 (3) 从以下分布中采样一个新 token：

$$\frac{p_t(x_i\mid x_{:i-1})-q_d(x_i\mid x_{:i-1})}{C}$$

因此，总的接受概率为：

$$q_d(x_i\mid x_{:i-1})+C\cdot \frac{p_t(x_i\mid x_{:i-1})-q_d(x_i\mid x_{:i-1})}{C}=p_t(x_i\mid x_{:i-1}).$$

无论哪种情况，token 都以概率 $p_t(x_i\mid x_{:i-1})$ 被接受。所以这个过程是精确的：你仍然是在从目标模型的分布中采样。

这类似于拒绝采样，但有一个关键的操作性差异：标准的拒绝采样可能反复拒绝，而在这里，token 保证最多三步内解决——直接接受、按概率接受，或拒绝后从残差分布采样一次。

性能量化：接受率与接受长度

两个量在实践中很有用：

• 接受率（Acceptance rate）$\alpha$：草稿 token 被目标模型接受的平均概率，即逐 token 接受概率对位置和上下文取平均。
• 接受长度（Accepted length）$\tau$：一次推测循环中期望产出的 token 数，包括在拒绝之后或草稿被完全接受之后由目标模型发出的那个 token。

对于推测长度 $\gamma$ 和平均接受率 $\alpha$，在假设各位置接受相互独立的简化条件下，Leviathan 等人 [2] 给出的期望接受长度 $\tau$ 为：

$$\tau =\sum _{i=0}^{\gamma }{\alpha }^i=\frac{1-{\alpha }^{\gamma +1}}{1-\alpha }$$

其中 $i=0$ 项对应目标模型在验证期间总会发出的那个 token。即使第一个草稿 token 被拒绝，该循环仍会生成一个 token；如果全部 $\gamma$ 个草稿 token 都被接受，验证前向传播还会额外生成一个目标 token。因此接受长度 $\tau$ 的取值范围在 1 到 $\gamma +1$ 之间。

尽管加速还取决于批处理、内存开销等许多其他因素，Sadhukhan 等人 [3] 提出的下面这个公式可以很好地近似平均逐 token 延迟 $L$，它由草拟时间 $T_{\text{draft}}$、验证时间 $T_{\text{verify}}$ 和接受长度 $\tau$ 表示：

$$L=\frac{T_{\text{draft}}+T_{\text{verify}}}{\tau }$$

这个近似公式说明，推测解码在以下情形下会提升解码速度：

• 草拟变得更准确（$\tau$ 增大）；
• 草拟变得更快（$T_{\text{draft}}$ 减小）；
• 或者验证变得更快（$T_{\text{verify}}$ 减小）。

接受率如何影响性能

理论上，推测解码的有效性高度依赖接受率。为了分离这一变量，可以用预设概率接受每个草稿 token 来模拟推测，而不是运行真正的草稿模型。例如，BentoML 基准测试 就用了一个打过补丁的 vLLM 设置做这件事；Modular MAX 支持推测解码，并提供了 --synthetic-acceptance-rate 参数用于同类受控测试。模拟基准测试显示了四种模式：

1. $\alpha$ 越高，加速越大。
2. 增大 $\gamma$ 只在 $\tau$ 较高时有帮助；否则性能可能受到负面影响。
3. 延迟随 $\alpha$ 近乎线性下降，吞吐量近乎线性上升。
4. 当 $\alpha \ge 0.6$ 且 $\gamma \ge 5$ 时，推测解码相比基线解码实现了 2-3 倍加速。

然而在实践中，加速往往低于预期。

不同工作负载下性能如何变化

合成接受率测试分离了 $\alpha$ 和 $\gamma$ 的影响，但真实部署还要面对并发和并行。另一组基准测试在不同的并发级别和张量并行（TP）配置下测量了推测解码，用 vLLM 在 H100 GPU 上服务 Llama-3.3-70B-Instruct：

• TP = 1：相比基线，总吞吐量更早进入平台期（约 20-30 个并发请求时），表明草稿模型与目标模型的协调在高负载下可能带来开销。不过，每输出 token 时间（TPOT）改善了约 2 倍。
• TP = 2：推测解码性能提升，相对基线表现出明显的吞吐量优势；但更高的推测 token 数（$\gamma =5$）在高并发（40+ 请求）下出现更大的延迟尖峰。

总体而言，推测解码在不同工作负载下都降低了 TPOT。增加并行度（TP = 2）提升了吞吐量，但你需要在高负载下调优 $\gamma$ 以避免延迟尖峰。

注意：以上结果来自非正式测试，仅供参考。性能因模型、硬件、工作负载和框架选择而异。生产环境采用前，请务必在你自己的条件下对推测解码进行基准测试。

推测解码的草拟策略

延迟近似公式表明，推测解码主要是一个草拟器设计问题：一方面，一个聪明但缓慢的草拟器会削弱推测解码承诺的延迟加速；另一方面，一个快速但经常出错的草拟器会把计算浪费在被目标模型拒绝的草稿 token 上。当前研究很大一部分都在探索这一取舍：如何让草拟既快又准。

下面按方法的内在逻辑顺序逐一介绍：从免训练的检索式方法（n-gram、Suffix Decoding），到经典的双模型方案（独立草稿模型），再到把草拟器内置进目标模型的方法（Medusa、MLP Speculators、MTP），进而到复用目标隐藏状态的特征级方法（EAGLE 系列）与并行草拟方法（DFlash、DSpark）。

n-gram 推测

零训练的推测方法：维护一个近期上下文 token 的缓冲区。生成时，在提示与已生成文本中查找最近的 N 个 token——若存在匹配，则从该匹配处复制接下来的 K 个 token 作为草稿。

提示: "def fibonacci(n):\n    if n <= 1:\n        return n\n    return fibonacci(n-1) + fibonacci(n-2)"
用户: "Now write iterative version."
生成: "def fibonacci(n):\n    if n <= 1:\n        return n\n    [从提示中草拟: a, b = 0, 1...]"

接受率：代码 30-60%，对话 20-40%，结构化输出（JSON、XML）50-70%，重复性内容（长上下文摘要、编辑操作）80% 以上。

加速比：典型负载 1.3-2 倍，重复性内容最高 3 倍。成本：零额外显存、零训练。对大多数工作负载而言，这是应首先尝试的推测方法。

Suffix Decoding

Suffix Decoding 是一种精妙的、免模型（model-free）的加速技术，专为智能体循环（agentic loops）和代码生成等重复性工作负载设计。与占用内存的草稿模型不同，它利用历史文本中的模式，完全在 CPU 上运行，因此非常适合在不增加 GPU 内存开销的情况下最大化速度。

该技术在概念上与 n-gram 匹配类似——选取一些最近生成的 token 并在过去搜索它们。区别在于搜索方式：n-gram 匹配在提示和生成文本中执行线性扫描；而 Suffix Decoding 使用预先构建的树数据结构，使模式查找更快，尤其是当文本历史增长时。

双后缀树缓存与模式匹配

其核心是高效的后缀树（Suffix Tree）数据结构，存储来自两个来源的历史模式：

树类型	模式来源	在推测中的用途
每请求树（局部）	当前提示和请求中到目前为止生成的 token	捕获正在进行的对话中即时、自我重复的模式
全局树	vLLM 服务过去处理的所有请求的输出	提供常见 LLM 输出的深层统计知识，对智能体循环中的重复至关重要

每一步，Suffix Decoding 都会寻找长的匹配模式（从 $t-p+1$ 到 $t$）用于推测：进行中的序列（$x_1$ 到 $x_t$）是生成到当前 token $t$ 为止的完整文本，模式长度 $p$ 是最近序列的大小，模式序列（$x_{t-p+1}$ 到 $x_t$）是最后 $p$ 个 token。系统尝试"沿"双后缀树向下走来匹配该模式；如果找到，就到达节点 $N_p$，其所有下行路径都是该模式的可能续写。

打分与贪心扩展

检查每一个可能的未来序列在计算上很昂贵，因此 Suffix Decoding 构建一个聚焦的"推测树"，依赖两个概率分数决定生长哪些分支：

• 单步概率（$C(N)$）：这个特定 token 跟随前一个 token 的可能性有多大？
• 路径置信度（$D(N)$）：整个序列（从根到这个 token）正确的可能性有多大？这是决策的主要过滤器。

一个新 token 的置信度基于通向它的路径的置信度：

$$D(N)=D(\text{Parent})\times C(N)$$

要得到新节点 $N$ 的路径置信度，取父节点的置信度乘以新 token 的单步概率；如果在根节点，置信度就是 1（即 100%）。贪心过程从最后一个匹配的 token（$N_p$）开始，计算可用下一步的路径置信度，将置信度最高的叶节点加入树，不断重复直到树达到最大允许规模（MAX_SPEC）。这保证了计算能力只花在扩展模型最可能实际使用的序列上。

三阶段工作流

Suffix Decoding 的算法分为三个阶段：

1. 寻找模式：当前 token（例如 8, 5, 4, 8, 5）与两个后缀树匹配（顶部对应进行中的推理，底部对应之前的输出），识别出所有可能的推测树候选。
2. 构建推测树：使用接受概率（$D(N)$）为候选打分，贪心地选择最有希望的分支，得到一个单一、紧凑的推测树。
3. 验证与生成：目标模型接收原始序列加上整个推测树，执行单次前向传播，token 被并行验证。在结果中，目标模型接受了部分 token（例如 1 和 3），它们被添加到最终输出（8, 5, 4, 8, 5, 1, 3），通过一步接受多个 token 加速生成。

这个完整的模式匹配与草拟过程极快（在 CPU 上运行），而且是自适应的：推测的 token 数量（MAX_SPEC）会根据模式匹配长度动态调整，以避免浪费计算。Suffix Decoding 的核心思想来自 Oliaro 等人（2024） 的论文 Suffix Decoding: A Model-Free Approach to Speeding Up Large Language Model Inference。

独立草稿模型

Chen 等人 [1] 和 Leviathan 等人 [2] 的原始实现使用了一个双模型系统：一个小型草稿模型 + 一个目标模型。草稿模型通常是来自与目标模型同一家族（相同 tokenizer、相近的指令微调风格）的较小参数模型。后来的工作还会从目标模型蒸馏草稿模型以提高接受率。

使用独立草稿模型，可以开箱即用地借助现成模型，无需额外训练，据报道可获得 2-3 倍的加速。但这种方法需要托管第二个模型。此外，由于草稿模型本身也是自回归的，超过最优草稿长度后加速会下降——因为每多一个草稿 token 就增加一个顺序的草稿步骤，而带来的接受率增益却在递减。

让我们用经典短语 "The quick brown fox" 来说明整个工作流程的加速效果：

1. 猜测：快速草稿模型查看 "The quick brown fox"，预测 5 个新 token——"jumps over the lazy dog"（注意：正确短语应为 "jumps over the log"）。
2. 检查：强大的目标模型获取文本和 5 个猜测，运行一次检查来同时验证它们。
3. 结果：目标模型审查概率——"jumps"接受、"over"接受、"the"接受、"lazy"拒绝（目标模型计算出这里 "log" 才是可能词，"lazy" 的概率太低，无法通过拒绝检查）。
4. 加速：即使在第 4 个 token 上失败，也在通常只生成一个 token 的时间里成功生成了 3 个 token（"jumps over the"），这一步就是 3 倍加速。
5. 纠正：目标模型用正确词替换被拒绝的 "lazy"："log"。下一轮从新的确认文本 "The quick brown fox jumps over the log..." 重新开始草拟过程。

Medusa

Cai 等人 [4] 提出了 Medusa，完全消除了托管独立草稿模型的运维成本。它不维护独立的草稿模型，而是在预训练语言模型的最终隐藏层上添加额外的头：其中第 $i$ 个头预测位置 $i+1$ 的 token（目标模型自己的 LM 头已经覆盖了下一个 token）。

这些头通过自蒸馏（self-distillation）训练，以预测基础模型的输出。根据训练预算，可以只训练这些头、训练整个模型，或使用参数高效微调（parameter-efficient fine-tuning）来训练整个模型。

在生成过程中，预测下一个 token 的头产生 $s_1$ 个候选，预测两步之后 token 的头产生 $s_2$ 个候选，依此类推，直到预测 $K$ 步之后 token 的头产生 $s_K$ 个候选。这些组合起来共形成 $s_1\cdot s_2\cdot \dots \cdot s_K$ 个长度为 $K$ 的候选序列，然后由目标模型使用树注意力（tree attention）并行验证。

Medusa 有两个优势：(i) 只需要维护一个模型，以及 (ii) 可以并行生成多个草稿候选。

Medusa-1 方法报告约 2.2 倍加速，而 Medusa-2 报告 2.3-3.6 倍加速、每步接受长度 3.0-3.5 个 token。虽然这免去了托管第二个模型的成本，但额外的预测头需要额外的训练。此外，由于每个预测头独立预测其位置，草稿质量在后段位置会衰减，降低接受率。

MLP Speculators

MLP Speculator 技术构建在 Medusa 架构之上，并由 IBM 改进，目标是达到完整草稿模型的预测精度，同时避免加载整个第二 LLM 的巨大内存成本。核心思想来自 Wertheimer 等人（2024） 的论文 Accelerating Production LLMs with Combined Token/Embedding Speculators。

架构：多头轻量预测器

Speculator 是一个多阶段、多头 MLP，直接附着在目标模型上。与只预测一个 token 的标准模型不同，该架构具有专门用于向前看 1、2 或 3 步的预测头。MLP 以目标模型的上下文嵌入向量（内部状态 $Z$）为基础；关键是，后续每个头都以前一个头采样出的 token 为条件进行预测——头 1 预测 token $T_2$，头 2 接受该预测并预测 $T_3$，依此类推。

训练：逐头损失计算

训练过程中目标模型被冻结，MLP 使用交叉熵损失训练，但系统为每个推测步骤计算三个独立的损失——${\text{Loss}}_{t+1}$（头 1 与 token $t+1$ 真实值之间的误差）、${\text{Loss}}_{t+2}$、${\text{Loss}}_{t+3}$。分开跟踪这些损失很重要，因为预测紧邻的下一个 token（$t+1$）"更容易"、损失下降快，而预测更远的未来（$t+3$）更难且依赖前几步的准确性，损失曲线更高——分开计算可以避免近期误差被远期误差掩盖。

训练分两个阶段：

1. 阶段 1：输入对齐（代理数据）：speculator 在长上下文的标准文本数据批次上训练，学会将目标模型的嵌入映射到有效的下一个 token。
2. 阶段 2：输出对齐（模型蒸馏）：训练切换到使用目标模型自己生成的输出作为真实值，迫使 MLP 精确模仿冻结目标模型本会生成的内容，使 MLP 的"个性"与目标模型对齐。

推理与预测

MLP Speculator 通过快速顺序预测多个 token 来工作：目标模型先做一次前向传播产生上下文嵌入向量；MLP Speculator 随后取该上下文向量，快速生成 $K$ 个推测 token（使用第一个被预测 token 的 logits 条件化第二个预测，构建序列 $T_{t+1},T_{t+2},\dots ,T_{t+K}$）；整个推测序列被捆绑发送给目标模型，在单次前向传播中验证。

生产环境的关键优势

• 海量显存节省：MLP 很小（通常参数约为 1/10 或更少），相比完整草稿模型内存开销微乎其微。
• 高接受率：通过利用目标模型自身的上下文，预测高度准确，将墙钟推理速度加速 2-3 倍。
• 高效：直接附着在目标模型上，避免了复杂的独立模型管理。

多 token 预测（MTP）

多 token 预测（Multi-token Prediction, MTP）由 Gloeckle 等人 [11] 提出，它并非为了推测解码而设计，而是为了训练更好的模型。MTP 使用与 Medusa 相同的多头思想：增加多个额外的输出头，各自预测更靠后的 token。一次性预测多个 token 是一种更丰富的学习信号，能让模型本身变得更强。高达 3 倍的推理加速只是副产品。

目的不同，与 Medusa 的主要差异也就产生了：

• 目标：Medusa 把预测头加装到一个已经训练好的模型上来加速草拟；而 MTP 在预训练阶段训练这些头以让基础模型变得更好，并顺带免费获得一个草拟器。
• 基础模型：Medusa 不改变模型的输出质量；而 MTP 会提升它。
• 适用性：Medusa 可以添加到任何现成的检查点；而 MTP 必须从一开始就纳入训练。

EAGLE / EAGLE-2 / EAGLE-3

EAGLE（Extrapolation Algorithm for Greater Language-model Efficiency，更高语言模型效率的外推算法）系列由 Li 等人 [5] 提出，并在 EAGLE-2 [6] 和 EAGLE-3 [7] 中得到扩展。这是一种在特征层面（feature level）进行草拟的推测解码方法，从目标模型的内部隐藏状态出发进行外推。

虽然把草拟器折叠进目标模型消除了维护第二个模型的开销，但 Medusa 的 token 级预测头是相互独立的，这意味着草拟器会逐个预测头地重新推导目标模型已经计算过的上下文。EAGLE 把"内置草拟器"这一想法再推进一步：它不直接预测未来的 token，而是利用并复用冻结目标模型中特征级别的上下文：

• EAGLE（2024）[5]：直接预测下一个特征（隐藏状态）而非下一个 token，以提高接受率。为此，它在目标模型上挂接一个在特征层面运行的小型自回归草拟器：取目标模型顶层的特征（紧邻 LM 头之前）以及先前采样 token 的嵌入，将二者融合以预测下一个位置的特征，再将预测出的特征通过其冻结的 LM 头生成一个草稿 token。据报道可带来 2.7-3.5 倍的推理加速（对 LLaMA2-Chat 70B 报告）。
• EAGLE-2（2024）[6]：引入了动态草稿树，根据草拟器的置信度自适应地调整树结构，让草拟器能够探索多条生成路径，对可预测的文本产生更长的分支、对复杂部分产生更短的分支。据报道可带来 3.05-4.26 倍的推理加速。
• EAGLE-3（2025）[7]：用直接 token 预测取代特征预测，改进了训练目标。通过训练时的"测试"（Training-Time Test）让草拟器基于其自身反馈的输出进行训练，弥合训练与推理之间的输入分布差异；同时融合来自目标多个层的特征，而非仅依赖顶层。据报道加速最高可达 6.5 倍。

不过，EAGLE 的草稿机制仍然是自回归的，这意味着草拟成本随草稿长度增长，且错误会在整个块内累积。下面介绍的并行草拟器正是为了克服这一点。

DFlash

DFlash 由 Chen 等人 [8] 提出，是一个使用轻量块扩散模型（block diffusion model）进行并行草拟的推测解码框架。与 EAGLE 类似，DFlash 把目标模型的内部特征视为丰富的草拟信号，但它不是逐 token 草拟，而是并行地生成整个块，将并行块扩散模型在草拟上的速度与自回归目标模型在验证上的质量结合起来。

上面几乎所有草拟变体都是自回归的。然而，自回归草拟器的顺序特性带来了与自回归解码相同的瓶颈。在 DFlash 自己的基准测试下，这使自回归草拟器的加速被限制在约 2-3 倍。

自回归生成的一个有效替代方案是使用扩散 LLM 进行并行生成。不过，代价是当前扩散模型生成的输出质量通常低于自回归模型。尤其是完全并行的扩散模型存在固定长度生成的问题，且缺乏高效的 KV cache 支持。块扩散模型 [9] 通过同时去噪一批被掩码的 token 来解决这些问题，从而实现并行生成，同时缩小与自回归模型之间的质量差距。

为此，目标是训练草稿模型使其与目标分布对齐。这是可行的，因为目标模型的隐藏特征编码了关于未来 token 的信息并捕获了长距离依赖。让草拟器以这些上下文特征为条件，它就能以高接受率预测未来的 token 块。具体来说，DFlash 通过以下步骤实现：

1. 提取上下文特征：目标模型先对给定提示执行一次标准 prefill 前向传播，生成第一个 token（锚点 token）。在此过程中，从一组固定的层提取隐藏表示，拼接后通过一个投影层融合为紧凑的目标上下文特征。
2. 通过 KV 注入进行目标特征条件化：融合后的上下文特征被注入草稿模型的 KV cache，用于每一层的注意力机制。这使得接受长度能随着草稿层数的增加而持续提升，而不是趋于平台期。
3. 块并行扩散草拟：扩散草拟器在单次前向传播中，通过并行去噪所有被掩码的位置，生成一整块未来 token。每个草稿块以一个锚点 token（一个已知 token，草拟器以它为条件预测块的其余部分）开头。训练时，DFlash 从真实答案中采样这些锚点，并掩码每个锚点之后的 block_size - 1 个位置，然后草稿模型并行预测这些被掩码的 token。

DFlash 在其最佳基准上报告高达 6 倍以上的加速，平均加速接近 4-5 倍。其接受长度也随草稿层数有效扩展，意味着更深的草拟器会提升接受率而非陷入平台期。

由于并行草拟器在单次前向传播中产出所有草稿位置，其草拟延迟几乎与块大小无关。这降低了草拟延迟，即使使用更深的草稿模型也能实现高得多的硬件利用率。原则上，这让并行草拟器可以生成更长的草稿块，而更高质量的草稿反过来又会提高接受率。但在实践中，由于缺乏 token 间依赖，它们往往面临接受率快速衰减的问题。

DSpark

DSpark 由 Cheng 等人 [10] 提出。它表明，推测解码在大规模下不仅是草拟问题，也是验证问题。因此，DSpark 推测解码框架通过半自回归（semi-autoregressive）架构，将快速并行生成与自适应的、感知负载（load-aware）的验证相结合。

并行草拟器有两个主要缺点：

• 生成质量：由于并行草拟器独立预测块中的每个位置，它们缺乏 token 间依赖。虽然草稿块早期的 token 可能很强，但后期的位置会遭受后缀衰减（suffix decay）。
• 验证浪费：虽然并行生成能快速产生长草稿块，但这些块只有在草稿 token 会被接受时才有用。在高并发下，验证风险高（很可能被拒绝）的长草稿块，会浪费目标模型本可用于服务其他请求的关键批次容量。

DSpark 保留了并行的优势，同时通过两个核心思想补足了所需的顺序结构：

• 半自回归生成：将并行主干与轻量顺序头相结合，以建模块内依赖并缓解后缀衰减。并行主干为草稿块生成隐藏状态和基础 logits，而顺序头在块内从左到右采样，并加上一个依赖前缀的转移偏置。这样草拟器既能获得大部分块并行速度，又让每个采样 token 都能依赖之前的草稿 token。
• 置信度调度验证（Confidence-scheduled verification）：DSpark 决定对每个请求验证草稿的多少部分，而非使用固定长度。一个置信度头估计每个草稿 token 有多大可能通过验证；一个感知硬件的前缀调度器将这些估计与引擎当前的负载和吞吐量结合起来，为每个请求选择要验证的草稿 token 数量。

DSpark 方法提高了接受长度、减少了验证浪费，并在吞吐量匹配的条件下，将单用户生成速度提升了 60-85%。不过，DSpark 的收益以复杂度为代价：它增加了一个顺序头、一个置信度头和一个感知负载的调度器，以及它们所需的校准与服务集成。此外，它的调度可靠性完全取决于置信度估计，而置信度在分布偏移下可能会漂移。

方法分类与选型

上面的草稿-验证模式描述的是经典设置——由独立的更小模型负责草拟。但这只是生成草稿 token 的一种方式。大体上，这些方法可以分为四类：

• 独立草稿模型（Standalone draft model）：一个独立的更小模型提出 token（即经典方式）。
• 目标专属辅助草拟器（Target-specific auxiliary drafter）：一个专门为目标模型训练的轻量模型提出 token 或隐藏特征。EAGLE 属于这一类，通常使用独立的检查点。
• 模型集成草拟器（Model-integrated drafter）：额外的预测头或模块包含在目标模型检查点中，如 Medusa 或原生 MTP 模型。
• 免训练或检索式方法（Training-free or retrieval-based methods）：候选 token 通过算法生成或从提示与已生成上下文中检索，无需经过训练的草稿组件。

没有普遍最优的方法，正确的选择取决于你的需求：

方法	额外草稿模型	是否需要训练	说明
经典推测解码	是	否（可选微调）	匹配一个好的草稿模型可能比较棘手
Medusa	否（额外预测头）	是（预测头）	中等加速
MTP	否	是（预训练时联合训练）	需要 MTP 训练的模型（如 DeepSeek-V3）
n-gram	否	否	零配置收益，适用于基于输入的任务
EAGLE	是	是（草稿模型）	报告加速强劲，框架支持广泛

vLLM、MAX 和 SGLang 等推理框架实现了其中多种方法，因此你可以在投入之前，针对自己的工作负载对它们进行基准测试。

推测解码的实践应用

推测解码在实践中是否划算，取决于目标模型运行的条件。

在低批次大小下，自回归解码是内存带宽受限的（参见为什么推测解码有效：带宽瓶颈）。每一步都从内存重新加载模型权重，而 GPU 的算术单元大多闲置。推测解码把闲置的计算转化为额外的 token——以大约一个 token 的成本验证 $\gamma +1$ 个位置。这正是它带来最大收益的场景。

随着批次大小增大，是否仍然成立取决于上下文长度。当有大量短上下文请求同时进行时，目标模型的矩阵乘法会从内存受限变为计算受限，验证额外的草稿 token 不再接近免费：它要与其他请求争夺已经饱和的计算资源，加速会缩小，而验证那些很可能被拒绝的草稿 token 甚至会降低整体吞吐量。

在推测解码划算的情况下，它已开箱即用地内置于大多数主流服务栈中，如 vLLM、SGLang、llama.cpp 或 MLX。每个框架都允许挂接一个草稿模型，其中几个还支持 EAGLE 或 Medusa 风格的草拟器，只需几个配置标志即可，例如：

python -m sglang.launch_server \
    --model-path <目标模型> \
    --speculative-algorithm DFLASH \
    --speculative-draft-model-path <草稿模型>

使用技巧

推测解码可以带来实实在在的收益，但前提是仔细配置。关键在于弄清楚它在哪些场景最有用、哪些场景可能适得其反。

留意内存开销

你需要把草稿模型和目标模型都加载到 GPU 内存中。在单张 GPU 上，这会很快挤占其他任务（如批处理）的空间，在高负载或使用较大模型时损害性能。对于多 GPU 配置（如 TP > 1），情况则不同——将模型拆分到多张 GPU 上可以缓解瓶颈，例如在 50 个并发请求下，$\gamma =3$ 或 $\gamma =5$ 的推测解码仍可持续优于基线。

不要忽视浪费的计算

当目标模型拒绝了太多草稿 token 时，GPU 仍然会花时间生成和验证它们。这些工作没有回报，反而违背了推测加速的初衷，这也是接受率如此重要的原因。

选对草稿模型

草稿模型的分布与目标模型的匹配程度决定了接受率。开箱即用的草稿模型在某些情况下可能工作正常，但面对特定领域任务或超长上下文时往往表现不佳。如果你的工作负载有自己的特点，在自己的数据上微调一个草稿模型通常会得到更好的结果——它能学会更贴近目标模型，从而提高接受率和加速比；反过来，如果你已经看到了不错的接受率，就可以跳过训练，照样受益。

实测基准：哪种方法在你的场景胜出？

以上各节的理论讨论最终要落到实测上。JarvisLabs 在受控生产环境中使用 vLLM 运行了广泛的基准测试，在 ShareGPT（1000 条提示，通用对话）与 SWE-bench Lite（300 个样本，编码与智能体）两个数据集上，对比了 n-gram 匹配、Suffix Decoding、EAGLE 与 EAGLE-3，并包含基线（无推测）作为对照。测试硬件为单块 NVIDIA L40S（8B 模型）与双块 NVIDIA H200（70B 模型），使用 vLLM 内置的 vllm bench serve 压力测试工具。

注意：这些结果针对 Llama 模型（3.1-8B 与 3.3-70B）在 ShareGPT 与 SWE-bench 上的表现，来自非正式测试。你的实际收益可能因模型架构、数据集特征、硬件与框架选择而异，生产环境采用前务必在自己工作负载下重新基准测试。

Llama-3.1-8B（效率层级，单 L40S）

8B 模型是计算受限而非内存受限的——模型权重轻松容纳在 GPU 内存中，瓶颈转移到矩阵乘法的执行速度。因此目标模型本身已经很快，推测解码需要极低的开销才能提供有意义的加速。

通用对话：EAGLE 胜出（ShareGPT）

在开放式对话中，EAGLE 技术（v1 和 v3）更优——人类对话不可预测，简单模式匹配难以看得很远，而 EAGLE 的学习式"草稿头"能一次准确预测 2-3 个 token。基线为 421 tok/s。

解码技术	输出吞吐量 (tok/s)	每输出 token (ms)	加速比
n-gram 匹配	491	21.85	1.17 倍
Suffix Decoding	585	18.21	1.39 倍
EAGLE-3	589	17.90	1.40 倍
EAGLE（赢家）	601	17.49	1.43 倍

值得注意的是，EAGLE 的 token 间延迟（31.1ms）反而高于基线（23.4ms），但通过以"块"而非逐词生成，整体速度显著更快。

编码任务：Suffix Decoding 胜出（SWE-bench-lite）

排行榜在编码场景完全翻转：代码高度结构化（重复的变量名、缩进模式、样板 import），Suffix Decoding 通过匹配长模式最大化接受率，以 534 tok/s 领先（基线 370 tok/s）。而两种 EAGLE 变体都难以匹敌——这证实了对较小模型和刚性任务，简单启发式匹配往往胜过复杂训练预测器，因为草稿模型的开销超过了其收益。

解码技术	输出吞吐量 (tok/s)	每输出 token (ms)	加速比
n-gram 匹配	406	23.90	1.10 倍
EAGLE	398	24.40	1.08 倍
EAGLE-3	379	25.56	1.03 倍
Suffix Decoding（赢家）	534	18.10	1.45 倍

Llama-3.3-70B（规模层级，双 H200）

70B 模型展示了内存带宽才是最终瓶颈：每一步和每次内存访问都很昂贵，移动数据（权重）所花的时间是最大的瓶颈，而更大的模型使这更糟。

通用对话：EAGLE-3 胜出（ShareGPT）

EAGLE-3 使用更先进、更轻量的草稿头预测接下来的几个 token，精度高得多，显著减少重型 70B 模型被完整访问的次数。相比之下，标准 EAGLE 仅达到 351 tok/s（1.02 倍），几乎与基线（343 tok/s）持平——这凸显了关键发现：对 Llama-3.3-70B 架构，升级到 EAGLE-3 是看到真实收益的必要条件。

解码技术	输出吞吐量 (tok/s)	每输出 token (ms)	加速比
EAGLE（标准）	351	22.81	1.02 倍
n-gram 匹配	385	21.90	1.12 倍
Suffix Decoding	455	18.24	1.33 倍
EAGLE-3（赢家）	537	15.95	1.57 倍

编码与智能体：EAGLE-3 保持领先（SWE-bench-lite）

尽管智能体工作流文本重复度高、通常有利于模式匹配，EAGLE-3 仍以 601 tok/s 保持领先（基线 375 tok/s，比 Suffix Decoding 多生成近 80 tok/s）——70B 的 EAGLE-3 草稿模型足够稳健，比最好的启发式方法更有效地预测结构化代码模式。

解码技术	输出吞吐量 (tok/s)	每输出 token (ms)	加速比
EAGLE（标准）	377	25.38	1.01 倍
n-gram 匹配	416	23.20	1.11 倍
Suffix Decoding	522	18.32	1.39 倍
EAGLE-3（赢家）	601	15.73	1.60 倍

选型结论

综合四组基准，模型规模确实改变了规则：

使用场景	建议技术	原因
通用聊天机器人（客服、角色扮演）	EAGLE / EAGLE-3	训练过的草稿头更适合预测流畅、不可预测的人类对话
编码助手（小模型）	Suffix Decoding	计算受限模型上，低开销启发式匹配利用代码重复而不增加草稿开销
编码与智能体（大模型）	EAGLE-3	内存受限的 70B 模型上，准确预测减少了昂贵的目标访问
严格硬件限制（显存有限）	Suffix Decoding	无需额外权重、无需训练——内存紧张时是"免费"的性能提升

一个实用的起点是从 Suffix Decoding 开始——它无需训练、无需额外显存、立即可用，是"低垂的果实"；如果你部署更大模型（70B+）并需要最大吞吐量，再投入精力设置 EAGLE-3。

自适应推测解码

大多数推测解码部署使用固定的推测 token 数或草稿步数（$\gamma$）。它可能对基准测试有效，但对生产环境中的每个请求来说很少是最优的。真实工作负载是动态的：下一个 token 的可预测性在生成过程中不断变化，批大小也随请求进出系统而波动。当草稿模型高度准确且批大小较小时，较大的推测窗口可能效果很好；但当接受率下降或批大小增长时，同一个窗口可能变得低效。

因此固定 $\gamma$ 是一种妥协。自适应推测解码通过在运行时调整推测解码参数而非依赖单一配置来解决这个问题，目标是让推测与当前条件保持对齐。

什么可以自适应？

自适应推测解码可以修改推测过程的一个或多个方面：

• 推测长度（Speculative length）：草稿模型在交给目标模型验证之前提出多少个 token。调优这是最常见、风险最低的自适应形式——它只改变速度，输出仍与目标模型本会产生的完全一致（无损）。例如，系统可以在接受率高、资源可用时增大推测长度，在接受率下降或系统饱和时减小。
• 接受标准（Acceptance criterion）：目标模型验证每个草稿 token 的严格程度。放宽验证会让更多"足够接近"的 token 通过，这加速了生成，但允许输出偏离目标模型的精确分布（有损）。这是用少量质量换取额外速度，应当审慎使用。

现有方案

自适应推测解码是一个活跃的研究领域，当前方案从生产就绪功能到研究原型不一而足。

SGLang 自适应推测解码

SGLang 提供了内置的自适应推测解码机制，在推理过程中动态调整推测长度。每轮验证之后，SGLang 测量接受的草稿 token 数量，维护接受长度的指数移动平均（EMA），并据此在少量预定义的推测长度档位（例如默认的 [1, 3, 7]）之间切换。每个档位都有自己的预捕获 CUDA 图，因此切换成本很低，无需重新捕获图。该方法是反应式（reactive）、批级别（batch-level）的，并且无损——因为它只调整推测长度，保留原始验证算法。

AdaSpec

AdaSpec 是一个基于 vLLM 构建的研究型 LLM 推理系统，采用了更复杂的预测式方法：它试图在草拟开始前预测不同推测长度的效率。AdaSpec 使用草稿模型的置信度分数估计接受率，并将这些估计与一个考虑批大小和上下文长度等因素的性能模型相结合，然后选择一个在满足服务等级目标（SLO，例如 TPOT 目标）的同时最大化性能的推测配置。作者报告，在真实服务轨迹上，AdaSpec 始终实现高 SLO 达标率，相比之前的推测服务系统提供高达 66% 的加速。

AdaSD

AdaSD 是一种研究型解码算法，主要面向开箱即用的草稿与目标模型配对。与大多数自适应方法不同，AdaSD 同时自适应推测长度和接受标准，引入两个由运行时统计动态调整的阈值：草稿 token 熵决定草稿模型何时应停止生成额外的推测 token；草稿与目标分布之间的 Jensen-Shannon（JS）距离决定草稿 token 是否足够接近目标分布从而被接受。由于 AdaSD 可以接受不严格满足原始接受规则的 token，它是一种有损方法——作者报告，在其基准上相对朴素推测解码最高 1.46 倍加速，同时将准确率下降限制在 1.8% 以内。AdaSD 要求草稿模型和目标模型共享相同的词表，因为熵和 JS 距离的计算直接作用于两个模型产生的 token 概率分布。

自适应推测解码何时值得使用？

当服务条件随时间显著变化时，自适应推测解码最为有用，例如突发的流量模式、快速变化的批大小、混合工作负载，或接受率大幅波动的应用。在这些情况下，动态适应当前条件通常优于任何单一的固定推测长度。另一方面，如果你的工作负载稳定，并且你已经为模型和硬件调优了静态 $\gamma$，自适应机制可能只带来边际收益。与推测解码的总体情况一样，唯一可靠的方法是：在应用于生产之前，先在你自己的模型、硬件和工作负载下进行基准测试。

总结

推测解码通过结合轻量草拟机制与并行验证，在不改变输出的前提下加速了 LLM 推理：由目标模型进行并行验证，从而保持目标分布不变。要让其有效运作，草拟器必须既快又准。

近年来的推测解码方法沿着这条权衡路径不断演进：从独立的草稿模型，到内置于目标的草拟头（Medusa、MLP Speculators、MTP），再到复用目标自身隐藏状态的特征级自回归草拟器（EAGLE 系列），进而到一次生成整个块的并行块扩散草拟器（DFlash），最后到与负载感知验证调度搭配的半自回归草拟（DSpark）。当服务规模超过一定水平后，推测解码不再只是草拟问题，同时也是验证调度问题。

方法	草拟模式	接受长度*	报告的加速
独立草稿模型	自回归	~3.6 个 token	2-3 倍
n-gram	检索（n-gram 匹配）	~1-4 个 token	1.3-2 倍
Suffix Decoding	检索（后缀树）	~2-6 个 token	1.3-1.45 倍
MLP Speculators	并行（多头 MLP）	~2-3 个 token	2-3 倍
Medusa	并行（多头）	~3.0-3.5 个 token（Medusa-2）	2.2-3.6 倍
EAGLE-3	自回归	~5-7.5 个 token	6.5 倍
DFlash	块并行扩散	~4-8 个 token	>6 倍
DSpark	半自回归	~3.1-6.2 个 token	1.6-1.85 倍**

* 接受长度通常是在不同模型和数据集上报告的，因此只能作为参考，不能直接比较。

** DSpark 未报告相对标准（非推测）自回归解码的墙钟加速。该数字是相对 MTP-1 生产基线的单用户生成加速。

参考文献

• [1] Charlie Chen, Sebastian Borgeaud, Geoffrey Irving, Jean-Baptiste Lespiau, Laurent Sifre, John Jumper（2023）Accelerating Large Language Model Decoding with Speculative Sampling。
• [2] Yaniv Leviathan, Matan Kalman, Yossi Matias（2023）Fast Inference from Transformers via Speculative Decoding。ICML 2023。
• [3] Rohan Sadhukhan, Jian Chen, Zheyu Chen, Vikram Tiwari, Ruihang Lai, Jiayu Shi, I. En-Hsu Yen, Avner May, Tianqi Chen, Beidi Chen（2025）MagicDec: Breaking the Latency-Throughput Tradeoff for Long Context Generation with Speculative Decoding。ICLR 2025。
• [4] Tianle Cai, Yuhong Li, Zhengyang Geng, Hongwu Peng, Jason D. Lee, Deming Chen, Tri Dao（2024）Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads。ICML 2024。
• [5] Yuhui Li, Fangyun Wei, Chao Zhang, Hongyang Zhang（2024）EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty。ICML 2024。
• [6] Yuhui Li, Fangyun Wei, Chao Zhang, Hongyang Zhang（2024）EAGLE-2: Faster Inference of Language Models with Dynamic Draft Trees。EMNLP 2024。
• [7] Yuhui Li, Fangyun Wei, Chao Zhang, Hongyang Zhang（2025）EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test。NeurIPS 2025。
• [8] Jian Chen, Yesheng Liang, Zhijian Liu（2026）DFlash: Block Diffusion for Flash Speculative Decoding。[链接待更新]
• [9] Marianne Arriola, Aaron Gokaslan, Justin T. Chiu, Zhihan Yang, Zhixuan Qi, Jiaqi Han, Subham Sekhar Sahoo, Volodymyr Kuleshov（2025）Block Diffusion: Interpolating Between Autoregressive and Diffusion Language Models。ICLR 2025。
• [10] Xin Cheng, Xingkai Yu, Chenze Shao, Jiashi Li, Yunfan Xiong 等（2026）DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation。[链接待更新]
• [11] Fabian Gloeckle, Badr Youbi Idrissi, Baptiste Rozière, David Lopez-Paz, Gabriel Synnaeve（2024）Better & Faster Large Language Models via Multi-token Prediction。ICML 2024。