大模型性能测试，到底在测什么？模型层 vs Agent 层一次讲清
前言：
最近在梳理 AI 项目时，发现一个很常见的混淆：
很多人说做了“大模型性能测试”，
但实际在做的事情可能完全不同。
有人压的是：
模型 API 并发
TTFB
Token 生成速度
有人压的是：
Agent 系统接口
工具调用
状态落盘
两者都叫“AI 性能测试”，但本质不一样。
这篇文章我结合自己两段经历，梳理一下：
模型层压测 vs Agent 系统压测，到底在测什么。
一、第一类：模型服务层压测
这类压测的对象是：
已经部署好的大模型服务（API 形式）
比如：
http://xxx/v1/chat/completions
本地 Ollama
vLLM 服务
公司自研模型推理服务
压测目标通常包括：
1️⃣ 并发能力
2️⃣ 响应时间（P95 / P99）
3️⃣ 首 token 时间（TTFB）
4️⃣ Token 生成速度（token/s）
5️⃣ QPS
6️⃣ 成功率
7️⃣ GPU / CPU / 显存使用率
例如我当时做的压测脚本就是：
ThreadPoolExecutor 并发
统计每次请求耗时
计算平均值 / P95
分阶段提升并发
观察成功率下降点
结合 nvidia-smi 看显存瓶颈
最终发现：
30 并发开始成功率下降
GPU 显存接近 82%
CPU 正常
这类压测回答的是：
模型服务能扛多少流量？
瓶颈在哪里？
它更偏“系统性能”。
二、第二类：Agent 系统压测
当开始做 Agent 项目后，发现问题变复杂了。
Agent 的链路不是：
请求 → 模型 → 返回
而是：
自然语言 → 决策 → tool → 状态 → 再生成
这时候如果只压模型并发，是不够的。
需要把 Agent 拆成三层：
L1：决策层
L2：状态层
L3：生成层
分别验证：
路由是否稳定
是否误触发工具
并发写入是否损坏数据
是否幂等缺失
生成结构是否漂移
是否幻觉生成
这类压测回答的是：
Agent 系统是否可靠？
数据是否被污染？
决策是否稳定？
它更偏“系统可靠性”。
三、为什么容易混淆？
因为两种测试都会：
用并发
看 RT
看错误率
但它们关注的核心不同：
| 维度 | 模型层压测 | Agent 层压测 |
|---|---|---|
| 目标 | 服务能力 | 系统可靠性 |
| 核心问题 | 慢 / 限流 | 错 / 乱 / 偏 |
| 关注指标 | TTFB / token/s | 幂等 / 漂移 / JSON 完整性 |
| 瓶颈定位 | GPU / 推理框架 | 业务逻辑 / 状态管理 |
四、正确理解：两者应该是层级关系
Agent 系统性能测试，应该包含：
1、模型层压测
2、决策层验证
3、状态层并发安全
4、生成层结构稳定
模型层只是其中一部分。
如果只压模型：
JSON 被写坏你不会知道
幂等缺失你不会知道
路由漂移你不会知道
但如果只压 Agent：
模型 API 本身扛不住你也没发现
所以完整的 AI 性能测试，是“分层的”。
五、认知转变
以前我也认为：
AI 性能测试就是压大模型。
但在 Agent 项目中发现：
真正致命的，往往不是模型慢，而是系统乱。
比如：
并发写入 JSONL 空行
同样输入两次写两条数据
reject 却触发 tool
这些和模型性能没关系。
但会直接影响系统可信度。
六、小结
如果你在做 AI 项目，建议先问自己三个问题：
我现在压的是模型服务，还是 Agent 系统？
我关注的是吞吐能力，还是决策/状态可靠性？
我的压测是否分层设计？
把这三点想清楚，性能测试思路会清晰很多。