Speculative Decoding 与 MTP：先猜多个 token，再让大模型一次验完

1. 为什么一次验证多个 token 可能比逐个生成快

普通 AR decode 每步只输入一个新 token，却要遍历 target 的每一层，读取大量权重和历史 KV。在 batch 较小、模型很大时，GPU 算力没有吃满，延迟常由 HBM 读取和跨卡 collective 主导。若把 4 个候选 token 一起送进 target，GEMM 的 token 维变宽，权重仍只需在这一轮被利用，硬件并行度更高。

target 参数没有减少，验证也没有省略。候选后缀中的每个位置仍经过完整 target，只是把 4 次窄 decode 合并成 1 次宽 verify。它用更多并行计算换取更少的串行轮次；当大 batch 已让 target 饱和，额外候选只会增加 FLOPs、KV 和通信，甚至使执行变慢。

2. Draft-Target 主循环：提出、验证、接受、修正

设已经提交的前缀为 x1...xt。drafter 按自己的分布 q 生成 K 个候选 y1...yK。target 在带因果 mask 的一次前向里，计算每个候选位置对应的 target 分布 p1...pK，以及候选全通过时可用的 bonus 分布。

候选必须按顺序接受：若 y2 被拒绝，y3 是在错误的 y2 条件下生成的，不能单独保留。一次 cycle 至少产生一个 target-correct token；若多个 draft 被接受，就一次推进多个位置。

3. 概率正确性：为什么拒绝后不能直接重采 target

单个位置上，drafter 分布为 q(v)，target 分布为 p(v)。先从 q 采候选 v，以 min(1,p(v)/q(v)) 接受。若拒绝，不是再从完整 p 采样，而是从 target 相对 drafter 的剩余质量中采样：

证明可以直接核算最终输出 v 的概率。接受路径贡献 q(v)×accept(v)=min(p(v),q(v))；拒绝路径贡献 Z×residual(v)=max(0,p(v)-q(v))。两项相加恰好为 p(v)。对序列逐位置应用同一条件论证，就保持 target 的完整生成分布。

若拒绝后又从完整 p 采一次，drafter 已覆盖的概率质量会被重复计数，最终分布就会偏移。2023 speculative sampling 论文除了并行打分，还依赖这一步 residual distribution 修正。

4. Greedy、随机采样和 relaxed acceptance 必须分开

temperature=0 的 greedy 场景可逐位置比较候选是否等于 target argmax；第一次不等就使用 target token。随机采样必须使用上述概率接受和 residual distribution，且 p、q 应在约定的 temperature、top-p/top-k 变换之后一致计算。不同 tokenizer 或词表映射还需要额外校正。

“只要候选位于 target top-k 就接受”“logprob 差不大就接受”等 relaxed 规则可以提高接受率，却不再保证 target 原分布。TensorRT-LLM 文档中的 reasoning relaxed acceptance 就明确提供 relaxed_topk 与 relaxed_delta 开关。它可以是合理的质量-延迟选择，但评测必须标为 lossy。

即使算法严格，浮点归约、batch 形状、并行拓扑与随机数消费顺序也可能使逐 token 输出不与单请求 baseline 逐字一致。应验证分布或 logprob 容差，而不是把固定 seed 下的字节完全相等误当作唯一正确性标准。

5. 接受率：它本质上是两个分布的重叠

最优拒绝采样的单位置期望接受率是 p 与 q 的重叠，也等于 1 减 total variation distance。交叉熵或 KL 能让 drafter 接近 target，却不直接等价于最大化有限容量 drafter 的接受率。2026 的 LK Losses 和 Bebop 因此直接优化 TV/接受目标。

需要同时报告三种指标：draft token acceptance rate 是所有候选中通过的比例；acceptance length 是每个 cycle 连续通过的 draft 数；mean emitted length 还会计入每轮至少产生的 correction/bonus token。不同论文对“accepted length”是否包含 bonus 的约定不总相同，不能只拿一个数字横向比较。

