闯关预计 30 分钟

闯关：AllReduce 只有理论值一半

两节点 16 卡，busbw 卡在一半上不去。在模拟终端里查出它到底走没走 RDMA。

学完这节你能做到

算法团队报过来一句：

新集群的 NCCL 测试跑通了，正确性检查也过了，但 busbw 只有 190 GB/s，我们预期是 400。是不是网络没配好？

已知的硬件配置：

先自己算一遍理论峰值再往下看：

理论峰值 busbw = 网卡数 × 单口带宽 ÷ 8
              = 8 × 400 Gbps ÷ 8
              = 400 GB/s

实测 190 GB/s，只有 47.5%。参考判定标准：≥90% 优秀，80–90% 可接受，低于 80% 属于异常。所以这确实是个需要查的问题，而且"只有一半"这个比例本身就是很强的线索。

✓怎么玩

在终端里按目标一步步查。输入 goals 看目标，hint 要提示。四个目标达成即过关。

思路提示：先看结果、再看 NCCL 到底选了哪条路、再看硬件实际状态、最后看配置。

root@k8s-work-105

目标 0/4

2 节点 × 8 卡，每节点 8 × 400G RoCE。理论 busbw 400 GB/s，实测 190 GB/s。
测试任务已跑完，launcher pod 日志还在。

[root@k8s-work-105 ~]#

证据	说明了什么
`Wrong values : 0 OK`，busbw 190 GB/s	功能正常，纯粹是带宽问题
190 / 400 ≈ 47.5%，接近整整一半	强烈暗示"资源用了一半"
NCCL 日志 `NET/IB`、GPUDirect Enabled	走的是 RDMA，不是回退 TCP
NCCL 日志只列出 `mlx5_0`–`mlx5_3`	只有 4 张卡参与
`ibdev2netdev` 显示 8 张卡全部 Up	硬件与链路都正常
`ibstat mlx5_4`：Active / LinkUp / 400	未使用的卡本身完全健康
`NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3`	根因
`nvidia-smi topo -m`	GPU4–7 的近邻卡正好被排除，还额外跨了 NUMA

根因：NCCL_IB_HCA 只列了 4 张网卡（很可能是从 4 卡机型的配置抄来的），另外 4 张 400G 卡完全闲置。可用网络带宽只有一半，所以 busbw 也差不多是一半。

修法：

# 方案一：前缀匹配，把所有 mlx5 设备都纳入
NCCL_IB_HCA=mlx5

# 方案二：显式列全 8 张（想精确控制时用）
NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_2,mlx5_3,mlx5_4,mlx5_5,mlx5_6,mlx5_7

改完重跑，期望 busbw 到 360 GB/s 以上（理论峰值的 90%）。

!为什么「跑通了」不等于「配对了」

这次故障里正确性检查全过、NCCL 也确实走的 RDMA，唯一的症状就是数字偏低。如果没有人去算理论峰值并对比，这套集群会带着一半的带宽一直服役下去。

所以 GPU 集群交付必须有一条硬性验收：算出理论峰值，实测 busbw 达到 90% 才算通过。 这个数字是唯一能一次性覆盖网卡、链路、拓扑、拥塞控制和参数配置的端到端指标。

i顺便记住这几个「一半」的常见原因

busbw 大约只有理论值一半时，嫌疑名单（按出现频率排）：

NCCL_IB_HCA 少列了卡 —— 本例
PCIe 槽位喂不满网卡 —— 400G 卡插在 Gen4 x16 上，上限只有约 250 Gb。用 lspci -vv | grep LnkSta 核对，详见 PCIe：机内的那张网
端口速率协商降级（400G 口协商成 200G）—— 用 ibstat 看 Rate
NVLink 掉了几条链路 —— 机内变慢也会拉低整体 busbw，用 nvidia-smi topo -m 看 NV# 是否一致
rail 布线接错 —— 同 rail 流量被迫上 spine（拓扑那节细讲）
只有单向流量在跑 —— 测试参数或拓扑不对称

如果掉到只剩几分之一甚至十分之一，那通常不是"一半"类问题，而是回退到 TCP 了：去日志里找 NET/Socket。

检查点单选

NCCL 日志里出现 NET/Socket 而不是 NET/IB，意味着什么？

检查点单选

8 卡 × 400G 的节点，实测 busbw 190 GB/s。下面哪个排查顺序最合理？

检查点单选

本例中 nvidia-smi topo -m 提供了什么额外信息？