# 多机多卡 NCCL 诊断报告

- 日期：2026-05-23
- 测试入口：`nccl-gpu-1` / `aikubeworker0012` / `172.72.8.12`
- 对端节点：`nccl-gpu-2` / `aikubeworker0016` / `172.72.8.16`
- 诊断配置：`configs/multinode_nccl_nccl227_auto_16g.yaml`
- 当前最佳原始脚本报告：`reports_multinode_nccl_16g_2x8_nccl227_auto.md`

## 当前结论

这不是单纯 “IB 不通” 的问题。底层 CUDA RDMA perftest 可以跑到接近单端口 400Gb/s 的水平；最初使用 pip 包里的 NCCL 2.21.5 时，NCCL 在实际 2 节点通信中把 GPU Direct RDMA 禁用了，导致带宽显著偏低。

后续临时切换到 apt 包解压出的 NCCL 2.27.7+cuda12.4 后，NCCL GDR 已经恢复启用，2 节点 x 8 GPU allreduce 从 `67.42 GB/s` 提升到 `237.86 GB/s`，alltoall 从 `9.56 GB/s` 提升到 `28.62 GB/s`。

继续 tuning 后发现，配置里固定的 `NCCL_MIN_NCHANNELS=4`、`NCCL_IB_QPS_PER_CONNECTION=4`、`NCCL_IB_SPLIT_DATA_ON_QPS=1` 会明显压低 16G allreduce。去掉这些固定参数、让 NCCL 2.27.7 自动选择后，正式脚本报告中 2 节点 x 8 GPU allreduce 提升到 `354.60 GB/s`，alltoall 小幅提升到 `30.01 GB/s`。当前剩余问题不再是 GDR disabled，而是 GDR enabled 且 NCCL 自动调参后，仍低于当前配置里的验收阈值。

按 `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`。

同时，`nccl-gpu-2` 的 SSH 入口曾因未认证连接过多触发 `MaxStartups` 随机拒绝，导致 `mpirun` 拉起远端 rank 失败。已经做了临时 SSHD 缓解并拿到有效的 2 节点 x 8 GPU allreduce/alltoall 报告。

## 已完成的修正

1. 修正 `mpirun` 使用路径，避开系统 `/usr/bin/mpirun` 与 DOCA OpenMPI 动态库混用导致的崩溃。
2. 补充 `LD_LIBRARY_PATH`，确保 `mpirun`、CUDA、pip 安装的 NCCL 动态库可同时解析。
3. 将 NCCL HCA 限定到 400Gb/s 活跃端口：`mlx5_0,mlx5_1,mlx5_6,mlx5_7`。
4. 在脚本中加入 multi-node NCCL 网络诊断解析，报告会展示 `NCCL Network`、`GPU Direct RDMA`、`GDR Disabled HCAs`。
5. 增加 `multinode_nccl.extra_env`，可以在配置里快速试 NCCL 环境变量，不需要改代码。
6. 增加诊断配置 `configs/multinode_nccl_diagnostic.yaml`，固定跑 2 节点 x 8 GPU、256M、`NCCL_DEBUG=INFO` 和 `NCCL_DEBUG_SUBSYS=INIT,NET`。
7. 在 `nccl-gpu-2` 上临时提高 SSHD `MaxStartups` 并缩短 `LoginGraceTime`，缓解未认证连接过多导致的 SSH 随机拒绝。
8. 将 OpenMPI OOB TCP 控制通道固定到 `bond0`，并加入 `plm_rsh_args`，减少 `mpirun` 远端启动受 SSH/host key/接口选择影响的概率。
9. 从 NVIDIA apt 源下载但不安装 `libnccl2=2.27.7-1+cuda12.4`，解压到两台机器 `/tmp/nccl-2.27.7-cuda12.4`，用 `LD_LIBRARY_PATH` 临时覆盖 NCCL 运行库验证。
10. 增强报告解析，能够区分 `GPU Direct RDMA ENABLED` 和 `DISABLED`，并列出 enabled/disabled HCA。
11. 将 multi-node NCCL 配置中的 `qps_per_connection`、`min_nchannels`、`split_data_on_qps` 改为 `null`，避免默认导出会压低大包 allreduce 的固定 NCCL 参数。
12. 增加 topology 级 `cuda_visible_devices`、`env`、`op_env` 配置能力，支持按 GPU/NIC 亲和性和不同 NCCL op 分别设置环境变量。
13. 生成 PDF 矩阵式原始报告 `reports_multinode_nccl_pdf_matrix_nccl227.md`，覆盖 2 机 1/2/4/8 GPU per node。
14. 对 8 卡 alltoall 做 NCCL 网络参数 sweep，并将有效项 `NCCL_PXN_DISABLE=1` 固化到 PDF 矩阵配置。

