Lesson 03 · 目标用时 25 分钟

MTP 如何成为 proposer

本节把训练目标、候选生成和正确性验证分开，再用一个可计算的速度模型回答：为什么“预测更多 token”不等于“推理一定更快”。

先预测

一个模型训练时加入 4-token MTP loss。推理时直接一次输出 4 个 head 的 argmax，不做 target verification。它是否自动等价于原模型逐 token 解码？

1. 三层概念不要折叠

MTP objective

训练时让同一位置的表示预测多个未来 token，增加监督密度，并可能促使表示提前规划。

Proposer / draft

推理时低成本产生一段候选及相应 qᵢ。它可以来自 MTP heads，也可以是独立小模型、EAGLE、n-gram 等。

Speculative decoder

让 target 一次评分候选，并执行 accept/correct。它保证 greedy 一致性或 stochastic 分布一致性。

一句话关系

MTP 可以让 proposer 又便宜又接近 target，从而提高接受率；但 MTP 本身不是 speculative decoding，也不负责无偏性证明。

2. 通用的并行-head MTP

Gloeckle et al. 的结构用共享 Transformer trunk 产生上下文表示 z≤t，再用 n 个独立输出 head 分别预测 xₜ₊₁ … xₜ₊ₙ：

L_n = − Σ_t Σ_i=1..n log P_θ(x_t+i | z_≤t)

Shared trunk读取真实 prefix，生成同一个上下文表示。

Head +1预测下一个 token。

Head +2从同一 prefix 表示预测第二个未来 token。

Head +3/+4继续预测更远位置。

这些 future heads 的预测共享已知 prefix，但后面的 head 并没有条件化在前面 head 实际生成的 token 上。因此，单独看各位置都可能很准，拼起来却未必是一条连贯的自回归路径。用于推理时，需要 blockwise verification 或 tree candidates 来筛出有效前缀。

该论文把额外 heads 用于 greedy self-speculative decoding：7B、4-token prediction model 在 code 上平均每次 forward 取回 3.50 个 token，报告相对速度 3.05×；这说明 MTP 能形成高质量 proposal，但数值是特定模型、数据和实现的实测结果，不是结构保证。

3. DeepSeek-V3 的顺序 MTP modules

DeepSeek-V3 没有采用“所有 future heads 只看同一个 trunk state”的并行结构，而是串接 D 个 MTP modules。第 k 个 module：

取得上一深度的表示 hᵢᵏ⁻¹；
拼接第 i+k 个 token 的 embedding；训练时它是真实 token，推理 draft 时对应前一深度产生的 token；
经过线性投影和一个 Transformer block，得到 hᵢᵏ；
用与主模型共享的 output head 预测再下一个 token。

h′_i^k = M_k[RMSNorm(h_i^k−1); RMSNorm(Emb(t_i+k))]

h^k = TRM_k(h′^k),　P_i^k+1 = OutHead(h_i^k)

这保留了完整 causal chain：更深的预测显式接收前一个未来 token，而不是从同一个静态 prefix 独立猜更远的位置。DeepSeek-V3 report 也明确说，MTP 的首要目的仍是改善主模型训练；推理时可以丢弃 modules，也可以把它们改作 speculative decoding。

维度	Gloeckle et al. 并行 heads	DeepSeek-V3 顺序 modules
未来位置之间	从共享 trunk state 独立预测	后一个深度接收前一深度状态与 token embedding
额外结构	每个 future position 有独立 head layers	每个深度有 projection + Transformer block，共享 embedding/output head
训练意图	提升训练质量，也支持 self-speculation	主要提升主模型质量，speculation 是可选复用
推理正确性	仍需 base/target verification	仍需 main/target verification

4. MTP 接入投机解码的数据流

prefix ── main model ──► target hidden state + p_1
                           │
                           └─ MTP module 1 ─► y_1, q_1
                                  │ Emb(y_1)
                                  ▼
                              MTP module 2 ─► y_2, q_2
                                  │
                                  ▼
                              ... y_γ, q_γ

prefix + [y_1 ... y_γ] ── target verification forward ──► p_1 ... p_(γ+1)
                                                          │
                                               accept / correct / commit KV

有的实现可以复用 main model 已经计算的第一组 logits 或 hidden state，有的会把 proposal 与 verification 调度成不同 worker step。读源码时不要被类名牵着走，只追四类对象：

