# 多节点 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 都 ACTIVE，allreduce 能跑到约 `354 GB/s busbw`。
- 不是 GDR disabled：NCCL `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 等价的节点组合复测。