GPU 监控指标与 XID 故障速查——一线运维的 6 张表

训练突然变慢、推理延迟升高、GPU 从 nvidia-smi 中消失，一线运维需要先回答三个问题：影响了谁、还能否继续运行、下一步该交给谁处理。

本文面向 H800、A100 与 GeForce RTX 4090 等混合集群，把指标解释、Xid 分流、取证与升级整理为六张表。它们用于缩小排查范围，不能替代设备具体型号、驱动版本和服务器厂商的诊断流程。

先记住处置顺序

确认业务影响 → 留存现场 → 限制故障资源继续接单 → 按恢复要求处理 → 验证后重新纳管。 若业务或数据风险仍在持续，取证与隔离应并行推进。

应用异常不一定需要重启节点；隔离节点也不意味着已经认定 GPU 硬件损坏。发生故障时，先关联同一时刻的应用、驱动、PCIe、NVLink 和 BMC 事件，再确定影响范围。

同一场 GPU 异常，可以用三层证据来解释：先确认任务影响，再把设备状态、历史趋势与事件时间线对齐。

表 1：nvidia-smi 必看的 8 个健康字段

先运行一次查询。命令包含表中的八个健康字段，以及时间、UUID、PCI 地址等定位信息：

nvidia-smi \
  --query-gpu=timestamp,index,uuid,pci.bus_id,name,temperature.gpu,utilization.gpu,memory.used,memory.total,power.draw,power.limit,pstate,ecc.errors.uncorrected.volatile.total \
  --format=csv

字段含义与支持范围见 NVIDIA-SMI 文档。返回 N/A 表示不可用或不支持，不能转换成“0 错误”；4090 尤其不能照搬数据中心卡的 ECC 监控能力。

需要连续观察时，可在查询末尾加 --loop=2。nvidia-smi 并非只能以 1Hz 查询，也支持 --loop-ms；但轮询加快不会自动提高底层传感器或硬件计数器的更新速度。脚本长期采集更适合使用 NVML 或 exporter。

运维记录应以 GPU UUID + PCI Bus ID 定位设备，index 只用于当次查询。卡序号可能在重启后变化；volatile ECC 计数也可能随驱动重新加载而归零，不能把重启后的零值当作从未发生故障。

表 2：DCGM 与 exporter 的重点指标

DCGM 的价值在于集中采集、活动计数器和健康诊断，而不是“它总比 nvidia-smi 采样快”。生产环境还需分别配置 DCGM 更新周期、exporter 采集周期与 Prometheus 抓取周期。

以下使用常见 dcgm-exporter 输出名。实际导出的字段取决于版本、采集配置、GPU 和权限；部分字段默认未启用。DCGM API 文档中的底层名称也可能已经改为 *_UTIL_RATIO 等写法，不能把 API 名称直接当作 Prometheus 指标名。官方采集配置、exporter 指标映射

Profiling 指标是时间窗口平均值。单位和活动定义见 DCGM Profiling 文档。换算时，0.25 才是 25%；NVLink 的 bytes/s 转十进制 GB/s 应除以 1e9，同时确认是整卡聚合还是单链路、单向还是双向。

在目标节点上先确认支持范围：

dcgmi discovery -l
dcgmi profile --help
dcgmi profile -l -i 0

# 以下假设 exporter 暴露在本机默认端口，且允许本机访问
curl -fsS http://127.0.0.1:9400/metrics

非数据中心 GPU 的 DCGM 功能有限，Profiling 官方支持范围也不能直接外推到 GeForce。4090 或 MIG 环境出现缺项时，应先检查支持矩阵、配置和实体范围，而不是补零后显示为“健康”。MIG 实例与整卡的指标不能混在同一个容量或利用率分母中。DCGM 平台说明

**关于 Xid 告警：**不要对 DCGM_FI_DEV_XID_ERRORS 使用 rate() 或 increase() 统计次数；changes() 也会漏掉连续重复的相同代码。事件计数优先从内核日志生成，或者使用已核实版本语义的 exporter 事件计数指标。新版提供的 DCGM_EXP_XID_ERRORS_TOTAL 与旧的代码值 Gauge 并不是同一指标。exporter 指标类型说明

“GPU 利用率 90%、Tensor 活动 25%”只能作为进一步分析的线索。通信等待、访存瓶颈、小 batch、算子混合和采样平均都可能影响读数；要定位到算子，应在可控复现环境使用 Nsight Systems / Compute，并协调它们与 DCGM Profiling 的计数器占用。

