GPU 训练集群运维三板斧：InfiniBand、NCCL-tests 与 XID 监控

发表于 分类于
整理 GPU 训练集群运维三板斧：InfiniBand 网络排查、NCCL-tests 带宽验收，以及 XID 与 DCGM 运行监控。

整理一份自用的 GPU 训练集群运维笔记。三层递进：网络先通（IB）→ 带宽达标（NCCL-tests）→ 运行健康（XID/DCGM 监控）。命令都可直接落地，性能数字是业界参考值，实际以自己环境跑出来的基准为准。

一、InfiniBand：先把网络这层夯实

大模型训练是通信密集型，GPU 之间要频繁做 all-reduce，网络是决定训练吞吐的第一变量。

IB vs RoCEv2

InfiniBand RoCEv2
本质 原生无损网络，credit-based 流控 IB 协议跑在以太网 + DCB（PFC + ECN）上
延迟 ~1 µs ~1.5–2 µs
运维难度 单一栈，子网管理器统一管 跨厂商，但调参很折磨（PFC/ECN 水线）
成本 交换机贵 可复用以太网基建

带宽同代其实一样，差别在流控、延迟、运维难度和价格。经验上 ≥256 GPU 的集群直接上 IB——RoCE 调不好，实测能只跑到 IB 的一半。

速率代际

代 端口速率 年份 典型卡
EDR 100 Gbps 2014 早期 A100
HDR 200 Gbps 2018 主流 A100
NDR 400 Gbps 2022 主流 H800
XDR 800 Gbps 2024+ H200/B200

一台 8 卡 H800 标配「8 GPU + 8 张 NDR-400 HCA」（一卡一网卡），单机出口 3.2 Tbps。有的机器砍到 4 张 HCA，出口腰斩到 1.6 Tbps——这是训练性能杀手，采购/验收时要盯。

Rail-aligned 拓扑

LLM 的集合通信有规律：数据并行的 all-reduce 是 rank-0↔rank-0、rank-1↔rank-1……张量并行基本在机内。

Rail-aligned 的做法是把编号相同的 GPU 接到同一台 leaf 交换机，让 DP 流量在一条 rail（一台 leaf）内闭环，不上 spine。跳数从 5 降到 3，延迟低约 30%、带宽更稳。随机布线 vs rail-aligned 在大集群上训练吞吐能差两三成，值得在布线阶段就规划好。

常用诊断命令

1
2
3
4
5
6
7
8
9
10
ibstat                       # 端口 State=Active / PhysState=LinkUp / 速率
ibstatus
ibdev2netdev -v              # IB 设备 ↔ Linux 网卡 映射
ib_write_bw -d mlx5_0 --report_gbits   # 点对点带宽
ib_write_lat                 # 延迟
sminfo                       # 确认有子网管理器在跑
ibqueryerrors --details      # 交换机端口错误计数
ibhosts                      # SM 上报的 LID / 节点
# 某节点 HCA reset 后掉出网络，重启 SM 让它重新加入：
systemctl restart opensmd

要点：

  • NDR-400 上 ib_write_bw 应到 ~390 Gbps（不是 400，有编码开销）；
  • LinkErrorRecoveryCounter / SymbolErrorCounter 持续上涨 = 光模块或线缆有问题，换掉；
  • 光纤脏了/弯折会让 SM 自动降速，是隐蔽的性能坑。

PCIe 亲和性与 GDR（NDR 速度下的关键）

到了 NDR，PCIe 拓扑经常成瓶颈。用 nvidia-smi topo -m 看 GPU↔NIC 矩阵：

  • 想要 PIX（同一 PCIe switch 下，可走 GPUDirect RDMA 直连）；
  • 出现 SYS（跨 NUMA 经主机内存）→ GDR 直连废掉，性能腰斩。

GDR 开启：

1
2
3
sudo modprobe nvidia_peermem      # 老版本叫 nv_peer_mem
lsmod | grep nvidia_peermem       # 确认已加载
# NCCL 会自动用 GDR，日志里 grep "GDRDMA" 能看到

网络验收清单

  1. 所有端口 Active、跑在额定速率（ibstat）
  2. 所有 GPU↔NIC = PIX（nvidia-smi topo -m）
  3. nvidia_peermem 已加载
  4. ib_write_bw ≥ 380 Gbps（NDR）
  5. 错误计数为 0 或不增长

5 条全过，再去跑 NCCL-tests——否则 busbw 不达标时你分不清是硬件还是软件问题。

二、NCCL-tests：训练前先验带宽

网络物理通了，用 NCCL-tests 验证实际能跑出多少集合通信带宽。核心是：训练上去之前先过这关，跑起来之后再排查难得多。

编译

1
2
3
4
git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests
make MPI=1 MPI_HOME=<...> NCCL_HOME=<...> CUDA_HOME=<...>
# 用 NVIDIA HPCX 时路径在 $HPCX_DIR 下

产物在 build/，all_reduce_perf 覆盖 AI 训练约九成场景。

单机（测 NVLink）

1
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8   # 8B 起，8GB 止，每步翻倍，8 卡

看 busbw 那列，不是 algbw——busbw 才反映物理链路的真实利用率。

单机 busbw 参考值：

硬件 busbw (GB/s)
8×H800 SXM NVLink 460–480
8×A100 SXM NVLink 230–250
8×H800 PCIe（无 NVSwitch） 35–45
4×H800 PCIe + NVLink Bridge 200–230

比参考低 20% 以上就有问题，常见是残留的 NCCL_P2P_DISABLE=1 或某条 NVLink 掉了，nvidia-smi nvlink -s 查。

多机（测 IB）

