跳至主要內容

常见错误排查

Kinger2026/7/23大约 11 分钟AI基础设施

在智算中心的日常运维中，大模型训练任务的突然中断、卡死或性能暴跌，往往是由极其复杂的软硬件协同失效引起的。本手册全面总结了 9 类最常见的 AI 算力集群故障，旨在为一线 SRE 和 AI Infra 架构师提供标准排查与修复流程（Runbook）。

故障一：显存溢出 (CUDA Out of Memory - OOM)

1. 故障现象

训练进程突然异常中断，PyTorch 抛出 RuntimeError: CUDA out of memory. Tried to allocate... 报错；或者 K8s 控制台显示 Pod 被 OOMKilled。

2. 核心监控指标与日志联动定位

  • **DCGM_FI_DEV_FB_USED** (Field ID 252)：呈现陡峭的上升曲线，直至达到 DCGM_FI_DEV_FB_TOTAL (Field ID 250) 的物理上限（如 H200 的 141GB）。
  • **DCGM_FI_DEV_FB_FREE** (Field ID 253)：瞬间暴跌至接近 0。
  • **DCGM_FI_DEV_XID_ERRORS** (Field ID 152)：在崩溃瞬间，可能捕获到 Xid 31 (MMS-triggered dynamic page retirement) 或 Xid 62 (Address translation fault)，这代表应用层因为显存越界尝试读写未分配的物理地址。

3. 根因排查与解决手段

  • 根因 1：Batch Size (批大小) 设定过大

  • 调优手段：降低 per_device_train_batch_size。若想保持总 Batch Size 不变，可等比例增加 梯度累积步数 (Gradient Accumulation Steps)。

  • 根因 2：激活值 (Activation) 堆积

  • 调优手段：要求算法工程师开启 激活值重计算 (Activation Checkpointing)。该技术用“时间换空间”，不保存中间激活值，而在反向传播时重新计算，能省下近 50% 的显存。

  • 根因 3：模型并行切分不合理

  • 调优手段：对于超大参数模型，提高 张量并行 (TP) 或 流水线并行 (PP) 的度，或者引入 ZeRO-Stage 3 (DeepSpeed) 机制，将优化器状态和梯度切片并卸载 (Offload) 到 CPU 主存。

故障二：算力蒸发与降频 (Thermal & Power Throttling)

1. 故障现象

训练任务没有挂，但是大模型每秒吞吐的 Token 数（TFLOPS）无故发生断崖式下跌（例如下降 30% ~ 50%）。

2. 核心监控指标与日志联动定位

  • **DCGM_FI_DEV_SM_CLOCK** (Field ID 100)：运行频率明显低于官方标称的基准频率。
  • **DCGM_FI_DEV_THERMAL_VIOLATION** (Field ID 1011) 或 **DCGM_FI_DEV_POWER_VIOLATION** (Field ID 1012)：该指标从 0 变为非零，且持续累加。代表 GPU 触发了温度墙或功耗墙保护。
  • **DCGM_FI_DEV_GPU_TEMP** (Field ID 150)：温度曲线突破告警阈值（如 $>80^\circ\text{C}$）。

3. 根因排查与解决手段

  • 根因 1：机房精密空调/液冷 CDU 散热失效

  • SRE 动作：如果一个机架（Rack）上的 8 台机器全部出现 THERMAL_VIOLATION，说明是机房物理冷却层问题。需立刻联系机房值班人员检查液冷泵压力、水温，或检查风道挡板。

  • 根因 2：单机服务器电源（PSU）故障

  • SRE 动作：若仅有单台机器降频，且 BOARD_LIMIT_VIOLATION (Field ID 1013) 飙升，说明服务器部分电源模块离线，导致总供电功率不足，主板强行限制了 GPU 的 TDP。需联系硬件供应商更换 PSU。

故障三：硬件掉卡与致命故障 (Xid Hardware Failure)

1. 故障现象

分布式训练进程突然卡死（进程还在，但无吞吐），最终因为 TCP Keepalive 超时而崩溃。系统日志抛出显卡脱离 PCI 总线错误。

