其实就是在speculative decoding的基础上，多种方式ensemble
另外，lstm都来了，死去的记忆攻击我。。
btw，要问投机解码是什么，cursor的fast apply用的就是投机解码。
图 1. 使用 vLLM 中的推测式解码，运行在 8 张 H100 GPU 上的 Llama-3.1-70B-Instruct 的生成速度。
在这篇博客中，我们展示了我们在推测式解码方面的最新工作，以及 Arctic Inference + vLLM 如何在 SWE-Bench 任务中实现 LLM agent 4 倍的平均推理速度提升，在开放式交互任务中实现高达 2.8 倍的解码速度提升（相较于未使用推测的 vLLM）。
在发布时，Arctic Inference 是 vLLM（v0.8.4）中最快的推测解码方案，显著超过了 vLLM v1 中的原生 N-gram 和 EAGLE 推测器，在多个工作负载中表现优异。
本研究成果包含在 Snowflake AI Research 开源的以下项目中：
- Arctic Inference：一个兼容 vLLM 的插件，支持快速推测与验证
- Arctic Training：一个支持可复现 YAML 配方的推测器训练框架
- 预训练的推测器覆盖：Llama-3.1-8B、Llama-3.1-70B、Llama-3.3-70B、Qwen2.5-32B
接下来的博客将介绍我们构建的内容、如何快速上手、以及我们的方法论的深入讲解。如需引用我们的工作，请查看下方 BibTeX 引用。
为什么传统推测解码在真实世界中效果不佳
生成延迟仍是现代 LLM 应用的主要瓶颈——会减慢聊天助手、代码工具和多步骤智能体流程的响应速度。长时间的等待不仅降低生产力，也让用户感到沮丧，限制了智能体应用的实际可用性。
推测解码是一种解决方案，它通过并行预测和验证多个 token，大幅减少聊天机器人、编程助手和复杂智能体流程的延迟。然而，现有开源推测解码解决方案存在多个问题（见图 2）：
- 它们无法充分利用许多智能体应用中的重复生成模式（如自反性循环、多路径推理），因为即使存在大量重复 token，它们也只预测少量 token。
- 它们缺乏一个简单且标准化的框架，来训练自定义草稿模型并无缝部署到线上。这对于预测开放式对话中非重复生成模式是必要的。同时，系统级开销也使草稿模型无法达到理论峰值加速。
图 2. 智能体代码生成中的重复模式（左）与草稿模型推测的实际加速 vs. 理论加速（右）
Arctic Inference 与 Arctic Training 的增强推测式解码
我们很高兴介绍我们为 Arctic Inference 和 Arctic Training 系统引入的增强推测式解码能力，解决了上述挑战，具体包含两类改进：
✅ 针对重复生成的后缀解码
- 解锁了跨长 token 序列的高效推测
- 在 CPU 上每个推测 token 解码仅需 20 微秒
- 无需草稿模型
✅ 针对非重复生成的推测训练与推理管道
- 提供易用的训练管道，用于训练强大且轻量的草稿模型
- 实现了优化的推测代码路径，在 vLLM 中实现高达 91% 的理论最大加速
我们最终将这两者结合，实现了“鱼与熊掌兼得”：显著降低重复与非重复任务的生成延迟（见图 1）。例如：
- 在像 SWE-Bench 这样的智能体任务中，Llama 3.3 70B 推理速度提升最高达 4 倍，任务完成速度提升 1.8–4.5 倍
- 在 ShareGPT 等开放对话和 HumanEval 代码生成任务中快 2.8 倍
- 比 vLLM 中现有最好的开源方案还快 1.8 倍
以下将介绍如何在现有 vLLM 部署中使用 Arctic Inference 的增强推测解码功能，以及如何使用 Arctic Training 自定义草稿模型。
推测解码方法深入解析
对于想要深入了解技术细节的读者，以下内容将介绍推测解码的背景、我们为重复与非重复任务构建的架构、以及在 SWE-Bench、ShareGPT 和 HumanEval 数据集上的真实基准测试。
什么是推测解码？
推测解码的核心思想是使用一个更小、更快的模型来“预判”可能的未来 token，然后由主模型对这些 token 进行并行验证。
我们可以将推测解码流程分为三部分：
- Proposer（提议器） ：通常是一个较小且成本较低的语言模型（称为草稿模型），快速生成一组候选 token（例如 3 到 5 个）。它也可以是无模型的，例如从提示中提取 n-gram。
- Scorer（评分器） ：这是我们要保持输出质量的大型 LLM。它不再只生成一个 token，而是接收提议器生成的一整段草稿 token，在一次前向传播中并行评分。
- Verifier（验证器） ：用于决定哪些 token 被接受的步骤，通常采用拒绝采样（rejection sampling）机制。
接受率及其意义
“接受率”是评估推测解码效果的关键指标，表示在每个解码步骤中，提议器提出的 token 有多少最终被验证器接受。
高接受率意味着草稿模型能准确预测主模型的输出，因此每次验证能生成更多 token，整体速度更快。
而低接受率说明预测经常出错，导致解码效率下降。
平衡接受率与草稿开销
在推测解码中，存在一个基本的权衡：
- 高接受率意味着草稿质量好，可以获得更高加速；
- 但也要控制草稿模型本身的计算开销，否则得不偿失。
因此，要根据模型和工作负载特征，设计一个能平衡“接受率”与“计算资源”的优秀推测器。
一个简单示例
图 3：一次推测解码步骤示意图
图中展示了一个典型的推测解码过程：
- 在初始预填阶段生成状态。
- 提议器生成 3 个候选 token：13、578、7301。
- 评分器（主模型）并行评分这些 token，并将它们与最后一个验证通过的 token（如 16）一起输入。
- 验证器采用采样策略，决定接受其中的 13 和 578，之后生成 token 21747。
本例中，推测解码步骤中接受了 2 个 token（共 3 个），接受率为 66.7%。
后缀解码：适用于重复（智能体）生成
许多智能体工作流涉及自我反思循环、多路径推理等，包含大量可预测且重复的 token 序列。但大多数推测解码方法一次只预测几个 token，未能充分加速这些场景。
我们提出了一种轻量级的新型推测方法 —— 后缀解码（Suffix Decoding） ，针对该类问题设计：
- 它利用文本结构的重复性，从历史输出和当前输入中动态构建候选序列；
- 不再预测固定数量的 token，而是自适应地识别最可能出现的长序列。
核心机制如下：
- 构建一个紧凑的 后缀树（suffix tree），索引历史生成和当前提示中的重复 token；
- 使用此结构可快速查找并匹配重复模式，实现快速推测；
- 每个候选 token 的优先级基于频率评分（经验概率）；
- 主模型一次 forward pass 即可验证整个推测序列。
图 4：使用两个后缀树（提示 + 历史输出）进行后缀解码，匹配最近生成的 token 并根据频率生成候选 token。
后缀解码实际效果
后缀解码显著优于现有推测方法，尤其适用于涉及重复 LLM 查询的智能体任务。
在 SWE-Bench 中（结合生成 + 执行动作），后缀解码实现了 1.8x–4.5x 的加速。
提升非重复任务的推测性能
易用的推测器训练配方
草稿模型（draft model）在推测解码中是一个成熟的方法，尤其适用于开放式对话这类重复性较低的场景。但由于缺乏标准化的训练工具，其应用仍受限制。
我们提出 Arctic Training 框架 来解决这个问题，提供可访问、标准化的训练配方：
- 每个配方包含数据集、超参数、模型架构，统一定义在一个 YAML 文件中，易于复现和分享。
- 框架支持任意草稿模型架构，但我们重点优化了类似 MLP-Speculator 的设计，因其在接受率与推理延迟之间表现良好。
我们提供了两种草稿模型的完整训练流程，包括数据生成：
- MLP-Speculator（图 5a） ：简单的前馈模型，使用 LLM 最后隐藏状态和上一个 token 的 ID，结构类似 RNN。
- LSTM-Speculator（图 5b） ：MLP 的扩展版本，引入标准的 LSTM 门（遗忘、输入、输出、状态门），展示训练框架的灵活性。
图 5. （a）MLP-Speculator 与（b）LSTM-Speculator 架构示意图。
| 模型 | 参数量 (B) | 接受率 |
|---|---|---|
| MLP-Speculator（公开） | 2.1 | 13.7% |
| MLP-Speculator（Arctic） | 2.1 | 42.7% |
| LSTM-Speculator（Arctic） | 1.8 | 44.5% |
表 1. 在 Llama 3.1-70B-Instruct 上对比三种推测器，数据集：ShareGPT。
我们训练的 speculator 明显强于现有开源基线。训练策略如下：
- 与常见的“两阶段训练”（真实数据预训练 + LLM 生成数据微调）不同，
- 我们只使用 LLM 生成的合成数据（基于 UltraChat 与 MagiCoder prompt），
- 并延长训练周期，达到 3.1x 更高的接受率。
我们还用更少参数的 LSTM 模型进一步提升效率。所有训练管道都可以通过 YAML 配方完全复现。
推测推理管道优化
推测解码由 Proposer（推测器）、Scorer（大模型）和 Verifier（验证器）组成。我们对整个推理路径进行了系统优化：
推测器优化：
-
FP8 量化：压缩线性层带宽瓶颈，降低推测器延迟。
-
张量并行（TP） ：将计算分散至多个 GPU，减轻单卡负担，提高吞吐。
-
通信优化：
- 原始路径：Logits（分片） → AllGather → Logits（全局）→ TopK（全局）
- 优化路径：Logits（分片） → TopK（分片） → AllGather → TopK（全局）
-
CUDA Graphs：将整个推测模型和推理循环封装进一个 CUDA 图，减少 kernel 启动开销。
通过上述改进，MLP 推测器延迟从 ~1.47ms/token 降至 ~0.47ms/token，加速约 3.1x。
验证器优化：
- 从 拒绝采样 改为 贪婪验证（只有与贪婪解码一致的 token 被接受），在不影响准确率的前提下简化操作。
- 自定义轻量 CUDA 内核将验证器延迟从 ~1.34ms 降至 ~0.38ms，加速约 3.5x。
整体系统优化：
- 精简推测逻辑（例如将采样替换为 TopK，移除无用元数据和数据结构），降低 CPU 和 GPU 的整体开销。
综合来看，在使用相同草稿模型的情况下，我们在 vLLM V0 上实现了 高达 1.42x 的端到端加速，达到了推测解码理论上限的 91% 性能，即使在 vLLM 高度优化的基线上也是如此。
联合使用后缀解码与草稿模型推测
前文我们分别介绍了后缀解码擅长处理重复性任务，草稿模型适用于开放式对话等非重复任务。但在真实世界中，LLM 往往同时面对这两类任务。
幸运的是，我们可以将这两者结合起来：
- 后缀解码已有的 scoring 函数可用于选择候选 token。
- 其评分是根据历史生成模式对 token 是否被接受的经验估计。
因此，我们可以用一个简单规则来二选一：
- 使用后缀解码生成候选 token。
- 如果评分低于 draft 模型最多能推测的 token 数，则丢弃后缀候选，改用 draft 模型；
- 否则，直接使用后缀候选。
性能评估
我们首先展示：借助后缀解码（Suffix Decoding），在智能体工作负载（例如来自 OpenHands 的 CodeAct 编码代理）中实现了最先进的生成性能，端到端加速高达 1.8x–4.5x（涵盖生成与动作执行任务）。
其次，我们展示：在开放式对话（ShareGPT）与通用编码任务（HumanEval）上，使用 Llama 3.1 70B 模型，相较于优化后的非推测实现（如 vLLM V1 FP8 + TP=8）可实现高达 2.45x 的加速；相较于 vLLM 中最优推测方案（如 EAGLE+vLLM V1）快 1.82x。
使用后缀解码加速编码智能体
我们设计后缀解码是为了解决智能体任务中大量可重复 token 的问题。例如，OpenHands 的 CodeAct 2.1 智能体在 SWE-Bench 上达到 SOTA 性能（解决真实 GitHub 问题）。
一个 CodeAct 智能体会执行以下流程：
- 接收用户的指令与反馈；
- 生成代码并在沙箱环境中执行；
- 观察执行结果；
- 向用户响应新的建议。
其背后由一个定制训练的 LLM（如 all-hands/openhands-lm-32b-v0.1-ep3）驱动，在每一步反复调用 LLM 进行推理和规划。这些 LLM 查询在总耗时中占据了主导。
为加速 CodeAct，我们在这些核心推理步骤中使用后缀解码，并与 vLLM 中其他方法对比：
- prompt-lookup 解码（如 N-gram 推测）
- vanilla 解码（不使用推测）
由于该 LLM 没有可用的 EAGLE-3 草稿模型，因此未进行对比。结果见下图。
图 6. Arctic Inference 中使用后缀解码进行 SWE-Bench 性能评估。
结果显示，后缀解码相较于原始解码将解码时间缩短了 2.3x–6.3x，对应整体完成时间减少 1.8x–4.5x。
目前，在 vLLM 中运行 SWE-Bench 时，Arctic Inference 的后缀解码是最快的实现，较 prompt-lookup 解码（如 vLLM 中的 N-gram）还快 1.4x–3.9x，同时仍保持与原始智能体相当甚至更高的解决率（>37%）。
这些加速来源于推理查询中出现的重复：
- 代码修复：因执行反馈修复生成代码，新生成的代码与之前高度重复；
- 多路径推理：每个步骤多次查询 LLM 提高鲁棒性，但这些路径之间重复度高。
加速开放式对话与代码生成任务
我们也评估了在开放式对话（ShareGPT）与代码生成（HumanEval）中的推测性能。方法：
- 使用 Arctic Training 训练的 MLP/LSTM 推测器；
- 基于 Arctic Inference 实现，运行于 vLLM V1；
- 使用 Llama 3.1 70B；
- 请求速率设为 0.5 req/sec。
对比基线：
- 非推测（vLLM V1，FP8，TP=8）
- 推测（使用公开 MLP-Speculator 或 EAGLE/EAGLE-3 草稿）
- FlashAttention 使用性能最好的版本（V2 或 V3）
我们注意到：EAGLE/EAGLE-3 的理论加速并未在 vLLM 中实际体现，原因可能包括草稿未在相似数据集微调、vLLM 缺少 tree-decoding 支持、或推测推理路径中存在额外开销。
结果展示
图 7. 左图：相较非推测解码，我们的改进带来 2.05x–2.45x 的加速；右图：相较于 EAGLE 推测方案快 1.69x–1.84x。
| 推测器 | ShareGPT | HumanEval |
|---|---|---|
| 公共 MLP（vLLM V0） | 77.9 tok/s | 66.7 tok/s |
| Arctic MLP（vLLM V0） | 120.5 tok/s | 144.7 tok/s |
| 提升幅度 | +54.7% | +116.9% |
表 2. Arctic MLP/LSTM 推测器 vs 公开 speculator 对比
| 框架 | ShareGPT | HumanEval |
|---|---|---|
| vLLM V0 | 120.5 tok/s | 144.7 tok/s |
| Arctic + vLLM V0 | 153.1 tok/s | 186.6 tok/s |
| Arctic + vLLM V1 | 171.2 tok/s | 205.8 tok/s |
| 提升幅度 | +42.1% | +42.2% |
表 3. 加入系统优化的推测解码管道性能提升
联合使用后缀解码 + 草稿推测：终极效果
我们还评估了联合使用后缀解码与草稿推测的表现，基准测试覆盖 ShareGPT、HumanEval、SWE-Bench 及其混合负载。指标为平均输出 token/s。
| 工作负载 | 无推测 | N-gram（vLLM） | EAGLE（vLLM） | LSTM（Arctic） | 后缀解码（Arctic） | LSTM + 后缀（Arctic） |
|---|---|---|---|---|---|---|
| ShareGPT | 76.0 | 91.2 | 102 | 172 | 113 | 179 |
| HumanEval | 77.2 | 100 | 112 | 204 | 148 | 217 |
| SWE-Bench | 75.8 | 175 | — | 123 | 286 | 302 |
| 混合 | 82.9 | 112 | — | 154 | 155 | 209 |
表 4. Arctic Inference 中联合使用 LSTM + 后缀解码的性能评估
可见：
- LSTM 在 ShareGPT/HumanEval 上表现最好；
- 后缀解码在 SWE-Bench 上领先；
- 二者联合后，在所有工作负载上都至少持平甚至超越单一方案；
- 在混合负载中比单独方案多出 55 tokens/s 的吞吐。
这说明：无需在后缀与模型推测之间二选一，两者结合即可兼顾所有任务类型。
使用 Arctic Inference 部署推测解码
后缀解码、MLP/LSTM 草稿推测器以及本博客中描述的系统优化全部都集成在开源项目 Arctic Inference 中。
Arctic Inference 是由 Snowflake AI Research 开发的开源库，包含当前与未来的 LLM 推理优化功能。它通过 vLLM 的自定义插件机制集成在 vLLM v0.8.4 中，使我们可以快速开发、集成优化，并将其开放给社区使用。
一旦安装完成，Arctic Inference 会自动补丁 vLLM，将本文中的推测式解码功能集成进去，用户仍可继续使用熟悉的 vLLM API 与 CLI。
安装 Arctic Inference
pip install "git+https://github.com/snowflakedb/ArcticInference.git#egg=arctic-inference[vllm]"
安装后，Arctic Inference 会向 vLLM 的 --speculative-config 参数添加多个可选配置。
例如，以下命令会启用 MLP/LSTM 草稿推测器 + 后缀解码：
vllm serve \
meta-llama/Llama-3.1-70B-Instruct \
--quantization "fp8" \
--tensor-parallel-size 2 \
--speculative-config '{
"method": "arctic",
"model":"Snowflake/Arctic-LSTM-Speculator-Llama-3.1-70B-Instruct",
"num_speculative_tokens": 3,
"enable_suffix_decoding": true
}'
解释：
"method": "arctic"：启用 Arctic 的推测器与优化路径；"model"：使用指定的 Arctic 训练草稿模型；"enable_suffix_decoding": true：开启后缀解码功能。
使用 Arctic Training 训练自定义草稿模型
Arctic Training 让你可以轻松训练适配不同 LLM 与工作负载的草稿模型，并直接用于 Arctic Inference 中部署。
安装 Arctic Training：
pip install arctic-training
在 Arctic Training 中，每个训练配方完全通过单个 YAML 文件定义，便于复用与复现。
示例 YAML 文件：
model:
name: LSTM-Speculator
hidden_dim: 2048
num_layers: 2
training:
batch_size: 64
learning_rate: 1e-4
epochs: 10
data:
type: synthetic
prompts: [UltraChat, MagiCoder]
target_model: meta-llama/Llama-3.1-70B-Instruct
output_dir: ./output/lstm-speculator-70b
保存为 config.yaml 后，仅需执行：
arctic_training config.yaml
训练完成后，你就可以将模型路径填入前述 --speculative-config 的 "model" 字段，直接部署上线使用。
引用方式
如果你希望在研究或博客中引用本项目，请使用以下 BibTeX 格式：
@misc{arctic-speculator,
author = {Wang, Ye and Oliaro, Gabriele and Lee, Jaeseong and He, Yuxiong and Qiao, Aurick and Rajbhandari Samyam},
title = {Fastest Speculative Decoding in vLLM with {Arctic Inference} and {Arctic Training}},
year = {2025},
month = {May},
day = {1},
howpublished = {\url{https://www.snowflake.com/en/engineering-blog/fast-speculative-decoding-vllm-arctic}}
}
