han.zhao/test_gpu_scripts
1
0
Fork 0
Code Issues Pull Requests 2 Actions Packages Projects Releases Wiki Activity

Document NCCL alltoall secondary sweep

Browse Source
This commit is contained in:
cs 2026-05-23 17:28:28 +08:00
parent 71ac97a24e
commit 9a32645c9d
2 changed files with 50 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
reports_multinode_nccl_alltoall_tuning_20260523.md
View File

@ -14,7 +14,7 @@
复测错误/拥塞 counter 后，没有看到 discard、链路错误、RoCE 重传、slow restart 或 packet sequence error 增长；主要非零异常是部分端口 `port_xmit_wait`。不过 allreduce 对照在 `354 GB/s busbw` 时也会出现同类 `port_xmit_wait`，所以当前不支持“链路坏包/重传导致慢”的判断，也不能只用 `port_xmit_wait` 解释 alltoall 低吞吐。更可能的方向是 NCCL internal alltoall 通信模式效率、交换侧调度/拥塞控制，或缺少 NCCL net plugin/SHARP。
这个提升有实际价值，但仍远低于 PDF 参考 `76.54 GB/s`。其他参数没有改善，部分明显变差：
这个提升有实际价值，但仍远低于 PDF 参考 `76.54 GB/s`。在 `NCCL_PXN_DISABLE=1` 之前做过一轮参数 sweep，其他参数没有改善，部分明显变差：
| Case | Avg Bus BW | 结论 |
|------|------------|------|
@ -32,6 +32,31 @@
| `NCCL_IB_ADAPTIVE_ROUTING=0` | `30.0535 GB/s` | 无改善 |
| `NCCL_IB_PCI_RELAXED_ORDERING=0` | 未完成 | 明显异常，不建议 |
在 `NCCL_PXN_DISABLE=1` 作为基线后又补跑了一轮叠加参数 sweep。短测窗口里 `NVLS_ENABLE=0`、`P2P_NET_CHUNKSIZE=4M` 有小幅波动式提升，但更长 `-w 10 -n 10` 复测没有复现，不能作为稳定优化项。
| Case | Avg Bus BW | 结论 |
|------|------------|------|
| `NCCL_PXN_DISABLE=1` | `37.0069 GB/s` | 短测基线 |
| `+ NCCL_NVLS_ENABLE=0` | `37.2217 GB/s` | 小幅波动，不稳定 |
| `+ NCCL_P2P_NET_CHUNKSIZE=4194304` | `37.2522 GB/s` | 小幅波动，不稳定 |
| `+ NCCL_BUFFSIZE=8388608` | `37.0911 GB/s` | 无实质改善 |
| `+ NCCL_MIN_NCHANNELS=16 NCCL_MAX_NCHANNELS=16` | `37.0189 GB/s` | 无实质改善 |
| `+ NCCL_IB_AR_THRESHOLD=0` | `37.0843 GB/s` | 无实质改善 |
| `+ NCCL_IB_QPS_PER_CONNECTION=4 NCCL_IB_SPLIT_DATA_ON_QPS=0` | `35.9847 GB/s` | 变差 |
| `+ NCCL_IB_QPS_PER_CONNECTION=4 NCCL_IB_SPLIT_DATA_ON_QPS=1` | `29.8406 GB/s` | 明显变差 |
| `+ NCCL_IB_QPS_PER_CONNECTION=8 NCCL_IB_SPLIT_DATA_ON_QPS=1` | `24.1183 GB/s` | 明显变差 |
| `+ NCCL_NCHANNELS_PER_NET_PEER=8` | `29.8904 GB/s` | 明显变差 |
长测复核：
| Case | Avg Bus BW | 结论 |
|------|------------|------|
| `NCCL_PXN_DISABLE=1` | `32.7280 GB/s` | 当前窗口基线下滑 |
| `+ NCCL_P2P_NET_CHUNKSIZE=4194304` | `31.9340 GB/s` | 未复现短测提升 |
| `+ NCCL_NVLS_ENABLE=0 NCCL_P2P_NET_CHUNKSIZE=4194304` | `27.6585 GB/s` | 明显变差 |
补充 ENV/INIT/NET 日志确认，性能波动时仍是 NCCL `2.27.7+cuda12.4`、4 条 400G HCA、GDR enabled、internal IB plugin；不是退回旧 NCCL、HCA 选择错误或 GDR 失效。
## PXN disabled 端口计数器
`NCCL_PXN_DISABLE=1` 后，8 卡 alltoall 输出：
@ -103,5 +128,6 @@ op_env:
1. PXN 在当前拓扑下对 8 卡 alltoall 有负面影响，禁用后有约 `22-24%` 提升。
2. 禁用 PXN 可以修复 rail 分布不均衡，但无法打满每条 400G rail。
3. 禁用 PXN 后仍只有 PDF 目标的一半左右，剩余差距不是单一 NCCL 环境变量可以补齐。
4. 后续重点仍应放在 NCCL net plugin/SHARP、交换网络策略和 NCCL internal alltoall 实现效率；`port_xmit_wait` 需要结合 allreduce 对照解读，不能单独作为 alltoall 根因。
3. PXN disabled 基线上继续叠加 NVLS、P2P chunk、buffer、channel、QP/split、AR 等参数，没有稳定收益；QP/split 和 `NCCL_NCHANNELS_PER_NET_PEER=8` 反而明显变差。
4. 禁用 PXN 后仍只有 PDF 目标的一半左右，剩余差距不是单一 NCCL 环境变量可以补齐。
5. 后续重点仍应放在 NCCL net plugin/SHARP、交换网络策略和 NCCL internal alltoall 实现效率；`port_xmit_wait` 需要结合 allreduce 对照解读，不能单独作为 alltoall 根因。

