训练突然退出，终端最后显示 CUDA 错误，并不等于 A100 80GB 已发生硬件故障。在搭载 A100 80GB 的美国GPU服务器上，同样的任务中断，可能来自应用非法访存、主机内存不足、作业超时，也可能来自 GPU 显存错误或设备失联。尤其是异步执行的 CUDA 任务，最后报错的位置不一定是最先出问题的位置。

排查应按这个优先级进行：先保存作业退出原因与时间范围，再提取同一时段的宿主机内核 Xid 及上下文，通过 GPU UUID、PCI 地址和进程信息关联作业，最后按证据修复并复测。 不要先重启或重置 GPU，以免丢失进程映射、瞬时状态和故障现场。

Xid 是分类线索，不是硬件故障判决

Xid 是 NVIDIA 驱动报告 GPU 异常时使用的错误标识，通常出现在 Linux 内核日志中，常见前缀为 NVRM: Xid。错误码用于缩小排查方向，但不能单凭一个数字确定根因。

例如，访存类异常需要检查应用代码、输入与运行环境；GPU 失联则需要检查设备与主机之间的通信状态。还要区分：

• GPU 显存不足：通常由框架或 CUDA 接口报告分配失败，不一定产生 Xid。
• 主机内存不足：可能由 Linux OOM killer 或容器内存限制终止进程，应查内核与平台事件。

没有查到 Xid，只表示当前日志范围内没有对应记录。 日志轮转、未持久化、查询了错误的启动周期，或只查看容器日志，都可能造成遗漏。

以下命令适用于使用 systemd 的 Linux 宿主机，需要内核日志读取权限；GPU 查询需要 NVIDIA 驱动及 nvidia-smi 可用。命令不修改 GPU 配置，但文件重定向会覆盖同名文件，执行前应选择空间充足的目录，并为每次故障使用独立文件名。

第一步：固定作业退出原因和时间窗口

先保存作业 ID、开始时间、最后正常输出时间、首次异常时间与最终退出时间。分布式任务应收集各 rank 或节点的第一条异常，不能只保留主进程最后的通信失败提示。

退出码 137 通常表示进程受到 SIGKILL，不能单凭它认定 OOM。只有同时找到 OOM killer 记录或平台明确的内存超限事件，才支持内存不足方向；管理员终止、超时强杀也可能出现类似退出结果。

美国GPU服务器的部署地区不决定系统时区，容器与宿主机也可能不同。先检查：

date -Is
timedatectl status

关联时统一转换为 UTC，并核实未标注时区的应用日志采用什么时间配置。查询窗口从首次异常前几分钟开始，覆盖进程退出后的短时间；没有线索再扩大范围。多节点日志还需核实各节点是否存在时钟偏差，否则不能把跨节点时间戳直接当作严格先后顺序。

第二步：提取内核 Xid，保留同一窗口的完整上下文

先确认故障属于哪次系统启动：

sudo journalctl --list-boots

下面的 UTC 时间仅为示例，执行前替换为实际窗口。-b 0 表示当前启动：

START='2026-09-08 02:10:00 UTC'
END='2026-09-08 02:30:00 UTC'

sudo journalctl -k -b 0 --utc -o short-iso-precise \
  --since "$START" --until "$END" --no-pager \
  > kernel-window.log

grep -nEi 'NVRM|Xid|out of memory|oom-kill|killed process|AER|PCIe Bus Error' \
  kernel-window.log

筛选输出用于找入口，kernel-window.log 用于查看前后文。只保存 Xid 那一行，可能漏掉更早的 PCIe 错误、OOM 或后续恢复信息。

查询结果按以下分支处理：

• 找到 Xid：记录时间、PCI 地址、错误码及描述，进入设备映射检查。
• 只找到 OOM 或平台终止事件：核对被终止的 PID、容器或作业是否匹配，优先解释外部终止原因。
• 没有相关记录：先检查启动周期、权限与日志保留范围，再扩大时间窗口，不能直接排除设备问题。

如果故障后已重启，应按启动列表改用对应 boot ID 或偏移量，例如 -b -1。历史日志能否读取取决于 journal 持久化和保留设置。

没有 journal 时，可查看当前内核环形缓冲区：

sudo dmesg --time-format iso \
  | grep -Ei 'NVRM|Xid|out of memory|killed process|AER'

