TPM和RPM介绍，和并发的关系：
- TPM = Tokens Per Minute（每分钟 Token 数）
- RPM = Requests Per Minute（每分钟请求数）
跟“并发数”混在一起了。
它们不是一个东西。
一般 AI API 厂商限制是：
| 指标 | 含义 |
|---|---|
| RPM | 每分钟允许多少次请求 |
| TPM | 每分钟允许消耗多少 Token |
| 并发 | 同时正在处理中的请求数 |
比如：
- 30 并发
- 每个请求平均 10 秒
- 那么理论 RPM 大概：
RPM \ approx \ frac{ 30 \ times 60 }{10} = 180
也就是：
- 大约 180 RPM
如果：
每个请求平均：
- 输入 3000 token
- 输出 1000 token
- 总计 4000 token
那么 TPM：
TPM \ approx 180 \ times 4000 = 720000
即：
- 大约 72 万 TPM
所以：
30 并发 ≠ 30 RPM。
很多人会误解。
你现在如果对方问你：
“TPM 和 RPM 有预估吗？”
你可以这样比较专业地回答：
当前系统实际稳定并发大约在 30 左右。
RPM 和 TPM 需要结合平均响应时长以及单次请求 Token 消耗来估算。
按目前场景粗略估计，RPM 大概在 100~200 区间，TPM 需要根据具体模型和上下文长度进一步统计。
如果你想再工程化一点，可以这我们目前关注的是实际在线并发样说：
，稳定值大概 30。
TPM/RPM 还没做精确压测，因为它和：
- 请求耗时
- 上下文长度
- 输出长度
- 是否流式返回
都强相关。
后续会根据真实 Token Usage 做容量模型。
这个说法在架构/运维/AI 平台里是合理的，显得更专业。
