前言：

在完成模型压测、决策验证、状态并发测试、生成结构验证之后，我把整个 AI 项目的性能测试梳理成一个完整框架。

这篇做一次总览。

很多人做 AI 性能测试时，只压了模型接口。

但在实际项目中，模型只是其中一层。

完整的 AI 性能测试，应该分层设计。

---

一、为什么需要分层？

AI 系统不只是一个接口。

典型 Agent 链路是：

自然语言
→ 决策判断
→ 工具调用
→ 状态写入
→ 再生成

如果只压模型并发：

• 决策漂移发现不了

• 状态写坏发现不了

• 结构失控发现不了

所以须分层验证。

---

二、AI 性能测试四层框架

我把它拆成四层：

---

第一层：模型服务层（Model Serving Layer）

关注：

• 并发能力

• P95 / P99

• TTFB

• QPS

• 成功率

• GPU 显存瓶颈

核心问题：

模型服务扛不扛得住？

风险类型：

• 超时

• 失败率上升

• 显存溢出

这一层解决的是“慢”。

---

第二层：决策层（L1 Decision Layer）

关注：

• 路由是否稳定

• 同样输入是否始终走同一路径

• reject 是否误触发 tool

• 是否存在路由漂移

核心问题：

模型行为是否一致？

风险类型：

• 意图误判

• 偶发触发写入

• 行为不稳定

这一层解决的是“错”。

---

第三层：状态层（L2 State Layer）

关注：

• 并发写入是否安全

• JSON 是否损坏

• 是否幂等缺失

• 数据是否丢失或覆盖

核心问题：

数据是否会被污染？

风险类型：

• 并发写坏

• 空行

• 重复记录

这一层解决的是“乱”。

---

第四层：生成层（L3 Generation Layer）

关注：

• 输出结构是否稳定

• 模板是否完整

• 是否超过条目上限

• 是否幻觉生成

核心问题：

输出是否可控？

风险类型：

• 结构漂移

• 模板缺失

• 无数据却生成内容

这一层解决的是“偏”。

---

三、四层之间的关系

这四层不是并列的。

它们是递进关系：

模型层稳定
↓
决策层稳定
↓
状态层安全
↓
生成层可控

任何一层出问题，系统都不可信。

---

四、常见误区

误区一：只压模型接口
误区二：只看 RT 不看行为
误区三：不做结构验证
误区四：忽略并发状态污染

很多所谓“AI 性能测试”，只完成了第一层。

---

五、完整测试流程

可以按以下顺序执行：

1️⃣ 模型服务层压测
2️⃣ 决策稳定性验证
3️⃣ 状态并发安全验证
4️⃣ 生成结构稳定性验证
5️⃣ 修复后回归全链路

这样才能形成闭环。

---

六、这个框架的价值

这个框架的价值在于：

• 可以直接落地到 Agent 项目

• 可以用于面试表达

• 可以用于项目复盘

• 可以避免“只压模型”的误区

它本质是一种：

分层验证思维。

---

七、最终总结

AI 性能测试，不是一个数字。

不是一个 QPS。

不是一个 P99。

它是对整个 AI 系统可靠性的验证。

真正完整的 AI 性能测试框架应该覆盖：

慢（模型层）
错（决策层）
乱（状态层）
偏（生成层）

只有四层都稳定，系统才是可信的。