MTP 完全拆解：多 token 预测如何让 DeepSeek 自带草稿模型

输入组合：两条信息拼成一条#

对于第 $i$ 个输入 token $t_i$、第 $k$ 个预测深度，模块的输入由两部分拼接而成：第 $i$ 个 token 在第 $k-1$ 个深度的表示 $\mathbf{h}_i^{k-1} \in \mathbb{R}^d$，以及第 $i+k$ 个 token 的 embedding $\operatorname{Emb}(t_{i+k}) \in \mathbb{R}^d$。两者先各自过 RMSNorm，再拼接后经线性投影：

其中 $[\cdot;\cdot]$ 表示沿特征维拼接，$M_k$ 把 $2d$ 维压回 $d$ 维。特别地，当 $k=1$ 时，$\mathbf{h}_i^{k-1}$ 就是主模型最后一层给出的表示——第一个 MTP 模块直接吃主模型的输出。

这条公式值得逐项解释，因为每个部件都有它的”为什么”：

• 为什么要用第 $i+k$ 个 token 的 embedding？ 因为第 $k$ 个深度的任务是预测第 $i+k+1$ 个 token，而 $t_{i+k}$ 是它前面紧挨着的那个 token——预测”下一个”之前，先让模块”看到”上一个真值 token 的信息。注意这里用的是真值 token（训练时是 ground-truth，这叫 teacher forcing）：第 $k$ 个深度的预测链完全建立在真实历史上，而不是建立在第 $k-1$ 个深度自己的猜测上。这正是论文强调的”在每个预测深度都保持完整因果链”（complete causal chain）的含义——从任何深度往前看，路径都是确定且正确的。
• 为什么拼接两路而不是只给 embedding？ 预测 $t_{i+k+1}$ 只靠 $t_{i+k}$ 的 embedding 是不够的——那就退化成 bigram 语言模型了。$\mathbf{h}_i^{k-1}$ 携带了模型对第 $i$ 个位置全部上下文的理解（这个表示在主模型的第 $k-1$ 层深度上已经过完整推理），拼接后模块同时拥有”当前位置的深层语义”和”紧邻的未来 token 信息”，两者结合才能做出高质量预测。注意位置关系：$\mathbf{h}_i$ 属于位置 $i$，而 $\operatorname{Emb}(t_{i+k})$ 属于位置 $i+k$，两者相差 $k$ 个位置——这 $k$ 步的跨度正是用 $M_k$ 这条”捷径”补上的。
• 为什么要 RMSNorm？ 两条输入来自不同空间（一个是深层表示，一个是浅层 embedding），量纲和分布差异很大。RMSNorm 先把两者各自归一化到相同尺度，再拼接，避免投影矩阵被某一侧的数值主导。这也是 DeepSeek 全系架构的标准做法（MLA、DeepSeekMoE 都用 RMSNorm）。
• 为什么 $M_k$ 的形状是 $d \times 2d$？ 输入拼接后是 $2d$ 维，输出要恢复成 Transformer block 期望的 $d$ 维输入，所以投影矩阵必须是 $d \times 2d$。这是这个模块唯一”新增”的参数（与 Gloeckle 的独立输出头不同，$M_k$ 很小，参数量为 $2d^2$，对 671B 模型可以忽略不计）。

经过 Transformer block 与共享输出头#

组合后的 $\mathbf{h}_i^{\prime k}$ 送入第 $k$ 个深度的 Transformer block，得到该深度的输出表示：

其中 $T$ 是输入序列长度，$i:j$ 表示切片操作（左右边界都包含）。序列长度从 $T$ 减到 $T-k$，是因为第 $i+k$ 个 token 的 embedding 最多取到 $t_{T}$，所以 $i$ 最大只能到 $T-k$——序列末尾的 $k$ 个位置没有足够的”未来 token”可用。

最后，把 $\mathbf{h}_i^{k}$ 交给共享输出头，得到第 $k$ 个额外预测 token 的概率分布 $P_{i+k+1}^{k} \in \mathbb{R}^{V}$（$V$ 是词表大小）：

