调用 OpenAI API 时遇到 rate limit，不一定是余额不足，也不意味着换一个 API Key 就能恢复。新手应先区分请求频率、Token 吞吐和计费额度，再决定排队、重试或调整接入方案。本文按排查顺序说明如何估算预算，以及采购 API 中转服务时该核对什么。
先看错误信息：限流还是额度不足？
收到 HTTP 429 后，应保存响应中的错误类型、错误代码、请求 ID 与可用的限流响应头，避免只凭状态码判断。速率限制与计费额度不足需要分别处理：前者通常要降低发送速度，后者需要检查账单状态、可用额度或消费上限。具体原因以实际错误内容和账户控制台为准。
- 出现 rate_limit_exceeded：检查每分钟请求数、Token 吞吐及突发流量。
- 出现 insufficient_quota：检查可用额度、账单配置和相关预算限制，持续重试通常无助于恢复。
- 通过中转网关调用：确认错误来自上游模型还是网关自身，并核对网关余额与路由限制。
请求额度、Token 吞吐与并发怎么估算？
RPM 表示每分钟请求数，TPM 表示每分钟 Token 吞吐，两者都可能形成瓶颈。额度可能与模型、组织或项目等维度有关，应查看当前配置，不能套用网上的固定数字。多个 Key 若共享限制范围，轮换 Key 也无法获得独立额度。
例如业务每分钟预计发起 30 次请求，每次输入约 2,000 Token、输出约 500 Token，则预算层面的吞吐约为 75,000 Token/分钟。这只是容量估算；限流计量不一定等于账单中的实际 Token 用量，还需结合接口规则、输出上限参数与响应头验证，并为流量波动留出余量。
并发也不能直接等同于 RPM。可用“平均每秒请求数 × 平均响应秒数”估算在途请求量，再通过压测调整。长文本生成、工具调用和长连接都会影响响应时长，因此建议按模型或任务类型分别配置队列。
解决 rate limit：先削峰，再重试
- 在应用端设置请求队列，同时控制发送频率与在途并发，避免批处理任务瞬间打满额度。
- 对可重试的限流使用带随机抖动的指数退避；若提供 Retry-After，优先遵循，并设置最大重试次数和总超时。
- 缩短重复上下文，合理设置输出长度；符合条件时使用缓存或批处理，但需另行核对支持范围与限制。
- 持续记录模型、延迟、Token 用量、错误类型与重试次数，再判断是否需要申请更高限制或调整容量。
失败请求也可能消耗限流预算，因此不要用无限重试解决拥堵。涉及支付、写入等操作时，还应在业务层防止重试引发重复执行。
Token 预算与 API 中转价格怎么核算？
基础费用可按“输入 Token ÷ 报价单位 × 输入单价 + 输出 Token ÷ 报价单位 × 输出单价”估算。月预算再乘以预计调用量，并单独考虑缓存计费、工具费用、失败重试及网关服务费；是否收费、如何计量，均以实际报价和账单为准。
采购 Token 批发或 API 中转服务时，应核对模型标识、价格单位、共享或独立限额、并发规则、余额预警和用量导出能力。中转余额不等于上游吞吐额度，低单价也不代表更高并发。评估 openmagic.ai 等接入方案时，可先用真实业务做小规模测试，对比成功率、尾部延迟与实际账单，再确定采购预算。