23
reports_multinode_nccl_diagnosis_20260523.md
View File

@ -16,7 +16,7 @@
按 `sx算力节点跨Leaf NCCL测试报告.pdf` 的矩阵继续对齐后，发现 2 机 4 卡档位的核心问题是默认 GPU 选择不符合 GPU-NIC 亲和性。显式选择 `CUDA_VISIBLE_DEVICES=0,1,4,5` 后，2 机 4 卡 allreduce 可以恢复到 `333-335 GB/s` 区间，接近 PDF 的 `335.48 GB/s`；alltoall 配合 PDF 固定 NCCL 参数可到 `72.93 GB/s`，接近 PDF 的 `73.73 GB/s`。但 2 机 8 卡档位仍只有 allreduce `354.02 GB/s`、alltoall `30.04 GB/s`，与 PDF 的 `491.84/76.54 GB/s` 差距明显。
进一步 sweep 8 卡 alltoall 网络参数后，`NCCL_PXN_DISABLE=1` 是唯一有效正向项。正式矩阵配置已对 2 机 8 GPU 的 alltoall 单独加入该变量，8 卡 alltoall 从约 `30.04 GB/s` 提升到 `36.70 GB/s` peak / `36.74 GB/s` avg，但仍低于 PDF 参考 `76.54 GB/s`。复测端口 counter 后，PXN disabled 下 4 条 rail 的流量已均衡，且没有明显链路错误、丢包、RoCE 重传或 slow restart；同类 `port_xmit_wait` 在高吞吐 allreduce 中也会出现，因此它不是 alltoall 低吞吐的充分解释。剩余差距更像 NCCL internal alltoall 通信模式效率、交换网络策略，或缺少 NCCL net plugin/SHARP 能力。
进一步 sweep 8 卡 alltoall 网络参数后，`NCCL_PXN_DISABLE=1` 是唯一有效正向项。正式矩阵配置已对 2 机 8 GPU 的 alltoall 单独加入该变量，8 卡 alltoall 从约 `30.04 GB/s` 提升到 `36.70 GB/s` peak / `36.74 GB/s` avg，但仍低于 PDF 参考 `76.54 GB/s`。复测端口 counter 后，PXN disabled 下 4 条 rail 的流量已均衡，且没有明显链路错误、丢包、RoCE 重传或 slow restart；同类 `port_xmit_wait` 在高吞吐 allreduce 中也会出现，因此它不是 alltoall 低吞吐的充分解释。继续在 PXN disabled 基线上叠加 NVLS、P2P chunk、buffer、channel、QP/split、AR 等参数，没有稳定收益。剩余差距更像 NCCL internal alltoall 通信模式效率、交换网络策略，或缺少 NCCL net plugin/SHARP 能力。
同时，`nccl-gpu-2` 的 SSH 入口曾因未认证连接过多触发 `MaxStartups` 随机拒绝，导致 `mpirun` 拉起远端 rank 失败。已经做了临时 SSHD 缓解并拿到有效的 2 节点 x 8 GPU allreduce/alltoall 报告。
@ -38,6 +38,7 @@
14. 对 8 卡 alltoall 做 NCCL 网络参数 sweep，并将有效项 `NCCL_PXN_DISABLE=1` 固化到 PDF 矩阵配置。
15. 对 PXN disabled 后的 8 卡 alltoall 抓取 `counters`/`hw_counters` 增量，确认 rail 已均衡且无明显错误/重传。
16. 对同样 2x8 allreduce 抓 counter 对照，确认高吞吐 allreduce 也会出现 `port_xmit_wait`，因此该 counter 不是 alltoall 低吞吐的唯一根因。
17. 在 PXN disabled 基线上继续 sweep NVLS、P2P chunk、buffer、channel、QP/split、AR 等参数，确认没有稳定收益，部分参数明显变差。
## 关键证据
@ -319,6 +320,23 @@ PXN disabled 计数器显示该参数确实修复了 rail 分布：
判断：allreduce 在接近物理上限时也会出现 `port_xmit_wait`，所以 alltoall 的核心问题不能只归因于该 counter。现在更应关注 NCCL alltoall 通信模式、交换网络策略、以及 NCCL net plugin/SHARP 能力差异。
PXN disabled 基线上的二次参数 sweep：
| Case | Avg Bus BW | 结论 |
|------|------------|------|
| `NCCL_PXN_DISABLE=1` | `37.0069 GB/s` | 短测基线 |
| `+ NCCL_NVLS_ENABLE=0` | `37.2217 GB/s` | 小幅波动，不稳定 |
| `+ NCCL_P2P_NET_CHUNKSIZE=4194304` | `37.2522 GB/s` | 小幅波动，不稳定 |
| `+ NCCL_BUFFSIZE=8388608` | `37.0911 GB/s` | 无实质改善 |
| `+ NCCL_MIN_NCHANNELS=16 NCCL_MAX_NCHANNELS=16` | `37.0189 GB/s` | 无实质改善 |
| `+ NCCL_IB_AR_THRESHOLD=0` | `37.0843 GB/s` | 无实质改善 |
| `+ NCCL_IB_QPS_PER_CONNECTION=4 NCCL_IB_SPLIT_DATA_ON_QPS=0` | `35.9847 GB/s` | 变差 |
| `+ NCCL_IB_QPS_PER_CONNECTION=4 NCCL_IB_SPLIT_DATA_ON_QPS=1` | `29.8406 GB/s` | 明显变差 |
| `+ NCCL_IB_QPS_PER_CONNECTION=8 NCCL_IB_SPLIT_DATA_ON_QPS=1` | `24.1183 GB/s` | 明显变差 |
| `+ NCCL_NCHANNELS_PER_NET_PEER=8` | `29.8904 GB/s` | 明显变差 |
长测复核没有复现 `NVLS/P2P chunk` 的短测小涨：同一环境确认仍为 NCCL `2.27.7+cuda12.4`、4 条 400G HCA、GDR enabled、internal IB plugin，但 baseline 窗口下滑到 `32.7280 GB/s`，`P2P_NET_CHUNKSIZE=4M` 为 `31.9340 GB/s`，`NVLS_ENABLE=0 + P2P_NET_CHUNKSIZE=4M` 为 `27.6585 GB/s`。因此这些参数不应固化到正式配置。
### 8. 8 卡链路计数器与物理上限判断
计数器探测报告：`reports_multinode_nccl_counter_probe_20260523.md`
@ -421,6 +439,7 @@ libnccl-dev
- `NCCL_PXN_DISABLE=1` 可将 8 卡 alltoall 提升到约 `36.7 GB/s`，并修复 rail 分布不均，但仍不到 PDF 参考值的一半
- PXN disabled 复测没有看到 discard、链路错误、RoCE 重传、slow restart、packet sequence error 等错误类 counter 增长
- allreduce 对照同样出现 `port_xmit_wait` 但能跑到 `354.366 GB/s`，说明 `port_xmit_wait` 不是 alltoall 低吞吐的唯一根因
- PXN disabled 基线上继续叠加 NVLS、P2P chunk、buffer、channel、QP/split、AR 等参数没有稳定收益；QP/split 和 `NCCL_NCHANNELS_PER_NET_PEER=8` 明显变差
### 阻塞 3：`nccl-gpu-2` SSH 存在外部连接压力
@ -443,7 +462,7 @@ libnccl-dev
6. 尝试安装或启用匹配当前 OFED/driver 的 NCCL net plugin/SHARP；当前日志显示 `Could not find: libnccl-net.so`，NCCL 使用的是 internal IB plugin。
7. 核对跨 Leaf 链路的 rail mapping、交换机端口速率、路由、credit/拥塞等待与交换机侧队列计数；同时用 allreduce 对照避免把 `port_xmit_wait` 误判为 alltoall 独有根因。
8. 确认当前 PDF 的 `491.84/76.54 GB/s` 是否要求当前这两台节点在只有 4 条 400G rail 的形态下也达到；如果要求一致，需要网络/硬件侧继续介入。
9. 对 8 卡 alltoall，重点查 SHARP/NCCL net plugin、NCCL internal alltoall 行为、交换机 ECMP/自适应路由和拥塞/credit 等待；`NCCL_IB_HCA` 顺序与 rail 分布本身已经不是当前主问题。
9. 8 卡 alltoall 当前不建议继续盲调 NCCL 环境变量；重点查 SHARP/NCCL net plugin、NCCL internal alltoall 行为、交换机 ECMP/自适应路由和拥塞/credit 等待；`NCCL_IB_HCA` 顺序与 rail 分布本身已经不是当前主问题。
## 当前可交付物