人人都会AI编程

21.2 常见硬件故障排查：GPU 故障、网卡故障、存储故障定位

更新时间：2026-07-09

算力集群在长期高强度运行中，硬件故障几乎是必然事件。本章不讨论“怎么保证绝对不坏”（那是冗余设计的事），而是聚焦于当故障发生时，如何快速定位、确认范围、恢复业务。GPU、高速网卡和存储系统，是集群中最容易出问题，也最容易引发连锁反应的三个组件。下面逐一拆解典型故障现象、排查路径和处置策略。

一、GPU 故障排查

GPU 是训练任务的直接发动机。它的故障通常不会直接报“硬件损坏”，而是表现为训练异常、性能骤降或节点离线。

1. 典型故障现象

  • 训练任务突然报错：CUDA error: unknown error / illegal memory access / uncorrectable ECC error
  • 显存占用异常：某张卡的显存占用始终远高于其他卡，或周期性出现 OOM（Out of Memory）
  • 计算性能骤降：GPU 利用率显示 100%，但实际吞吐量只有正常的一半
  • 温度与功耗异常：温度飙升至 85℃ 以上且降频，或功耗读数跳变
  • 节点失联：nvidia-smi 无法识别 GPU，显示 ERR! 或设备丢失

2. 快速定位三板斧

第一步：查看 nvidia-smi 基础状态

nvidia-smi

关注几个关键指标：

  • 温度（Temp）：持续超过 80℃ 需立即检查散热（风冷是否堵塞、液冷是否泄漏/堵塞）
  • 功耗（Pwr:Usage/Cap）：正常训练负载下应在额定功率 80%–90% 左右。若满载但功耗极低，可能是降频或供电不足
  • 显存使用（Memory-Usage）：检查是否异常满载
  • ECC 错误计数（Volatile ECC）：出现非零值说明显存有硬件错误
  • GPU-Util（利用率）：训练时应在 90%–100%，若长期低位但任务未完成，可能卡在通信或数据加载

第二步：查看系统内核日志确认硬件异常

dmesg | grep -i -E "nvidia|nvrm|xid|pci|error"

重点关注 Xid 错误码（NVIDIA GPU 的硬件错误标识）。常见致命 Xid：

  • Xid 31/43/45：GPU 内部存储/显存故障，通常需硬件更换
  • Xid 48：双位 ECC 错误不可纠正，需更换 GPU
  • Xid 62/74/79：与散热/电源相关，可能是掉卡前兆
  • Xid 13/63：用户态驱动问题，重启往往可恢复

第三步：针对性硬件级测试
如果怀疑某张卡有隐性故障（如偶发静默数据损坏），可在非训练时段运行 NVIDIA 官方诊断工具：

# 快速级别（5分钟左右）
nvidia-smi -a | grep -i health
dcgmi diag -r 1

# 完整性显存测试（需先卸下驱动资源）
nvidia-fabricmanager --check
sudo nvidia-smi -pm 1
sudo nvidia-smi -lgc <valid_range>
# 使用专门的 stress 工具（如 gpu-burn）做满负载烧机测试
git clone https://github.com/wilicc/gpu-burn
cd gpu-burn && make
./gpu_burn 60  # 运行60秒满负载测试，监控是否有错误

3. 应急处置与恢复

  • 单卡 ECC 错误/OOM 异常：若训练框架支持（如 DeepSpeed、Megatron），可配置 auto-restart 跳过故障卡或将卡标记为不可用，在 8 卡节点中降级为 7 卡运行。
  • 温度过高：立即增加风扇转速（可用 nvidia-settings 或 BMC），检查机房冷通道温度。风冷场景下，常见原因是机箱风道积尘或 GPU 风扇故障。
  • 无法恢复的硬件故障：封卡走 RMA（返厂），同时在 Slurm/K8s 中将该节点状态置为 drain 或 cordon，避免新任务调度上去。