输出头就是主模型的 unembedding 层：线性映射到 logits 后接 softmax。注意索引：第 $k$ 个模块用位置 $i$ 的表示预测位置 $i+k+1$ 的 token，偏移恰好是 $k+1$。整个结构串起来就是：主干 → 投影 + 拼接 → 一层 Transformer → 共享输出头 → 第 $k+1$ 个未来 token 的分布。

设计决策：为什么是”顺序模块”而不是”并行头”#

把 DeepSeek-V3 的 MTP 与 Gloeckle 的并行多头、EAGLE 的基于特征的草稿放在一起对比，能看清 DeepSeek 每一步选择的理由：

关键区别在两点：

1. 顺序性。第 $k$ 个模块的输入包含第 $i+k$ 个 token 的信息，而第 $i+k$ 个 token 正是前 $k$ 个模块”负责”的位置——这保证了每个深度的预测都建立在确定的前缀上。推理时若把 MTP 模块当草稿器，草稿 token 也是按这个因果链逐个产生的，这正是投机解码的要求。
2. 共享 embedding 与输出头。论文里明确说每个模块的 embedding 层和输出头都与主模型共享。embedding 共享意味着 MTP 模块直接消费主模型的输入表示空间；输出头共享意味着它的预测落在与主模型完全相同的输出分布空间。这样设计一是省参数（D 个模块只多出 D 个 Transformer block 和 D 个投影矩阵），二是让 MTP 的预测分布天然靠近主模型——后者对推理时的接受率至关重要，后面会看到。

参数开销具体有多少？DeepSeek-V3 发布版配置了 D=1，即 1 个 MTP 模块（对应模型配置文件里的 num_nextn_predict_layers: 1）。模块主体是一个与主模型同构的 Transformer block（约一层 MoE 的体量），加上投影矩阵，总共约 14B 参数，相对 671B 主模型只增加约 2%——这是 V3-0324 检查点 685B 总参数与 V3 671B 之差的来源（Hugging Face 讨论、NVIDIA Megatron-LM 文档）。相比之下，一个独立的草稿模型动辄几十亿参数且分布与主模型有 gap，MTP 用 2% 的参数代价换来了一个”分布几乎一致”的草稿器。

MTP 训练目标：给主模型加一份稠密监督#

训练时，每个深度各自算一个交叉熵损失。第 $k$ 个深度的损失是：

其中 $t_i$ 是第 $i$ 个位置的真值 token，$P_i^{k}[t_i]$ 是第 $k$ 个 MTP 模块给出的、$t_i$ 被预测到的概率。这本质上是把”预测第 $i+k+1$ 个 token”的交叉熵在序列上取平均——注意下标从 $2+k$ 开始，与前面序列切片的原因一致（前 $k+1$ 个位置没有足够未来上下文）。

总损失是各深度损失的均值再乘一个权重系数 $\lambda$：

DeepSeek-V3 中 $\lambda$ 取 0.1（Megatron-LM 的 MTP 实现文档确认了这一取值）。$\lambda$ 调得小的原因很实际：MTP 只是辅助目标，不能喧宾夺主地干扰主模型的 next-token 学习。训练效果上，论文报告 MTP 让模型在标准基准上普遍受益（尤其在数学与代码任务上），代价是约 3% 的训练时间增加——训练侧的效果本文点到为止，不再展开。

论文原话：推理时两用#

论文在 “MTP in Inference” 一段里写得很直白：

我们的 MTP 策略主要目的是提升主模型的性能，因此推理时可以直接丢弃 MTP 模块，主模型照常独立工作。此外，我们也可以把这些 MTP 模块重新用于投机解码，进一步改善生成延迟。

这句话点明了 MTP 的双重身份：训练时它是给主模型”加课”的辅助目标，推理时它是不需要额外训练就存在的草稿模型。V3 发布时 DeepSeek 没有公开 MTP 权重（投机解码只停留在官方内部），到 V3.2-Exp 才把这条推理路径正式开放并推广。下面推导它到底怎么加速、能加速多少。

草稿-验证-接受的三段式流程#

自投机解码与经典投机解码的流程骨架完全一样，区别只在草稿从哪来：

