在 AI 算力集群和 GPU 运维的语境下，XID（或者写作 Xid） 是英伟达（NVIDIA）GPU 驱动抛出的系统级底层错误代码。
它是 SRE 和 AI Infra 工程师排查 GPU 故障时最权威、最直接的“判官”。当 GPU 发生硬件故障、驱动崩溃、应用层越界或网络死锁时，NVIDIA 的内核驱动程序（NVRM）会向操作系统的内核日志（syslog 或 dmesg）中打印一条包含特定 XID 数字的错误消息。
🔍 一、 如何发现和读取 XID 错误？
XID 并不是由 PyTorch 直接抛出的，它隐藏在系统内核的最底层。你可以通过以下三个渠道抓取它：
- 宿主机内核日志（最原始、最精准）：
在服务器终端运行以下命令，可以直接过滤出 XID 报错：
dmesg -T | grep -i NVRM
# 或者
journalctl -k | grep -i "Xid"典型的报错日志格式：
NVRM: Xid (PCI:0000:0e:00): 79, GPU has fallen off the bus.(这行日志意味着这物理槽位上的 GPU 掉卡了)
- Prometheus 监控监控（AIOps 实时告警）：
我们在dcgm_parameters_reference.md中提到的DCGM_FI_DEV_XID_ERRORS(Field ID 152) 指标，会实时捕获最近一次发生的 XID 错误代码。 - Kubernetes 容器事件：
如果宿主机安装了 NVIDIA Node Problem Detector (NPD)，XID 错误会被转化为 K8s Event，从而自动触发 Pod 驱逐。
🛠️ 二、 常见的 XID 故障代码大盘点
英伟达官方定义了上百个 XID 代码，但在大模型训练和 AI 算力集群中，最常遇到、杀伤力最大的主要是以下几类。我们将其分为：软件/算法导致的异常、硬件损坏（必须换卡）、以及驱动/固件卡死（需要复位/重启）。
1. 软件/算法与显存越界类（通常无需更换硬件，需算法优化）
| XID 代码 | 错误英文全称 | 物理含义与痛点 | 根因与 SRE/算法解决手段 |
|---|---|---|---|
| XID 31 | MMS-triggered Page Retirement |
显存页面退休事件或驱动分配异常。 通常伴随着显存耗尽或驱动在尝试回收不稳定的物理显存。 | 排查：检查显存占用。这通常是 OOM（显存溢出）的前兆或伴生现象。 |
| XID 45 | Preemption Timeout |
抢占超时。 某个 CUDA 核心上运行的计算任务太霸道、运行时间过长，拒绝释放（Yield）计算资源给其他任务。 | 根因：算法团队写了低效的 custom CUDA 算子、Triton 算子，或者代码中出现了死循环。 |
解决：优化算子，或调整驱动的抢占超时阈值。 |
| XID 62 | Address Translation Fault | 地址翻译故障（即 GPU 端的“段错误 Segment Fault”）。 GPU 尝试读写一个未分配、越界或已被释放的显存物理地址。 | 根因：极其经典的算法 Bug。多发生于 custom 算子中的指针越界，或者 PyTorch 与底层 CUDA 驱动的版本冲突。
解决：使用 cuda-gdb 或 compute-sanitizer 调试算法代码，定位越界的张量。 |
2. 物理硬件损坏类（P0级灾难，通常必须联系厂商换卡）
| XID 代码 | 错误英文全称 | 物理含义与痛点 | 根因与 SRE/算法解决手段 |
|---|---|---|---|
| XID 79 | GPU fallen off the bus |
GPU 掉卡（脱离 PCIe 总线）。 物理主板再也检测不到这张显卡，像被物理拔出了一样。 | 根因：1. 供电暴跌：GPU 暴算时瞬时电流过大把电源（PSU）打挂；2. 热保护：温度过高触发硬件强制断电；3. 金手指氧化/松动。 |
解决：先尝试下线机器重启；若无法恢复，必须开箱重新插拔显卡，重打螺丝扭矩，或者更换整卡/主板。 |
| XID 92 | HBM Link Training Error | HBM 显存物理链路训练错误。 GPU 与其物理并排封装的 HBM 显存之间的微米级连接通道发生信号失真。 | 根因：HBM 颗粒由于长期高温老化、物理微裂纹导致损坏。无法通过软件修复。
解决：直接报修换卡。 |
| XID 94 / 95 | NVLink Error | NVLink 物理链路错误。 机器内部 8 张卡之间的高速互联通道发生严重信号失真或中断。 | 根因：对应我们聊到的 DCGM_FI_DEV_NVLINK_FLIT_CRC_ERR_COUNT 飙升。物理 NVLink 桥接板损坏、接触不良、或主板高频电磁干扰。
解决：重新拔插并清理 NVLink 桥接板金手指，重打官方扭矩螺丝。 |
3. 驱动与固件卡死类（可以通过重启或复位尝试自愈）
| XID 代码 | 错误英文全称 | 物理含义与痛点 | 根因与 SRE/算法解决手段 |
|---|---|---|---|
| XID 61 | Internal Microcontroller Error |
GPU 内部微控制器（如 GSP 芯片）内部错误。 | 根因：GPU 的内部管理芯片固件（GSP Firmware）发生了死锁或跑偏。 |
解决：尝试通过 nvidia-smi -r 软件复位 GPU，或者温和重启（Warm Reboot）服务器。 |
| XID 119 / 120 | GSP RPC Timeout | GSP 远程过程调用超时。 在 Hopper（H100/H200）及更新的架构中，英伟达默认启用了 GSP（GPU System Processor）固件。CPU 与 GSP 通信时发生超时卡死。 | 根因：驱动（Driver）版本与 GSP 固件版本不兼容，或高负载下 GSP 固件死锁。
解决：强烈建议升级 NVIDIA GPU 驱动到官方最新的长生命周期（LTS）版本。 |
⚙️ 三、 SRE 视角：基于 XID 的智能化自愈工作流 (AIOps)
在真实的万卡大模型训练集群中，如果 1 张卡报 XID 故障导致整批 1024 张卡停工，人工去排查会造成巨大的算力资金浪费。现代智算中心通常会部署如下的自动自愈链路：
[GPU 产生 XID 79 掉卡]
│
▼
[dcgm-exporter (指标 152) 捕获到 79]
│
▼
[Prometheus 触发告警] ───> [K8s Operator 拦截并标记节点为 脏节点 (Taint)]
│
▼
[将当前的 PyTorch 训练 Pod 驱逐 (Evict)]
│
▼
[在健康节点上拉起新 Pod，自动从最近的 Checkpoint 恢复]
│
▼
[故障机自动执行硬件自检 (Diag Script)]
│
┌──────────────┴──────────────┐
▼ ▼
[自检通过: 清除 XID] [自检失败: 自动向厂商申报换卡]
│ │
▼ ▼
[重新上线 (Ready)] [保持隔离 (Offline)]通过这套逻辑，XID 就不再只是一个冷冰冰的报错数字，而是变成了整个智算中心自动化运维、保卫大模型算力资产的核心数据源。