多GPU服务器交付验收：GPU健康、P2P、NCCL与稳定性测试思路

高端GPU服务器的验收不能只停留在 nvidia-smi。

对于4卡、8卡等多GPU平台，比较完整的验证链路通常是：

配置与环境 → GPU健康与压力 → PCIe/NUMA拓扑 → P2P → NCCL → 多节点网络（如适用） → 代表性工作负载。

本文不针对某一款GPU给出统一"合格分数"，而是梳理一套可复用的工程测试思路。

1. 基础状态：先确认设备和环境

最基础的GPU状态检查：

nvidia-smi

重点确认：

• GPU数量和型号；
• 显存容量；
• Driver状态；
• GPU温度、功耗和运行状态；
• 是否存在明显异常。

但这一层只能说明"系统已经识别到GPU"，不能证明高负载稳定性、多GPU数据路径和集合通信都正常。

同时还应核对：

• CPU、内存、存储、网卡；
• PCIe设备识别；
• Driver、CUDA等基础环境；
• BIOS/BMC/固件版本。

2. GPU健康与压力：重点看持续负载

压力测试不是为了追求某一个峰值，而是为了把潜在问题暴露出来。

建议关注：

• 温度、功耗、频率；
• 多GPU之间的性能一致性；
• ECC状态（对于支持ECC的GPU）；
• Xid事件；
• 掉卡、重置、异常降频。

NVIDIA平台可根据具体GPU类别和软件环境考虑DCGM Diagnostics。例如：

dcgmi diag --run 1

这是快速部署/基础检查。

在产品和平台支持相应测试的情况下，还可以进一步运行PCIe、memory、diagnostic等项目，例如：

dcgmi diag --run pcie,diagnostic --entity-id gpu:0,gpu:1

需要注意：DCGM不同级别和插件对GPU类别、平台和软件条件有不同要求，不能假设所有GPU都支持同一组测试。

3. 多GPU拓扑：先看"怎么连"，再看"跑得怎么样"

查看GPU拓扑：

nvidia-smi topo -m

这一步可以帮助判断：

• GPU与GPU之间的连接层级；
• GPU与CPU NUMA的关系；
• GPU与NIC的位置关系。

对于PCIe多GPU平台，还可以根据实际环境检查GPU之间的P2P能力：

nvidia-smi topo -p2p p

NVIDIA的NCCL故障排查文档也明确指出，GPU-to-GPU P2P会受PCIe拓扑、驱动、BIOS/IOMMU等因素影响。

需要注意：

P2P状态正常，不等于整台服务器的多GPU通信已经验证完成。

它解决的是"GPU之间能不能直接访问"的一部分问题。

4. P2P与带宽测试：不要直接拿理论峰值判定

如果需要继续验证GPU之间的实际数据路径，可以使用适合当前平台的带宽测试工具。

对于NVIDIA平台，官方NCCL故障排查资料推荐使用 nvbandwidth 等工具检查可用GPU带宽路径。

这里更重要的是测试方法一致：

• 相同GPU型号；
• 相同服务器拓扑；
• 相同Driver/CUDA版本；
• 相同测试参数；
• GPU处于相近空闲状态。

这样才能建立可复用的参考基线。

不要把GPU公开规格里的理论互联带宽，直接等同于某一次P2P或集合通信测试必须达到的结果。

5. NCCL：验证多GPU集合通信

NCCL Tests可以同时验证NCCL操作的正确性和性能。

单节点多GPU的典型AllReduce测试形式，例如：

./build/all_reduce_perf -b 8 -e 128M -f 2 -g 8

实际GPU数量和消息范围应根据服务器配置调整。

NCCL Tests会输出包括：

• time；
• algorithm bandwidth（algbw）；
• bus bandwidth（busbw）；
• correctness相关结果。

这里要特别区分 algbw 和 busbw。

NCCL Tests官方文档中，algbw按数据量/时间计算；busbw则根据不同集合通信操作进行换算，用于更接近硬件通信瓶颈的比较。

因此验收时更建议看：

1. 测试能否稳定完成；
2. 不同消息大小下结果是否连续、合理；
3. 是否有正确性错误；
4. 多卡结果是否存在明显离群；
5. 与同机型基线相比是否异常。

不要简单设定一个"所有8卡服务器都必须达到X GB/s"的标准。

6. 多节点才增加RDMA和跨节点NCCL

单节点服务器没有必要把RDMA作为通用必测项。

进入InfiniBand或RoCE多节点集群后，才需要继续验证：

• HCA/网卡状态；
• RDMA带宽；
• RDMA时延；
• 端口和链路健康；
• GPU到NIC的数据路径；
• 跨节点NCCL。

NVIDIA NCCL网络故障排查文档给出的典型带宽测试工具是 ib_write_bw：

# server
ib_write_bw -d <device> -a

# client
ib_write_bw -d <device> <server_hostname_or_ip> -a

如果要验证GPUDirect RDMA，不能只看普通Host Memory RDMA结果。平台和 perftest 构建支持的情况下，可以继续比较GPU Memory路径，例如：

ib_write_bw -d mlx5_0 --use_cuda=<gpu_id> <server_hostname_or_ip> -a

具体参数应以当前 perftest 版本的 ib_write_bw --help 为准。

7. 最后一层：代表性工作负载

硬件和通信测试结束后，如果项目条件允许，建议再跑一次代表性业务。

大模型场景可以确认：

• 模型加载；
• 多GPU调用；
• 并行任务启动；
• 显存分配；
• 持续运行期间的GPU/驱动/通信状态。

这里不是评价模型效果，而是确认整套平台能不能稳定承载目标软件栈。

8. 一个更适合落地的验收结构

层级	核心内容
基础	配置、Driver/CUDA、BIOS/BMC、PCIe
GPU	健康、显存、压力、ECC/Xid
多卡	拓扑、NUMA、P2P、NCCL
集群	IB/RoCE、RDMA、跨节点通信
业务	代表性工作负载

工程上最重要的一点是：

测试项可以通用，性能阈值不能简单通用。

同一种测试，放到不同GPU、不同服务器拓扑、不同互联架构上，结果可能完全不同。真正适合长期使用的方式，是逐步建立"同GPU + 同机型 + 同拓扑 + 同软件环境"的交付基线。

这样验收的目的就不是"把所有工具跑一遍"，而是快速判断：这台服务器有没有偏离它本来应该达到的状态。