Eval bug: NextN/MTP tensors now load by default for existing GGUFs, no load-time opt-out (regression from #25980)

快速结论：该报错发生在升级 llama.cpp 后，旧有的 GLM-5.2（GLM_DSA）等包含 NextN/MTP 张量（如 blk.78）的 GGUF 模型开始默认加载这些张量，即使没有指定 --spec-type draft-mtp，导致显存/内存占用上升，在接近上限时触发 cudaMalloc 失败或 OOM。优先排查方向：确认当前 llama.cpp 版本是否引入了 #25980 的加载行为回归，并关注是否已合入后续修复 PR（如 #26296）。

适用环境：llama.cpp（版本 10183，commit 3018a11e7，GNU 15.3.0 编译）；Linux x86_64；CUDA 后端；模型为 GLM-5.2（GLM_DSA），可能同时影响 hy_v3、qwen35moe、step35。

最快修复方案：暂无确认的一步修复方案。Issue 讨论中提出了修复 PR（#26296），但需测试验证；在修复合入前，可优先尝试在转换时使用 --no-mtp 重新转换模型（代价大），或用脚本从本地 GGUF 中剥离 MTP 张量，但均非官方推荐的一劳永逸方案。

注意事项：以上“剥离张量”方法来自社区用户的自制 Python 脚本，并非 llama.cpp 官方支持；重新转换需要重新下载原始权重、重新量化并重新分发，成本很高。修复 PR（#26296）是为 GLM_DSA 准备的，是否同样覆盖 hy_v3/qwen35moe/step35 尚未在 Issue 中确认。

问题场景

用户在 Linux 下使用 llama.cpp（版本 10183）通过 CUDA 后端加载 GLM-5.2（GLM_DSA）模型的 GGUF 文件。升级 llama.cpp 后，使用与之前完全相同的命令行和模型文件，显存/内存占用却明显增加，接近显存上限时直接出现分配失败。问题源于 PR #25980 改变了 GLM_DSA 的加载逻辑：只要 GGUF 中存在 NextN/MTP 张量（例如 blk.78），就会默认加载，而不再像旧版本那样只有在请求投机解码时才加载。即使没有传入 --spec-type draft-mtp，这些张量也会被载入。

报错原文

Eval bug: NextN/MTP tensors now load by default for existing GGUFs, no load-time opt-out (regression from #25980)
failed: out of memory

原因分析

可能原因：#25980 合入时已明确标注这是一个有意的行为变更——NextN/MTP 张量从“从不加载”变为“存在即加载”。这个改动照顾了默认使用 MTP 的用户，但破坏了原有 GGUF 的向后兼容性：同一个文件、同一条命令行，升级后多加载了 blk.78 等张量，导致 VRAM/RAM 占用上升。对于 744B 级别的 MoE 量化模型，这种额外开销可能直接触顶，引发 cudaMalloc 失败。类似的存在性探测逻辑据称也影响了 hy_v3、qwen35moe、step35，因此不一定限于 GLM_DSA。

环境排查

llama.cpp 版本：确认是否处于 10183（3018a11e7）或包含 #25980 的版本范围内。
操作系统：Linux x86_64；GGML 后端为 CUDA。
显卡：任何型号均可能触发，关键是显存/内存余量是否吃紧。
模型：GLM-5.2（GLM_DSA）；也需排查 hy_v3、qwen35moe、step35 是否同样受影响。
检查启动命令中是否包含 --spec-type draft-mtp：若未指定，仍会加载 MTP 张量，说明触发了本回归。
确认 GGUF 文件中是否包含 blk.78 或对应架构的 NextN 张量。

解决步骤

先确认问题根源：用旧版 llama.cpp（#25980 之前）加载同一 GGUF，对比显存/内存占用；或检查日志中是否加载了 blk.78 等 MTP/NextN 张量。
关注修复 PR #26296（可优先尝试）：如果该 PR 已合入目标版本，请升级到包含该修复的 llama.cpp 版本，并用同样的命令重新测试 GLM_DSA 模型。
临时缓解：如果暂时无法升级，可自行用 Python 脚本从 GGUF 中剥离 MTP/NextN 张量后再加载，以恢复原有显存占用。注意：这是社区用户验证过的做法，但并非官方方案，操作前请备份原文件。
终极方案（成本最高）：在转换时使用 --no-mtp 重新转换模型。但对于 744B 级别模型，需要重新下载源权重、重新量化并重新分发，不是理想选择。
如果模型文件是公开分享的，建议等待官方的运行时开关（例如 --no-mtp / --skip-mtp）合入后再决定是否重新发布，避免反复分发大文件。

验证方法

用同一模型文件和同一条启动命令（不包含 --spec-type draft-mtp），对比修复前后的显存/内存占用：升级到修复版本后，加载时应不再读取 NextN/MTP 张量，原有配置下可以正常加载并运行，不再出现 cudaMalloc 失败或 OOM。若使用剥离脚本，可通过日志或 nvidia-smi 确认额外张量未加载且推理结果正常。