技术博客

GPU 服务器 Linux 运维上线前检查清单:驱动、CUDA、PCIe 和容器运行时

GPU 服务器上线前不能只看 nvidia-smi。本文整理 Linux 运维需要检查的硬件识别、驱动版本、CUDA、PCIe、NUMA、容器运行时和压力测试。

GPU服务器Linux运维NVIDIA驱动CUDA

GPU 服务器比普通 Linux 服务器更容易出现“表面正常、运行不稳”的问题。nvidia-smi 能看到卡,不代表训练任务一定稳定;CUDA 能跑样例,也不代表 Kubernetes Pod 能访问 GPU;驱动版本一致,也不代表 PCIe、NUMA、散热和容器运行时都没有问题。

这篇文章整理 GPU 服务器上线前的 Linux 运维检查清单,适合新节点入库、重装系统、扩容 GPU 集群和故障节点回归验证。

一、确认硬件识别

先看系统是否识别到 GPU:

lspci | grep -i nvidia
nvidia-smi -L
nvidia-smi

如果 lspci 能看到设备,但 nvidia-smi 失败,通常是驱动问题。如果 lspci 都看不到,要继续检查 BIOS、PCIe 插槽、供电、硬件故障或虚拟化透传配置。

二、确认驱动和内核

驱动和内核关系很紧。内核升级后,驱动模块可能加载失败。

uname -r
lsmod | grep nvidia
modinfo nvidia | head
dmesg | grep -i nvidia

常见问题:

生产环境建议固定内核升级策略,不要让 GPU 节点自动滚动升级内核。

三、确认 CUDA 和容器访问

宿主机能跑 GPU,不代表容器能跑 GPU。容器运行时需要 NVIDIA Container Toolkit 或等效配置。

Docker 测试:

docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

containerd / Kubernetes 场景要检查 runtime 配置和 device plugin。

crictl info | grep -i nvidia
kubectl describe node <gpu-node> | grep -A5 Allocatable

如果 Pod 申请了 GPU 但容器里看不到,优先检查 runtime class、device plugin、节点 allocatable 和 Pod 事件。

四、确认 PCIe 和 NUMA

GPU 性能问题不一定是模型问题。PCIe 降速、NUMA 不匹配、CPU 亲和性都可能拖慢训练。

lspci -vv | grep -A20 -i nvidia | grep -E "LnkSta|LnkCap"
numactl --hardware
nvidia-smi topo -m

重点看:

五、确认散热和功耗

新节点上线要观察温度和功耗:

nvidia-smi --query-gpu=index,name,temperature.gpu,power.draw,power.limit,utilization.gpu,memory.used --format=csv

如果空载温度异常,先不要上线。高温可能导致降频,训练任务表现为速度不稳定。

六、做基础压力测试

上线前至少跑短时间压力测试,观察温度、错误和掉卡。

检查:

watch -n 1 nvidia-smi
dmesg -w
journalctl -k -f

如果出现 XID 错误,需要记录 GPU UUID、节点、时间和任务信息,再决定是否下线检测。

常见问题 FAQ

nvidia-smi 正常就可以上线吗?

不够。还要确认容器访问、Kubernetes allocatable、监控、压力测试和错误日志。

驱动版本是不是越新越好?

不一定。生产环境更关注稳定和兼容。要结合 CUDA 镜像、GPU Operator、内核和业务框架选择。

GPU 节点能不能自动升级内核?

不建议无控制自动升级。内核升级可能影响驱动模块,需要维护窗口和回滚方案。

为什么训练任务慢,但 GPU 利用率不高?

可能是数据读取、CPU、网络、PCIe、NUMA 或分布式通信瓶颈,不一定是 GPU 本身。

参考资料