在Kubernetes环境中，GPU资源的管理复杂度高、故障诊断和恢复难度大，且宕机成本高。出现故障时，您需要正确识别问题（硬件、驱动、配置等问题），快速采取恰当的恢复措施，以最小化对终端用户的影响。本文介绍常见的GPU故障类型及对应解决方案，以便您快速响应故障，最大限度地减少宕机时间，保障业务应用的连续性和高性能。
GPU资源管理面临的挑战
管理复杂：相较于常规的CPU和内存资源，在Kubernetes环境中，GPU资源不能通过简单的原生Kubernetes API进行管理，通常需要集成额外的设备插件，管理复杂度高。
故障诊断和恢复难度大：相较于传统硬件设备，由于GPU本身的特殊性和复杂的依赖关系（例如对驱动程序和库版本的依赖），GPU资源的故障诊断和恢复工作难度更大。
宕机成本高：相较于普通ECS实例，GPU实例单价通常较高且库存供应更为有限。任何与GPU相关的故障均可能引发高昂的系统宕机成本。
GPU故障类型
在Kubernetes集群环境中，GPU故障大致分为如下几类。
故障类型 | 说明 |
GPU物理组件发生的故障，可能涉及GPU芯片、显存、风扇、电源或其他硬件部位。包括： | |
GPU驱动程序问题，包括安装错误、版本不兼容（操作系统版本，内核版本、容器运行时等）、驱动本身缺陷等。包括： | |
包括NVIDIA Container Runtime、Device Plugin等组件出现问题。包括： | |
GPU应用引起的故障，例如GPU越界内存访问、Pod配置出错等。包括： | |
cGPU模块出现的问题，例如内核升级导致的编译版本过期等。其中包括内核升级导致的编译版本过期。 |
本文部分故障来自于XID错误报告。
硬件故障
GPU硬件故障指由于设备损坏、老化或者其他物理原因而导致的GPU工作异常或者完全失效的情况。硬件故障可能会导致算力下降、系统崩溃、图形输出错误等问题。在ACK集群中，尤其在执行深度学习、科学计算或任何高性能并行计算任务时，GPU硬件故障会对依赖GPU资源的应用产生重大的影响。
XID错误表明的硬件故障
故障描述
以下列举一些较为常见的XID的错误以及其错误原因。关于XID的更多信息，请参见XID Errors。
XID | 错误说明 |
32 | Invalid or corrupted push buffer stream. 事件由PCIe总线上管理NVIDIA驱动和GPU之间通信的DMA控制器上报。通常是PCI质量问题导致，而非应用程序导致。 |
61 | Internal micro-controller breakpoint/warning. GPU内部引擎已停止工作，业务已经受到影响。 |
62 | Internal micro-controller halt. 与XID 61的触发场景类似。 |
63 | ECC page retirement or row remapping recording event.
当应用程序遭遇GPU显存硬件错误时，NVIDIA自纠错机制会将错误的内存区域 Retirement和Remapped信息需要记录到infoROM（信息只读存储器）中才能永久生效。
|
64 | ECC page retirement or row remapper recording failure. 与XID 63的触发场景类似，只是XID 63代表Retirement和Remapped信息成功记录到了 infoROM，XID 64代表该记录操作失败。 |
74 | NVLINK Error. 由NVLink硬件错误导致的问题，说明GPU已经出现严重的硬件故障，需要下线维修。 |
79 | GPU has fallen off the bus. GPU硬件检测到掉卡，即从PCIe总线上断开连接，导致系统无法检测此GPU卡。收到此事件说明GPU已经出现严重硬件故障，需要下线维修。 |
如需检查节点上是否产生XID错误，您需要登录该节点，然后执行如下命令。
grep "NVRM: Xid" -B 1 /var/log/messages如果没有内容输出，则表明没有XID错误。
如果有内容输出，则表明有XID错误产生。示例如下。
[…] NVRM: GPU at 0000:03:00: GPU-b850f46d-d5ea-c752-ddf3-c4453e44d3f7
[…] NVRM: Xid (PCI:0000:03:00): 14, Channel 00000001 预期输出表明，GPU产生XID为14的错误，其BUS ID为0000:03:00，其GPU ID为GPU-b850f46d-d5ea-c752-ddf3-c4453e44d3f7。
解决方案
请提交工单联系容器服务技术支持。
GPU设备无法识别
故障描述
GPU设备无法识别指在PCIe总线上无法识别某GPU设备，或者识别到的状态有误。
您可以在节点上利用lspci命令的输出来确保所有GPU设备的识别正常。如果每个GPU末尾标识为(rev a1)，则表明该设备可以正常被PCIe识别；如果输出信息末尾为(rev ff)，则表明GPU设备在总线上的识别异常。
设备识别异常的示例如下。
$ lspci | grep NVIDIA
00:07.0 3D controller: NVIDIA Corporation GV100GL [Tesla V100 SXM2 32GB] (rev ff)解决方案
请提交工单联系容器服务技术支持。
GPU设备带宽异常
故障描述
在GPU节点上，需要确保GPU对当前带宽与额定带宽一致且为x16。您可以使用lspci命令进行检测。当前带宽和额定带宽的检测命令分别为：
额定带宽：
lspci -vvd 10de: | grep -i Lnkcap:当前带宽：
lspci -vvd 10de: | grep -i Lnksta:
示例如下。
# 额定带宽
$ lspci -vvd 10de: | grep -i Lnkcap:
LnkCap: Port # 8, Speed 8GT/s, Width x16, ASPM not supported
# 当前带宽
$ lspci -vvd 10de: | grep -i Lnksta:
LnkSta: Speed 8GT/s (ok), Width x16 (ok)解决方案
请提交工单联系容器服务技术支持。
NVIDIA-SMI发现的硬件问题
故障描述
如果在节点上执行nvidia-smi的结果中发现Fan ERR或Power Usage ERR，表明GPU出现了硬件故障。
Fan ERR：GPU的风扇出现了故障，可能会进一步导致GPU温度过高甚至GPU设备出现问题。Power Usage ERR：GPU的电源供应可能存在问题，可能是因为电源线未连接好、电源适配器故障、电源输出不稳定或电源容量不足等原因。如果GPU无法获得足够的电源供应，可能会导致系统不稳定，显卡可能会频繁重置、性能下降，或者在高负载情况下完全停止工作。
执行nvidia-smi出现Fan ERR错误的示例如下。
$ nvidia-smi
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 418.67 Driver Version: 418.67 CUDA Version: 10.1 |
|-------------------------------+----------------------+----------------------+
| GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. |
|===============================+======================+======================|
| 0 Tesla V100-SXM3... On | 00000000:3E:00.0 Off | 0 |
| ERR! 44C P0 ERR!/ 350W | 0MiB / 32480MiB | 0% Default |
+-------------------------------+----------------------+----------------------+解决方案
某些情况下，可以通过重启节点解决Fan ERR或者Power Usage ERR错误。推荐流程如下。
重启节点，尝试恢复该GPU状态。如果执行
nvidia-smi命令后，显示问题未出现，则表明问题已解决。如果重启无法解决问题，则表明硬件出现问题。请提交工单联系容器服务技术支持。
GPU设备的infoROM损坏
InfoROM是显卡上的一个存储区域，用于存放固件和重要的配置数据。如果InfoROM损坏，可能会影响显卡正常运行，甚至无法使用。
故障描述
当执行nvidia-smi命令时，预期输出中出现infoROM is corrupted，表明NVIDIA GPU的InfoROM损坏。
执行nvidia-smi出现InfoROM损坏的示例如下。
+---------------------------------------------------------------------------------------+
| NVIDIA-SMI 535.54.03 Driver Version: 535.54.03 CUDA Version: 12.2 |
|-----------------------------------------+----------------------+----------------------+
| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |
| Fan Temp Perf Pwr:Usage/Cap | Memory-Usage | GPU-Util Compute M. |
| | | MIG M. |
|=========================================+======================+======================|
| 0 Tesla V100-SXM2-32GB On | 00000000:00:07.0 Off | 0 |
| N/A 31C P0 22W / 300W | 0MiB / 32768MiB | 0% Default |
| | | N/A |
+-----------------------------------------+----------------------+----------------------+
+---------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=======================================================================================|
| No running processes found |
+---------------------------------------------------------------------------------------+
WARNING: infoROM is corrupted at gpu 0000:07.0解决方案
请提交工单联系容器服务技术支持。
驱动故障
GPU驱动故障指由于GPU的软件驱动程序出现问题而导致的一系列故障和异常行为，可能表现为系统崩溃、性能下降、图形显示错误、功能失效或其他不稳定的行为。驱动程序是操作系统用来与硬件设备通信的软件，负责告诉操作系统如何控制GPU并与GPU交互。驱动程序的正确性对于确保GPU的正常工作至关重要。
驱动版本与GPU设备不匹配
故障描述
每个版本的驱动都有其适用的GPU设备，如果安装的驱动版本和目标节点上的GPU设备不匹配，会出现一些预期外的问题，例如驱动安装失败等。当节点安装的驱动版本与硬件不匹配时（例如非vGPU机型安装了GRID驱动），系统日志中会上报一个NVRM事件。
您可以执行以下命令获取NVRM事件的详细内容。
dmesg | grep -i nvrm如果预期输出中存在类似not supported的字段，则表明驱动版本和设备不匹配。
Nov 30 20:56:46 NEV000GPUD03 kernel: [ 1680.567330] NVRM: The NVIDIA GPU 0000:00:06.0 (PCI ID: 10de:1db6)
Nov 30 20:56:46 NEV000GPUD03 kernel: [ 1680.567330] NVRM: installed in this system is not supported by the
Nov 30 20:56:46 NEV000GPUD03 kernel: [ 1680.567330] NVRM: NVIDIA 515.65.01 driver release.解决方案
到NVIDIA官方网站寻找GPU设备对应的驱动版本。
卸载旧驱动，并重启机器。
安装新的驱动。
驱动无法连接
故障描述
当执行nvidia-smi命令或者使用NVML库获取GPU设备信息时，出现类似couldn't communicate with the NVIDIA driver的错误，表明驱动存在问题，无法连接。
执行nvidia-smi出现驱动无法连接的示例如下。
nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver解决方案
一般是驱动本身出现问题，需要重新安装驱动。
卸载旧驱动，并重启机器。
重新安装该版本驱动。
内核升级导致的编译版本过期
故障描述
NVIDIA GPU驱动程序的安装不是单纯的文件复制过程，而是“半编译包”，即驱动的一部分为预先编译，而另一部分则需要基于系统的内核开发包（kernel-devel）进行现场编译。编译模块是针对特定内核版本的。如果在安装GPU驱动后进行了内核升级，可能会导致现有的GPU驱动模块不可用。
升级内核版本后，重启机器，然后执行nvidia-smi，若出现如下错误，则表明内核升级导致编译版本过期。
nvidia-smi
NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver故障定位方案如下：
执行
uname -r，输出当前内核版本。uname -r 5.10.134-16.1.al8.x86_64执行如下命令，确认
nvidia.ko模块是否在当前内核版本目录下。find /usr/lib -name nvidia.ko /usr/lib/modules/5.10.134-16.1.al8.x86_64/kernel/drivers/video/nvidia.ko如果路径中显示的内核版本与执行
uname -r获取到的内核版本不一致，表明驱动异常是由升级内核导致的。
解决方案
重新安装驱动。
NVIDIA-SMI的驱动故障
故障描述
可以根据执行nvidia-smi获取的状态码来判断驱动是否存在问题。例如下表所示。
nvidia-smi状态码 | 说明 |
3 | 请求的操作在目标设备上不可用。可能是目标节点上的设备不支持 |
6 | 查找GPU设备的查询失败，驱动问题。 |
9 | 未加载NVIDIA驱动，驱动问题。 |
容器化环境故障
容器化环境故障主要指NVIDIA Container Runtime以及Device Plugin等组件出现故障，导致在ACK集群中无法使用节点GPU资源。
NVIDIA Container Runtime故障
NVIDIA Container Runtime是NVIDIA推出的一种容器运行时包装器（Wrapper），以便在容器化环境中更好地支持GPU设备。它允许用户在Docker或containerd容器中快速部署GPU应用，无需进行复杂的配置和设置。
Container Runtime配置文件不正确
故障描述
当一个容器设置环境变量NVIDIA_VISIBLE_DEVICES后，容器内部并未发现GPU设备，执行nvidia-smi也出现报错。
nvidia-smi
bash: nvidia-smi: command not found在容器查看/dev目录下的设备文件，并未出现GPU设备。
ls /dev/nvidia*
ls: cannot access '/dev/nvidia*': No such file or directory此问题可能是因为节点上的Container Runtime配置文件并未生效（或者没有配置）。
containerd
在containerd中，Container Runtime配置文件位于/etc/containerd/config.toml。下方示例中，第4～12行为NVIDIA Container Runtime的配置。
containerd:
...... # 省略其他
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"
privileged_without_host_devices = false
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
BinaryName = "nvidia-container-runtime" # 配置nvidia container runtime
NoPivotRoot = false
NoNewKeyring = false
SystemdCgroup = true
..... # 省略其他Docker
在Docker中，Container Runtime配置文件位于/etc/docker/daemon.json。下方示例中，第2～8行为NVIDIA Container Runtime的配置。
{
"default-runtime": "nvidia",
"runtimes": {
"nvidia": {
"path": "/usr/bin/nvidia-container-runtime",
"runtimeArgs": []
}
},
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m",
"max-file": "10"
},
"bip": "169.254.123.1/24",
"oom-score-adjust": -1000,
"registry-mirrors": ["https://pqbap4ya.mirror.aliyuncs.com"],
"storage-driver": "overlay2",
"storage-opts":["overlay2.override_kernel_check=true"],
"live-restore": true
}默认情况下，ACK的GPU节点会自动在Container Runtime配置文件中完成NVIDIA Container Runtime相关配置。但在某些情况下，Container Runtime被修改后可能会导致NVIDIA Container Runtime配置丢失，NVIDIA Container Runtime无法正常工作。
解决方案
在Container Runtime配置文件中，手动添加NVIDIA Container Runtime的配置，然后重启Container Runtime。
NVIDIA Device Plugin故障
Device Plugin与kubelet gRPC连接中断
故障描述
Device Plugin启动时，正常上报节点GPU资源，但在运行一段随机时间后，节点GPU资源数变成0，而此时Device Plugin仍在正常运行。
查看节点上报GPU资源数为0的示例如下。
kubectl get nodes cn-beijing.192.168.2.180 -oyaml | grep nvidia.com
f:nvidia.com/gpu: {}
f:nvidia.com/gpu: {}
nvidia.com/gpu: "0"
nvidia.com/gpu: "0"同时查看Device Plugin状态，其正常运行，日志显示也正常。
kubectl get po -n kube-system nvidia-device-plugin-cn-beijing.192.168.2.180
NAME READY STATUS RESTARTS AGE
nvidia-device-plugin-cn-beijing.192.168.2.180 1/1 Running 0 4h12m此问题可能是因为Device Plugin与kubelet之间gRPC连接由于某些原因意外中断，导致节点上报GPU资源数为0，调度器不会在该节点上调度并运行GPU任务，造成节点GPU资源的浪费。
解决方案
重新创建Device Plugin Pod，并参见GPU Device-Plugin重启重启Device Plugin。
应用故障
某些时候，应用的运行失败有可能是由于应用本身代码存在缺陷或者配置有问题。
XID错误表明的业务应用故障
故障描述
XID错误也可以表示一些由于用户应用程序原因而导致的问题。以下列举一些比较常见的与业务应用相关的XID的错误以及其错误原因。
XID | 说明 |
13 | Graphics Engine Exception. 通常是数组越界、指令错误，小概率是硬件问题。 |
31 | GPU memory page fault. 通常是应用程序的非法地址访问，极小概率是驱动或者硬件问题。 |
43 | GPU stopped processing. 通常是应用自身错误，而非硬件问题。 |
45 | Preemptive cleanup, due to previous errors -- Most likely to see when running multiple cuda applications and hitting a DBE. 通常是终端用户手动退出或者其他故障（硬件、资源限制等）导致 GPU 应用退出，XID 45只是一个结果，底层原因通常需要日志分析。 |
解决方案
尝试重置正在运行的应用程序或修复代码错误。
容器对CUDA版本的限制
故障描述
在GPU容器启动时，有时会遇到类似于Fails with CUDA driver version is insufficient for CUDA runtime version的错误。这是因为宿主机上的NVIDIA驱动版本无法满足业务容器依赖的CUDA版本，且在业务容器中存在类似NVIDIA_REQUIRE_CUDA="cuda>=11.1 driver>=450.80.02"的环境变量。NVIDIA Container Runtime会在启动容器时校验CUDA版本的兼容性，不满足条件则拒绝启动容器。
解决方案
修改业务容器中对应的限制校验，也可以变更业务容器中的CUDA版本依赖或者调整宿主机上的NVIDIA驱动版本。
NCCL Hang问题
NCCL（NVIDIA Collective Communications Library）是NVIDIA的一个集合通信库，旨在提高多GPU和多节点环境中的集合数据通信效率。上层应用程序在使用NCCL的过程中会遇到一些错误，最常见的是NCCL Hang的问题，即在执行集合通信操作时，通信进程无法继续或无法完成，导致应用程序无法继续执行。
故障描述
应用了NCCL的应用程序在运行过程中有可能遇到由于IO阻塞或通信异常而导致的NCCL阻塞的问题。表现为GPU进程中的一个或多个线程已停止在用户态运行，也无法自行终止，整个进程处于Z状态，成为僵尸进程（Zombie State）。
解决方案
重启节点，强制结束该进程。
GPU容器运行一段时间后设备无法访问
故障描述
某些场景下，申请GPU的容器运行一段时间后执行nvidia-smi后返回如下错误。
nvidia-smi
Failed to initialize NVML: Unknown Error同时查看容器的/sys/fs/cgroup/devices/devices.list文件内容已被修改为如下内容。
....... # 省略其他
c 195:0 m # 原始内容为c 195:0 rw，也就是设备权限被修改。
....... # 省略其他这是因为节点执行systemctl daemon-reload、systemctl daemon-reexec等操作时会更新cgroup相关配置，进而影响NVIDIA GPU设备在容器中的正常使用。更多信息，请参见#1671。
解决方案
修复方式，请参见#1730。
cGPU故障
cGPU是ACK集群中实现共享GPU调度和显存隔离的组件。更多信息，请参见安装共享GPU调度组件。
内核升级导致的编译版本过期
故障描述
cGPU的安装不是单纯的文件复制过程，而是“半编译包”，即驱动的一部分为预先编译，而另一部分则需要基于系统的内核开发包（kernel-devel）进行现场编译。cGPU和编译时依赖的内核版本强相关。如果在安装cGPU后进行了内核升级，可能会导致cGPU不可用。
解决方案
卸载cGPU，重新安装。关于如何卸载cGPU，请参见升级节点cGPU版本。
相关文档
您可以发起GPU节点诊断，根据诊断结果定位和解决问题。更多信息，请参见自助诊断GPU节点问题。
关于使用GPU节点过程中可能会遇到的一些常见问题，请参见GPU FAQ。