GPU硬件与驱动故障诊断

状态：草稿（更新于2026-10-06）。 本文内容主要基于官方文档确认的表述， 仅在三种消费级GPU上以只读方式确认过的内容（第10节末尾的“实测”部分） 是直接确认的值。未能测量数据中心GPU及真实的故障事件。 请先阅读文章末尾的“确认的版本和日期”与“未确认的内容”。 编写规则：以实测数据为基础，未能测量的内容标注为“未实测”。

目录

• 摘要
• 1. 信号流经的路径
• 2. 消费级GPU与数据中心GPU
• 3. 如何读取XID
• 4. ECC、行重映射与退役
• 5. NVLink、NVSwitch与Fabric Manager
• 6. 降频与PCIe降级
• 7. 一个慢速GPU拖慢整体
• 8. Kubernetes应对策略：隔离与自动恢复
• 9. 告警设计
• 10. 动手尝试（只读）
• 外部依据：通过论文和官方资料确认的内容
• 11. 面试可能问到的问题
• 12. 常见的误解
• 13. 参考资料与确认的版本
  • 实测：在三种消费级GPU上读取的值（只读）

摘要

GPU故障诊断本质上是读取三路信号的工作：内核日志中的XID消息、DCGM（Data Center GPU Manager）与 nvidia-smi 指标，以及Kubernetes的节点状态。

读完本文后在面试中能够阐述的内容

1. 如何按照“编号、目录中的立即处理桶、是否单独发生”的顺序读取XID，从而区分应用错误与硬件错误
2. ECC、NVLink、降频、PCIe降级会通过哪些指标和代码体现出来，以及如何找出拖慢整体的慢速GPU
3. 自动隔离与恢复流水线的构建，以及哪些情况触发页寻呼（Page）告警、哪些情况作为工单保留的标准

1. 信号流经的路径

GPU + 드라이버(NVML)
 ├─ 커널 로그 "NVRM: Xid (PCI:0000:ca:00): 79, ..." ─► 로그 수집기(syslog 모니터)
 ├─ NVML 이벤트(XID) ─► 디바이스 플러그인 ─► 장치 unhealthy ─► kubelet allocatable 감소
 └─ DCGM ─┬─ dcgm-exporter :9400/metrics ─► Prometheus ─► 알림
          └─ health watch, dcgmi diag (능동 점검)

这是dcgm-exporter默认指标文件（default-counters.csv, main）中用于诊断的指标。括号内为默认状态。

由于DCGM API文档中的字段名（例如： ..._TEMP_CELSIUS）可能与exporter指标名不同，请以所使用的exporter的CSV为准。

2. 消费级GPU与数据中心GPU

这是实验环境中的实测结果。在8GB级笔记本GPU（驱动595.91.07）的dcgm-exporter原文中没有 XID_ERRORS 和 PROF_* 行，且 MEMORY_TEMP 与重映射行指标为0。0是代表“支持且正常”还是“不支持故为0”，以及XID行缺失的原因是exporter版本问题还是消费级GPU限制，均未确认。XID目录的“适用对象”列也仅限A100及以上数据中心产品。

3. 如何读取XID

格式为 NVRM: Xid (PCI 주소): 번호, 부가 정보 。读取顺序为：① 目录中的立即处理桶，② 是单独（solo）发生还是与其他XID一同发生（45也会作为其他错误的结果被记录），③ 在同一个GPU上是否重复发生。处理桶包括 RESTART_APP（仅重启应用）、 RESET_GPU, RESTART_BM（重启节点）、 IGNORE, CONTACT_SUPPORT 。Xid 154 会告知所需的恢复操作（None, Drain P2P, Drain and Reset, GPU Reset Required, Node Reboot Required）。

由于目录称31更常见于应用侧，而GPU调试指南将其称为“Suspected Hardware Problems”（疑似硬件问题），因此需要直接建立“单次出现为应用、重复出现为硬件”的分支判断。设备插件将13、31、43、45、68、109硬编码为“应用错误”并予以忽略，而在NVML发出Critical告警的其余XID中将设备标记为unhealthy（源码）。由于源码中的FIXME提到没有从unhealthy恢复的路径，因此推测重置后需要重启插件（未确认）。

4. ECC、行重映射与退役

