AI系统如何做性能测试？最近两年，很多测试团队都开始接触 AI 项目。以前测一个接口，大家的思路很清楚：加并发、压 Q

最近两年，很多测试团队都开始接触 AI 项目。

以前测一个接口，大家的思路很清楚：加并发、压 QPS、看响应时间、错误率、CPU、内存，再找性能拐点。

但把这套方法直接搬到大模型、RAG、Agent 系统上，很快就会遇到一个问题：

接口明明没报错，CPU 也不高，用户为什么还是觉得系统很慢？

比如两个 AI 系统：

系统 A：8 秒后一次性返回完整答案
系统 B：800ms 开始输出，持续生成 10 秒

从传统“总响应时间”看，B 更慢。

但真实用户通常会觉得 B 更快。

因为 AI 系统不是简单的“请求—响应”，而是一个持续生成 Token 的过程。

这也是 AI 性能测试真正发生变化的地方。

传统系统主要测“请求有没有扛住”，AI 系统还要测“生成过程有没有扛住”。

2026 年 8 月，MLCommons 发布了端到端 RAG Inference Benchmark。一个很值得测试工程师关注的变化是：对于包含检索、模型和其他组件的 RAG 流水线，单一的 Token/s 已经无法代表整个系统性能。

这其实释放出了一个很明确的行业信号：

AI 性能测试，正在从单接口压测走向全链路容量工程。

一、AI 上线之后，传统性能测试为什么突然不够用了？

传统 Web 系统的一次调用大致是：

所以我们过去习惯关注：

QPS、TPS、平均响应时间、P95、P99、错误率、CPU、内存、数据库连接池。

这些指标到了 AI 系统依然有价值。

问题是，它们已经不够了。

因为一次大模型请求实际上更接近：

这里出现了传统接口里很少单独讨论的三个阶段：

排队、Prefill、Decode。

所以同样一个“响应时间 10 秒”，背后可能完全是两种问题。

一种是：

等了 8 秒
+
生成 2 秒

另一种是：

等了 500ms
+
持续生成 9.5 秒

优化方向完全不同。

NVIDIA 当前的大模型 Benchmarking 文档也明确区分了传统负载测试和模型性能 Benchmark：前者主要验证真实流量、容量和扩缩容能力，后者则重点观察模型吞吐、延迟以及 Token 级指标。两者需要结合，而不是互相替代。([NVIDIA Docs][2])

所以，做 AI 系统性能测试时，第一个需要改变的不是工具，而是性能指标模型。

二、AI 性能问题的本质，已经从接口延迟变成推理链路延迟

很多团队第一次做大模型性能测试，通常会直接压：

POST /chat/completions

这种方法没错。

但它只能告诉你：

模型 API 能不能扛住？

真实生产环境需要回答的却是：

整个 AI 应用能不能扛住？

因为现在稍微复杂一点的 AI 应用，架构往往已经变成这样：

这张图其实也是理解 AI 性能测试最重要的一张图。

一次用户请求可能经历：

向量检索
→ Rerank
→ Prompt 拼装
→ 模型第一次推理
→ Agent 判断
→ Tool 调用
→ 模型第二次推理
→ 流式输出

假设整个请求用了 12 秒。

真正的耗时可能是：

环节	P95耗时
Vector Search	200ms
Rerank	600ms
Prompt 构建	100ms
LLM 第一次调用	3.2s
Tool 调用	2.1s
LLM 第二次调用	5.3s
其他开销	500ms

如果没有 Trace，你看到的可能只有：

Response Time = 12s

然后大家开始调 GPU、换模型、扩机器。

最后发现几乎没效果。

因为真正慢的可能根本不是模型，而是外部 Tool 或数据库。

AI 系统的性能瓶颈，很多时候不在模型，而在模型前后的整条调用链。

因此 RAG 性能测试和 Agent 性能测试必须做分段耗时和全链路 Trace，不能只在网关入口统计一个总响应时间。

三、真正做 AI 性能测试，要盯住哪些指标？

AI 性能指标很多，但没必要一开始就堆几十个。

实际工程里可以先拆成四层。

1. 用户体验层：TTFT 比总响应时间更值得关注

第一个非常重要的指标叫：

TTFT：Time To First Token。

也就是：

用户发送请求以后，需要等待多久才能看到第一个 Token。

例如：

请求发送：10:00:00.000

首个 Token：
10:00:00.800

那么：

TTFT = 800ms

对于 AI 客服、聊天机器人、Copilot 等流式场景，TTFT 对用户体验影响非常明显。

因为用户并不一定要求答案瞬间生成完。

但很难忍受页面一直没有反应。

另一个指标叫：

TPOT：Time Per Output Token。

它描述的是首 Token 出现之后，后续 Token 的平均生成速度。

vLLM 当前的 Benchmark 定义中：

