AI服务器GPU掉卡排查：从现象到修复的实操流程

GPU掉卡通常表现为 nvidia-smi 输出中卡数少于物理卡数，或某张卡显示为 ERR!
、N/A。
在动手重启前，先按顺序确认掉卡范围和伴随日志，多数问题能在 10 分钟内定位到驱动、供电或硬件层面。

先确认掉卡现象和范围

登录服务器后，第一件事是查看当前 GPU 状态：

nvidia-smi

记录输出中实际列出的 GPU 编号。
如果物理有 8 张卡，但只显示 7 张，说明第 8 张已经掉线。
接着用以下命令确认系统层面是否仍能识别到该 PCI 设备：

lspci | grep -i nvidia

对比 lspci 输出的 NVIDIA 设备数量和 nvidia-smi 显示的卡数。
如果 lspci 能列出 8 个设备但 nvidia-smi 只显示 7 个，问题偏驱动或内核模块；
如果 lspci 也少一个，问题偏硬件、供电或 PCIe 链路。

同时记录掉卡发生的时间点，方便后面查日志时对齐时间。

从内核日志里找线索

掉卡原因最直接的证据在 dmesg 里。
执行：

dmesg -T | grep -i -E "nvidia|nvrm|xid|pcie" | tail -50

重点关注以下几类信息：

• Xid 错误码：NVIDIA 驱动用 Xid 标记 GPU 异常。Xid 79 通常表示 GPU 掉线（fallen off the bus），Xid 48 表示双比特 ECC 错误，Xid 62 表示内部微控制器错误。不同 Xid 对应不同处理方向，先记录具体编号再查对应含义。
• PCIe 链路错误：出现 AER 或 pcieport 相关报错，说明 PCIe 链路不稳定，可能是转接卡、插槽或主板问题。
• NVRM 报错：NVRM: Xid 或 NVRM: GPU at PCI:... has fallen off the bus 是最典型的掉卡日志。

如果 dmesg 信息被刷掉了，可以查系统日志：

journalctl -k --since "2024-01-01" | grep -i nvidia | tail -50

把日志里的 Xid 编号和掉卡时间对照，基本能判断是软件层还是硬件层。

驱动和内核模块的检查与重载

如果日志里没有硬件级错误，先尝试重载 NVIDIA 内核模块：

sudo rmmod nvidia_uvm nvidia_drm nvidia_modeset nvidia
sudo modprobe nvidia
nvidia-smi

如果重载后卡恢复，说明是驱动模块临时异常，可以继续观察是否复发。
如果重载时报 Module nvidia is in use，先停掉占用 GPU 的进程：

sudo fuser -v /dev/nvidia*

找到进程后停止对应服务，再重载模块。

驱动版本不匹配也会导致掉卡。
用以下命令核对驱动版本和内核版本：

nvidia-smi --query-gpu=driver_version --format=csv
uname -r

如果最近升级过内核但没重装驱动，DKMS 可能没自动编译新模块。
检查：

dkms status

输出中 nvidia 模块应对应当前内核版本。
如果缺失，重新安装驱动或执行 dkms autoinstall。

硬件层面的验证与压力测试

排除驱动问题后，重点查供电和散热。
用 nvidia-smi -q 查看掉卡前的温度、功耗和 ECC 错误计数：

nvidia-smi -q -d TEMPERATURE,POWER,ECC

如果某张卡温度长期接近上限，或 ECC 可纠正错误计数持续增长，硬件老化的可能性较高。

对恢复后的卡做一次短时压力测试，确认稳定性：

gpu-burn 60

如果没有 gpu-burn，可以用 nvidia-smi dmon 观察一段时间内的功耗和温度波动。
压力测试中再次掉卡，基本可以锁定该卡或对应插槽的硬件问题，建议更换插槽或联系厂商检修。

常见坑和后续观察

• 不要直接 reboot 了事：重启能暂时恢复，但会丢掉 dmesg 里的关键日志，下次掉卡仍然无法定位。
• Xid 79 不一定是卡坏了：也可能是 PCIe 转接卡接触不良或电源瞬时不足，先换插槽、检查供电线再判断。
• 多卡服务器注意电源冗余：满载时瞬时功耗可能超过单路电源上限，导致个别卡掉线。
• 修复后持续观察：用 nvidia-smi dmon -s pucvmet 记录一段时间，确认没有反复掉卡再结束排查。

如果按以上步骤仍然无法恢复，保留 dmesg 中完整的 Xid 日志和 lspci 输出，再联系服务器厂商或 NVIDIA 支持，能显著缩短沟通时间。