GPU能识别，RDMA端口处于Active状态，交换机也没有明显告警，多机训练吞吐为什么还是上不去？

设备状态正常，只能说明一部分检查通过了。一次分布式训练中的数据，需要经过GPU内存、节点内互连、网卡和交换网络；其中任何一段选路不合理、容量不足或配置不一致，都可能放大为训练中的等待。

直接用完整训练任务验收集群，很难区分问题来自通信、计算、数据加载还是存储。更有效的做法是：先使用NCCL-tests建立通信基线，再把真实训练接进来验证。 本文按“单机 → 双机 → 多节点”的顺序展开，重点回答三个问题：

1. 集合通信是否正确完成？
2. 相同条件下，性能是否稳定且达到基线？
3. 异常从哪个节点规模、哪类消息或哪段路径开始出现？

先明确验收边界

NCCL-tests用于测试NCCL通信操作的正确性和性能。本文以AllReduce为主线；如果实际训练主要依赖AllGather、ReduceScatter或点对点通信，还应增加相应测试，不能用一项AllReduce结果覆盖所有通信模式。

验收遵循逐级扩大范围、逐级保留证据的原则：每一级通过后再进入下一级；性能比较需要保持节点规模、消息大小和软件配置一致。

建立可复现、可比较的基线

基线是一组条件，不是一个带宽数字

“AllReduce达到多少GB/s才算合格”没有适用于所有集群的统一答案。GPU型号、NVLink/PCIe拓扑、网卡数量、网络分层、软件版本和消息大小，都会影响结果。

正式测试前，至少记录以下信息：

下面的命令可以作为每个节点的基础采集模板。RDMA工具由发行版或网卡软件包提供，缺失时需先安装对应组件。

BASELINE_DIR="nccl-baseline/$(hostname)/$(date +%Y%m%d-%H%M%S)"
mkdir -p "$BASELINE_DIR/environment"

nvidia-smi > "$BASELINE_DIR/environment/gpu.txt"
nvidia-smi topo -m > "$BASELINE_DIR/environment/topology.txt"
lscpu > "$BASELINE_DIR/environment/cpu.txt"
uname -a > "$BASELINE_DIR/environment/kernel.txt"
nvcc --version > "$BASELINE_DIR/environment/cuda-toolkit.txt" 2>&1
mpirun --version > "$BASELINE_DIR/environment/mpi.txt" 2>&1
ibstat > "$BASELINE_DIR/environment/rdma.txt" 2>&1
ibdev2netdev -v > "$BASELINE_DIR/environment/rdma-netdev.txt" 2>&1
env | sort | grep '^NCCL_' > "$BASELINE_DIR/environment/nccl-env.txt"

nvidia-smi中显示的CUDA版本不能直接替代Toolkit或程序运行时版本记录。还应保存测试日志中的NCCL版本，以及实际使用的动态库和网络插件信息。若使用NCCL配置文件，也要一并归档；仅记录环境变量可能遗漏配置来源。

建议每次测试独立保存“环境、完整命令、原始输出、诊断日志、结论”，并按单机、双机、4节点、8节点和完整规模分类。首次上线没有历史数据时，可先选定经过验证的参考节点与节点组合，形成初始基线，再扩展到全量设备。

先约定比较口径

比较当前结果与历史结果时，要同时匹配 节点规模、消息大小、通信操作、数据类型和进程布局。单进程管理8张GPU与8个进程各管理1张GPU，是两种不同的测试配置。

本文建议每组配置至少独立运行3次，保留每个消息大小的结果，并使用中位数辅助比较。这是验收方法建议，不是NCCL的强制标准；如果环境波动明显，应增加重复次数并查明原因。

验收前由项目约定两类指标：

• 性能偏差：同条件下，当前结果相对参考基线下降多少需要调查。
• 稳定性：多次运行之间的波动，以及测试期间的错误、重试和异常等待是否可接受。

阈值应由历史分布、硬件目标和业务需求共同确定，不能把示例中的某个百分比当成通用标准。

单机：先排除节点内部异常

检查GPU、PCIe、NUMA与P2P

nvidia-smi
nvidia-smi topo -m

重点核对GPU数量与型号、节点内连接关系、GPU到NIC的路径，以及CPU/NUMA亲和性。拓扑输出需要结合服务器硬件设计解读，不能只凭GPU与NIC的编号判断“就近”。

GPU间带宽与传输能力可使用NVIDIA的 nvbandwidth辅助检查，并选择与当前GPU和软件环境匹配的测试项。这类结果不能直接证明GPU-NIC的RDMA路径正常。旧环境中常见的p2pBandwidthLatencyTest已在CUDA Samples 13.4中移除，复用旧流程前应先检查工具版本。CUDA Samples变更记录