4. 预防性检查清单

  • 每周巡检 nvidia-smi 的 ECC 错误计数器是否增长
  • 月度运行一次 dcgmi 诊断（需 NVIDIA DCGM 套件）
  • 持续监控训练日志中的 CUDA 错误重试次数，一旦出现隐性错误反复就该提前替换
  • 保持驱动版本一致性，避免新旧驱动混跑导致报 NVML 错误

二、网卡故障排查

分布式训练极度依赖高带宽低延迟网络（InfiniBand 或 RoCE）。一块网卡的间歇性丢包，就可能让千卡训练任务收敛变慢、挂死甚至发散。

1. 典型故障现象

  • 分布式训练通信挂死（NCCL timeout、Broadcast hang、AllReduce stuck）
  • 训练吞吐量周期性驟降，GPU 利用率出现锯齿状（计算等待数据）
  • ibstat 显示 Link Down 或频繁翻动
  • 内核日志大量报 mlx5_core 相关错误（Mellanox 网卡驱动）
  • Ping 大包丢包率上升（ping -s 65500）
  • 多节点 all_reduce 测试结果严重不均匀

2. 排查路径

第一步：物理层与链路状态

# IB 网卡状态
ibstat
# 关注 State: Active，Rate: 200 Gb/sec (或预期速率)

# 以太网/RoCE 网卡状态
ip link show && ethtool <netdev>
# 看 Link detected: yes，Speed 符合预期

# 查看接口错误计数
ip -s -s link show <netdev>
# 关注 errors, dropped, overruns 非零值

第二步：检查网卡固件与驱动
大量网络问题源于固件版本不匹配（网卡与交换机两端），或与 NVIDIA 驱动不兼容。

# 查看网卡固件
ibstat  # IB 场景
ethtool -i <netdev>  # 查看驱动版本和固件版本

# 检查 RoCE 网卡是否开启 PFC/ECN 等必要参数
# 参照集群部署时的基线配置对比

第三步：NCCL 通信测试
这是定位分布式通信问题最直接的手段：

# 多节点 NCCL 带宽测试
mpirun -np <总GPU数> -H <node1:8,node2:8,...> \
  -bind-to none -map-by slot \
  -x NCCL_DEBUG=INFO \
  -x NCCL_IB_DISABLE=0 \
  all_reduce_perf -b 8 -e 128M -f 2 -g 1
  • 若所有卡之间带宽均匀且接近理论值，说明网络基础 ok
  • 若某几张卡或某个跨节点路径带宽异常低，则大概率是线缆、光模块或交换机端口问题

第四步：线缆与光模块排查

  • 插拔重试：用手感觉光模块温度，过热可能是光模块损坏前兆；重新插拔线缆，观察 ip link 是否恢复
  • 端口错误计数：在交换机端查看对应端口（IB 用 ibportstate，以太网用交换机 CLI），重点关注 CRC 错误、FEC 校正计数、符号错误（symbol error）
  • 替换法：将可疑光纤/光模块/铜缆与正常节点对调，观察故障是否迁移

3. 应急处置

  • 单网卡电气级故障（如 Link flapping）：立即将对应网卡 down 掉（ip link set down），或关闭对应 IB 端口，避免影响交换机邻居。若节点为多网卡冗余，可降级运行。
  • NCCL 超时导致的任务卡死：增加 NCCL_TIMEOUT 环境变量，或配置 NCCL_NET_GDR_LEVEL 等参数绕过问题网卡（需重启任务）。
  • 网络分区：检查 InfiniBand 子网管理器（OpenSM）状态，确认所有节点均被正确发现且路径正常。

4. 预防措施

  • 每月进行一轮 NCCL all_reduce_perf + alltoall_perf 全集群基线测试，记录性能曲线，一旦漂移立即预警
  • 固件与驱动升级必须在维保窗口统一执行，且先小范围灰度
  • 建立光模块/线缆的失效预测：记录 FEC 纠错计数增长趋势，超过阈值提前更换

三、存储故障排查

存储系统承载训练数据、Checkpoint 和日志，一旦出现性能抖动或数据损坏，轻则训练挂起，重则数天训练成果丢失。

