数据中心 GPU 服务器“显存报错”排查全攻略：怎么看日志 · 怎么定位 · 怎么处理
摘要：在数据中心（A100 / H100 / V100 / L40 / 4090 混布，K8s 或 Slurm 调度）场景里，“显存报错”是 GPU 故障告警里最容易被误判的一类。它既可能是应用层 CUDA 越界访问（软件问题，GPU 健康），也可能是 HBM 出现不可纠正 ECC（硬件问题，需要隔离 / RMA）。本文基于 NVIDIA 官方文档和本人多个集群的运维实践，给出一套“看日志 → 判类别 → 定位 → 处理 → 回归”的完整闭环，所有命令均可直接复制执行。
一、先梳理：用户说的“显存报错”到底是哪一种
接到告警或用户反馈时，先别急着换卡。把“显存报错”拆成三类，排查方向完全不同：
| 应用层报错 | CUDA error、OOM、illegal memory access，nvidia-smi 正常 | 软件 / 用户程序 | 退还给业务方，GPU 不用动 |
| ECC / 显存硬件错误 | Xid 48/63/64/92/94/95，ECC 计数增长、页退役 | 硬件退化 | 隔离、reset、评估 RMA |
| 掉卡 / 链路错误 | nvidia-smi 显示 ERR! / N-A，Xid 74/79 | PCIe / NVLink / 电源 / 卡硬件 | 重启、排查 riser / 电源，RMA |
核心判断原则：Xid 13 / 31 / 43 基本是应用层；Xid 48 / 63 / 64 / 74 / 79 / 92 / 94 / 95 才是硬件层。第一步永远是抓 Xid，而不是重启。
二、日志在哪里：5 个必看的信息源
定位显存问题，下面 5 个来源按优先级看，缺一不可。
1. 内核日志（Xid 的真相来源）
NVIDIA 驱动的所有 Xid 事件都写进内核日志，这是第一现场。
# 实时/历史 Xid 事件（最常用）
dmesg -T | grep -iE "NVRM: Xid"
journalctl -k –since "2 hours ago" | grep -iE "nvidia|nvrm|xid"
# 传统 syslog 路径（CentOS/RHEL）
grep "Xid (PCI" /var/log/messages
# Debian/Ubuntu
grep "Xid (PCI" /var/log/kern.log
输出形如：NVRM: Xid (PCI:0000:3b:00): 48, An uncorrectable double bit error (DBE) has been detected。其中 48 是错误码，PCI 地址定位到具体哪张卡。
2. nvidia-smi：ECC / 页退役 / 行重映射
这是本文的主战场，第四、五节详讲，先把命令列全：
nvidia-smi -q -d ECC,PAGE_RETIREMENT,ROW_REMAPPER # 单卡加 -i 0
nvidia-smi -q | grep -i 'bit ecc'
nvidia-smi –query-retired-pages=gpu_uuid,retired_pages.address,retired_pages.cause –format=csv
3. DCGM / dcgm-exporter（监控与诊断）
dcgmi health -s a # 开启全部健康监控
# 等待 >=60s 或复现一次后查看
dcgmi health -c
# 诊断分级：1=秒级快速，2=约2分钟，3=约15分钟硬件压测，4=长时间
# 二级及以上务必在节点排空后跑
dcgmi diag -r 1 -i 0
dcgmi diag -r 3 -j > diag.json
说明：dcgmi diag 是官方“这张卡到底健不健康”的权威工具；-r 3 会对显存做读写校验（默认占用 75% 显存、5 种 pattern），生产务必先 drain 节点。
4. 系统层：PCIe、电源、温度
lspci -vvv -s 0000:3b:00.0 | grep -iE "LnkSta|width|speed"
nvidia-smi –format=csv –query-gpu=index,temperature.gpu,power.draw,pcie.link.width.current
# IPMI / BMC 看电源与主板事件（关键：Xid 79 先看这里）
ipmitool sel list | grep -iE "power|voltage|thermal"
5. 完整 bug report（提工单必备）
nvidia-bug-report.sh # 生成 nvidia-bug-report.log，连同 DCGM 日志一起提交厂商
三、Xid 错误码速查表（必须背下来的几个）
完整清单见 NVIDIA 官方 Xid Errors 文档，下表是数据中心最高频、且与显存直接相关的一组：
| 13 | Graphics Engine Exception（多为越界访问） | 否 | 退回业务方，排查 CUDA 代码 |
| 31 | GPU memory page fault（非法地址） | 通常否 | 偶发重启应用；反复出现再收集日志 |
| 43 | GPU 停止处理，应用被终止 | 否 | 应用层，忽略 |
| 45 | Robust channel 清理 | 否 | 伴随其他 Xid 才关注 |
| 48 | Double Bit ECC（不可纠正） | 是 | 见第五节流程 |
| 63 | 页退役 / 行重映射已记录成功 | 是（退化信号） | reset 或重启使其生效 |
| 64 | 页退役 / 重映射记录失败 | 是 | reset GPU，失败则 RMA 候选 |
| 74 | NVLink 错误（卡/交换机间） | 是 | 排查链路、重做 NVLink 连接 |
| 79 | GPU has fallen off the bus | 是 | 重启节点、查 PCIe/电源/riser |
| 92 | High single-bit ECC rate | 是（预警） | 监控趋势，加速则计划换卡 |
| 94 | Contained ECC error（Hopper+） | 是 | 仅该应用受影响，重启应用 |
| 95 | Uncontained ECC error | 是 | 该卡近期输出均可能污染，谨慎 |
经验：Xid 79 在 4/8 卡通过 riser 转接的服务器上，大概率不是 GPU 本体，而是 PCIe riser / 电源接头热胀冷缩松动。优先 re-seat（重新插拔）、换供电线、复测，再考虑 RMA，能省掉大量误换卡。
四、怎么看 ECC / 显存状态：逐条解读 nvidia-smi
1. ECC 计数：volatile vs aggregate
nvidia-smi –query-gpu=index,ecc.errors.corrected.volatile.total,\\
ecc.errors.uncorrected.volatile.total,\\
ecc.errors.corrected.aggregate.total,\\
ecc.errors.uncorrected.aggregate.total –format=csv
解读要点：volatile = 自驱动加载以来（reset/重载清零），看“增量”；aggregate = 累计（烧录在 infoROM，生命周期口径），看“历史”。确认新事件看 volatile 差值，评估换卡看 aggregate 趋势。
2. Retired Pages（页退役）
nvidia-smi -i 0 -q -d PAGE_RETIREMENT
# …
# Retired pages
# Single Bit ECC : 2
# Double Bit ECC : 0
# Pending Page Blacklist : Yes
- Single Bit ECC（SBE）：可纠正，会累积，增长过快才是问题；
- Double Bit ECC（DBE）：不可纠正，出现即严重，触发 Xid 48；
- Pending Page Blacklist：
- No = 坏页已全部隔离，不影响后续；
- Yes = 有待隔离的坏页，需重启节点或 reset GPU 才会生效，在此之前坏地址仍可被分配到。
3. Row Remapper（Ampere 及以后，行重映射）
nvidia-smi -q -d ROW_REMAPPER
重点关注三个值：Remapped Rows（已重映射行数）、Pending（Yes = 需 reset 生效）、Remapping Failure Occurred（Yes = 备援行已耗尽，无法自愈，RMA 候选）。
五、标准化处理流程（Runbook）
下面是可直接落地为 SOP / 自动化脚本的流程。触发条件：出现 Xid 48/63/64/74/79/92/94/95，或 dcgmi diag 失败，或 row remapper 报 pending/failure。
步骤 1：保留现场证据（reset 前必做）
NODE=gpu-19.dc1 GPU=3
ssh $NODE 'dmesg -T | grep -i "NVRM: Xid"'
ssh $NODE nvidia-smi –query-gpu=index,uuid,serial,pci.bus_id –format=csv
ssh $NODE nvidia-smi -i $GPU -q -d ECC,ROW_REMAPPER,PAGE_RETIREMENT
# 复制出来归档，reset 会清空 volatile 计数！
步骤 2：判类别（应用 vs 硬件）
Xid 13/31/43 → 退回业务方（compute-sanitizer / cuda-gdb 排查），GPU 保持健康，不要走 RMA；其余 → 继续本流程。
步骤 3：隔离节点（避免新任务调度进来）
# K8s
kubectl cordon $NODE
kubectl drain $NODE –ignore-daemonsets –delete-emptydir-data –timeout=15m
# Slurm
scontrol update nodename=$NODE state=drain reason="XID hardware fault"
步骤 4：排空并重置 GPU
nvidia-smi –query-compute-apps=pid,process_name,used_gpu_memory –format=csv
# 确认无进程占用后
nvidia-smi -i $GPU -r # 单卡 reset
# Xid 79（掉卡）时 reset 无效，必须整机重启
步骤 5：回归验证
dcgmi diag -r 3 -i $GPU -j > diag-after.json # 约15分钟硬件压测
# 或仅显存专项
dcgmi diag -r memory -p "memory.is_allowed=True;memory.l1_is_allowed=True"
判定：diag 全 Pass 且 ECC 计数不再增长 → 解除隔离、放回生产；仍 Fail 或出现 Xid → 进入 RMA 评估。
步骤 6：RMA 判定标准（NVIDIA 官方口径）
| Double Bit ECC（30 天内） | ≥ 5 |
| Double Bit ECC（保修期内累计） | ≥ 10 |
| SBE + DBE 合计（保修期内累计） | ≥ 60 |
| Row Remapping Failure = Yes | 立即 RMA 候选 |
| 同一节点反复 Xid 48/79 | 换卡 + 排查主板/电源 |
提 RMA 时一并附上：机型 / OS / 驱动版本、GPU 序列号与 UUID、PCI bus id、完整 dmesg、nvidia-bug-report.log、DCGM diag 日志、应用框架与版本。信息越全，厂商响应越快。
六、解决思路：三个真实场景对照
| 训练偶发 CUDA error | 仅 Xid 13/31，ECC 全 0 | 查用户 CUDA 越界 / OOM | 退回业务方 |
| 单卡 ECC 持续增长 | Xid 48 + 63，DBE 递增 | 对比同节点其他卡 ECC 趋势 | drain → reset → 监控，达阈值 RMA |
| 整机某卡消失 | nvidia-smi ERR!，Xid 79 | IPMI 电源事件 + lspci 是否可见 | 重插 riser/供电，复测，否则 RMA |
通用心法：对比法 + 趋势法。数据中心的价值在于“同型号、同负载、同环境”的横向对比——某一张卡 ECC 计数明显偏离同伴，基本可以定性为硬件退化，比任何单次告警都可靠。建议把 ECC、温度、功耗、PCIe width、throttle reason 全部接入 Prometheus，做差分告警而不是绝对值告警。
七、防呆：常见坑
八、一句话总结
看日志先抓 Xid → 用 nvidia-smi 看 ECC / Retired Pages / Row Remapper → 区分应用层与硬件层 → drain + reset + dcgmi diag 回归 → 按阈值评估 RMA。
把这条链路做成自动化 Runbook，数据中心 GPU 运维就从“救火”变成“可度量、可预测的容量管理”。
参考资料
原创内容，转载请注明出处。如有勘误欢迎在评论区交流。
