按均值配容量，遇到峰值必崩。
先搞清"并发"在 AI 场景里指什么
传统服务的并发 = 同时在处理的请求数。AI 场景要拆成三层，因为瓶颈在不同地方：
1. 入口并发：同时在线的用户/任务数（决定排队与限流）；
2. 上游并发：同时占用模型配额的请求数（通常是最硬的约束）；
3. 下游并发：向量库/数据库/工具调用的并发（容易被忽略的瓶颈）。
容量规划要分别估，取最紧的那一层作为上限。
怎么估（用可测量的数，不要凭感觉）
· 单请求平均耗时（含排队）：T；
· 目标吞吐：Q（每秒处理多少请求）；
· 需要的并发 ≈ Q × T（利特尔法则）。
例：平均 6 秒、目标 2 请求/秒 → 需要约 12 个并发位；若上游配额只给 5 → 那么实际吞吐上限是 0.83/秒，
必须在产品侧定价/限流/排队，而不是硬扛。
峰值怎么处理
· 峰值因子：真实峰值通常是均值的 3~10 倍（活动、工作日白天、整点）；
· 三种手段，按代价排序：
1. 排队 + 可见进度（最便宜，用户体验可接受）；
2. 降级到小模型/缓存（中，见降级那篇）；
3. 扩容（最贵，且上游配额未必给得动）。
先做 1 和 2，把 3 留给真正的业务峰值。
三类常见误判
· 只算均值：按均值配容量，遇到峰值必崩；
· 忽略长尾：P95 是均值的好几倍，容量要按 P95 × 峰值请求 估，而不是均值；
· 忽略重试放大：失败重试会让实际并发翻倍（这也是成本失控的常见来源）。
一张最小容量表（建议进交接文档）
| 项 | 值 | 来源 |
|---|---|---|
| 平均耗时 T | ? | 埋点 P50 |
| P95 耗时 | ? | 埋点 P95 |
| 目标吞吐 Q | ? | 业务预估 |
| 需要并发 ≈ Q×T | ? | 计算 |
| 上游配额上限 | ? | 供应商 |
| 峰值因子 | ? | 历史观测 |
填完这张表，瓶颈在哪、该限流还是该扩容就一目了然。
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：把用户反馈做成闭环：收集、分类、归因、回归
下一篇：把工具调用做成可观测的：日志、回放与重试 →
第 40 / 171 篇