From 48a27472e25a43e35404dc750d67d122b1a45f9c Mon Sep 17 00:00:00 2001 From: cs Date: Sat, 23 May 2026 16:42:27 +0800 Subject: [PATCH] Document NCCL rail saturation evidence --- ...s_multinode_nccl_counter_probe_20260523.md | 80 +++++++++++++++++++ reports_multinode_nccl_diagnosis_20260523.md | 38 +++++++++ 2 files changed, 118 insertions(+) create mode 100644 reports_multinode_nccl_counter_probe_20260523.md diff --git a/reports_multinode_nccl_counter_probe_20260523.md b/reports_multinode_nccl_counter_probe_20260523.md new file mode 100644 index 0000000..9ccc52c --- /dev/null +++ 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 数量和交换网络能力。 diff --git a/reports_multinode_nccl_diagnosis_20260523.md b/reports_multinode_nccl_diagnosis_20260523.md index fccf1b7..42d7b52 100644 --- 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`：本中文诊断总结