投机解码与知识蒸馏：把 70B 的脑子塞进 7B 的速度，且不丢精度

本文先讲清自回归解码为什么是延迟瓶颈，再用一次并行验证把投机解码（speculative decoding）的无损性数学保证推到底。接着分析 draft 模型选型、知识蒸馏，以及 EAGLE-3/DFlash 遇到的 offline-to-inference mismatch 难题。核心章节拆解上交大与清华在 EMNLP 2026 提出的 Draft-OPD：用 on-policy 蒸馏解决 mismatch，对思考模型实现 5 倍无损加速，比 EAGLE-3/DFlash 分别高 23% 和 13%。最后给一套工程落地步骤、MoE 特例、硬件感知建议和 6 条线上踩坑排查手册。读完你应能判断自己的服务到底该不该上投机解码，以及 draft 该怎么选、怎么训。

关键词：投机解码、知识蒸馏、Draft-OPD、EAGLE、on-policy distillation、MoE、TensorRT、无损加速、推理优化

一、写在前面：为什么现在必须聊这件事

2026 年做推理优化的人，最难啃的一块其实是 decode（解码）阶段。prefill 阶段是算力密集，可以靠批处理堆吞吐；decode 阶段是访存密集，每生成一个 token 必须等前一个 token 算完，批再大也摊不薄这一步的延迟。结果就是：你花大价钱训了个 70B 的强模型，线上用户感知到的首 token 延迟和每 token 速度，却卡在那个串行循环里动弹不得。

把模型量化到 4 位能省显存，但救不了 decode 的本质串行；把层数减到 7B 能快，但精度掉得你不敢上生产。有没有一条路，能同时拿到"大模型的质量"和"小模型的速度"？有，答案就是投机解码加知识蒸馏这套组合拳。

这篇文章的目标有三个。第一，把投机解码为什么无损这件事用概率论讲透，让你敢于在生产上开它而不必担心"是不是偷偷降了精度"。第二，拆解为什么简单的 SFT 蒸馏做 draft 会撞上 offline-to-inference mismatch 天花板，以及 Draft-OPD 是怎么用 on-policy 蒸馏破局的。第三，给你一套能落地的工程步骤和踩坑清单，因为投机解码是最容易"上线即负优化"的优化之一，盲目开只会让 P99 更难看。

一句话结论先放这里：投机解码是 2026 年最值得上的 decode 加速手段，但它不是免费的午餐，draft 选错、batch 调错、分布没对齐，都会让它从加速变成减速。

二、技术背景与现状梳理

2.1 自回归瓶颈：每 token 都在等前一个

Transformer 解码的本质是自回归（autoregressive）：第 t 个 token 的概率依赖前 t-1 个 token 的 KV。实现上，每生成一个 token 都要跑一次完整的模型前向（forward），而这次前向里绝大部分计算是"为这一个新 token 重算/复用 KV 并过一遍全部参数"。一个 70B 模型每走一步，哪怕只输出一个 token，也要把整个权重搬一遍过attention。

这就带来两个结构性约束：

• 串行依赖：第 t+1 步必须等第 t 步完成，无法并行。这是延迟的下界，和批大小无关。
• 单步完整前向：每一步都是一次"满血"前向，不能因为只差一个 token 就偷工减料。

所以纯自回归的 decode 速度，近似等于"每步前向耗时 x 输出长度"。想提速只有两条路：要么减少每步耗时（量化、稀疏、更少的层），要么一次步里多产出几个 token。投机解码走的是第二条路。

2.2 投机解码与知识蒸馏的定位

投机解码（speculative decoding）解决的是"一次产出多个 token"的问题；知识蒸馏（knowledge distillation）解决的是"draft 模型从哪来、怎么够小又够准"的问题。两者通常是配套出现的：你需要一个比 target 小得多的 draft 来"猜"，而这个 draft 最好是通过蒸馏从 target 身上学来的，这样它的分布和 target 接近，接受率才高。