6. 后缀衰减：第 1 个候选准，不代表第 7 个也值得验

第 i 个候选只有在前 i-1 个全部接受时才有机会提交。令条件接受率为 alpha_i，一次 cycle 的期望输出 token 数近似为：

例如每位条件接受率都为 0.8，K=4 时期望输出约 1+0.8+0.64+0.512+0.4096=3.3616，不是 4.2。真实 drafter 的后缀通常更差，因为后续 token 依赖尚未验证的自生成 token。DSpark 2026 专门处理这种 suffix decay，用轻量顺序模块补充块内依赖，并按预测的 prefix survival probability 动态裁剪验证长度。

7. 速度模型：接受得多仍可能不赚钱

令单步 target AR 延迟为 T1，draft K 个候选耗时 Tdraft，target 宽验证耗时 Tverify(K)，调度与采样为 Toverhead。单用户近似加速为：

假设四个位置的条件接受率依次 0.9、0.8、0.7、0.6，期望输出为 1+0.9+0.72+0.504+0.3024=3.4264。若 draft 0.4ms、verify 1.3ms、调度 0.15ms，而 AR 每 token 1ms，加速约 1.85×；若高 batch 下 verify 升到 2.9ms，则几乎没有收益。这个示意说明调参必须把接受率与实际 kernel 时间放在一起。

临界点随 prompt 长度、batch、硬件、量化、目标模型和输出域变化。代码常有高可预测后缀，创作或高温采样可能重叠更低；长 prompt 会增加每个候选的 attention 成本；MoE 验证还会改变 expert 访问与通信。

8. Drafter 家族：小模型、查表、特征头与块生成

“MTP”是模型训练/架构能力，“speculative decoding”是带 target verification 的生成算法。模型可以用 MTP loss 提升表征却不在部署时启用 speculation；也可用完全独立小模型做 speculative decoding。两者不能互换。

9. MTP 架构：预测多个未来位置不等于一次平行吐出多个 token

典型 MTP 在主干的 next-token loss 之外，增加预测 t+2、t+3... 的目标。DeepSeek-V3 的公开结构把当前 token embedding 与主干 hidden state 分别归一化、拼接投影，再经过一个额外 transformer block 和共享 LM head；官方开放权重包含 1 个 MTP module。

这类 MTP 常以轻量模块顺序滚动 K 步，省的是每步运行完整 target，而不是完全消除 AR 依赖。并行多 head 可以一次预测 K 位，但缺少候选之间的条件依赖。2026 的 DFlash 用 block diffusion 一次生成候选块；DSpark 用 parallel backbone 加轻量 sequential module，在并行度和后缀质量之间折中。

10. Drafter 训练：KL、TV 和端到端接受目标

标准训练用真实未来 token 做交叉熵，或让 drafter logits 蒸馏 target logits。它们优化 token 准确或 KL，但有限容量下不保证最大化 sum min(p,q)。LK Losses 直接围绕 acceptance/TV 设计目标，在 8B 到 685B target、四类 drafter 上报告平均 acceptance length 提升最高约 8%-10%。

Bebop 研究 RL rollout 时 target 熵变化导致 MTP 接受率下降，使用概率 rejection sampling 与端到端 TV loss。论文报告接受率最高 95%、额外 inference throughput 最高 25%，异步 RL 端到端最高 1.8×。这些都是各自实验上限，不是所有域的默认值。

训练数据必须覆盖部署中的 chat template、代码、工具调用、reasoning mode 和 temperature。只在通用文本蒸馏的 drafter，可能在 JSON、长 CoT 或 agent trajectory 上迅速失配；target 每次后训练更新也可能使 drafter 过期。

11. KV cache：稳定前缀、draft 分支和 target 临时页

