推测解码：草稿模型、n-gram、MTP 和 EAGLE

问题：自回归解码速度缓慢

大语言模型每次生成 1 个 token。每个 token 都需要在模型中完成一次完整的前向传播——遍历每一个权重、每一层——然后才能开始生成下一个 token。正如推理工作原理所述，此解码阶段是内存带宽受限的：GPU 从内存中读取数 GB 的权重以生成单个 token，然后为下一个 token 重复同样的操作。计算单元大部分时间处于空闲状态，等待数据到达。您的 GPU 并未执行有用工作——它在等待内存。推测解码利用了这些空闲容量。它不是每次前向传播只生成 1 个 token，而是提前猜测多个 token 并一次性验证它们。

核心思想

推测解码使用 2 个模型协同工作：

草稿模型 —— 一个小型快速模型提前提出 N 个 token（通常为 4-8 个 token）。
目标模型 —— 您实际想要使用的大型模型在一次前向传播中验证所有 N 个提出的 token。

如果目标模型接受了 K 个提出的 token，您只需付出大模型 1 次前向传播的代价即可获得 K+1 个 token（加上小模型 1 次廉价的前向传播）。错误的猜测会被丢弃，生成从最后一个被接受的 token 继续。计算很简单：在 75% 接受率和 5 个草稿 token 的情况下，每次大模型前向传播平均生成约 2-3 个 token，而非 1。这直接转化为 2-3x 的生成速度提升。

推测解码不会改变输出质量。目标模型仍负责每一次接受决策，因此输出分布在数学上与常规自回归解码完全相同。

N-gram 推测解码

工作原理