1. 草稿阶段（draft）：主模型输出第 $t$ 个 token 后，把它的最后一层 hidden state $\mathbf{h}_t$ 送入第 1 个 MTP 模块，结合刚生成 token 的 embedding，预测出草稿 token $\hat{t}_{t+1}$；然后把这个草稿 token 的 embedding 传给第 2 个深度（或同一模块的下一轮），预测 $\hat{t}_{t+2}$……如此自回归地跑 $\gamma$ 步。注意此时 MTP 模块里”下一 token 的 embedding”不再是真值，而是上一轮自己预测出来的草稿 token——训练时的 teacher forcing 在推理时换成了自回归，因果链仍然保持。
2. 验证阶段（verify）：把 $\gamma$ 个草稿 token 拼在当前序列后面，主模型做一次完整的并行前向，得到每个位置的真实预测分布。这次前向同时算出了 $\gamma+1$ 个位置的结果（包括真正的第 $t+1$ 个 token），成本与普通解码一步相同。
3. 接受阶段（accept）：从第 $t+1$ 个位置开始，逐个比较草稿与主模型预测：一致就接受（贪婪模式下直接接受，采样模式下按拒绝采样规则接受），直到第一个不一致的位置为止，其后的草稿全部丢弃，下一轮从这个”分歧点”重新开始草稿。

因为验证一步并行覆盖了 $\gamma+1$ 个位置，而主模型每步只算一次前向，所以平均每个主模型前向产出的 token 数从 1 变成了 $>1$，解码速度随之提升。

加速比的推导：接受率与草稿成本#

设草稿长度 $\gamma$、每个草稿位置被接受的概率（接受率）为 $\alpha$，主模型一次前向的成本记为 1，草稿阶段每个 token 的成本记为 $\beta$（$\beta \ll 1$，原因见下）。

期望产出 token 数：一轮中至少接受 1 个的概率是 1，至少接受 2 个的概率是 $\alpha$，至少接受 3 个是 $\alpha^2$……至少接受 $\gamma+1$ 个是 $\alpha^{\gamma}$（$\gamma$ 个草稿全部通过，额外还赚到第 $\gamma+1$ 个验证位置）。期望产出：

期望成本：$\gamma$ 步草稿 + 1 次验证，即 $\gamma \beta + 1$。

加速比：

这个公式是理解一切投机解码（包括 MTP）的钥匙，值得记下来。两个极端情况验证一下：$\alpha=0$（草稿全错）时 $S = 1/(1+\gamma\beta) < 1$，白白多花了草稿成本；$\alpha \to 1$ 时 $S \to (\gamma+1)/(1+\gamma\beta) \approx \gamma+1$，主模型每步白赚 $\gamma+1$ 个 token。

MTP 的成本优势：为什么 $\beta$ 小、$\alpha$ 高#

现在把 MTP 的自投机场景代入这两个量：

草稿成本 $\beta$：草稿阶段每步只跑 MTP 模块——一个 Transformer block + 共享输出头。主模型有 61 层，而 MTP 模块是主干之外的一个额外 block（V3 配置下只有 1 个模块，D=1），所以单步草稿的计算量约为主模型完整前向的 $1/61 \approx 1.6\%$，加上输出头投影，$\beta \approx 0.02$。相比之下，经典投机解码的草稿模型即使小一个数量级（如 1.5B 对 13B），$\beta$ 也在 0.1 左右；对 MoE 大模型，独立草稿模型与主模型之间的参数量差距往往更小，$\beta$ 很难压下来。MTP 把 $\beta$ 压到了接近极限——草稿器与验证器共享了几乎全部权重。

接受率 $\alpha$：草稿质量决定接受率。MTP 的草稿来自主模型自己的表示空间：第 1 个 MTP 模块直接吃主模型最后一层 hidden state，而主模型的最后一层表示恰恰是最接近”正确下一个 token 分布”的特征（EAGLE 系列工作的核心洞察也是这个：用主模型的隐藏状态预测草稿，接受率远高于独立小模型）。V3 的 MTP-1（$\gamma=1$）在部署中实测接受率约 85%–90%（AI Wiki 对多 token 预测的整理；xLLM 文档 同样引用这一数据）。

