4. GPU硬件与驱动层故障诊断
推理服务跑着跑着突然吞吐掉底、请求超时，甚至进程直接退出，很多时候问题并不在模型或框架，而在 GPU 硬件与驱动这一层。这一层故障的特点是：现象往往“看起来像软件问题”，但根因在卡、显存、链路或驱动。要快速定位，关键是学会读三类信号——ECC 计数、Xid 报错、掉卡与显存异常，再结合驱动版本兼容性做判断。
一、先分清五类故障的“指纹”
ECC（Error Correcting Code）是显存和内部 SRAM 的纠错机制。它分两类：可纠正错误（Correctable / Single-Bit）由硬件自动修复，通常只影响性能；不可纠正错误（Uncorrectable / Double-Bit）无法修复，会导致数据损坏、进程崩溃甚至整卡失效。判断严重程度看两点：错误类型和增长速率。偶发单比特、计数不涨，可观察；持续增长或出现双比特，必须处理。
Xid 是 NVIDIA 驱动上报的错误事件编号，写在系统日志里，是硬件层最重要的“诊断码”。常见的有：Xid 13/31（GPU 异常、非法访问）、Xid 43（GPU 停止处理任务）、Xid 48（双比特 ECC）、Xid 63/64（行重映射，ECC 相关）、Xid 74（NVLink 总线错误）、Xid 79（GPU 掉卡/掉总线）、Xid 92/94（驱动与硬件通信异常）。不同 Xid 对应不同处置动作，不能一概重启了事。
掉卡指 GPU 从系统中消失，nvidia-smi 报 “Unable to determine the device handle” 或设备列表少卡，常见于 Xid 79、供电/散热异常、PCIe 链路问题。显存异常表现为显存占用异常、OOM 但实际占用不高、推理结果乱码，多与 ECC 双比特或显存颗粒故障相关。驱动版本不兼容则表现为 CUDA 初始化失败、nvidia-smi 与驱动版本不匹配、容器内无法识别 GPU。
二、ECC 错误的识别与处理
用 nvidia-smi -q -d ECC 查看计数，重点看 Volatile（本次开机以来）和 Aggregate（累计）两个维度。示例输出中若 Single Bit 的 Volatile 计数为 0、Aggregate 为 12，说明历史上出现过但当前稳定；若 Volatile 在几分钟内从 0 涨到几十，说明该卡正在持续出错。
nvidia-smi -q -d ECC | grep -A 4 "ECC Errors"
# 关注：
# Volatile - Single Bit / Double Bit
# Aggregate - Single Bit / Double Bit
# Remapped Rows（行重映射，ECC 修复的痕迹）处理原则：单比特且不增长，记录基线后继续观察；单比特快速增长或出现双比特，立即把该卡从推理集群中摘除（在调度层打 taint 或从可用卡列表移除），迁移实例，再走硬件报修。注意：双比特错误后即使重启恢复，显存数据也可能已损坏，不能直接放回生产。
三、Xid 错误的定位与处置
Xid 写在 dmesg 或 /var/log/syslog 中，格式类似 NVRM: Xid (PCI:0000:3b:00): 79, pid=..., GPU has fallen off the bus。定位时先抓 Xid 编号和 PCI 地址，再对照处置表。例如 Xid 48 表示双比特 ECC，按 ECC 双比特流程处理；Xid 74 是 NVLink 错误，多卡推理时需检查 NVLink 拓扑和互联；Xid 13/31 常与非法内存访问相关，需排查是否有越界访问或驱动 bug。
四、掉卡与显存异常的排查
掉卡后 nvidia-smi 会报设备句柄错误或直接少卡。排查顺序：先看 lspci | grep -i nvidia 是否还能看到设备，若 lspci 都看不到，说明是 PCIe 层掉链，重点查供电、金手指、插槽和散热；若 lspci 能看到但 nvidia-smi 看不到，多为驱动层问题，可尝试 nvidia-smi -r 复位或重载驱动模块。
显存异常除了 ECC，还可用 cuda-memtest 或 NVIDIA 的 dcgm 做显存压力测试。推理场景中若出现“显存占用正常但结果乱码”，优先怀疑 ECC 双比特或显存颗粒故障，而不是模型问题。此时应停止该卡上的推理任务，做显存测试确认。
五、驱动版本不兼容的识别
驱动不兼容的典型现象：nvidia-smi 报 “Failed to initialize NVML: Driver/library version mismatch”，或容器内 CUDA 初始化失败。根因通常是内核模块版本与用户态库版本不一致（例如升级了驱动包但没重启，或容器镜像里的 CUDA 版本高于宿主驱动支持的版本）。
排查方法：用 nvidia-smi 看 Driver Version 和 CUDA Version，用 cat /proc/driver/nvidia/version 看内核模块版本，两者必须一致。容器场景还要确认镜像的 CUDA 版本不超过宿主驱动支持的上限。处理方式是重启加载新模块，或重装与 CUDA 匹配的驱动版本。
nvidia-smi + 一次小规模推理冒烟测试验证 GPU 可用性，避免版本漂移导致的批量故障。六、一份可执行的排查清单
| 现象 | 首要检查 | 关键命令/日志 | 处置 |
|---|---|---|---|
| 吞吐骤降、无报错 | ECC 单比特增长 | nvidia-smi -q -d ECC | 记录基线，持续监控 |
| 进程崩溃、结果乱码 | ECC 双比特 / Xid 48 | dmesg | grep Xid | 隔离该卡，迁移实例 |
| nvidia-smi 少卡 | Xid 79 / PCIe 掉链 | lspci、dmesg | 查供电散热，换槽验证 |
| NVML 初始化失败 | 驱动版本不匹配 | nvidia-smi、/proc/driver/nvidia/version | 重启或重装匹配驱动 |
| 容器内无 GPU | CUDA 与驱动不兼容 | 容器内 nvidia-smi | 对齐镜像 CUDA 版本 |
掌握这套“采集信号 → 判读指纹 → 对照处置”的方法，就能在推理服务出现硬件层异常时快速区分是卡的问题、显存的问题还是驱动的问题，避免把硬件故障误判为模型或框架问题而浪费排查时间。