过去做性能测试，我们最关心的通常是：

接口能不能扛住并发？ RT 有没有超过阈值？ TPS/QPS 能不能达到目标？ CPU、内存、数据库连接池有没有打满？

但到了 AI 系统，尤其是大模型应用、RAG 知识库、AI Agent、多模态问答系统，性能测试就不能再只套传统那一套了。

因为 AI 系统的慢，不一定慢在接口。 它可能慢在模型生成第一个 Token。 可能慢在检索召回。 可能慢在工具调用。 可能慢在上下文太长。 也可能慢在队列排队、GPU KV Cache、流式输出、重试机制和成本控制。

所以，AI 系统性能测试的核心，不是问一句：

“

“这个接口能抗多少 QPS？”

而是要问：

“

“在真实业务场景下，用户多久能看到第一个结果？完整回答多久生成？并发上来后 Token 输出是否稳定？系统成本是否可控？质量有没有明显下降？”

这才是 AI 系统性能测试和传统系统压测最大的区别。

---

阅读目录

一、AI 系统性能测试和传统压测有什么不同 二、AI 系统性能测试到底测什么 三、核心指标：别只看 RT，要看 TTFT、TPOT、TPS 四、不同 AI 系统的压测重点 五、AI 性能测试的整体链路怎么设计 六、压测数据怎么准备 七、监控指标怎么埋 八、常见性能瓶颈与优化方向 九、一个可落地的 AI 性能测试流程

---

一、AI 系统性能测试，为什么不能只看 QPS？

传统系统性能测试，本质上是在验证服务端资源承载能力。

比如：

用户登录接口 下单接口 支付接口 查询接口 报表接口

这些接口的特点是：请求进来，服务端执行一段确定性的逻辑，然后返回结果。

但 AI 系统不一样。

一个 AI 问答请求进来后，背后可能经历这些步骤：

这个链路里，任何一层都可能成为性能瓶颈。

更关键的是，AI 系统的响应不是一次性返回，而是经常采用流式输出。

用户体感上的“快”，并不是完整响应耗时短，而是：

第一个 Token 出来得快不快； 后续 Token 输出是否顺滑； 回答中途会不会卡顿； 完整生成时间是否可接受； 并发上来后是否排队严重。

所以，AI 系统性能测试要从“接口压测”升级成“端到端链路压测”。

---

二、AI 系统性能测试到底测什么？

AI 系统性能测试，至少要覆盖四层。

1. 接口服务层

这一层和传统性能测试接近，主要关注：

接口 RT QPS / RPS 错误率 超时率 网关限流 鉴权耗时 连接池 线程池 CPU / 内存 日志写入 消息队列堆积

但这只是最外层。

如果只测这一层，很容易得出一个错误结论：

“接口很快，系统没问题。”

实际上接口可能只是很快把请求转发给模型服务，真正的慢在后面。

---

2. 模型推理层

这是 AI 系统性能测试最核心的一层。

大模型推理不能只看接口耗时，还要看 Token 级指标。NVIDIA 的 LLM 推理性能文档中就把 TTFT、ITL、吞吐等作为大模型推理性能的重要指标；OpenAI 的延迟优化文档也强调，模型处理 Token 的速度通常会用 TPM 或 TPS 来衡量。

重点指标包括：

指标	含义	重点关注
TTFT	Time To First Token，第一个 Token 返回耗时	用户多久看到系统开始响应
TPOT / ITL	每个输出 Token 的平均生成耗时	流式输出是否顺滑
TPS	Tokens Per Second，每秒生成 Token 数	模型整体吞吐能力
E2E Latency	端到端完整响应耗时	一次请求完整完成时间
Input Tokens	输入 Token 数	Prompt、上下文、历史对话长度
Output Tokens	输出 Token 数	生成内容长度
Queue Time	请求排队时间	并发下是否堵塞
Timeout Rate	超时率	高峰期稳定性

其中 TTFT 很关键。它通常包含排队、预填充、网络等耗时；Prompt 越长，首 Token 出来的时间往往越容易变长。

---

3. RAG 检索层

如果你的 AI 系统接入了知识库，就不能只压模型接口。

RAG 系统至少要测这些环节：

Embedding 生成耗时 向量检索耗时 关键词检索耗时 混合检索耗时 Rerank 重排耗时 上下文拼接耗时 TopK 数量变化对性能的影响 文档数量增长后的查询耗时 召回内容过多导致的 Prompt 变长问题

