你让本地 AI 写一段话，它通常要一个词元接一个词元地往外吐。词元（token）是模型处理文字的基本单位，可能是一个字、一个词或词的一部分。前一个没生成，后一个就得等着。MTP——Multi-Token Prediction，多词元预测——试图改变这种排队方式：一次计算先猜后续多个词元，再由推理工具利用这些候选结果，减少逐词等待。
现在，ggml-org/llama.cpp 的 Pull Request #29761 提交了为 Qwen4Exp 增加 MTP 支持的方案。llama.cpp 是广泛使用的本地大模型推理项目，能借助量化等办法，让普通电脑运行大模型。若这条路径最终稳定落地，Qwen 新结构的 MTP 才有机会真正用于本地解码加速。
需要先说清信源边界：目前材料全部来自同一个 GitHub PR 及其讨论，没有 Qwen 官方公告、独立测试或完整性能报告。材料也不足以确认“17 小时完成合并”以及正式发布状态，因此本文不把这两点写成事实。
不是模型有能力就够了
MTP 可以理解成让模型一次交出几张“下一步草稿”，但 llama.cpp 还得知道怎样读取、安排和验证这些草稿。新模型结构只有获得正确的模型加载、计算图和算子支持，才可能在本地设备上运行。算子就是程序执行模型计算时使用的具体数学操作。
PR 讨论显示，这次方案沿用了早期 Qwen 模型的接入方式。维护者认为，相比此前的 PR #28243，这是一条更合适的实现路线。我们在 9 月 18 日曾报道，llama.cpp 正在为 Qwen 的实验结构补充 hyperconnection 等支持，当时同样无法确认改动是否合并。此次 MTP 提案延续的是同一条工具链建设：先让底层框架理解新结构，再谈真实速度。
快起来之前，先处理几处摩擦
这次接入不只是加一个开关。讨论中，Qwen4Exp 的 MTP 使用 llama-hybrid-idx。参与者提出，如果没有正确利用 sparse attention——稀疏注意力，即只选择部分信息参与计算——长上下文下可能出现性能下降。这是讨论中的技术判断，并非已经得到系统测试的结论。
模型文件也有兼容问题。GGUF 是 llama.cpp 常用的模型文件格式。当 MTP head——负责给出多词元候选的附加预测部分——作为独立 GGUF 加载时，它不会共享 tok_embd，也就是把词元转换成模型内部表示的嵌入参数。一名测试者因此遇到 token_embd.weight 缺失错误。作者判断，现有模型可能需要重新量化；量化是用更低精度保存模型，以减少内存和计算开销。讨论同时表明，跨不同 GGUF 共享这部分参数的方式目前不受支持。
还有一处更底层的问题。MTP 的草稿上下文可能经过层过滤后不剩任何层，于是 recurrent memory——模型在连续计算中保留的循环记忆区——会变成空模块。相关修改会在这种情况下停用 rollback snapshots，也就是用于回退计算状态的快照，避免程序对不存在的记忆执行回滚。
为什么仍值得关注
它的意义不在于已经证明“快了多少”，而在于本地推理工具开始接住模型侧提供的多词元预测能力。模型能同时猜多个词元，只是准备好了多张草稿；llama.cpp 还要负责加载附加结构、管理记忆，并让它适应长上下文和不同硬件。PR #29761 把这些实际接口问题摆到了同一条实现路径上。
这也是 llama.cpp 一贯路线的延续：把原本依赖专门环境的新模型能力，逐步塞进个人设备可用的工具链。但眼下更准确的说法是“新的加速路径正在接入”，而不是“一键提速已经完成”。
局限与未知
- 现有材料没有可靠说明 PR 的最终合并与发布状态，也无法验证“17 小时完成合并”。
- 没有统一基准测试，无法判断吞吐量、MTP 候选接受率或实际加速倍数。
- 长上下文降速、重新量化需求及显存问题主要来自单个 PR 的讨论和早期测试，尚不能视为普遍结论。