Eval bug: Nemotron 3.5 Bolt 74B-A9B segfaults on Metal in ggml_metal_op_mul_mat_id

快速结论：在 Apple Silicon 上通过 Metal 运行 Nemotron 3.5 Bolt 74B-A9B（IQ2_XXS）时，只要发出第一个对话请求、进入 prompt processing，进程就可能在该路径崩溃，报错为 Eval bug: Nemotron 3.5 Bolt 74B-A9B segfaults on Metal in ggml_metal_op_mul_mat_id。优先排查 Metal 的 mul_mm_id map0 kernel 覆盖了哪些 top-k（ne20）值——Bolt 的 n_expert_used = 9 当前没有对应的 kernel 实例。

适用环境：llama.cpp 0.7.0-dev（build 11669，commit 620d2225c，含 #30520），macOS 27.0（26A428），Apple Metal 后端，Apple M1 Max 32 GB（32 核 GPU，GPU family 7），模型为 unsloth/NVIDIA-Nemotron-3.5-Bolt-74B-A9B-GGUF 的 official-IQ2_XXS.gguf。评论中另有 M3 Ultra（96 GB、f12aaa3）与 M5 Max 的确认结果。

最快修复方案：在 mul_mm.metal 中 map0 的 ne20 模板实例列表里，紧挨其他实例增加一个 <9> 实例化，然后重新编译；M1 Max、M3 Ultra、M5 Max 均已确认可修复崩溃。仅转换 NVFP4 张量为 Q8_0 可解决随后出现的 decode 慢速问题，但不能替代该 Metal kernel 修复。

注意事项：<9> 修复已在上述硬件上验证，但尚未合并为官方改动，自行修改需留意后续源码变更。文档给出的 NVFP4→Q8_0 重写脚本属于用户侧 workaround（文件 22.0→24.2 GB，最差转换误差 0.41%），并非修复崩溃本身；另有人建议让 supports_op 对未实例化的 ne20 回退而非崩溃，属于推测建议，未验证。

问题场景

用户在 Apple Silicon Mac 上用源码编译的 llama.cpp 0.7.0-dev 启动 llama serve，加载 NVIDIA-Nemotron-3.5-Bolt-74B-A9B-official-IQ2_XXS.gguf（纯文本、无 mmproj，启用 –jinja、-ngl 99、-fa on），模型本身能正常加载。随后向 /v1/chat/completions 发送任意约 150 token 的用户提示，服务端在 prompt processing 阶段崩溃。单 token 解码走 mul_mv_id 路径，不经过 map0，所以只在批量预填充时触发。

报错原文

Eval bug: Nemotron 3.5 Bolt 74B-A9B segfaults on Metal in ggml_metal_op_mul_mat_id

EXC_BAD_ACCESS, SIGSEGV, KERN_INVALID_ADDRESS at 0x0
libggml-metal.0.27.0.dylib   ggml_metal_pipeline_max_theads_per_threadgroup
libggml-metal.0.27.0.dylib   ggml_metal_op_mul_mat_id
libggml-metal.0.27.0.dylib   ggml_metal_op_encode
libggml-metal.0.27.0.dylib   __ggml_metal_set_n_cb_block_invoke
libggml-metal.0.27.0.dylib   ggml_metal_graph_compute
libggml-base.0.27.0.dylib    ggml_backend_sched_graph_compute_async
libllama.0.7.0.dylib         llama_context::graph_compute(ggml_cgraph*, bool)
libllama.0.7.0.dylib         llama_context::process_ubatch(...)
libllama.0.7.0.dylib         llama_context::decode(llama_batch_ext const&)
libllama-server-impl.dylib   server_context_impl::decode(int&, int)
libllama-server-impl.dylib   server_context_impl::update_slots()

原因分析

Bolt 每个 token 路由到 9 个专家（n_expert_used = 9），但 Metal 的 mul_mm_id map0 kernel 只针对 ne20 ∈ {1, 2, 4, 5, 6, 8, 10, 16, 22} 做了实例化。ggml_metal_library_get_pipeline_mul_mm_id_map0() 去查 kernel_mul_mm_id_map0_ne20_9，该 kernel 不存在，于是返回空 pipeline，紧接着在 ggml_metal_pipeline_max_theads_per_threadgroup() 中解引用空指针，与崩溃堆栈一致。每层专家数量不同（240/304/368/432/496）以及 IQ2_XXS/NVFP4 数据类型都不是触发条件，任何量化的 Bolt 都应能复现；Nemotron 3.5 Super 是 top-22，已有对应 kernel。

崩溃修好后，使用 NVIDIA 官方 24GB GGUF 的用户还会遇到第二个问题：decode 仅约 6 t/s。可能原因是其中 80 个 Mamba 的 ssm_in/ssm_out 投影以 NVFP4 存放，而 ggml_metal_supports_mul_mat_op 对 GGML_TYPE_NVFP4 返回 false，这些矩阵乘在每个 token 上都回退到 CPU。该慢速问题已由用户明确归因为缺少原生 Metal NVFP4 支持，但官方层面尚无修复。

环境排查

确认 llama.cpp 版本与构建：0.7.0-dev build 11669 / commit 620d2225c，是否包含 #30520；评论中的验证基于 f12aaa3。
确认系统为 macOS 27.0（26A428）、芯片为 Apple Silicon（如 M1 Max），以及 GPU 是否走 Metal 后端。
确认所用模型为 Bolt 且 n_expert_used = 9；可用 Nemotron 3.5 Super（top-22）对照，后者已有 kernel。
关注后续出现的 decode 速度：若 6 t/s 左右，检查模型文件中 ssm_in/ssm_out 是否为 NVFP4 类型。
Issue 未提供 Python、CUDA/PyTorch 版本信息，无需据此排查。

解决步骤

在 mul_mm.metal 的 map0 ne20 实例列表中，参照 #18667 为 ne20=5 添加实例的做法，增加一行 <9> 实例化。
按原方式重新编译（cmake -B build -DCMAKE_BUILD_TYPE=Release 后构建），用同一条 llama serve 命令加载 Bolt IQ2_XXS。
重新发送 /v1/chat/completions 请求，确认不再崩溃并正常返回回答。
如修复崩溃后 decode 仅约 6 t/s：可优先尝试仅将 NVFP4 张量转换为 Q8_0 重写模型文件，其余 QAT IQ2_XXS、Q8_0 与 F32 .scale 张量按字节原样复制；脚本需以 PYTHONPATH=llama.cpp/gguf-py 运行 gguf-py 脚本（原帖附完整示例脚本）。
如希望避免同类崩溃，可优先尝试让 map0 getter 或 supports_op 在遇到未实例化的 ne20 时拒绝并回退，而非返回空 pipeline；这是推断性建议，尚未在硬件上验证。

验证方法

用与复现时相同的模型、启动参数和 ~150 token 提示请求服务端，服务端应能完成 prompt processing 并正常输出回答，不再出现 EXC_BAD_ACCESS/SIGSEGV 堆栈。对慢速 workaround，可在 M3 Ultra 上用 llama-bench -fa 1 -r 3 对比：原 24GB NVFP4 文件 pp2048 247.8、tg128 6.40；转换为 Q8_0 后 pp2048 604.8、tg128 37.74、d32768 下 tg128 35.97，且需确认工具调用、JSON schema、代码任务等检查项与原文件表现一致。