投机解码实战：原理、性能边界与大模型推理加速配置

对应用开发者来说，关键是自己的工作负载下，回答能否更快地流式输出。对推理服务运维人员来说，还要看并发请求增多、显存吃紧时，这种收益能否保住。对托管 API 的使用方来说，则要先确认服务商是否开放了这项优化，或在文档中说明了它的使用情况。

**文档核验日期：2026 年 10 月 30 日。**涉及 vLLM、SGLang 和 NVIDIA TensorRT-LLM。下文命令依据其在线文档编写，属于配置示例，并非本文实测的基准结果。

什么是投机解码？

**先由开销较小的候选生成器预测后续 token，再由目标模型决定哪些能进入最终回答。**token 是模型处理文本的基本单位，往往只是一个单词的一部分。目标模型，就是我们希望保留其生成行为的那个模型。

可以把它想成助手替一位严谨的编辑起草句子。助手可以提前写，但内容必须经过编辑审核，才能交给读者。加速的关键在于：目标模型可以同时评估这段候选续写，不必每生成一个新 token 都单独走一遍生成流程。NVIDIA 将这一过程描述为先生成草稿，再由目标模型执行一轮验证。TensorRT-LLM 文档

图中的字母代表 token ID。草稿模型提出 A B C。贪心解码每次选择概率最高的下一个 token；假设目标模型认可 A B，但认为后面应该是 X，那么最终确定的输出就是 A B X。草稿中接在被拒绝的 C 后面的内容也会被丢弃，因为它依赖的是错误的前缀。

如果采用采样生成，接受规则就不只是检查两个模型是否选中了同一个词。标准投机采样会用到目标模型与候选生成器的概率；候选被拒绝时，还会使用修正分布。正是这一步修正，保证了目标模型的概率分布得以保留。原始算法还允许在整段草稿全部被接受时，由目标模型额外生成一个 token。Leviathan、Kalman 和 Matias 的原始论文

因此，小模型只负责提出候选，不是接管回答的后备模型。使用精确验证器时，草稿质量差应当只会拖累速度，而不会悄悄让小模型替目标模型作答。

“不用更弱的模型回答”究竟意味着什么？

**应当要求的保证，是保留目标模型的概率分布。**这并不意味着每次随机生成的回答都相同，也不会消除目标模型的错误，或提升它的推理能力。vLLM 文档指出，即使算法本身无损，数值计算和批处理的影响仍可能造成输出差异。vLLM 无损保证

评估投机解码时，应固定目标模型权重、量化方式和采样设置。否则多个变量同时变化，就无法判断质量差异究竟来自哪一项改动。

投机解码有哪些方案？各引擎的文档在哪里？

**选择方案时，要以具体目标模型和推理服务版本的支持情况为准。**这些方案都遵循“先起草、再验证”的机制，区别在于草稿从哪里来。

独立草稿模型

由一个较小的语言模型使用自身权重生成候选 token。这是最直观的方案，但需要额外加载并运行一个模型。兼容性和预测一致性都很重要：模型更小，不代表它就适合当草稿模型。vLLM 通常要求两者共用词表，同时也记录了一种适用范围受限的跨词表方案。vLLM 草稿模型文档

如果服务的显存占用已经接近上限，再加一个模型可能并不是合适的第一步。如果服务对延迟敏感、资源尚有余量，又有匹配良好的草稿模型，就可以开展一次受控实验。

EAGLE 投机解码

EAGLE 是 Extrapolation Algorithm for Greater Language-model Efficiency 的缩写。它使用与目标模型配套、经过训练的辅助草稿模型，借助目标模型的内部表示预测后续内容。这类经过学习的组件常被称为预测头，需要使用兼容的检查点。vLLM 将 eagle 和 eagle3 区分为不同配置。vLLM EAGLE 文档

目标模型与 EAGLE 检查点必须配套使用。不能只因为检查点名称里出现了同一个模型家族，就认为它兼容。部署记录应写明对应的模型家族、模型修订版本和推理服务实现。

MTP 投机解码

多 token 预测，即 MTP，利用模型原生具备的能力来预测未来 token。vLLM 为受支持的模型家族提供了这条路径，文档中的启动示例不需要指定独立草稿模型。模型本身不具备这项能力时，把 method 设为 mtp 也不会让它凭空获得能力。vLLM MTP 文档

如果当前服务已在使用受支持的 MTP 检查点，可以先按文档尝试原生路径，再考虑添加其他独立草稿模型。这样能减少需要处理的兼容性选择，但性能收益仍须实测。

下表直接链接到各引擎的官方文档，方便查找配置入口。表中列有某种方案，不代表所有模型都能在该引擎下使用它。