先用 dmesg --help 核实版本是否支持该时间格式。环形缓冲区会覆盖旧记录，墙上时间转换也可能受校时或休眠影响，不能替代完整历史。若发行版启用了传统系统日志，还应检查实际存在的 /var/log/kern.log、/var/log/messages 及轮转文件。

第三步：把报错设备映射到 A100 80GB 作业

一条 Xid 记录至少应提取时间戳、PCI 地址、Xid 数字及附加描述。PID、进程名、channel 等字段是否出现，取决于错误类型和驱动版本；GPU UUID 也可能位于相邻标识行，而不是每条 Xid 中。

保存当前设备映射与状态：

nvidia-smi -L

nvidia-smi \
  --query-gpu=timestamp,index,uuid,pci.bus_id,name,driver_version \
  --format=csv

nvidia-smi -q > gpu-state.txt

用 name 核对设备型号，用 UUID 和 PCI 地址定位物理 GPU，再对照作业分配记录。不要只凭“GPU 0”判断：宿主机序号、CUDA_VISIBLE_DEVICES 顺序与容器内部编号不一定一致，重启或重新分配后也不宜把序号作为唯一证据。

若 A100 80GB 启用了 MIG，还需将作业使用的实例标识映射回父 GPU。宿主机 PID 与容器内 PID 可能不同，数字不一致不能直接排除关联。

当前查询只能证明当前映射与状态，不能完整还原已退出进程的历史。 因此，作业启动时最好记录节点名、作业 ID、GPU UUID、PCI 地址、可见设备配置以及进程映射。若 nvidia-smi 无法查询设备，也应保留原始错误输出，而不是反复重置尝试恢复。

第四步：按时间线解释 Xid，而不是按最后一条报错猜测

CUDA 操作通常异步执行：某个算子先触发异常，应用可能到后续同步或数据复制时才报告错误。应从最早的相关异常向后梳理，而不是从最后的 traceback 倒推责任。

以下时间线仅为整理方式示意：

可靠关联需要同时满足：时间接近、设备一致、进程或作业关系吻合。 共享服务器上，同一时段的日志可能来自其他作业；时间先后也不自动等于因果关系。

常见 Xid 可按下表初筛，具体定义及处理建议应核对 NVIDIA 官方 Xid Errors 文档，并结合实际驱动版本和完整描述。

对于 A100 80GB，应结合 nvidia-smi -q 中可用的 ECC、行重映射及恢复相关信息判断。字段是否存在、是否显示 N/A，受驱动、设备暴露方式和权限影响；N/A 不代表没有错误。连续多个 Xid 也可能包含错误传播、上下文终止或恢复失败，不能逐条当成独立故障。

按证据处理，并用原触发条件验证

处理应从低风险检查进入需要维护窗口的操作；若已有严重设备级证据，不应继续用生产任务试错。

1. 明确 OOM、超时或外部取消：处理对应内存限制、资源使用或作业策略，再确认相同条件下不再触发终止。

2. 固定输入可复现访存类错误：缩小为单进程、单 GPU、最小输入，检查自定义算子、扩展构建环境与版本匹配。必要时用 NVIDIA Compute Sanitizer 的 memcheck 检查最小复现；其开销较高，不宜直接套用完整生产任务。

3. 出现 ECC、重映射失败或设备失联：停止向目标 GPU 分配新作业，保存内核窗口、设备状态和作业映射，交由有宿主机权限的维护人员处理。

4. 异常紧随环境变更出现：保留当前环境清单，在隔离环境对照上一个已验证版本，一次只改变一个变量，并保留返回原环境的路径。

GPU reset、驱动重载和主机重启可能影响同卡或整机任务，也会改变现场。执行前必须保存日志与检查点、确认影响范围并安排维护窗口；被中断的运行状态通常只能依赖检查点恢复，不能靠“回滚重置”找回。

复测前保存目标 GPU UUID 和状态基线，再使用原触发输入或等价负载运行到原失败阶段之后，同时检查：

• 作业是否完成、输出是否正确，而不只是进程仍存活。
• 同一 GPU 是否新增相关 Xid。
• ECC、行重映射状态相对基线是否变化。
• 是否再次出现 OOM、设备失联或相同位置的应用异常。

在其他条件尽量一致时，同一任务在不同可用 GPU 上都于相同算子失败，更支持应用或环境方向；多个独立任务持续在同一物理 GPU 上失败，并伴随设备级错误，更支持设备或平台方向。单次重跑成功只能说明本次未复现，不能替代根因解释，也不能单独证明故障已经消除。