单比特错误由硬件纠正，双比特错误仅用于检测。计数器分为驱动加载后的volatile（易失性）和终身累计的aggregate。Ampere之后，行重映射替代了页面退役（旧型号最多64个），最多可重映射512次，应用时需要重置GPU。重映射失败标志会在以下情况出现：向已重映射8行的bank再次尝试、向已重映射的行再次尝试、或者总次数达到512次，这是进行RMA（退货授权）判断的依据。依据文档以A100及之后为准。

nvidia-smi -q -d ECC,ROW_REMAPPER,PAGE_RETIREMENT

5. NVLink、NVSwitch与Fabric Manager

Fabric Manager（FM）在NVSwitch系统中将所有GPU绑定为一个内存结构（Memory Fabric）并监控链路。HGX A100如果在FM初始化之前启动CUDA，则会产生 cudaErrorSystemNotReady 。Hopper之后，GPU和交换机会自行进行链路学习，重置时不再需要FM。FM必须与驱动版本保持一致。如果出现74，则通过 nvidia-smi nvlink -e 查看CRC、replay、recovery错误计数器。致命的SXid会中断CUDA任务并同时留下74和45。Blackwell系列针对NVLink 5使用XID 144到150号段，且不再应用SXid。Ampere NVSwitch系统仅在FM运行时才能逐个重置GPU，否则需要将NVLink绑定的GPU一同重置。

6. 降频与PCIe降级

clocks_event_reasons 是一个位掩码。其取值分别为：GPU空闲 0x1、应用程序时钟 0x2、软件功率上限 0x4、硬件减速 0x8、同步提升 0x10、软件散热 0x20、硬件散热 0x40、硬件功率刹车 0x80、显示时钟 0x100、板卡限制 0x200、可靠性 0x400（go-nvml）。其中 0x8 和 0x40 会将核心时钟降至一半以下，0x80 是外部电源刹车信号，意义重大。Llama 3论文记载，由于正午气温原因，吞吐量呈日周期性变化1%到2%。PCIe需对比 pcie.link.gen.current 和 pcie.link.gen.max, pcie.link.width.current ，但根据手册说明，当前值在空闲时可能会降低，因此必须在负载状态下测量。重试次数为 PCIE_REPLAY_COUNTER ，DCGM health的示例输出将每分钟超过8次视为警告。

7. 一个慢速GPU拖慢整体

Meta报告称，在Llama 3 405B历时54天的区间内，发生了466次中断（其中意外中断419次），约78%的意外中断由硬件原因引起（其中GPU占58.7%）。查阅论文原文发现，正文中虽然记录了58.7%，但这是将表5中打印的比例相加得出的；若按表中具体次数重新统计，GPU分类对应的次数为268次，占419次的64.0%（表中“Faulty GPU”的30.1%似乎是与148次这一计数不符的印刷错误，按计数算为35.3%）。这些内容已整理在下文的“外部依据”中。同一篇文章指出，运行正常但速度缓慢的落后者很难被发现，单个慢速GPU会拖慢数千个GPU，并且表现为通信迟缓。排查顺序为笔者整理：① 比较各Rank的步骤及集合通信时间（PyTorch flight recorder）。② 将慢速Rank GPU的降频原因、温度、功率、PCIe代际与宽度、NVLink错误并排对照。③ 清空节点后，使用 dcgmi diag -r 3（包含targeted_stress、nvbandwidth、nccl_tests）进行确认。DCGM文档明确指出，这并不能替代全面的硬件诊断以及RMA的依据。

8. Kubernetes应对策略：隔离与自动恢复

flowchart LR
  D["탐지<br/>XID, DCGM, 플러그인"] --> C["분류<br/>카탈로그 버킷, 반복 여부"]
  C --> Q["cordon·taint"]
  Q --> R["drain<br/>PDB 존중"]
  R --> X["복구<br/>GPU 리셋, 노드 재시작, 교체"]
  X --> V["검증<br/>dcgmi diag -r 1 또는 2"]
  V --> U["uncordon"]
  X -. 반복 실패 .-> H["사람 호출"]

即使变为unhealthy状态，已分配的Pod仍然绑定在该设备上（Kubernetes文档），因此必须进行排水（Drain）。1.36的 ResourceHealthStatus（Beta版）通过容器状态 allocatedResourcesStatus 告知设备健康状况。NVSentinel（v1.25.0，Beta/Stable，Kubernetes 1.34+，需要独立版DCGM）使用内置目录对DCGM和syslog的XID进行分类，进而串联起cordon、drain、重置与重启流程，并且如果节点在5分钟内有50%被cordon则会触发熔断器停止操作，默认仅开启监控。Amazon EKS的node monitoring agent将常见的XID映射为节点条件 AcceleratedHardwareReady=False 提升至 48 则执行重启，74 和 79 则记录为更换，未知的 XID 仅作为事件保留。在联系厂商之前， nvidia-bug-report.sh 请收集输出、FM 日志以及 DCGM 诊断日志（参考 GPU 调试指南）。

