llama.cpp 升级踩坑：CUDA 驱动不匹配导致 GPU 掉线全记录

模型服务器上的 llama.cpp 整整落后了一个月。源码编译、替换二进制，本以为是个 10 分钟的常规操作——结果硬生生折腾了一上午，踩了一个隐藏极深的 CUDA 驱动版本不匹配的坑。

本文记录完整的诊断过程，希望帮你在遇到同类问题时少走弯路。

背景

ModelBase 服务器配置：

• 双 RTX 2080 Ti（22GB 魔改版）
• AMD Ryzen 7 5700G，8 核 16 线程
• CUDA 12.8，Ubuntu 24.04
• llama.cpp 运行 Ornith-1.0-35B（Q4_K_M 量化），正常速度 ~104 tok/s

旧版 llama.cpp 编译于 2026-06-27（commit ae7151b），落后最新 master 一个月。最近一个月的主要更新包括：

• NVFP4 W4A4 activation quantization 优化
• mlock/mmap/directio 加载模式重构
• 投机解码 draft model 自动识别
• DeepSeek v4 chat template 修复

第一阶段：编译——顺利得不像话

下载源码、cmake 配置、编译，一气呵成：

# 下载
aria2c -c -x4 -s4 'https://gh-proxy.com/https://github.com/ggml-org/llama.cpp/archive/refs/heads/master.zip'

# 编译（关键参数）
cmake .. \
  -DCMAKE_BUILD_TYPE=Release \
  -DGGML_CUDA=ON \
  -DGGML_CUDA_FA=ON \
  -DCMAKE_CUDA_ARCHITECTURES=75 \
  -DCUDAToolkit_ROOT=/usr/local/cuda-12.8 \
  -DCMAKE_CUDA_COMPILER=/usr/local/cuda-12.8/bin/nvcc

cmake --build . --config Release -j$(nproc)

16 核全开，约 5-10 分钟编译完成。llama-server --version 正常输出。

第二阶段：部署——第一个坑

编译完成后，我把旧的 build/ 目录改名为 build.old/，新版放到 build/，然后重启 systemd 服务。

测速——14 tok/s。

不对，正常应该是 100+ tok/s。

查日志：

warning: no usable GPU found, --gpu-layers option will be ignored
warning: llama.cpp was compiled without support for GPU offload.

GPU offload 没生效。模型跑在 CPU 上。

诊断 1：RUNPATH 硬编码

readelf -d llama-server | grep RUNPATH
# 0x000000000000001d (RUNPATH) Library runpath: [/home/tony/llama.cpp/build/bin:]

二进制文件在编译时，CMake 会把编译目录的绝对路径写进 RUNPATH。旧版二进制编译时路径是 build/bin，现在这个位置放着新版的 .so 库——版本不兼容，GPU 后端加载失败。

ldd llama-server | grep ggml-cuda
# libggml-cuda.so.0 => /home/tony/llama.cpp/build/bin/libggml-cuda.so.0

旧版二进制加载的是新版 CUDA 库。修复方法是覆盖 RUNPATH 或用 LD_LIBRARY_PATH，但这只是表面问题。

诊断 2：切回旧版也一样

我完全恢复了旧版目录结构，确保二进制和 .so 库版本一致。重启服务，再测——还是 14 tok/s，同样报 no usable GPU found。

这就不对了。目录结构完全恢复到升级前状态，配置文件一行没动，为什么 GPU 还是掉线？

诊断 3：CUDA 驱动版本不匹配

# 内核驱动版本
cat /proc/driver/nvidia/version
# NVRM version: NVIDIA UNIX x86_64 Kernel Module  580.159.03

# 用户空间库版本
ls -la /lib/x86_64-linux-gnu/libcuda.so.1
# libcuda.so.1 -> libcuda.so.580.173.02

内核驱动 580.159.03，用户空间库 580.173.02。版本不匹配！

写一个最简单的 CUDA 测试程序：

#include <cuda_runtime.h>
int main() {
    int count;
    cudaError_t err = cudaGetDeviceCount(&count);
    printf("count=%d err=%d\n", count, err);
    return 0;
}

nvcc -o test test.cu && ./test
# count=0 err=804

CUDA 错误码 804：forward compatibility was attempted on non supported HW。驱动版本不匹配，CUDA 完全不可用。

第三阶段：根因——apt 的静默升级

dpkg -l | grep nvidia-driver 显示：

nvidia-driver-580  580.173.02-0ubuntu0.24.04.1

用户空间库已经是 580.173.02。但当前跑的内核是 6.8.0-124，里面加载的 nvidia 内核模块还是旧的 580.159.03。

