1. 压测基础

大家好，我是你们的老朋友。今天咱们聊聊压测——这个听起来有点硬核、但每个做AI服务的人都绕不开的话题。

先问个问题：你辛辛苦苦训练好的模型，上线之后突然被大量用户调用，结果响应慢得像蜗牛，甚至直接挂了。这时候你慌不慌？

嗯，我经历过。有一次我们团队上线一个对话AI服务，上线前没做压测，结果用户一多，GPU显存直接爆了，服务崩溃了整整两个小时。从那以后，我再也不敢跳过压测这一步了。

1.1 什么是服务压测？

服务压测，说白了就是模拟大量用户同时访问你的服务，看看它能扛住多大的压力。

你可以把它想象成给一座桥做承重测试。你不可能等桥建好了、车开上去才发现它要塌。你得提前用重车压一压，看看极限在哪里。

在AI服务里，压测就是模拟成千上万个请求同时打过来，观察服务的表现。比如：

• 一个文本生成模型，同时有1000个用户请求推理
• 一个图像识别服务，每秒涌入500张图片
• 一个语音合成接口，并发连接数达到200

我个人习惯把压测分成两类：

类型	目的	典型场景
负载测试	验证在预期负载下能否正常运行	日常业务高峰
压力测试	找到系统的极限和瓶颈	大促、突发流量

1.2 压测的核心目标

压测到底要测什么？三个核心指标：吞吐量、延迟、并发。咱们一个一个说。

1.2.1 吞吐量（Throughput）

吞吐量就是单位时间内能处理多少请求。常见的单位有：

• QPS（Queries Per Second）：每秒查询数
• TPS（Transactions Per Second）：每秒事务数
• RPS（Requests Per Second）：每秒请求数

举个例子：你的AI翻译服务，每秒能处理100个翻译请求，那吞吐量就是100 QPS。

我记得有一次给一个OCR服务做压测，一开始吞吐量只有30 QPS。后来发现是GPU显存分配不合理，调整了batch size之后，直接飙到了120 QPS。你看，压测能帮你找到这种隐藏的优化点。

1.2.2 延迟（Latency）

延迟就是用户发一个请求到收到响应的时间。通常关注几个分位值：

指标	含义	AI服务典型要求
P50	50%的请求在这个时间内完成	实时服务 < 200ms
P95	95%的请求在这个时间内完成	实时服务 < 500ms
P99	99%的请求在这个时间内完成	实时服务 < 1s

1.2.3 并发（Concurrency）

并发是指同时有多少个请求在处理。注意，并发和吞吐量不是一回事。

你想想看：一个服务可以同时处理100个请求，但每个请求处理得很慢，那吞吐量可能只有10 QPS。反过来，如果每个请求处理得很快，即使只同时处理10个请求，吞吐量也可能达到100 QPS。

在AI服务里，并发尤其重要。因为GPU显存是有限的，并发太高可能导致显存溢出。我曾经遇到过一个BERT模型服务，并发超过8个请求就直接OOM了。后来通过调整并发上限和排队策略才解决。

1.3 压测在AI服务中的重要性

为什么AI服务特别需要压测？原因有三点：

1.3.1 GPU显存是硬约束

传统Web服务，CPU和内存不够可以加机器。但AI服务依赖GPU，显存是固定的。一个模型加载到显存里，占了多少就是多少。并发请求一多，显存不够就直接崩。

我曾经给一个图像生成服务做压测，模型本身占用了6GB显存，每个请求推理还需要额外2GB。结果并发4个请求时，显存就爆了。压测帮我精准找到了这个临界点。

1.3.2 推理延迟波动大

AI推理的延迟不像普通API那么稳定。输入文本长度不同、图片大小不同、batch size不同，延迟可能差好几倍。不做压测，你根本不知道最坏情况下的延迟是多少。

1.3.3 资源利用率需要精细调优

GPU很贵，一台A100就要好几万。你希望把GPU利用率跑满，但又不能超载。压测就是帮你找到那个「刚刚好」的点。

1.4 本章知识体系

下面这张图总结了本章的核心内容，方便你快速回顾：

这张图把本章的知识点串起来了。从压测的定义出发，到三个核心目标，再到AI服务的特殊性。你可以在后续章节中反复对照这张图来理解。