背景：大模型慢，不只是”模型太大”
大模型推理慢，通常有两个瓶颈：prefill 和 decode。
Prefill 负责把输入 prompt 一次性编码进 KV Cache，输入越长，首 token 前的等待越明显。Decode 则是逐 token 生成，每生成一个 token，都要读一次大量权重和 KV Cache。对在线聊天、代码补全、Agent 工具调用这类交互式场景来说，用户感知最强的往往不是总吞吐，而是 TTFT（Time To First Token）和 ITL（Inter-Token Latency）。
Speculative Decoding，也常被称为 Assisted Generation，解决的是 decode 阶段的串行问题。它的核心想法很直接：先让一个更快的”草稿器”猜出后面几个 token，再让目标大模型一次性验证这些 token。如果多个 token 被接受，目标模型就相当于用一次前向计算推进了多步生成。
这不是简单的缓存，也不是量化。它更像是把”一个大模型一步一步写答案”，改成”一个小模型先写草稿，大模型批量审稿”。
核心原理：草稿、验证、接受率
一个典型的推测解码循环可以拆成四步：
- Draft（草稿）：草稿模型或草稿算法生成 K 个候选 token。草稿器可以是小模型，也可以是 n-gram、suffix、Medusa head、EAGLE、MTP 等结构。
- Verify（验证）：目标模型拿到这 K 个候选 token，在一次或较少次数前向计算中并行验证它们。
- Accept / Reject（接受/拒绝）：如果候选 token 与目标模型在当前采样规则下可接受，就直接推进；一旦遇到不接受的 token，就回退到目标模型自己的输出。
- Repeat（重复）：新的上下文继续进入下一轮草稿和验证。
这里最关键的变量不是”草稿一次猜几个”，而是 接受率。如果草稿 token 经常被目标模型接受，目标模型一次前向可以产出多个有效 token，ITL 会下降。反过来，如果草稿经常猜错，系统既付出了草稿成本，又没有减少多少目标模型调用，延迟可能反而上升。
Hugging Face 在 Assisted Generation 的介绍中把这个机制解释为：assistant 模型先逐 token 生成候选序列，target 模型再一次性验证这些候选；收益来自目标模型一次前向确认多个 token，而不是每次只生成一个 token。
关键工程判断：它不是所有流量都快
vLLM 文档对推测解码的定位很克制：它适合降低 中低 QPS、memory-bound 工作负载下的 inter-token latency。这个限定非常重要。
在低 QPS 时，单个请求的 decode 往往无法充分填满 GPU，目标模型每步生成一个 token 的串行成本很明显。推测解码让目标模型一次验证多个候选 token，可能明显改善用户看到的流式输出速度。
在高 QPS 时，情况会变化。连续批处理会把多个请求合并，GPU 利用率提高，单请求的 decode 不再完全像孤立运行。2026 年 5 月提交的论文《An Interpretable Latency Model for Speculative Decoding in LLM Serving》专门分析了这个问题：生产系统中的有效 batch size 会随请求率变化，推测解码的加速常常会随着服务负载上升而衰减。
所以，推测解码不是一个”打开就变快”的开关。它更像一个需要按流量、模型、场景和采样策略调参的延迟治理手段。
常见技术路线对比
1. N-gram / Prompt Lookup
N-gram 推测不需要额外草稿模型。它从输入 prompt 或已生成内容里寻找重复片段，把可能重复的 token 当成草稿。
TensorRT-LLM 文档指出，NGram 直接从输入 prompt 和此前输出中复制 draft tokens，适合输入和输出存在高 n-gram 重叠的场景，比如摘要、文档问答、多轮聊天、代码编辑。
优点：部署简单、额外资源少、风险低。 缺点：对开放式创作、复杂推理、低重复任务，接受率通常不稳定。
2. Draft Model
Draft Model 是最直观的方案：用一个小模型为大模型草拟 token。
它的难点在于，小模型必须足够快，也必须足够像目标模型。Hugging Face 的 Universal Assisted Generation 文章提到，传统 assisted generation 往往要求 target 和 assistant 使用相同 tokenizer；UAG 则试图扩展到不同 tokenizer 的模型组合。同时，文章也给出一个很现实的经验：assistant 通常要比 target 小很多，才更容易得到有意义的延迟收益。
适合：低 QPS、延迟敏感、目标模型很大、且可以找到合适小模型的场景。 不适合：草稿模型本身就很重，或跨 tokenizer 对齐成本过高。
3. EAGLE、MTP、MLP Speculator
vLLM 的文档列出 EAGLE、MTP、draft model、PARD、MLP、N-gram、suffix、dynamic speculative decoding 等多种方法，并给出方法选择建议：模型型方法通常有更高延迟收益，但实现和兼容成本也更高。
这类方案的共同目标是减少草稿阶段的串行成本。例如 Speculators 项目把 speculator 定义为可训练、可部署到 vLLM 的草稿模型体系，让小型草稿器提前预测多个 token，再由基础模型一次验证。
适合：有模型训练能力、有明确推理成本目标、并且愿意做压测和灰度发布的团队。
4. Medusa / Tree-based Speculation
Medusa 的思路是在模型上增加多个预测未来 token 的 head，形成多候选路径。TensorRT-LLM 文档强调，Medusa 的潜力来自多路径验证，但树的宽度和深度需要剪枝，否则额外计算会抵消收益。
SpecInfer 论文进一步把候选 token 组织成 token tree，用目标 LLM 作为 verifier 并行验证树中候选序列，目标是降低端到端延迟和计算成本。
树形推测的收益空间更大，但工程复杂度也更高。它需要处理候选路径、稀疏 attention mask、接受路径选择、显存开销和调度策略。
| 方案 | 额外模型 | 部署复杂度 | 适用场景 | 收益天花板 |
|---|---|---|---|---|
| N-gram / Prompt Lookup | 无 | 低 | 摘要、文档问答、代码编辑 | 中 |
| Draft Model | 需要小模型 | 中 | 低 QPS、大模型服务 | 高 |
| EAGLE / MTP / MLP | 需要训练 | 中高 | 有训练能力的团队 | 高 |
| Medusa / Tree-based | 需要修改模型 | 高 | 深度优化场景 | 最高 |
为什么高负载下收益会消失
很多团队第一次测试推测解码时，会得到一个看起来矛盾的结果：单请求测试很快，小流量也快，一旦压到线上目标 QPS，收益明显下降，甚至比普通 decode 更慢。
原因通常有四个：
第一，草稿成本不是免费的。 草稿模型也要占 GPU、CPU、内存、KV Cache 和调度资源。低负载下这些成本可能被更少的目标模型步数抵消；高负载下，它会进入排队系统，变成真实开销。
第二，连续批处理改变了基线。 不开推测解码时，高 QPS 可能已经通过 batching 提高了目标模型吞吐。推测解码引入的 draft / verify 分阶段流程，可能破坏原本简单稳定的批处理节奏。
第三，接受率随任务变化。 代码补全、文档问答、摘要通常有较高局部可预测性；开放式聊天、长链路推理、强采样、多工具调用，接受率会下降。接受率下降后，推测深度越大，浪费越多。
第四，采样参数会改变收益。 temperature、top_p、top_k 等参数会影响目标模型分布，也会影响草稿 token 被接受的概率。只在 greedy decoding 下验证出来的收益，不能直接迁移到生产采样配置。
一个更稳的落地路径
第一步：先建立普通 decode 基线
不要一开始就比较”开”和”不开”。先把普通 decode 的基线测清楚。
至少记录这些指标：
- TTFT p50 / p95 / p99
- ITL p50 / p95 / p99
- 输出 token 吞吐
- 请求队列等待时间
- GPU SM 利用率与显存占用
- 平均输入长度与输出长度
- 按任务类型拆分的延迟分布
推测解码主要改善的是 decode 阶段，不要把 prefill 很重的长上下文请求误判为推测解码失败。长上下文服务往往还需要 prefix cache、KV cache 管理、P/D 解耦等手段配合。
第二步：从低风险方法开始
如果业务包含 RAG、文档问答、代码编辑、多轮上下文复用，可以先试 n-gram 或 suffix。它们不需要额外训练草稿模型，比较适合做第一轮线上灰度。
vLLM 的 n-gram 配置可以从保守参数开始：
vllm serve Qwen/Qwen3-32B \
--speculative-config '{
"method": "ngram",
"num_speculative_tokens": 4,
"prompt_lookup_min": 2,
"prompt_lookup_max": 5
}'这类配置的目标不是追求极限加速，而是验证三个问题：任务是否有足够重复片段、接受率是否稳定、尾延迟是否变差。
第三步：再评估模型型 speculator
如果 n-gram 收益有限，但业务仍然 decode-heavy，可以评估 draft model、EAGLE、MTP 或 MLP speculator。
一个典型的 draft model 配置形态如下：
vllm serve large-target-model \
--speculative-config '{
"method": "draft_model",
"model": "small-draft-model",
"num_speculative_tokens": 5,
"draft_tensor_parallel_size": 1
}'这里不要只看平均速度。更重要的是观察：草稿模型本身是否成为瓶颈、draft 和 target 是否争抢同一资源、接受率是否随 prompt 类型显著波动。
第四步：做负载分层，而不是全局开关
生产系统不应该只有一个布尔开关。更合理的是按流量和请求类型启用不同策略。
# simplified routing logic
def choose_decode_policy(request, metrics):
if metrics.qps_high or metrics.queue_wait_p95_ms > 200:
return "baseline_decode"
if request.task in ["document_qa", "summarization", "code_edit"]:
return "ngram_speculation"
if request.output_len_estimate > 256 and metrics.acceptance_rate_p50 > 0.65:
return "draft_model_speculation"
return "baseline_decode"这个逻辑的核心是：当系统进入高负载，先保护稳定吞吐和尾延迟；当任务高度可预测，再启用更激进的推测深度。
适用场景
推测解码更适合下面几类任务：
- 代码补全与代码编辑：代码有强结构、强局部模式和大量重复符号，草稿 token 更容易被接受。
- 文档问答和摘要：输出经常复述输入材料中的实体、短语和结构，n-gram / prompt lookup 可能带来低成本收益。
- 低 QPS、高交互要求的聊天服务：当 GPU 没有被充分打满时，decode 串行性更明显，推测解码可能改善用户感知速度。
- 固定模型族内部的大模型服务：如果能找到同族小模型、MTP checkpoint 或训练好的 speculator，工程集成成本会低一些。
不太适合的场景包括：高 QPS 满负载服务、强随机采样、超低接受率任务、草稿模型与目标模型差异过大、以及主要瓶颈在 prefill 而不是 decode 的长上下文请求。
常见误区
误区一：只看 tokens/s。 吞吐提高不等于用户体验改善。在线服务更应该看 TTFT、ITL、尾延迟和失败率。如果 tokens/s 提高，但 p99 ITL 变差，用户感知可能更差。
误区二：草稿越长越好。 num_speculative_tokens 不是越大越好。推测深度变大后，草稿成本、验证成本、KV 管理和拒绝浪费都会增加。合理做法是根据接受率和负载动态调整。
误区三：小模型越小越好。 草稿模型太小会快，但猜不准；太大能猜准，但不够快。好的草稿器应该在”足够快”和”足够像目标模型”之间取得平衡。
误区四：离线 benchmark 可以直接代表线上。 离线固定 batch、固定输入长度、固定输出长度的测试，无法覆盖真实线上流量。线上请求长度、任务类型、采样参数、排队状态都会变化。
误区五：忽略回退机制。 推测解码必须能快速回退到普通 decode。没有回退策略，就很难处理接受率突降、草稿模型异常、显存压力上升或队列等待变长。
上线检查清单
模型与算法
- 确认目标模型、草稿模型、tokenizer、采样参数兼容。
- 确认严格验证路径不会改变输出质量。
- 对 greedy、temperature、top_p 等采样配置分别测试。
- 对不同任务类型分别记录接受率。
性能与容量
- 比较普通 decode、n-gram、draft model、EAGLE / MTP 等方案。
- 分别测试低 QPS、中 QPS、高 QPS。
- 记录 TTFT、ITL、输出吞吐、GPU 利用率、显存、队列等待。
- 单独观察 p95 / p99，而不是只看平均值。
灰度与回退
- 按任务类型灰度，不要全量开启。
- 设置接受率下限，低于阈值自动回退。
- 设置队列等待阈值，高负载时自动回退。
- 保留普通 decode 路由。
- 监控草稿模型错误、OOM、超时和验证失败。
成本核算
- 计算草稿模型额外 GPU 成本。
- 计算目标模型减少的 forward step。
- 计算整体请求成本，而不是只看单请求速度。
- 如果使用远程 drafter，额外计算网络延迟和跨服务调度开销。
总结
推测解码不是一个”打开就变快”的魔法开关。它是一套需要仔细评估流量特征、任务类型、接受率和资源约束的延迟优化手段。低 QPS 下它可能显著改善 ITL，高 QPS 下收益衰减甚至反噬。务实路线是从 n-gram 等低风险方法起步，建立基线，分层路由，始终保留回退路径——让你的生产系统在”快”和”稳”之间找到真正的平衡点。
参考资料
- vLLM Documentation: Speculative Decoding（访问日期 2026-06-29）
- NVIDIA TensorRT-LLM Documentation: Speculative Sampling / NGram / Medusa（访问日期 2026-06-29）
- Hugging Face Blog: Universal Assisted Generation: Faster Decoding with Any Assistant Model（2024-10-29）
- Hugging Face Blog: Faster Assisted Generation with Dynamic Speculation（2024-10-08）
- vLLM Project: Speculators GitHub Repository（访问日期 2026-06-29）
- SpecInfer: Accelerating Generative Large Language Model Serving with Tree-based Speculative Inference and Verification（arXiv:2305.09781，v4 2024-04-01）
- An Interpretable Latency Model for Speculative Decoding in LLM Serving（arXiv:2605.15051，提交日期 2026-05-14）
- SPECTRE: Hybrid Ordinary-Parallel Speculative Serving for Resource-Efficient LLM Inference（arXiv:2605.08151，修订日期 2026-05-12）