GPU服务器验收指南：配置、GPU健康、P2P、NCCL与压力测试

GPU 服务器交付后，“能开机、能看到 8 张 GPU”只能证明设备完成了最基础的启动。对于训练、推理和科研计算平台，真正的验收还应确认显存、PCIe、NVLink、网络、存储、压力负载和实际业务是否达到预期。

先给结论：AI/GPU 服务器建议按“配置一致性 → 硬件健康 → 拓扑与通信 → 存储/网络 → 压力稳定性 → 真实业务基线”逐层验收。验收指标最好在采购或项目开始前就明确，避免交付后只剩“理论参数”和“主观感觉”。

GPU 服务器验收可以分成 6 层

层级	主要内容	目的
1. 配置核对	CPU、GPU、内存、硬盘、NIC、固件	确认实物与约定一致
2. 健康检查	GPU 状态、ECC、温度、错误、设备访问	排除基础硬件/软件异常
3. 拓扑与通信	PCIe、NVLink、P2P、NCCL	确认多 GPU 通信路径
4. 网络与存储	Ethernet/RDMA、NVMe、文件系统	确认数据通路满足设计
5. 压力与稳定性	计算、显存、功耗、长时间负载	确认持续运行稳定
6. 业务基线	真实模型/应用、吞吐、延迟、错误率	确认平台真正满足使用目标

第一步：验收之前先把“标准”写清楚

很多验收争议不是硬件故障，而是项目开始时没有定义“什么算通过”。建议至少提前记录：

服务器型号、CPU/GPU/内存/NVMe/NIC 的具体配置；
GPU 和网卡拓扑要求；
驱动、CUDA/ROCm、操作系统和框架版本；
需要运行哪些健康检查和压力测试；
是否需要真实模型性能基线；
每项测试的测试时长、通过条件和记录方式。

不要在没有双方确认基线的情况下，临时用网上其他平台的性能数字作为强制验收值。

第二步：配置一致性核对

首先确认实机和交付清单一致，包括：

CPU 型号、数量、核心数；
GPU 型号、数量、显存；
系统内存总容量、通道与 DIMM 状态；
NVMe/SATA/SAS 盘数量与容量；
网卡型号、端口速率、固件；
电源数量和冗余状态；
BIOS/BMC、GPU 驱动、CUDA/ROCm、OFED 等版本。

配置核对的目标是建立一个可追溯的“交付快照”，便于后续升级和排障。

第三步：GPU 健康和基础诊断

可以使用 nvidia-smi、DCGM 等工具检查 GPU 是否正常枚举、温度和功耗是否合理，以及是否出现 XID、不可纠正显存错误等异常。

NVIDIA DCGM Diagnostics 的目标之一，就是在生产工作负载上线前评估 GPU 节点的 readiness。其诊断插件可以覆盖：

软件部署条件和 CUDA Context；
GPU Memory；
PCIe 与 P2P；
持续计算负载；
Memory Bandwidth；
NVLink/PCIe 带宽；
NCCL 通信（在满足环境条件时）。

需要注意：某个测试执行失败不一定直接等于硬件损坏。驱动、权限、CUDA 初始化或环境冲突也可能导致诊断无法完成，应结合错误码和日志判断。

第四步：显存和 ECC 怎么看？

对于支持 ECC 的数据中心 GPU，应记录 ECC 状态以及是否出现不可纠正错误、Row Remap 等异常。显存测试应覆盖分配、读写和数据正确性，而不只是观察“显存容量显示正常”。

消费级 GPU 或不支持 ECC 的型号不能套用相同验收项，应根据硬件能力选择对应测试。

第五步：PCIe 链路和拓扑必须验

多 GPU 服务器中，GPU 数量正确但 PCIe 链路宽度、速率或 NUMA 分布异常，同样会影响实际性能。

建议检查：

每张 GPU 的 PCIe Link Width / Link Generation；
GPU 是否位于预期的 CPU Socket / Root Complex；
NIC、NVMe 与 GPU 的拓扑是否符合平台设计；
是否存在异常降速或设备掉链路。

nvidia-smi topo -m 可以用于查看 GPU、NIC 和 CPU 之间的关系。

第六步：有 NVLink/NVSwitch 的服务器，要单独验互联

不能只看到 nvidia-smi 有 8 张 GPU，就默认 NVLink 正常。DCGM 可以查看 NVLink Link Status、错误计数和拓扑关系，相关诊断还可以对 GPU Copy Path 进行带宽验证。

验收时至少应确认：