TPOT =
（端到端耗时 - TTFT）
÷
（输出 Token 数 - 1）

同时还会统计 ITL，也就是连续流式输出之间的间隔。需要注意的是，不同 Benchmark 工具对这些指标的定义并没有完全统一，真正做横向比较时，要看计算方式，而不能只看指标名字。([vLLM][3])

所以用户侧至少应该同时观察：

TTFT
+
TPOT / ITL
+
End-to-End Latency

如果：

TTFT = 500ms
TPOT = 300ms

用户体验依然可能是：

开始回答挺快，但一个字一个字往外蹦。

2. 吞吐层：只看 QPS，很容易误判大模型容量

传统系统喜欢看：

100 QPS
500 QPS
1000 QPS

但大模型里，两个 Request 对 GPU 造成的压力可能完全不同。

请求 A：

Input：300 Tokens
Output：100 Tokens

请求 B：

Input：20000 Tokens
Output：3000 Tokens

从 HTTP 层看：

都是 1 Request

但从模型推理层看，两次计算量完全不同。

所以大模型性能测试还需要观察：

Token Throughput / Tokens Per Second。

也就是：

系统每秒到底能处理或生成多少 Token。

这也是为什么只用 QPS 衡量大模型服务能力，很容易得出错误结论。

3. 资源层：CPU 没满，不代表 AI 系统还能扛

AI 系统除了传统指标：

CPU
Memory
Load
GC
Thread
Network

还需要加入：

GPU Utilization
GPU Memory
KV Cache
Batch Size
Queue Length
Input Tokens
Output Tokens
Context Length

尤其值得关注的是：

Queue Length 和 KV Cache。

一个常见现象是：

20 并发 → TTFT 800ms
50 并发 → TTFT 1.2s
80 并发 → TTFT 2s
100 并发 → TTFT 6s

但此时：

CPU = 40%
Memory = 55%

如果仍然按照传统服务器监控方式判断，很可能得出：

系统资源还很充足。

实际情况却可能是：

GPU 已经接近饱和，请求正在等待调度。

vLLM 的生产指标里现在已经直接暴露了 Waiting Requests、端到端请求延迟、Inter-token Latency、Decode Time、Generation Tokens 以及 KV Cache 相关指标。

这说明大模型性能监控正在逐渐从“主机级监控”转向“推理引擎级监控”。

4. Agent 层：一次请求到底放大成了多少次调用？

Agent 又比单纯的大模型服务复杂一层。

用户只发送了一条请求：

帮我分析最近一周的线上异常，并给出原因。

Agent 内部可能发生：

LLM
↓
日志查询 Tool
↓
LLM
↓
监控查询 Tool
↓
LLM
↓
数据库 Tool
↓
LLM
↓
最终回答

于是一个用户 Request，背后可能变成：

4 次 LLM 调用
3 次 Tool 调用
2 次数据库查询
15000 Tokens

所以 Agent 性能测试还要关注：

指标	关注什么
Agent End-to-End Latency	一个完整任务多久完成
Agent Steps	一个任务跑了多少步
LLM Calls	调了多少次模型
Tool Calls	调了多少外部工具
Retry	有没有频繁重试
Input Tokens	输入上下文规模
Output Tokens	最终生成规模
Cost	一个任务实际成本

这里特别容易出现一个问题：

Token Amplification，Token 放大。

用户可能只输入 300 Token。

但 Agent 跑完一个完整任务，内部已经消耗 15000 Token。

并发增加 10 倍之后，GPU 压力和模型费用也可能一起被放大。

到了 Agent 系统，性能测试实际上已经开始和成本测试发生交叉。

四、一个 RAG + Agent 系统，性能瓶颈到底会出现在哪里？

来看一个更接近真实生产环境的例子。

假设公司上线了一套企业 AI 知识库：

现在逐步提高并发。

假设得到这样一组测试数据。

50 并发

TTFT P95：1.0s
TPOT P95：40ms

Retrieval P95：180ms
Rerank P95：300ms

GPU：65%
Queue：基本为 0

系统正常。

150 并发

TTFT P95：3.5s
TPOT P95：45ms

Retrieval P95：210ms
Rerank P95：320ms

GPU：93%
Queue：明显增加

这个结果非常值得注意。

TPOT 几乎没怎么变，TTFT 却从 1 秒涨到了 3.5 秒。

说明模型一旦真正开始 Decode，生成速度没有明显恶化。

真正的问题更可能发生在：

请求排队
+
Scheduler
+
Prefill

250 并发

TTFT P95：9.5s
TPOT P95：60ms

GPU：98%
Queue：持续上涨

Timeout：4%

到这里就可以认为系统进入了明显的饱和区。

真正应该得到的测试结论不是：

系统最大可以支持 250 并发。

而应该是：