## 关键证据

### 1. CUDA RDMA perftest 通过

命令类型：

```bash
CUDA_VISIBLE_DEVICES=0 ib_write_bw -d mlx5_0 -i 1 --use_cuda=0 -s 4194304 -F --report_gbits 172.72.8.16
```

结果：

| 测试 | 设备 | GPU | 平均带宽 | 结论 |
|------|------|-----|----------|------|
| `ib_write_bw --use_cuda` | `mlx5_0` | GPU0 | `387.16 Gb/s` | PASS |

解释：GPU 内存参与 RDMA 写带宽测试可以接近 400Gb/s，说明 `nvidia_peermem`/经典 GPUDirect RDMA 路径并非完全不可用。

### 2. CUDA DMA-BUF 路径不可用

命令类型：

```bash
CUDA_VISIBLE_DEVICES=0 ib_write_bw -d mlx5_0 -i 1 --use_cuda=0 --use_cuda_dmabuf -s 4194304 -F --report_gbits 172.72.8.16
```

结果：

| 测试 | 输出 | 结论 |
|------|------|------|
| `ib_write_bw --use_cuda_dmabuf` | `DMA-BUF is not supported on this GPU` | FAIL |

解释：当前环境不能走 CUDA DMA-BUF RDMA。后续 NCCL 应优先确认是否能稳定走经典 `nvidia_peermem` 路径。

### 3. NCCL 单卡跨节点仍禁用 GDR

使用 pip NCCL 2.21.5 时，

已经尝试：

- `NCCL_NET_GDR_LEVEL=SYS`
- `NCCL_NET_GDR_LEVEL=5`
- `NCCL_NET_GDR_READ=1`
- `NCCL_DMABUF_ENABLE=0`
- `NCCL_IB_CUDA_SUPPORT=1`
- `NCCL_IB_HCA=mlx5_0`

结果仍显示：

```text
NCCL INFO Using network IB
NCCL INFO NET/IB : GPU Direct RDMA Disabled for HCA 0 'mlx5_0'
```

256M allreduce 约 `13.4 GB/s`，明显低于 400Gb/s IB 端口能力。

### 3.1 NCCL 2.27.7 恢复 GDR

临时使用：

```bash
LD_LIBRARY_PATH=/usr/mpi/gcc/openmpi-4.1.9a1/lib:/tmp/nccl-2.27.7-cuda12.4/usr/lib/x86_64-linux-gnu:/usr/local/cuda-12.4/targets/x86_64-linux/lib
```

2 节点 x 1 GPU 日志显示：

```text
NCCL version 2.27.7+cuda12.4
NET/IB : GPU Direct RDMA Enabled for HCA 0 'mlx5_0'
Channel ... via NET/IB/0/GDRDMA
```

256M allreduce 从 NCCL 2.21.5 的约 `13.4 GB/s` 提升到 `45.2 GB/s`。判断：NCCL 2.21.5 与当前 driver/OFED/H100 组合存在 GDR 判定或注册路径兼容问题；升级 NCCL 是有效修复方向。

### 4. 脚本 2 节点 x 8 GPU 诊断结果

原始报告：`reports_multinode_nccl_diagnostic_2x8_sshfix.md`，使用 pip NCCL 2.21.5。

| Operation | Topology | Peak Bus BW | Threshold | Status | NCCL Network | GPU Direct RDMA |
|-----------|----------|-------------|-----------|--------|--------------|-----------------|
| allreduce | 2 nodes x 8 GPUs | `67.42 GB/s` | `>= 480 GB/s` | FAIL | IB | DISABLED |
| alltoall | 2 nodes x 8 GPUs | `9.56 GB/s` | `>= 75 GB/s` | FAIL | IB | DISABLED |

