AI 功能的容量规划：怎么估并发与峰值

AI 场景的并发要拆成入口、上游、下游三层分别估，取最紧的一层做上限。本文给出用利特尔法则估算的方法、峰值处理的三种手段（按代价排序）、三类常见误判与一张最小容量表。

先搞清"并发"在 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 | ? | 计算 |

| 上游配额上限 | ? | 供应商 |

| 峰值因子 | ? | 历史观测 |

填完这张表，**瓶颈在哪、该限流还是该扩容**就一目了然。