2. 核心监控指标与日志联动定位

  • **DCGM_FI_DEV_XID_ERRORS** (Field ID 152)：这是排查掉卡的唯一金钥匙。

  • 如果捕获到 Xid 79 (GPU fallen off the bus)：代表 GPU 物理上从 PCIe 总线上“消失”了，主板再也无法读写该卡。

  • 如果捕获到 Xid 61 (Internal microcontroller error) 或 Xid 92 (High-bandwidth memory Link training error)：代表 GPU 内部或 HBM 物理链路损坏。

  • **DCGM_FI_DEV_NVLINK_RECOVERY_ERR_COUNT** (Field ID 242)：如果伴随有该指标的暴涨，说明机内 NVLink 互联排线出现严重的物理级信号干扰。

3. SRE 自动化自愈预案

这是分布式训练中最怕遇到的“单点故障”，1 张卡掉线会导致 1024 张卡全部停工。

  1. 自动驱逐与下线 (Drain & Taint)：AIOps 平台一旦监听到宿主机上报 Xid 79，立刻触发 K8s webhook，将该物理节点打上污点（Taint），防止新任务调度上来。
  2. 平滑迁移：健康检查机制（Liveness Probe）识别到节点死锁后，触发任务重排，使用最新的自动 Checkpoint 恢复训练。
  3. 硬件自检 (Field Diag)：运维脚本在后台对故障机器执行 nvidia-smi -r 重置 GPU。若重置失败，直接调用 BMC 带外管理关机，并自动创建厂商硬件报修工单。

故障四：无损网络拥塞与死锁 (PFC / NCCL Deadlock)

1. 故障现象

在多机分布式训练的梯度同步阶段，全集群 GPU 利用率（SM_ACTIVE）瞬间跌至 0% 且呈水平直线。网络延迟飙升至秒级。

2. 核心监控指标与日志联动定位

  • **PFC_Pause_Frames_Rx/Tx**：交换机和宿主机网卡端口上的 PFC 暂停帧计数疯狂暴涨。
  • **DCGM_FI_PROF_SM_ACTIVE** (Field ID 1002)：所有机器全部跌至 $<5\%$。
  • **DCGM_FI_PROF_NVLINK_TX_DATA** (Field ID 1010)：内部通信数据停滞，卡在极低的值。

3. 根因排查与解决手段

  • 根因 1：QoS 标签映射断裂（对暗号失败）

  • 排查方向：检查 GPU 节点的网卡固件中 DSCP 值（如 26）是否成功在交换机侧翻译为正确的 PCP 优先级（如 3）。如果映射丢失，RoCEv2 流量会被当作普通流量丢弃，引发重传。

  • 解决手段：重构交换机 QoS Profile，对齐端到端的流量染色标签。

  • 根因 2：PFC 死锁 (Deadlock)

  • 排查方向：多台交换机之间因为环路或并发反压，导致 A 等 B、B 等 C、C 等 A 的死锁状态。

  • 解决手段：在核心交换机上开启 PFC 死锁预防 (PFC Deadlock Prevention / Recovery) 功能。一旦监测到某个队列被持续 Pause 超过 X 微秒，强行解冻该队列（允许丢包，由上层 NCCL 协议重传），打破物理死锁圈。

故障五：数据饥饿 (GPU Data Starvation)

1. 故障现象

GPU 硬件和网络一切正常，但 SM_ACTIVE (Field ID 1002) 呈现“锯齿状”（一会儿高一会儿低，或者长期卡在 $20\%$ 左右），机器温度也很低，训练极慢。

2. 核心监控指标与日志联动定位

  • **DCGM_FI_PROF_SM_ACTIVE** (Field ID 1002)：长期处于低位（$<30\%$）。
  • **node_disk_read_time_seconds_total** (存储读延迟) 或 **CPU iowait**：发生异常飙升，表示 CPU 有大把的时间无所事事，在等硬盘把数据读出来。
  • **DCGM_FI_DEV_PCIE_RX_THROUGHPUT** (Field ID 201)：网络/存储网卡通过 PCIe 向 GPU 显存输送数据的带宽低于理论阈值。