2026 年的推理优化路线图里，prefill/decode 两阶段已经被分开对待：prefill 用批处理、量化、稀疏 attention 提吞吐；decode 用投机解码提单请求延迟。蒸馏则横跨两端，既给投机解码供 draft，也给"用更小的模型替代更大模型"提供质量兜底。

三、核心原理拆解

这一章是全文重点，我们按"无损性数学保证 -> draft 选型 -> 知识蒸馏 -> mismatch 难题 -> Draft-OPD -> 工程步骤 -> MoE 特例 -> 硬件感知"这条线拆开。

3.1 投机解码的基本流程

思路非常朴素：用一个小而快的 draft 模型，基于当前上下文先"猜"出接下来一串 token（比如 4 到 8 个），然后把这串草稿连同原上下文一起交给大的 target 模型，target 用一次并行前向对这整块草稿逐个位置打分，凡是和 target 自己在该位置贪心选择一致的就接受，第一个分歧点之后的全丢掉，并从分歧点继续。

关键洞察是：target 对草稿块做的是"一次前向、整块独立打分"，而不是逐 token 串行。所以验证 k 个草稿 token 的代价，约等于一次前向，而不是 k 次前向。如果接受率高（比如平均接受 4 个），那么原本要 4 次前向的活，现在变成 1 次 draft 前向 + 1 次 target 验证前向，净赚。

3.2 无损性的数学保证

这是大家最担心的一点：并行验证会不会改变输出分布，让结果"不是原来的模型了"？答案是否定的，有严格证明。

记 target 分布为 p，draft 分布为 q。draft 自回归地提出一串 x1, x2, …, xk。target 对这整块做一次前向，得到每个位置的条件概率 p(x_i | x_<i)。验证时采用如下接受规则：

• 对 i = 1…k，若 draft 提出的 x_i 恰好等于 target 在该位置的贪心 argmax（即 p 下概率最大的 token），则接受 x_i，继续。
• 在第一个分歧位置 m（draft 提议 != target 贪心），我们不直接用 draft 的提议，而是从如下修正分布中采样一个 token：

p'(x) = normalize( max(0, p(x) - q(x)) ) 当 x != draft_proposal p'(draft_proposal) = sum_y min(p(y), q(y)) （即接受草稿的剩余质量）

这个修正分布的妙处在：它等价于"先从 p 采样，若不等于 draft 提议则按概率拒绝并改从残差分布补采"，最终从 x_m 往后的边际分布严格等于 p。换句话说，被接受的 token 序列，其联合分布与 target 自己一步步自回归生成的分布完全一致。这是投机解码"无损"的严格含义：它不是近似，是分布级别的精确等价。

直观理解：匹配的前缀本来就与 target 贪心一致；第一个分歧点我们用"拒绝采样 + 残差补偿"把 draft 带来的偏差精确抵消掉，所以从统计学意义上，这条轨迹和纯 target 解码无法区分。这也是为什么业界敢在生产上直接替换而不重新做质量评估。

3.3 draft 模型选型

draft 选得好不好，直接决定加速比。实践中的经验区间如下：

• 规模：draft 取 target 的 5% 到 10% 参数量，常见做法是 1/10 到 1/20 大小。太小则接受率低，太大则 draft 自身前向变慢、净收益消失。
• 草稿长度（draft length）：4 到 8 个 token 是甜区。太长则第一个分歧大概率更早出现，多猜的都被丢弃，浪费 draft 算力；太短则并行验证的摊薄效果不足。
• 接受率 < 50% 要微调：如果实测平均接受率长期低于 50%，说明 draft 和 target 分布偏得太远，这时候不该继续加长草稿，而应该回过头微调 draft，让它更贴近 target。
• 大 batch 下收益消失：这是最反直觉的一条。当并发 batch 很大时，target 模型从"访存密集"变成"算力密集"（compute-bound），此时多 draft-target 对会争用调度，验证步的开销盖过了并行收益，投机解码甚至可能变负优化。它最适合的是低延迟、小 batch 的在线场景，而不是高吞吐离线批处理。