如果单机已经异常，应先处理节点内问题。此时直接扩大到多机，会把本地瓶颈与网络瓶颈混在一起。

编译支持多进程的nccl-tests

后续要运行多机测试，必须在编译时启用MPI支持。 仅执行普通make，不能替代这一前提。官方构建说明给出了MPI=1与MPI_HOME的用法。

下面假设CUDA、NCCL和Open MPI分别安装在示例路径中；修改为真实位置后执行：

git clone https://github.com/NVIDIA/nccl-tests.git
cd nccl-tests

# 正式验收应检出团队验证过的提交，并记录该提交号。
git rev-parse HEAD

make -j"$(nproc)" \
  MPI=1 \
  MPI_HOME=/opt/openmpi \
  CUDA_HOME=/usr/local/cuda \
  NCCL_HOME=/usr

./build/all_reduce_perf -h
ldd ./build/all_reduce_perf

检查帮助输出是否包含需要的参数，动态库是否能正确解析。将同一构建产物部署到各节点相同的绝对路径，并确认启动它的MPI与编译时使用的MPI相兼容。本文后续统一使用/opt/nccl-tests/build/all_reduce_perf作为部署路径。

先扫消息范围，再做大消息测试

只测试1 GiB以上的大消息，会漏掉小消息延迟和算法切换区间。建议先做完整扫描，再根据实际训练中的通信消息分布加密采样。

单节点、单进程、8张GPU的起步示例：

set -o pipefail
mkdir -p results/single-node

/opt/nccl-tests/build/all_reduce_perf \
  -b 8 -e 1G -f 2 \
  -t 1 -g 8 \
  -d float -o sum \
  -w 20 -n 100 -c 1 \
  2>&1 | tee results/single-node/allreduce-scan.log

pipefail让管道保留测试程序的失败状态，避免只看到tee成功便误判测试成功。重复测试时使用不同的文件名或独立目录，保留每次原始输出。

在常规、未拆分通信组的运行中，总NCCL rank数为“进程数 × 每进程线程数 × 每线程GPU数”。参数语义以安装版本的帮助输出及 nccl-tests使用说明为准。

这里的1G是1 GiB的消息大小，不是整个程序的显存占用上限。发送、接收、校验缓冲区及NCCL自身还会消耗显存；扩大到8G前，必须按GPU可用显存验证。消息上限应贴近业务并留有余量。

保留与多机一致的进程布局

如果多机验收采用“一进程一GPU”，单机也应补一组同布局结果，用于后续比较：

mpirun -np 8 \
  --map-by ppr:8:node --bind-to none \
  /opt/nccl-tests/build/all_reduce_perf \
  -b 8 -e 1G -f 2 \
  -t 1 -g 1 -d float -o sum \
  -w 20 -n 100 -c 1

此命令应在仅分配了该单节点的运行环境中执行。--bind-to none用于明确这组示例不施加MPI CPU绑定；生产验收应采用经过验证的CPU/GPU亲和性策略，并在各规模中保持一致。进程映射选项属于Open MPI，详见 mpirun手册。

双机：确认GPU-NIC与跨节点路径

单机正常后，再验证两台机器之间的通信。检查应覆盖“GPU → 本地NIC → 网络 → 远端NIC → GPU”，但这是一条逻辑检查路径，并不表示数据必须经过主机内存或由CPU转发。

RDMA端口正常，还需要传输验证

IB环境可先检查：

ibstat
ibstatus
ibdev2netdev -v

确认HCA（RDMA适配器）与端口识别正确、链路状态和速率符合设计，并核对RDMA设备与Linux网络接口的映射。RoCE还需要检查IP、VLAN、MTU、优先级以及按网络设计配置的拥塞控制机制。

有条件时先运行perftest的点对点带宽测试。下面是基本用法，实际设备名和RoCE参数以本机帮助与网络配置为准：

# 服务端节点
ib_write_bw -d mlx5_0 -a

# 客户端节点：将示例地址替换为服务端可达地址
SERVER_IP=192.0.2.10
ib_write_bw -d mlx5_0 -a "$SERVER_IP"

两条命令分别在两台节点上执行，服务端需要先启动。常规主机内存测试通过，只说明对应RDMA路径有传输能力；验证GPU内存路径还需使用支持CUDA的构建及匹配参数。相关方法见 NCCL网络排障文档。

RoCE GID配置要区分版本