很多 RAG 系统上线后变慢，不是模型本身变慢，而是：

知识库越来越大； TopK 设置过高； Rerank 模型耗时过长； 拼接上下文太多； 历史对话没有裁剪； 检索结果质量不稳定导致模型生成更长。

所以 RAG 性能测试不能只看“问答接口 RT”，要把检索链路拆开测。

---

4. Agent 工具调用层

如果系统是 AI Agent，性能测试会更复杂。

因为 Agent 不只是“问一次模型，返回一次答案”，它可能会循环执行：

模型思考 选择工具 调用接口 读取结果 再次思考 再次调用工具 最终输出答案

Agent 的链路可能是这样的：

Agent 性能测试要重点关注：

单次任务平均工具调用次数 工具调用成功率 工具调用平均耗时 模型循环次数 最大执行步数 任务完成时间 中间步骤失败率 重试次数 外部 API 超时率 最终成功率

很多 Agent 系统的慢，不是模型慢，而是工具链慢。

比如：

一次任务调用 8 个工具； 每个工具平均 1 秒； 中间再重试 2 次； 最终任务耗时自然会被拉长。

---

三、AI 系统性能测试的核心指标

传统压测里，我们常看：

QPS TPS RT P90 / P95 / P99 错误率 资源利用率

AI 系统当然也要看，但还不够。

AI 系统至少要增加下面这些指标。

---

1. TTFT：第一个 Token 返回时间

TTFT 决定了用户是否觉得系统“有反应”。

比如两个系统：

系统 A：1 秒开始输出，10 秒完整输出 系统 B：6 秒才开始输出，8 秒完整输出

从完整耗时看，B 更快。 但从用户体感看，A 可能更好。

因为用户更怕“没反应”。

所以，AI 应用尤其是聊天机器人、客服助手、代码助手、智能问答，一定要单独监控 TTFT。

建议指标：

TTFT 平均值 TTFT P90 TTFT P95 TTFT P99 高并发下 TTFT 增长曲线 长 Prompt 下 TTFT 增长曲线

---

2. TPOT / ITL：Token 输出是否顺滑

ITL 通常表示相邻 Token 之间的时间间隔，也可以理解成每个输出 Token 的生成耗时。NVIDIA 文档中也把 ITL 定义为连续 Token 之间的平均时间间隔。

这个指标影响的是“流式输出体验”。

如果 TTFT 很快，但后续输出一卡一卡的，用户体验也不好。

比如：

第一个字 1 秒出来； 后面每隔 2 秒吐几个字； 看起来就像系统卡住了。

建议指标：

平均 TPOT / ITL P95 TPOT / ITL 输出 Token 抖动情况 不同输出长度下的生成速度 不同并发下的生成速度

---

3. TPS：Token 吞吐量

TPS 不是传统意义上的事务数，而是 Token 处理能力。

这里要区分：

Input TPS：每秒处理多少输入 Token Output TPS：每秒生成多少输出 Token Total TPS：整体 Token 吞吐能力

vLLM 的监控指标里也会关注 prompt tokens processed per second 和 generation tokens per second，这类指标可以帮助判断推理服务真实吞吐能力。

为什么 TPS 很重要？

因为 AI 系统的压力不只来自请求数，还来自 Token 数。

同样是 100 个请求：

每个请求 200 Token 输入，500 Token 输出； 和每个请求 8000 Token 输入，3000 Token 输出；

对系统压力完全不是一个量级。

所以 AI 压测不能只说“100 并发”，还要说明：

平均输入 Token 数是多少； 平均输出 Token 数是多少； 是否流式输出； 上下文长度是多少； 是否包含工具调用； 是否包含 RAG 检索。

---

4. E2E Latency：端到端完整耗时

端到端耗时仍然重要。

但 AI 系统的 E2E Latency 要拆开看：

用户请求进入系统 Prompt 拼装 检索召回 Rerank 模型首 Token 模型完整输出 工具调用 结果后处理 内容安全审核 日志落库 返回前端

只有把链路拆开，才能定位到底是哪一段慢。

---

5. 成本指标：AI 系统性能测试必须看钱

AI 系统还有一个传统系统不明显的问题：成本。

一次请求不是简单消耗 CPU，而是消耗：

模型调用费用 输入 Token 成本 输出 Token 成本 Embedding 成本 Rerank 成本 向量数据库资源 GPU 资源 缓存资源 外部工具 API 成本