下面这段脚本按 3.3 的规模区间自动给出 draft 候选规模，并建议起始 draft length：

#!/usr/bin/env python3"""根据 target 参数量给出 draft 规模候选与起始 draft length。"""defdraft_candidates(target_params_b):# 取 target 的 5%~10% 区间lo=target_params_b*0.05hi=target_params_b*0.10returnlo,hidefsuggest_draft_length(accept_rate):ifaccept_rate>=0.6:return8ifaccept_rate>=0.4:return5return3# 接受率偏低，先短一点，回去微调 draftif__name__=="__main__":lo,hi=draft_candidates(70)print(f"70B target -> draft 候选:{lo:.1f}B ~{hi:.1f}B")print("建议起始 draft length:",suggest_draft_length(0.55))

3.4 知识蒸馏：让 draft 贴近 teacher

draft 模型怎么来？最直接的是拿一个现成的小模型当 draft，但更优的是从 target 身上蒸馏一个专用 draft。知识蒸馏和传统"只学硬标签"的训练不同：学生学的是 teacher 的输出分布（软标签 / 概率向量），而不是仅仅学"正确答案是哪个 token"。

为什么这对延迟优先场景特别合适？因为我们的目标是"draft 的分布尽量逼近 target 的分布"，这样接受率才高；而蒸馏正是最小化学生与 teacher 输出分布差异的训练范式（比如用 KL 散度做损失）。一个从 70B teacher 蒸馏出来的 7B student，天然比一个无关的小模型更适合当它的 draft。这也顺带回答了"能不能直接拿小模型压缩替代大模型"：能，但用蒸馏得到的 draft 在投机解码框架里还能再叠加一层加速。

3.5 offline-to-inference mismatch：SFT 的天花板

EAGLE-3、DFlash 这类方法，用 SFT（监督微调）让 draft 学习 target 在固定轨迹上的行为。问题出在训练和推理的错位，业界称为offline-to-inference mismatch：

• 训练时，draft 学的是"target 固定轨迹"上的下一 token 预测，数据来自 teacher 的某条确定轨迹。
• 推理时，验证的是 draft自己策略提出来的块（因为草稿是 draft 自回归生成的，不是 teacher 生成的）。

也就是说，draft 在训练时从没见过"自己提的块被验证"的分布。结果是 SFT 很快撞上 plateau（平台期）：无论怎么加数据、加步数，接受长度（accept length，平均一次验证能接受几个 token）不再涨。mismatch 导致 draft 在它真正要工作的分布上校准不足，提的块经常第一个位置就分歧，加速比上不去。

3.6 Draft-OPD：用 on-policy 蒸馏破局

2026 年 9 月，上海交通大学与清华大学在 EMNLP 2026 提出Draft-OPD（On-Policy Distillation for Drafts），正面解决 mismatch。它的核心思想是让 draft 在"自己实际提出、并被 target 验证"的分布上学习，而不是在离线固定轨迹上学习。三个关键机制：

• target 辅助 rollout 维稳：训练时用 target 的输出来辅助生成训练信号、稳住训练过程，避免 draft 在 on-policy 自我生成时分布漂移失控。
• 在验证暴露的错误位重放（replay）：把验证阶段暴露出的分歧位置（即 draft 提错的地方）收集起来，针对性地重放训练，专门修补这些弱项，而不是均匀地学整条轨迹。
• 接受感知蒸馏目标（acceptance-aware distillation objective）：蒸馏目标同时利用 target 对草稿的"接受"和"拒绝"两种信号——不仅从被接受的提议里学，也从被拒绝的提议里学"为什么错"，从而把 draft 的分布往"更容易被接受"的方向推。

效果上，据 2026-09-25 的公开报道，Draft-OPD 对思考模型（reasoning model）实现约 5 倍无损加速，相比 EAGLE-3 和 DFlash 分别带来约 +23% 和 +13% 的加速增益。思考模型之所以受益尤其明显，是因为其长链式推理输出长、decode 步数多，投机解码一次能吞下的 token 也更多。

