西安GPU服务器交付时的性能验证清单，核心结论是：必须围绕计算性能、存储带宽、互联拓扑和稳定性压力测试四个维度逐项验收，缺一不可。
很多团队在西安拿到GPU服务器后，插上电就跑模型，结果训练速度达不到预期，或者跑着跑着突然掉卡，问题往往不是硬件本身有故障，而是交付验收环节没做透，GPU服务器不同于普通CPU服务器，它的性能天花板由多个部件协同决定，任何一项短板都会拉低整体算力输出，下面这份清单，是根据多年在西安机房交付大算力集群的实际经验整理的,照着做能避开绝大多数坑。
交付环境检查：别急着上电，先看物理层
在机柜里装好设备后，别第一时间按电源键，先检查供电和散热环境，这两项在西安的数据中心里特别容易出问题，西安夏季机房温度容易偏高，如果空调冗余不足,高负载测试时可能触发高温降频。
- 电源冗余验证：确认双路供电都正常，查看BMC/IPMI面板上的电源状态,两个PSU都亮绿灯才算合格。
- 散热风道确认：检查前后风道无遮挡，GPU模组进风口温度低于35度,用手背贴近进风口感受是否有明显气流。
- 网络连通性：管理网口和业务网口都要插线，并记录交换机端口对应关系，使用
ip a命令核对IP能否ping通管理网关。
物理层检查通常半小时内能完成，这部分不复杂,但能避免后面测试时突然断电或过热重启的麻烦。
GPU基础状态与驱动验证
驱动和固件版本是性能验证的前提，版本不对,后面的benchmark数据完全没有参考意义。
检查GPU识别数量与拓扑
登录系统后，先执行nvidia-smi，确认系统识别到预期数量的GPU，例如8卡机器，nvidia-smi应该列出8张卡,且没有报错信息。
接着查看NVLink拓扑结构，使用nvidia-smi topo -m，输出中能看到GPU之间的互联方式，如果是NVLink全互联架构，矩阵中应该显示NV连接；如果是PCIe直连，则显示PHB或PIX，行业共识认为，8卡训练场景下,NVLink互联比PCIe道带宽对模型并行训练的影响可达到数倍差距。
确认驱动与CUDA版本匹配
在西安的交付现场，我们经常遇到驱动版本过老或CUDA Toolkit版本不匹配的情况，用nvidia-smi看右上角的CUDA Version，再用nvcc --version查看本机CUDA编译器版本，两个版本不需要完全一致，但驱动版本必须高于或等于CUDA工具包要求的驱动下限，如果驱动版本过低，PyTorch会报CUDA error: no kernel image is available,这直接在交付阶段就拦截住。
计算性能基准测试：单卡与多卡并行
这是整个验证清单的核心环节，只跑跑nvidia-smi看显存大小是没用的,必须用实际算力负载去压测。
单卡峰值性能测试
使用gpu-burn或stress-gpu这类工具,将GPU的计算核心推到接近满载状态。
- 执行命令：
./gpu-burn 600,持续运行10分钟。 - 观察指标：用
nvidia-smi dmon -s puc每隔1秒记录GPU利用率、显存利用率和功耗。 - 判定标准：满载运行时，GPU利用率应接近100%（可以有小幅波动，但不应低于95%），功耗应接近该型号的TDP标称值，例如某型号TDP为350W，实际满载功耗应在330W-350W区间,温度控制在85度以下为健康状态。
如果某个GPU的利用率只有拉满到82%就上不去，或者功耗明显低于其他卡，大概率是显存颗粒有瑕疵或供电相数有问题，这种情况需要联系厂商换货,不要尝试自行修复。
多卡并行与通信测试
单卡性能正常不代表多卡能高效协同,这一步专门测GPU之间的通信带宽。
推荐使用nccl-tests工具包，编译后运行./build/all_reduce_perf -b 1M -e 8G -f 2 -g 8,这个命令测试8张卡之间执行AllReduce操作的耗时。
- 观察输出中的
busbw（总线带宽）数值。 - 以8卡A100（40GB显存版本）为例，NVLink互联状态下，
busbw通常可以达到600GB/s以上。 - 如果只有200GB/s，说明NVLink未生效，检查
nvidia-smi topo -m中的连接模式,或者确认驱动加载了NVSwitch相关模块。
这里要特别提醒：测试时最好同时开两个终端，一个跑nvidia-smi观察，另一个跑nccl-tests，如果多卡测试期间某张卡的显存占用一直为0，说明通信阻塞严重,GPU根本没进入工作状态。
显存与带宽专项验证
训练大模型时，显存带宽直接决定数据读写的天花板，这个项目容易被忽略,但出问题概率不低。
显存容量核验
用nvidia-smi --query-gpu=name,memory.total --format=csv查看每张卡的显存总量，对比厂商标称值，差异应该为0，有些显卡被刷过BIOS，实际显存小于标称,这类问题只能靠容量查询发现。
显存读写带宽测试
使用bandwidthTest工具（CUDA Samples自带），运行./bandwidthTest --memory=pinned --mode=shutdown。
- 通过PCIe访问显存时，带宽会比GPU直接访问显存低一个数量级,这个结果只作为参考。
- 真正要看的是GPU内部的显存带宽，用
./bandwidthTest --device=0（各卡编号轮换测试）,数值应接近该型号的理论显存带宽。
业内专家指出，显存带宽不达标会直接导致大模型训练时的数据加载瓶颈，GPU核心经常处于等待数据的状态，表现出来就是利用率忽高忽低,训练吞吐量上不去。
长时间稳定性压测与日志监控
性能达标的硬件，不一定扛得住连续数天的高负载运行,交付验收时最好做一轮超过12小时的耐久测试。
持续压力测试方案
执行./gpu-burn并加上循环参数，或者直接跑一个完整的深度学习训练脚本（例如BERT-Large微调任务），两种方案各有侧重：gpu-burn是纯计算压测，训练脚本则能覆盖数据加载、CPU预处理、GPU计算和通信的完整链路。
设置监控脚本,记录以下指标：
- GPU温度随时间变化曲线,观察是否持续堆积升高。
- 显存ECC错误计数，使用
nvidia-smi -q -d ECC查看，任何非零的Volatile Uncorrectable错误都意味着硬件隐患。 - 掉卡或驱动重置事件，检查
dmesg -T | grep -i nvidia，如果出现NVML_ERROR_DRIVER_NOT_LOADED或Xid error,说明设备不稳定。
在西安做过的不少交付项目中，前4小时一切正常，但到第10小时左右开始出现Xid错误，这就是典型的热稳定性缺陷，出现任何Xid错误，无论是否自动恢复，都建议直接申请换卡,不然未来生产环境会频繁中断训练任务。
存储与数据加载性能验证
GPU算得再快，数据喂不进去等于白搭，这一步验证本地NVMe盘和文件系统读取能力,很大程度决定实际训练中的整体效率。
本地NVMe顺序读测试
使用fio测试工具：fio --name=read_test --rw=read --bs=1M --size=10G --numjobs=4 --iodepth=32 --direct=1。
- 关注
READ: bw=字段的聚合带宽。 - 对于现代数据中心级NVMe盘（如Intel P5510或三星PM9A3），多队列顺序读应达到6GB/s以上。
- 如果只有1-2GB/s，检查是否误用了SATA线缆或插在PCIe 3.0 x1插槽上。
数据加载链路测试
在存储上放置一个约50GB的随机图片或小文件集（比如ImageNet格式的数据集），用PyTorch的DataLoader API实际加载一遍,记录耗时。
- 用
time python load_test.py观察实际读盘到内存的时间。 - 对比本地NVMe盘与传统SATA盘的数据源，能看到明显性能差距,这有助于判断存储配置是否满足分布式训练的数据喂送需求。
多卡模型并行训练模拟验证
基准测试全过，最后一步跑一个贴近真实业务的最小规模训练任务，比如用DeepSeek或Llama架构的1.5B模型，在8卡上执行一次完整的微调（约跑200步），这一步能验证框架层面的CUDA调用是否正确，以及是否存在无形中降低性能的隐性问题（如PCIe降速）。
执行torchrun --nproc_per_node=8 train_script.py
,观察输出：
- 每张卡的利用率是否均在95%以上,没有掉队卡。
- 训练loss是否稳步下降,无NaN或剧烈跳动。
- 单卡吞吐量（tokens/s）是否符合该模型在对应GPU型号上的合理区间。
如果此前所有单项测试都通过但真实训练脚本跑不起来，优先排查PyTorch版本与CUDA版本兼容性，执行python -c "import torch; print(torch.__version__)"核对版本编号，在西安的机房交付中曾遇到PyTorch 2.0编译的轮子文件和CUDA 11.8驱动不兼容导致显存分配失败,更换PyTorch构建版本后问题解决。
西安GPU服务器性能验证常见疑问解答
问：西安GPU服务器交付时，只看nvidia-smi能判断性能正常吗？
不能。nvidia-smi只能反映设备是否被系统识别，以及当前利用率、温度、功耗等基础状态，它不测试计算峰值、通信带宽和稳定性，不少硬件在空载或低负载显示正常，但在高压力下才会暴露物理损伤,必须以实际跑分工具和长时间压测结果为依据。
问：交付测试应该在多少温度环境下进行才符合西安机房条件？
建议将机房进风温度控制在18-27度之间，这是大多数GPU厂商推荐的工作温度区间，夏季西安机房若无法稳定控制在这个范围，GPU性能会受限于热降频保护机制，在机柜后没做冷热通道隔离的情况下，建议把压力测试时间安排在下午2点到6点，这个时段通常是机房环境温度的最高点,通过测试就代表最恶劣工况下也没问题。
问：多卡通信测试不通过时的排查步骤是什么？
答： 首先检查BIOS中PCIe链路速度设置，确保没有锁定在Gen3模式，应为Gen4或Auto，其次更新NVIDIA官方驱动到最新稳定版，新版驱动往往修复NVLink初始化问题，再次核查nvidia-smi topo -m输出的拓扑结构是否与硬件架构图吻合，不吻合则联系服务器厂商获取正确的PCIe switch配置，最后更换GPU间数据线缆再跑一次all_reduce_perf，物理链路损坏也会导致通信带宽骤降，按这个顺序排查，经历大量现场验证,能解决绝大多数通信异常情况。
这份西安GPU服务器交付验证清单的最终价值，在于用可重复执行的测试步骤替代盲目信任的交付报告。 跑完上述所有项目且全部达标，就可以放心地投入训练任务，若任何一环亮红灯，务必在验收单上明确备注并跟进硬件调换，这远比事后服务中断再排查代价更低，硬件的坑在交付期填平，后续开发和运维才能把精力放在模型迭代本身，毕竟，一份可靠的性能验证清单,省下的是整个项目周期里最昂贵的隐性成本。