Document NCCL rail saturation evidence

2026-05-23 16:42:27 +08:00 · 2026-05-23 16:42:27 +08:00 · e756f0b7b4
commit e756f0b7b4
parent aa05ccab2e
2 changed files with 118 additions and 0 deletions
--- a/reports_multinode_nccl_counter_probe_20260523.md
+++ b/reports_multinode_nccl_counter_probe_20260523.md
@ -0,0 +1,80 @@
+# 多机 NCCL 8 卡链路计数器探测
+
+- 日期：2026-05-23
+- 主机：`aikubeworker0012` / `172.72.8.12`，`aikubeworker0016` / `172.72.8.16`
+- NCCL：临时 `2.27.7+cuda12.4`
+- HCA：`mlx5_0,mlx5_1,mlx5_6,mlx5_7`
+- HCA 速率：每节点 4 x 400Gb/s NDR，理论单向合计约 `200 GB/s`
+
+## 结论
+
+8 卡 allreduce 的 NCCL `algbw` 已经到 `189 GB/s` 左右，接近当前每节点 4 条 400G rail 的理论单向合计 `200 GB/s`。因此 PDF 参考的 `491.84 GB/s busbw` 对应 `262 GB/s algbw`，在当前 4 x 400G rail 形态下不太可能达到，除非实际可用跨节点 rail 数量或网络能力高于当前节点暴露的 4 条 400G。
+
+8 卡 alltoall 仍只有 `30 GB/s busbw`，不是 HCA 顺序导致。HCA 顺序 sweep 都稳定在 `30.02-30.07 GB/s`。计数器显示 alltoall 流量主要压在 `mlx5_0` 和 `mlx5_6` 上，`mlx5_1` 和 `mlx5_7` 只有约三分之一流量，说明剩余问题更像 NCCL alltoall rail 分布、路由、拥塞、NCCL net plugin/SHARP 或网络侧策略问题。
+
+## 8 卡 allreduce
+
+NCCL 输出：
+
+| Metric | Value |
+|--------|-------|
+| `algbw` | `189.16 / 189.07 GB/s` |
+| `busbw` | `354.68 / 354.52 GB/s` |
+| `Avg bus bandwidth` | `354.597 GB/s` |
+
+allreduce busbw 换算关系约为：
+
+```text
+busbw = algbw * 2 * (nranks - 1) / nranks
+      = algbw * 1.875  # nranks=16
+```
+
+因此：
+
+| 项 | busbw | 换算 algbw |
+|----|-------|------------|
+| 当前测试 | `354.60 GB/s` | `189.12 GB/s` |
+| PDF 参考 | `491.84 GB/s` | `262.31 GB/s` |
+
+当前 `189.12 GB/s algbw` 已接近 `4 x 400Gb/s = 200 GB/s` 理论单向总带宽。
+
+## 8 卡 alltoall
+
+NCCL 输出：
+
+| Metric | Value |
+|--------|-------|
+| `algbw` | `32.04 / 32.05 GB/s` |
+| `busbw` | `30.03 / 30.04 GB/s` |
+| `Avg bus bandwidth` | `30.0389 GB/s` |
+
+同一测试窗口内，端口计数器增量显示流量不均衡：
+
+| Host | HCA | Xmit GB | Recv GB |
+|------|-----|---------|---------|
+| 172.72.8.12 | `mlx5_0` | `885.54` | `885.51` |
+| 172.72.8.12 | `mlx5_1` | `295.19` | `295.19` |
+| 172.72.8.12 | `mlx5_6` | `885.53` | `885.51` |
+| 172.72.8.12 | `mlx5_7` | `295.19` | `295.19` |
+| 172.72.8.16 | `mlx5_0` | `885.51` | `885.54` |
+| 172.72.8.16 | `mlx5_1` | `295.19` | `295.19` |
+| 172.72.8.16 | `mlx5_6` | `885.51` | `885.53` |
+| 172.72.8.16 | `mlx5_7` | `295.19` | `295.19` |
+
+## HCA 顺序 sweep
+
+8 卡 alltoall 对 HCA 顺序不敏感：
+
+| `NCCL_IB_HCA` | Avg Bus BW |
+|---------------|------------|
+| `mlx5_0,mlx5_1,mlx5_6,mlx5_7` | `30.0367 GB/s` |
+| `mlx5_0,mlx5_6,mlx5_1,mlx5_7` | `30.0696 GB/s` |
+| `mlx5_0,mlx5_7,mlx5_1,mlx5_6` | `30.0397 GB/s` |
+| `mlx5_1,mlx5_0,mlx5_7,mlx5_6` | `30.0413 GB/s` |
+| `mlx5_6,mlx5_7,mlx5_0,mlx5_1` | `30.0230 GB/s` |
+
+## 判断
+
+1. 8 卡 allreduce 当前不是软件参数小调能解决的问题，性能已经贴近当前 4 条 400G rail 的物理带宽上限。
+2. 8 卡 alltoall 仍明显异常，且不是 HCA 顺序问题；需要继续从 NCCL alltoall rail 分布、网络路由/拥塞、NCCL net plugin/SHARP、交换机侧策略排查。
+3. 如果验收必须达到 PDF 的 2 机 16 卡 `491.84/76.54 GB/s`，需要确认当前两台机器是否具备与 PDF 参考环境同等的有效跨节点 rail 数量和交换网络能力。
--- a/reports_multinode_nccl_diagnosis_20260523.md
+++ b/reports_multinode_nccl_diagnosis_20260523.md
@ -272,6 +272,36 @@ NET/IB : GPU Direct RDMA Disabled for HCA 0 'mlx5_0'

 解释：2 机 4 卡档位已经基本定位并修复到接近 PDF；2 机 8 卡档位不是简单 GPU 顺序问题。尝试调整 8 卡 `CUDA_VISIBLE_DEVICES` 顺序、加入 100G/25G active HCA、以及套 PDF 固定参数都没有改善；固定参数反而会把 8 卡 allreduce 从约 `354 GB/s` 压到约 `239 GB/s`。

