我发现不少用户在第一次接触GPU服务器时，会下意识把“能用”和“用得对”画上等号。机器一到，nvidia-smi能看到卡，就开始跑训练或推理任务。
但现实是，GPU服务器最容易出问题的阶段，恰恰是刚交付那几天。
比如我们在交付验收时，就遇到过这些情况：
- GPU数量对，但显存规格和订单不一致
- 多GPU都能识别，但PCIe链路没有跑满
- 单卡测试没问题，一上多卡通信就明显掉速
- 短时间跑正常，压力一上来就开始报错或降频
所以我更建议你把GPU参数验证当成一套标准化验收流程，而不是一次“随便看看”。先确认识别是否正确，再确认性能是否达标，最后确认多GPU能长期稳定协同。
开箱与基础验收：别让硬件问题拖慢后面所有工作
在系统层面验证之前，我通常会先把最基础的事情确认清楚。
你可以从这几个点开始：
- 记录机器SN、GPU型号、GPU数量、内存和磁盘规格
- 检查GPU供电线、风道、散热组件是否有明显松动
- 第一次开机后查看内核日志，确认没有明显的硬件级报错
这一步不追求性能数字，而是确保：机器本身是一个“健康的起点”。如果这里就埋了雷，后面的驱动、性能测试都会被误导。
驱动与CUDA环境：确认GPU被“正确点亮”
很多新手会卡在这一层，但其实思路可以很简单。
我的做法是分两步：
- 先确认驱动是否正常加载，GPU是否可被系统识别
- 再确认你后续要用的CUDA环境与驱动是匹配的
nvidia-smi是最直观的入口，它适合用来快速确认GPU是否在线、是否有明显错误状态。但我通常会提醒用户一点：
nvidia-smi里显示的CUDA Version，并不等于你已经安装了对应版本的CUDA Toolkit。
如果你后面要跑训练、编译CUDA程序，这一点一定要分清。
参数识别验证：型号、数量、显存是否真的符合预期
这一部分，是GPU服务器验收中最容易被“草草带过”的，但也是最容易埋坑的。
我一般会重点核对三件事：
- GPU型号与数量
- 单卡显存容量
- PCIe链路当前状态与上限
与其肉眼看截图，不如直接把关键字段导出成文件留档。这样后续无论是自查还是和服务商沟通，都有统一依据。
很多人第一次看到PCIe当前代际比最大值低会很紧张，其实你可以先跑一点负载再观察。GPU在空闲状态下降速是常见行为，真正需要警惕的是在负载下依然跑不上去。
性能验证不是“跑分”，而是确认是否达到预期区间
我一直不太喜欢把GPU服务器测试叫做“跑分”，因为真正有价值的不是一个漂亮数字，而是是否符合你这台机器应该有的表现。
在实际验收中，我会把性能验证拆成三个方向：
- GPU计算与显存访问是否正常
- PCIe或NVLink等互联链路是否达标
- 多GPU协同通信是否稳定、可扩展
显存与链路带宽：先确认基础通道没问题
CUDA Samples里的bandwidthTest是一个很好用的工具。
它不追求极致成绩，而是帮你快速判断：
Host到Device、Device到Device的带宽是否落在合理区间。
如果你买的是高规格GPU服务器，但这里的结果明显偏低，那问题通常不在“算法”，而在链路、NUMA或BIOS设置。
多GPU互联：别等训练慢了才怀疑拓扑
只要涉及多GPU，我都会建议你单独验证P2P能力和GPU之间的通信延迟。
p2pBandwidthLatencyTest的价值在于，它可以直接告诉你：
哪些GPU之间通信快，哪些慢，这是否符合你这台机器的拓扑设计。
一旦你发现某几张卡明显“掉队”，那后续训练掉速往往不是偶然。
多GPU协同验证：NCCL测试一定要提前跑
哪怕你现在只打算跑推理，我也建议你至少跑一次NCCL相关测试。
原因很简单：
只要模型或框架涉及多卡并行，通信效率迟早会成为瓶颈。
nccl-tests提供的all_reduce_perf等工具，可以同时验证：
- 多GPU通信是否正确
- 带宽是否随数据规模正常提升
- 是否存在异常卡或异常链路
我更看重趋势是否合理，而不是单次峰值。
稳定性测试：把“隐藏问题”逼出来
很多问题只在时间维度上才会出现。
短时间测试一切正常，不代表你的GPU服务器适合长期跑任务。
我们在实际交付中，经常会加上一轮30分钟到1小时的压力测试，重点观察：
- 温度是否稳定
- 功耗是否异常波动
- 是否出现降频、Xid或ECC错误
gpu-burn这类工具虽然“粗暴”，但非常适合做稳定性筛查。
一份你可以直接用的GPU服务器验收清单
如果你不想每次都重新梳理思路，可以直接用下面这套逻辑作为参考：
| 验证项 | 关注重点 | 常见风险 |
|---|---|---|
| GPU型号与数量 | 是否与订单一致 | 混插、少卡 |
| 显存容量 | 单卡显存是否达标 | 显存规格不符 |
| 驱动状态 | 是否有明显报错 | Xid、ECC |
| PCIe/NVLink | 链路是否跑满 | 拓扑或BIOS问题 |
| 多GPU通信 | P2P与NCCL是否正常 | 掉速、卡死 |
| 压力稳定性 | 长时间是否稳定 | 散热、供电问题 |
FAQ
我只是跑推理，也需要这么多验证吗？
需要。推理服务同样可能涉及多卡并行、显存拷贝和跨卡通信，提前验证比线上排错成本低得多。
nvidia-smi够不够？
够用来“看状态”，但不够用来“做结论”。真正的验收，需要结合带宽、通信和稳定性测试。
什么时候可以认为服务器“验收通过”？
当配置识别正确、性能落在合理区间、多GPU通信正常、压力测试稳定时，就可以放心投入业务。
结尾：把验收前置，是最省时间的选择
我一直认为，独立GPU服务器真正昂贵的不是硬件价格，而是你在问题出现后被拖走的时间。
如果你能在交付阶段，把这套参数验证流程完整跑一遍，后面无论是训练、推理还是扩展，都能少走很多弯路。
欢迎你在评论区分享你正在使用的GPU型号和卡数，也可以把关键测试结果贴出来一起讨论。如果你觉得这篇文章对你有帮助，也欢迎点赞、收藏或转发给同样刚拿到GPU服务器的朋友。