gpt-oss:20b (MXFP4) deterministic llama-server abort in CUDA ADD_ID on a short two-message /api/chat (0.32.13 and 0.33.3)

快速结论：在 NVIDIA RTX 4000 Ada（cc 8.9）上用 Ollama 运行 gpt-oss:20b（MXFP4）时，短的两条消息（system + user）/api/chat 请求会触发 CUDA 图计算中的 ADD_ID failed 断言并导致 llama-server 崩溃（core dumped），HTTP 返回 500；优先排查是否命中了 MXFP4 张量进入只接受 F32 的 ADD_ID kernel 的图路径，以及容器/GPU 是否有累积状态。

适用环境：Rocky Linux 10.2（kernel 6.12.0-211.54.1.el10_2.x86_64）；NVIDIA RTX 4000 Ada (24 GB)，驱动 610.57.04；Ollama 0.32.13 与 0.33.3（均使用容器 ollama/ollama 镜像，且使用自带的 cuda_v13 runner）；模型 gpt-oss:20b，MXFP4 量化，20.9B 参数。

最快修复方案：暂无确认的一步修复方案。Issue 中维护者未能在 CPU、AMD 8060s、NVIDIA GB10 上复现，也未见官方修复合并；发帖者给出的是源码级定位（ADD_ID 缺少反量化 shim）与“重启容器临时恢复”的观测，二者均未在合入版本中验证。

注意事项：该崩溃在 Issue 讨论者复测中表现为间歇性、与状态相关：同一二进制、同一模型、同一 GPU 在容器重启后 80+ 次请求无崩溃，说明可能需要累积的 GPU 显存/CUDA 图缓存/KV 缓存状态才会触发。仅重启容器不是根治手段。ADD_ID 只接受 F32 输入、MXFP4 张量经 MoE 路由（MUL_MAT_ID → ADD_ID）进入该 kernel 的说法来自社区分析，非官方修复说明，属于可能原因。

问题场景

用户在 Docker（ollama/ollama:0.32.13，部分场景下亦为 0.33.3）中运行 gpt-oss:20b（MXFP4，13 GB），GPU 为 RTX 4000 Ada。请求是一个很短的两条消息 /api/chat 调用：一条 system 消息（普通英文，无特殊字符）加一条 user 消息，prompt 约 460 tokens / 约 1 KB，远低于任何上下文上限，且使用默认请求参数。此时 llama-server 在 CUDA 图计算阶段（不是加载或 checkpoint 阶段）确定性 abort。

Issue 给出的最小复现矩阵显示关键变量是 system 消息是否存在：

有 system + temperature 0 / seed 144 / num_ctx 8192 / num_predict 512 → 500，abort
有 system + 默认参数 → 500，abort
无 system + harness 参数 → 200
无 system + 默认参数 → 200

报错原文

ggml_cuda_compute_forward: ADD_ID failed
  current device: 0, in function ggml_cuda_compute_forward at
  .../ggml/src/ggml-cuda/ggml-cuda.cu:2417
ggml_abort(...)
/usr/lib/ollama/libggml-base.so.0(ggml_abort+0x11e)
/usr/lib/ollama/cuda_v13/libggml-cuda.so(+...)        # ggml_cuda_op_mul / graph_compute
libllama.so.0: llama_context::graph_compute -> decode
ollama llama-server: "llama-server terminated" error="signal: aborted (core dumped)"

原因分析

最直接的证据是崩溃点位于 ggml-cuda/add-id.cu 的 ggml_cuda_op_add_id，其断言为：

GGML_ASSERT(src0->type == GGML_TYPE_F32);
GGML_ASSERT(src1->type == GGML_TYPE_F32);

社区分析认为 ADD_ID 只接受 F32 输入；当 gpt-oss:20b 以 MXFP4 量化时，经 MoE 路由路径（MUL_MAT_ID → ADD_ID，或经 mul_mat_id_bias_glu_ops 融合）进入 ADD_ID 的中间张量类型是 MXFP4 而非 F32，断言触发后调用 ggml_abort 并 core dump。这属于可能原因，Issue 中未给出官方确认的根因结论。

关于“为什么两条消息会崩、一条不会”：推测单条消息的 decode 太短，图没有触发 MoE expert routing；加上 system 消息后上下文增长，走到 MUL_MAT_ID + ADD_ID（expert combination）路径，MXFP4 张量才命中仅支持 F32 的 kernel。这也属于推测。

关于“为什么维护者复现不了”：维护者测试的是 CPU（无 CUDA ADD_ID 路径）、AMD 8060s（无 CUDA）、或 GB10（图执行顺序/量化可能不同）。触发条件可能需要 MXFP4 + RTX 4000 Ada（cc 8.9）这一特定组合。

此外，讨论者指出该 backtrace 与 #17534 不同——#17534 崩在 context-checkpoint 创建，本 Issue 崩在图计算内的 ADD_ID，但触发形态（短 gpt-oss:20b chat 上确定性 abort）相近。

环境排查

确认 GPU 型号与计算能力：是否 NVIDIA RTX 4000 Ada 或其他 Ada Lovelace（cc 8.9）。
确认 NVIDIA 驱动版本：Issue 中为 610.57.04。
确认 Ollama 版本：0.32.13 与 0.33.3 均有复现记录，且使用容器自带 cuda_v13 runner。
确认运行方式：是否为容器 ollama/ollama 镜像，是否与模型 volume 同源。
确认模型：ollama list gpt-oss:20b，Issue 中输出为 ID 17052f91a42e、13 GB、MXFP4。
确认触发请求是否包含 system 消息，以及是否使用了 OpenAI 兼容端点 /v1/chat/completions 与流式输出。
确认容器/GPU 已运行时长、是否有崩溃历史（讨论者观测到崩溃发生在容器启动约 24 小时后，需累积状态）。

解决步骤

Issue 中没有经维护者验证的官方修复。以下为基于讨论证据可优先尝试的排查/规避动作：

查看服务端日志确认崩溃特征，日志排查方式参考 Ollama troubleshooting 文档；重点匹配 ggml_cuda_compute_forward: ADD_ID failed 与 llama-server terminated: signal: aborted (core dumped)。
确认复现请求：用 Issue 中的 payload.json 通过 curl http://127.0.0.1:11434/api/chat 发送，stream=false；若单次未崩溃，按讨论者建议在容器不重启的情况下循环发送 10+ 次，观察是否在若干次成功后才出现崩溃。
尝试去掉 system 消息对比：Issue 中确认无 system 消息时同一请求返回 200，可用于判断是否命中该触发路径。
作为临时规避，重启 Ollama 容器/服务：讨论者在 2026-09-19 02:05 UTC 重启容器后，80+ 次不同参数请求均未崩溃。但这只是规避累积状态，不是修复。
若需要根治方向，可关注 ggml-cuda/add-id.cu 的改动：讨论提出的修复思路是给 ADD_ID kernel 加反量化 shim（检测非 F32 的 src0/src1，反量化到临时 F32 buffer 后再执行 kernel，然后释放），或把 ADD_ID 注册进 dequant-aware dispatch 路径。此为社区建议，尚未被合并验证。

验证方法

用 Issue 中带 system 消息的原始 payload 重复调用 /api/chat（stream=false），以及 /v1/chat/completions 和流式端点，确认均返回 HTTP 200 且内容正确、无 ADD_ID failed 日志、无 signal: aborted (core dumped)。由于该问题表现为间歇性，仅在重启后短时间验证不足以判定修复，需在服务持续运行较长时段、累积多次推理后再复测，并同步检查服务端日志。