它在算什么

大模型 API 的限流通常有两把尺子：RPM（每分钟请求数）和 TPM（每分钟 token 数）。 两者是「与」的关系，任何一条到顶都会被拒。判断自己受限于哪一条很简单： 用单请求平均 token 数乘以 RPM 上限，如果结果超过 TPM 上限，那你实际受限于 TPM，RPM 那个数字根本用不到。

算出实际可用速率之后，再换算成并发：并发 ≈ 可用 RPM ÷ 60 × 单请求耗时。 这一步是最多人搞错的地方——并发和速率是两个维度，通过耗时才能互相换算。 单请求越慢，同样的速率需要越高的并发；反过来，把并发盲目调大并不会提高吞吐，只会制造更多 429。

怎么填这几个数

RPM / TPM 从厂商控制台的额度页面拿，注意区分免费档和付费档——两者差别通常很大， 用免费额度压测出来的容量不代表付费后的表现。

单请求平均 token 要算输入加输出的合计（多数厂商的 TPM 是合并口径）。 输入包括 system prompt、工具定义、检索片段和历史，不只是用户那句话； 把完整请求体粘进 token 计算器量一下更准。

单请求平均耗时从你的日志里统计，用中位数而不是平均值。如果还没有线上数据， 先做一次速度测试，方法见大模型 API 的速度怎么测。

业务峰值要用分钟级峰值，不是小时平均。流量集中的业务，峰值可能是日均的好几倍， 按日均申请的额度会在高峰时段被打爆。

算出缺口之后怎么办

一是提额。多数厂商支持按用量或申请提升档位，但通常有审核周期，别等撞墙才申请。

二是降需求。缩短输入直接降低 TPM 压力；把多个小任务合并成一次调用降低 RPM 压力； 把不紧急的活挪到批处理接口（通常有独立额度）。具体手段见 大模型 API 降本十招。

三是削峰。把可延迟的任务错峰到低谷时段，用低一档的额度就够了，还能省钱。

四是分散。多家并用按权重分配，既扩容又是可用性保险。做法见 Agent 的多模型路由策略。

配套要做的事

算出建议并发之后，最好在客户端做主动限速（令牌桶），把速率压在额度以内， 而不是等服务端拒绝再退避——被拒的请求不产生任何输出，但重试是要重新计费的。 限流触发后的正确处理姿势见 API 报 429 怎么办， 额度口径的完整说明见 RPM 和 TPM 是什么。