Document NCCL environment equivalence gaps

This commit is contained in:
cs 2026-05-23 18:54:35 +08:00
parent adcdb36e05
commit b914cb7b4b

View File

@ -0,0 +1,168 @@
# 多节点 NCCL 环境等价性缺口说明 2026-05-23
## 目的
这份文档用于回答一个核心问题:当前 `aikubeworker0012` / `aikubeworker0016` 是否具备与参考 PDF 的 2 机 16 GPU NCCL 目标相同的硬件和 NCCL 网络软件环境。
结论先行:**当前环境不能证明与 PDF 参考环境等价**。主要差异有两类:
1. 当前每节点只有 4 条可用于 NCCL 的 400G InfiniBand rail。
2. 当前没有外部 NCCL net plugin / SHARP / HCOLL 组件NCCL 使用 internal IB plugin。
## 采集时间和节点
采集时间:`2026-05-23T10:53:18+00:00``2026-05-23T10:53:21+00:00`
| 节点 | SSH alias | 内网地址 | kernel |
|---|---|---|---|
| `aikubeworker0012` | `nccl-gpu-1` | `172.72.8.12` | `5.15.0-119-generic` |
| `aikubeworker0016` | `nccl-gpu-2` | `172.72.8.16` | `5.15.0-119-generic` |
## HCA / Rail 现状
两台机器的 `/sys/class/infiniband/mlx5_*/ports/1` 结果一致:
| HCA | State | Rate | Link layer | 对 NCCL 跨节点验收的含义 |
|---|---|---:|---|---|
| `mlx5_0` | ACTIVE | `400 Gb/sec (4X NDR)` | InfiniBand | 可作为 400G rail |
| `mlx5_1` | ACTIVE | `400 Gb/sec (4X NDR)` | InfiniBand | 可作为 400G rail |
| `mlx5_2` | ACTIVE | `25 Gb/sec (1X EDR)` | Ethernet | 不是 400G IB rail |
| `mlx5_3` | DOWN | `25 Gb/sec (1X EDR)` | Ethernet | 不可用 |
| `mlx5_4` | ACTIVE | `100 Gb/sec (2X HDR)` | InfiniBand | 不是 400G rail |
| `mlx5_5` | ACTIVE | `100 Gb/sec (2X HDR)` | InfiniBand | 不是 400G rail |
| `mlx5_6` | ACTIVE | `400 Gb/sec (4X NDR)` | InfiniBand | 可作为 400G rail |
| `mlx5_7` | ACTIVE | `400 Gb/sec (4X NDR)` | InfiniBand | 可作为 400G rail |
| `mlx5_8` | ACTIVE | `25 Gb/sec (1X EDR)` | Ethernet | 不是 400G IB rail |
| `mlx5_9` | DOWN | `25 Gb/sec (1X EDR)` | Ethernet | 不可用 |
因此当前推荐并实际使用的 HCA 列表是:
```text
NCCL_IB_HCA=mlx5_0,mlx5_1,mlx5_6,mlx5_7
```
这代表每节点 `4 x 400Gb/s`,理论单向原始带宽约:
```text
4 * 400Gb/s / 8 = 200 GB/s
```
## 与 PDF 目标的物理带宽关系
参考 PDF 的 2 机 16 GPU 目标:
| Operation | PDF Bus BW |
|---|---:|
| AllReduce | `491.84 GB/s` |
| AllToAll | `76.54 GB/s` |
NCCL allreduce 在 16 ranks 下,`busbw = algbw * 2 * (n - 1) / n = algbw * 1.875`
因此 PDF 的 allreduce `491.84 GB/s busbw` 反推:
```text
491.84 / 1.875 = 262.31 GB/s algbw
```
但当前 4 条 400G rail 的理论单向原始带宽约 `200 GB/s`。本项目实测 2x8 allreduce
| 测试 | Bus BW | 反推 Alg BW |
|---|---:|---:|
| 本轮深度诊断 allreduce | `354.025 GB/s` | `188.81 GB/s` |
| 本轮 GRAPH allreduce | `354.224 GB/s` | `188.92 GB/s` |
这已经接近当前 4 x 400G rail 的物理单向上限。除非 PDF 参考环境具备更多有效 400G rail、更高交换网络能力或使用了当前缺失的网络加速组件否则当前 2x8 allreduce 很难靠 NCCL 环境变量小调达到 `491.84 GB/s`
## GPU-NIC 亲和性影响
`nvidia-smi topo -m` 显示的 NIC legend 两台一致:
| NIC | HCA |
|---|---|
| NIC0 | `mlx5_0` |
| NIC1 | `mlx5_1` |
| NIC2 | `mlx5_2` |
| NIC3 | `mlx5_3` |
| NIC4 | `mlx5_4` |
| NIC5 | `mlx5_5` |
| NIC6 | `mlx5_6` |
| NIC7 | `mlx5_7` |
| NIC8 | `mlx5_8` |
| NIC9 | `mlx5_9` |
关键亲和关系:
| GPU | 最近的有效 400G HCA |
|---|---|
| GPU0 | `mlx5_0` |
| GPU1 | `mlx5_1` |
| GPU4 | `mlx5_6` |
| GPU5 | `mlx5_7` |
这解释了为什么 2 机 4 GPU 档位需要使用:
```text
CUDA_VISIBLE_DEVICES=0,1,4,5
```
默认 GPU0/1/2/3 会把 GPU2/GPU3 放到非理想 NIC 亲和路径上,其中 GPU2 最近的 `mlx5_2/3` 不是可用 400G IB rail。
## NCCL Net Plugin / SHARP 状态
在两台节点上搜索:
```text
find /usr /opt /tmp /root -name 'libnccl-net*.so*' -o -name 'libsharp*.so*'
```
结果为空。
两台节点包列表中能看到:
| 包 | 版本/说明 |
|---|---|
| `doca-ofed` | `3.3.0-088000` |
| `mlnx-ofed-kernel-dkms` | `26.01.OFED.26.01.1.0.0.1-1` |
| `ucx` | `1.20.0-1.20260211...` |
未看到:
- `libnccl-net.so`
- `libsharp*.so`
- SHARP packages
- HCOLL packages
本轮 NCCL GRAPH 日志也显示 `plugin_missing=16`,说明 NCCL 只能走 internal IB plugin。
## 当前 2x8 结果归因边界
已经基本排除:
- 不是 SSH / mpirun launch 问题preflight 已通过。
- 不是 HCA 完全不可用4 条 400G rail 都 ACTIVEallreduce 能跑到约 `354 GB/s busbw`
- 不是 GDR disabledNCCL `2.27.7` 日志中 GDR enabled。
- 不是 rail 完全打偏:`NCCL_PXN_DISABLE=1` 后 alltoall 四条 rail 流量均衡。
- 不是明显坏链路/重传counter 未见 discard、RoCE retrans、slow restart、packet sequence error 等增长。
仍然成立的缺口:
1. **2x8 allreduce 的 PDF 目标疑似超过当前 4 x 400G rail 物理能力。**
2. **2x8 alltoall 即使 rail 均衡仍只有 `36-37 GB/s`,更像 NCCL alltoall 图策略、internal IB plugin 能力、缺少 SHARP/NCCL net plugin 或交换网络策略问题。**
## 给网络/环境侧的确认清单
请网络/环境侧确认以下问题:
1. PDF 参考环境每节点实际参与 NCCL 的 400G rail 数量是多少?是否为 8 条 400G而不是当前的 4 条 400G
2. PDF 命令中列出的 HCA 列表是否在参考环境中全部为 400G InfiniBand ACTIVE
3. PDF 参考环境是否启用了 NCCL net plugin、SHARP、HCOLL、UCX plugin 或交换机侧 SHARP aggregation
4. 当前交换网络是否开启 adaptive routing / ECMP / congestion control是否存在跨 Leaf 场景下对 alltoall pattern 不友好的 hash 或路径限制?
5. 当前 `mlx5_4/5` 为什么只有 100G`mlx5_2/8` 为什么是 Ethernet 25G`mlx5_3/9` 为什么 DOWN这些是否符合机器采购和验收预期
6. 如果验收必须按 PDF 的 `491.84/76.54 GB/s`,是否需要更换到与 PDF 等价的 rail 数量/交换网络/软件栈再测。
## 建议下一步
1. 暂停继续盲调 NCCL 小参数;已有 sweep 显示收益不稳定或负向。
2. 先让硬件/网络侧确认 rail 数量和速率是否与 PDF 等价。
3. 如果确认硬件等价,再补齐 NCCL net plugin / SHARP 环境,并用 `scripts/multinode_nccl_deep_diagnose.sh graph` 复查 plugin 和 graph 变化。
4. 如果硬件不等价,应调整验收阈值或改用与 PDF 等价的节点组合复测。