所以 AI 性能测试还要看：

单请求平均成本 千次请求成本 每用户会话成本 高峰期小时成本 失败请求成本 重试带来的额外成本 长上下文带来的成本增长

否则可能出现一种情况：

性能指标看起来没问题，但成本已经不可接受。

---

四、不同 AI 系统，压测重点不一样

AI 系统不是一种系统，而是一类系统。

不同类型的 AI 应用，性能测试重点完全不同。

---

1. 普通大模型问答系统

典型场景：

智能客服 AI 助手 知识问答 代码解释 文本生成

重点测试：

TTFT TPOT 完整响应时间 并发用户数 输入 Token 长度 输出 Token 长度 上下文轮数 流式输出稳定性 超时率 限流策略

测试重点不是“接口能不能通”，而是“用户是否觉得它快”。

---

2. RAG 知识库系统

典型场景：

企业知识库 文档问答 制度查询 客服知识库 合同问答 技术文档助手

重点测试：

检索耗时 Embedding 耗时 向量库查询耗时 Rerank 耗时 TopK 对耗时的影响 文档规模增长后的性能变化 上下文拼接后 Prompt Token 增长 答案生成耗时 召回质量和性能之间的平衡

RAG 压测不能只压问答接口，还要压知识库规模。

比如：

1 万文档 10 万文档 100 万文档 不同 chunk 大小 不同 TopK 是否启用 Rerank 是否启用混合检索

这些都会影响最终性能。

---

3. AI Agent 系统

典型场景：

自动化测试 Agent 运维 Agent 数据分析 Agent 代码生成 Agent 办公自动化 Agent 浏览器操作 Agent

重点测试：

任务完成时间 平均执行步数 最大执行步数 工具调用次数 工具调用耗时 工具失败率 重试次数 循环失控率 外部系统依赖耗时 任务成功率

Agent 系统性能测试最怕只看“接口返回耗时”。

因为有些 Agent 是异步任务，接口可能很快返回 task_id，但真正任务执行可能要几十秒甚至几分钟。

所以 Agent 要测的是“任务生命周期性能”。

---

4. 多模态 AI 系统

典型场景：

图片问答 截图分析 视频理解 OCR + 大模型 图文审核 视觉质检

重点测试：

图片上传耗时 图片预处理耗时 OCR 耗时 视觉模型推理耗时 多模态模型首 Token 时间 图片大小对性能影响 分辨率对性能影响 批量图片处理能力 多模态输入 Token 成本 端到端耗时

多模态系统经常不是文本模型慢，而是图片处理链路慢。

比如：

图片压缩 格式转换 OCR 目标检测 视觉编码 文件存储 对象存储读取 安全审核

这些都要纳入性能测试范围。

---

五、AI 系统性能测试怎么设计场景？

AI 性能测试场景不能只写：

100 并发，持续 10 分钟。

这太粗了。

应该按真实业务负载设计。

---

1. 按输入长度分层

AI 请求的压力，很大程度取决于输入 Token。

可以分成：

短输入：100 - 500 Token 中输入：500 - 2000 Token 长输入：2000 - 8000 Token 超长输入：8000 Token 以上

不同长度要分别压测。

因为短 Prompt 快，不代表长 Prompt 也快。

---

2. 按输出长度分层

输出越长，模型生成时间越久，成本也越高。

可以分成：

短回答：100 - 300 Token 中回答：300 - 1000 Token 长回答：1000 - 3000 Token 报告型回答：3000 Token 以上

很多系统平时问答没问题，一到“生成报告”“总结长文档”“生成测试用例”，性能就明显下降。

原因就是输出 Token 变长了。

---

3. 按业务任务分层

不要只用随机问题压测，要用真实任务。

比如测试 AI 测试平台，可以设计这些场景：

需求文档生成测试点 接口文档生成接口用例 图片页面生成测试用例 错误日志分析根因 根据用户故事生成自动化脚本 根据缺陷描述生成复现步骤 基于知识库回答测试规范问题 调用工具查询接口返回并分析结果

每种任务的链路不同，性能表现也不同。

---

4. 按链路复杂度分层

可以把 AI 请求分成四类：

类型	链路	示例
L1	只调用模型	普通问答、文本改写
L2	模型 + RAG	知识库问答、文档问答
L3	模型 + 工具	查询订单、调用接口、执行脚本
L4	模型 + RAG + 多工具 + 多轮推理	Agent 自动完成任务

