Speculative Decoding 生产实战：用草稿模型降低 LLM 生成延迟

背景问题

大模型生成慢，根源不是”模型不会一次写完答案”，而是自回归解码的串行依赖：每生成一个 token，都要基于前文再做一次目标模型前向计算。对于聊天、代码补全、Agent 工具调用、长答案生成等场景，输出长度一长，端到端延迟就会被逐 token 解码放大。

常见推理优化手段包括量化、KV Cache、Prefix Caching、Continuous Batching、PagedAttention、Tensor Parallelism 等。它们分别解决显存、重复前缀、吞吐和硬件并行问题，但仍然没有直接打破”每轮只确认一个 token”的节奏。Speculative Decoding 的目标是：让一个更快的草稿路径先猜出多个候选 token，再让目标模型一次性验证这些候选 token，从而减少目标模型串行前向次数。

它适合的问题不是所有推理都要加速，而是更具体的低延迟问题：单请求或小 batch 场景中，目标模型每步解码没有充分吃满 GPU，并且输出存在可预测片段。例如代码补全、摘要、文档问答、格式化回答、客服回复、模板化业务文案等。

核心原理：从”一步一个 token”到”一次验证多个 token”

经典流程可以拆成三步：

1. Draft：用小模型、NGram、额外解码头或其他轻量方法生成 K 个候选 token。
2. Verify：把这些候选 token 交给目标模型，在一次批量前向中验证。
3. Commit：接受前缀中被目标模型认可的 token；遇到第一个不匹配位置时，丢弃后续候选，并由目标模型修正。

可以把它理解成 CPU speculative execution 在 LLM 解码里的变体：先预测未来路径，预测对了就省时间，预测错了就回退。区别在于，LLM 的输出分布不能随便改变。经典 speculative decoding 使用接受-拒绝采样，让最终分布与目标模型逐 token 解码保持一致。

论文《Fast Inference from Transformers via Speculative Decoding》提出的方法可在不修改模型结构的情况下加速已有自回归模型，并在 T5-XXL 上报告了 2x-3x 加速，同时保持 identical outputs。这个结果不能直接外推到所有模型和业务流量，但说明了该方向的关键价值：把目标模型的多次串行前向，压缩成更少的验证前向。

为什么它能快

大模型推理经常受内存带宽限制。Hugging Face 的 assisted generation 文章指出，文本生成的延迟瓶颈来自大型模型连续 forward pass；在许多情况下，加载模型权重到计算核心比算术计算本身更关键。也就是说，目标模型处理 1 个新 token 和处理一小段候选 token，未必呈线性成本增长。

Speculative Decoding 正是利用这一点：

• 草稿模型很小，生成候选 token 的代价低；
• 目标模型一次验证多个 token，提升每次前向的”确认 token 数”；
• 如果接受率足够高，目标模型前向次数减少；
• 如果草稿成本低于节省下来的目标模型成本，就能降低延迟。

这里的关键不是”草稿模型越强越好”，而是草稿模型的延迟、接受率、目标模型验证开销之间的平衡。一个更强但太慢的草稿模型，可能让系统变慢。

工程选型：几类主流方案

1. Draft-Target Model

这是最容易理解的方案：使用一个小草稿模型和一个大目标模型。草稿模型预测候选 token，目标模型验证。

适用场景：

• 目标模型较大，单步解码慢；
• 有同 tokenizer 或高度兼容的小模型；
• 请求是小 batch、低延迟优先；
• 业务输出偏确定，接受率较高。

工程约束：

• tokenizer 最好一致，否则会引入解码/重编码成本；
• 草稿模型要部署、监控、版本管理；
• 需要处理目标模型和草稿模型的采样参数一致性；
• 要保证流式输出不会提前暴露未验证 token。

Hugging Face 的 assisted generation 实现要求 assistant model 与主模型使用相同 tokenizer，并提醒需要 benchmark 后再应用；其文章也指出，assistant model 至少应比主模型小一个数量级，收益才更容易显现。

2. NGram / Prompt-based Speculation

NGram speculative decoding 不依赖单独训练的草稿模型，而是从输入 prompt 或已生成输出中复制可能重复的 n-gram 作为候选。

这类方法适合：

• 摘要；
• 文档问答；
• 多轮聊天中重复上下文；
• 代码编辑；
• 输出高度引用输入的任务。

TensorRT-LLM 文档也把 NGram 作为 speculative sampling 支持方式之一，强调它适合输入和输出之间存在高 n-gram overlap 的场景。