9. 告警设计

Google SRE 书中提到：“如果响应是机械化的，那它就不是 Page。”以下是我据此提出的建议。

10. 动手尝试（只读）

# GPU 가 있는 노드에서 실행
journalctl -k --no-pager | grep -E "NVRM: Xid" | tail   # dmesg 가 막힌 계정에서도 읽힘, 아래 「실측」 참고
nvidia-smi --query-gpu=index,name,pcie.link.gen.current,pcie.link.gen.max,pcie.link.width.current,temperature.gpu,power.draw,clocks_event_reasons.active --format=csv
nvidia-smi -q -d PERFORMANCE,ECC,ROW_REMAPPER | head -80

# 쿠버네티스에서 dcgm-exporter 지표 확인
kubectl -n gpu-operator get po -l app=nvidia-dcgm-exporter -o wide
curl -s http://<파드IP>:9400/metrics | grep -E "XID|REMAP|PCIE_REPLAY|VIOLATION"

在仅查看使用率、功耗、温度、VRAM 和时钟的仪表盘中，很容易漏掉 GPU 专用的告警规则。笔者曾观察到在 8GB 卡上，服务器进程的分配器缓存仅在 6 分钟内就从 6.4 GB 增长到了 7.8 GB，这种 VRAM 趋势是练习配置告警的极佳素材。

外部依据：通过论文和官方资料确认的内容

由于没有数据中心 GPU 和大规模集群，我们无法直接测量实际故障事件。相反，我们翻阅了大规模运营报告和 NVIDIA 官方文档，比对叙述了 11 篇资料。由于设备和条件不同，外部数据仅用于判断方向是否一致。

厂商数据仅搬运了正文中明确记录条件的资料，未能打开论文正文的资料则未予使用。

11. 面试常见问题

1. 看到了 XID 79。应该怎么做？ 这意味着无法通过 PCIe 访问 GPU，目录分类为重启节点。在执行 cordon 和 drain 后重启，如果反复出现，则检查链路、电源和系统事件日志并进行更换。
2. XID 13 和 48 该如何处理？ XID 13 通常是应用错误，应用 Compute Sanitizer 查看；如果同一 TPC/GPC 中反复出现，则怀疑是硬件问题。XID 48 是无法纠正的 ECC，需要重置或重启；如果伴随 63 或 64，则在 drain 后重置。
3. 如何找到单张变慢的 GPU？ 通过各 rank 的通信时间缩小可疑 rank 范围，并对比该 GPU 的降频原因、温度、PCIe 和 NVLink 错误。在清空节点后， dcgmi diag -r 3 进行确认。
4. 在自动恢复中需要注意什么？ 设置并发上限和断路器，防止一次性隔离过多设备，重复失败的情况则交由人工处理。重置时必须确保没有进程在使用 GPU。
5. 什么情况下触发 Page？ 机械化处理的事件应实现自动化并仅保留记录。当自动恢复失败或重复发生、可用 GPU 低于阈值时，触发 Page。

12. 常见误区

• “只要打印了 XID，GPU 就坏了”：13、31、43、45 通常是应用错误。
• 「XID_ERRORS “ 是错误次数”：这只是最后的 XID 值。
• “使用率高就是正常的”：运行缓慢的 GPU 其使用率同样很高。

13. 参考资料与确认版本

全部于 2026-10-05 访问。

• https://docs.nvidia.com/deploy/xid-errors/（目录，最后更新 2026-09-09）
• https://docs.nvidia.com/deploy/a100-gpu-mem-error-mgmt/ , https://docs.nvidia.com/deploy/gpu-debug-guidelines/
• https://docs.nvidia.com/datacenter/dcgm/latest/（feature-overview, dcgm-diagnostics, getting-started, dcgm-api-field-ids）
• https://github.com/NVIDIA/dcgm-exporter（default-counters.csv）, https://github.com/NVIDIA/k8s-device-plugin（health.go）, https://github.com/NVIDIA/go-nvml（const.go）
• https://docs.nvidia.com/deploy/nvidia-smi/index.html , https://docs.nvidia.com/datacenter/tesla/fabric-manager-user-guide/index.html
• https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/troubleshooting.html
• https://github.com/NVIDIA/NVSentinel , https://docs.nvidia.com/nvsentinel/ , https://docs.aws.amazon.com/eks/latest/userguide/node-health-nma.html
• https://arxiv.org/abs/2407.21783 , https://arxiv.org/abs/2505.05713 , https://sre.google/sre-book/monitoring-distributed-systems/
• https://docs.pytorch.org/tutorials/unstable/flight_recorder_tutorial.html , https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/

