1. 先把话说清楚：NCCL 带宽测试到底在测什么
跑到一半突然卡住、GPU 利用率从 95% 掉到 30%、日志里 all-reduce 耗时忽高忽低——这些症状里有一大半最后都会指向同一个源头：卡间或机间的通信带宽没有达到预期。这时候你需要的第一件工具不是 profiler，也不是盯着 loss 曲线发呆，而是一次干净利落的 NCCL 带宽测试。它能在十分钟内告诉你：这套机器、这个网络、这版库，从 A 卡把数据搬到 B 卡到底能跑多快，以及和理论上限差了多少。
NCCL 是 GPU 集群里做集合通信的事实标准库，all-reduce、all-gather、broadcast、reduce-scatter 这些分布式训练绕不开的操作都由它实现。它要解决的问题很具体：在给定拓扑（同一块板卡内的 NVLink、跨 CPU 的 PCIe 通道、跨机器的高速网络）下，把多张卡的数据聚合起来，同时在带宽和延迟之间找到最优的走法。nccl-tests 则是配套的一组微基准程序，把 NCCL 的通信能力单独拎出来压测，剥离掉计算、数据加载、优化器更新这些干扰因素。
这套东西适合谁？三类人最该掌握：一是刚接手一批训练机器、需要做上线验收的工程师；二是排查训练变慢、怀疑通信瓶颈的算法或框架同学；三是负责集群选型、想在采购前对比不同互联方案的实际运维人员。哪怕你只是单机八卡做实验，跑一遍 all_reduce_perf 也能立刻知道自己的机器是"真八卡"还是"共享 PCIe 的假八卡"——这两者的训练效率差距可以是三四倍。
我见过太多团队在训练出问题后才第一次打开 nccl-tests，结果发现测试环境本身就搭错了，跑出来的数字既不能复现也不能解释。所以这篇内容不打算只给你几条命令，而是把参数含义、结果解读、常见故障和调优经验一次讲透，照着做就能得到可信的数字。
2. 测试环境准备：驱动、库和编译三件套的版本对齐
2.1 版本不匹配是最高频的翻车点
分布式通信测试里最让人抓狂的一类问题，是程序能编译、能启动，跑到一半报个语焉不详的 internal error。绝大多数情况源于四处版本没有对齐：GPU 驱动、CUDA 运行时、NCCL 库本身、以及编译 nccl-tests 时链接的那份 NCCL。这四个东西只要有一个版本跨度太大，轻则性能打折，重则直接崩。
操作上的原则很简单：nccl-tests 必须链接你实际训练时用的那份 NCCL。很多环境里系统自带一份 NCCL（装在/usr/lib/x86_64-linux-gnu/），conda 环境里又有一份，自己编译的框架还带一份。你可以用下面这条命令确认当前动态库到底加载的是哪个文件：
ldd ./build/all_reduce_perf | grep nccl python -c "import torch; print(torch.__version__, torch.version.cuda)"如果输出的路径不是你预期的那个，那后面的所有数字都不可信。想强制指定就用LD_LIBRARY_PATH前置，而不是依赖系统默认搜索顺序。
注意：不要在测试机上随手
apt upgrade升级 NCCL 包。库版本变了但驱动没跟上，或者反过来，都会出现"能跑但带宽对不上"这种最难查的软故障。
2.2 编译 nccl-tests：一条命令和它背后的取舍
拉源码、编译，标准流程如下：
git clone https://github.com/NVIDIA/nccl-tests.git cd nccl-tests make MPI=1 \ MPI_HOME=/usr/local/mpi \ CUDA_HOME=/usr/local/cuda \ NCCL_HOME=/usr/local/nccl \ -j 16这几个变量的作用值得说清楚，因为很多人直接make就完事，结果后面多机测试跑不起来。
MPI=1决定是否编译多进程版本。不开这个开关，生成的二进制只能单进程运行，多机测试根本无从谈起。MPI_HOME指向 MPI 实现（常见的是 OpenMPI 或 MPICH）的安装前缀，编译时会去${MPI_HOME}/include找头文件、去${MPI_HOME}/lib找库。如果你的 MPI 是通过系统包管理器装的，路径可能是/usr/lib/x86_64-linux-gnu/openmpi，用mpicc --showme:incdirs能直接问出来。
CUDA_HOME和NCCL_HOME分别指向 CUDA Toolkit 和 NCCL 的前缀目录。如果你用的是自己编译的 NCCL，NCCL_HOME就是你make install时指定的PREFIX；如果用系统包，可以省掉这个变量，让编译器从默认路径找。
编译完成后build/目录下会出现一批二进制，常用的有：
| 二进制 | 测什么 | 典型用途 |
|---|---|---|
all_reduce_perf | 全规约 | 训练里梯度同步的主路径，最常用 |
all_gather_perf | 全收集 | 张量并行、参数分片场景 |
reduce_scatter_perf | 规约散射 | ZeRO 类优化器的通信形态 |
broadcast_perf | 广播 | 参数初始化、权重下发 |
sendrecv_perf | 点对点 | 流水线并行的相邻阶段传输 |
alltoall_perf | 全交换 | 专家并行（MoE）场景 |
一次完整的验收，我建议至少跑 all_reduce、all_gather、reduce_scatter 三个，因为它们在真实训练中的流量占比最高，而且对拓扑的敏感程度不一样。
2.3 编译通过不等于能跑：先做一次冒烟测试
编译成功后别急着上长消息压测，先跑一条最小命令确认链路是通的：
./build/all_reduce_perf -b 8 -e 8M -f 2 -g 8 -c 1 -n 20 -w 5这条命令让 8 张卡做一次从 8 字节到 8 MB 的 all-reduce 扫描，每个尺寸迭代 20 次、预热 5 次，并且开校验。能顺利跑完并打印出Avg bus bandwidth一行，说明 GPU 可见性、P2P 通路、NCCL 初始化都正常。如果这一步就报错，后面的参数调优全是白费功夫，先解决初始化问题。
提示：冒烟测试阶段建议加上
NCCL_DEBUG=WARN（或排查问题时用INFO）。默认日志级别几乎不输出任何信息，出问题时你连它选了什么算法、走了哪条链路都不知道。
3. 核心参数体系拆解：一条命令里每个字母都是什么意思
3.1 消息尺寸三兄弟：-b、-e、-f
-b是起始字节数，-e是结束字节数，-f是步进倍数。三者组合决定了测试扫描的消息尺寸序列。比如-b 8 -e 128M -f 2会依次测试 8B、16B、32B……一直到 128MB。
为什么一定要扫描而不是测单一尺寸？因为集合通信的性能曲线是分段的。小消息（几 KB 以内）主要由延迟决定，带宽利用率普遍很低，这时候比较的是"每次操作花多少微秒"；中等消息（几十 KB 到几 MB）是延迟和带宽的混合区；大消息（几十 MB 以上）才真正跑满带宽。如果你的训练是百亿参数模型、梯度桶几十 MB，那只关心大消息的数值就行；如果是小模型、频繁 all-reduce，那小消息延迟反而是关键。
步进倍数选 2 是通用做法，能把 8B 到 8GB 压缩到三十来个采样点。测试时间紧可以选 4，但会在中小尺寸区间丢掉细节。
3.2 迭代与预热：-n、-w、-c 的真实作用
-w是预热次数，-n是正式迭代次数，-c是是否开启结果校验（1 开 0 关）。
预热这件事特别容易被忽略，但影响很大。第一次通信往往包含建链、内存注册、算法选择等一次性开销，耗时可能是稳态的十倍以上。不预热直接取平均，小消息的数值会被严重污染。我的习惯是-w 20 -n 100：预热足够多，统计样本也够，跑一遍八卡 all_reduce 大概两三分钟，属于可接受范围。
-c 1开启校验时，程序会在通信后检查结果正确性，同时会因为额外的结果比对拖慢一点点速度。做基线记录时建议开校验，确认这条路真的算对了而不只是跑得快；做极限性能压测时可以关掉，但前提是你已经确认过正确性。
3.3 进程与设备映射：-g 和 -p
-g指定每个进程用几张 GPU。单机测试时-g 8表示一个进程管理八卡；多机测试时必须设成-g 1，让每个进程绑一张卡，由 MPI 负责进程分发。
-p是打印级别，-p 1会输出每个尺寸、每次迭代的明细，适合定位偶发的性能抖动。平时用默认值就够了，输出太多反而看不清趋势。
这里有个坑要提醒：-g的值并不决定用哪几张卡，真正决定的是CUDA_VISIBLE_DEVICES。如果环境变量里只放了0,1，那-g 8会直接报错退出。多机测试时更要注意每台机器的环境变量是否一致，否则会出现"部分进程找不到对应数量的设备"这类启动失败。
3.4 一个容易被忽略的参数：-R
-R控制是否把结果循环重复多轮。看起来可有可无，但在排查"性能随时间波动"这类问题时非常有用——单轮测试可能恰好赶上一个安静窗口，多轮重复才看得出稳定性。定验收标准时用-R 3跑三轮，三轮之间的离散度比绝对值更能说明机器的健康程度。
把上面这些拼起来，一条配置合理的完整命令是：
NCCL_DEBUG=WARN ./build/all_reduce_perf \ -b 8 -e 8G -f 2 \ -g 8 \ -c 1 \ -n 100 -w 20从 8 字节扫到 8 GB，覆盖了几乎所有真实场景的消息尺寸区间，八卡全用，开校验，预热和迭代次数都足够。
4. 单机多卡实操：从跑通到跑准
4.1 先看清楚你的机器到底是什么拓扑
在跑任何命令之前，先执行这一条：
nvidia-smi topo -m它会打印一张 GPU 之间的连接矩阵，每个格子标着NV#（NVLink 第几代）、PIX（同一 PCIe 交换芯片）、PXB（跨 PCIe 交换芯片）、PHB（跨 CPU 的 PCIe host bridge）、SYS（跨 NUMA 节点）或NODE。这张表是后面所有带宽解读的坐标系。
简单判断方法：如果所有矩阵格子都是NV#，那是全互联的 NVLink 机型，带宽会非常高；如果出现大量SYS，说明卡分布在两个 CPU 插槽下，跨插槽通信要绕远路，性能会明显掉一档；如果整张表都是PHB且没有 NVLink，那就是纯 PCIe 机型，八卡共享上行带宽，跑出来的数字不要期待太高。
我踩过的一次坑：某台机器 BIOS 里把 PCIe 速率从 Gen4 降到了 Gen3 做兼容，nvidia-smi topo -m依然显示PIX，看不出任何异常，但实测带宽刚好只有预期的一半。后来用nvidia-smi -q | grep -A2 "GPU Link Info"才确认链路速率被降级了。拓扑图只告诉你"怎么连"，不告诉你"连得多快"，这两个要分开验证。
4.2 基线命令与结果读取
假设八卡机器，跑下面这条：
./build/all_reduce_perf -b 8 -e 8G -f 2 -g 8 -c 1 -n 100 -w 20输出是一张表，每行一个消息尺寸，列有time（平均耗时）、algbw（算法带宽）、busbw（总线带宽）。八卡 all-reduce 用的是 ring 算法，两者的换算关系是：
busbw = algbw × 2 × (n - 1) / nn是参与通信的 GPU 数。八卡代入就是2 × 7 / 8 = 1.75。也就是说如果algbw显示 200 GB/s，busbw就是 350 GB/s。
为什么要看busbw而不是algbw？因为algbw的定义是"消息长度 / 耗时"，它把整个通信任务当成一次搬运；而 ring 算法实际上每个卡既发送又接收、数据在环上转了两圈（一圈 reduce-scatter，一圈 all-gather），物理链路上真实流动的流量是算法层数据量的 1.75 倍。只有busbw才能和硬件规格书上的链路带宽做直接对比，也只有它能跨不同卡数、不同集合操作横向比较。
所以看结果的核心动作是：把busbw的峰值和下面这张参考表对一下。
| 互联方式 | 单卡单向理论带宽 | 实测 busbw 合理区间 |
|---|---|---|
| PCIe Gen4 x16 | 约 32 GB/s | 20 - 26 GB/s |
| PCIe Gen5 x16 | 约 64 GB/s | 45 - 55 GB/s |
| NVLink 上一代（每卡 6 链路） | 约 150 GB/s 双向 | 110 - 140 GB/s |
| NVLink 新一代（每卡 18 链路） | 约 450 GB/s 双向 | 280 - 400 GB/s |
| 单端口 200Gb/s 高速网络 | 约 25 GB/s | 20 - 23 GB/s |
| 单端口 400Gb/s 高速网络 | 约 50 GB/s | 40 - 46 GB/s |
这张表给的是量级，不是标准答案。机型、BIOS 设置、GPU 代数、驱动版本都会让数值上下浮动 15% 左右。真正有价值的是同一批机器之间的横向对比：如果十台同型号机器里有三台明显低于其他七台的均值，那三台一定有问题，绝对数值是多少反而次要。
4.3 不同尺寸段的性能特征
把整条曲线拉出来看，你会发现三个明显的区间。
8 字节到 4 KB：busbw极低，可能只有几百 MB/s。这段是纯延迟主导，每次通信的总耗时基本固定（几十微秒），数据量再小也省不掉建链、同步、内核启动的固定开销。这个区间的数值主要反映 NCCL 的启动开销和核函数效率，调优空间不大，除非你把通信和计算重叠起来隐藏掉。
8 KB 到 1 MB：曲线快速爬升，是性能最不稳定的区域。不同算法（Ring 和 Tree）在这个区间的交叉点附近会有明显的性能断层。如果发现某段尺寸的数值突然掉下去再升上来，很可能是 NCCL 自动选算法时切到了一个不合适的策略。
4 MB 以上：曲线趋于平台，这才是真正的带宽饱和区。所有大消息的busbw应该稳定在同一个水平线上。如果大尺寸反而掉速，基本可以确定是网卡或链路层面的问题，不是 NCCL 调参能救的。
心得：不同尺寸的收益递减点，通常对应训练里梯度桶的最优大小。如果你的梯度融合桶配成了 1 MB，但实测显示 8 MB 之后才进入带宽平台期，那把桶放大到 8 MB 左右能省下可观的同步开销。
4.4 换几种卡数跑，看扩展性
固定消息尺寸，改变 GPU 数量，是另一个维度的观察。八卡跑出来的busbw应该和四卡跑出来的接近，因为 ring 算法的总线流量已经被归一化了。如果八卡的busbw明显低于四卡，说明拓扑上有跨 NUMA 或跨交换芯片的瓶颈，卡越多越吃亏。
用-g 2、-g 4、-g 8各跑一遍，把 8 MB 和 128 MB 两个点的busbw列成表，扩展性问题一眼就能看出来。
5. 多机测试：MPI 启动、网卡绑定与端口配置
5.1 启动骨架与 hostfile
多机测试靠 MPI 分发进程，每台机器起若干进程，每个进程绑一张卡。先准备一个hostfile：
node-01 slots=8 node-02 slots=8 node-03 slots=8 node-04 slots=8每行一个主机名和该机可用的进程槽位数，通常等于 GPU 数。启动命令：
mpirun -np 32 \ --hostfile hostfile \ --allow-run-as-root \ -x NCCL_DEBUG=INFO \ -x NCCL_SOCKET_IFNAME=eth0 \ -x NCCL_IB_HCA=mlx5_0 \ -x LD_LIBRARY_PATH \ ./build/all_reduce_perf -b 8 -e 8G -f 2 -g 1 -c 1 -n 100 -w 20-np 32是总进程数，等于四机乘八卡。-x把环境变量透传给远端进程，这一步非常关键——MPI 默认只在自己进程里设置环境变量，不回传给远端，很多人在这里栽跟头，远端进程拿不到NCCL_SOCKET_IFNAME就会选错网卡，带宽直接砍半。-g 1让每个进程只绑一张卡，靠CUDA_VISIBLE_DEVICES不同的取值让各进程落到不同的 GPU 上。
--allow-run-as-root只在容器内以 root 运行时需要，物理机上用普通账号跑更安全，也免得 MPI 直接拒绝启动。
5.2 网卡选择：SOCKET_IFNAME 和 IB_HCA
NCCL_SOCKET_IFNAME指定做控制面和 bootstrap 通信的网卡名。名称可以从ip addr或ifconfig里查，写eth0或=eth0都行，前缀=表示精确匹配。如果机器上有 docker0、虚拟网桥、业务网口等多个接口，不指定这个变量，NCCL 可能挑中一个不通的接口，表现为启动阶段长时间卡住然后报连接超时。
NCCL_IB_HCA指定用哪块高速网络设备（RDMA 设备，名称形如mlx5_0、mlx5_1）。这个变量有两种写法：-x NCCL_IB_HCA=mlx5_0表示只用这一块；-x NCCL_IB_HCA=^mlx5_1表示排除这一块、其余全用。多网卡机器上要特别注意，某些型号的网卡会同时暴露多个设备名但只有部分是数据端口，选错会直接降级到 TCP 回退。
判断有没有走成高速网络，最简单的方法是看 INFO 日志里有没有NET/IB或NET/IBext字样。如果通篇都是NET/Socket，那你测的其实是 TCP，带宽和延迟都会差一个数量级。
5.3 值得提前设定的几个环境变量
除了网卡，还有几个变量在多机场景下建议显式指定，避免 NCCL 自己猜错：
export NCCL_IB_GID_INDEX=3 export NCCL_IB_SL=0 export NCCL_NET_GDR_LEVEL=2 export NCCL_NSOCKS_PERTHREAD=4 export NCCL_SOCKET_NTHREADS=2NCCL_IB_GID_INDEX决定用什么类型的地址做握手，不同网络环境下的默认值不一样，选错的表现是连接能被发起但建立不起来，日志里出现IBV_WC_REM_ACCESS_ERR或超时重试。这个值通常需要配合网络管理方给的配置来定，不是随便填一个整数就行。
NCCL_NET_GDR_LEVEL控制是否启用 GPU 显存直通（GPU Direct RDMA），让数据从网卡直接进显存而不绕经主机内存。设成2以上通常表示允许跨 NUMA 也直通。开启后跨机带宽能提升 10% 到 20%，但要求驱动和固件都支持，不支持的机器上设了也不生效，只在日志里报一条提示。
NCCL_NSOCKS_PERTHREAD和NCCL_SOCKET_NTHREADS影响 TCP 控制通道的并发度。多机连接数量大的时候（比如 32 个进程以上），提高这两个值能减少建链阶段的串行等待，缩短启动时间。它们的代价是占用更多 CPU 核心，机器核数紧张的时候要权衡。
5.4 跨机带宽的预期管理
跨机测试最常见的困惑是：单机内有 NVLink 跑出 300 GB/s 以上，跨机一测只有 20 GB/s，以为是哪里配错了。其实对比参照物错了——跨机走的是网络端口，每台机器每张网卡就那么大带宽，和机内的 NVLink 完全不是一个数量级。
正确的参照方式是：把跨机 busbw 和单端口网络的理论带宽对比。200Gb/s 的端口理论峰值约 25 GB/s，实测 20 到 23 GB/s 就是健康值。如果你有四块这样的网卡做聚合，理论上限能到 100 GB/s 左右，那实测跑到 80 到 90 GB/s 就算优秀。
另一个常见误区是拿跨机 all-reduce 的 busbw 和单端口带宽直接比。四机 32 卡做 all-reduce，ring 环会跨机转好几圈，同一个消息实际上要多次经过网络，所以 busbw 有可能超过单端口带宽的 2 到 3 倍——这不是"突破了物理极限"，只是归一化口径不同。看跨机性能，更靠谱的做法是看实际吞吐：一次 1 GB 的 all-reduce 花了多少秒，反推每秒搬了多少真实数据。
6. 常见问题与排查技巧实录
6.1 快速对照表
| 现象 | 可能的根因 | 排查动作 |
|---|---|---|
启动即报no CUDA-capable device | CUDA_VISIBLE_DEVICES未设置或数量不足 | 检查环境变量与-g是否匹配 |
日志全是NET/Socket | 高速网络未被识别 | 检查NCCL_IB_HCA、驱动、设备状态 |
| 启动阶段长时间挂起无输出 | 网卡选择错误、端口不通 | 用NCCL_SOCKET_IFNAME精确指定，逐机 ping 验证 |
| 小消息正常、大消息掉速 | 链路降级、显存带宽瓶颈 | 检查 PCIe 速率、网络误码计数 |
| 卡数少于预期 | MPI 槽位配置、设备数量不一致 | 核对 hostfile 与各机 GPU 数 |
| 性能随机波动大 | 有别的进程抢占、温度降频 | 查 GPU 利用率与时钟频率 |
| 多机不同进程数值差异大 | 单台机器异常、链路质量不一致 | 逐机单跑对比定位 |
6.2 "卡数不对"的三种成因
现象是-g 8却只用了 4 张卡，或者进程数少于-np指定值。第一种原因是CUDA_VISIBLE_DEVICES里确实只暴露了 4 个设备，容器启动时--gpus参数写少了，或者NVIDIA_VISIBLE_DEVICES设了子集。第二种是 hostfile 里slots数量写小了，MPI 认为这台机器只能放这么多进程，超出的被挤掉。第三种是各机器 GPU 数确实不一样，四台机器里有一台只装了四张卡，-np 32就凑不齐。
排查顺序建议从内向外：先在单机跑-g 1确认单卡能通，再逐渐加到-g 8确认单机能满，最后才上多机。跳过前两步直接多机，出问题时无法区分是单机环境问题还是多机协同问题。
6.3 带宽只有理论值三分之一时的思考路径
这是最常见也最值得花时间的一类问题。我的排查顺序是固定四步，按成本从低到高排：
第一步看日志里的算法选择。NCCL_DEBUG=INFO会打印实际用的算法（Ring 或 Tree）和协议（LL、LL128、Simple）。小消息用 LL 或 LL128 是对的，如果大消息也被选成了 LL，那带宽必然上不去。可以用NCCL_ALGO=Ring、NCCL_PROTO=Simple强制试一次，对比数值差异。如果强制之后大幅提升，说明自动选择在你的拓扑上判断失误了。
第二步看链路速率。用nvidia-smi -q查 GPU 和 PCIe 的当前链路速率与宽度，确认没有降级。Gen4 x16 降成 x8 就是一半带宽，而且topo -m从上面完全看不出来。
第三步做二卡对比。用-g 2跑一遍，如果两卡都能跑满而八卡不行，问题在拓扑或交换机；如果两卡就跑不满，问题在单卡链路或驱动，范围立刻缩小一半。
第四步隔绝干扰。停掉机器上其他吃 GPU 或吃 PCIe 的进程，包括监控采集、其他容器、图形界面服务。我遇到过一台机器上有个残留的推理服务占着半张卡的显存，虽然它不跑计算，但显存带宽和链路共享还是拖累了通信测试，数值一直偏低 15%，查了两天才发现。
6.4 多机测试卡在建链阶段
表现是mpirun启动后长时间没有任何输出，几分钟后批量报超时。先确认三件事：各机器之间网络互通（用不带任何特殊工具的普通连通性检查即可）、防火墙没有拦截测试端口、NCCL_SOCKET_IFNAME指定的接口在每台机器上都存在且名称一致。
名字不一致是隐蔽性很高的一种。比如有的机器网卡叫eth0，有的叫ens1f0，你用同一个变量值传给所有机器，部分机器的进程就会找不到接口，回退到默认选择，然后和其他机器选到不同网段，握手失败。
另外，MPI 本身也有自己的网络选择逻辑，和 NCCL 是两套独立配置。MPI 通了不代表 NCCL 通，NCCL 的日志和 MPI 的日志要分开看，别指望从 MPI 的报错里找到 NCCL 的问题。
6.5 结果校验失败怎么办
开了-c 1之后报出数据不匹配，这比性能问题严重得多，说明通信结果本身错了。常见原因有两个：一是用了-g大于 1 且没有正确绑定设备，多个进程抢同一张卡导致数据覆盖；二是混合了不同版本的 NCCL 库，部分进程加载了旧版本，协议实现不一致。
排查方法是在命令里加上NCCL_DEBUG_SUBSYS=INIT,COLL，把初始化过程和多播组信息打出来，逐进程核对设备号、库版本、通信域成员是否对得上。这类问题不会自愈，必须解决后再谈性能。
7. 调优与压测经验：怎么把数字榨到接近上限
7.1 环境变量调优的正确姿势
调优有个基本原则：一次只改一个变量，改完立刻复测，记录前后数值。NCCL 的环境变量有几十个，互相之间还有耦合，同时改五个然后看结果，等于没做实验。
下面这几个是收益相对明确的：
| 变量 | 作用 | 建议尝试值 |
|---|---|---|
NCCL_ALGO | 强制算法选择 | Ring / Tree |
NCCL_PROTO | 强制协议 | Simple / LL128 |
NCCL_NET_GDR_LEVEL | 显存直通层级 | 2 或 3 |
NCCL_NSOCKS_PERTHREAD | 每线程 socket 数 | 4 或 8 |
NCCL_BUFFSIZE | 通信缓冲区大小 | 默认 4 MB，大消息可试 8 MB |
NCCL_P2P_LEVEL | 点对点通路层级 | 按拓扑调整，慎用 |
NCCL_BUFFSIZE值得一提。它控制每次通信用的临时缓冲区大小，太小会导致频繁的分片和流水线切换，太大又会挤占显存并影响缓存命中。默认值在多数场景下是合理的，只有在明确观察到"大消息处理呈现明显分段"时才值得往上调。
NCCL_P2P_LEVEL更要谨慎。把它调高（比如强制走 NVLink 或 PCIe P2P）在某些拓扑上能提升性能，但如果硬件实际不支持而你又强制指定，会直接跑到一个不可用的路径上导致失败。改这个变量之前，用nvidia-smi topo -m和 P2P 能力查询确认硬件支持。
7.2 算法与协议的匹配关系
Ring 和 Tree 的差别在于：Ring 把所有卡串成一个环，数据沿着环逐跳传递，随着卡数增加，跳数也增加，延迟会线性上升，但实现简单稳定，大消息时带宽利用率高；Tree 是分层的树形结构，能把跳数压到对数级，适合卡数多、消息中等的场景，但实现更复杂，在小消息上未必更快。
NCCL 默认会按消息尺寸和卡数自动选，多数情况下选得不错。手动干预的场景通常是：你发现某个尺寸段性能异常，怀疑自动选择失误；或者你的拓扑非常规（比如不对称的连接），自动判断不出来。
协议层面，Simple适合大消息、追求峰值带宽；LL和LL128通过减少同步开销来降低小消息延迟，但牺牲了一部分带宽效率。这三个的选择逻辑是"消息越小越倾向于低延迟协议"，方向是对的，不用刻意去反着来。
7.3 测试环境和生产环境的差距
这里要说个实在话：nccl-tests 测出来的是理想条件下的上限，生产环境里跑不到这个数是正常的。差距主要来自几处。
测试是纯通信，没有并发的计算核在抢显存带宽和 SM 资源；真实训练里通信和计算交织，实际可用的通信带宽会被压缩。测试是同构的消息尺寸，真实训练的梯度桶大小各不相同，NCCL 要在不同算法间切换，切换本身有开销。测试没有其他进程干扰，生产环境里数据加载、日志、监控都在占资源。
所以验收标准不要定成"必须达到测试值的 90%"，更合理的做法是建立一个本环境的基线：同一批机器，统一配置，跑一次测试记录数值，后续所有机器的验收都以这个基线为准，偏离超过 10% 就排查。这样既能发现问题，又不会被不同环境的绝对数值差异误导。
7.4 让带宽测试成为常态化监控
最后分享一个已经在用的做法：把带宽测试脚本放进定期的健康检查里，每天夜里跑一次短版本（-b 8M -e 1G，只测大消息段），结果写入时序库。这套东西的价值不在于单次数值，而在于趋势——某台机器的 busbw 在一周内从 280 GB/s 缓慢滑到 240 GB/s，通常意味着散热、链路误码或者对端设备出了问题，这种渐变只靠人工抽查是发现不了的。
短版本跑一次大约 30 秒，四机规模也不过两分钟，成本完全可以接受。跑的时候注意错开训练的繁忙时段，否则既是测试干扰训练，训练也在干扰测试，两边数据都不干净。
我个人在实际操作中体会最深的一点是：这套工具真正难的地方不在于命令怎么敲，而在于结果出来之后敢不敢下判断。看到一个低于预期的数字，第一反应往往是"可能是正常的吧"，于是放过去了。我的建议是把每次测试的结果和当时的环境信息（驱动版本、拓扑、GPU 时钟）一起记下来，积累十几台机器的数据之后，你自然就知道哪些数字该被质疑、哪些属于正常抖动，判断力是靠对比喂出来的，不是靠查文档。