3.7 工程落地步骤

把投机解码真正跑顺，建议严格按下面六步推进，不要跳步：

1. 基线延迟：先量清 target 不带投机解码时，在目标 batch 下的 p50/p95/p99 每 token 延迟和吞吐。没有基线就没有加速比。
2. 选 draft：按 3.3 的规模区间挑/训一个 draft，优先从 target 蒸馏。
3. 固定 draft length：先固定一个长度（比如 5）做对照，别一上来就动态。
4. soak 测接受率：长时间 soak（压测）下观察平均接受长度与接受率，确认稳定且不掉。
5. 动态 draft length：接受率稳了再上动态长度（接受率高就加长，低就缩短）。
6. 全链路 telemetry：把接受/拒绝比、每步验证耗时、加速比都打点上报，作为线上 SLO。

3.8 MoE 特例

如果你的 target 是 MoE（混合专家）模型，draft 选型有特殊讲究：优先用从 target 自身 expert 蒸馏出来的 draft，而不是一个通用的小 dense 模型。原因是 MoE 的路由逻辑和专家特化让它输出分布有独特风格，一个无关 dense draft 很难贴合这种"某些 token 走专家 A、某些走专家 B"的模式，接受率会被压低。从 target 的 expert 层蒸馏，能让 draft 在风格和逻辑上都更贴近，匹配度更高。

MoE 专用 draft 的蒸馏配置骨架（按 expert 选择性蒸馏，而非整层）：

#!/usr/bin/env python3"""MoE draft 蒸馏：仅对 target 高频激活的 expert 做蒸馏，其余层用原小模型。"""EXPERT_WHITELIST=["e3","e7","e11"]# 线上路由分析得到的高频 expertdefbuild_moe_draft(target,base_small):draft=base_small.copy()forname,modintarget.named_expert_modules():ifany(einnameforeinEXPERT_WHITELIST):draft.inject_expert(name,distill_from=mod)# 从 target 对应 expert 蒸馏returndraftif__name__=="__main__":print("MoE draft 将注入 expert:",EXPERT_WHITELIST)

3.9 硬件感知

投机解码能不能真正加速，一半在软件一半在硬件栈：

• NVIDIA TensorRT / TensorRT-LLM 原生支持投机解码：在 TensorRT 的运行时里，投机解码的 draft 验证是和 kernel 融合、调度深度绑定的，比在普通 PyTorch 上自己拼要高效得多。生产上要拿满加速比，基本都要落到 TensorRT 这类原生支持的运行时的肩上。
• 模块化架构让 draft 可热换：把 draft 抽象成一个可插拔模块，而不是写死在推理循环里。这样你可以随时换更大的 draft、换蒸馏版、换 MoE 专用 draft，甚至按流量在高峰关掉投机解码（避免 3.3 说的大 batch 负优化），而不用改主推理路径。

四、环境与依赖准备

下面给一套用于验证和落地的技术栈与门槛，版本以 2026 年 10 月可用组合为准：

硬件门槛的关键点：draft 极小（5%~10% 参数量），几乎不额外吃显存，所以同一张卡上 target + draft 是可行的。真正的门槛是 TensorRT 栈的兼容性和你能否拿到业务真实的 prompt 分布来做接受率校准——用公开的 wikitext 测出来的接受率，和你的线上分布往往差很远。

五、完整实操

这一章给可运行代码，覆盖"投机解码验证步、draft 蒸馏训练骨架、接受率 telemetry、TensorRT 配置、动态 draft length、基线测量"。

5.1 投机解码验证步（可运行示例）

下面这段用贪心验证演示一次投机解码的接受逻辑（为可读性用占位模型，真实环境替换为你的 target/draft 调用）：