allreduce 失败原因是带宽不达标，且报告捕获到 GDR 被 NCCL 禁用：

| GDR Disabled HCAs |
|-------------------|
| `mlx5_0, mlx5_1, mlx5_6, mlx5_7` |

allreduce 和 alltoall 本轮均正常完成，`returncode=0`、`wrong=0`，失败原因是带宽低于阈值，不是正确性失败。

### 4.1 NCCL 2.27.7 诊断结果

256M 诊断报告：`reports_multinode_nccl_diagnostic_2x8_nccl227_v2.md`

| Operation | Topology | Peak Bus BW | Threshold | Status | NCCL Network | GPU Direct RDMA |
|-----------|----------|-------------|-----------|--------|--------------|-----------------|
| allreduce | 2 nodes x 8 GPUs | `212.19 GB/s` | `>= 480 GB/s` | FAIL | IB | ENABLED |
| alltoall | 2 nodes x 8 GPUs | `28.37 GB/s` | `>= 75 GB/s` | FAIL | IB | ENABLED |

1M 到 4G sweep 报告：`reports_multinode_nccl_sweep_2x8_nccl227.md`

| Operation | Peak Bus BW | Peak Size | Threshold | Status | GPU Direct RDMA |
|-----------|-------------|-----------|-----------|--------|-----------------|
| allreduce | `237.26 GB/s` | `4G` | `>= 480 GB/s` | FAIL | ENABLED |
| alltoall | `28.78 GB/s` | `1G` | `>= 75 GB/s` | FAIL | ENABLED |

16G 大包报告：`reports_multinode_nccl_16g_2x8_nccl227.md`

| Operation | Peak Bus BW | Peak Size | Threshold | Status | GPU Direct RDMA |
|-----------|-------------|-----------|-----------|--------|-----------------|
| allreduce | `237.86 GB/s` | `16G` | `>= 480 GB/s` | FAIL | ENABLED |
| alltoall | `28.62 GB/s` | `16G` | `>= 75 GB/s` | FAIL | ENABLED |

解释：NCCL 2.27.7 已经修复 GDR 禁用问题，且性能提升明显；但在固定 `min_nchannels=4/qps=4/split=1` 的配置下仍不达标。allreduce 约稳定在 `238 GB/s`，alltoall 约稳定在 `28-29 GB/s`。

### 4.2 NCCL 2.27.7 自动通道/QP 参数结果

进一步对 16G 大包做 tuning，发现默认配置里锁定的参数会压低 allreduce：

| 配置 | allreduce Avg Bus BW | alltoall Avg Bus BW | 结论 |
|------|----------------------|---------------------|------|
| NCCL 2.27.7 + 固定 `min_nchannels=4/qps=4/split=1` | `238.56 GB/s` | `28.62 GB/s` | GDR 已启用，但 allreduce 被压低 |
| NCCL 2.27.7 + NCCL 自动选择 channel/QP | `354.57 GB/s` | `30.02 GB/s` | 当前最佳脚本结果 |

正式脚本报告：`reports_multinode_nccl_16g_2x8_nccl227_auto.md`

| Operation | Peak Bus BW | Avg Bus BW | Peak Size | Threshold | Status | GPU Direct RDMA |
|-----------|-------------|------------|-----------|-----------|--------|-----------------|
| allreduce | `354.60 GB/s` | `354.57 GB/s` | `16G` | `>= 480 GB/s` | FAIL | ENABLED |
| alltoall | `30.01 GB/s` | `30.02 GB/s` | `16G` | `>= 75 GB/s` | FAIL | ENABLED |

对比临时 tuning 命令：

