速率限制是什么：单位时间配额不等于账号余额
解释请求数和词元限制的作用，区分限流、并发与费用上限，并说明等待重试应怎样依据服务返回处理。
先说结论
先理解这个概念
速率限制是服务在一定时间范围内对请求量或处理量施加的约束，可能按请求数、词元等维度计算。它与账号是否有余额不同，也不一定等同于最大并发。触发限制后应读取实际错误和重试信息，按规则等待或减少负载；不能因为一条请求被拒绝，就推断模型故障或不断立即重发。
01
不同配额维度可能同时生效
OpenAI 与 Anthropic 都说明服务存在不同维度的限制，具体按账号、模型或使用层级等条件变化。一次很长的请求可能很快消耗词元预算，即使请求数量不多；多个短请求也可能先触发次数限制。不要从某个公开示例推断所有账号有相同额度。费用限制控制支出，速率限制控制时间内负载，两者需要分别核对。应用还要区分认证、无效参数与限流错误，避免用同一种恢复策略处理所有失败。
02
用有限公开请求检查限流处理
例如应用批量处理公开短句，可以先通过受控模拟返回验证限流分支，再在允许范围内检查实际服务信息。保留必要请求标识和等待状态，核对重试是否产生重复结果。服务返回重试时间时应遵循该信息，不按想象持续加速。本文没有压测服务或读取账号额度，例子不涉及收费调用。对单条已经可能完成的写入请求，还应先查目标状态，不能只因限流或超时就反复提交业务动作。
03
调度需要考虑等待和失败恢复
增加并发不能突破服务允许的总预算，反而可能让更多请求同时失败。任务调度应记录当前限制条件，将未完成项排队，并在恢复后继续，不把空结果当成功。额度或模型变化后重新核对规则，避免长期写死旧数值。比较性能时分开记录排队与实际处理时间，成本也要计入重复请求。最终让使用者知道正在等待还是确实失败，不能只显示转圈，更不能把速率限制解释为答案质量差。
核对来源
以下资料用于核对概念和方法。文中的示例与测试范围分别注明，实际使用时请核对所用工具的版本。