预期存在的 NVLink 是否 Up；
GPU 间拓扑是否符合平台设计；
是否存在持续增加的链路错误；
多 GPU 通信测试是否能稳定完成。

第七步：8 卡服务器为什么要做 NCCL 基线？

训练和大模型 Tensor Parallel 会大量依赖集合通信，因此只测试单卡矩阵算力无法覆盖多卡通信链路。

可以使用 NCCL Tests 或 DCGM 中可用的 NCCL 诊断测试 All-Reduce 等集合通信，以确认：

所有 GPU 都能加入通信；
没有明显异常的 GPU Pair 或路径；
通信过程中没有错误或 Hang；
测得带宽与当前平台、拓扑和测试条件基本一致。

带宽阈值应依据具体服务器架构、GPU 和互联方式约定，不能使用一个数值覆盖所有 8 卡服务器。

第八步：多节点还要验 Ethernet / RDMA

如果服务器用于多节点训练或推理，应继续验证：

网卡端口速率和 Link 状态；
IP/VLAN/MTU 是否一致；
RoCE/RDMA 设备、GID 与端口配置；
节点间带宽和时延；
NCCL 是否使用预期的高速网络而不是意外回退。

普通 Ping 只能作为基础连通性测试，不能替代 RDMA 和集合通信验证。

第九步：NVMe 和存储怎么验？

存储验收应先区分系统盘、模型盘、数据盘和共享存储的用途，再选择合适测试。

需要记录：

磁盘型号、容量、SMART/健康状态；
RAID/文件系统配置；
顺序读写、随机 I/O 是否符合项目目标；
多盘并行是否出现单盘异常或明显不均衡；
实际模型加载、Checkpoint 或数据读取是否稳定。

不要只用峰值顺序读带宽代替真实业务 I/O。

第十步：压力测试要看“稳定”，不只看峰值

DCGM 的诊断插件可以对计算、显存、PCIe、功耗和带宽施加负载。压力测试期间应同时观察：

GPU 温度、频率、功耗；
XID、ECC 和其他硬件错误；
是否发生降频、重置或掉卡；
不同 GPU 的性能是否存在异常离群；
整机风扇、电源和 BMC 是否正常。

测试时长与强度应由交付要求确定。生产环境中不要在有正式业务的 GPU 上直接运行侵入式压力测试。

最后一步：用真实模型做业务基线

通用硬件测试通过后，建议再选择代表性模型或业务负载建立平台基线。例如大模型推理可以记录：

模型版本和精度；
输入/输出 Token 长度；
Context；
并发或请求速率；
TTFT、TPOT/ITL、Output Throughput、E2E；
错误率、显存占用和持续运行情况。

业务基线不是为了证明服务器达到某个“网上最高分”，而是给后续扩容、升级、故障对比提供可复现参照。

一份可执行的验收清单

项目	建议记录	是否建议纳入正式验收
硬件配置	型号/数量/序列信息/固件	是
GPU 健康	DCGM/nvidia-smi、错误状态	是
PCIe/NVLink	拓扑、Link、P2P/带宽	多 GPU 建议
NCCL	All-Reduce 等集合通信	训练/模型并行建议
RDMA	端口、GID、带宽、连通	多节点建议
NVMe	健康、容量、I/O 基线	建议
压力稳定性	温度、功耗、错误、掉卡	是
真实业务	固定模型/负载性能	项目型交付建议

常见问题 FAQ

Q1：GPU 服务器能跑 CUDA Sample 就算验收了吗？

不能。它只能证明基础 CUDA 环境可用，不能覆盖显存、PCIe、NVLink、NCCL、网络、存储和长时间稳定性。

Q2：DCGM 全部 Pass 就等于业务性能一定达标吗？

不等于。DCGM 更偏节点健康和诊断，真实模型性能仍需要业务基线测试。

Q3：NCCL 带宽应该达到多少才算正常？

没有跨平台通用阈值。GPU 型号、PCIe/NVLink/NVSwitch 拓扑、NCCL 版本和测试消息大小都会影响结果，应按具体平台建立参考基线。

Q4：为什么验收最好保留完整测试记录？

后续驱动升级、硬件更换、扩容或性能下降时，可以与交付时的同条件结果对比，快速判断变化发生在哪一层。

赋创可提供的支持

赋创可基于客户现有软件环境、代表性负载和目标完成时间，协助整理 AI/GPU 服务器的配置核对、计算与互联测试、性能基线及验收方案，并形成可复查的交付记录。

方案咨询

需要把方案落到实际配置？

联系赋创获取算力、软件栈和交付路径建议。

咨询方案浏览指南