团队采购 AI API 额度批发时，常遇到“余额充足，请求却被限流”的问题。客服、研发和内容任务共用接入通道，高峰流量容易触发 rate limit。评估中转服务不能只看 Token 单价，还要确认限流范围、并发能力与排队机制，让采购额度匹配实际吞吐需求。
余额、速率与并发，为什么不能混为一谈？
余额代表可消费资源，不等于单位时间内的处理能力。RPM 通常描述每分钟请求数，TPM 描述每分钟 Token 数，并发数则表示同时处理的请求数量。具体统计口径、时间窗口及输入输出 Token 的计算方式，应以模型提供方和中转服务说明为准。
购买更多额度，不代表自动获得更高限流上限。短请求可能先碰到 RPM 限制，长上下文或长输出任务可能先耗尽 TPM，流式请求也可能较长时间占用并发槽位。不同模型、项目或账户是否共享限制，需要在采购前确认。
团队使用版：先设共享预算，再控制任务入口
只在每台客户端限制并发，难以约束多成员、多实例的总流量。更稳妥的方式是在统一 API 网关或任务服务中设置共享限速器，并按团队、项目及模型拆分预算。
- 建立任务队列：将实时对话与离线批处理分开，设置优先级和最长等待时间，避免批量任务挤占交互请求。
- 同时约束速率与并发：用令牌桶等机制控制请求速率，用信号量限制在途请求；多实例部署需要共享计数或协调机制。
- 估算 Token 占用：结合输入长度与预期输出预留预算，完成后按实际用量校正，并为估算偏差保留余量。
- 设置成员配额：为不同项目配置消费上限和流量预算，避免单个脚本耗尽共享资源；告警阈值与负责人同步登记。
并发值应通过压测逐步调整，而不是按余额推算。观察成功率、首 Token 延迟、整体耗时及限流比例，接近瓶颈时降低入队速度。流式调用应在结束、异常或取消后及时释放并发槽位。
遇到 429：区分原因，再决定是否重试
HTTP 429 常与请求过快有关，但不能只凭状态码判断。应结合响应错误类型、错误正文及服务文档，区分速率限制、额度不足或网关策略限制；不同接入层的错误映射可能不同。
对可恢复的限流，若响应提供 Retry-After，应据此安排等待；否则采用带随机抖动的指数退避，并设置最大重试次数和总等待时长。额度不足或权限配置错误则需要处理根因，连续重试通常无效。重试流量也必须经过共享限速器。超时不一定代表上游未执行，生成、工具调用等任务还需检查重复执行风险。
采购 AI API 额度批发前，要问清哪些问题？
- 限流按账户、密钥、项目还是模型计算？是否还受上游共享限制影响？
- 额度有效期、余额查询、用量明细及失败请求计费如何说明？
- 是否提供请求标识和错误透传，方便排查限流来源？
- 扩容需要什么条件，能否先用小流量验证高峰表现？
在 openmagic.ai 评估接入方案时，可先整理模型清单、峰值请求量、平均上下文长度和延迟目标，再核对服务说明。将费用、重试损耗与排队时间一起比较，才能判断额度批发是否适合团队，而非只比较 Token 标价。