N-gram 推测解码不使用单独的草稿模型，而是查看当前序列中最后 N 个 token，在上下文中搜索匹配的模式，并提议该模式后跟随的 token。它仅基于现有文本进行纯模式匹配。例如，如果最后 4 个 token 是 def calculate_total(，且较早的上下文中包含 def calculate_total(items): return sum(，引擎会提议 items、:、return、sum 作为接下来的 4 个 token。目标模型随后对这些 token 进行验证。

适用场景

最佳适用： 代码生成、结构化输出、重复性文本、模板、日志解析。最不适用： 创意写作、多样化开放式回复、无重复模式的短上下文。当输出包含重复结构（如函数签名、JSON 模式、样板代码）时，N-gram 推测表现优异。当文本过于多样化而不适合模式匹配时，它会静默失效（接受率低，回退到常规解码）。

实现

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model ngram \
  --num-speculative-tokens 5 \
  --ngram-prompt-lookup-max 5 \
  --gpu-memory-utilization 0.90

./llama-server \
  --model models/llama-3.1-70b-q4_k_m.gguf \
  --draft ngram \
  --n-predict 128 \
  --lookup-cache-static

无需额外下载模型，无需额外显存。唯一的成本是 CPU 在上下文中搜索匹配所花费的时间——与 GPU 前向传播相比可忽略不计。

草稿模型推测解码

工作原理

同一模型系列中的较小模型生成候选 token。例如，Llama-3.1-8B 为 Llama-3.1-70B 生成草稿。小模型运行其自身的自回归生成过程，提出 4-8 个 token，随后大模型在 1 次前向传播中一次性验证它们。接受率——即目标模型同意的草稿 token 比例——对于匹配良好的模型对，通常介于 70% 和 85% 之间。接受率越高，加速效果越明显。

适用场景

最佳适用： 当您有足够的显存余量加载较小模型时，用于通用生成。内存开销： 两个模型必须同时加载。一个 8B 草稿模型在目标模型基础上额外增加约 4-5 GB 空间（采用 Q4 量化）。请据此规划您的模型适配。加速比： 1.5-2.5x，取决于接受率和草稿 token 数量。超过 6-8 个草稿 token 后收益递减，因为序列中后续 token 的接受率会下降。

实现

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model meta-llama/Llama-3.1-8B-Instruct \
  --num-speculative-tokens 5 \
  --gpu-memory-utilization 0.90

./llama-server \
  --model models/llama-3.1-70b-q4_k_m.gguf \
  --draft models/llama-3.1-8b-q4_k_m.gguf \
  --n-predict 128

草稿模型和目标模型应使用同一模型系列。跨系列配对（例如，Mistral 为 Llama 生成草稿）的接受率显著更低，因为它们的 token 分布存在差异。

DFlash：随模型附带的草稿生成器

大多数草稿模型方案要求您自行寻找兼容的小模型并调优配对。DFlash 是 Meta 为 Muse Glimmer 30B 设计的草稿生成器，省去了这一步骤：它与目标模型在同一版本中发布，并提议 16 个 token 的块，由 Muse Glimmer 在 1 次前向传播中进行验证。 Meta 报告的性能提升分别为 3.1x（RTX 5090）、1.8x（Apple M5 Max）和 1.5x（Apple M4 Max）。这些是厂商报告的数据，目前尚无独立复现，因此请在您自己的硬件上进行基准测试后再依赖这些数字。

模型原生推测头：MTP 和 DSpark

工作原理

某些模型架构经过训练，能够从单次前向传播中同时预测多个未来 token。模型本身一次性生成多个候选 token——无需单独的草稿模型，无需模式匹配。推测 token 由模型自身的内部表示生成。这与外部推测存在根本区别：多 token 头与基础模型联合训练，因此它们共享相同的上下文理解。

适用场景

最佳适用： 原生支持该特性的模型。无需配置选择——如果模型使用 MTP 头训练，则启用它们；否则无法添加。当前 DeepSeek 示例： DeepSeek-V4-Flash-0731 在其官方检查点中捆绑了 DSpark 模块。部分 Qwen 模型使用 MTP 头。优势： 无需单独的草稿模型检查点或模型对调优。劣势： 需要特定的模型训练。无法将 MTP 应用于任意检查点。

实现

vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
  --trust-remote-code \
  --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

官方 0731 示例使用存储在同一检查点中的 DSpark 头。请勿为该模型添加 --speculative-draft-model-path。

官方 0731 模型卡片记录了 DSpark 在 vLLM 和 SGLang 上的支持情况。硬件支持因情况而异，请使用匹配的运行时方案并对您的确切检查点进行基准测试。参见 DeepSeek V4 Flash 0731 本地硬件。

EAGLE（用于提升语言模型效率的外推算法）

工作原理

EAGLE 在目标模型的隐藏状态之上训练一个小型”头”网络。它不加载完整的草稿模型，而是将一个轻量级神经网络附加到目标模型的中间表示上，并利用这些表示来预测未来 token。由于头网络读取目标模型自身的内部状态，它比朴素的草稿模型实现了更高的接受率（80-90%）。与完整模型相比，头网络非常小——通常仅为目标模型大小的 5-10%。

适用场景

最佳适用： 在可用时，EAGLE 提供所有技术中最佳的加速与内存比。当前状态： 处于研究阶段，运行时支持有限。vLLM 和 SGLang 具有实验性的 EAGLE 集成，但需要预训练的 EAGLE 头检查点，而大多数模型家族尚未广泛发布这些检查点。当 EAGLE 支持成熟时，预计： 2-3x 的速度提升，且仅带来 5-10% 的内存开销——显著优于完整的草稿模型。

实现

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model yuhuili/EAGLE-LLaMA3.1-Instruct-70B \
  --num-speculative-tokens 5 \
  --speculative-draft-tensor-parallel-size 1

EAGLE 头检查点是特定于模型和架构的。在尝试使用此技术之前，请验证是否已为您的确切目标模型发布了 EAGLE 检查点。

比较

N-gram

额外内存： 无 加速比： 1.2-1.5x 需要训练： 否 运行时支持： vLLM、llama.cpp 最佳适用： 重复性内容、代码、结构化输出

草稿模型

额外内存： 20-30% 额外 加速比： 1.5-2.5x 需要训练： 否（使用同系列中更小的模型） 运行时支持： vLLM、llama.cpp 最佳适用： 具有显存余量的通用生成

多 token 预测

额外内存： 无 加速比： 1.5-2x 需要训练： 是（特定于模型） 运行时支持： vLLM（仅限部分模型） 最佳适用： 模型原生头，如 DeepSeek V4 Flash 0731 DSpark 和受支持的 Qwen MTP 变体

EAGLE

额外内存： 5-10% 加速比： 2-3x 需要训练： 是（头网络） 运行时支持： 实验性 最佳适用： 在可用时提供最佳的加速与内存比

技术	额外内存	典型加速比	需要训练	运行时支持	最佳适用
N-gram	无	1.2-1.5x	否	vLLM、llama.cpp	重复性内容
草稿模型	20-30%	1.5-2.5x	否	vLLM、llama.cpp	通用用途
DFlash	~2 GB	1.5-3.1x（厂商报告）	否（随模型提供）	Ollama（`-dflash` 标签）	仅限 Muse Glimmer
MTP	无	1.5-2x	是（特定于模型）	vLLM（部分模型）	仅支持的模型
EAGLE	5-10%	2-3x	是（头网络）	实验性	当可用时

何时使用推测解码

使用场景：

您的工作负载是解码受限的——长时间生成，大部分时间花在生成 token 上，而非处理提示词
您有显存余量用于草稿模型（目标模型之外至少 5-10 GB 空闲空间）
您生成结构化或重复性输出——代码、模板、JSON、日志
您服务于单个用户或低并发工作负载

避免使用场景：

您的工作负载是预填充受限的——短输出配长输入（摘要、分类）。推测解码仅加速解码阶段。
您已达到显存上限。草稿模型或额外的 KV 缓存条目可能导致内存溢出。请参阅 DGX Spark 内存调优进行容量规划。
您使用连续批处理且并发度高。推测解码与大多数运行时中的高效批调度冲突——验证阶段假设每个请求的草稿长度固定，这会增加批处理组合的复杂性。

实用设置指南

vLLM 中的 N-gram 推测

最简单的起点——无需额外下载，无需额外内存：

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model ngram \
  --num-speculative-tokens 5 \
  --ngram-prompt-lookup-max 5 \
  --gpu-memory-utilization 0.90

其中 --ngram-prompt-lookup-max 标志设置模式匹配的窗口大小。较大的值在长上下文中能找到更多匹配，但会略微减慢草稿步骤。从 5 开始，如果接受率低则增大。

vLLM 中的草稿模型

当显存充足时，可获得更高的加速比：

vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --speculative-model meta-llama/Llama-3.1-8B-Instruct \
  --num-speculative-tokens 5 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192

如果遇到 OOM，请减小 --max-model-len。两个模型共享同一显存池，且草稿模型的 KV 缓存会增加总显存占用。

获取并调优此类草稿模型对是常规路径。Meta 的 Muse Glimmer 30B 跳过了这一步：拉取以 -dflash 结尾的 Ollama 标签（例如 muse-glimmer:30b-q4_K_M-dflash），DFlash 草稿器会自动加载，无需设置 --speculative-model 标志。

llama.cpp 中的 N-gram 推测

./llama-server \
  --model models/llama-3.1-70b-q4_k_m.gguf \
  --draft ngram \
  --n-predict 128 \
  --lookup-cache-static \
  --port 8080

其中 --lookup-cache-static 标志跨 token 缓存 n-gram 查找，提高重复模式的草稿速度。

如何测量加速比

运行相同的提示词两次——一次使用推测解码，一次不使用——并比较每秒 token 数：

# Baseline (no speculation)
vllm serve meta-llama/Llama-3.1-70B-Instruct \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 &

# Send a test request and note tok/s in the response headers
curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Llama-3.1-70B-Instruct",
    "messages": [{"role": "user", "content": "Write a Python class that implements a binary search tree with insert, delete, and search methods."}],
    "max_tokens": 512
  }'

停止基线服务器，启动推测服务器，发送相同的请求，然后进行比较。查找 x-tokens-per-second 标头，或从 usage.completion_tokens 除以实际耗时进行计算。对于系统性基准测试，请使用 vLLM 内置的基准测试工具：

python -m vllm.benchmarks.benchmark_serving \
  --model meta-llama/Llama-3.1-70B-Instruct \
  --num-prompts 10 \
  --request-rate 1

经过良好调优的推测设置可在不改变输出质量或 token 数量的情况下，将平均解码延迟提升 1.5-2.5x。

深入了解

解码与预填充功耗

针对您的硬件调优预填充和解码阶段，以实现最大吞吐量。

推理工作原理

了解预填充、解码以及为何内存带宽是瓶颈。

DGX Spark 上的 vLLM

配置 vLLM 并使用最佳设置，包括推测解码支持。

模型适配

计算您的目标模型加上草稿模型是否能装入显存。

测试您的部署

本地大语言模型部署的系统化基准测试方法。

硬件与适配

服务与连接运行时

连接客户端或应用

对比

推测解码：草稿模型、n-gram、MTP 和 EAGLE

问题：自回归解码速度缓慢

核心思想

N-gram 推测解码

草稿模型推测解码

DFlash：随模型附带的草稿生成器

模型原生推测头：MTP 和 DSpark

EAGLE（用于提升语言模型效率的外推算法）

比较

N-gram

草稿模型

多 token 预测

EAGLE

何时使用推测解码

实用设置指南

vLLM 中的 N-gram 推测

vLLM 中的草稿模型

llama.cpp 中的 N-gram 推测

如何测量加速比

深入了解

解码与预填充功耗

推理工作原理

DGX Spark 上的 vLLM

模型适配

测试您的部署

​问题：自回归解码速度缓慢

​核心思想

​N-gram 推测解码

​草稿模型推测解码

​DFlash：随模型附带的草稿生成器

​模型原生推测头：MTP 和 DSpark

​EAGLE（用于提升语言模型效率的外推算法）

​比较

N-gram

草稿模型

多 token 预测

EAGLE

​何时使用推测解码

​实用设置指南

​vLLM 中的 N-gram 推测

​vLLM 中的草稿模型

​llama.cpp 中的 N-gram 推测

​如何测量加速比

​深入了解

解码与预填充功耗

推理工作原理

DGX Spark 上的 vLLM

模型适配

测试您的部署

问题：自回归解码速度缓慢

核心思想

N-gram 推测解码

草稿模型推测解码

DFlash：随模型附带的草稿生成器

模型原生推测头：MTP 和 DSpark

EAGLE（用于提升语言模型效率的外推算法）

比较

何时使用推测解码

实用设置指南

vLLM 中的 N-gram 推测

vLLM 中的草稿模型

llama.cpp 中的 N-gram 推测

如何测量加速比

深入了解