H20 集群 GPU 掉卡、NVSwitch 与 Fabric Manager 排障闭环

进入生产后，真正考验运维能力的不是“有没有故障”，而是故障出现后能否快速定界。GPU 掉卡、NVSwitch 未识别、Fabric Manager 启动失败、NCCL 慢节点，这些问题在单台机器上看似独立，在训练集群里都会表现为任务失败、通信超时或整体带宽下降。

一、排障原则：先定界，再换件

生产现场最容易犯的错误是看到 nvidia-smi 少卡就直接判断 GPU 坏了。实际上，GPU 不识别可能来自多种原因：

类别	可能原因
GPU 单卡	硬件故障、ECC/Row Remapper 异常、温度或供电问题
槽位/线缆	连接不良、线缆或转接板异常、插槽问题
基板/整机	PCIe 拓扑异常、主板或基板问题
NVSwitch	模块未识别、Fabric Manager 启动失败
软件栈	驱动、内核模块、Fabric Manager 版本不匹配
网络链路	RoCE、HCA、PFC/ECN、路由异常导致 NCCL 慢

正确方法是先收集证据，再缩小范围，最后决定是否换 GPU、换线缆、处理 NVSwitch、调整配置或升级软件。

二、第一步：带外和 OS 双视角确认

GPU 掉卡排障建议先看带外，再看 OS。

带外视角用于判断硬件管理面是否能识别 GPU。这里可以通过 BMC 页面或 Redfish 接口查看设备状态、传感器、错误告警。

OS 视角用于判断驱动和系统是否识别 GPU：

nvidia-smi
nvidia-smi -L
lspci | grep -i nvidia
dmesg | egrep -i 'nvrm|xid|nvidia|pcie'

如果 BMC 能识别但 OS 不能识别，优先看驱动、PCIe、系统日志和 Fabric。若 BMC 和 OS 都不能识别，硬件路径问题概率更高。

三、第二步：检查 ECC 与 Row Remapper

如果 GPU 仍然可见，但训练任务异常、NCCL 报错或性能不稳定，建议检查 ECC 与 Row Remapper：

nvidia-smi -q -d ECC,ROW_REMAPPER

关注项包括：

项目	风险
Uncorrectable ECC	可能导致任务失败或数据错误
Row Remapper Pending	可能需要维护窗口处理
Retired Pages 异常增长	需要结合厂商策略评估
Xid 错误	需要结合内核日志判断原因

如果错误已经指向 GPU 硬件健康问题，就不应继续把它放回训练池。生产上可以先隔离节点，再做进一步定界。

四、第三步：NVSwitch 与 Fabric Manager

8 卡服务器如果使用 NVSwitch 或 Fabric Manager，GPU 可见不代表 Fabric 正常。Fabric Manager 异常会导致 GPU 间通信能力受影响，NCCL 可能表现为初始化失败、带宽异常或任务挂住。

常用检查：

dmesg | grep -i nvswitch
systemctl status nvidia-fabricmanager
journalctl -u nvidia-fabricmanager -n 100 --no-pager
lspci -nn | grep -i nvidia

排障时建议分三层看：

1. lspci 是否能看到对应 NVIDIA 设备。
2. 内核日志是否有 NVSwitch 或 PCIe 错误。
3. Fabric Manager 服务是否启动成功，日志里是否有模块未识别、拓扑不一致或版本不匹配。

如果确认某个 NVSwitch 模块未识别，现场可以按厂商维护规范做断电复位、插拔清洁或部件替换。公开文章建议写方法，不建议公开现场照片和模块编号。

五、第四步：NCCL 慢节点单卡隔离

有些故障不会表现为 GPU 掉卡，而是表现为 NCCL 慢。定位这类问题时，最有效的方法是逐步隔离 GPU 和 HCA。

单机全卡测试：

./all_reduce_perf -g 8 -b 8M -e 12G -f 2

排除某一张 GPU：

CUDA_VISIBLE_DEVICES=0,1,2,3,4,5,6 ./all_reduce_perf \
  -g 7 \
  -b 8M \
  -e 12G \
  -f 2

轮流排除 GPU 0 到 GPU 7。如果排除某一张 GPU 后性能恢复，要继续判断问题是 GPU 本身、对应 HCA、PCIe 路径、NVSwitch 路径，还是局部链路。

跨机慢节点也可以用类似方法：

1. 从大规模测试中拿掉可疑节点。
2. 对可疑节点做双机测试。
3. 对可疑节点做单机 8 卡测试。
4. 轮流排除 GPU 或 HCA。
5. 结合 RoCE 队列、端口错误、PFC/ECN 统计判断。

六、第五步：槽位对调判断“跟卡走还是跟槽走”

当 OS 不识别某张 GPU，且重启无法恢复时，可以通过槽位对调进一步定界：

对调前：
  Slot-X 中 GPU-A 不识别。

操作：
  将 GPU-A 与 Slot-Y 中 GPU-B 对调。

对调后：
  如果故障跟着 GPU-A 走，倾向 GPU 单卡问题。
  如果故障仍停留在 Slot-X，倾向槽位、线缆、基板或主板路径问题。

生产现场一定要记录 GPU UUID、SN、槽位、线缆、BDF 和对调前后照片

七、排障证据清单

证据	命令或来源	公开处理
GPU 列表	nvidia-smi -L	脱敏 UUID
GPU 健康	nvidia-smi -q -d ECC,ROW_REMAPPER	保留异常类型，隐藏 SN
PCIe 设备	lspci	隐藏完整 BDF 映射
内核日志	dmesg	截取错误类型
Fabric 状态	systemctl status nvidia-fabricmanager	隐藏主机名
Fabric 日志	journalctl -u nvidia-fabricmanager	隐藏节点信息
NCCL 结果	all_reduce_perf	隐藏主机名/IP
槽位对调	现场记录	不公开照片、SN、地址

八、故障闭环模板

建议每一次生产故障都按同一个模板记录：

故障现象：
  训练任务失败 / NCCL 带宽下降 / nvidia-smi 少卡 / Fabric Manager 异常。

影响范围：
  单节点 / 单 Leaf / 多节点 / 整网。

初步证据：
  告警、日志、NCCL 结果、GPU 健康状态。

定界过程：
  BMC -> OS -> GPU 健康 -> Fabric -> 单卡隔离 -> 槽位对调。

结论：
  GPU 单卡 / NVSwitch / HCA / 线缆 / 槽位 / 软件配置。

恢复动作：
  隔离、替换、复位、升级、回滚。

复测结果:
  单机 NCCL、双机 NCCL、目标规模 NCCL。

这个模板的价值在于减少误判。没有复测结果的“恢复”，不能算闭环。

九、生产经验

第一，慢节点优先隔离，避免影响正在排队的训练任务。大规模集群里，一个慢节点可能拖垮整个作业。

第二，硬件证据和软件证据要分开看。nvidia-smi 正常不代表 NVSwitch 正常，BMC 正常也不代表 OS 驱动正常。

第三，换件前要尽量完成槽位对调或路径定界。否则可能出现 GPU 换了、问题还在原槽位的情况。

第四，恢复后必须复跑 NCCL。硬件恢复只是第一步，训练通信恢复才是生产可用的证据。

十、总结

智算集群故障定界的关键是流程化：先带外，再 OS；先设备识别，再健康指标；先单机，再跨机；先隔离，再换件；最后用 NCCL 复测闭环。

在 生产环境里，排障方法本身就是平台能力的一部分。只有把 GPU 掉卡、NVSwitch 异常、Fabric Manager 故障和 NCCL 慢节点纳入统一闭环，集群才能长期稳定运行。

---