3. 根因排查与解决手段

  • 根因 1：训练数据集包含海量零碎小文件（如小图片、小文本段）

  • 排查方向：传统的 Linux VFS（虚拟文件系统）和慢速 NFS 无法支撑高并发的小文件 open/read 请求，元数据服务器被卡死。

  • 解决手段：

  1. 数据打包：要求算法组必须将零碎数据集使用 WebDataset 或 TFRecord 格式重构，合并为单个几百 MB 的连续大文件，将随机小 I/O 转化为高效的顺序大 I/O。
  2. 数据预热：在 K8s 任务拉起时，利用 Init Container 提前将本轮需要训练的数据从“冷对象存储 (OSS)”极速拷贝到“高性能存储 (Weka/CPFS)”中。

故障六：NCCL 异常退化与慢速 TCP 网络回退

1. 故障现象

多机多卡分布式训练可以跑通，但只要涉及多机通信，算力利用率或数据吞吐就会暴跌（甚至下跌 90% ），外网网口被打满，但 RDMA 无损网卡（如 400G Mellanox 网卡）几乎没有流量。

2. 核心监控指标与日志联动定位

  • 容器标准输出日志（需要提前配置 **export NCCL_DEBUG=INFO**）：

  • 故障日志：NCCL INFO Using network Socket（意味着退回到了慢速以太网通信）。

  • 正常日志：NCCL INFO Using network IB（表示正在走高性能 RDMA 极速通道）。

  • **DCGM_FI_DEV_PCIE_TX_THROUGHPUT** (Field ID 200)：数值极其微弱，意味着跨机高速总线通信几乎闲置。

3. 根因排查与解决手段

  • 根因 1：NCCL 通信路由抓错了网口或 **GID INDEX** 错位

  • 排查方向：检查网络配置。在跨网段 RoCEv2 环境中，网卡 GID 索引如果指错（例如指向了不支持 L3 路由的 RoCEv1），NCCL 会因握手失败而静默退化到 TCP/IP。

  • 解决手段：

在部署大模型的 K8s Pod 或脚本中显式配置以下环境变量：

export NCCL_IB_GID_INDEX=3          # 强制指向支持跨路由的 RoCEv2 队列
export NCCL_IB_DISABLE=0            # 强制开启 IB/RDMA 通信
export NCCL_SOCKET_IFNAME=eth0      # 仅限握手使用普通网卡
export NCCL_IB_HCA=mlx5_0,mlx5_1    # 指定专门用来梯度同步的 RDMA 网卡设备

故障七：GPUDirect (GDR/GDS) 极速通道失效

1. 故障现象

在大模型拉起或 Checkpoint 写入阶段，服务器的主板 CPU 负载（特别是 iowait 和软中断）突然飙升至 100%，系统响应极慢，加载 Checkpoint 耗时长达数分钟甚至数小时，阻碍了 GPU 的及时计算。

2. 核心监控指标与日志联动定位

  • **node_cpu_seconds_total{mode="iowait"}**：数值飙升。
  • **DCGM_FI_DEV_PCIE_RX_THROUGHPUT** (Field ID 201)：在读取 Checkpoint 时，该值卡在几百 MB/s 级别，无法发挥 PCIe Switch 的 GB/s 级吞吐实力。
  • 系统调用栈跟踪：利用 strace 追踪训练进程，发现存在高频的 read/write 传统系统调用，未发现对 GPUDirect 设备的 ioctl 映射。

3. 根因排查与解决手段

  • 根因 1：未正确安装 nvidia-fs 驱动，或高性能存储未启用 GDS (GPUDirect Storage)

  • 排查方向：数据没有通过 GPUDirect 绕过内核，而是被强制送入主板内存进行了大量的 Page Cache 拷贝。

  • 解决手段：

  1. 确保宿主机上已成功加载 nvidia-fs 内核模块：lsmod | grep nvfs。
  2. 检查 Weka 或 CPFS 的 CSI 挂载选项，确保开启了对 GDS（例如 gds_enabled）的支持。
  3. 要求算法框架代码（如 PyTorch / DeepSpeed）适配 GPUDirect RDMA（GDR），跳过 CPU 中断传输。