算法名称和执行架构是两回事。TensorRT-LLM 当前版本的发行说明移除了独立草稿引擎的执行路径，保留了将草稿模块作为子模块放入模型内部的实现。这不代表草稿模型与目标模型配合的方案消失了，而是说，旧部署指南描述的执行路径可能已不再存在于所安装的版本中。TensorRT-LLM 发行说明

什么情况下能加速，什么情况下反而拖慢？

**把所有额外开销都算进去后，有效输出仍然更快，投机解码才有价值。**接受率很重要，但它只是这笔账的一部分。

接受的 token 必须抵得过草稿开销

接受率等于被接受的草稿 token 数除以提出的草稿 token 数。单看这个比例，无法知道生成候选付出了多少成本。更慢的草稿模型即使与目标模型更一致，也仍可能让整个服务变慢。

可以用下面的关系判断是否值得启用：

（草稿生成时间 + 验证时间 + 协调时间）÷ 最终确定的输出 token 数 < 基线每个 token 的解码时间

这是一种核算方法，不是性能预测。应在自己的硬件上测量完整一轮的耗时。“最终确定的输出 token 数”不仅包括被接受的草稿 token，还包括目标模型提供的修正 token 或额外 token。

代码编辑助手的输入输出常有重复的局部结构，可能有利于草稿预测。客服助手的草稿模型也许很擅长预测礼貌用语和衔接语，却难以准确预测产品相关的回答。两类工作负载应分别测量，不能仅凭平均接受率决定是否上线。

草稿越长，被拒绝后可能浪费的工作也越多。只有额外确定的输出足以补偿草稿生成、验证和显存开销时，才应继续增加草稿深度。Fireworks 的调优指南也强调了这一点：接受率本身不足以证明能加速。Fireworks 基准测试指南

批大小会改变加速空间

**先从受解码速度限制的交互式工作负载入手，再测试峰值并发。**vLLM 明确将投机解码定位于请求速率中低、受内存带宽限制的工作负载。在这种计算步骤中，限制进度的主要因素是模型数据的搬运，而非可用算力。vLLM 工作负载指南

并行验证可以利用原本闲置的算力，但繁忙的服务器可能已经把这部分算力用于其他请求。因此，单个聊天请求的延迟下降，并不能证明繁忙接口的总吞吐量也会上升。

连续批处理会动态改变每个生成步骤中一起处理的请求。评估投机解码时，应使用实际调度器，并模拟真实的请求到达模式。空闲的开发环境接口和有请求排队的生产接口，是两种不同的实验条件。

不要设定一个通用的批大小分界线。有效边界取决于模型、硬件、草稿方案和调度器。应同时观察延迟与容量：回答流式输出有多快，以及服务在满足延迟目标的前提下能持续承载多少流量。

显存压力可能抵消收益

**草稿模型也要占用有限的 GPU 显存预算。**独立权重、草稿状态和验证工作区，会挤占原本可用于承载请求的空间。用于保存已有 token 注意力状态的 KV 缓存，也是这份预算的一部分。

例如，某个文档助手处理短提示词很快，但处理长文档时已接近容量上限。短提示词上的投机解码试验成功，并不能说明生产环境的缓存与草稿模型仍能同时放得下。应在真实并发下，测试计划支持的最长上下文。

SGLang 的显存不足排查指南明确列出了减少显存预留、图捕获规模、草稿树大小和并发请求数等方法。如果必须降低并发才能容纳投机解码，这就是需要量化的取舍，并非没有代价的优化。SGLang 显存故障排查

要加速的是用户真正等待的环节

回答慢，可能是开始输出前等得太久，也可能是开始后流式输出慢，还可能是模型之外的环节造成了延迟。投机解码针对的是生成阶段。如果应用的大部分时间花在检索文档或等待工具调用上，解码循环更快，对用户体验的改善也可能很小。

测量时，应把排队、预填充和解码分开。预填充处理提示词，解码生成后续内容。大模型推理指南解释了这些阶段，每秒 token 数指南则区分了输出速度和请求总吞吐量。

如何启用投机解码？

**在推理服务进程中启用投机解码，再与同一目标模型未启用时的表现对比。**以下示例假设已安装相应引擎、硬件能容纳所选模型，并且有权访问其权重。文档必须与部署版本对应；在线 latest 页面不保证与旧容器兼容。

vLLM 投机解码配置

vLLM 通过 --speculative-config 接收 JSON 配置。下面是独立草稿模型示例，目标模型、草稿模型和草稿长度均来自其在线服务文档：

vllm serve Qwen/Qwen3-4B-Thinking-2507 \
  --speculative-config '{"method":"draft_model","model":"Qwen/Qwen3-0.6B","num_speculative_tokens":5}'

其中的 5 只是示例使用的候选 token 数，并非推荐的最优值。文档已将旧的独立参数 --speculative-model 和 --num-speculative-tokens 标记为弃用。vLLM 启动示例

原生 MTP 的文档示例使用 Xiaomi MiMo 基础模型检查点：

