用于 LLM 推理的推测解码：吞吐量提升与权衡
推测解码 LLM 服务可以减少等待下一个 token 的时间——而无需让目标模型变成另一个模型。与其让大型目标模型在每个解码步骤中只生成一个 token，不如由一个成本更低的提议模型起草一段简短的续写。目标模型会并行验证该续写，提交被接受的前缀，并从第一个不一致处继续生成。
这听起来像是一种通用加速器。事实并非如此。结果取决于草稿质量、请求组合、批处理、采样设置、GPU 内存余量，以及你的工作负载是否确实受解码限制。本指南将解释其底层工作原理、EAGLE 和 Medusa 如何改变设计，以及如何判断推测解码是否应纳入你的服务栈。
实用原则：将推测解码视为一种经过测量的服务优化，而非论文中宣传的加速设置。只有当它能在不降低并发能力或可靠性的前提下，改善实际流量所关注的延迟或输出 token 吞吐量目标时，才应保留它。
什么是用于 LLM 推理的推测解码？
自回归生成是顺序进行的：token t + 1 依赖于之前的 token。因此，普通解码器必须等待大型目标模型为每个生成的 token 运行一次。推测解码改变的是调度方式，而不是目标分布：一个更小型或专用的草稿机制预测多个候选 token；目标模型对这些候选位置进行联合评分或验证；系统接受匹配的前缀，并在第一个被拒绝的位置回退。
最初的推测解码论文将其描述为一种在并行评估多个候选位置的同时，从目标模型获得精确样本的方法。论文报告的 2–3× 结果是其 T5 设置下的基准测试结果，并非对每个模型或服务的承诺。阅读原始论文。
推测解码 LLM 推理示意图
请求 + 当前上下文
|
v
草稿机制提出： [A] [B] [C] [D]
|
v
目标模型在一次传递中验证所有提议位置
|
+-- 接受 [A] [B] [C] -> 提交该前缀（以及可能额外的一个目标 token）
|
+-- 在 [C] 处拒绝 -> 提交 [A] [B]，在 [C] 处采样/修正，然后重复
节省的工作并不是草稿计算本身。潜在收益来自于用一次目标模型验证传递替代多次串行的目标模型解码迭代。如果提议经常出错，目标模型仍需频繁恢复，收益就会缩小。
关键指标：每次目标验证所接受的 token 数
最有用的健康信号是通过验证的提议 token 数量。团队通常将其称为接受率或接受长度。请同时跟踪以下两项：
| 指标 | 它告诉你的信息 | 为何单独看可能产生误导 |
|---|---|---|
| 接受率 | 目标模型接受的提议 token 占比 | 不包含草稿成本或目标验证成本。 |
| 平均接受长度 | 每轮获得多少个已提交的草稿 token | 平均值可能掩盖长尾请求和不同采样模式。 |
| Token 间延迟（ITL） | 流式 token 之间的时间 | 这通常是用户可见的解码指标。 |
| 总体输出 token/秒 | 跨并发请求的有用服务容量 | 它可能会提升，而低 QPS 的交互式用户几乎感受不到收益，反之亦然。 |
| GPU 内存和活跃请求数 | 提议器是否挤占 KV 缓存或并发容量 | 单个请求更快，可能是更差的全机群配置。 |
要进行公平的 A/B 测试，应保持模型修订版本、tokenizer、量化、最大输出长度、提示词组合、采样参数、硬件和并发策略不变。比较端到端延迟、首 token 时间、p50/p95 ITL、输出 token/秒和错误率。一个没有负载形态说明的“token/秒”数字，不足以用于选择配置。
推测解码的适用场景与不适用场景
当解码受内存限制，且每个请求具有足够长的生成长度，使重复验证轮次能够产生影响时，推测解码 LLM 服务通常最具吸引力。当前的 vLLM 指南特别将其定位为一种降低中低 QPS、内存受限工作负载 token 间延迟的方法，并指出实际收益取决于模型家族、流量、硬件和采样设置。查看 vLLM 推测解码指南。
在以下情况下，它的吸引力较低：
- 预填充主导请求。长提示词配合短回答时，大多数时间花在摄取上下文上。草稿生成改变的是解码工作，而不是已经主导端到端延迟的提示词预填充工作。
- 接受效果不佳。创造性解码、不匹配的草稿模型，或产生较弱候选续写的配置，都可能导致反复验证失败。
- 服务器已经达到批处理饱和。在高并发下，目标 GPU 可能已被常规调度器高效占用。添加草稿器可能消耗原本可用于服务更多请求的内存或计算资源。
- KV 缓存余量紧张。额外的草稿模型或提议器状态可能会减少发生驱逐或排队前可存活的序列数。在将单请求加速解读为机群收益前，请查阅LLM GPU 内存要求。
- 目标模型与所选提议器不兼容。基于模型的方法需要兼容的制品、tokenization 和服务支持；绝不能因为小模型更便宜，就假设它是有效的草稿模型。
因此，正确的问题不是“推测解码能让这个模型更快吗？”而是“在我们的流量分布下，它改善了哪一项服务级约束？”
草稿模型、EAGLE 和 Medusa：三种 token 提议方式
独立草稿模型
经典设计将快速草稿模型与更大的目标模型配对。草稿模型提出 k 个 token；目标模型对其进行验证。这在概念上可能很简单，但会增加另一个模型制品、内存占用、兼容性工作，以及需要进行版本管理和监控的运维层面。
当你拥有经证明兼容、低延迟的提议器，并且有足够的 GPU 容量来保持目标服务的并发性时，可使用此方法。应从一小组推测长度开始，而不要假定更深的提议总是更好。
EAGLE 推测解码 LLM
EAGLE 是一种基于模型的方法，它在特征层面进行草稿生成，而不只是采用传统的小型 token 模型提议路径。该论文描述了使用向前一步的 token 序列作为条件进行特征预测，以解决特征级不确定性问题。在论文测试的设置中，它报告了在保持生成文本分布的同时改善延迟和吞吐量；这为该方法的潜力提供了有用证据，而不是对其他模型或 GPU 机群的容量预测。阅读 EAGLE 论文。
对于运营人员而言，其含义很直接：当目标模型家族有可用的受支持制品时，EAGLE 可能很有吸引力，但它不是适用于每个 checkpoint 的通用开关。在将其推广前，请验证确切的目标模型/提议器配对及服务引擎版本。
Medusa 推测解码 LLM
Medusa 在骨干模型上配置多个解码头，并使用基于树的注意力来创建和验证多个候选续写。这避免了维护一个完全独立的草稿模型，但这些头必须针对骨干模型进行训练或微调。Medusa 论文区分了冻结骨干模型的路径和联合微调，并报告了这些实验设置下的基准加速结果。阅读 Medusa 论文。
其运维权衡不同于草稿模型配对：可能减少独立模型管理，但需要模型特定的制品以及训练或集成工作。应将其视为模型服务选择，而不是运行时技巧。
GPU 推理的实用上线计划
1. 建立具有代表性的基线
至少采集一个接近生产环境的请求切片：提示词长度分段、输出长度分段、语言或任务类型、temperature/top-p 设置、流式行为和并发级别。分别记录首 token 时间和解码的基线。如果工作负载以提示词为主，不要让输出 token 基准掩盖预填充问题。
2. 选择一种提议器策略和保守的深度
从一种受支持的方法开始——草稿模型、EAGLE、Medusa 或其他引擎支持的提议器——并采用较小的候选长度。例如，vLLM 文档说明了 --speculative-config 设置，其中包括方法、提议器模型和 num_speculative_tokens；在将任何配置复制到生产环境前，请查阅与版本匹配的文档。有关更广泛的运维设置，请参阅vLLM 部署指南。首次测试时，不要同时调优推测深度和批处理。
3. 运行负载矩阵，而非单个基准测试
在低、中等和接近峰值的并发度下测试相同的流量切片。对于每个点，比较：
- 基线与推测模式的端到端延迟。
- 流式请求的 p50 和 p95 token 间延迟。
- 总体输出 token/秒和完成请求数/秒。
- 接受长度、拒绝频率和提议器延迟。
- GPU 内存、KV 缓存压力、排队延迟以及错误/超时率。
如有可能，请按提示词分段和输出分段拆分结果。对长代码补全有帮助的配置，未必能改善简短聊天回答；而良好的离线结果在计入排队后可能会变差。
4. 在金丝雀发布前设置护栏
在流量接触变更前定义回滚阈值：例如 p95 ITL 回归、峰值负载下完成请求数/秒下降、内存不足事件增加，或接受率持续崩塌。起初仅路由符合条件的一部分流量，并保留基线路径以便快速比较。
5. 上线后持续测量
接受情况会随着模型更新、提示词分布、工具使用格式和默认采样设置而变化。每当目标模型、tokenizer、量化、GPU、服务引擎或流量特征发生任何实质变化后，都应重新运行比较。
最小化 vLLM 起步配置
对于支持该功能的服务引擎，配置应明确说明提议器方法，而不是将其隐藏在不透明的默认设置中。当前 vLLM 文档针对独立草稿模型使用如下结构：
vllm serve <target-model> \
--speculative-config '{
"method": "draft_model",
"model": "<compatible-draft-model>",
"num_speculative_tokens": 5
}'
这些占位符是有意保留的。兼容模型、推测 token 数量、并行度设置和内存预算，必须根据你已测试的制品和引擎版本来选择。不要将此代码片段视为某个特定目标模型/草稿模型组合受支持的证据。
吞吐量收益与权衡一览
| 决策 | 可能的收益 | 主要成本或失败模式 | 首先应测量什么 |
|---|---|---|---|
| 启用独立草稿模型 | 当接受率高时，减少串行目标解码步骤 | 额外的模型内存、兼容性和草稿延迟 | 接受长度、KV 缓存余量、p95 ITL |
| 增加推测长度 | 每次验证有更多潜在 token | 后续 token 被拒绝时会产生更多浪费的草稿工作 | 净 ITL 和总体输出 TPS，而不仅是接受率 |
| 使用 EAGLE | 在支持相关制品时具有强大的基于模型的提议路径 | 模型家族和引擎兼容性要求 | 目标模型/提议器兼容性和负载形态基准结果 |
| 使用 Medusa | 无需独立完整草稿模型的多头提议 | 模型特定的头以及集成/训练工作 | 输出质量检查、服务支持和回滚路径 |
| 在峰值 QPS 时启用 | 在合适的引擎/工作负载中可能带来吞吐量收益 | 调度器、内存或计算资源争用可能抹去收益 | 完成请求数/秒、排队时间和错误率 |
常见问题
推测解码会改变目标模型的回答吗？
正确的推测采样使用目标模型验证和修正，因此采样可以保持目标分布。该保证取决于使用正确的算法和兼容的实现。服务变更仍可能影响运维行为——例如延迟、排队或错误——因此除了速度外，还应评估质量和可靠性。
推测解码能改善首 token 时间吗？
通常，它针对的是生成开始后的解码阶段。如果提示词处理主导了你的请求，首 token 时间可能几乎没有变化。请分别测量预填充和解码。
应该使用多少个推测 token？
不存在通用的最佳值。请针对你的模型、提议器、采样设置、GPU 类型和并发度测试较小范围。更长的提议仅在有足够多 token 被接受，且额外工作不会降低服务容量时才能获胜。
应该使用 EAGLE 还是 Medusa？
选择你的目标模型和服务引擎能够良好支持的方法，然后在你的工作负载上进行基准测试。EAGLE 依赖受支持的特征级草稿制品；Medusa 依赖与骨干模型关联的多个头。两者都不能自动与通用草稿模型互换。
将决策置于整体背景中
推测解码是 LLM 服务优化的一个层面。它与清晰的模型服务选择、现实的容量限制和明确的监控配合使用时效果最佳。有关更广泛的服务引擎比较，请参阅 vLLM vs SGLang：吞吐量、延迟、模型支持和运维。有关生产 API 的容量方面，请参阅 RPM vs TPM：LLM 速率限制与 429 修复。
如果你正在规划 GPU 实验或新的推理环境，探索 Flatkey Compute，并从一份同时报告用户可见延迟和机群级吞吐量的基准计划开始。最佳的推测解码 LLM 配置，是在真实负载下改善受约束指标，并能在工作负载变化时安全回滚的配置。本推测解码 LLM 指南是建立这种测量纪律的起点，而不是其替代品。