#!/usr/bin/env python3"""演示投机解码的贪心验证：draft 提议一串，target 一次打分，前缀接受到首个分歧。"""importrandomdefdraft_propose(ctx_tokens,k):# 占位：真实环境调用 draft 模型自回归生成 k 个 tokenreturn[f"d{i}"foriinrange(k)]deftarget_greedy(ctx_tokens,pos):# 占位：返回 target 在 pos 位置的贪心 argmaxreturnf"t{pos}"defspeculative_step(ctx,k=5):draft=draft_propose(ctx,k)accepted=[]fori,tokinenumerate(draft):iftok==target_greedy(ctx,i):accepted.append(tok)else:# 首个分歧：从修正分布重采（此处简化为直接取 target 贪心）accepted.append(target_greedy(ctx,i))breakreturnacceptedif__name__=="__main__":out=speculative_step(["ctx"],k=5)print("accepted:",out,"len=",len(out))

注意真实实现里分歧点要用 3.2 的残差修正分布采样，而不是简单取 target 贪心，否则分布会偏移。这里为了可运行做了简化。

5.2 draft 蒸馏训练骨架

下面是一个 on-policy 感知的蒸馏训练骨架，演示如何同时利用接受/拒绝信号（对应 Draft-OPD 的接受感知目标）：

#!/usr/bin/env python3"""draft 蒸馏训练骨架：以 target 输出分布为教师信号，最小化 KL，并按接受/拒绝加权。"""importtorchimporttorch.nn.functionalasFdefdistill_step(draft_logits,target_logits,accept_mask):# draft_logits / target_logits: [B, T, V]# accept_mask: 1 表示该位置被 target 接受，0 表示被拒绝soft=F.softmax(target_logits/1.0,dim=-1)logp=F.log_softmax(draft_logits,dim=-1)kl=F.kl_div(logp,soft,reduction="none").sum(-1)# [B, T]# 接受感知：被拒绝的位置给更高权重，逼 draft 修正错误weight=torch.where(accept_mask==0,2.0,1.0)loss=(kl*weight).mean()returnlossif__name__=="__main__":B,T,V=4,8,32d=torch.randn(B,T,V,requires_grad=True)t=torch.randn(B,T,V)m=torch.randint(0,2,(B,T)).float()loss=distill_step(d,t,m)print("distill loss:",float(loss))

5.3 接受率 telemetry（挂到监控）

把接受/拒绝比打点上报告警，是线上防负优化的眼睛：

#!/usr/bin/env python3"""把每次投机解码的接受长度与拒绝数记录为指标。"""fromcollectionsimportdequeclassSpecMetrics:def__init__(self,window=1000):self.accept_len=deque(maxlen=window)self.rejects=deque(maxlen=window)defrecord(self,accepted_len,rejected):self.accept_len.append(accepted_len)self.rejects.append(rejected)defaccept_rate(self):ifnotself.accept_len:return0.0returnsum(self.accept_len)/(sum(self.accept_len)+sum(self.rejects)+1e-9)if__name__=="__main__":m=SpecMetrics()m.record(4,1)m.record(5,0)print("accept_rate =",round(m.accept_rate(),3))

5.4 TensorRT-LLM 投机解码配置

在 TensorRT-LLM 的启动配置里开启原生投机解码（结构示例，字段名以你所用版本为准）：

{"speculative_decoding":{"enabled":true,"draft_model_dir":"/models/draft-7b","num_draft_tokens":5,"use_dynamic_draft_length":true},"max_batch_size":8}

注意max_batch_size不要设太大，否则落入 3.3 的大 batch 负优化区间。小 batch（如 1 到 8）才是投机解码的甜区。

5.5 动态 draft length 逻辑

接受率稳了之后，用动态长度替代固定长度，让系统自适应：

#!/usr/bin/env python3"""根据近期接受率动态调整 draft length。"""classDynamicDraftLen:def__init__(self,lo=2,hi=8,start=5):self.lo,self.hi,self.cur=lo,hi,startdefupdate(self,recent_accept_rate):ifrecent_accept_rate>0.7andself.cur<self.hi:self.cur+=1elifrecent_accept_rate<0.4andself.cur>self.lo:self.cur-=1returnself.curif__name__=="__main__":d=DynamicDraftLen()print("len after high AR:",d.update(0.85))print("len after low AR:",d.update(0.3))