1
2
mpirun ... -x NCCL_IB_HCA=mlx5 -x NCCL_IB_GID_INDEX=3 \
           -x NCCL_SOCKET_IFNAME=ib0 ... all_reduce_perf -b 8 -e 8G -f 2 -g 1

多机 busbw 参考值（H800 + 8×NDR-400 HCA + GDR）：

节点数 busbw (GB/s)
2 350–380
4 320–360
8 280–320
16 240–280

随节点增加而下降是正常的（跳数变多）。但 2 节点就 <200 GB/s，得查。

排障清单（配 NCCL_DEBUG=INFO）

  1. GDR 开了吗：日志里找 GDRDMA；没有就查 lsmod | grep nvidia_peermem；
  2. HCA 数量对吗：日志列出的网卡数应等于物理 HCA 数；
  3. GID Index：RoCEv2 通常 3、纯 IB 通常 0——配错会静默变慢；
  4. PXN 开了吗：不开的话同 NUMA 的跨 GPU 流量绕主机内存，掉约 30%；
  5. 算法：小数据 tree 快、大数据 ring 快，强行 NCCL_ALGO=Ring 会拖慢小 size。

最低验收标准（都在 8GB 处）

  • 单机 NVLink：busbw ≥ 460 GB/s（H800）
  • 节点对 IB：busbw ≥ 350 GB/s（2 节点 NDR）
  • 全集群 ring：相比理想值劣化不超过 25%

三、XID 与 DCGM：跑起来之后的日常监控

训练在跑了，日常监控盯什么。nvidia-smi 是 1Hz 采样、太粗，生产上用 DCGM / dcgm-exporter（输出 Prometheus 格式），健康巡检用 dcgmi diag（Lv3 约 30 分钟、Lv1 约 5 分钟快检）。

nvidia-smi 关键字段

  • 温度：H800 <85°C、A100 <88°C；进风温 >35°C 是机房问题，去找机务不是找 NVIDIA；
  • 利用率：训练期望 ≥90%，长期 <70% 多半是数据/调度瓶颈，不是卡的问题；
  • 显存：可用到 95%，留 1–2GB 给 NCCL buffer；
  • 功耗：H800 SXM ≤700W；
  • pstate：训练时应是 P0，P2 表示在空转；
  • ecc.errors.uncorrected.volatile.total 必须为 0。

DCGM 值得盯的指标

  • DCGM_FI_PROF_SM_ACTIVE：真实 SM 活跃度（比 occupancy 实在）；
  • PIPE_TENSOR_ACTIVE：Tensor Core 利用率——GPU 利用率 90% 但 Tensor Core 才 ~25%，往往是该用 fp16 的算子跑成了 fp32；
  • HBM 带宽、NVLink 流量（单向应 <900 GB/s）；
  • DCGM_FI_DEV_XID_ERRORS：XID 错误。

XID 错误码速查与处置

XID 含义 处置
13 Graphics Engine Exception 重启进程；反复出现考虑驱动降级
31 MMU fault 多是用户代码 bug（CUDA 越界），非硬件
43 GPU 停止处理 进程崩溃/OOM，重启容器
63 ECC page retirement 可纠正错误已屏蔽，记录即可
64 ECC page retirement 失败 立即下线
74 NVLink error 查 nvidia-smi nvlink -e
79 GPU fallen off bus 硬件故障
119/120 不可恢复的 HBM 错误 下线、送修

一线策略：13/31/43 自动重试一次；某卡 XID 63 累计 >5 次就迁走；64/79/119/120 直接 cordon 节点 + 上报送修。开工单时记下 XID 时间戳，RMA 溯源要用。

送修判据

任一非零 uncorrectable ECC、dcgmi diag -r 3 出现 FAIL、XID 64/79/119/120 出现一次、累计退役 HBM 页 >64、或 NVLink CRC 错误率 >1e-9——满足其一即送修。

日志位置

1
2
3
dmesg | grep -i xid
journalctl -k | grep -i nvrm
# 还有 /var/log/nvidia-installer.log、syslog/messages

小结

三层是一条递进的闭环：

  1. IB 网络先通——端口 Active、PIX 亲和、GDR 加载、ib_write_bw 达标；
  2. NCCL-tests 验带宽——看 busbw，单机/多机都过最低标准；
  3. XID/DCGM 盯运行——uncorrected ECC 为 0，XID 分级处置，异常自动进告警。

网络不通别谈带宽，带宽不达标别开训练，训练跑起来就靠监控兜底。数字都以自己环境的实测基准为准。

2026 更新：XID 告警的下一站不是告警群

这篇写于 2024 年。两年后回看,三板斧本身没变,变的是第三板斧的出口。

当年 XID 告警的终点是告警群里的一条消息,值班的人看到 XID 79,自己去翻上面那张速查表。现在这条链路在我这里长这样:

  1. XID/DCGM 事件进告警网关:去重(一块坏卡会在几分钟内重复报几十次)、按错误码分级(79/48 直接 high,13/31 先观察)、决策链落账;
  2. 值得深挖的升级给一个只读调查 Agent:它自己跑 dmesg、查 DCGM 指标、对照速查表和历史 case,几分钟后给出”这块卡该送修还是该先排除应用侧”的判断——上面那张 XID 速查表,现在是它的 runbook 的一部分;
  3. 调查结论蒸馏回 runbook,下一次同型号卡报同一个 XID,判断更快。

换句话说:2024 年这篇文章教人怎么查,2026 年它变成了机器查的时候照着用的东西。三板斧的知识没有过期,只是从”值班手册”变成了”agent 的技能文件”——这大概是运维笔记能有的最好归宿。