+### 8. 8 卡链路计数器与物理上限判断
+
+计数器探测报告：`reports_multinode_nccl_counter_probe_20260523.md`
+
+当前 2 机 8 GPU allreduce 输出：
+
+| Metric | Value |
+|--------|-------|
+| `algbw` | `189.16 / 189.07 GB/s` |
+| `busbw` | `354.68 / 354.52 GB/s` |
+| `Avg bus bandwidth` | `354.597 GB/s` |
+
+allreduce 在 16 ranks 下的换算关系约为：
+
+```text
+busbw = algbw * 2 * (nranks - 1) / nranks = algbw * 1.875
+```
+
+因此 PDF 参考 `491.84 GB/s busbw` 对应约 `262.31 GB/s algbw`。但当前节点可用的 400G HCA 是 `mlx5_0,mlx5_1,mlx5_6,mlx5_7`，每节点 4 条 400Gb/s，理论单向合计约 `200 GB/s`。当前 allreduce `189 GB/s algbw` 已经接近这个物理上限，所以 8 卡 allreduce 剩余差距基本不能靠 NCCL 参数小调解决。
+
+8 卡 alltoall 当前仍只有：
+
+| Metric | Value |
+|--------|-------|
+| `algbw` | `32.04 / 32.05 GB/s` |
+| `busbw` | `30.03 / 30.04 GB/s` |
+| `Avg bus bandwidth` | `30.0389 GB/s` |
+
+同一测试窗口内端口计数器显示 alltoall 流量分布不均衡：`mlx5_0` 和 `mlx5_6` 的流量约 `885 GB`，`mlx5_1` 和 `mlx5_7` 约 `295 GB`，约为三倍差距。继续调换 `NCCL_IB_HCA` 顺序后，8 卡 alltoall 仍稳定在 `30.02-30.07 GB/s`，说明不是简单 HCA 列表顺序问题。
+
 ## 当前阻塞

 ### 阻塞 1：当前生产 NCCL 版本过旧，GDR 被禁用
@ -297,6 +327,12 @@ NET/IB : GPU Direct RDMA Disabled for HCA 0 'mlx5_0'

 判断：2 机 8 GPU 档位的剩余差距更像硬件 rail 数量/交换网络/路由/拥塞/NCCL net plugin 能力问题，不再是旧 NCCL GDR disabled 或 4 卡 GPU 选择问题。

+补充证据：
+
+- 8 卡 allreduce `algbw ~= 189 GB/s`，接近当前 4 x 400G HCA 的理论单向合计 `200 GB/s`
+- PDF 8 卡 allreduce `491.84 GB/s busbw` 反推需要约 `262 GB/s algbw`，超过当前 4 x 400G 的物理单向总带宽
+- 8 卡 alltoall 端口计数器显示 rail 分布不均，且 HCA 顺序 sweep 无改善
+
 ### 阻塞 3：`nccl-gpu-2` SSH 存在外部连接压力

 现象：
@ -318,6 +354,7 @@ NET/IB : GPU Direct RDMA Disabled for HCA 0 'mlx5_0'
 6. 尝试安装或启用匹配当前 OFED/driver 的 NCCL net plugin/SHARP；当前日志显示 `Could not find: libnccl-net.so`，NCCL 使用的是 internal IB plugin。
 7. 核对跨 Leaf 链路的 rail mapping、交换机端口速率、路由和拥塞计数，确认 4 个 400Gb/s HCA 是否都在跨节点通信中充分利用。
 8. 确认当前 PDF 的 `491.84/76.54 GB/s` 是否要求当前这两台节点在只有 4 条 400G rail 的形态下也达到；如果要求一致，需要网络/硬件侧继续介入。
+9. 对 8 卡 alltoall，重点查 NCCL rail 分布、交换机 ECMP/自适应路由、拥塞计数、SHARP/NCCL net plugin，而不是继续调 `NCCL_IB_HCA` 顺序。

 ## 当前可交付物

@ -333,4 +370,5 @@ NET/IB : GPU Direct RDMA Disabled for HCA 0 'mlx5_0'
 - `reports_multinode_nccl_16g_2x8_nccl227.md`：NCCL 2.27.7 16G 大包报告
 - `reports_multinode_nccl_16g_2x8_nccl227_auto.md`：NCCL 2.27.7 16G 自动 channel/QP 原始报告
 - `reports_multinode_nccl_pdf_matrix_nccl227.md`：NCCL 2.27.7 PDF 矩阵式原始报告
+- `reports_multinode_nccl_counter_probe_20260523.md`：8 卡链路计数器与 HCA 顺序 sweep 报告
 - `reports_multinode_nccl_diagnosis_20260523.md`：本中文诊断总结