独立 draft-target 至少维护两套状态：target KV 保存已提交前缀；drafter KV 保存同一逻辑前缀并在 draft 阶段顺序扩展。target verify 为 K 个候选分配临时 KV 页，一次计算它们的 K/V 和 logits。找到首个 rejection 后，只提交有效前缀对应页，拒绝位置之后的页回收到 allocator。

修正 token 的 KV 是否已在本轮形成，取决于 verify kernel 的输入/输出对齐；runtime 必须显式记录“已产生 logits”和“已写入该 token KV”的边界，不能只改 sequence length。树式候选还会产生多分支 block table 与 tree attention mask，最终只提交一条路径。

取消、超时、prefix cache 命中与 page eviction 都要同时处理 target 和 draft 状态。若只回收 target 临时页，drafter 页会泄漏显存；若输出已经流出但 KV 尚未提交，异常发生后流式响应又会与内部状态不一致。

12. KV Sharing 不是通用接口：每个模型共享的对象不同

独立小模型维度和层数不同，通常不能复用 target KV，只能各自 prefill。Gemma 4 Assistant 官方 Transformers 文档称其整个 drafter 使用 KV sharing：复用 target 已填充的 KV，从而跳过 drafter prefill；assistant 不更新该 cache，使用常量 position id，并把 token embedding 与 target hidden state 拼接作为输入。

GLM-5.2 的官方说明是 MTP 多步之间共享第一个 MTP step 的 KV 和 top-k sparse-attention indices，且不同 MTP steps 共享参数。这个机制只覆盖其特定状态，不能推出所有 target 层 KV 都能零成本交给任意 draft 模型。DeepSeek-V3 的 MTP module 共享 embedding 与 output head，并依赖主干 hidden state；实现仍需遵循对应框架的 EAGLE/MTP state layout。

13. Continuous batching：每个请求处在不同状态机阶段

普通 decode scheduler 每轮给每个活跃请求一个 token slot。speculative scheduler 要处理 DRAFT → VERIFY → COMMIT：不同请求的 K、实际接受长度和 tree 宽度不同；有的请求在 draft，有的等待 verify，有的新请求还在 prefill。调度预算应按候选 token 和临时 KV 页，而不是只按请求数。

verify batch 通常按候选长度 bucket，减少 padding，并为常见 batch×K 组合捕获 CUDA Graph。SGLang 的 DeepSeek 文档提醒：大于 48 的 MTP batch 需要同步调大 max-running-requests 和 CUDA graph batch 列表。这项限制来自 runtime 预捕获与资源配置，不属于模型理论。

动态关闭 speculation 很重要：在 target 已满载、K 后缀存活概率低或 drafter 排队时，AR 可能更优。策略应依据在线的 acceptance-by-position、draft latency、verify latency 和 queue depth，而不是固定用一个全局 K。

14. MoE 验证：被拒绝的 token 也做了 expert 计算和通信

Dense target 宽验证主要增加 GEMM 的 token 维；MoE target 中，每个候选还会路由到若干 experts。候选越多，一轮触及的 expert 集合可能越大，grouped GEMM、HBM 权重读取和 expert-parallel all-to-all payload 都增加。最终被拒绝的后缀也已支付这些成本。

Gemma 4 官方 MTP 文档专门指出：26B A4B 的不同 token 可能激活不同 experts，batch 1 时缺少 expert 重用，在不擅长并行的平台上 drafter 未必带来加速；batch 增大后，序列间 expert 重叠可能改善复用。它说明接受率相同也不能从 dense 模型外推 MoE speedup。

DeepSeek 类大 MoE 还叠加 MLA/稀疏 attention、TP、EP 与 data-parallel attention。verify 宽度改变每 rank 的 token 数与 all-to-all 分布；调优必须同时观察 expert load imbalance、all-to-all 时间、MLA query 长度和被拒绝 token 比例。

15. 多 GPU 通信：候选 token 很小，隐藏状态和 collective 很大

