我们在深度学习业务落地的过程中，GPU服务器的稳定性和可用性是保障模型高效运行的关键。近期我们在香港节点部署的一批深度学习业务服务器中，遇到了“GPU卡识别失败”的严重问题，导致模型训练无法启动、推理任务中断。本文将通过一次完整的故障排查实录，深入分析问题原因，并给出可复现的修复方案，帮助读者在类似场景中快速响应和处理。
一、故障环境
部署环境：
- 服务器型号：Dell R740（共16台）
- GPU型号：NVIDIA A100 40GB PCIe
- 操作系统：Ubuntu 20.04 LTS
- CUDA版本：11.8
- NVIDIA Driver版本：525.60.13
- 容器运行环境：Docker + NVIDIA Container Toolkit
- 调度系统：Kubernetes v1.26，GPU调度通过 nvidia-device-plugin 插件实现
业务场景为大规模多节点分布式训练（PyTorch DDP），GPU资源需求紧张，对识别准确性和调度性能要求高。
二、故障现象
nvidia-smi 命令无法识别GPU，提示 No devices were found
Kubernetes节点处于 Ready 状态，但 nvidia.com/gpu 资源为 0
日志中反复出现如下错误信息：
Failed to initialize NVML: Driver/library version mismatch
Error: nvidia-container-cli: initialization error: unknown error
容器中无法加载 GPU 设备，推理服务持续失败
某些节点偶发性可以识别 GPU，但重新启动后再次失效
三、故障排查过程
1. 初步硬件检查
使用 lspci | grep -i nvidia 命令确认 PCIe 层是否能够识别 GPU：
0000:82:00.0 3D controller: NVIDIA Corporation A100 PCIe 40GB (rev a1)
可以确认，服务器硬件层面已成功安装 A100 GPU，无物理损坏。
2. 驱动加载状态核查
检查内核模块加载情况：
lsmod | grep nvidia
未返回任何结果，表明 NVIDIA 驱动未加载成功。尝试手动加载：
modprobe nvidia
报错：
modprobe: ERROR: could not insert 'nvidia': No such device
进一步确认 dmesg 输出，发现如下内容：
NVRM: loading NVIDIA UNIX x86_64 Kernel Module 525.60.13 failed.
NVRM: No NVIDIA GPU found on this system.
可能原因：驱动未与内核版本适配。
3. 驱动版本与内核兼容性验证
当前内核版本：
uname -r
返回：
5.15.0-101-generic
参考 NVIDIA 驱动发布说明，发现 525.60.13 对 5.15.x 支持不完全，建议使用更高版本驱动（如 535.113.01）。部分节点通过自动更新，已升级内核至 5.15.0-103，而未重新编译驱动，导致 Driver/library version mismatch。
四、问题根因
综上，GPU无法识别的根因是：内核升级后未同步更新 NVIDIA 驱动模块，导致内核与驱动不兼容。此外，由于 Kubernetes 使用 nvidia-device-plugin 自动暴露 GPU 资源，驱动异常也直接影响了容器调度和业务部署。
五、修复方案
1. 升级驱动并重新编译内核模块
以 root 权限登录节点，执行以下步骤：
步骤一：卸载原驱动
sudo nvidia-uninstall
sudo apt-get purge nvidia-*
步骤二：禁用自动内核更新（防止版本漂移）
sudo apt-mark hold linux-image-generic linux-headers-generic
步骤三：安装推荐驱动（以 535.113.01 为例）
sudo apt-add-repository ppa:graphics-drivers/ppa
sudo apt-get update
sudo apt-get install nvidia-driver-535
sudo reboot
重启后，使用 nvidia-smi 验证驱动加载成功。
2. 校验容器运行环境
重新安装 nvidia-container-toolkit 并配置运行时：
sudo apt-get install nvidia-container-toolkit
sudo systemctl restart docker
检查默认运行时：
cat /etc/docker/daemon.json
应包含如下内容：
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "nvidia-container-runtime",
"runtimeArgs": []
}
}
}
3. Kubernetes 插件修复
重新部署 nvidia-device-plugin：
kubectl delete -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.13.0/nvidia-device-plugin.yml
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.13.0/nvidia-device-plugin.yml
验证 GPU 已暴露：
kubectl describe node <node-name> | grep nvidia.com/gpu
应返回类似信息：
Capacity:
nvidia.com/gpu: 4
Allocatable:
nvidia.com/gpu: 4
这次香港服务器GPU无法识别的问题，实质上是因 内核版本与驱动不匹配 所致，触发了一系列容器环境和 Kubernetes 调度的连锁反应。通过系统性排查，我们确立了以下经验要点：
- 升级内核需同步驱动重编译，避免版本不兼容；
- 冻结生产环境内核版本，稳定性优先；
- 建议使用 自动化脚本批量检测 GPU 状态，如定期运行 nvidia-smi、kubectl get nodes 等命令收集状态；
- 对多节点环境可使用 Ansible 脚本部署驱动更新，减少手动操作错误。
希望能为广大运维和研发工程师提供一个高可复制、实战性强的GPU故障排查范例，提升线上业务的可用性与可靠性。