| 变量组合 | allreduce Avg Bus BW | alltoall Avg Bus BW |
|----------|----------------------|---------------------|
| baseline auto | `353.63 GB/s` | `30.05 GB/s` |
| `NCCL_IB_MERGE_NICS=1` | `352.73 GB/s` | `30.07 GB/s` |
| `NCCL_CROSS_NIC=1` | `354.68 GB/s` | `30.05 GB/s` |
| `NCCL_IB_QPS_PER_CONNECTION=8` + `NCCL_IB_SPLIT_DATA_ON_QPS=0` | `350.91 GB/s` | `29.41 GB/s` |
| `NCCL_MIN_NCHANNELS=16` + `NCCL_MAX_NCHANNELS=16` | `354.32 GB/s` | `30.06 GB/s` |

解释：allreduce 的主要提升来自取消不合适的固定参数，而不是 `MERGE_NICS` 或 `CROSS_NIC`。alltoall 对这些参数不敏感，当前基本稳定在 `30 GB/s` 左右。

### 5. SSHD MaxStartups 阻塞已临时缓解

`nccl-gpu-2` 曾显示：

```text
sshd: /usr/sbin/sshd -D [listener] 52 of 10-100 startups
maxstartups 10:30:100
```

同时存在大量 `sshd: unknown [priv]` / `sshd: unknown [net]` 未认证连接，来源主要是 `172.239.10.85`。这会触发 OpenSSH `MaxStartups` 随机拒绝，直接表现为：

```text
kex_exchange_identification: Connection closed by remote host
```

先临时改为：

```text
MaxStartups 120:30:240
LoginGraceTime 20
```

后续外部未认证连接继续上涨到 `110 of 120-240 startups`，测试窗口进一步临时改为：

```text
MaxStartups 500:30:1000
LoginGraceTime 5
```

改完后从 0012 连续 SSH 0016 5 次成功，2 节点 `mpirun hostname` 成功，2 节点 x 8 GPU allreduce/alltoall 也都能跑出有效结果。

### 6. `nvidia_peermem` legacy 模式实验无效

两台机器默认参数一致：

| 参数 | 值 |
|------|----|
| `nvidia_peermem` version | `580.159.03` |
| `peerdirect_support` | `0` |
| `persistent_api_support` | `1` |
| OFED | `OFED-internal-26.01-1.0.0` |

临时切换两台机器到 `peerdirect_support=1` 后，2 节点 x 1 GPU NCCL 仍显示：

```text
NET/IB : GPU Direct RDMA Disabled for HCA 0 'mlx5_0'
```

带宽仍约 `13.4 GB/s`。测试后已经恢复默认 `peerdirect_support=0,persistent_api_support=1`。

### 7. PDF 矩阵对齐与 GPU-NIC 亲和性

参考 PDF 的跨 Leaf 命令覆盖 2 机 2/4/8/16 卡矩阵，并使用：

- `NCCL_IB_GID_INDEX=3`
- `NCCL_IB_SL=5`
- `NCCL_IB_TC=136`
- `NCCL_SOCKET_IFNAME=bond0`
- `NCCL_IB_TIMEOUT=22`
- `NCCL_NET_PLUGIN=none`
- `NCCL_NVLS_ENABLE=1`

本环境与 PDF 参考机器有一个关键硬件差异：当前两台机器只有 `mlx5_0,mlx5_1,mlx5_6,mlx5_7` 是 400Gb/s NDR；`mlx5_4,mlx5_5` 是 100Gb/s HDR；`mlx5_2,mlx5_8` 是 25Gb/s；`mlx5_3,mlx5_9` 为 DOWN。参考 PDF 的命令列出了更多 HCA，但当前节点不能等价使用为 8 条 400G rail。

`nvidia-smi topo -m` 显示：

| GPU | 最近的 400G HCA |
|-----|-----------------|
| GPU0 | `mlx5_0` |
| GPU1 | `mlx5_1` |
| GPU4 | `mlx5_6` |
| GPU5 | `mlx5_7` |

默认 2 机 4 卡会选择 GPU0/1/2/3，其中 GPU2 最近的是 25G/down 端口，GPU3 没有直接对应 400G rail。因此 2 机 4 卡默认 allreduce 只有约 `168 GB/s`。显式设置 `CUDA_VISIBLE_DEVICES=0,1,4,5` 后：

