From a64e964e3cf470f62d8e5a5827e40f6a90687489 Mon Sep 17 00:00:00 2001 From: cs Date: Sat, 23 May 2026 16:46:15 +0800 Subject: [PATCH] Add raw RDMA rail bandwidth evidence --- ...s_multinode_nccl_counter_probe_20260523.md | 29 ++++++++++++++++--- reports_multinode_nccl_diagnosis_20260523.md | 13 +++++++++ 2 files changed, 38 insertions(+), 4 deletions(-) diff --git a/reports_multinode_nccl_counter_probe_20260523.md b/reports_multinode_nccl_counter_probe_20260523.md index debc0bc..784b5c4 100644 --- a/reports_multinode_nccl_counter_probe_20260523.md +++ b/reports_multinode_nccl_counter_probe_20260523.md @@ -10,8 +10,28 @@ 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。 +裸 RDMA 并发 perftest 也验证了这 4 条 400G rail 本身可以同时工作：4 个 HCA 并发 `ib_write_bw` 合计 `1476.95 Gb/s`，即 `184.62 GB/s`。这与 NCCL 8 卡 allreduce 换算出的 `189 GB/s algbw` 一致，说明 allreduce 已经接近裸网络可用带宽。 + 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 或网络侧策略问题。 +## 裸 RDMA 4 rail 并发 + +命令类型： + +```bash +ib_write_bw -d -i 1 -p -s 4194304 -n 5000 -F --report_gbits +``` + +结果： + +| HCA | BW average | +|-----|------------| +| `mlx5_0` | `387.16 Gb/s` | +| `mlx5_1` | `387.07 Gb/s` | +| `mlx5_6` | `355.02 Gb/s` | +| `mlx5_7` | `347.70 Gb/s` | +| Total | `1476.95 Gb/s` / `184.62 GB/s` | + ## 8 卡 allreduce NCCL 输出： @@ -75,7 +95,8 @@ NCCL 输出： ## 判断 -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 数量和交换网络能力。 -4. 两台机器当前均未发现 `libnccl-net.so` 或 SHARP/HCOLL 包，NCCL 使用 internal IB plugin；如果目标值依赖 NCCL net plugin/SHARP，需要先补齐对应运行环境。 +1. 裸 RDMA 4 rail 可以并发跑到约 `184.62 GB/s`，网络基础带宽不是单 rail 瓶颈。 +2. 8 卡 allreduce 当前不是软件参数小调能解决的问题，性能已经贴近当前 4 条 400G rail 的物理带宽上限。 +3. 8 卡 alltoall 仍明显异常，且不是 HCA 顺序问题；需要继续从 NCCL alltoall rail 分布、网络路由/拥塞、NCCL net plugin/SHARP、交换机侧策略排查。 +4. 如果验收必须达到 PDF 的 2 机 16 卡 `491.84/76.54 GB/s`，需要确认当前两台机器是否具备与 PDF 参考环境同等的有效跨节点 rail 数量和交换网络能力。 +5. 两台机器当前均未发现 `libnccl-net.so` 或 SHARP/HCOLL 包，NCCL 使用 internal IB plugin；如果目标值依赖 NCCL net plugin/SHARP，需要先补齐对应运行环境。 diff --git a/reports_multinode_nccl_diagnosis_20260523.md b/reports_multinode_nccl_diagnosis_20260523.md index fce5084..8253caf 100644 --- a/reports_multinode_nccl_diagnosis_20260523.md +++ b/reports_multinode_nccl_diagnosis_20260523.md @@ -292,6 +292,18 @@ 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 参数小调解决。 +裸 RDMA 4 rail 并发 `ib_write_bw` 也验证了底层 4 条 400G rail 可以同时工作： + +| HCA | BW average | +|-----|------------| +| `mlx5_0` | `387.16 Gb/s` | +| `mlx5_1` | `387.07 Gb/s` | +| `mlx5_6` | `355.02 Gb/s` | +| `mlx5_7` | `347.70 Gb/s` | +| Total | `1476.95 Gb/s` / `184.62 GB/s` | + +这个裸 RDMA 总带宽与 NCCL 8 卡 allreduce 的 `189 GB/s algbw` 接近，进一步说明 allreduce 已经贴近当前网络形态可提供的实际带宽。 + 8 卡 alltoall 当前仍只有： | Metric | Value | @@ -353,6 +365,7 @@ libnccl-dev 补充证据： - 8 卡 allreduce `algbw ~= 189 GB/s`，接近当前 4 x 400G HCA 的理论单向合计 `200 GB/s` +- 裸 RDMA 4 rail 并发 `ib_write_bw` 合计 `1476.95 Gb/s` / `184.62 GB/s` - PDF 8 卡 allreduce `491.84 GB/s busbw` 反推需要约 `262 GB/s algbw`，超过当前 4 x 400G 的物理单向总带宽 - 8 卡 alltoall 端口计数器显示 rail 分布不均，且 HCA 顺序 sweep 无改善 - 当前环境缺失 NCCL net plugin/SHARP，NCCL 只能使用 internal IB plugin