3. 性能需求定义：响应时间、吞吐量、并发用户数、资源利用率
3.1 边界划定：从“快”到“准”的四维拆解
性能需求不能仅用一个“快”字概括。在AI产品架构中，必须将性能拆解为四个相互耦合、但度量性质截然不同的维度：响应时间（快不快）、吞吐量（多不多）、并发用户数（挤不挤）、资源利用率（省不省）。四者共同构成性能容量的边界约束。
| 指标 | 定义 | AI 产品典型关注点 | 边界含义 |
|---|---|---|---|
| 响应时间 (Latency) | 从请求发出到收到完整响应所经过的时长 | 模型推理时延、前处理/后处理时延、网络传输时延 | 用户可容忍的最大等待时间，通常 P99 < 2000ms |
| 吞吐量 (Throughput) | 单位时间内系统成功处理的请求数或数据量 | 每秒处理图片数(QPS)、每分钟处理文本字数(TPS) | 硬上限由算力与带宽决定，超过即排队积压 |
| 并发用户数 (Concurrency) | 同一时刻与系统保持交互的用户数量 | 同时在线推理的用户数、同时等待模型返回的会话数 | 决定连接池、线程池、GPU显存分配的基线 |
| 资源利用率 (Utilization) | 系统中各类资源实际使用量与总容量的比率 | GPU显存占用率、CPU核利用率、内存/磁盘IO | 超过 80% 通常视为高负载警戒线 |
架构约束提示： 这四个维度不能单独定义。例如 “响应时间 < 500ms” 若没有同时声明并发用户数（如 100 并发）和吞吐量（如 50 QPS），则这个数值毫无意义，因为单用户下响应时间极易达标。
3.2 系统分层与组件职责
在AI推理服务中，性能需求需要从入口至落点逐层分解，每一层承担不同的性能组件职责：
- 接入层（API Gateway / Nginx）：负责连接管理、限流、负载均衡。职责是维持高并发连接，把请求均匀分发至推理节点。
- 编排层（业务服务 / 推理路由器）：负责请求组装、预处理调度、后处理聚合。职责是控制响应时间的拆解节奏，避免某个预处理成为瓶颈。
- 推理引擎层（TensorRT / ONNX Runtime / vLLM）：负责模型加载和推理执行。职责是最大化GPU利用率、控制单次推理时延。
- 资源管理层（Kubernetes / 调度器）：负责GPU/CPU显存与算力的分配、扩缩容。职责是确保资源利用率在安全阈值内，避免OOM。
风险点： 很多AI产品在编排层忽视“预处理耗时”，把图片解码、文本切分等耗时操作当作瞬时完成。实践中，预处理可能占据整个响应时间的 30%-50%，必须单独定义和监控。
3.3 数据流与性能指标传递链路
性能指标的采集和聚合需要明确的数据流。典型的性能链路如下：
用户请求
─→ 接入层 (记录墙钟响应时间 start_time)
─→ 编排层 (记录排队等待时间、预处理耗时)
─→ 推理引擎 (记录模型推理耗时、显存使用峰值)
─→ 编排层 (记录后处理耗时)
─→ 接入层 (记录完整响应时间 end_time)
─→ 监控系统 (Prometheus / Grafana 聚合P50/P95/P99)中间每层的耗时都必须通过链路追踪（如 OpenTelemetry）标记，才能在出现性能劣化时准确定位瓶颈是出在模型本身还是前/后处理。
3.4 性能需求选型权衡
| 场景 | 优先关注指标 | 架构选型倾向 | 代价 |
|---|---|---|---|
| 在线实时对话（对话AI） | 响应时间 P99 < 1s | 小模型 + 模型量化 + 流式输出 | 牺牲单轮推理质量 |
| 离线批量数据处理（数据标注） | 吞吐量 最高 | 大模型 + 动态批处理 + 异步队列 | 响应时间秒级到分钟级 |
| 高并发图片审核 | 并发用户数 & 吞吐量 同时高 | 多卡多实例 + 水平扩展 + 缓存命中 | GPU 资源成本倍增 |
| 边缘端AI推理 | 资源利用率 & 响应时间 平衡 | 模型剪枝 + 专用NPU + 固定批大小 | 模型泛化能力下降 |
3.5 落地步骤：性能需求验收清单
在AI产品交付阶段，必须逐条验证以下条件，才能判定性能需求达标：
- 定义基准负载： 明确测试用的请求数据（图片大小、文本长度）、并发模型、测试时长。
- 单指标孤立测试： 控制变量，先测试 1 并发下 P50/P99 响应时间，再逐步增加并发到目标值。
- 资源利用率监控： 在目标并发下，确认 GPU 显存利用率不超过 90%, CPU 利用率不超过 85%。
- 边界压力测试： 突增 2 倍并发确认系统是否触发限流、OOM或崩溃。
- 长稳测试： 持续运行 8 小时，检测性能曲线是否出现梯度衰减（显存泄漏常见现象）。
3.6 内联SVG框架图：性能需求四维分层模型
3.7 验收标准：性能需求验收前置条件
| 验收项 | 具体标准 | 通过条件 |
|---|---|---|
| 响应时间 | 在目标并发 100 下，P50 < 600ms，P99 < 2000ms | 连续 3 次测试均达标 |
| 吞吐量 | 在保持 P99 不超 2000ms 前提下，QPS ≥ 50 | 峰值 QPS 持续 5 分钟不下降 |
| 并发用户数 | 系统能稳定支撑 200 并发用户，无连接断开/请求失败 | 错误率 < 0.1% |
| 资源利用率 | GPU 显存利用率 ≤ 85%，CPU 利用率 ≤ 80% | 持续 8 小时无 OOM 或 CPU 限流 |
验收常见陷阱： 单次测试结果不能代表系统稳定性。许多 AI 产品在第一次推理时需加载模型（冷启动），此时响应时间可能数倍于稳定态。验收时必须明确区分 冷启动 与 稳定运行 两个阶段的性能标准。
3.8 风险点与后置预案
- 显存泄漏： 每次推理后未正确释放显存导致资源利用率逐步上升。需在落地步骤中加入每 1000 次推理后检查显存回收的自动化用例。
- 并发增长时响应时间非线性恶化： 当并发数超过某个阈值，请求可能在接入层排队，此时继续增加并发反而降低吞吐量。需在架构中预设 主动降级 策略，例如返回兜底回复或降级为小模型。
- 模型版本更新导致性能回退： 模型结构微调可能增加推理时延。验收阶段必须包含模型版本更新后的性能回归测试集。