候选 token id 从 drafter 发给 target 的字节很少，主要成本来自 target 每层的 TP all-reduce、EP all-to-all，以及某些 MTP 设计需要传递的 hidden feature。drafter 与 target 共卡时，feature 可留在设备但会多占 HBM；放到独立 GPU 后可以并行执行，却要维护远端状态与请求一致性。

SPECTRE 把多租户系统中低利用率的 tail-model 服务作为远端 drafter，使用 ordinary/parallel 混合策略、优先调度与 prompt compression 保持重叠。在 Qwen3-235B-A22B TP=8 等实验中报告相对 AR 最高 2.28×，相对最强 speculative baseline 最高再提升 66%。这依赖数据中心已有闲置小模型资源，不等同于单机白送的加速。

16. 2026 模型状态表：GLM-5.2、Gemma 4 与 DeepSeek

17. GLM-5.2：让长上下文 MTP 少算 index 与 KV

GLM-5.2 官方文章把 MTP 目标写得很直接：降低 draft model 成本，同时提高 acceptance。模型对 sparse attention 使用 IndexShare，每四个主干层共享一个 indexer；在多步 MTP 中只在第一步建立 index，后续步骤复用 top-k indices，并在训练/推理中共享第一 MTP step 的 KV，step 参数也共享。

官方 ablation 固定 7 个 MTP steps，在 GLM-5.1 backbone 和训练数据上，coding acceptance length 从 baseline 4.56，经 IndexShare+KV Share 到 5.10，再加 rejection sampling 到 5.29，最终端到端 TV loss 到 5.47，即提升 20%。这个数字说明系统共享和训练目标同时影响收益，不能只增加 K。

1M context 还改变成本中心：官方明确说架构降低 per-token FLOPs，却没有等比例降低 per-token KV 大小。因此长上下文 speculative serving 要同时考虑 prefix KV 容量、cache transfer、CPU scheduler 与宽验证；MTP 不会解决 prompt prefill。

18. Gemma 4：专用 Assistant 与 MoE 反例

Google 官方 MTP 文档把 Gemma 4 assistant 定义为 target 专用组件。它共享 target input embedding，读取 target 最后一层 activation，与 token embedding 拼接、降维后生成候选；E2B/E4B 还用 token cluster 选择候选簇，避免每步做完整词表投影。因此不能把它当作独立通用聊天模型使用。

官方 QAT collection 为各规格提供 assistant checkpoint；vLLM 要将它识别为 method=mtp，不是 generic draft model。一个最小服务形态如下，版本与模型名仍应以当日官方文档为准：

vllm serve google/gemma-4-E4B-it \
  --speculative-config \
  '{"method":"mtp","model":"google/gemma-4-E4B-it-assistant","num_speculative_tokens":4}'

部署前分别测 dense E4B、dense 12B/31B 和 MoE 26B A4B。官方已经提示 MoE batch 1 可能没有收益，因此不能把某个 dense checkpoint 的 2× 结果当成全系列结论。

19. DeepSeek：从 V3 开放 MTP 到 V4 生产负载

DeepSeek-V3 官方仓库给出 671B 主模型和约 14B MTP 部分；权重文档进一步说明 MTP 有 11.5B unique 参数，另共享约 0.9B embedding 与 0.9B output head，开放配置为 1 个 MTP module。SGLang 当前文档在 H200 TP8 上报告 batch 1 约 1.8×、batch 32 约 1.5×，默认搜索起点是 3 steps、topk 1、4 draft tokens。

python3 -m sglang.launch_server \
  --model-path deepseek-ai/DeepSeek-V3-0324 \
  --speculative-algorithm EAGLE \
  --trust-remote-code \
  --tp 8

DeepSeek 官方 2026 发布页确认 V4-Pro 为 1.6T total/49B active，V4-Flash 为 284B/13B active，二者均为 1M context；官方推理代码公开 MTPBlock。DSpark 则由 DeepSeek 作者团队报告其在 V4 live traffic 部署：相对生产 MTP-1 baseline，在 matched throughput 下 per-user generation speed 提升 60%-85%。