1. 典型故障现象

  • 训练日志频繁报 DataLoader time out、IOError、Time out waiting for ranks
  • Checkpoint 保存极慢或失败
  • 某个节点莫名其妙断开共享目录
  • df -h 显示挂载点卡死（长时间无响应）
  • 训练数据读取时出现数据损坏（CRC 校验失败）

2. 故障定位

第一步：确认是否存储自身故障
在疑似故障节点手动读写测试：

# 测写
dd if=/dev/zero of=/mnt/shared/testfile bs=1M count=1024 oflag=direct
# 测读
dd if=/mnt/shared/testfile of=/dev/null bs=1M count=1024 iflag=direct

若吞吐量远低于正常值（如万兆网连接存储端，正常写应在 1GB/s 左右），说明存储链路或存储集群异常。

第二步：检查挂载状态与客户端服务

# 检查挂载点是否正常响应
ls /mnt/shared  # 若卡住，基本是服务端或网络问题
stat -f /mnt/shared

# 对于并行文件系统（如 Lustre），检查客户端状态
lctl get_param osc.*.state  # 应显示 CONNECTED
lfs df -h  # 查看 OST/MDT 的使用率和状态

第三步：服务端日志与存储集群健康度

  • Lustre：lctl get_param ..health 查看所有对象存储的目标（OST）和管理目标（MDT）健康状态，若某个 OST 标记为 INACTIVE 会直接导致 IO 阻塞
  • JuiceFS/GPFS：检查 metadata 节点日志，查看是否有 slow disks、degraded disk 警告
  • 通用 SAN/NAS：查看存储控制器的告警灯，登录管理口检查磁盘 SMART 状态、RAID 状态、电源模块状态

第四步：网络与链路延迟
存储的性能瓶颈很大概率是网络。使用 ping -f 或 qperf 等工具测试节点到存储服务端的延迟和丢包率。对于 RDMA 存储（如 DAOS、部分 Lustre 配置），检查 ib_send_bw 测试带宽是否达标。

3. 应急处置

  • 单个节点无法访问存储：先尝试重启该节点的存储客户端（如 umount -f 强制卸载后重新挂载），无效则将节点剔出训练并重启节点。
  • 存储集群部分损坏（如某个 OST 离线）：并行文件系统通常支持单点失效降级，此时 IO 可能变慢但不会丢失数据。需立即联系存储管理员恢复故障盘，并加速重建。
  • Checkpoint 保存失败：立即暂停训练保存进程，切换到备用存储路径，切勿强制覆盖可能已经损坏的历史 Checkpoint。
  • 数据损坏：从最近的完好 Checkpoint 回滚。对于训练数据损坏，需校验数据集完整性（如 MD5 列表对比），从备份重拉缺失文件。

4. 预防体系

  • 存储系统必须配置多副本或纠删码，且定期巡检磁盘 SMART 状态、RAID 电池状态
  • 每天自动对最近 2–3 个 Checkpoint 做快速校验（加载模型权重并进行简单前向传播测试），确保可恢复
  • 存储网络专网专用，避免与计算网络混跑，防止相互干扰
  • 明确 IO 路径的监控：包括挂载点响应时间、IOPS、带宽，设定阈值告警（如 mount point response time > 5s 即告警）

四、通用排查心法

面对复杂故障，遵循“隔离 → 分层 → 替换”的原则：

  1. 隔离：将可疑节点从集群摘除，确认故障是否随节点迁移。若跟随节点走，是节点自身硬件；若不跟随，可能是网络、存储等环境侧。
  2. 分层：严格自底向上排查——物理层（指示灯、线缆、供电）→ 驱动/固件层 → 系统层（内核日志）→ 应用层（训练框架日志）。
  3. 替换：不要在有问题的硬件上花太多时间“修”，对 GPU、网卡、光模块等高故障率组件，备件到位后直接替换，将坏件离线分析。

最终，故障不可避免，但恢复速度取决于你的监控体系和预案厚度。在第 21.3 节训练性能调优中，我们会进一步讨论如何识别计算、通信、存储三大瓶颈，并系统性地提升集群弹性。