GPU集群吞吐压测方案实战 - 第2节

2. 压测基础理论

做GPU集群压测，说白了就是搞清楚一件事：这套系统到底能扛多少活？

我刚开始接触压测时，也以为就是跑个脚本看看数字。后来踩了不少坑才明白——不懂基础理论，压测结果就是一堆废纸。今天咱们把几个核心概念掰开揉碎了讲清楚。

吞吐量（Throughput）

吞吐量，就是单位时间内系统能处理多少请求。在GPU集群场景下，我习惯用每秒处理的样本数（Samples/sec）来衡量。

举个例子：你有个推理服务，1秒钟能处理1000张图片。那吞吐量就是1000 img/s。

延迟（Latency）

延迟，就是单个请求从发出到收到响应的时间。单位通常是毫秒。

这里有个坑——平均延迟会骗人。我曾经优化过一个模型，平均延迟只有50ms，但P99延迟到了500ms。用户反馈「时不时卡一下」，就是这1%的慢请求搞的鬼。

所以我在压测时，必看三个指标：

• P50：一半请求比这个快
• P99：99%的请求比这个快
• P999：千分之九十九的请求比这个快

你想想看，如果P99是200ms，那意味着每100个请求里就有1个要等200ms以上。对于高并发场景，这1%可能就是灾难。

并发（Concurrency）

并发，就是同一时刻系统正在处理的请求数。注意，不是QPS。

很多人把并发和QPS搞混。我举个例子：

• 并发100：系统同时处理100个请求
• QPS 1000：系统每秒处理1000个请求

两者关系是：QPS = 并发 / 平均延迟（秒）

假设平均延迟是100ms（0.1秒），并发100时，QPS就是100 / 0.1 = 1000。这个公式很实用，我经常用它来估算系统瓶颈。

QPS / TPS

QPS（Queries Per Second）和TPS（Transactions Per Second）本质一样，都是衡量系统处理能力的指标。在GPU集群场景下，我统一用QPS。

指标	含义	GPU集群场景
QPS	每秒查询数	每秒推理请求数
TPS	每秒事务数	每秒完整训练迭代数

嗯，这里要注意：QPS和TPS不是越高越好。我见过有人把压测调到极限，QPS确实爆表，但GPU利用率只有30%——因为CPU成了瓶颈。这种压测结果，说白了就是自欺欺人。

压测的黄金三原则

做了这么多年压测，我总结出三个铁律。不遵守这三条，压测就是浪费时间。

原则一：可重复

同一个压测场景，今天跑和明天跑，结果应该基本一致。

我曾经遇到一个案例：同样的模型、同样的数据、同样的GPU，两次压测结果差了30%。查了半天，发现是CPU频率被降频了。从那以后，我每次压测前都会检查：

• CPU/GPU频率是否锁定
• 内存带宽是否被其他进程占用
• 网络是否稳定

原则二：可量化

压测结果必须用数字说话。不要说什么「感觉还行」「好像不卡」——这些词在压测报告里就是废话。

可量化的意思是：

• 吞吐量：精确到小数点后两位
• 延迟：给出P50、P99、P999
• GPU利用率：平均利用率、峰值利用率
• 显存占用：峰值显存、平均显存

我习惯用这样的表格记录：

场景	QPS	P50延迟(ms)	P99延迟(ms)	GPU利用率(%)
batch=1	850.23	1.18	2.45	35.6
batch=8	3200.56	2.50	5.12	78.3
batch=32	5600.89	5.71	12.34	95.2

你看，这样一对比，哪个batch size最优，一目了然。

原则三：可对比

压测结果必须能和其他场景、其他版本做对比。否则你优化了半天，怎么证明有效果？

我一般会做三组对比：

• 横向对比：不同模型、不同框架之间的性能差异
• 纵向对比：同一模型优化前后的性能变化
• 基线对比：和行业标准或历史数据做对比

知识体系结构图

下面这张图，把压测基础理论的核心逻辑串起来了。我建议你保存下来，每次做压测前看一眼。

这张图的核心逻辑是：四个指标是压测的「度量衡」，三原则是压测的「方法论」。没有度量衡，你测不出东西；没有方法论，你测不准东西。