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