调用 OpenAI API 时遇到 rate limit，先别急着充值或购买更高并发。相同的 HTTP 429，可能涉及请求频率、Token 吞吐限制，也可能与可用额度有关。限流、余额不足与中转网关限制不是同一件事，处理前要保存错误正文、请求 ID、模型名称和发生时间，再判断瓶颈在哪一层。
先读错误信息，区分频率与额度
不要只凭状态码诊断。检查响应中的错误类型、错误码和提示内容；若返回限流相关响应头，也应记录剩余量与重置时间。不同接口、模型及接入方式返回的信息可能不同，以当前响应和控制台显示为准。
- 请求频率受限：短时间请求过密，应降低发送速率并平滑流量。
- Token 吞吐受限：请求不多也可能触发，需检查长上下文、批量任务和输出上限。
- 额度或计费异常：检查余额、预算限制及计费状态，连续重试通常无效。
- 中转层受限：核查网关账号、模型路由及套餐规则，不能直接套用上游额度。
通过 openmagic.ai 等 API 中转方式接入时，应同时查看网关日志和可获取的上游错误信息。不要把完整 API Key 或用户敏感输入写进排障日志。
RPM、TPM 与并发如何估算？
RPM 是每分钟请求数，TPM 是每分钟 Token 数，并发则是同一时刻正在处理的请求数。三者相关但不等价：提高并发可能造成瞬时突发；长文本任务即使 RPM 不高，也可能先撞上 TPM。
例如，每分钟发送 20 次请求，每次输入约 1500 Token、输出约 500 Token，则业务侧预估用量约为每分钟 4 万 Token。这只是容量规划估算，不等于平台实际限流计数；部分接口的限流估算还可能受请求参数影响，应结合文档与实测校准。
并发起点可用“每秒请求数 × 平均请求耗时”粗估，再通过压测调整。平均耗时不能代表高峰，需要为延迟波动留出空间，并将交互请求与后台批处理分开排队。
价格、额度和 Token 预算怎么计算？
费用可按“输入 Token × 输入单价 + 输出 Token × 输出单价”估算，计算前统一价格单位。缓存、工具调用及其他计费项目，应按实际模型和接口规则单独核对。本文不提供固定报价，采购时应核实模型标识、计价单位和账单口径。
月预算可由日请求量、单次平均用量和运行天数推算，并为失败重试、上下文增长及峰值任务预留预算。购买更多 Token 不代表获得更高 RPM 或 TPM。选择 API 中转或 Token 批发方案时，应分别询问余额、有效期、模型权限、限流和并发规则，避免只比较单价。
新手可执行的修复顺序
- 用单个短请求验证模型、密钥和计费状态，排除基础配置问题。
- 增加队列与客户端限速，缩短重复上下文，合理设置输出上限。
- 对适合重试的暂时性限流使用带随机抖动的指数退避；若有 Retry-After 提示则参考执行，并设置重试上限。
- 检查 SDK 是否已自动重试，避免业务层重复叠加；对有副作用的操作做好去重。
- 持续记录成功率、延迟、Token 用量与费用，再判断是否需要申请额度调整或变更接入方案。
解决 OpenAI API rate limit 的核心，是先确认限制来源，再匹配吞吐与预算。评估中转服务时，优先核查错误透传、用量明细和限流说明，而不是把“高并发”宣传当作无限调用承诺。