优点是部署简单，不需要维护草稿模型；缺点是泛化能力有限，遇到开放式创作或推理任务时接受率可能不稳定。

3. Medusa / 多头预测

Medusa 不使用独立草稿模型，而是在目标模型上增加多个额外 decoding heads，用这些 head 预测未来 token，并通过树状候选和 attention mask 验证多个路径。

它降低了”额外维护一个草稿模型”的复杂度，但需要训练额外 head，并处理候选树规模、mask、KV Cache、推理后端兼容性等问题。Medusa 论文报告 Medusa-1 可在不损害生成质量的情况下实现 over 2.2x speedup，Medusa-2 可进一步达到 2.3-3.6x，但这些是论文实验结果，不应直接当成线上 SLA 承诺。

4. EAGLE / Feature-level Drafting

EAGLE 将 speculative sampling 的草稿预测从 token 层面转向模型内部 feature 层面。EAGLE 论文指出，对 second-to-top-layer feature 做自回归预测比直接预测 token 更直接，并在 LLaMA2-Chat 70B 上报告了 2.7x-3.5x latency speedup，同时保持生成文本分布。

这类方法通常更接近推理系统与模型训练的结合点：效果可能更好，但部署门槛也更高，需要匹配特定模型、草稿组件、后端 runtime 和验证逻辑。

5. Lookahead Decoding

Lookahead Decoding 试图不用草稿模型，而是把自回归解码看成非线性方程求解问题，通过 Jacobi-like 并行解码产生 n-gram，再在同一步进行验证。LMSYS 文章说明它不需要 draft model，并报告了 1.5x-2.3x 延迟降低。

它的工程价值在于减少草稿模型维护成本；但是否适合生产，要看 runtime 支持、attention mask 实现、具体模型和任务输出形态。

工程落地流程

第一步：先找适用流量，不要全站启用

不要把 Speculative Decoding 当成通用开关。先按请求类型切分流量：

• 代码补全；
• 文档问答；
• 摘要；
• 格式化 JSON 或模板化输出；
• 客服/内部助手；
• 长推理或创作类对话。

建议先从低温度、低开放性、输出可预测的场景开始。开放式创作、复杂推理、强采样、高温度输出，草稿接受率通常更不稳定。

第二步：定义草稿策略

草稿策略至少要回答四个问题：

1. 草稿来源是什么：小模型、NGram、Medusa head、EAGLE draft，还是 Lookahead？
2. 候选长度 K 如何设置：固定、动态，还是基于历史接受率调整？
3. 与目标模型是否共享 tokenizer、词表和采样配置？
4. 草稿失败时如何回退到普通解码？

一个简化的动态候选长度策略如下：

class DraftBudget:
    def __init__(self, min_k=2, max_k=8):
        self.k = min_k
        self.min_k = min_k
        self.max_k = max_k

    def update(self, accepted: int, drafted: int):
        if drafted == 0:
            return
        ratio = accepted / drafted
        if ratio > 0.8:
            self.k = min(self.k + 1, self.max_k)
        elif ratio < 0.4:
            self.k = max(self.k - 1, self.min_k)

这段代码不是完整推理实现，只表达一个工程原则：K 不宜拍脑袋固定，要受接受率和延迟反馈约束。

第三步：接入推理后端

如果使用现成 runtime，优先从框架原生能力开始：

框架	支持的 Speculative 方案
TensorRT-LLM	draft-target、NGram、Medusa、ReDrafter、EAGLE、Lookahead
Hugging Face Transformers	assisted generation
vLLM / SGLang	以实际版本文档和 benchmark 为准

线上接入时不要只测单请求 demo。至少要覆盖：

• 单请求 TTFT；
• 流式输出节奏；
• 低并发小 batch；
• 高并发 batch；
• 长输出；
• 多租户混合流量；
• 失败回退。

第四步：观测指标必须前置

上线前建议建立以下指标：

指标	说明	为什么重要
accepted_tokens / drafted_tokens	草稿 token 接受率	判断草稿是否有效
target_forward_passes_saved	节省的目标模型验证次数	判断是否真的减少串行步骤
draft_latency_ms	草稿生成成本	防止草稿模型拖慢整体
verify_latency_ms	目标模型验证成本	观察验证批量是否划算
TTFT	首 token 延迟	用户体感关键指标
TPOT	每输出 token 延迟	生成阶段核心指标
rollback_rate	回退普通解码比例	判断稳定性
quality_diff_sampled	抽样质量差异	防止实现细节破坏质量