代入公式看 V3 的 MTP-1：$\alpha = 0.87, \gamma = 1, \beta = 0.02$：

与多个独立来源报告的”DeepSeek-V3 上 MTP 带来约 1.8 倍生成吞吐加速”（AI Wiki、xLLM 文档、SegmentFault 解读）严丝合缝。模型预测得越准（$\alpha$ 越高），收益越大——$\alpha=0.9$ 时 MTP-1 加速约 1.9 倍，$\alpha=0.95$ 时约 1.95 倍。

为什么 V3 生产环境只用 MTP-1（$\gamma=1$）而不是更长的草稿？ 公式揭示了一个微妙权衡：$\gamma$ 越大，每轮期望产出 $E$ 越高（$S$ 的分子变大），但 (1) 草稿成本 $\gamma\beta$ 线性上升，(2) 更关键的是，第 $k$ 个草稿位置的接受率会随 $k$ 衰减——预测距离越远越难。MTP-1 只预测紧邻的下一个 token，接受率 85–90%；如果强推 MTP-3，第三个位置的接受率会显著下降，且高并发下验证阶段的 batch 增大、内存带宽压力上升，总吞吐可能不升反降。这也是为什么 TensorRT-LLM 的 DeepSeek-V3.2 优化博客 建议延迟敏感场景用 MTP-3、其余场景 MTP-1 通常已够用——低延迟（batch 小）时草稿成本占比低、收益显著；高吞吐（batch 大）时草稿与验证的带宽竞争加剧，MTP-1 更稳。

DeepSeek-V3.2-Exp：官方正式开放自投机解码#

2025 年 9 月 29 日发布的 DeepSeek-V3.2-Exp（官方技术文档，与 DeepSeek-V3.2-Exp 模型卡）有两件大事：一是把 DeepSeek Sparse Attention（DSA，稀疏注意力，本站 NSA 系列 已拆解过它的 kernel 与工程落地）做成了正式特性；二是把 MTP 自投机解码作为官方推荐的推理加速路径开放出来——MTP 模块的权重随模型发布，vLLM、SGLang 等框架用 method: "deepseek_mtp" 即可开启。官方同时将长上下文推理成本大幅下调（公开报道称 API 成本下降超过 50%），其中自投机解码与 DSA 各贡献了一部分。

图：DeepSeek-V3.2-Exp 论文 Figure 1——DSA 实例化在 MLA 之上，绿色部分展示了 indexer 如何为 query 选出 top-k 键值条目（图片来源：DeepSeek-V3.2-Exp 官方文档）

V3.2 里 MTP 与 DSA 的配合方式值得一提：MTP 草稿阶段会产生 $\gamma$ 个额外的 query token，这些草稿 token 在验证时是作为同一个 query 组（query group）一次性进入注意力计算的——DSA 的 indexer 可以为整个 query 组共享一次 top-k 选择，草稿 token 无需重新计算选择结果。后续的 PIVOT 论文（query 组索引的 token 级稀疏注意力）直接确认：生产环境中的 DeepSeek-V3.2 正是以 MTP 深度 3（d=3，即 4 个 query 一组） 部署的，稀疏注意力与自投机解码是”买一送一”的关系——草稿 token 天然构成 query 组，几乎零额外成本。

框架适配：一个 kernel 层面的硬约束#

MTP 从论文到生产，真正的工程难点不在算法而在 kernel。V3.2 的 DSA 解码依赖一个 MQA（Multi-Query Attention）风格的 indexer kernel，而这个 kernel 最初只支持序列长度 1 或 2——也就是只能处理 MTP-off 或 MTP-1。要让 MTP-3 跑起来，TensorRT-LLM 的解决方案（PR-9045） 是把序列维展平（flatten）到 batch 维：把 4 个 query token 当成 4 个 batch 项喂给 kernel，序列长度恒为 1。这个 trick 有个副作用：flatten 后 kernel 会忽略因果掩码（对角线区域的遮盖），但随后 top-k 选择阶段会重新正确地施加因果掩码，所以最终选出的 top-k 索引不受影响。vLLM 的 PR #36982 走了另一条路：当 MTP=1 时直接利用 indexer 的原生支持，不再 flatten。而 DeepSeek 自己的 DeepGEMM 库则在 commit 2be3f36 中给稀疏 MLA kernel 加上了原生 MTP-3 支持——从”绕过限制”到”消除限制”，这是生态走向成熟的过程。