实测：从三款消费级 GPU 读取的值（只读）

在台式机 24GB 级（Ampere 架构，驱动 570.195.03）、笔记本 8GB 级（Ada 架构，595.91.07）、笔记本 6GB 级（Ampere 架构，595.91.07）中读取了 nvidia-smi -q -d ECC,ROW_REMAPPER,PAGE_RETIREMENT, --query-gpu 字段和内核日志。三者均处于空闲状态，未做任何更改。

• 第 2 节表格中提到的“GA10x·Ada 列显示行重映射”因产品而异。 Ampere 架构的两款消费级型号返回了 N/A，只有 Ada 架构的笔记本返回了数值。在该 GPU 上，0 表示“支持且正常”；而在不支持的 GPU 上，相同的查询返回的不是 0 而是 N/A。因此，在仪表盘中必须区分 N/A 和 0，不能因为数值一直为 0 就认为它正常。第 2 节中 8GB 级笔记本 GPU 的 exporter 显示的重映射 0 与该值一致。
• 在这三款型号（GDDR6 世代）中，未暴露 ECC 计数器。 由于这三种型号均为 N/A，因此无法通过硬件计数器捕获内存错误，只能依赖 Xid 日志和应用的异常行为。我们不能笼统地认为“消费级 GPU 没有 ECC”。NVIDIA 的 RTX Blackwell 白皮书指出，GDDR7 的 ECC 内置于 DRAM 晶圆中，始终处于开启状态且无法通过软件关闭（是否能看到计数器则另当别论），而且我没有找到直接说明 RTX 30/40 系列消费级产品没有 ECC 的官方文档（nvidia-smi 文档中“消费级产品的信息非常有限”的表述以及 ECC 模式项需要 InfoROM 对象的表述是间接依据）。
• 查询字段名称在驱动 570 和 595 中均有效。 remapped_rows.correctable, remapped_rows.uncorrectable, remapped_rows.pending, remapped_rows.failure, retired_pages.pending, ecc.errors.corrected.volatile.total, inforom.ecc, clocks_event_reasons.hw_thermal_slowdown, clocks_event_reasons.sw_power_cap, pcie.link.gen.gpucurrent 返回了没有错误的数值或 [N/A] 。也就是说，并没有出现字段名称错误的报错，因此 N/A 并不意味着没有该字段，而是表示 GPU 未提供该数值。
• 内核日志可能被阻止读取 dmesg 。 三个节点的 kernel.dmesg_restrict=1 均为 ，因此普通账号的 dmesg 以 read kernel buffer failed: Operation not permitted 失败，而 journalctl -k 则被成功读取。由于被告知需要 sudo 的命令在无密码账号中会被阻止，因此运维检查脚本最好优先使用 journalctl -k 。
• grep -iE "NVRM|Xid" 用于捕获错误的行。 在诸如此类的日志中，该模式同时捕获了 (1) 打印了芯片修订版本的 NIC 驱动程序行以及 (2) 非 Xid 的 XID 541 消息（分配失败 NVRM: ）。 NV_ERR_NO_MEMORY由于这两者都不是 GPU 故障，因此报警规则和检查命令应缩小范围至 NVRM: Xid 。实际的 NVRM: Xid 行在三个节点上均为 0 条。
• PCIe 代数在空闲状态下已降至 1。 三个节点的 gpucurrent 均为 1，看起来与最大值 (4) 不同，但由于可能是空闲省电状态，第 6 节的降级判定必须在施加负载的状态下重新读取。其中一块笔记本 GPU 的宽度为 x8（最大 x16），这可能是出于设计原因，因此未作判定。
• 施加负载后重新进行了读取（一张 8GB 级笔记本 GPU）。 作为推理服务器施加了约 80 秒的负载，每 2 秒读取一次，共获得 38 个样本。PCIe 代数为最大值 4（37 个样本，其余 1 个为 2），宽度稳定在 8。SM 频率中位数为 2,640MHz（未达到最大值 3,105MHz，有样本在负载开始时降至 375MHz），功耗中位数为 78W，最大 91.8W，温度最高 63°C，使用率中位数为 100%。**所有 37 个负载样本中的限频原因均全为 0（无）**，仅有 1 个空闲样本为 0x01（空闲）。也就是说，在此负载下并未触发功耗上限或热降频，未达到最高频率似乎是根据负载和功耗策略且无限制原因导致的（推测）。即使在空闲状态下，如果有服务器进程占用 GPU，PCIe 代数也会保持在 4（6 个样本，SM 频率 1,890MHz，功耗 8.7W），而在没有进程的节点上读取到的代数 1 很可能是处于无上下文的省电状态（推测）。未测试实际触发热降频和功耗上限的高温密闭环境（持续 15 分钟的负载已在下方确认，未触发限频）。
• 即使在持续 15 分钟的负载下也没有触发限频原因（一张 8GB 级笔记本 GPU）。 使用同一台服务器连续施加 32 并发负载 15 分钟，以 2 秒为间隔读取了 443 个样本。PCIe 保持在代数 4、宽度 8，SM 频率中位数为 2,625MHz（范围 1,890~2,640），功耗中位数为 78W，最大 93.2W，温度最高 70°C。除了 1 个空闲比特样本外，限频原因全部为 0（没有样本触发功耗上限或热降频）。在同一时间段内，吞吐量为 829~832 tok/s，在 23 次测量中波动为 ±0.2%。最高温度比 80 秒测试时的 63°C 上升了 7°C，但在该环境中热量并未削减性能。这与数据中心的长时间训练或更炎热的环境有所不同。
• 确实遇到了施加负载后 PCIe 代数也没有上升的 GPU（一张 24GB 级桌面端 GPU）。 该 GPU 设备支持的最大链路为 16GT/s（代数 4）且宽度为 x16，但在矩阵乘法与主机到 GPU 复制重叠运行 25 秒后，已进入 P0 状态、使用率 100%、SM 频率 1,950MHz，然而 nvidia-smi 的当前代数仍然是 1，并且从主机端每 3 秒读取 20 次 /sys/bus/pci/devices/<장치>/current_link_speed 的数值也全部都是 2.5GT/s（代数 1）。在拥有 1GiB 固定（pinned）内存的主机上，主机到 GPU 传输速度为 1.7~1.9GB/s，GPU 到主机为 1.6~2.2GB/s，重复三次结果均相同。这大约是 PCIe 4.0 x16 理论带宽（约 31.5GB/s）的 6%。由于该 GPU 的内存带宽（读取 905GB/s）和计算吞吐量（fp16 矩阵乘法 63~71 TFLOPS）均正常，因此似乎是仅限链路被锁死在低代数的问题。原因（主板设置、省电策略、延长线、插槽）尚未查明（未确认）。由于该 GPU 的模型加载和 KV 卸载会受限于主机到 GPU 传输这一瓶颈，因此在加载 7GB 模型时仅传输就需要约 4 秒（7 ÷ 1.8），加载 8 篇 KV 的收益也会减少（计算得出）。检查方法有两种：在负载期间读取 nvidia-smi --query-gpu=pcie.link.gen.current,pcie.link.gen.max --format=csv ，并将主机的 current_link_speed 与 max_link_speed 进行比较。空闲时代数较低是正常的，但如果在 负载期间依然较低则是发生了降级。

局限性：仅测试了消费级的三种型号，未能遇到数据中心 GPU 的 ECC、行重映射失败、XID 79 等实际故障。DCGM 的 XID_ERRORS 指标为何不会在消费级 GPU 上显示（是 exporter 版本问题还是 GPU 限制），也无法通过本次测试区分（未确认）。

确认的版本：GPU Operator 26.7.1 捆绑包中的 DCGM 4.6.1-1、DCGM Exporter 4.6.1-4.8.4、Kubernetes 稳定版 v1.37.1。

未确认的事项：消费级 GPU 的 ECC、行重映射、XID 指标的实际输出，实验环境中 exporter 的版本，查询字段名（基于第三方公开的 --help-query-gpu 输出标准）在驱动 595 中是否有效，以及目录是否适用于消费级 GPU。告警等级表和调查顺序并非官方规定，而是本人的判断。