vllm serve XiaomiMiMo/MiMo-7B-Base \
  --tensor-parallel-size 1 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}'

这是另一个模型的示例，不能直接拿来给上面的 Qwen 目标模型充当草稿模型。关键限制是检查点是否受支持：模型必须本身具备 MTP 能力，引擎也必须支持它。vLLM MTP 启动示例

SGLang 投机解码配置

SGLang 当前的重叠调度器示例，提供了一组采用独立草稿模型方案的 Qwen 目标模型与草稿模型：

python3 -m sglang.launch_server \
  --model Qwen/Qwen2.5-7B-Instruct \
  --speculative-algorithm STANDALONE \
  --speculative-draft-model-path Qwen/Qwen2.5-1.5B-Instruct \
  --speculative-num-steps 4 \
  --speculative-eagle-topk 1 \
  --speculative-num-draft-tokens 5 \
  --mem-fraction-static 0.7 \
  --cuda-graph-max-bs-decode 8

当前重叠调度路径要求设置 --speculative-eagle-topk 1。从其他示例照搬更宽的草稿树，会与这条路径不兼容。调度器和草稿设置应按文档配套使用。SGLang 重叠调度器示例

针对不断变化的工作负载，SGLang 还为受支持的 EAGLE 配置单独提供了自适应投机解码文档。在期待系统自动调整草稿深度之前，应先核对该功能的使用条件。SGLang 自适应投机解码

TensorRT-LLM 配置

TensorRT-LLM 通过 YAML 配置接收投机解码设置。将以下内容保存为 speculative.yaml：

speculative_config:
  decoding_type: Eagle3
  max_draft_len: 4
  speculative_model: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B

这里的草稿长度和检查点来自 NVIDIA 的投机解码配置示例。按服务命令行文档启动与之匹配的目标模型：

trtllm-serve meta-llama/Llama-3.1-8B-Instruct \
  --config speculative.yaml

除了配置名称，还要核对检查点的代际。NVIDIA 文档将 Eagle 列为 Eagle3 的兼容别名，但旧代 EAGLE 检查点仍不兼容这条路径。TensorRT-LLM 检查点限制

如果还在同时选择推理引擎和投机解码方案，可以参考更完整的 vLLM 与 SGLang 对比。即使草稿模型很合适，也无法弥补引擎缺少应用所需其他功能的问题。

使用托管 API 的团队也能受益吗？

**可以，前提是服务商明确说明并启用了这项能力；能控制哪些设置，则取决于具体服务。**即使没有自己的 GPU，也能受益于服务商的推理优化。

托管推理服务商 Fireworks AI 的文档说明，在专用部署中，多数受支持模型配有默认草稿模型。没有默认草稿模型的模型，除非另行配置，否则不会启用基于模型的投机解码。无服务器服务的配置由 Fireworks 管理，因此，专用部署提供了这些参数，并不代表每个无服务器接口都在使用投机解码。Fireworks 部署文档

如果调用方只需对文件做少量修改并重新生成，Fireworks 还提供了 Predicted Outputs：通过请求中的 prediction 字段传入预期文本。已知文本构成了另一种候选来源，也可以与基于模型的投机解码配合使用。这适合预先知道大部分输出内容的任务，而不是开放式提问。Fireworks Predicted Outputs

使用其他托管接口时，在宣称有此收益或添加相关设置之前，应先找到该服务自己的文档。仅凭 API 兼容性，无法判断接口背后是否运行了草稿模型，更无法知道具体是哪一个。

哪些说法夸大了效果？

**投机解码的收益有条件，不能套用一个通用加速倍数。**本文不承诺具体加速数字，因为其他目标模型、草稿模型、GPU 和流量组合测出的结果，无法代表自己的服务。

“接受的 token 越多，应用就越快”，忽略了草稿成本、排队，以及应用在生成之外所做的工作。“草稿越长越好”，忽略了拒绝后被丢弃的计算。“无损就意味着字符串完全一致”，则混淆了采样分布与某一次随机输出。

代价最大的误判，是把空闲接口上的测试结果当成生产容量结论。开发者可能觉得代码助手变快了，共享接口能承载的并发会话却变少了。应先明确优化目标是响应延迟、持续吞吐量，还是两者兼顾，并将它写进上线标准。

下周可以怎样开始验证？

开发者应在解码成为瓶颈时试用兼容的候选生成方案；运维人员应要求它在生产负载下仍有收益；托管 API 团队则应从服务商文档明确提供的控制项入手。

如果大部分等待发生在生成之前，就先解决那个瓶颈。如果显存放不下草稿模型，或者没有兼容检查点，就让目标模型按原方式运行。某项功能可用，并不能证明当前部署就需要它。

开发者常见问题

订阅邮件通讯，获取构建与运维 AI 系统的实用指南。