不要把其他集群的NCCL_IB_GID_INDEX值直接复制过来。它与设备、端口、地址和RoCE配置有关。

NVIDIA的排障文档说明：NCCL 2.21及之后的版本会动态选择GID，通常应保持NCCL_IB_GID_INDEX未设置；旧版本需要结合show_gids等信息确定合适的索引。若自动选择结果与预期不符，先核对地址与网络配置，再依据对应版本文档排查。版本说明

GPU-NIC亲和性与Rail映射

GPU0靠近NIC0，并不意味着所有服务器上的mlx5_0都连接同一个Rail。设备枚举编号、PCIe位置与交换机端口是三个需要分别核对的信息。

建议维护一张实际映射表，至少记录“节点、GPU UUID/PCI地址、HCA/端口、NUMA、Leaf端口、Rail”。先验证节点内访问路径，再验证跨节点连接关系。

判断Rail对齐要看实际数据路径，而不只看设备编号：下图只示意选定的流量路径，其他连接省略。

Rail对齐的价值，是让通信路径与网络分区设计相匹配，减少本可避免的跨Rail流量干扰。跨Rail并不必然低效，共享链路也不必然拥塞：还要看容量、路由、并发流量，以及Collective的实际通信模式。

NCCL_CROSS_NIC影响Ring/Tree是否使用不同NIC，必须结合网络拓扑理解，不能把某个取值当作所有多网卡集群的通用优化。相关语义见 NCCL_CROSS_NIC文档。

GPUDirect RDMA不能靠一个模块判定

GPUDirect RDMA（GDR）涉及GPU、NIC、PCIe、驱动、内存注册机制和通信库。nvidia-peermem已加载，并不能单独证明测试实际使用了GDR；没有该模块，也不能直接判定GDR不可用。

在满足条件的内核与驱动组合下，NCCL可以使用DMA-BUF，因此判断时要同时看软件栈支持情况、GPU-NIC拓扑、实际传输日志和GPU内存通信测试。NVIDIA对相关机制的说明

区分网络选择参数

即使数据通过RDMA传输，初始化与连接信息交换仍可能涉及IP网络。看到Socket相关日志时，应区分初始化过程与真正的数据传输后端；不能仅凭一行日志判断是否“退回TCP”。参数详见 NCCL环境变量文档。

运行双机AllReduce

执行前确认以下条件：

• 两台节点各提供8张可见GPU，资源已分配给当前测试。
• 各节点的程序、动态库和运行目录可访问，MPI能成功启动远端进程。
• 进程到GPU的分配符合预期，没有多个本地进程意外挤到同一张GPU。
• 两台节点的软件配置与测试参数一致，测试时没有其他任务争抢资源。

以下命令采用16个MPI进程，每节点8个进程、每进程1张GPU：

set -o pipefail
mkdir -p results/2-node

mpirun \
  -H node1:8,node2:8 -np 16 \
  --map-by ppr:8:node --bind-to none \
  /opt/nccl-tests/build/all_reduce_perf \
  -b 8 -e 1G -f 2 \
  -t 1 -g 1 -d float -o sum \
  -w 20 -n 100 -c 1 \
  2>&1 | tee results/2-node/allreduce-scan.log

-H、--map-by和--bind-to是Open MPI的启动选项；调度器分配的资源边界仍然有效，不能仅靠增加-np越过资源配额。Open MPI启动选项

第一次运行先检查输出中的主机、rank和GPU分配，再看性能。否则，即使得到一组数字，也可能测到与计划不同的配置。

读懂输出：正确性、延迟与带宽分别看

先检查测试是否正确完成

读结果时，建议采用以下顺序：

1. 确认预期rank全部参与，程序正常结束，没有挂起或超时。
2. 确认已启用正确性检查，查看错误计数及程序末尾的检查结果。
3. 区分输出中的out-of-place与in-place结果，使用同一组列与历史数据比较。
4. 按消息大小分析时间和带宽，而不是只看最终平均值。

若版本输出包含#wrong或Out of bounds values等校验信息，应确认校验实际执行且未报告错误。关闭检查得到的高带宽，不能作为正确性通过的证据。字段名称与格式以当前构建的输出为准；其校验逻辑可参见 nccl-tests源码。

time、algbw与busbw的关系

对AllReduce，令S为每个rank的消息字节数，t为通信时间（秒），N为该通信组的rank数：

algbw = S / t
busbw = algbw × 2 × (N - 1) / N

带宽输出为GB/s时，需要在字节/秒的结果上再除以10^9。其他Collective的折算关系不同，不能直接套用AllReduce公式。官方性能指标说明

