调用 OpenAI API 时遇到 rate limit，不一定是余额不足，也不一定靠升级套餐就能解决。新手应先区分请求频率、Token 吞吐与计费额度，再决定调整并发、申请额度，还是评估 API 中转。先确认限制类型，再估算扩容成本，能避免无效充值和重复请求。
第一步：区分限流与计费额度不足
遇到 HTTP 429 时，先查看响应中的错误类型、message、请求标识与限流响应头，不要只看状态码。请求过快、Token 使用过密，以及额度或计费问题，都可能需要不同的处理方式；具体以实际响应和账户控制台为准。
- 请求频率限制：检查每分钟请求数，以及多个服务是否共用同一项目或额度池。
- Token 吞吐限制：统计输入上下文和输出预算，长对话、批量任务尤其容易触发。
- 计费额度问题：核对余额、预算设置、项目权限与计费状态，单纯重试通常无效。
- 中转侧限制：若经网关调用，还需确认限制来自上游模型还是中转服务自身。
记录发生时间、模型、并发数、输入长度和重试次数。日志不要保存 API Key；涉及业务文本时应脱敏，便于安全复现问题。
第二步：估算 RPM、TPM 与 Token 预算
先用真实样本测量平均输入、输出 Token。每分钟预计请求数可按“活跃用户数 × 每人每分钟调用次数”估算；每分钟 Token 需求可按“请求数 × 单次平均输入与输出 Token 合计”估算，并为峰值留出余量。这是容量测算，不等同于平台实际限流口径，部分接口可能将请求中的输出上限纳入限流估算。
例如，业务预计每分钟 30 次调用，平均输入 1500 Token、输出 500 Token，则业务侧吞吐约为每分钟 6 万 Token。该数字不是账户额度承诺；仍需核对所选模型、项目及共享额度池的限制。降低并发只会拉长处理时间，不会自动减少总 Token 消耗。
第三步：估算价格，不把充值当作提额
模型成本可按“输入 Token ÷ 计价单位 × 输入单价＋输出 Token ÷ 计价单位 × 输出单价”测算。单价与计价单位以当前模型报价为准；缓存、工具调用等费用应单独核对。月预算还需计入失败重试、业务增长，以及中转服务可能收取的费用。
比较 API 中转或 Token 批发方案时，应询问模型映射、计费倍率、余额规则、失败请求计费方式和并发限制。充值余额、消费预算与速率额度不是同一概念，购买前需确认增加余额是否实际改变 RPM 或 TPM，避免有余额却仍被限流。
第四步：用队列和退避解决高峰限流
优先在应用侧设置统一队列、并发上限和 Token 预算，避免多个实例各自放量。对可重试的限流错误使用指数退避与随机抖动，参考服务返回的等待提示，并设置最大次数；计费或权限错误则停止自动重试。缩短无关上下文、合理限制输出，也有助于减少吞吐压力。
接入 openmagic.ai 等模型中转入口前，应核对模型名称、SDK 的 base_url 配置、超时设置与错误透传方式，并用小流量验证。中转可以统一接入和用量管理，但不应被视为无限额度承诺。最终用成功率、峰值排队时间和每次成功调用成本判断方案，而不是只比较标称 Token 单价。