如果只有 GPU 利用率和总 tokens/s，很容易误判。Speculative Decoding 经常是延迟优化，而不一定在所有并发下提高总吞吐。

常见误区

误区一：只看论文 speedup

论文和文档中的加速比是在特定模型、硬件、任务和实现下测得的。线上系统还有调度、网络、流式返回、队列等待、KV Cache 管理、多租户混合负载等因素。正确做法是做本业务 benchmark，而不是直接复用公开数字。

误区二：草稿模型越强越好

草稿模型强，接受率可能更高；但如果草稿模型慢，整体仍可能变慢。更合理的目标是最大化：

saved_target_time - draft_time - verification_overhead - scheduling_overhead

草稿模型选择应该用端到端延迟和成本判断，而不是只看草稿模型困惑度或 benchmark 分数。

误区三：忽略 tokenizer 和采样参数

草稿模型和目标模型 tokenizer 不一致，会引入额外重编码成本，也可能造成候选 token 对齐复杂化。采样参数、停止符、logits processor、禁用词、结构化输出约束不一致，也会导致验证逻辑和普通解码行为不一致。

误区四：高并发场景一定更快

TensorRT-LLM 文档指出 speculative sampling 在 GPU 因小 batch 而利用不足时可降低平均 token 延迟。反过来，如果高并发 batch 已经把 GPU 打满，验证多个候选 token 可能增加计算压力，收益会下降，甚至出现吞吐倒退。

误区五：提前向用户流式输出未验证 token

如果系统为了体感速度提前输出草稿 token，后续又被目标模型拒绝，就会出现撤回、闪烁或错误输出。生产系统应该只流式输出已验证 token，除非产品层明确接受”可修正草稿”的交互形态。

上线检查清单

上线前至少检查：

• 已明确启用范围：按模型、路由、业务、租户或流量比例灰度。
• 已配置一键回退普通解码。
• 草稿模型与目标模型 tokenizer、特殊 token、停止符策略已验证。
• 采样参数、logits processor、结构化输出约束已对齐。
• 已记录 accepted_tokens、drafted_tokens、draft_latency、verify_latency。
• 已覆盖低并发和高并发 benchmark。
• 已进行固定 golden prompt 回归。
• 已评估流式输出是否只暴露 verified tokens。
• 已评估 KV Cache、position id、attention mask 与候选树实现。
• 已准备异常回退和告警阈值。

适用场景

更适合：

• 低温度代码补全；
• 文档摘要；
• RAG 问答中答案大部分来自上下文；
• 业务模板化回复；
• 多轮对话中常见表达和固定流程；
• 单请求或小 batch 低延迟场景。

谨慎使用：

• 高温度开放式创作；
• 强推理长 CoT；
• 高并发大 batch；
• 草稿模型难以维护的多模型平台；
• 输出强依赖复杂工具调用状态的 Agent。

总结

如果你的线上瓶颈主要是 prefill、检索、工具调用、网络排队或后处理，Speculative Decoding 未必是第一优先级。它主要优化 decode 阶段，应先用 tracing 把瓶颈拆清楚。对于匹配的场景，从低风险流量开始灰度、建立完整指标体系、做好回退预案，才是将论文加速比转化为生产收益的正确姿势。

参考资料

1. Yaniv Leviathan, Matan Kalman, Yossi Matias, “Fast Inference from Transformers via Speculative Decoding”, arXiv, 2022. https://arxiv.org/abs/2211.17192
2. Hugging Face Blog, “Assisted Generation: a new direction toward low-latency text generation”, 2023. https://huggingface.co/blog/assisted-generation
3. NVIDIA TensorRT-LLM Documentation, “Speculative Sampling”. https://nvidia.github.io/TensorRT-LLM/advanced/speculative-decoding.html
4. LMSYS, “Break the Sequential Dependency of LLM Inference Using Lookahead Decoding”, 2023. https://www.lmsys.org/blog/2023-11-21-lookahead-decoding/
5. Tianle Cai et al., “Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads”, arXiv, 2024. https://arxiv.org/abs/2401.10774
6. Yuhui Li et al., “EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty”, arXiv, 2024. https://arxiv.org/abs/2401.15077
7. Shenggui Li et al., “SpecForge: A Flexible and Efficient Open-Source Training Framework for Speculative Decoding”, arXiv, 2026. https://arxiv.org/abs/2603.18567