最近两年很多测试团队都开始接触 AI 项目。以前测一个接口大家的思路很清楚加并发、压 QPS、看响应时间、错误率、CPU、内存再找性能拐点。但把这套方法直接搬到大模型、RAG、Agent 系统上很快就会遇到一个问题接口明明没报错CPU 也不高用户为什么还是觉得系统很慢比如两个 AI 系统系统 A8 秒后一次性返回完整答案系统 B800ms 开始输出持续生成 10 秒从传统“总响应时间”看B 更慢。但真实用户通常会觉得 B 更快。因为 AI 系统不是简单的“请求—响应”而是一个持续生成 Token 的过程。这也是 AI 性能测试真正发生变化的地方。传统系统主要测“请求有没有扛住”AI 系统还要测“生成过程有没有扛住”。2026 年 8 月MLCommons 发布了端到端 RAG Inference Benchmark。一个很值得测试工程师关注的变化是对于包含检索、模型和其他组件的 RAG 流水线单一的 Token/s 已经无法代表整个系统性能。这其实释放出了一个很明确的行业信号AI 性能测试正在从单接口压测走向全链路容量工程。目录一、AI 上线之后传统性能测试为什么突然不够用了二、AI 性能问题的本质已经从接口延迟变成推理链路延迟三、真正做 AI 性能测试要盯住哪些指标四、一个 RAG Agent 系统性能瓶颈到底会出现在哪里五、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 Search200msRerank600msPrompt 构建100msLLM 第一次调用3.2sTool 调用2.1sLLM 第二次调用5.3s其他开销500ms如果没有 Trace你看到的可能只有Response Time 12s然后大家开始调 GPU、换模型、扩机器。最后发现几乎没效果。因为真正慢的可能根本不是模型而是外部 Tool 或数据库。AI 系统的性能瓶颈很多时候不在模型而在模型前后的整条调用链。因此 RAG 性能测试和 Agent 性能测试必须做分段耗时和全链路 Trace不能只在网关入口统计一个总响应时间。三、真正做 AI 性能测试要盯住哪些指标AI 性能指标很多但没必要一开始就堆几十个。实际工程里可以先拆成四层。用户体验层TTFT 比总响应时间更值得关注第一个非常重要的指标叫TTFTTime To First Token。也就是用户发送请求以后需要等待多久才能看到第一个 Token。例如请求发送10:00:00.000首个 Token10:00:00.800那么TTFT 800ms对于 AI 客服、聊天机器人、Copilot 等流式场景TTFT 对用户体验影响非常明显。因为用户并不一定要求答案瞬间生成完。但很难忍受页面一直没有反应。另一个指标叫TPOTTime Per Output Token。它描述的是首 Token 出现之后后续 Token 的平均生成速度。vLLM 当前的 Benchmark 定义中TPOT 端到端耗时 - TTFT÷输出 Token 数 - 1同时还会统计 ITL也就是连续流式输出之间的间隔。需要注意的是不同 Benchmark 工具对这些指标的定义并没有完全统一真正做横向比较时要看计算方式而不能只看指标名字。([vLLM][3])所以用户侧至少应该同时观察TTFTTPOT / ITLEnd-to-End Latency如果TTFT 500msTPOT 300ms用户体验依然可能是开始回答挺快但一个字一个字往外蹦。吞吐层只看 QPS很容易误判大模型容量传统系统喜欢看100 QPS500 QPS1000 QPS但大模型里两个 Request 对 GPU 造成的压力可能完全不同。请求 AInput300 TokensOutput100 Tokens请求 BInput20000 TokensOutput3000 Tokens从 HTTP 层看都是 1 Request但从模型推理层看两次计算量完全不同。所以大模型性能测试还需要观察Token Throughput / Tokens Per Second。也就是系统每秒到底能处理或生成多少 Token。这也是为什么只用 QPS 衡量大模型服务能力很容易得出错误结论。资源层CPU 没满不代表 AI 系统还能扛AI 系统除了传统指标CPUMemoryLoadGCThreadNetwork还需要加入GPU UtilizationGPU MemoryKV CacheBatch SizeQueue LengthInput TokensOutput TokensContext Length尤其值得关注的是Queue Length 和 KV Cache。一个常见现象是20 并发 → TTFT 800ms50 并发 → TTFT 1.2s80 并发 → TTFT 2s100 并发 → TTFT 6s但此时CPU 40%Memory 55%如果仍然按照传统服务器监控方式判断很可能得出系统资源还很充足。实际情况却可能是GPU 已经接近饱和请求正在等待调度。vLLM 的生产指标里现在已经直接暴露了 Waiting Requests、端到端请求延迟、Inter-token Latency、Decode Time、Generation Tokens 以及 KV Cache 相关指标。这说明大模型性能监控正在逐渐从“主机级监控”转向“推理引擎级监控”。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 AmplificationToken 放大。用户可能只输入 300 Token。但 Agent 跑完一个完整任务内部已经消耗 15000 Token。并发增加 10 倍之后GPU 压力和模型费用也可能一起被放大。到了 Agent 系统性能测试实际上已经开始和成本测试发生交叉。四、一个 RAG Agent 系统性能瓶颈到底会出现在哪里来看一个更接近真实生产环境的例子。假设公司上线了一套企业 AI 知识库图片现在逐步提高并发。假设得到这样一组测试数据。50 并发TTFT P951.0sTPOT P9540msRetrieval P95180msRerank P95300msGPU65%Queue基本为 0系统正常。150 并发TTFT P953.5sTPOT P9545msRetrieval P95210msRerank P95320msGPU93%Queue明显增加这个结果非常值得注意。TPOT 几乎没怎么变TTFT 却从 1 秒涨到了 3.5 秒。说明模型一旦真正开始 Decode生成速度没有明显恶化。真正的问题更可能发生在请求排队SchedulerPrefill250 并发TTFT P959.5sTPOT P9560msGPU98%Queue持续上涨Timeout4%到这里就可以认为系统进入了明显的饱和区。真正应该得到的测试结论不是系统最大可以支持 250 并发。而应该是当并发超过约 150 后TTFT 开始明显恶化到 250 并发时排队持续增长并出现超时因此当前可接受容量应结合 TTFT SLO 定义在饱和点之前。这是两种完全不同的性能测试思维。性能容量不是“系统什么时候挂”而是“用户体验什么时候开始不可接受”。五、AI 性能测试真正应该怎么落地真正落地时不建议一上来就对整个 Agent 系统打 1000 并发。更合理的方法是分四层压。第一层先测模型裸性能链路尽量简单Load Generator↓LLM Serving测试不同Input TokenOutput TokenConcurrencyRequest Rate观察TTFTTPOT / ITLTPSRequest ThroughputGPUKV CacheQueue这一层解决的问题是模型服务本身到底有多少容量。第二层再把 RAG 加回来加入EmbeddingVector DBTopKRerankPrompt然后测试不同 Context Length1K4K8K16K32K观察Retrieval LatencyRerank LatencyPrompt TokensTTFTGPU因为上下文变长以后不只是 Token 成本会上涨Prefill 压力也会增加。这一阶段真正要回答的是知识库到底给模型塞多少内容性能和效果最平衡第三层最后测 Agent 完整任务不要只用你好作为压测 Prompt。真实业务应该按照生产流量准备不同任务。例如简单问答 40%RAG 查询 30%数据库查询 15%多 Tool Agent 10%长文本分析 5%再根据真实分布生成流量。重点记录任务完成时间Agent StepsLLM CallsTool CallsRetryToken Usage成功率单请求成本AI 性能测试真正困难的地方其实不是制造 1000 个并发。而是制造 1000 个“像真实用户一样”的并发。第四层性能、质量、成本一起看这是 AI 测试里非常容易遗漏的一层。比如通过 Context 裁剪把输入从20000 Tokens↓5000 Tokens结果TTFT3.2s↓1.4s性能提升非常明显。但是评测结果回答正确率92%↓78%这个优化还能上线吗通常不能。反过来也一样。如果通过增加 5 次 Agent Step把准确率从 85% 提升到 91%但平均耗时5s → 18sToken3000 → 14000单请求成本增长 4 倍这个方案同样需要重新评估。所以真正完整的 AI 性能测试应该同时看图片没有把性能、质量和成本放在一起AI 性能测试其实只完成了一半。六、测试工程师接下来真正需要补什么以前做性能测试通常需要懂JMeter / Locust / k6LinuxJVMMySQLRedisMQ微服务监控链路追踪这些能力并没有过时。但 AI 系统开始继续往上增加新的技术栈TokenContext WindowStreamingTTFTTPOTITLTPSGPUKV CacheBatchingSchedulerEmbeddingVector DatabaseRerankRAGAgentTool CallingMCPTracingLLM Observability这也是为什么很多测试工程师第一次接 AI 项目会突然产生一种感觉以前会做性能测试现在好像又不会了。问题不在于 JMeter 不会用了。而是被测试对象变了。以前面对的是API数据库缓存微服务现在面对的可能是APIRAGLLMGPUAgentTool第三方模型测试工程师需要回答的问题也从这个接口能不能达到 1000 QPS逐渐变成在真实 Prompt、真实 Token、真实 RAG、真实 Agent 调用链下这套 AI 系统到底能稳定服务多少用户以及慢到底慢在哪里甚至还要继续追问如果把性能提高 30%质量和成本发生了什么变化从这个角度看AI 测试真正提高的并不是某一个工具的使用门槛。它要求测试工程师开始理解模型推理、RAG、Agent、GPU、可观测性、容量规划以及质量评测之间的关系。而这可能也是未来普通测试工程师和 AI 测试工程师真正开始拉开差距的地方。参考当前 NVIDIA 的 LLM Benchmarking 指标体系、vLLM 的生产监控指标以及 MLCommons 新推出的端到端 RAG Benchmark都可以看到同一个趋势AI 性能评测正在从单模型、单接口指标进一步走向真实工作负载和完整 AI 系统链路。如果现在把公司正在使用的一个 RAG Agent 系统交给你你能不能真正回答这三个问题它到底能扛多少用户慢到底慢在哪里性能提升以后质量和成本有没有一起失控