故障八：QoS 端到端打标丢失与 silent 清洗

1. 故障现象

多机训练遇到拥塞时，大模型进程会发生诡异的丢包和频繁重传，NCCL 报错中断。即使配置了无损网络，在交换机端依然监测到 Queue 0（普通队列）存在丢包，而原本应走无损通道的 Queue 3（RoCE 专用队列）无任何流量或 PFC 暂停帧。

2. 核心监控指标与日志联动定位

  • **PFC_Pause_Frames_Rx/Tx**：在发生拥塞时值为 0（说明 PFC 完全没起作用）。
  • 交换机物理端口队列监控：交换机上 Queue 0 丢包计数（Drop Counter）持续累加，Queue 3 吞吐量几乎为零。
  • 物理抓包 (IP Tos / Traffic Class 字段)：使用物理分光镜或交换机镜像端口（SPAN）抓包，分析 IP Header，发现包头的 DSCP（三层）或 VLAN 的 PCP（二层）标志位变为了 0（Best Effort）。

3. 根因排查与解决手段

  • 根因 1：中间路由器或防火墙的 “Silent 标签清洗”

  • 排查方向：数据在跨网段路由过程中，中间节点未配置 QoS 信任，或者被部分默认安全策略将所有 DSCP 标签重置回了 0。导致翻译断层，末端交换机将其塞入普通队列导致溢出丢包。

  • 解决手段：

  1. 在所有经过的核心路由器和三层交换机接口上，强制配置 QoS 信任机制：
mls qos trust dscp  # 声明信任上游打的 DSCP 标签，不得清洗
  1. 保证网卡配置（DSCP to PCP Mapping）与交换机配置绝对一致，坚决避免翻译暗号对不上的情况。

故障九：Transformer Engine FP8 动态缩放精度崩溃

1. 故障现象

在 Hopper (H100/H200) 架构上启用 FP8（单字节）高阶加速训练大模型时，训练日志中的 Loss 突然飙升为 NaN（Not a Number），发生严重的梯度爆炸崩溃；或者模型的 Loss 停滞不收敛，直接退化成了“垃圾代码”。

2. 核心监控指标与日志联动定位

  • 训练进程日志：高频输出 NaN detected 或 scale factor underflow 警告。
  • **DCGM_FI_PROF_TENSOR_OP_UTIL** (Field ID 1015)：在崩溃前，利用率非常高，但数值伴随突发式的参数异常波动。
  • 模型权重张量 Dump：Dump 运行时矩阵，发现大量的 FP8 数值触碰到了其物理最大表示区间 $448$（对于 E4M3 格式）或 $57344$（对于 E5M2 格式）。

3. 根因排查与解决手段

  • 根因 1：Transformer Engine (TE) 的动态缩放因子（Scale Factor）步长和历史窗口设置过短

  • 排查方向：FP8 的数值表示范围极其狭窄，必须要靠算法底层的动态缩放控制器（TE）进行平滑变换。若历史窗口设置不当，会导致某一步的数值突变直接击穿 FP8 物理极限（溢出）。

  • 解决手段：

  1. 微调 Transformer Engine 运行时参数，增大缩放历史保存窗口（margin / history_len），使其能更平滑地预测下一个 Step 的张量最大值。
  2. 如果梯度极度不稳定，可尝试将注意力机制（Attention）的关键矩阵暂时保护性回退到 BF16，仅对计算更为规整的 MLP 层使用 FP8 模式：
import transformer_engine.pytorch as te
# 在大模型代码中配置 TE 动态保护策略
with te.fp8_autocast(enabled=True, fp8_recipe=te.recipes.DelayedScaling(margin=1.0, interval=1)):
    outputs = model(inputs)