| 场景 | allreduce | alltoall | 说明 |
|------|-----------|----------|------|
| 默认 GPU0/1/2/3 | `167.89 GB/s` | `39.68 GB/s` | GPU/NIC 亲和性错误 |
| `CUDA_VISIBLE_DEVICES=0,1,4,5` + auto NCCL | `335.34 GB/s` | `63.90 GB/s` | allreduce 接近 PDF |
| `CUDA_VISIBLE_DEVICES=0,1,4,5` + PDF 固定参数 | `225.29 GB/s` | `73.10 GB/s` | alltoall 接近 PDF，但 allreduce 被压低 |

因此当前脚本支持按 op 配环境变量：4 卡 allreduce 用 auto，4 卡 alltoall 用 PDF 固定参数。

矩阵式正式报告：`reports_multinode_nccl_pdf_matrix_nccl227.md`

| Topology | allreduce | PDF Reference | Status | alltoall | PDF Reference | Status |
|----------|-----------|---------------|--------|----------|---------------|--------|
| 2 nodes x 1 GPU | `47.26 GB/s` | `48.90 GB/s` | FAIL | `24.87 GB/s` | `27.25 GB/s` | FAIL |
| 2 nodes x 2 GPUs | `136.36 GB/s` | `136.93 GB/s` | FAIL | `47.69 GB/s` | `54.41 GB/s` | FAIL |
| 2 nodes x 4 GPUs | `333.23 GB/s` | `335.48 GB/s` | FAIL | `72.82 GB/s` | `73.73 GB/s` | FAIL |
| 2 nodes x 8 GPUs | `353.47 GB/s` | `491.84 GB/s` | FAIL | `36.70 GB/s` | `76.54 GB/s` | FAIL |

解释：2 机 4 卡档位已经基本定位并修复到接近 PDF；2 机 8 卡档位不是简单 GPU 顺序问题。尝试调整 8 卡 `CUDA_VISIBLE_DEVICES` 顺序、加入 100G/25G active HCA、以及套 PDF 固定参数都没有改善；固定参数反而会把 8 卡 allreduce 从约 `354 GB/s` 压到约 `239 GB/s`。

8 卡 alltoall 目前的最佳软件侧改动是 `NCCL_PXN_DISABLE=1`：

| Case | 8 卡 alltoall Avg Bus BW |
|------|--------------------------|
| baseline | `30.06 GB/s` |
| `NCCL_PXN_DISABLE=1` | `37.24 GB/s` |
| 正式矩阵报告 | `36.74 GB/s` |

其他变量如 `NCCL_P2P_PXN_LEVEL`、`NCCL_NET_SHARED_COMMS`、`NCCL_NET_SHARED_BUFFERS`、`NCCL_NCHANNELS_PER_NET_PEER`、`NCCL_IB_ADAPTIVE_ROUTING` 均无改善或变差。

### 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 参数小调解决。

裸 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 |
|--------|-------|
| `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 列表顺序问题。

### 9. NCCL net plugin / SHARP 状态

两台机器上均未找到：

- `libnccl-net.so`
- `libsharp*`
- SHARP/HCOLL 相关 deb 包

当前仅看到 UCX 包：

```text
ucx 1.20.0-1.20260211.d9a4f352d.2601100
```

apt 源里与 NCCL 直接相关的包只有：

```text
libnccl2
libnccl-dev
```

因此当前 NCCL 日志里的 `Could not find: libnccl-net.so` 是真实环境缺失，不是脚本漏配路径。当前运行走的是 NCCL internal IB plugin；如果要继续追 8 卡 alltoall 或 PDF 2 机 16 卡参考值，需要补齐匹配当前 OFED/driver/CUDA/NCCL 的 NCCL net plugin/SHARP 环境，或由网络侧确认该集群不依赖这些组件也能达到目标值。

## 当前阻塞

### 阻塞 1：当前生产 NCCL 版本过旧，GDR 被禁用

现象：

- pip NCCL 2.21.5：`GPU Direct RDMA Disabled`，2x8 allreduce `67.42 GB/s`
- 临时 NCCL 2.27.7：`GPU Direct RDMA Enabled`，2x8 allreduce `237.86 GB/s`
- 因此，生产测试环境应避免继续使用 pip NCCL 2.21.5 作为多机 NCCL 验收运行库

判断：底层 RDMA 能力存在，GDR 禁用主要由旧 NCCL 版本触发。建议正式安装并固定 NCCL 2.27.7+cuda12.4 或更新的已验证版本。

### 阻塞 2：2 机 8 GPU 档位仍低于 PDF 参考值

现象：

- 2x8 16G allreduce：`354.02 GB/s`，PDF 参考 `491.84 GB/s`
- 2x8 16G alltoall：`30.04 GB/s`，PDF 参考 `76.54 GB/s`
- 已使用 4 个 400Gb/s HCA：`mlx5_0, mlx5_1, mlx5_6, mlx5_7`
- 加入 `mlx5_4,mlx5_5` 100G HCA 或 `mlx5_2,mlx5_8` 25G HCA 基本无收益
- 调整 8 卡 `CUDA_VISIBLE_DEVICES` 顺序基本无收益
- 套 PDF 固定参数会让 8 卡 allreduce 明显变差

判断：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`
- 裸 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
- `NCCL_PXN_DISABLE=1` 可将 8 卡 alltoall 提升到约 `36.7 GB/s`，但仍不到 PDF 参考值的一半