需要保留证据层级：模型规模和开放权重来自官方模型卡；DSpark 的线上收益来自论文；完整线上 admission、K 分布、硬件和流量细节并未全部开放。因此本文不把 60%-85% 写成用户自行部署 V4 的可保证结果。

20. 2026 系统研究：重点从“更准的 draft”转向“少浪费 verify”

这些最大值使用的 target、硬件、batch、采样、数据集和计时边界并不相同。较稳妥的共同做法是预测各后缀位置的存活概率，按 target 当前饱和度调整 verify 宽度，并让 draft 与 target 重叠执行，而非一味拉长候选块。

21. 生产部署蓝图：让 speculation 成为可回退优化

策略层先检查 tokenizer、sampling 参数、assistant 版本与 target revision 是否匹配；不匹配就回退 AR。资源层为 drafter 权重和临时 KV 设置硬上限，防止 speculation 挤掉正常并发。执行层在 GPU 上融合 acceptance/residual sampling，避免每 cycle CPU 同步；commit 后才对外流式发送 token。

多 replica 集群应分别自动调 K：低 batch 延迟池可用较长 draft，高吞吐池可能只用 1-2 token 或完全关闭。remote drafter 必须携带 request epoch、prefix length、model revision 和 cancellation token，防止迟到候选写入已回滚的 target 请求。

22. 服务测量：接受率只是仪表盘的一行

vLLM 当前指标可由 accepted/draft counters 计算 draft acceptance rate，并可按位置统计；mean acceptance length 通常用每次 draft 的 accepted 数再加每轮 bonus/correction 约定。生产至少同时记录：

同时报告 target-only baseline，固定 target revision、prompt 集、temperature/top-p、输出长度、并发、硬件和 P/D/TP/EP 配置。单请求 tok/s 不能代表在线吞吐；平均 acceptance 也会掩盖长尾域、后缀位置和高并发退化。

23. 常见失败模式与边界

assistant 与 target tokenizer/revision 不一致会降低接受或直接错位；LoRA 改变 target 分布却未更新 drafter；structured output mask 只施加在一侧会破坏正确性；重复惩罚、presence penalty 和 tool grammar 若不在 p/q 两边一致执行，也会改变接受概率。

实现层常见错误包括 temporary KV 未回滚、tree mask 越界、CUDA Graph 不覆盖实际 batch×K、RNG 在拒绝路径多消费、流式输出早于 commit，以及 remote draft 的迟到响应。MoE 上还会出现接受率很好但 all-to-all 变差、触及 experts 增多而吞吐下降。

speculative decoding 只加速输出 decode；不减少长 prompt prefill，也不能解决模型权重首次加载。短输出、超高并发、强随机采样或 drafter 失配时，关闭它往往更合理。

24. 最小复现实验：先证明无损，再寻找盈亏点

1. 用 target-only 与 speculative 两条路径跑相同 prompt；greedy 检查序列，sampling 比较 token logprob/分布与统计容差。
2. 固定 K=1、2、4、7，记录每位置条件接受率、draft/verify/commit 时间和 temporary KV 峰值。
3. 扫描 batch 1、8、32、64，观察何时 target 宽验证饱和，并验证自动 fallback 是否优于固定开启。
4. 按聊天、代码、数学、工具调用、长上下文分桶，避免高重复代码掩盖其他域的低接受率。
5. 多卡分别记录 TP/EP collective；对 MoE 比较 touched experts、expert load 和 rejected-token communication。
6. 做取消、超时、OOM、drafter 崩溃、版本不匹配和 cache eviction 注入，确认能无损回退 AR。

最终画两条 Pareto 曲线：单用户 inter-token latency 对并发，以及 completed tokens/s 对 P99。离线接受率提高只是中间指标；只有曲线在目标流量下整体外移，MTP 才带来实际服务收益。

25. 一手来源