投机解码与 MTP：为什么「猜测」是免费的

我在检查清单上看到"MTP round-trip"时，完全不知道这是什么意思。两个缩写词加一个连字符，显然重要到被人当成一个独立条目列了出来。

搞清楚它的含义把我带到了一个意想不到的地方。真正有趣的部分根本不是 MTP，而是投机解码之所以可行的根本原因——那是一个我之前理解反了的硬件事实。

生成文本很慢，因为它本质上是串行的：每生成一个 token 需要一次完整的 forward pass。

但处理五个 token 的 forward pass 和处理一个 token 的 forward pass 耗时大致相同。生成速度的瓶颈在于搬运权重，而不是计算本身。

投机解码正是利用了这一点：用一个廉价的组件 draft 出 k 个 token，大模型一次 forward pass 验证所有 token。

它是精确的，不是近似解。输出分布与普通解码完全一致。

MTP（Multi-Token Prediction，多 token 预测）是产生 draft 的方式之一——一个内置于模型本身的小模块。

MTP 有两条独立的生命线：训练时的辅助损失（用完即可丢弃），和推理时的 draft head（不能丢）。

为什么生成文本很慢

要生成第 N+1 个 token，模型需要第 N 个 token。这个顺序无法绕过——这就是"语言模型"的含义。

所以生成 100 个 token 意味着要跑 100 次完整的网络 forward pass。以 GLM-5.2 为例，那是 78 层，乘以 100。

显而易见的结论是：生成比读取 prompt 贵 100 倍。这个结论是错的，而且错的方式本身就是整篇文章的核心。

处理一个 token 的 forward pass 和处理五个 token 的 forward pass，墙钟时间大致相同。

我一直以为计算量随 token 数量线性增长。实际上不是，因为计算不是瓶颈。

每次 forward pass 都必须把模型的权重从内存读入计算单元。无论你处理一个 token 还是五十个 token，都有数百 GB 的数据在内存总线上传输。处理少量 token 的实际算术运算，在权重搬运成本面前只是舍入误差。

所以成本结构是这样的：

同样的 token，同样的算术，内存流量却多了五倍——纯粹是因为顺序依赖。

这个比例就是关键。如果你能在一次操作中处理五个 token，就能获得大约五倍的加速。但你做不到，因为 token 3 依赖于 token 2。

投机解码：先 draft，再验证

诀窍是把生成过程拆成两个角色。

某个廉价组件一次 draft 出 k 个 token。这些是猜测。

大模型对这 k 个位置做一次 forward pass，逐一检查每个猜测。

接受最长的正确前缀，丢弃其余的。

第二步就是全部关键所在，它依赖于一个容易忽略的特性：验证是并行的，尽管生成是串行的。

顺序依赖的存在是因为你不知道 token 3，除非已经生成了 token 2。但在验证阶段，你已经有了候选 token 1 到 k——drafter 已经把它们交出来了。所以你可以把它们全部铺开，在一次 forward pass 中检查。不需要再等任何东西。

如果连续猜对三个 token，你就用一次权重读取的代价生成了四个 token。如果第一个就猜错了，就退回生成一个 token——反正你本来也只能生成一个。

它是精确的，不是近似解

这是我以为有猫腻的部分，但实际上没有。

投机解码产生的输出分布与普通解码完全相同。它不是速度换质量的折中。最终输出中的每个 token 都是大模型本身认可的——drafter 的猜测只是建议，任何大模型不会做出的建议都会被拒绝。

接受测试的设计保证了幸存 token 的分布与大模型独立生成时完全一致。所以没有精度旋钮可调，也没有质量回退要监控。要么更快，要么不快。

唯一代价是差的 drafter 白费了 draft 工作。这意味着真正重要的指标是接受率：有多少比例的猜测存活下来。

Draft 从哪来

有几种方案，这正是 MTP 最终登场的地方。

独立模型方案最早出现，有一个尴尬的特性：两个模型独立训练，所以它们的想法不一定一致。当 drafter 的直觉与大模型背离时，接受率就会下降，而猜测不断被拒绝的 drafter 纯粹是开销。

这促使人们把 drafter 内置到模型里。

Multi-Token Prediction。GLM-5.2 的配置：

"num_hidden_layers": 78,
"num_nextn_predict_layers": 1

78 层主模型，加一个额外模块，负责预测下下个 token。那个模块就是 MTP。

两个特性让它成为一个优秀的 drafter：

它与主模型保持一致，因为它和主模型一起训练，坐落在相同的内部表示之上。它的猜测是主模型可能会做出的猜测，而这正是接受率所奖励的。使用相同设计的 DeepSeek-V3 报告，下一个 token 的接受率为 85–90%，端到端吞吐量约为 1.8 倍。

它很便宜，因为它复用了主模型已经计算好的隐藏状态。Draft 成本只是一层额外的计算，不是一个完整模型的 forward pass。

而且没有第二个 checkpoint 要版本管理、部署或保持同步。drafter 随模型一起交付。

MTP 有两条独立的生命线

这是一个我不仔细看就会搞错的区别。

在训练时，MTP 是一个辅助损失。强制模型预测两个 token 之后而非一个，推动它形成携带更多前瞻信息的表示，从而改进主模型。这样用的话，MTP 是可丢弃的——训练完成后可以扔掉这个模块，收益会保留。

在推理时，MTP 是 draft head。这样用的话，就必须保留它，否则就失去了加速。

同样的权重，两个不相关的关注理由。你是否需要 MTP 在流水线中存活，完全取决于你想要哪个。

回到检查清单

这终于解释了为什么"MTP round-trip"是独立的条目。

训练流水线会在格式之间转换模型：HuggingFace 转 Megatron 来训练，Megatron 再转回 HuggingFace 来服务。Round-trip 就是那个循环，问题是 MTP 模块能否完整地走出来。

它需要自己单独的检查的原因是：丢失它是静默的。MTP 不在主 forward 路径上——它不影响模型说什么，只影响说得有多快。所以：

转换完成，没有报错

Forward 一致性测试通过

训练运行，损失曲线正常

服务可用，吞吐量只有一半，日志里什么都没有

我看了流水线中引发这一切的验证脚本。第 5 步通过在相同输入上运行两个实现并比较输出来检查 HuggingFace 到 Megatron 的权重映射——cosine 0.9936，干净通过。它还包含这行：

if hasattr(hc, "num_nextn_predict_layers"): hc.num_nextn_predict_layers = 0

MTP 在测试中被关闭了。对于那个测试的目的来说这是正确的——它隔离了主干，这样不匹配就会指向特定位置。但这意味着验证过的映射对 MTP 没有任何说明，而且 forward 一致性检查本来也无法捕获这个遗漏，因为 MTP 不接触被比较的 forward 路径。

你真正想要的验证在性质上不同：不是"模型行为还正确吗"而是"每个权重都还在吗"。在转换前后枚举 tensor，比较名称和形状，并要求数值完全一致——格式转换不做算术，所以没有浮点误差的容许空间。更像是一次盘点，而不是一次测试。

我进来时以为 MTP 是主题、投机解码是背景。恰恰相反：投机解码是思想，MTP 是其中一个部件的一种实现。

不过真正值得带走的是底层的硬件事实。Forward pass 的成本几乎不取决于里面有多少 token。一旦理解了这个，投机解码就不再像巧妙的把戏，而开始显得理所当然——车里有四个空座，不如猜猜谁来。

它也跟我之前遇到的 vLLM 副本自动扩展问题异曲同工：直观的成本模型是错的，只有检查硬件实际在做什么才能发现。