调用 OpenAI API 遇到 rate limit，不一定是余额不足，也不一定需要购买更多 Token。新手应先区分请求速率、Token 吞吐、并发控制与账户额度，再决定调整程序还是评估 API 中转。本文围绕 OpenAI API rate limit 解决，说明排查顺序和预算方法；具体限制与价格以实际账户、模型及服务商文档为准。
先读错误信息：429 不等于同一种故障
收到 HTTP 429 后，先保存响应中的错误类型、错误说明、请求 ID，以及返回中可用的限流响应头。不要只根据状态码判断：速率限制与额度不足可能需要完全不同的处理。
- 请求频率过高：检查 RPM，即每分钟请求数，以及是否存在瞬时突发。
- Token 吞吐超限：检查 TPM，即每分钟 Token 数；长上下文和较高输出上限都可能影响限流核算。
- 额度或计费异常：核对账户余额、项目预算、付款状态及错误中的额度提示。
- 中转层限制：确认限制来自上游模型，还是网关自身的套餐、渠道或并发规则。
有余额不代表不会限流。余额解决支付能力，速率额度决定处理速度；增加余额也不应被视为自动提升吞吐的保证。
新手排查顺序：先降速，再定位瓶颈
先用单并发、短输入的小请求测试。若小请求成功而批量失败，优先检查突发流量和队列；若短文本成功、长文本失败，则关注 Token 吞吐、上下文长度与模型参数限制。上下文超长不一定属于 rate limit，应按实际错误处理。
在 SDK 或业务层加入带随机抖动的指数退避，若响应提供 Retry-After 等等待信息，可据此安排重试。同时设置最大重试次数、超时和队列长度，避免多个客户端同步重试。额度不足、鉴权失败等错误不应无限重试；已产生业务副作用的操作还需防止重复执行。
上线时按模型、项目或渠道设置限速器，逐步提高并发并观察成功率和延迟。并发数不是 RPM：请求耗时不同，相同并发产生的请求速率也不同。不要用轮换密钥来规避平台限制。
价格、额度和 Token 预算怎么估算？
预算应把“总用量”和“峰值吞吐”分开计算。日 Token 量可按“日请求数 × 单次平均 Token 量”估算，但费用需要分别统计输入与输出，再乘对应模型单价；缓存、工具调用等项目按实际计费规则另算。
例如，业务预计每天 1000 次调用，平均每次输入 1500 Token、输出 500 Token，则日输入约 150 万 Token、日输出约 50 万 Token。这只是用量示例，不代表任何平台的价格或赠送额度。若高峰每分钟 20 次请求，平均每次合计 2000 Token，基础吞吐需求约为每分钟 4 万 Token，还需考虑突发与限流核算差异。
连续记录实际用量、失败率和重试次数，再修正预算。减少无关历史、压缩重复提示词、合理设置输出上限，通常比单纯提高并发更有助于控制成本。
何时评估 API 中转或 Token 批发？
需要统一接入、多模型路由或集中对账时，可评估 API 中转，但中转不等于无限额度。在 openmagic.ai 等接入场景中，应先核验目标模型、SDK 兼容方式、计费单位、限流规则与错误透传能力，再用小额流量测试。采购 Token 或批发额度前，还要确认有效期、失败请求计费、数据处理方式及余额查询方法，避免只比较标价而忽略实际成功调用成本。