举一个仅用于解释公式的算术示例：16个rank，每个rank的消息大小为1 GiB，通信耗时为20 ms，则algbw ≈ 53.69 GB/s，busbw ≈ 100.66 GB/s。这不是实测结果，也不是验收门槛。

busbw并非某张NIC的实时吞吐计数器，也不等于所有网卡或整个集群的总流量。它可以结合拓扑与硬件上限辅助分析，但不能直接与单端口标称速率画等号。比较网卡速率时，还要区分 Gb/s（比特） 与 GB/s（字节）。

不要让平均值掩盖问题

一个“看起来不错”的平均带宽，可能掩盖三类异常：

• 小消息延迟偏高，影响频繁同步的工作负载。
• 某个消息区间突然下降，需要检查算法、协议、资源占用或路径变化。
• 多次运行波动明显，可能存在并发负载、链路重试或不稳定节点。

因此，结果报告至少要保留每个消息大小的耗时、带宽和正确性状态。遇到短时停顿或长尾，仅有平均耗时还不够，应结合版本支持的逐次计时、系统监控或训练时间线继续分析。

用NCCL日志确认实际路径

把日志与测试结果一起保存

当结果低于基线时，应检查NCCL实际识别了哪些GPU、选了哪些HCA、使用了什么传输后端，以及算法和拓扑选择是否符合预期。

下面的双机诊断示例将配置显式传给远端进程。-x是Open MPI的环境变量传递选项；如果还设置了经过验证的HCA或接口筛选变量，也需要确保各远端进程实际收到正确配置。

export NCCL_DEBUG=INFO
export NCCL_DEBUG_SUBSYS=INIT,ENV,GRAPH,NET,TUNING
export NCCL_DEBUG_FILE='/tmp/nccl-diagnostic.%h.%p.log'

mpirun \
  -H node1:8,node2:8 -np 16 \
  --map-by ppr:8:node --bind-to none \
  -x NCCL_DEBUG -x NCCL_DEBUG_SUBSYS -x NCCL_DEBUG_FILE \
  /opt/nccl-tests/build/all_reduce_perf \
  -b 8 -e 1G -f 2 \
  -t 1 -g 1 -d float -o sum \
  -w 20 -n 100 -c 1

%h与%p分别展开为主机名和进程PID，避免同一轮多个进程写入同一个日志文件。文件会生成在各节点自己的/tmp中，测试后应立即收集到本次结果目录；后续运行还应使用独立目录或批次前缀，以免PID复用造成覆盖。NCCL日志配置

建议按“初始化错误 → 设备选择 → 传输路径 → 拓扑与调优”的顺序读日志。不要只搜索一个关键词：插件名称、日志内容及传输实现可能随版本变化，需要联系上下文解读。

对照测试一次只改变一个因素

日志提供线索，对照实验才帮助缩小原因。例如：

以单机算法诊断为例，可在相同参数下分别设置：

NCCL_ALGO=Ring /opt/nccl-tests/build/all_reduce_perf \
  -b 1M -e 1G -f 2 -t 1 -g 8 -d float -o sum -w 20 -n 100 -c 1

NCCL_ALGO=Tree /opt/nccl-tests/build/all_reduce_perf \
  -b 1M -e 1G -f 2 -t 1 -g 8 -d float -o sum -w 20 -n 100 -c 1

这是诊断用的算法限制，不是生产推荐配置；所选算法还必须受当前版本与操作支持。默认策略也可能使用Ring/Tree之外的算法。多机复现实验时，应将变量传给所有进程，并在日志中核对生效情况。NCCL_ALGO说明

完成排障后，恢复计划用于验收的配置重新测试，并把最终配置与基线绑定保存。对于容器或虚拟机中的初始化异常，还应检查设备可见性、拓扑暴露、共享内存和内存锁定资源；这些问题不能仅靠换算法解决。NCCL环境排障说明

多节点：寻找异常扩展拐点

扩规模，也要换节点组合

双机通过后，按2 → 4 → 8 → 完整规模逐步扩展。每增加一级，保持消息范围、软件配置和每节点进程布局一致，并使用相同规模的参考结果作为主要比较对象。

不要要求单机、双机和8节点得到相同带宽。节点内互连与跨节点网络的能力不同，Collective的通信结构也会变化；规模增加后的下降，只有相对预期趋势或对应基线出现异常偏离时，才构成排障线索。

只用一组固定节点还不够。假如4节点正常、8节点异常，需要区分：

• 规模效应：跨越了新的网络层级、机架或共享资源。
• 成员效应：新增节点中存在硬件、软件或连接差异。

