从 QPS 到 TT/FT,当 RAG 成为标配,AI 性能测试到底卡在哪?
关注 霍格沃兹测试学院公众号回复「资料」, 领取人工智能测试开发技术合集最近做 AI 应用的团队都有遇到一个困惑接口压测数据很好看 但用户体验却“卡”。QPS 上去了 可回答迟迟不出来。问题出在哪不是模型不行 而是测试视角还停留在传统时代。首字延迟为什么突然重要GPU 为什么成了性能主战场RAG 上线后测试难度为什么陡增目录QPS 还在涨用户却觉得慢TT / FT首字延迟为什么变成核心指标GPU 资源性能瓶颈已经不在 CPURAG 为什么成为测试重点RAG 专项测试的三个高频翻车点多模态解析最容易被忽略的风险参数不是调大小TOPK 背后的逻辑一、QPS 很高用户却说慢在传统性能测试里我们盯着QPSCPU内存平均响应时间但 AI 应用里用户体验并不完全由“总响应时间”决定。流式输出场景下用户感知的是多久开始出现第一个字。这就引出了两个指标TTTime To First TokenFTFirst Token Time它测的不是“答完多久” 而是“开始多久”。当 TT 从 600ms 变成 1.8s 用户会明显感觉“卡”。即使总耗时差别不大。这在传统系统里几乎不被关注。二、首字延迟到底发生在哪可以用一个简单流程看清楚TT 本质上测的是从“发送请求”到“收到第一个 Token”。这段时间包含Prompt 构建检索拼接模型首次推理GPU 调度其中任一环节变慢首字延迟都会上升。这也是为什么接口层压测正常但用户体感变差。三、GPU性能瓶颈已经换了地方AI 性能测试绕不开 GPU。你要关注的不再只是“CPU 有没有打满”而是显存是否溢出推理是否触发 OOMKV Cache 是否暴涨显卡温度是否持续高位举个典型场景服务器有 4 张 22GB 显卡共 88GB 显存。当并发提升时问题可能不是接口崩溃而是显存碎片化严重推理时间拉长。AI 性能曲线和传统 Web 服务完全不同。它更像持续计算过程而不是一次短事务调用。四、RAG 上线后测试复杂度翻倍以“生源地助学贷款 AI 助手”为例。如果模型是本地部署的它可能无法回答“助学贷款客服电话是多少”因为训练数据不是实时更新的。于是引入 RAG检索增强生成。流程变成模型不再只靠“记忆”。它开始“查资料”。但测试难度也随之增加。五、RAG 测试的三个常见翻车点1. 只测标准提问真实用户不会问“生源地助学贷款客服电话是多少”他们可能问“助学贷款电话多少”“怎么联系官方”“有没有客服电话”测试如果只覆盖标准问法召回质量根本无法验证。2. 参数不理解只会调数值常见参数TOPK相似度阈值Chunk 大小例如TOPK1 → 精准但容易漏召回 TOPK5 → 召回更多但噪声增加如果回答出现“答非所问” 问题可能不是模型而是检索策略。3. 多模态盲区知识库里有一份注册协议。关键条款是图片格式。如果系统没有图像解析能力它根本读不到那部分内容。测试需要关注是否支持图文解析OCR 是否正确图片是否被向量化否则系统表面完整实际存在盲区。六、AI 测试的结构性变化从这次内容可以看到一个清晰趋势性能指标从“总耗时”转向“首字延迟”性能瓶颈从 CPU 转向 GPU测试类型增加 RAG、提示词、工具链专项检索质量成为系统稳定性的关键变量多模态能力成为新的风险来源测试对象已经变了。如果测试方法不变 问题会反复出现。写在最后当一个系统开始流式输出使用 GPU 推理检索知识库解析图片测试就不能只盯着 QPS。AI 性能测试不是“传统压测模型”。它是一次工程结构的变化。而真正的难点从来不在模型本身。往往在首字延迟召回质量参数策略多模态盲区当这些点被看清很多“神秘问题”其实都能解释。关于我们霍格沃兹测试开发学社隶属于测吧北京科技有限公司是一个面向软件测试爱好者的技术交流社区。学社围绕现代软件测试工程体系展开内容涵盖软件测试入门、自动化测试、性能测试、接口测试、测试开发、全栈测试以及人工智能测试与 AI 在测试工程中的应用实践。我们关注测试工程能力的系统化建设包括 Python 自动化测试、Java 自动化测试、Web 与 App 自动化、持续集成与质量体系建设同时探索 AI 驱动的测试设计、用例生成、自动化执行与质量分析方法沉淀可复用、可落地的测试开发工程经验。在技术社区与工程实践之外学社还参与测试工程人才培养体系建设面向高校提供测试实训平台与实践支持组织开展“火焰杯” 软件测试相关技术赛事并探索以能力为导向的人才培养模式包括高校学员先学习、就业后付款的实践路径。同时学社结合真实行业需求为在职测试工程师与高潜学员提供名企大厂 1v1 私教服务用于个性化能力提升与工程实践指导。