当并发超过约 150 后，TTFT 开始明显恶化；到 250 并发时排队持续增长并出现超时，因此当前可接受容量应结合 TTFT SLO 定义在饱和点之前。

这是两种完全不同的性能测试思维。

性能容量不是“系统什么时候挂”，而是“用户体验什么时候开始不可接受”。

五、AI 性能测试真正应该怎么落地？

真正落地时，不建议一上来就对整个 Agent 系统打 1000 并发。

更合理的方法是分四层压。

第一层：先测模型裸性能

链路尽量简单：

Load Generator
↓
LLM Serving

测试不同：

Input Token
Output Token
Concurrency
Request Rate

观察：

TTFT
TPOT / ITL
TPS
Request Throughput
GPU
KV Cache
Queue

这一层解决的问题是：

模型服务本身到底有多少容量。

第二层：再把 RAG 加回来

加入：

Embedding
Vector DB
TopK
Rerank
Prompt

然后测试不同 Context Length：

1K
4K
8K
16K
32K

观察：

Retrieval Latency
Rerank Latency
Prompt Tokens
TTFT
GPU

因为上下文变长以后，不只是 Token 成本会上涨，Prefill 压力也会增加。

这一阶段真正要回答的是：

知识库到底给模型塞多少内容，性能和效果最平衡？

第三层：最后测 Agent 完整任务

不要只用：

你好

作为压测 Prompt。

真实业务应该按照生产流量准备不同任务。

例如：

简单问答        40%
RAG 查询        30%
数据库查询      15%
多 Tool Agent   10%
长文本分析       5%

再根据真实分布生成流量。

重点记录：

任务完成时间
Agent Steps
LLM Calls
Tool Calls
Retry
Token Usage
成功率
单请求成本

AI 性能测试真正困难的地方其实不是制造 1000 个并发。

而是：

制造 1000 个“像真实用户一样”的并发。

第四层：性能、质量、成本一起看

这是 AI 测试里非常容易遗漏的一层。

比如通过 Context 裁剪，把输入从：

20000 Tokens
↓
5000 Tokens

结果：

TTFT：

3.2s
↓
1.4s

性能提升非常明显。

但是评测结果：

回答正确率：

92%
↓
78%

这个优化还能上线吗？

通常不能。

反过来也一样。

如果通过增加 5 次 Agent Step，把准确率从 85% 提升到 91%，但：

平均耗时：

5s → 18s

Token：

3000 → 14000

单请求成本：

增长 4 倍

这个方案同样需要重新评估。

所以真正完整的 AI 性能测试应该同时看：

没有把性能、质量和成本放在一起，AI 性能测试其实只完成了一半。

六、测试工程师接下来真正需要补什么？

以前做性能测试，通常需要懂：

JMeter / Locust / k6
Linux
JVM
MySQL
Redis
MQ
微服务
监控
链路追踪

这些能力并没有过时。

但 AI 系统开始继续往上增加新的技术栈：

Token
Context Window
Streaming

TTFT
TPOT
ITL
TPS

GPU
KV Cache
Batching
Scheduler

Embedding
Vector Database
Rerank

RAG
Agent
Tool Calling
MCP

Tracing
LLM Observability

这也是为什么很多测试工程师第一次接 AI 项目，会突然产生一种感觉：

以前会做性能测试，现在好像又不会了。

问题不在于 JMeter 不会用了。

而是被测试对象变了。

以前面对的是：

API
+
数据库
+
缓存
+
微服务

现在面对的可能是：

API
+
RAG
+
LLM
+
GPU
+
Agent
+
Tool
+
第三方模型

测试工程师需要回答的问题，也从：

这个接口能不能达到 1000 QPS？

逐渐变成：

在真实 Prompt、真实 Token、真实 RAG、真实 Agent 调用链下，这套 AI 系统到底能稳定服务多少用户？

以及：

慢到底慢在哪里？

甚至还要继续追问：

如果把性能提高 30%，质量和成本发生了什么变化？

从这个角度看，AI 测试真正提高的并不是某一个工具的使用门槛。

它要求测试工程师开始理解模型推理、RAG、Agent、GPU、可观测性、容量规划，以及质量评测之间的关系。

而这可能也是未来普通测试工程师和 AI 测试工程师真正开始拉开差距的地方。

参考当前 NVIDIA 的 LLM Benchmarking 指标体系、vLLM 的生产监控指标，以及 MLCommons 新推出的端到端 RAG Benchmark，都可以看到同一个趋势：AI 性能评测正在从单模型、单接口指标，进一步走向真实工作负载和完整 AI 系统链路。

如果现在把公司正在使用的一个 RAG + Agent 系统交给你，你能不能真正回答这三个问题：

它到底能扛多少用户？慢到底慢在哪里？性能提升以后，质量和成本有没有一起失控？

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。

推荐阅读： juejin.cn/post/768035…

AI系统如何做性能测试？

目录