5.6 基线延迟测量脚本

上线前必须先有基线。下面用 bash 起一个简单的压测思路（替换成你的真实推理端点）：

#!/usr/bin/env bash# 基线延迟测量：对目标端点发 N 次请求，记录每 token 耗时foriin$(seq1200);docurl-s-o/dev/null-w"%{time_total}\n"http://localhost:8000/generatedone|awk'{s+=$1; if($1>m)m=$1} END{print "avg="s/NR" max="m}'

六、结果对比与数据分析

6.1 draft 规模与预期收益

6.2 接受率与加速比关系（示意）

6.3 Draft-OPD 与基线方法对比（据 2026-09-25 报道）

6.4 工程落地步骤表

七、踩坑记录与排查手册

这部分是线上真实事故，每条按"现象 / 定位 / 原因 / 解决"四段式写。

7.1 草稿校准差，验证步净增延迟

• 现象：开了投机解码，P50 没降反而升了 10%。
• 定位：打点发现 verify（验证）步耗时远高于预期，且 accepted_len 长期为 1。
• 原因：draft 和 target 分布严重偏，几乎每个块第一个 token 就分歧，等于白跑一遍 draft 前向，又多一次 target 验证。
• 解决：回退到 3.3，重新校准 draft（蒸馏/微调），把接受率拉到 50% 以上再上；上线前用业务真实分布 soak。

7.2 大 batch 下变负优化

• 现象：单请求压测加速 3 倍，但生产高并发下反而比不开更慢。
• 定位：监控发现 GPU 从访存密集转为算力密集，draft-target 对争用调度。
• 原因：高并发 batch 下 target 已是 compute-bound，投机解码的并行验证收益被多对调度的额外开销吃掉（3.3 的反直觉点）。
• 解决：高吞吐场景关掉投机解码或只在小 batch 队列启用；用动态策略按 batch 大小切换。

7.3 接受率长期 < 50% 没发现

• 现象：服务跑了两周，没人注意到加速比在缓慢退化。
• 定位：接上 5.3 的 telemetry 后，发现 accept_rate 从 0.65 掉到 0.42。
• 原因：target 模型被悄悄升级/热更新，draft 还是老的，分布偏移但无人告警。
• 解决：把 accept_rate 设成 SLO 指标，低于阈值自动告警并触发 draft 重训（见 3.7 版本感知）。

7.4 draft 与目标分布偏移

• 现象：接受长度随输出长度变长而骤降，长回答几乎无加速。
• 定位：分析发现 draft 在长上下文尾部校准差，提的块全被拒。
• 原因：draft 训练数据多是短上下文，没覆盖长上下文分布；且遇到 offline-to-inference mismatch（3.5）。
• 解决：用 on-policy 蒸馏（Draft-OPD 思路）在 draft 自己提出的块上重训，并在错误位重放；扩大训练上下文长度覆盖。

7.5 tail latency 抖动

• 现象：p50 好看，但 p99 偶尔飙高，用户体验忽快忽慢。
• 定位：发现抖动出现在 draft length 动态调大时，偶发整块被拒导致需要补多次前向。
• 原因：动态 draft length 的步长太大，或在负载高峰误判接受率。
• 解决：动态长度加平滑（限单步调整幅度），并对 p99 单独设告警；高峰自动回退到保守固定长度。

7.6 MoE 用错 draft 类型

• 现象：MoE target 接了一个普通 dense 小模型当 draft，接受率远低于同规模理论值。
• 定位：对比实验显示换成从 MoE expert 蒸馏的 draft 后接受率明显上升。
• 原因：MoE 的路由特化和专家风格，通用 dense draft 拟合不了（3.8）。
• 解决：MoE target 一律用从自身 expert 蒸馏的专用 draft；把 draft 类型纳入选型 checklist。