压测时一定要区分。

否则你可能用 L1 场景压出来一个很好看的数据，然后上线跑 L4 任务直接崩。

---

六、AI 性能测试数据怎么准备？

AI 压测数据不能随便写几句“你好”“介绍一下公司”。

因为这种数据太短、太简单、太不真实。

建议准备四类数据。

---

1. 真实业务问题集

从线上日志、客服记录、用户提问、内部工单中抽样。

注意要脱敏。

例如：

用户真实问题 历史客服问答 真实需求文档 真实接口文档 真实缺陷描述 真实日志片段 真实知识库文档

真实数据的价值在于：它能暴露真实性能问题。

---

2. 长上下文数据

专门构造长 Prompt。

比如：

长需求文档 长接口文档 长会议纪要 长日志文件 长合同文本 多轮历史对话

很多 AI 系统在短文本下表现很好，但长文本下 TTFT 急剧上升。

---

3. 高复杂任务数据

用于压测 Agent。

比如：

需要 3 次工具调用才能完成的任务 需要查询多个系统的任务 需要先检索再分析的任务 需要生成结构化结果的任务 需要失败重试的任务

这类数据能测出 Agent 的真实瓶颈。

---

4. 异常数据

性能测试不能只测正常请求。

还要测：

空输入 超长输入 乱码输入 大量特殊符号 图片过大 文件格式异常 检索无结果 工具调用失败 模型返回超长 模型返回不完整 用户连续快速提问

AI 系统的稳定性，往往是在异常输入下暴露问题。

---

七、AI 性能测试监控怎么做？

AI 系统性能测试，如果没有监控，压测结果基本没什么价值。

因为你只能看到“慢了”，但不知道为什么慢。

建议监控分为五层。

---

1. 应用层监控

关注：

接口 RT QPS / RPS 错误率 超时率 限流次数 重试次数 请求队列长度 连接池使用率 线程池使用率 日志写入耗时

---

2. 模型层监控

关注：

TTFT TPOT / ITL Input Tokens Output Tokens Tokens Per Second 请求排队时间 Batch Size KV Cache 使用率 模型服务错误率 模型服务超时率 流式输出中断率

---

3. RAG 层监控

关注：

Embedding 耗时 向量检索耗时 关键词检索耗时 Rerank 耗时 TopK 数量 召回文档数量 上下文拼接 Token 数 向量库 CPU / 内存 / IO 索引查询耗时 缓存命中率

---

4. Agent 层监控

关注：

任务总耗时 执行步骤数 工具调用次数 工具平均耗时 工具失败率 模型调用次数 循环次数 最大步数触发次数 任务成功率 任务取消率

---

5. 资源与成本监控

关注：

CPU 内存 GPU 利用率 显存使用率 网络 IO 磁盘 IO 数据库连接 Redis 命中率 消息队列堆积 单请求 Token 成本 单位时间模型调用成本 失败请求成本

AI 系统性能测试最好把“性能”和“成本”放在一张图里看。

因为只追求快，可能成本爆炸。

---

八、一个 AI 性能测试指标体系

可以参考下面这个指标体系设计。

---

九、AI 系统常见性能瓶颈

1. Prompt 太长

很多系统慢，不是模型不行，而是 Prompt 拼得太长。

常见原因：

历史对话无限追加 RAG 召回内容过多 系统提示词太复杂 把无关字段都塞给模型 没有做上下文裁剪 没有做摘要压缩

优化方向：

限制历史轮数 长对话摘要化 RAG 结果裁剪 减少无用 system prompt 按任务动态拼 Prompt 对上下文做 Token 预算

---

2. RAG 检索链路太重

常见原因：

TopK 设置过大 Rerank 模型太慢 向量库索引不合理 文档 chunk 过碎 混合检索没有缓存 每次请求都重新 Embedding 知识库规模增长后没有重新评估

优化方向：

调整 chunk 大小 优化 TopK 增加缓存 异步预处理 Embedding 优化索引 按业务场景拆知识库 只对高价值候选做 Rerank

---

3. Agent 工具调用太多

常见原因：

模型规划不稳定 工具描述不清晰 工具粒度太细 每一步都重新调用模型 工具失败后无限重试 缺少最大步数限制 缺少任务中断机制

优化方向：

