前言：

在做 Agent 项目之前，我最早接触的 AI 性能测试，是模型服务层压测。

真正的模型服务层压测，核心不是“模型对不对”，而是：

模型作为一个高算力黑盒服务，能扛多少流量？瓶颈在哪？

这篇梳理模型服务层。

一、模型层压测的边界

先明确：

模型服务层压测不关注：

• loss

• 微调参数

• 训练效果

• 算法结构

它关注的是：

• 并发能力

• 延迟分布

• 成功率

• 资源瓶颈

也就是：

推理服务的系统性能。

---

二、模型服务层核心指标

我当时的压测，主要围绕四类指标。

---

1、延迟指标

• 平均响应时间

• P95 / P99

• 首 token 时间（TTFB）

平均值意义不大。

关键看 P95 / P99。

在对话系统中，TTFB（多久开始返回第一个 token）直接影响用户体感。

---

2、吞吐能力

• QPS

• 每秒 token 生成量（token/s）

• 最大可稳定并发数

压测不是一上来就 100 并发。

而是逐级递增：

5 → 10 → 20 → 30 → 50

找到“性能拐点”。

所谓拐点，就是：

• 成功率开始下降

• P99 突然拉长

• RT 出现明显抖动

---

3、成功率

须统计：

• HTTP 200 比例

• 超时比例

• 5xx 错误比例

高并发下常见现象：

• silent fail

• timeout

• 直接拒绝请求

只看 RT 是不够的。

---

4、资源指标（非常关键）

性能问题往往不在接口代码。

而在资源瓶颈。

需要同步监控：

• GPU 显存

• GPU 利用率

• CPU

• 内存

我当时压测的一个关键发现是：

• CPU 使用率正常

• GPU 显存接近上限

• 成功率在 30 并发后下降

说明瓶颈在 GPU 显存，而不是接口逻辑。

这一步才是真正的性能定位。

---

三、压测流程设计

采用的是分阶段压测。

---

Step 1：固定模型参数

必须固定：

• temperature

• max_tokens

• top_p

否则数据不可对比。

---

Step 2：单线程基线测试

目标：

• 获取基准 RT

• 记录 TTFB

• 确认无错误

---

Step 3：逐级提升并发

并发逐步递增：

• 记录每一级的：

  • 平均 RT

  • P95

  • 成功率

  • GPU 使用情况

---

Step 4：观察性能拐点

当出现：

• 成功率下降

• P99 飙升

• RT 抖动明显

说明接近系统上限。

---

Step 5：结合资源监控定位瓶颈

例如：

• 显存接近 100%

• GPU 利用率饱和

• CPU 正常

就可以判断：

模型推理资源成为限制因素。

---

四、模型层压测能回答什么？

模型服务层压测能回答：

• 单实例能支持多少并发？

• 是否需要多卡部署？

• 是否需要限流？

• QPS 上限在哪里？

• 是否需要扩容？

它不能回答：

• 决策是否稳定

• 状态是否安全

• 输出是否可靠

那是 Agent 层的问题。

---

五、常见误区

1.只看平均响应时间
2.不统计成功率
3.不监控 GPU
4.一上来就高并发
5.不固定模型参数

这些都会导致结论失真。

---

六、小结

模型服务层压测，本质是：

把大模型当成一个高算力黑盒 API，验证吞吐能力和资源瓶颈。

它解决的是：

“模型扛不扛得住”。

但不解决：

“系统会不会乱”。

在完整的 AI 性能测试框架中，它只是第一层。

后续还需要验证：

• 决策稳定性

• 状态并发安全

• 生成结构可控性

模型层压测，是基础，但不是全部。