8 卡服务器带宽验收：nvbandwidth 与 nccl-tests 怎么测
验收 8 卡机时，只跑算力测试是不够的。算力正常但 NVLink 或 PCIe 链路降速的机器，单卡基准分数看不出来，一上多卡训练就掉到地板。所以带宽必须单独测，而且要分清测的是哪种带宽。
一、nvbandwidth：点对点拷贝带宽
编译很直接，依赖 CUDA Toolkit 11 以上、C++17 编译器、CMake 3.20 以上：
cmake . make
先列测试项再决定跑哪些，不要一上来就跑全量（全量耗时长且输出难读）：
./nvbandwidth -l ./nvbandwidth -t device_to_device_memcpy_read_sm ./nvbandwidth -p device_to_device
关键参数（均以官方 README 为准）：
-b, --bufferSize：拷贝缓冲大小，单位 MiB，默认 512。README 明确写了小缓冲会低估实际可达带宽，所以测峰值不要改小；只有快速验证两卡连通性时才用-b 1。-i, --testSamples：迭代次数，默认 3，报告取中位数；加-m改用算术平均。-F json：输出 JSON，便于归档和横向比对，比截屏 text 输出可靠。--pair UUID1 UUID2：只测指定一对卡。UUID 用nvidia-smi -L取，形如GPU-xxxxxxxx-...，GPU-前缀不能省。
拷贝方式分两类：CE（Copy Engine，走 memcpy API）和 SM（Streaming Multiprocessor，走 kernel）。同一对卡，SM 和 CE 测出的数不一样，验收文档里必须写清用的是哪一个，否则两组数据没法比。
二、口径陷阱：双向带宽不是两方向之和
这是最容易在验收报告里写错的一条。官方 README 原文：双向测试报出的 GB/s 表示并发反向拷贝条件下的每方向带宽，不是两方向的汇总值（per-direction bandwidth under concurrent opposite-direction copy, not an aggregated sum）。
换句话说，双向测试拿到 300 GB/s，不等于这条链路总吞吐 300 GB/s——它是每个方向 300 GB/s。如果按「加起来」去写门槛，数字会翻倍，判据就全错了。同理，单向测试是矩阵里每对单独测，流量不是同时发的。
三、nccl-tests：集合通信带宽
点对点通了不代表集合通信正常，AllReduce 还要过一遍交换机拓扑。编译需带 MPI：
make MPI=1 MPI_HOME=/usr/local/mpi CUDA_HOME=/usr/local/cuda ./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8
参数含义：-b 起始字节数、-e 最大字节数、-f 翻倍因子（2 表示 8、16、32…逐级翻倍）、-g 每进程 GPU 数。输出里有两列必须分清：algbw 是算法带宽（按数据量除时间），busbw 是总线带宽（按算法带宽乘换算系数）。判断互联能力看 busbw，拿 algbw 去比硬件标称带宽会得出「只跑了一半」的错误结论。
四、现场易踩的坑
- 没开持久模式（
nvidia-smi -pm 1）时，每次调用都有初始化和驱动加载开销，短测试受影响明显。 - CPU 绑核没做对（NUMA 跨节点）会把 host-to-device 带宽压低，看起来像卡有问题。
- 多卡测试期间不能有其他进程占用 GPU，否则数值波动大且不可复现。
口径提示：本文命令与参数全部取自 nvbandwidth 与 nccl-tests 官方 README。具体通过门槛（例如某机型 P2P 应达到多少 GB/s）取决于机型、拓扑和链路类型，属各项目自定基线，本文不给出通用数值，避免被误用为行业标准。