合并工具能力 优化工具描述 限制最大执行步数 增加工具调用缓存 失败快速返回 增加任务状态机 对高频任务做模板化流程

---

4. 流式输出看似快，实际后端压力大

流式输出能改善用户体感，但不代表系统压力小。

因为连接保持时间更长，服务端需要维护更多长连接。

需要关注：

连接数 连接保持时间 SSE / WebSocket 稳定性 中途断连率 客户端消费速度 服务端缓冲区 网关超时配置

---

5. 重试机制放大流量

AI 系统经常会有重试：

模型超时重试 工具失败重试 检索失败重试 网络异常重试 内容审核失败后重试

如果重试策略不合理，高峰期可能形成流量放大。

比如原始 QPS 是 100，失败率 20%，每次失败重试 2 次，实际后端压力可能远高于预期。

所以压测时一定要打开真实重试策略。

---

十、AI 性能测试怎么落地？

可以按这个流程来做。

---

第一步：明确业务场景

先不要急着写压测脚本。

先问清楚：

这个 AI 系统给谁用？ 核心任务是什么？ 用户一次会话大概问几轮？ 输入内容一般多长？ 输出内容一般多长？ 是否需要 RAG？ 是否需要工具调用？ 是否需要多模态？ 是否需要流式输出？ 高峰期并发是多少？ 用户能接受多长时间返回？

如果这些不清楚，压测指标就没有意义。

---

第二步：拆分调用链路

把一次 AI 请求拆开。

例如 RAG 问答系统：

用户请求 鉴权 Prompt 拼装 Embedding 向量检索 Rerank 上下文拼接 模型调用 流式返回 日志记录

每一段都要有耗时。

否则压测报告只能写一句：

“接口 P95 = 8.5 秒。”

但这句话无法指导优化。

---

第三步：定义性能目标

AI 系统性能目标要分层定义。

例如：

指标	目标示例
TTFT P95	小于 2 秒
完整响应 P95	小于 15 秒
超时率	小于 1%
工具调用成功率	大于 99%
RAG 检索 P95	小于 800ms
单请求平均成本	不超过预算
流式输出中断率	小于 0.5%

注意：这些数值不是通用标准，要根据业务场景定。

客服问答和报告生成，对响应时间的要求完全不同。

---

第四步：准备压测数据集

建议至少准备三套数据：

基准数据集：正常问题 长文本数据集：长 Prompt、长文档 复杂任务数据集：RAG、工具调用、Agent 多步任务

每条数据最好记录：

问题类型 输入 Token 数 预期输出长度 是否需要检索 是否需要工具 是否多轮对话 是否流式输出 任务复杂度等级

这样压测结果才能按场景分析。

---

第五步：执行基准测试

先单用户、低并发跑。

目的不是压垮系统，而是拿到基线。

要记录：

平均 TTFT 平均 TPOT 平均完整耗时 平均输入 Token 平均输出 Token 平均检索耗时 平均工具调用耗时 单请求成本

基准测试很重要。

没有基准，就不知道后面性能下降是从哪里开始的。

---

第六步：执行阶梯压测

不要一上来就 1000 并发。

建议阶梯式增加：

1 并发 5 并发 10 并发 20 并发 50 并发 100 并发 200 并发

每个阶段观察：

TTFT 是否突然升高 P95/P99 是否恶化 队列是否堆积 GPU 显存是否接近上限 RAG 检索是否变慢 工具调用是否超时 错误率是否上升 成本是否线性增长

AI 系统压测特别要看拐点。

很多系统在低并发下很稳定，但到某个并发点之后，TTFT 会突然变长。

这个点就是容量边界。

---

第七步：执行稳定性测试

稳定性测试不是看峰值，而是看长时间运行。

比如：

持续 2 小时 持续 6 小时 持续 12 小时 持续 24 小时

观察：

是否内存泄漏 连接是否释放 队列是否持续堆积 缓存是否失效 日志是否打爆磁盘 Token 成本是否异常 模型服务是否出现周期性抖动 向量库是否出现查询变慢 工具 API 是否触发限流

AI 系统的稳定性问题，经常不是一开始就暴露，而是运行一段时间后才出现。

---

十一、压测脚本要注意什么？

如果是普通 HTTP 接口，可以用 JMeter、Locust、k6。

但 AI 系统压测要额外处理：