对象	必须持有的信息	输出
Proposer	prefix state、draft/MTP state、sampling params	`y₁…yγ` 与实际使用的 `q₁…qγ`
Target scorer	prefix KV、candidate tokens、position/attention metadata	`p₁…pγ+1` 与候选路径上的临时状态
Sampler	候选 token、对应 `pᵢ/qᵢ`、随机数	accepted prefix length 与 correction/bonus token
State manager	accepted length、sequence/block tables	只提交真实路径的 token 与 KV，回收无效后缀

5. 理论 tokens/iteration

假设每个 draft token 的接受事件独立同分布，平均接受率为 α。第 1 个 token 一定产出；要产出第 2 个，需要第 1 个 draft 被接受；要产出第 k+1 个，需要前 k 个都被接受。因此：

E[tokens / iteration] = 1 + α + α² + … + α^γ = (1−α^γ+1)/(1−α)

当 α=1 时取极限，等于 γ+1。当 γ→∞ 时上界是 1/(1−α)：若 α=0.8，即使无限加长 draft，理想平均产出也只趋近 5。

6. 理想速度模型

令一次 target decode step 耗时为 T，一次 draft step 耗时为 cT。理想化假设 target 对 γ+1 个位置的并行验证仍耗时约 T，一轮成本就是 (1+γc)T：

speedup = (1−α^γ+1) / ((1−α)(1+γc))

平均接受率 α = draft 长度 γ = draft/target 成本比 c =

期望 token/轮

理想加速比

候选槽位利用率

Speedup

上限 5x

练习：固定 α=0.6,c=0.1，逐步增加 γ。你会看到更长的 draft 很快停止带来收益，随后因 draft 成本继续累积而变慢。

7. 现实中为什么低于公式

把 target verification 相对单 token decode 的成本记为 v(γ,B,L)，再加入调度、采样和状态管理开销 o，更诚实的估算是：

practical speedup ≈ E[tokens/iteration] / (v(γ,B,L) + γc + o)

变量	为什么会恶化	你应测什么
`v`	候选越长，attention、activation、logits 和 kernel 工作量越大；大 batch 时 target 本来就 compute-bound	verify forward latency / baseline decode latency
`c`	独立 draft model 太大、跨设备通信，或 MTP modules 太深	每 proposal token 的端到端成本，不只看参数量
`α`	高温度、开放域难 token、draft/target tokenizer 或 sampling processor 不一致	按位置的 acceptance curve，而不只看整体平均值
`o`	动态 batch 重排、概率张量搬运、rejection sampling、KV truncate/recompute	非模型 kernel、CPU 调度和同步时间

吞吐与延迟不是同一结论

投机解码最自然地改善低 batch、memory-bound decode 的单请求延迟。高并发时，baseline 已能用 batch 填满 GPU；额外 draft 与 verification FLOPs 可能降低总吞吐。任何“x 倍加速”都必须同时给出 batch、序列长度、采样参数、硬件和指标定义。

8. 读论文与源码时的判断顺序

q 从哪里来？ 独立模型、并行 heads、顺序 modules、隐藏层退出，还是检索/n-gram？
候选是否构成真实 causal chain？ 若不是，是否用 tree attention 或 blockwise verification？
验证保存什么语义？ greedy 完全一致，还是 stochastic 分布严格一致，或只是近似阈值？
qᵢ 是否真的是产生 yᵢ 时的分布？ sampling processor、temperature 和概率张量是否对应？
首拒后的状态如何处理？ token、position、KV block 和 RNG 状态是否只提交有效前缀？
速度报告由谁贡献？ 接受率、draft 成本、verify 成本还是 batching 策略？

收尾检索

一个 MTP proposer 的 token acceptance 达到 90%，是否足以断言系统一定加速？

本节压缩

MTP 是训练目标/候选结构；speculative decoder 才执行 target verification 与分布修正。
通用 MTP heads 可从同一 prefix 并行预测多个未来位置；DeepSeek-V3 用顺序 modules 保留 token 间因果链。
理想每轮 token 数是 Σₖ₌₀ᵞ αᵏ，收益随 draft 长度递减。
真实速度由 acceptance、draft cost、verification inflation、batching 和状态管理共同决定。

主阅读

先读 Gloeckle et al., Section 2 与 3.2，再读 DeepSeek-V3 Technical Report, Section 2.2，逐项对照“并行 heads”和“顺序 modules”。之后只看本页的六步源码检查表，尝试解释一个你熟悉的 vLLM speculative backend；不确定的映射可以继续问我。