限流同时保护平台和客户
API 限流规定调用者可以多快使用服务。合理限流可以防止滥用、保护上游容量、控制账单并让多个客户公平共享资源。
只限制请求数而忽略 Token 或载荷大小是常见错误。AI API 应同时使用 RPM 与 TPM，因为一次超大请求可能比许多小请求更昂贵。
重要的限流术语
把这些术语写入文档和错误响应，开发者才能正确恢复和重试。
| 术语 | 含义 | 常见响应 |
|---|---|---|
| RPM | 每分钟请求数 | 超过后返回 429 |
| TPM | 每分钟 Token 数 | Token 预算超出后返回 429 |
| Burst | 短时突发余量 | 允许短暂峰值 |
| 并发 | 同时进行中的请求数 | 排队或拒绝超额请求 |
| Retry-After | 何时可以重试 | 秒数或时间戳响应头 |
简单的容量检查
假设上限为 3,000 RPM 和 1,000,000 TPM，250 个活跃用户每人每分钟调用 0.5 次，则需求为 125 RPM。若每次平均 900 Token，需求为 112,500 TPM，两项都在限制内。
需求 RPM = 活跃用户 × 每用户每分钟请求数；需求 TPM = 需求 RPM × 每请求平均 Token。
队列适合吸收正常突发
队列可以吸收短时高峰，但不能替代业务规则。如果长期需求高于 RPM 或 TPM，队列只会把问题推迟到延迟不可接受的时候。
后台处理、导出和批量任务可以使用较长队列；聊天、搜索等交互场景应使用较短队列、明确重试信息和每用户限额。
如何设计公平的用户限额
从上游限制中扣除运行缓冲，再按预期同时活跃用户进行分配，最后根据免费、付费和企业套餐设置不同等级。
- 429 错误应包含限制名称、当前用量和重试时间。
- 同时记录成功和被拒绝的请求。
- 对持续高利用率告警，而不是只盯单次错误。