时间线推断：

1. 6月28日：系统启动，加载内核 6.8.0-124，nvidia 模块 580.159.03
2. 6月29日：unattended-upgrades 或手动 apt upgrade 升级了 nvidia-driver-580 到 580.173.02（用户空间库）
3. DKMS 为新内核 6.8.0-136 编译了 580.173.02 的 nvidia 模块
4. 但没重启——旧内核 6.8.0-124 里跑的还是旧模块

此后所有依赖 CUDA 的程序都在静默失败，只是 llama.cpp 有 CPU fallback 兜底（4-14 tok/s），看起来”虽然慢但能跑”，没触发告警。

第四阶段：修复——重启切内核

# 确认新内核已安装
dpkg -l | grep linux-image
# linux-image-6.8.0-136-generic 6.8.0-136.136

# 确认 DKMS 已为新内核编译驱动
dkms status
# nvidia/580.173.02, 6.8.0-136-generic, x86_64: installed

# 确认 GRUB 默认启动最新内核
grep GRUB_DEFAULT /etc/default/grub
# GRUB_DEFAULT=0

# 重启
sudo reboot

重启后验证：

uname -r
# 6.8.0-136-generic

nvidia-smi
# NVIDIA-SMI 580.173.02   Driver Version: 580.173.02   CUDA Version: 13.0
# GPU 0: RTX 2080 Ti  22528MiB
# GPU 1: RTX 2080 Ti  22528MiB

驱动版本完全匹配，两张 GPU 正常识别。

第五阶段：测速——满血复活

# 热测速
curl http://10.28.9.6:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen3.5-35B-A3B-Ornith",
       "messages":[{"role":"user","content":"介绍上海"}],
       "max_tokens":200,"temperature":0}'

# 日志输出
# eval time = 1910 ms / 200 tokens (9.5 ms per token, 104.7 tokens per second)

104.7 tok/s。满血复活。

新版 vs 旧版对比

确认旧版恢复后，重新部署新版：

版本	库版本	热测速
旧版 (ae7151b)	0.15.3	101.6 tok/s
新版 (master)	0.17.0	104.7 tok/s

新版略快 3%，提升不大，但一个月的 bug fix 和新功能支持是值得的。

经验总结

1. GPU 掉线先查驱动版本匹配

cat /proc/driver/nvidia/version    # 内核模块版本
ls -la /lib/x86_64-linux-gnu/libcuda.so.1  # 用户空间库版本

两个版本必须一致。不一致就是 CUDA 驱动不匹配，所有 GPU 加速都会静默失败。

2. CPU fallback 是双刃剑

llama.cpp 有 CPU fallback 机制——GPU 不可用时自动切 CPU。这让服务”看起来正常”（能推理），但速度差 10 倍。如果不主动测速，可能几周都不会发现 GPU 掉线。

3. apt 升级 nvidia-driver 后必须重启

Ubuntu 的 unattended-upgrades 会自动升级 NVIDIA 驱动包，但内核模块需要重启才能加载。升级后检查：

# 比对版本
cat /proc/driver/nvidia/version
dpkg -l | grep nvidia-driver

版本不一致就准备重启。

4. RUNPATH 问题用独立目录规避

编译 llama.cpp 时，CMake 把绝对路径写进 RUNPATH。移动目录后找不到 .so 库。推荐每次新版放在独立目录（build_new/），通过 systemd 的 LD_LIBRARY_PATH 切换，保留旧版做备份。

5. systemd 管理 + 健康检查

llama-server 用 systemd 管理，重启后自动恢复。但 ComfyUI/Whisper/TTS 是手动 nohup 启动的，重启后需要手动拉起。建议后续都改成 systemd 服务。

最终架构

服务	端口	GPU	启动方式
llama-server	8080	GPU 0+1 (0.7:0.3)	systemd
ComfyUI	8188	GPU 1	nohup
Whisper	8700	GPU 1	nohup
TTS	8701	GPU 1	nohup

新版 llama.cpp 部署在 /home/tony/llama.cpp/build_new/，旧版保留在 build/ 作为备份，随时可切回。

发稿审核清单

本文发布前应逐项确认：

• 硬件规格（CPU 核数、GPU 显存、内存大小）已从 nproc、nvidia-smi、free -h 等命令输出逐字核实，不凭记忆写
• 命令参数中的端口、路径、IP 地址与当前环境一致
• 日志中的关键数据（版本号、速度值）与 llama-server.log 原文比对
• 技术总结中的操作用户实际可复现（非 root 操作已标注 sudo）
• 隐私数据（密码、token、内网 IP）已脱敏