切换工具
RPM/TPM 并发换算器
API 限流参数互算：RPM、TPM、并发数与日均调用量
实际可打满的 RPM
50
受 TPM 约束
折合每秒请求数
0.8 QPS
建议客户端并发
2.5
QPS × 平均耗时（利特尔法则）
理论日上限
72,000 次
按 24h 持续打满估算
触发 429 时：按响应头 Retry-After 指数退避重试（1s→2s→4s），客户端用令牌桶自限流从源头避免，硬重试可能被临时封禁。
大提示词场景几乎都是 TPM 先触顶，优化方向是压缩上下文、命中缓存或改走 Batch 接口（普遍半价且限额宽松），而不是降请求频率。
使用说明
厂商限流通常给两个数：RPM（Requests Per Minute）和 TPM（Tokens Per Minute）。输入你的单次请求平均 Token 数，工具算出"TPM 不超限的前提下实际能打满的请求数"、"需要设置的客户端并发数"以及"日均调用量上限"，三行结果随输入实时变化。
也可以反向使用：已知业务需要的每秒请求数（QPS），算出需要申请的 RPM/TPM 档位，作为向厂商提额或选套餐的依据。注意 TPM 按输入+输出合计计数，长提示词场景往往是 TPM 先触顶，而不是 RPM。
触顶的表现就是 HTTP 429（rate_limit_exceeded）。正确姿势：客户端按响应头 Retry-After 指数退避重试；发送前用令牌桶自限流；错峰批处理（Batch API 半价且限额宽松）；多 Key 轮转时注意各 Key 的 TPM 独立计量。
常见问题
取决于单请求 Token 数：若平均每请求 Token 数 > TPM/RPM，则 TPM 先触顶。例如限额 60 RPM + 100K TPM，平均每请求超过约 1666 Token 时 TPM 先炸。大提示词（RAG、长文档问答）几乎都是 TPM 限流，优化方向是压缩上下文与缓存，而不是降低请求频率。