### 阻塞 3：`nccl-gpu-2` SSH 存在外部连接压力

现象：

- 多次出现过：`kex_exchange_identification: Connection closed by remote host`
- 根因是未认证连接过多触发 `MaxStartups`
- 当前已经通过临时 SSHD 配置缓解，并拿到了有效 2x8 报告
- 但如果外部连接压力持续，仍建议从网络侧或安全策略侧处理来源连接

判断：这不再阻塞当前报告产出，但属于环境稳定性风险。

## 建议下一步

1. 从网络/安全侧处理 `172.239.10.85` 等来源的 SSH 未认证连接压力，或者保留更高的 `MaxStartups` 配置作为测试窗口临时策略。
2. 正式安装并固定已验证的 NCCL 2.27.7+cuda12.4 或更新版本，不要依赖 pip NCCL 2.21.5；当前 `/tmp/nccl-2.27.7-cuda12.4` 只是临时解压验证。
3. 4 卡 per node 测试应显式使用 `CUDA_VISIBLE_DEVICES=0,1,4,5`，避免默认 GPU0/1/2/3 落到错误 GPU/NIC 亲和性。
4. 4 卡 allreduce 建议继续让 NCCL 自动选择 channel/QP；4 卡 alltoall 如果要贴近 PDF，可单独套 `NCCL_IB_QPS_PER_CONNECTION=4`、`NCCL_MIN_NCHANNELS=4`、`NCCL_IB_SPLIT_DATA_ON_QPS=1`。
5. 8 卡 per node 不建议套上述固定参数，会降低 allreduce；继续用 auto。
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` 顺序。

## 当前可交付物

- `configs/multinode_nccl_diagnostic.yaml`：多机多卡诊断配置
- `configs/multinode_nccl_nccl227_diagnostic.yaml`：NCCL 2.27.7 256M 诊断配置
- `configs/multinode_nccl_nccl227_sweep.yaml`：NCCL 2.27.7 1M 到 4G sweep 配置
- `configs/multinode_nccl_nccl227_16g.yaml`：NCCL 2.27.7 16G 大包配置
- `configs/multinode_nccl_nccl227_auto_16g.yaml`：NCCL 2.27.7 16G 自动 channel/QP 配置
- `configs/multinode_nccl_nccl227_pdf_matrix.yaml`：按 PDF 矩阵和 GPU 亲和性优化后的跨 Leaf 配置
- `reports_multinode_nccl_diagnostic_2x8_sshfix.md`：脚本生成的原始 2x8 诊断报告
- `reports_multinode_nccl_diagnostic_2x8_nccl227_v2.md`：NCCL 2.27.7 256M 诊断报告
- `reports_multinode_nccl_sweep_2x8_nccl227.md`：NCCL 2.27.7 1M 到 4G sweep 报告
- `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_alltoall_tuning_20260523.md`：8 卡 alltoall NCCL 网络参数 sweep 报告
- `reports_multinode_nccl_diagnosis_20260523.md`：本中文诊断总结