表 3：重点 Xid 错误与第一步动作

Xid 是驱动记录的错误事件代码，不是“故障部件编号”。先查看故障前后的完整事件序列、关联进程和恢复要求；同一时间多张卡报警时，后续 Xid 可能只是对端故障的连带结果。

下表给出分诊方向。具体代码定义以 NVIDIA Xid Catalog 为准；内存恢复另参考 GPU Memory Error Management。

Xid 31：先复现应用，也保留硬件证据

如果只有某个版本的应用稳定触发异常，而其他工作正常，优先交给应用团队定位。最小复现可以在测试环境使用：

# ./your_app 替换为已准备好的最小复现程序
compute-sanitizer --tool memcheck ./your_app

该工具用于检查设备内存访问错误，会改变运行开销，不宜直接套在满负载生产任务上。若不同应用都在同一设备失败，或同时出现 ECC、PCIe 错误，应并行升级平台排查，而不是宣布“确定是代码 bug”。Compute Sanitizer 文档

Xid 79：查“为什么访问不到”，不要先判卡坏

保存 GPU UUID、PCI 地址和故障前后的内核日志，检查 lspci 是否仍能枚举设备，并关联上游 PCIe、riser、供电与 BMC 事件。GPU 掉线时，设备侧工具本身也可能失败，因此主机和带外日志尤其重要。

跨槽位或跨服务器对照测试，应由硬件团队在停机条件下执行，确认问题跟随板卡还是留在平台；SXM 模组不能套用普通 PCIe 插卡的现场操作方式。节点分诊指南、供应商升级流程参考

Xid 119 / 120：先处理 GSP 和驱动恢复链路

GSP 是 GPU System Processor。遇到 119/120，记录驱动分支、GSP 固件版本、近期升级和复现频率，收集 bug report 后按要求执行 GPU reset 或节点重启 / 断电重启。若恢复后仍复现，将材料交给供应商继续定位；一次事件不能证明必须返厂。GSP 错误定义

从报警到恢复：先保留现场，再按证据分流；存在持续业务或数据风险时，取证与资源隔离并行。

表 4：工具、日志与取证位置

最小取证命令

以下命令只采集现场，不进行 reset。假设使用 systemd，且已安装 NVIDIA 驱动、pciutils 和 GNU timeout：

umask 077
GPU_EVIDENCE_DIR="gpu-evidence-$(date -u +%Y%m%dT%H%M%SZ)"
mkdir -p "$GPU_EVIDENCE_DIR"

date -u --iso-8601=seconds > "$GPU_EVIDENCE_DIR/collected-at.txt"
uname -a > "$GPU_EVIDENCE_DIR/uname.txt"

# 先保留完整内核时间线，再另外筛选
sudo journalctl -k -b --since '1 hour ago' \
  --utc -o short-iso-precise --no-pager \
  > "$GPU_EVIDENCE_DIR/kernel.log" 2>&1

# 超时或命令失败时，记录输出与返回码，继续其他取证
timeout 20s nvidia-smi -q \
  > "$GPU_EVIDENCE_DIR/nvidia-smi-q.txt" 2>&1
printf '%s\n' "$?" > "$GPU_EVIDENCE_DIR/nvidia-smi-q.exit-code.txt"

sudo lspci -Dnnvv > "$GPU_EVIDENCE_DIR/lspci.txt" 2>&1

grep -Ei 'NVRM|Xid|SXid|AER|PCIe|NVIDIA' \
  "$GPU_EVIDENCE_DIR/kernel.log" \
  > "$GPU_EVIDENCE_DIR/kernel-filtered.log"

# 默认在当前目录生成 nvidia-bug-report.log.gz
(cd "$GPU_EVIDENCE_DIR" && sudo nvidia-bug-report.sh)

若取证命令卡住，应保留已经得到的部分材料和失败记录，不要因此无限期推迟故障隔离。重启后补充日志时，应明确区分“故障现场”和“恢复后”两个阶段。采集包可能包含主机、进程和路径信息，对外提交前按组织要求脱敏。

没有持久化 journal 的节点，重启后未必能读取上一轮启动日志；应提前配置日志留存或远程采集。/var/log/syslog、/var/log/messages 是否存在取决于发行版和日志配置；/var/log/nvidia-installer.log 主要记录安装过程，不是运行时 Xid 的主日志。NVIDIA 事件取证要求、bug report 说明

DCGM 诊断不要写成固定的“5 分钟 / 30 分钟”

