Eval bug: MoE models crashes llama with CUDA Error on first or second prompt.

问题场景

用户在 Linux + NVIDIA RTX 3070 + CUDA 后端环境下，使用 llama.cpp 的 llama cli 加载 MoE 模型进行对话。加载与第一次 prompt 可以正常完成，但第二次 prompt 时程序崩溃并触发 CUDA error，随后 SIGABRT。

报告者测试的 MoE 模型包括：

• unsloth/gemma-4-E4B-it-GGUF:Q4_K_XL
• ggml-org/gemma-4-E4B-it-GGUF:Q4_0
• unsloth/LFM2.5-8B-A1B-GGUF:Q4_K_M

作为对照，Dense 模型未受影响：

• unsloth/Qwen3.5-9B-GGUF:Q4_K_M
• unsloth/gemma-4-12b-it-GGUF:Q4_K_XL

评论中还出现了一个相近场景：使用 llama serve 加载 Qwen3.8-27B MoE 模型，并启用 --spec-type draft-mtp、--spec-draft-n-max 3、-ngl 99、-c 10384、--jinja -np 1，同样在模型加载后触发同一类 cublasGemmEx CUDA error。

报错原文

Eval bug: MoE models crashes llama with CUDA Error on first or second prompt.

llamacpp/ggml/src/ggml-cuda/ggml-cuda.cu:107: CUDA error

E CUDA error: the requested functionality is not supported
E   current device: 0, in function ggml_cuda_mul_mat_cublas_impl at llamacpp/ggml/src/ggml-cuda/ggml-cuda.cu:1552
E   cublasGemmEx(cublas_h, CUBLAS_OP_T, CUBLAS_OP_N, ne01, ne11, ne10, alpha, src0_ptr, cu_data_type_a, s01, src1_ptr, cu_data_type_b, s11, beta, dst_ptr, cu_data_type, ne0, cu_compute_type, CUBLAS_GEMM_DEFAULT_TENSOR_OP)

fish: Job 1, 'llama serve -m /mnt/D/Mymodels/…
  --spec-type draft-mtp \
  --spec-draft-n-max 3 \
  -ngl 99 \
  -c 10384 \
  --jinja -np 1' terminated by signal SIGABRT (Abort)

原因分析

从日志看，崩溃发生在 ggml_cuda_mul_mat_cublas_impl 内部调用 cublasGemmEx 时，CUDA 返回 the requested functionality is not supported。这说明问题出在 cuBLAS 的 GEMM 调用组合上，而不是简单的显存不足或模型加载失败。

可能原因包括：

• MoE 模型的专家层在推理时会产生特定的矩阵形状或数据类型组合，该组合在当前 CUDA/cuBLAS 版本或当前 llama.cpp 构建下不被支持。
• 当前 llama.cpp 构建（build 10679）与系统 CUDA 运行时/驱动之间的兼容性问题，导致 CUBLAS_GEMM_DEFAULT_TENSOR_OP 路径在部分矩阵形状上失败。
• 可能与该 Issue 中评论提到的 speculative decoding（--spec-type draft-mtp）路径有关，但原始报告者并未使用该参数，因此该路径只是相关场景之一，不是唯一触发条件。

需要注意，报告者最终表示问题自行消失，且无法说明是什么修复了它，因此目前没有确认的根因。

环境排查

• 确认 llama.cpp 构建版本与 commit：Issue 中为 version: 0.3.0-dev (build 10679, commit 50f068fff)。
• 确认编译使用的 CUDA Toolkit 版本，以及系统安装的 NVIDIA 驱动版本。Issue 中驱动相关包为 610.57.04，cuda-driver-devel 为 13.3.29。
• 确认 GPU 型号与计算能力：Issue 中为 NVIDIA GeForce RTX 3070。
• 确认 GPU 后端编译选项：Issue 中为 CUDA（GGML backends: CUDA）。
• 确认 Linux 发行版与内核：Fedora 44，内核 7.1.13-200.fc44.x86_64。
• 确认触发模型是否为 MoE 架构，并用 Dense 模型做对照测试，以区分是否为 MoE 特有问题。
• 确认是否启用了 speculative decoding、MTP 或其他非默认推理参数；评论中的相近报错使用了 --spec-type draft-mtp。
• 确认 Python、PyTorch 版本：Issue 未提供该信息，因此不列为必要排查项。

解决步骤

1. 先确认是否为 MoE 模型特有问题：在同一台机器、同一构建下，用 Dense 模型（如 Qwen3.5-9B 或 gemma-4-12b）执行多轮 prompt，确认 Dense 模型不触发该 CUDA error。
2. 重新观察触发位置：MoE 模型第一次 prompt 是否正常，第二次 prompt 是否必然崩溃，记录崩溃前最后一次成功生成的 token 数或对话轮次。
3. 确认当前构建对应的 CUDA 编译环境与运行时是否一致，必要时重新编译 llama.cpp，使 CUDA Toolkit 版本与驱动匹配。
4. 尝试更新或回退 NVIDIA 驱动 / CUDA 运行时到另一组已确认可用的组合。Issue 中没有给出具体可用版本，因此这一步属于可优先尝试的排查方向，而非已验证修复。
5. 如果正在使用 speculative decoding 或 MTP 相关参数，可临时移除 --spec-type draft-mtp、--spec-draft-n-max 等参数，观察是否仍崩溃；Issue 评论中的相近报错出现在该参数组合下。
6. 检查是否有可切换的 llama.cpp 构建或更新到较新 commit；Issue 本身未提供确认修复的具体 commit，因此只能作为尝试，不能保证解决。
7. 如果崩溃反复出现且可稳定复现，保留完整日志（包括 build 号、commit、触发 prompt、模型名与量化类型）并在原 Issue 中补充，便于进一步定位 cuBLAS 不支持的具体矩阵形状或数据类型。

验证方法

在调整构建、驱动、CUDA 版本或推理参数后，用同一 MoE 模型连续执行至少两轮 prompt。如果第二轮 prompt 不再触发 cublasGemmEx 相关 CUDA error，且进程不再以 SIGABRT 退出，则可认为问题已规避。若仍复现，说明当前调整未触及根因，需要继续按环境排查项逐项确认。

由于 Issue 中报告者最终称“Bug is gone. I can’t say what fixed it.”，验证时不能把问题自行消失当作已确认修复，只能以连续多轮稳定运行为准。

参考来源

ggml-org/llama.cpp #28251

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。