你让一个人续写句子。如果内容是熟悉的代码，他也许能一口气猜中后面十几个词；如果是拐弯很多的散文，猜得越远，改错的功夫反而越多。模型生成文本也有类似难题：一次多猜几个 token——也就是模型处理文字时使用的基本单位——可能加速，也可能白算。
llama.cpp 的 PR #27210 提议加入 adaptive MTP 模式，让服务器边生成边决定该猜多远。llama.cpp 是面向本地模型推理的工具；MTP（多 token 预测）则会一次猜测多个后续 token，再验证其中哪些可以采用。这个 PR 目前只是提交者公开邀请测试，材料没有表明它已经合并、发布或进入正式版本。下文的性能数字也全部来自提交者的自测陈述，尚无独立交叉验证。
不再固定猜三个
过去需要手工选择 MTP depth，也就是每轮向前猜测的深度。深度太浅，可能错过加速机会；太深，错误预测又会浪费计算。所谓推理吞吐，指单位时间内模型能处理或生成多少 token。吞吐提高，直观感受就是本地生成更快，但前提是额外猜测确实经常命中。
新 PR 的做法并不复杂。它使用一个计数式状态机——把程序分成若干状态，再按明确条件切换——根据近期运行情况动态调整 MTP 深度。可以把它理解成一名会看成绩改策略的速记员：连续猜得准，就试着多写几步；发现内容难预测，就收短步幅。提交者希望用户不用再反复琢磨最佳深度，把选择交给服务器。
推荐配置是 --spec-type draft-mtp-adaptive --spec-draft-n-max 12。按提交者说明，这会让深度在默认下限 3 与上限 12 之间变化；如果想修改下限，可以使用 --spec-draft-n-min-adaptive。
收益取决于文本好不好猜
提交者把它与固定 MTP=3 比较，而不是与关闭 MTP 的方案比较。在高密度、难预测文本以及普通散文上，自适应模式的典型表现约慢 3%；某些普通散文场景也可能平均更快，但适用边界没有说清。
代码看起来更适合动态加深预测。提交者称，普通代码生成通常快 10%—15%；回忆 thinking 阶段出现过的代码时，速度可能提高 50% 以上。如果模型只被要求修改几行，却恰好从记忆中重写整个文件，最高可能快 100%。后两项分别带有“可能超过”和“最高可达”的最佳情形色彩，尤其整文件重写属于特殊场景，不能当作日常收益。
回忆此前的散文内容时，提交者报告约 20%—30% 的提升。temperature——控制输出随机程度的采样参数——越高，后文越难预测，自适应模式相对固定 MTP=3 的优势就越小，不过其称代码生成通常仍会略有改善。
为什么值得关注
本刊 8 月 5 日曾报道 llama.cpp 为 Qwen3-Next 补上 MTP，并指出收益会随硬件变化。这次的新意不是再增加一种固定配置，而是把“该猜几步”变成运行中的自动决策。它直接碰到了本地推理最实际的权衡：既想提高吞吐，又不想为错误预测支付太多计算成本。即使最终增益并不普遍，减少用户手工试参数，本身也是清晰的工程方向。
局限与未知
- 所有结果都来自 PR 提交者的单一陈述，尚无独立复现。
- 材料没有披露硬件、模型、量化方式、上下文长度、采样参数、测试集、样本量、统计方法和原始结果，暂时无法判断数字能否推广。
- 普通散文“典型慢约 3%”与部分散文场景更快并非必然矛盾，但当前材料不足以划清两者边界。