流式响应 Token 统计 首 Token 时间 完整响应时间 请求上下文 多轮会话 RAG 参数 工具调用结果 失败重试 成本统计

伪代码可以这样设计：

import time
import requests

def test_ai_stream_api(payload):
    start_time = time.time()
    first_token_time = None
    output_text = ""

    response = requests.post(
        "https://your-ai-api.com/chat",
        json=payload,
        stream=True,
        timeout=60
    )

    for chunk in response.iter_lines():
        if chunk:
            now = time.time()

            if first_token_time isNone:
                first_token_time = now

            output_text += chunk.decode("utf-8", errors="ignore")

    end_time = time.time()

    return {
        "ttft": first_token_time - start_time if first_token_time elseNone,
        "e2e_latency": end_time - start_time,
        "output_length": len(output_text),
        "success": response.status_code == 200
    }

这个脚本只是示意，真实项目里还要增加：

Token 计算 异常处理 并发模型 统计聚合 P95/P99 日志上报 请求数据集管理 结果落库

---

十二、AI 性能测试报告应该怎么写？

AI 系统性能测试报告，不建议只写传统格式。

建议包含这些部分：

1. 测试对象

系统架构 模型类型 是否流式输出 是否使用 RAG 是否使用 Agent 是否调用外部工具 是否多模态输入

---

2. 测试场景

普通问答 知识库问答 长文本总结 测试用例生成 工具调用任务 多轮对话 异常输入 高并发请求

---

3. 负载模型

并发用户数 请求速率 输入 Token 分布 输出 Token 分布 会话轮数 任务复杂度 持续时间 压测数据来源

---

4. 核心指标

TTFT TPOT / ITL TPS 完整响应时间 P90 / P95 / P99 错误率 超时率 任务成功率 工具调用耗时 RAG 检索耗时 资源使用率 单请求成本

---

5. 瓶颈分析

瓶颈在哪一层 什么时候开始出现 哪个指标先恶化 是否和 Token 长度相关 是否和检索有关 是否和工具调用有关 是否和 GPU / 队列有关 是否存在成本异常

---

6. 优化建议

Prompt 优化 上下文裁剪 RAG 参数调整 缓存策略 模型选择 推理服务扩容 工具调用优化 异步化处理 限流与降级 成本控制策略

---

十三、AI 系统性能测试最容易踩的坑

坑一：只用短问题压测

比如全部使用：

“你好” “介绍一下你自己” “帮我写一段话”

这种压测没有意义。

真实用户不会只问这种问题。

---

坑二：只看平均响应时间

AI 系统一定要看 P95 和 P99。

平均值很好看，不代表高峰期用户体验好。

尤其是模型服务，尾延迟经常很明显。

---

坑三：只压模型，不压完整链路

模型单独压测很快，不代表业务系统快。

因为线上链路还有：

检索 Rerank 权限过滤 内容审核 工具调用 日志记录 网关转发 数据库查询

性能测试必须覆盖完整链路。

---

坑四：不统计 Token

不统计 Token，就无法解释性能变化。

一次请求慢，到底是因为并发高，还是因为输入太长，还是输出太长？

没有 Token 统计，就说不清楚。

---

坑五：不测成本

AI 系统不是只要能扛住就行。

有些方案性能很好，但成本高到无法上线。

性能测试必须带上成本视角。

---

十四、结尾

AI 系统性能测试，已经不是传统意义上的接口压测。

它要同时回答四个问题：

第一，用户体验是否足够快？ 重点看 TTFT、流式输出、完整响应时间。

第二，系统链路是否稳定？ 重点看 RAG、Agent、工具调用、重试、超时和错误率。

第三，资源容量是否清楚？ 重点看并发、队列、Token 吞吐、GPU/CPU/内存和缓存。

第四，成本是否可控？ 重点看输入 Token、输出 Token、模型调用次数、失败重试和单请求成本。

真正成熟的 AI 性能测试，不是压出一个漂亮的 QPS 数字，而是建立一套可解释、可定位、可复测、可优化的性能基线。

因为 AI 系统的性能问题，表面看是“回答慢”，本质上往往是：

上下文太长； 检索链路太重； 工具调用太多； 模型排队太久； Token 生成不稳； 成本控制不足； 缺少端到端观测。

所以，测试 AI 系统性能时，不能只问：

“能扛多少并发？”

而要问：

“在真实业务任务下，它能不能稳定、及时、可控地完成一次智能响应？”

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

​