llama.cpp 默认加载 MTP 张量，即便未启用推测解码也会占用额外显存

llama.cpp 近日的一项行为变更引发本地部署社区关注：最新构建版本会在加载 GGUF 时默认读取其中打包的 MTP（Multi-Token Prediction）张量，即便用户并未通过 --spec-type draft-mtp 显式开启推测解码，也会把这些张量一并装入显存与内存。受影响的模型包括 GLM-5.2、hy_v3、qwen35moe、step35 等采用 draft-mtp 架构的大模型。

行为变化：从「按需加载」到「默认加载」

在较早版本中，MTP/NextN 张量只有在用户显式启用推测解码时才会被加载；若未启用，相关张量会被直接跳过。这意味着此前默认状态下不会产生额外的显存与内存开销。但根据 llama.cpp 合并的 PR #25980，当前版本对所有 draft-mtp 架构的 GGUF 默认启用 MTP 张量加载，行为与是否使用推测解码无关。

对本地部署的实际影响

• 多一份张量开销：相当于每次加载时额外占用约一个 MoE 层的显存与内存，具体数值取决于模型规模。
• 大多数社区 GGUF 已默认打包 MTP 块：因此多数用户的本地推理都会受到这一变更影响，即使他们从未计划使用推测解码。
• 显存敏感场景需留意：在边缘设备或显存紧张的配置下，原本「能跑」的模型可能因此出现 OOM 或被迫降低上下文长度。

相关模型与后续建议

目前已知受影响的模型家族包括 GLM-5.2、hy_v3、qwen35moe、step35 等。如果用户当前无需使用 MTP 推测解码，可以关注 llama.cpp 后续是否提供关闭该默认行为的开关，或在加载前自行去除 GGUF 中的 MTP/NextN 张量以回收这部分显存。本次变更的具体讨论与 PR 细节可参见 llama.cpp GitHub 仓库的 PR #25980。