Speculative decoding：为什么 MTP 和外部 draft 不是一回事

在 speculative decoding 里，重点不只是更快。真正的重点是弄清楚工作最终落在什么地方：落在模型内部，还是落在你必须集成的系统里。

如果你要把它用进产品里，MTP 和 DRAFT 不是同一件事的两个名字。它们追求的是同一个目标——在不牺牲最终模型质量的前提下更快地产生文本——但它们把复杂度放在了流水线的不同位置。

实际来看：

• 用 MTP 时，推测路径被集成在模型内部
• 用 外部 draft 时，推测路径来自两个模型之间的协作

我觉得最有用的表述是：MTP 是集成式 speculative decoding，外部 draft 是组装式 speculative decoding。这不是一个绝对定义，而是一个操作层面的区分。它帮助我们理解复杂度到底住在哪里、由谁承担，以及把模型带进真实系统的团队还需要承担多少额外工作。

为什么会有 speculative decoding

Speculative decoding 源于一个很简单的问题：大模型很强，但延迟成本高。每一个 token 都需要计算，而这些计算会不断累积。

它的核心思路很优雅：先用一条更快的路径提前提出一些 token，再让更强的模型去验证它们。如果提议站得住，就能节省时间；如果站不住，系统就回到主路径，同时不损害最终回答的质量。

MTP 和 DRAFT 处在同一个概念空间里。真正的差异只体现在一个问题上：到底是谁提前提出这些 token，这条推测路径又是如何构建出来的？

MTP：当加速能力在模型内部

MTP 指的是 Multi-Token Prediction。从实际意义上说，它描述的是那些已经在自身结构里内建了提前预测多个 token 机制的模型。

把它称为集成式 speculative decoding 是合理的，因为这种加速并不是从外部把两个独立模型拼起来得到的：它本来就被打包进了模型设计本身。

这会带来很大变化。从架构角度看，推测行为是模型设计的一部分；从运营角度看，一大块复杂度在模型交到使用团队手里之前就已经被解决掉了。

所以，MTP 真正的承诺不只是"更快"，而是更少的故障面。

外部 draft：当加速必须被组装出来

使用外部 draft 时，推测系统来自至少两个独立组件之间的协作：一个主模型（target）和一个更小、更快的模型（draft）。draft 提出一些 token，target 去验证它们。如果提议一致，系统就加速；如果不一致，target 就修正轨迹。

这个思路很有力量，而且在某些场景下比 MTP 更有意思。但它不可避免地是一个组装出来的系统：加速并不只住在单个模型里，而是住在模型与模型之间的关系里。

这会改变工作的重心。你不只是选一个模型，而是在设计一种耦合。你要验证兼容性、推理引擎是否支持、格式是否一致、draft 成本与真实吞吐收益之间是否平衡，以及更细一点的问题，比如 tokenizer 和服务器在负载下的行为。

外部 draft 要求的不只是一个模型决策，而是一个系统决策。

复杂度到底住在哪里

使用 MTP 时，复杂度通常更偏上游：它在模型里，在那些设计、训练和优化模型的人所做的工作里。

使用 DRAFT 时，复杂度会更靠近采用这套方案的团队。哪怕概念本身很直观，集成过程也未必如此。你更容易发现自己在验证一些侧面的细节：功能是否真的被支持、target 和 draft 的组合是否正确、那些在纸面上存在但在真实流水线里会缩水的收益。

如果要把它浓缩成一句话：MTP 把问题推得更上游；DRAFT 则把问题留在更靠近下游的位置。

灵活性 versus 运营可靠性

外部 draft 的优势很明显：你可以选择不同的组合。更强的 target、更轻的 draft、针对特定预算或特定基础设施做出的特定折中。对于做研究或者维护高度定制技术栈的团队来说，这种灵活性很有价值。

但灵活性不是免费的。每多一个自由度，也就多一种不兼容、低效率或额外维护成本的可能。

MTP 放弃了一部分这种可组合性，换来的是一个更封闭但也更清晰的方案。你不能随意重新拼装一切，但也正因为如此，系统发生退化的节点更少。对很多团队来说，尤其是纯研究之外的团队，这不是损失，而是明确的优势。

为什么 MTP 在采用时往往更占优势

如果目标是可靠地使用 speculative decoding——而不是证明你能在底层编排一个推测系统——那么 MTP 几乎总是更占优势。

我刻意使用这种更谨慎的表达，因为确实存在外部 draft 才是正确道路的场景。但在大多数面向产品、可重复基准测试或具体落地的场景里，MTP 会减少那些消耗时间和注意力的附带决策。

关键不在于哪种方案在纸面上看起来更优雅。关键在于：团队的时间最终花在了哪里？

如果时间最后都花在集成、维护模型间关系、验证兼容性和诊断性能波动上，那么灵活性的理论优势就可能蒸发掉。只要支持足够好，MTP 会更好地保护团队的专注力：让团队把精力放在用例本身、真实基准、感知延迟和运营成本上。

什么时候我仍然会选择外部 draft

外部 draft 不是次一级方案。它是要求更高的方案。

当灵活性不是偶发优势，而是问题的结构性组成部分时，我会选择它：

• 当你需要精细控制 target 成本和 draft 成本之间的关系
• 当团队运行在高度定制的平台上
• 当首要目标是研究，而不是标准化
• 当基础设施本来就是为了试验不同模型组合而搭建的

在这些情况下，外部 draft 不再是令人不快的复杂度来源，而会成为真正的设计空间。选择它，意味着你是主动想要这种复杂度，而不是被迫承受它。

结论

MTP 和 DRAFT 不是两个包装不同的同义词。它们是两种架构选择。

前者把加速能力集成进模型；后者把加速能力构建在模型之间的关系里。前者往往会简化采用过程；后者往往会增加自由度，但也会增加集成负担。

如果要用一句话概括：MTP 是更即用型的 speculative decoding；DRAFT 是更可组合的形式。

在真实系统里，尤其当团队时间和性能同样重要时，这个差异的分量远比表面看起来要大。