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

整理一份自用的 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 在大集群上训练吞吐能差两三成，值得在布线阶段就规划好。

常用诊断命令

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" 能看到

网络验收清单

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

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

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

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

编译

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`）

GDR 开了吗：日志里找 GDRDMA；没有就查 lsmod | grep nvidia_peermem；
HCA 数量对吗：日志列出的网卡数应等于物理 HCA 数；
GID Index：RoCEv2 通常 3、纯 IB 通常 0——配错会静默变慢；
PXN 开了吗：不开的话同 NUMA 的跨 GPU 流量绕主机内存，掉约 30%；
算法：小数据 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

小结

三层是一条递进的闭环：

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

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