动手：NCCL 与 busbw 判读

busbw 是 GPU 集群的体检报告

perftest 验证的是"某一段是对的"：两张卡之间点对点能跑满线速。 但它测不出多机多卡同时通信时的表现。

NCCL 的 AllReduce 测试补上这一环。它一个数字就能覆盖：网卡、PCIe、NVLink、链路速率、 rail 布线、拥塞控制、参数配置——任何一处错都会反映在 busbw 上。

所以它既是调优工具，也是交付验收的最终指标。

先算理论峰值

不知道目标值，测出来的数字没有意义。公式很简单：

理论峰值 busbw = 每节点计算网卡数 × 单口带宽 ÷ 8

判定标准（来自实践口径）：

两个任务，顺序不能反

先做任务一，通过了再做任务二。 正确性没过就调性能是白费功夫。

-i 0 让数据量不递增，配合 -b/-e 相等，程序就会一直循环输出同一个尺寸的结果。

关键环境变量

配错任何一个，结果都会失真。分两类看。

所有机型一致的

按机型/网络差异的

NCCL_IB_HCA=mlx5                    # 前缀匹配，所有 mlx5* 设备
NCCL_IB_HCA=mlx5_0,mlx5_1,...       # 显式列举（要列全！）
NCCL_IB_HCA=^=mlx5_4                # 排除某个设备

调试时才开的

NCCL_DEBUG=INFO
NCCL_DEBUG_SUBSYS=INIT,NET,GRAPH     # 只看初始化、网络选择、拓扑

集合通信原语

AllReduce 是最常用的（数据并行的梯度同步就是它），但要理解 busbw 得先知道它做了什么：

Ring AllReduce 的实现是 ReduceScatter + AllGather 两阶段， 每张卡都要收发 2(n-1)/n 倍的数据——这正是下面校正因子的来源。

busbw 与 algbw：为什么要两个指标

测试输出有两列带宽，很多人只看后面那个而不知道区别：

#      size    count    type   redop   time   algbw   busbw #wrong
    8589934592 2147483648 float sum  84744.2  101.36  190.05      0

AllReduce 的校正因子是：

busbw = algbw × 2(n − 1)/n        n = GPU 总数

16 卡时：2 × 15 / 16 = 1.875，所以 101.36 × 1.875 ≈ 190.05。

跑一次完整测试

以 Kubeflow Trainer 提交为例（配置来自实践仓库）：

kubectl apply -f nccl-tests-b200.yaml

# 看完整日志（含 NCCL 初始化，--tail=-1 别省）
kubectl logs -l trainer.kubeflow.org/replicated-job-name=launcher -f --tail=-1

完成标准（三条都要过）

# Out of bounds values : 0 OK        ← 正确性
# Wrong values : 0 OK                ← 正确性
峰值 busbw ≥ 理论峰值 × 90%           ← 性能

扩展到 N 个节点要改两处

# numNodes 与 mpirun 的 -np 必须同时改，-np = 节点数 × 每节点 GPU 数
sed -e 's/numNodes: 2/numNodes: 4/' \
    -e 's/-np 16/-np 32/' \
    nccl-tests-b200.yaml > nccl-tests-4node.yaml
diff nccl-tests-b200.yaml nccl-tests-4node.yaml     # 改完先看 diff

只改一处是高频错误：numNodes 改了但 -np 没改， 结果只有一部分 GPU 参与，busbw 看起来"莫名偏低"。

转成压测

sed 's|all_reduce_perf -b 8 -e 16G -f 2 -g 1|all_reduce_perf -b 8G -e 8G -i 0 -g 1|' \
    nccl-tests-b200.yaml > nccl-tests-stress.yaml
kubectl apply -f nccl-tests-stress.yaml
# 跑够时长后手动停
kubectl delete -f nccl-tests-stress.yaml

判读日志：三行定生死

kubectl logs <launcher-pod> | grep -E 'NET/|Using network|GPU Direct'

NCCL INFO NET/IB : Using [0]mlx5_0:1/RoCE [1]mlx5_1:1/RoCE ... [7]mlx5_7:1/RoCE
NCCL INFO NET/IB : GPU Direct RDMA Enabled for HCA 0 'mlx5_0'
NCCL INFO Using network IB

这三行是排查 busbw 偏低的第一站，比调参数快得多。

busbw 偏低的排查顺序

busbw 不达标
   │
   ├─ 只剩几分之一（低于 30%）
   │     → 日志找 NET/Socket：回退 TCP 了
   │       查 NCCL_IB_DISABLE、NCCL_IB_HCA 设备名、Pod 内 ibv_devinfo 是否看得到设备
   │
   ├─ 约一半
   │     → ① NCCL_IB_HCA 少列了卡（日志里数一下）
   │       ② 端口速率降级（ibstat | grep Rate）
   │       ③ rail 布线接错（ibnetdiscover 核对）
   │       ④ numNodes 改了但 -np 没改
   │
   ├─ 约 60%
   │     → PCIe 代际/lane 不够（lspci LnkSta，400G 要 Gen5 x16）
   │
   ├─ 80–90% 且抖动
   │     → RoCE 无损配置：PFC 计数是否暴涨、NCCL_IB_TC 是否设置
   │
   └─ 单点异常（某几张卡慢）
         → NVLink 掉链（nvidia-smi topo -m 看 NV 数是否一致）
           或 BER 恶化（perfquery -a）

# 每次测试后记录关键字段
date +%F,$(kubectl logs <launcher> | awk '/Avg bus bandwidth/{print $NF}')

检查点

这节课的落点

• 理论峰值 = 网卡数 × 单口带宽 ÷ 8；判定线：≥90% 优秀、80–90% 可接受、低于 80% 必查
• 两个任务顺序不能反：单次扫描测正确性与曲线，通过后再做固定尺寸压测
• 固定 NCCL_ALGO=Ring 保证可比；NCCL_IB_DISABLE=0 否则回退 TCP
• NCCL_IB_HCA 是最容易出错的一个，从别的机型抄配置会少用卡
• 验收看 busbw 不看 algbw；busbw = algbw × 2(n−1)/n，因子的作用是消除规模影响
• 扩节点要同时改 numNodes 与 -np，只改一处会让部分 GPU 不参与
• 日志三行定生死：NET/IB vs NET/Socket、列出的 HCA 数量、GPU Direct RDMA Enabled
• 偏低比例即线索：几分之一 = 回退 TCP、一半 = 少卡/降速/接错 rail、60% = PCIe 不够
• 存基线定期复测，这一层的故障几乎都是静默退化