可将8节点拆成不同的4节点组合，并轮换参考节点测试，观察异常是跟随节点移动，还是只在跨越某条网络路径时出现。

保存可用于定位的记录

下面是结果表模板。每个消息大小、节点组合和运行批次应有独立记录；不要把不同消息的带宽混成一个平均值。表外统一注明数据类型、操作、进程布局、时间单位及对应的原始日志位置。

对某个固定消息大小，可用下面的方式表达带宽回退程度：

带宽回退率 = 1 - 当前多次运行的带宽中位数 / 同条件基线带宽中位数

对延迟则应比较耗时是否上升，两者不要混用。同一批测试还应记录链路错误、丢弃或重试计数器的变化，让性能曲线能够与网络证据对应。

根据异常边界安排排查顺序

异常首次出现在哪里，就从哪里缩小排查范围。这是排查优先级，不是因果证明；结论需要日志、链路计数器和对照测试共同支持。

例如，双机正常而跨机架测试变慢，可以优先调查Rail/Leaf-Spine路径、共享链路和新增节点配置；但仍需要通过节点替换、链路计数器和日志验证原因，不能只凭规模变化就断言“交换机拥塞”。

通信通过后，再验证真实训练

NCCL-tests通过，说明所测配置下的通信具备参考表现，不代表所有模型的训练吞吐都已达标。

真实训练还受到数据加载、存储吞吐、CPU/NUMA、计算内核、进程绑定、调度，以及通信与计算重叠（Overlap）的影响。还要考虑训练实际采用的数据类型、消息大小、通信组划分和Collective是否被测试覆盖。

如果通信基线正常、训练仍然偏慢，应结合训练Profiler的时间线观察：

训练验收应固定模型、全局与局部batch size、精度、并行策略、序列长度和数据条件，再比较端到端吞吐及训练步耗时。

将检查项变成可交付的验收结论

验收结论至少应包含四层证据：

上线前检查清单

环境与拓扑

• GPU、NIC数量和型号符合规划，节点内互连符合硬件设计。
• GPU-NIC的PCIe/NUMA亲和性、交换机端口与Rail映射已核对。
• CUDA、NCCL、MPI、网络插件和nccl-tests提交号已归档。
• [ ]测试程序启用所需MPI支持，远端路径与动态库可用。

链路与正确性

• RDMA端口状态、速率及对应网络配置符合设计。
• RoCE地址与GID选择经过确认，没有遗留的不适用配置。
• [ ]各rank使用预期GPU，NCCL选择的HCA与传输路径可解释。
• [ ]正确性检查已执行并通过，没有未解决的通信错误、挂起或异常重试。

性能与扩展

• [ ]单机与双机测试覆盖所需消息范围，达到对应基线。
• [ ]各规模采用可比的参数与进程布局，结果具备重复性。
• [ ]多节点、跨机架及不同节点组合均已覆盖。
• [ ]基线偏差、性能拐点和异常节点已记录、处理并复测。

训练与交付

• [ ]训练实际使用的主要Collective、数据类型与消息区间已覆盖。
• [ ]真实训练达到约定吞吐，数据、计算、存储和Overlap已纳入分析。
• [ ]环境、完整命令、原始结果、日志与验收结论能够相互追溯。
• [ ]诊断阶段的临时参数已复核，最终基线对应实际交付配置。

一份有效的验收报告，应能够说明“在什么环境、用哪些节点、执行什么配置、得到什么结果、与哪个基线比较”。这样，后续更换驱动、调整网络或扩容集群时，才能判断性能变化发生在哪里。

结语

NCCL-tests的价值，在于把复杂训练系统中的通信问题拆成可重复验证的步骤：先确认节点内部，再确认跨节点路径，最后检查规模扩展。

当吞吐不达预期时，先找到异常首次出现的边界，再用日志与对照测试缩小范围。建立并持续维护这套基线，才能让集群上线验收和后续性能回归都有据可依。

参考资料

以下为本文核对所用的官方资料，访问日期为2026-09-18。在线文档会更新，复现实验时应匹配实际安装版本。

1. NVIDIA nccl-tests：构建、参数与使用方式
2. NVIDIA nccl-tests：性能指标定义
3. NVIDIA NCCL：环境变量参考
4. NVIDIA NCCL：网络故障排查
5. NVIDIA NCCL 2.24.3：GPUDirect、拓扑与运行环境排障说明
6. NVIDIA nvbandwidth
7. NVIDIA CUDA Samples：版本变更记录
8. Open MPI 5.0：mpirun / mpiexec手册