实测数据：各框架的 MTP 加速#

• SGLang（NextN，PR #3582）：首个在 SGLang 中支持 DeepSeek-V3/R1 NextN（即 MTP）投机解码的 PR，把 nextn 层导出为草稿模型单独加载。实测 R1 在 2 节点 8×H20 上：batch=1 时吞吐从 17 提升到 52 token/s（约 3 倍），batch=30 时从 160 提升到 500 token/s（约 3.1 倍）。
• 百度百舸 × SGLang（开源生产级 MTP 代码）：2025 年 10 月开源了为 V3.2 DSA 架构深度定制的 MTP 推理实现（SGLang PR #11652），因为 DSA 改变了 KV 管理方式，旧版 MTP 代码无法直接复用。实测 V3.2 解码吞吐提升超过 2 倍，并且经过了大规模生产环境验证（InfoQ 报道）。
• TensorRT-LLM（Blackwell 优化博客）：在 B200/GB200 上验证 MTP-1/MTP-3 的配置组合，配合 FP8 稀疏 MLA 优化，报告了最高约 47% 的吞吐提升；再次印证”延迟敏感用 MTP-3，其他场景 MTP-1”的经验法则。
• xLLM（MTP 文档）：支持把 DeepSeek-V3/V3.2/R1 的 MTP 层导出为 sidecar 草稿权重。实测（ShareGPT 输入 2500 / 输出 1500 token）：并发 1 时平均 TPOT 从 40.61ms 降到 28.33ms（约 -30%），输出吞吐从 24.20 提升到 35.19 token/s；并发 4 时输出吞吐从 79.83 提升到 111.18 token/s。
• llama.cpp（PR #22673）：2026 年 5 月合入 MTP 支持，RTX 3090 上跑 Qwen3.6 27B 实测从 38 提到 65 token/s（约 1.7 倍）。这件事的意义不在数字本身，而在于 MTP 从”671B 数据中心的专属特权”变成了消费级单卡也能用的通用机制——任何训练过 MTP 头的模型都能直接受益。

局限与边界#

把 MTP 自投机解码放进真实服务，有三个必须知道的边界：

1. 高并发下收益缩水甚至为负。SGLang PR #3582 的评论区有一个真实案例：2 节点 8×H800 上跑 V3，高负载时 MTP 投机解码反而慢于普通解码（18.91 vs 30.02 token/s）。原因前面推导过：草稿成本 $\gamma\beta$ 在高并发时不再是”免费”的——草稿 token 与验证 token 争抢同一批 GPU 的算力和带宽，batch 越大，验证阶段本身已经接近带宽饱和，多跑的草稿就是纯开销。投机解码类方法本质上是”用计算换串行步数”，在带宽受限的稠密场景下这笔交易尤其划算，在算力饱和的场景下就要打问号。
2. 草稿长度是静态的，接受率是动态的。MTP-1/3 的 $\gamma$ 在部署时写死，但实际接受率随 prompt 难度、生成阶段剧烈波动——简单续写时 $\alpha$ 接近 0.95，长程推理时可能掉到 0.6 以下。静态 $\gamma$ 要么保守（MTP-1，错过高接受率时的收益），要么激进（MTP-3，接受率低时白跑）。本站写过的 DSpark（置信度调度验证）正是冲着这个缺陷去的：它用外部半自回归草稿模型 + 逐 token 置信度调度，在 V4 上相对 MTP-1 基线再拿 60–85% 的每用户生成加速——这也侧面说明 MTP-1 是 2026 年 DeepSeek 生产栈的事实基线。
3. 显存与权重管理成本。MTP 模块虽然只占 2% 参数量，但 14B 权重依然要常驻显存（或至少与主模型同机加载）。对显存捉襟见肘的部署（比如单卡跑 27B 的 llama.cpp 场景），开 MTP 意味着要预留额外空间，用户需要在”更快”与”更省”之间做选择。