4. 性能验收量化标准
适用场景
本章适用于以下场景：
- AI Agent 完成开发后，首次上线前的性能基准验收。
- 核心推理链路或工具调用逻辑发生重构后的回归性能验证。
- 负载模型（如从单轮对话切换到多轮记忆）变更后的容量摸底。
- 部署环境（如从GPU迁移到CPU集群）变更时的性能确认。
注意： 如果 Agent 涉及实时语音流或高并发 RPA，必须在生产环境副本或压测环境中执行，避免影响线上真实用户。
前置条件
- 环境隔离： 专用的压测服务器群组（不能与线上混布），网络带宽至少为生产环境的1.2倍。
- 测试工具就绪： 部署 JMeter / Locust / k6 中的至少一种，并已配置 Agent 的 HTTP/gRPC 端点。
- 监控组件： Prometheus + Node Exporter + cAdvisor 已采集基础资源指标；或同等级 APM 工具。
- 基线数据： 产品需求文档中声明的 SLA 目标（例如 P95 响应时间 ≤ 2 s）。
- 测试数据集： 覆盖常见用户 Query（如简单问答、复杂多轮推理、工具调用），数量不少于 10,000 条。
操作步骤
| 步骤 | 操作说明 | 关键检查点 |
|---|---|---|
| 1. 定义性能指标 | 明确四个维度的基准值：响应时间（均值/P50/P95/P99）、吞吐量（QPS/TPS）、并发能力（最大稳定并发数）、资源消耗基线（CPU、内存、GPU 显存、磁盘IO）。 | 指标必须可量化，如“P95 ≤ 1.5 s”而非“性能良好”。 |
| 2. 配置压测场景 | 编写测试脚本：模拟用户会话流程，包含 Token 输入、Agent思考、工具调用、结果返回。设置渐增并发策略：从 1 → 10 → 50 → 100 → 200（根据预期承载）。 | 每个并发阶段需稳定运行至少 5 分钟。 |
| 3. 执行压测并收集数据 | 依次执行无负载预热（1 min）、各阶段压测（每个 5 min）。后台自动记录响应时间直方图、吞吐量、错误率以及服务器 CPU/内存/带宽。 | 注意观察是否出现请求堆积或 OOM。 |
| 4. 提取基线并对比 | 将采集到的 P95 响应时间、平均吞吐量、最大并发数、资源占用率与 SLA 阈值对比，记录是否达标。 | 若资源消耗出现非线性增长（如 2×并发 → 3×内存），需标记为风险。 |
| 5. 生成验收报告 | 输出结构化报告（JSON/YAML），包含各维度数值、与基线的差距、超限情况、截图或日志摘要。 | 报告需有 QA 与开发双方签字。 |
高效实践： 可使用自动化流水线，将步骤2~4封装为 Jenkins 任务，每次代码合并自动触发性能回归，输出“PASS/FAIL”标记。
输入输出物
| 类别 | 输入物 | 输出物 |
|---|---|---|
| 文档 | 产品 SLA 文档 (包含性能阈值)、压测计划 | 性能验收报告 (含基线对比表) |
| 脚本 | JMeter .jmx / Locustfile.py / k6 .js | 压测日志 (CSV)、错误日志 |
| 数据 | 测试 Query 数据集 (JSONL)、Mock 工具响应 | 原始监控数据 (Prometheus 时间序列) |
| 配置 | 压测环境配置 (YAML)、监控告警规则 | 最终基线 JSON 快照 |
责任边界
- QA / 测试工程师： 设计压测场景、执行验收、输出报告、标注异常点。
- 开发工程师： 提供工具调用 Mock、修复基线超限的代码问题、优化推理逻辑。
- 运维 / SRE： 确保压测环境资源充足、安装并维护监控组件、导出资源消耗基线。
- 产品经理： 审定 SLA 阈值是否合理（需考虑成本与体验平衡）。
记录材料
至少保留以下字段的记录（建议以 CSV 或结构化日志形式持久化）：
TimeStamp, Concurrency, AvgRT_ms, P50_ms, P95_ms, P99_ms, QPS, ErrorRate(%), CPU_avg(%), Mem_avg(%), GPU_util(%), DiskIO_MBps
2025-04-01T10:00:00Z, 50, 320, 280, 480, 1020, 85.2, 0.12, 62.3, 47.1, 56.8, 12.4
2025-04-01T10:05:00Z, 100, 450, 390, 720, 2100, 160.1, 0.45, 78.6, 61.5, 78.2, 21.0
记录时务必带上测试环境标签（如 "staging-v2"），防止多个版本混合导致基线偏移无法追溯。
异常处理
- 响应时间超阈值： 先检查网络延迟（ping / traceroute），再分析 Agent 内各阶段的耗时（Tokenize / LLM推理 / 工具调用 / 反序列化）。
- 吞吐量不达标： 确认是否有线程 / 协程数量限制、数据库连接池耗尽、或 LLM 推理服务本身限流。
- 并发时出现 OOM / 内存泄漏： 使用 heap dump 或 memory profiler 定位（如 pprof）。立即停止压测，修复后重新执行。
- 工具异常（压测脚本错误）： 检查 Mock 服务是否正常响应；若工具返回 500，需修正测试数据。
- 资源消耗基线波动过大： 同场景重复执行 3 次取均值，若波动 > 15% 则需排查进程间资源争抢。
验收标准
| 指标维度 | 合格区间 | 警告区间 | 不合格 |
|---|---|---|---|
| P95 响应时间 | ≤ 2s | 2s ~ 3s | > 3s |
| 平均吞吐量 (QPS) | ≥ 100 | 50 ~ 100 | < 50 |
| 最大稳定并发数 | ≥ 200 且无错误 | 200 并发下错误率 ≤ 1% | < 200 或错误率 > 1% |
| CPU 占用 (均值) | ≤ 70% | 70% ~ 85% | > 85% 且持续 3 min |
| 内存占用 (均值) | ≤ 70% 可用内存 | 70% ~ 85% | > 85% 或 OOM |
| GPU 显存占用 | ≤ 80% | 80% ~ 90% | > 90% 或显存溢出 |
所有维度需同时满足“合格区间”才算通过验收；任何维度落在“不合格”区间，则整体验收不通过，必须打回优化。
警告： 资源消耗基线中的“CPU 占用”必须区分用户态 / 内核态 / I/O Wait；若 I/O Wait 占比 > 10%，即使总 CPU 未超 70% 也应视为风险，因为磁盘可能是瓶颈。