挑GPU云服务器时，很多人先看显卡型号。A100、H100、L40S这些名字听着都很厉害，但真正影响项目进度的，通常是几项具体指标，以及它们和你的任务是否匹配。这篇文章从指标、测试方法和几个实际案例说说，怎么判断一台GPU云服务器性能好不好。
先看四类指标
GPU云服务器的性能不是一个数字能说清的。选型时主要看下面四块。
- 算力：资料里常给FP16、TF32或INT8下的理论TFLOPS。它代表矩阵运算的上限，实际能跑到多少，取决于模型结构和代码写法，理论值和实际利用率通常有一段距离。
- 显存容量与带宽：容量决定模型能不能装下、batch size能开多大。带宽决定数据在显存和计算单元之间搬运的速度。跑大模型推理时，带宽往往先碰到天花板，算力反而还有富余。
- 卡间互联：多卡训练时，NVLink的带宽比PCIe高很多。如果实例只给PCIe，多卡通信会占掉一部分时间，八张卡不一定能换来八倍速度。
- 系统配套：CPU核数、内存、本地NVMe盘和网络带宽。数据喂不进去，GPU再强也只能等。
用实测代替纸面参数
参数表适合做初筛，用来决定哪几台机器值得进入下一轮。真正拍板，还是要拿自己的负载跑一遍。
- 训练场景：看每秒处理的样本数或tokens/s，同时观察GPU利用率曲线是否平稳。曲线忽高忽低，多半是数据供应跟不上。
- 推理场景：关注首token延迟，以及P50、P99这样的延迟分位数，再测目标并发下的QPS。平均延迟好看，不代表用户体验就好。
- 监控工具：nvidia-smi适合看即时利用率和显存占用。长时间观察可以用dcgmi，或者Prometheus配合DCGM Exporter，更容易发现温度降频、ECC错误这类隐性问题。
测试时变量要固定，同一个模型、同一份数据、同样的精度设置。时长也别太短，至少跑十几分钟。前几分钟往往还在预热，这段数字好看，不一定代表稳定状态。
三个案例
案例一：商品图像模型训练
某电商技术团队一开始用一款入门级GPU实例训练商品识别模型，单轮要跑将近两天。排查时发现，GPU利用率长期只有三成上下，瓶颈在数据预处理。实例的CPU核数偏少，图片解码和增强跟不上GPU的消耗。后来他们换到CPU核数更多、本地NVMe盘更快的规格，又把预处理改成异步流水线，训练时间压到约二十小时。显卡没有换，问题却解决了，所以GPU云服务器的短板，很多时候不在显卡上。
案例二：智能客服的大模型推理
一家做智能客服的公司要部署一个中等规模的大语言模型。最早选的机型显存够用，但带宽偏低。模型能跑，并发一上来，P99延迟就超过三秒，用户能明显感觉到卡顿。换成显存带宽更高的新一代GPU后，同样并发下P99降到一秒以内。之后团队又启用了量化和连续批处理，吞吐进一步提升。这说明，推理服务的体验要看延迟分布的尾部，平均值会把问题藏起来。
案例三：八卡训练的互联差异
一个科研小组在两种实例上跑同一个模型的八卡训练。A实例走NVLink，B实例只有PCIe。两边的理论算力接近，但A的扩展效率明显更好，八卡相对单卡的加速比接近线性，B只有大约五倍。通信密集的训练任务，互联方式的影响往往比单卡性能更大，选多卡机器时值得单独看这一项。
常见误区
- 只盯理论TFLOPS，不看实际利用率和显存带宽。
- 认为显存越大越好。先算清模型和batch size真正需要多少，多出来的显存就是白花的钱。
- 忽略虚拟化和共享资源带来的波动。同一规格在不同时段的结果可能差一截，最好多测几次。
- 只看平均延迟，不看P99和长时间稳定性。
- 一味追新卡，不算价格和负载是否匹配。跑小模型用旗舰卡，多半是浪费。
选型步骤
- 先确定负载是训练、微调还是推理，再估算显存需求。模型参数、激活值和batch size都要算进去，别只看权重文件的大小。
- 拿一小份数据，在两三款候选机型上跑基准，记录吞吐、延迟和GPU利用率。脚本和参数保持一致，结果才有可比性。
- 检查数据管道和存储。如果利用率上不去，先看CPU和磁盘是不是拖了后腿。
- 结合按需、包年包月或竞价实例的价格，算出单位任务的成本，而不是只看每小时单价。
- 上线后持续监控，负载变化了就调整规格。
GPU云服务器的性能没有通用的最优解。把指标含义弄清楚，用自己的负载测一测，再回到成本和业务目标上权衡，一般就能选到合适的机器。
