一、GPU集群压测概述：为什么需要压测、压测的核心指标、常见误区

1.1 为什么需要压测？——别等上线了才后悔

说实话，我见过太多团队踩过这个坑。

模型训练得好好的，一上集群就崩。或者推理服务延迟从10ms飙到500ms，用户直接骂娘。为什么会这样？因为开发环境和生产环境，根本就是两个世界。

我个人习惯，在项目初期就把压测纳入流程。不是等到快上线了才临时抱佛脚，而是从一开始就摸清集群的底牌。

压测的核心目的，说白了就三个：

• 验证集群能不能扛住预期负载——你算力再强，带宽不够也是白搭
• 找到性能瓶颈在哪——是卡在GPU计算上，还是卡在PCIe带宽上，还是卡在网络通信上？
• 给容量规划提供依据——比如你要支撑1000路并发推理，到底需要多少张卡？

1.2 压测的核心指标——盯住这三个数就够了

很多新手一上来就盯着GPU利用率看，觉得利用率高就是好。嗯，这里要注意——利用率高不一定代表效率高。

我个人习惯，压测时重点看三个指标：

1.2.1 吞吐量（Throughput）

这是最直观的指标。训练场景看的是「每秒处理多少样本」，推理场景看的是「每秒处理多少请求」。

举个例子：

# 训练场景
吞吐量 = 总样本数 / 总耗时
单位： samples/sec 或 tokens/sec

# 推理场景
吞吐量 = 成功响应数 / 总耗时
单位： QPS（Queries Per Second）

我建议你压测时，至少跑3轮取平均值。单次结果波动太大，没有参考价值。

1.2.2 延迟（Latency）

吞吐量高，不代表延迟低。你想想看，如果系统把请求都缓存起来批量处理，吞吐量确实上去了，但单个请求的等待时间可能很长。

延迟指标通常看这几个分位值：

分位值	含义	典型阈值（推理场景）
P50	50%的请求在这个时间内完成	< 50ms
P95	95%的请求在这个时间内完成	< 200ms
P99	99%的请求在这个时间内完成	< 500ms

1.2.3 利用率（Utilization）

利用率要分维度看：

• GPU计算利用率——核心是否在干活？但注意，利用率高也可能是由于kernel启动开销大导致的假象
• GPU显存利用率——显存是否够用？OOM了没？
• NVLink/PCIe带宽利用率——数据传输是否成为瓶颈？
• 网络带宽利用率——跨节点通信是否饱和？

我见过最离谱的情况：某团队看到GPU利用率95%，以为优化得不错。结果一查NVLink带宽利用率只有10%，说明GPU大部分时间在空转等待数据。这就是典型的「假忙」。

1.3 压测的常见误区——这些坑我替你踩过了

误区一：压测环境跟生产环境不一样

很多人图省事，在开发机上跑压测。但开发机通常只有几张卡，网络拓扑也简单。生产环境动辄几十上百张卡，跨节点通信的延迟和带宽完全不是一个量级。

我曾经见过一个团队，在4卡机器上压测一切正常，上线到64卡集群后，训练速度反而下降了。为什么？因为通信开销随着卡数增加呈指数级增长，小规模压测根本暴露不了这个问题。

误区二：只压测一个场景

有些团队只压测「理想情况」——比如纯计算密集型任务，或者小batch size。但实际生产环境是混合负载：有大batch训练、有小batch推理、有数据预处理、有模型保存。

我建议你至少压测三种场景：

1. 计算密集型——比如纯矩阵乘法，看GPU算力上限
2. 通信密集型——比如AllReduce操作，看网络带宽瓶颈
3. 混合负载——模拟真实训练/推理流程

误区三：压测时间太短

跑个几分钟就下结论，这是大忌。很多问题需要长时间运行才会暴露：

• 显存泄漏——跑几小时才出现OOM
• 温度过高——GPU降频导致性能下降
• 网络抖动——偶发性的丢包和重传

误区四：只看平均指标

平均吞吐量2000 QPS，看起来很漂亮。但如果你看时间序列，会发现它可能是「前10分钟3000 QPS，后20分钟1500 QPS」的平均值。这种波动在实际生产中是不可接受的。

我个人习惯，压测报告里一定要包含：

• 时间序列图（吞吐量随时间的变化）
• 分位值分布（P50/P95/P99）
• 异常点标注（比如延迟突增的时刻）

1.4 本章知识体系

下面这张图，是我自己总结的压测知识框架。每次做压测前，我都会对照着检查一遍：

这张图把压测的核心逻辑串起来了。你每次做压测前，可以对照着问自己三个问题：

• 我为什么要压测？——对应左侧
• 我看哪些指标？——对应中间
• 我有没有踩坑？——对应右侧

嗯，把这些想清楚了，压测就不会跑偏。