在支持的设备上，按维护流程确认测试范围和业务已迁出后执行：

dcgmi diag --help

# 短测试，主要检查软件和部署条件
dcgmi diag -r 1 -j > dcgm-short.json

# 长测试：可能施加显存、计算、功耗和互连负载
dcgmi diag -r 3 -j > dcgm-long.json

诊断耗时与版本、卡数、测试插件和参数有关，不能承诺固定时长。FAIL 需要进一步读取失败项：权限、部署、温度和硬件异常都可能造成失败；SKIP、不支持或无法执行也不能写成 PASS。DCGM Diagnostics 不替代厂商现场诊断，也不直接授予 RMA 资格。DCGM Diagnostics 文档

表 5：温度与功耗阈值，按设备建立基线

H800、A100 的不同板型，以及 4090 的不同厂商设计，都不应共用一组温度和功率上限。先读取设备报告，再对照整机环境要求：

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

# 核对当前驱动支持哪些细分查询字段
nvidia-smi --help-query-gpu

温度和时钟原因的定义见 NVIDIA-SMI 温度与性能说明。若设备只提供 T.Limit 温度余量，应按该字段的语义读取，不能当作绝对摄氏温度。

**一个本地告警策略示例：**设备提供有效的 Max Operating 温度时，可先以“距该温度不超过 5°C，持续 5 分钟”作为预警起点，再根据厂商建议和负载验证调整。这里的 5°C、5 分钟是示例策略，不是 NVIDIA 官方通用阈值；已经发生持续热降频、设备掉线或数据错误时，不应等待预警窗口结束。

低 GPU 利用率、低 Tensor 活动和接近功率上限，也应先与同型号、同任务阶段的基线比较。排查性能下降时，同时看计算、通信、存储、CPU、时钟和散热，避免仅凭一项读数更换硬件。

表 6：什么时候隔离、什么时候升级、什么时候申请返修

停止接单是控制影响的措施；RMA 是依据产品政策和诊断证据做出的返修决定。 两者可以相隔多个排查步骤。

NVIDIA 对行重映射的 RMA 政策强调 failure 标志及现场诊断验证；SRAM 另有对应标志和条件。不要把旧架构页退役数量直接移植到 A100 / H800 的行重映射判断中。内存 RMA 政策

NVLink 的累计 CRC 错误也不等于 bit error rate：需要明确计数对象、时间窗口、链路流量分母和硬件代际，再按供应商规则解释。4090 不具备 NVLink，相关项应标为不适用。GeForce RTX 4090 官方规格

Kubernetes：cordon 只是停止常规新增调度

确定需要从节点层面阻止新增作业时，可以先执行：

# 替换为已确认的故障节点名称
kubectl cordon NODE_NAME

cordon 不会迁走正在运行的 Pod，也不是设备已经停止使用的证明。后续驱逐、训练 checkpoint、跨节点作业整体退出和 GPU reset，要按业务与集群维护流程协调；单卡可隔离的调度环境，也不必一律扩大为整机下线。Kubernetes 节点维护文档

GPU reset 会影响设备上的工作，并受 MIG、NVLink / NVSwitch、Fabric Manager 和虚拟化方式限制。因此不要把 reset 或节点重启直接绑定到某个 Xid 自动执行。恢复前确认目标设备、相关进程和互连影响，恢复后检查错误状态、执行支持的诊断，再运行代表性工作负载。GPU Reset 能力与限制

升级工单应包含什么

将以下信息随工单一次提交，便于运维、应用和硬件团队对齐现场：

• 时间与身份：带时区的首次 / 最近发生时间、节点名、GPU UUID、PCI 地址、可获得的板卡序列号。
• 软件与任务：OS、内核、驱动、GSP 固件、DCGM / exporter 版本，以及任务 ID、镜像和近期变更。
• 原始证据：完整 Xid 前后文、bug report、BMC / AER、需要时的 Fabric Manager / SXid 日志。
• 影响与处置：受影响的卡、节点、任务，是否隔离，已做过哪些 reset / 重启，以及恢复后是否复现。
• 验证结果：诊断失败项、最小复现、正常设备对照及业务恢复表现；不支持和未执行的项目应明确标记。

九章智算云客户可按实际服务渠道提交上述材料。告警聚合、自动工单和控制台入口以具体部署及交付配置为准，不作为本文对所有环境的统一功能承诺。

一线速查真正需要记住的是：指标异常先关联业务，Xid 先还原上下文，恢复先确认影响范围，返修先准备可复核的证据。