- 推测解码用小草稿模型先猜几个 token，再由目标大模型一次前向并行验收，理论输出分布与目标模型一致，做到"无损加速"（Leviathan et al., 2023；Chen et al., 2023）。
- 目前几乎所有托管大模型的生产服务都在用它：OpenAI 把 GPT-5.6 Luna 降价 80% 部分归功于重设计的草稿模型，Anthropic 快速模式把同一个 Claude Opus 提速至 2.5 倍，DeepSeek 的 DSpark 带来 51% 吞吐提升，Kimi K3 直接随模型附赠草稿模型。
- 四代方法各拆一个瓶颈：EAGLE-3 拉长接受长度，DFlash 用扩散式并行起草压缩起草时间，DSpark 削减验证时间，DFlash 2 用 200 万参数的并行选择器进一步提升接受长度。
- "无损"是有条件的：放松验收阈值、调度器偷看后续 token、硬件数值偏差都会让输出分布漂移；论文测过的任务域只覆盖 OpenRouter 真实 token 流量的 17%，其余 83% 从未被测量。
- LosslessBench 的实测显示加速的质量代价真实存在：GLM 5.2 经第三方 fp4 加速后前端设计任务掉 5.6 分，而自带草稿模型的 Kimi K3 只掉 0.3 分——加速由谁做，决定质量损失归谁管。
推测解码是什么：草稿模型先猜，目标模型验收
每个大模型生成文本都是逐 token 串行的：产出 n 个 token 就要跑 n 次完整前向，这是推理的主要瓶颈。推测解码 2023 年提出后给出了另一条路：让一个轻量草稿模型先猜出接下来的 3 到 8 个 token，目标模型用一次前向把这几个候选全部验算一遍，逐个决定接受或拒绝。一次验收的开销约等于解码一个 token，省下的就是串行等待的时间。
可以把它想成编辑部流程：草稿模型是写初稿的实习生，目标模型是终审的主编。实习生写得越像主编的风格，一次签发的稿子就越多。这个类比对应三个决定速度的因子：起草时间、验收时间、接受长度 τ（每轮验收平均签发几个 token）。接受率 α 与两个分布的总变差距离直接相关——α = 1 − D(p, q)，草稿分布离目标分布越近，接受越多，加速越高。
无损性来自验收环节的拒绝采样：每个草稿 token 按 min(1, p/q) 的概率接受，被拒后从残差分布重采一个。数学上两种方式拼出来的输出概率与目标模型自己的分布完全相等，所以草稿再差也不改变输出，只改变速度。这套证明出自 Leviathan et al. 2023 的附录，2023 年之后的方法都继承这个定理，不再重新证明无损。
实际速度有多少？教程给出的例子：单张 B200 上用 SGLang 部署 Qwen3-8B，原始解码约 230 token/s；换上 DFlash 草稿后对话文本提速约 2.75 倍到 630 token/s 左右，生成一本《哈利·波特》篇幅（约 10 万 token）的时间从 7 分多钟压到 3 分钟以内。
四代方法怎么演化：每一代拆掉一个瓶颈
推测解码的速度由起草时间、验收时间、接受长度三个因子决定，四代方法各自针对其中一个。
| | | | |
|---|
| | | 单层草稿头复用目标模型隐层特征，训练时自展开对齐推理分布 | SGLang、vLLM 原生支持，Llama/Qwen/DeepSeek V3/Kimi K2.5 有官方草稿头 |
| | | | SGLang、vLLM、TensorRT-LLM、llama.cpp，Meta/NVIDIA 等发布官方草稿 |
| | | 置信度头预测各位置存活率，负载感知调度器按请求裁剪验证长度 | DeepSeek-V4 生产栈，开源权重与 DeepSpec 训练库 |
| | | 200 万参数并行路径选择器替代串行头，局部卷积保持块内连贯 | SGLang、vLLM、llama.cpp、Ollama |
EAGLE-3 之前，草稿是一个独立的小模型，或者 Medusa 那样挂在目标模型上的额外预测头。EAGLE 把草稿换成一个读取目标隐层特征的单层解码器，EAGLE-3 再砍掉特征预测目标、直接预测 token，并用"训练时自展开"解决推理时分布漂移。结果：对比原始解码最高 6.5 倍加速，约为 EAGLE-2 的 1.4 倍，也是目前生产框架里采用最广的草稿方案。
DFlash 解决的是"起草本身还在串行"的问题。它借鉴扩散模型整幅去噪的思路：草稿块从一排 MASK token 开始，一次前向把整块填完，起草成本不再随块长增长。五层起草网络一次生成 16 个 token，在起草成本和接受长度上同时胜过 EAGLE-3 的单层 8 token。教程引用的数据是多个模型和任务上超 6 倍的无损加速，比 EAGLE-3 再高 2.5 倍。
DSpark 转向验证侧：给每个草稿位置算一个存活置信度，调度器按引擎负载决定这一轮验证多长。离线上接受长度比同期最优起草器高 16% 到 31%；在 DeepSeek-V4 生产栈中，相同吞吐下单用户生成提速 60% 至 85%。DFlash 2 则回应 DSpark 重新引入串行头的取舍：它发现正确 token 往往已在各位置候选列表里，缺的只是选择——用一个 200 万参数、只增加 0.6% 延迟的并行路径选择器替代 DSpark 7780 万参数、增加 9.6% 延迟的串行头，在 Qwen3.5-4B 上把接受长度从 4.92 推到 5.97。
这套技术不是免费的。草稿模型要额外占显存；草稿猜得差时加速比可能跌破 1；高并发下 GPU 已被批处理占满，引擎会直接关掉推测。
生产环境里的"无损"什么时候失效
论文里的无损有三层前提，部署时每一层都可能破。
第一层是温度与验收规则。温度为 0 时解码是确定性的，草稿 token 与目标一致才接受，天然无损。温度为 1 时，像 Medusa 这类按概率阈值接受草稿的方法会让输出偏向草稿的偏好，分布就漂了。SGLang 默认把验收阈值卡在 1.0 保持严格拒绝采样，用户调低阈值换速度，无损就此失效。
第二层是调度器。无损证明要求"是否验证第 k 个位置"的决定只能看 1 到 k-1 的前缀，不能偷看后面的 token。DeepSeek 在生产部署 DSpark 时就撞上两个真实冲突：调度器扩大了搜索范围会破坏无损，引擎要求固定 batch size 而算法要变长验证。他们的解法是异步调度——用两步之前的置信度预测来设定 batch size，绕开偷看。
第三层是数值与系统。vLLM 文档把无损拆成三层：理论无损（到硬件数值精度为止）、算法无损（拒绝采样收敛测试）、输出稳定性（不承诺）。batch size 一变，logprobs 就在浮点精度内偏移，贪心解码下一个接近平局的 token 就会走向另一边。教程的实测很直观：同一个前端任务，vanilla 与 DSpark 两条路径有 76% 的字符级前缀相同，分岔点是一个 transition 时长 0.2s 与 0.3s 之差——两页都满足需求，但它们不是同一页。
更大的问题在测量覆盖。EAGLE-3、DFlash、DSpark 的实验都跑在 GSM8K、HumanEval、MT-Bench 这九个基准上，只覆盖编程、聊天、数学。对照 OpenRouter 真实流量的 29 类任务，已测任务域只占 token 用量的 17%，其余 83% 从未被任何推测解码论文测量过。论文里的"无损"，在这 83% 上没有证据。
LosslessBench：加速到底丢了多少质量
Lily Zhang 2026 年 7 月发布的 LosslessBench 就冲着这个缺口来：按 OpenRouter 真实流量结构选了五个域——前端设计、Agent 工作流、创意写作、安全护栏、编程，每个域用该域自己的基准（OpenDesign、tau3-bench、EQ-Bench、XSTest、Terminal-Bench）。
最直接的证据来自同一个模型的两条服务路径对比。GLM 5.2 在 Z.AI 以发布精度 fp8 提供服务，在 Baseten 则是 NVFP4 量化加推测解码、KV 路由、PD 分离的加速栈。结果前端设计一项掉了 5.6 分：一个"悬浮翻转的照片卡片"需求，fp8 路径得分 93 并实现 3D 翻转，fp4 加速路径得分 15，页面接近空白。Baseten 公布的质量证据是 BFCL 函数调用基准，它测功能正确性，不测质量。
Kimi K3 是反例。它从 SFT 阶段就做量化感知训练，把预训练的 MTP 层微调为 EAGLE-3 草稿模型，模型本体以 MXFP4 出货，加速由模型层自己持有。同样跑 LosslessBench，K3 前端设计只掉 0.3 分。这引出一个结构判断：模型公司要分发、推理服务商要速度、应用层要便宜能用，质量损失沿着链条向下滚，最后由用户买单；谁把加速收进模型层，谁就把质量责任接了回去。DeepSeek 把 fp8 推进预训练、gpt-oss 出货 MXFP4 QAT、K2-Thinking 以 INT4 报全部基准、K3 附赠草稿模型，都是同一方向。
教程作者自己也复现了覆盖缺口的后果：用 DFlash 草稿跑 LosslessBench，五个域的接受长度从 5.24 掉到 1.84，越是没有论文测过的域，草稿与目标的分歧越大；前端设计的接受率保持高位、页面却照样坏掉——接受率量的是两个模型的一致性，不是输出质量。
快速上手：自己跑一遍推测解码
教程附带一个完整的动手实验，仓库在 GitHub（lilyzhng/2026_NeurIPS_Education），GPU 可以用 Modal 新账号的 30 美元免费额度（H100 约 4 美元一小时，整个实验下来约 8 到 12 美元）。
第一步，用 vLLM 起一个 vanilla 服务并测速：
第二步，同一个模型挂上 DeepSpec 的 DSpark 草稿再测一次：
教程在单张 H100 上 5 次运行的结果是吞吐从 136.3 提到 231.4 token/s，加速比约 1.7 倍，接受长度约 3.5。接受长度 vLLM 不直接报，可以从 /metrics 的草稿 token 计数反推。
第三步，在 SGLang 里亲手调验收阈值。--speculative-accept-threshold-single 默认 1.0，逐步降到 0.4，在前端设计任务上接受长度从 4.9 升到 7.2——48% 的草稿偏好 token 被放行，生成更快，页面开始走样。温度为 0 时这个阈值不起作用，各档输出逐字节一致。这最后一组实验把前面所有概念变成了肉眼可见的东西。
下一步：多模态与工具调用
两个方向都没有到主流采用，但都已开局。多模态侧，vLLM 在 v0.11.1 合并了首个 VLM 的 EAGLE-3 支持（限 Qwen2.5-VL），其余推测路径仍拒绝多模态模型；首个 VLM 推测解码基准 MMSpec 的发现是，为语言模型设计的推测解码在多模态输入上会退化，原因是草稿模型的视觉能力跟不上目标模型。
另一个方向是把"先猜后验"从 token 提升到工具调用。Agent 的昂贵单位是工具调用：一次子查询或 API 请求要几秒钟，而发起它的代码还在生成中。Speculative programmatic tool calling 的做法是让第二个解释器先跑已写完的部分代码，把输入已确定的工具调用提前发出去；猜错只浪费一次提前调用。在 OOLONG 基准上用 Qwen3-30B 测得端到端提速 1 到 1.2 倍。这个方向还缺共享基准，各论文在各自的设置上评估。
行动清单
- 选引擎先看默认验收阈值：SGLang 默认 1.0 保持无损，调低就是拿质量换速度，改之前想清楚业务能不能承受分布漂移。
- 高并发场景不要指望推测解码：GPU 被批处理占满时引擎会关闭它，容量规划按 vanilla 吞吐做底。
- 评估加速方案别只看 accept length 和 tok/s：接受率量的是草稿与目标的一致性，不量任务质量，前端、写作这类论文没测过的域要自己跑一遍。
- 采购第三方加速端点时问清楚栈里叠了什么：量化、推测解码、KV 路由、PD 分离各自都可能引入质量损失，要求对方给出功能基准之外的质量证据。
- 有余力就用教程的 Modal 实验复现一遍：30 美元额度足够跑完全部实验，亲手调一次验收阈值比读十篇介绍都管用。
AI 速览