八、优化方案与进阶打法

基础投机解码跑顺后，还有几件事能进一步榨干收益：

其一，把接受率当一等指标运营。不要只在上线时测一次。接受率随模型版本、prompt 分布、业务淡旺季都会变，把它做成滚动看板 + 告警，才能避免 7.3 的"两周静默退化"。

其二，draft 热换与 A/B。借助 3.9 的模块化架构，可以在不重启主推理路径的前提下换 draft：新 draft 先对小流量开，对比接受率和延迟，胜出再全量。

其三，蒸馏用 on-policy 而不是 SFT。如果自研 draft，强烈建议直接走 Draft-OPD 这一类 on-policy 路线，避开 offline-to-inference mismatch 的 plateau。SFT 在初期快，但到了生产需要的接受长度就涨不动了。

其四，思考模型重点投入。思考模型 decode 步数多、输出长，投机解码的单位收益最高（报道里 5x 主要落在这一类）。把工程资源优先投向推理型负载，回报最大。

九、适用场景与选型建议

不是所有服务都该上投机解码，下面是我的判断：

• 低延迟、小 batch 的在线对话 / 代码补全：最推荐，投机解码的甜区，加速比实打实。
• 思考 / 推理模型长输出：强烈推荐，单位收益最高。
• 高吞吐离线批处理（大 batch）：不推荐，compute-bound 下容易负优化（7.2）。
• 输出极短（每次就几个 token）：收益有限，草稿块还没铺开就结束了，不值得上。
• target 频繁热更新：上之前先把 draft 重训/热换机制做好，否则 7.3 的退化会反复发生。

什么情况不该自研 draft：如果你没有蒸馏训练链路，也拿不到业务真实分布做校准，直接用语讯栈（如 TensorRT-LLM 自带 draft 或社区预训练 draft）比自己手搓更稳。不要为了"自己训"而训一个校准差的 draft，那只会触发 7.1。

十、总结与展望

投机解码的本质，是用"小模型猜、大模型一次验证"把自回归的串行下界打开一个口子，而且它无损——接受后的 token 分布与 target 自回归严格一致，不丢精度。真正决定它能否落地的，是 draft 的选型与训练：规模取 target 的 5% 到 10%、draft length 4 到 8、接受率低于 50% 就回炉；而 draft 怎么训，是分水岭——SFT 会撞上 offline-to-inference mismatch 的平台期，on-policy 蒸馏（如 Draft-OPD）才能持续把接受长度推上去，对思考模型实现约 5 倍无损加速。

落地上最容易被忽视的是：大 batch 下收益消失、接受率要当 SLO 运营、MoE 要用专用 draft、telemetry 不能省。这些踩坑每一条都曾让"上线即负优化"。把工程六步法和 6 条排查手册吃透，投机解码才会从论文里的漂亮数字，变成你线上实实在在的延迟下降。

展望 2026 下半年：随着 TensorRT 等运行时把投机解码做成默认能力，以及 Draft-OPD 这类 on-policy 方法的开源扩散，draft 的训练门槛会进一步降低。但无论工具多成熟，"draft 必须和你的真实业务分布对齐"这一点不会变，可观测的接受率永远是你最该盯的那根线。

参考素材与延伸阅读

• How Engineers Implement Speculative Decoding — AI Tutorial Maker，draft 取目标 5%~10%、draft length 4~8、接受率<50% 微调、大 batch 收益消失
• Draft-OPD: On-Policy Distillation for Speculative Decoding — 腾讯新闻，上交大+清华 EMNLP 2026，思考模型 5x 无损加速、较 EAGLE-3/DFlash +23%/+13%
• Draft-OPD Paper Summary and Mismatch Analysis — AlphaXiv，offline-to-inference mismatch 分析与摘要
• Roadmap to Mastering LLM Inference Optimization — World Programming，prefill/decode 两阶段、量化/稀疏/蒸馏分层路线图