AI API 限流怎么办？429 报错、重试与成本控制指南

应用一上线，最常见的 AI API 报错之一就是 429：请求太多，暂时不能处理。它不是简单的“网络不好”，而是服务商为了保护模型容量、保证公平使用而设置的限流机制。

处理限流的正确思路不是疯狂重试，而是让请求更有秩序：知道自己被哪种额度限制、何时该等、哪些任务可以排队，哪些可以缓存或降级。

先分清两种常见限制

请求数限制（RPM） 限制的是一分钟能发多少次调用。大量短问答、并发点击或 webhook 很容易触发它。

Token 限制（TPM） 限制的是一分钟内输入加输出的总 token。一次塞进长文档，即使请求数不多，也可能很快触顶。

还有并发数、单日配额和账户消费额度等限制。看到 429 时，先记录请求时间、模型、输入长度和响应头信息，别只把它当成一个可忽略的异常。

最低成本的修复：指数退避

短暂限流时，应让失败请求等待后重试，而且每次等待逐渐变长：例如 1 秒、2 秒、4 秒、8 秒，并加入随机抖动。这样能避免大量客户端在同一秒再次冲向服务，造成“重试风暴”。

需要注意：

• 设置最大重试次数和总等待时间
• 只重试可安全重试的请求
• 对用户显示“处理中”，而不是让页面假死
• 若响应提供 retry-after，优先遵循它

付款、发信、写数据库等有副作用的动作必须设计幂等键，避免重试造成重复执行。

把突发流量变成队列

批量摘要、文档处理、夜间报表这类非实时任务，不应直接与用户聊天抢同一条 API 通道。把任务放入队列，按模型和 token 预算平滑消费：

1. 接收任务后立即返回任务编号
2. Worker 按可用额度取任务
3. 超限时暂停或降低取队速度
4. 完成后写入结果并通知用户

队列能把“瞬间 1000 个请求”变成“持续稳定地处理”，通常比单纯加大套餐更有效。

四种减少限流的方法

缓存重复结果。 相同系统提示词、相同文档摘要、相同问题不必反复计算。注意给缓存加版本和过期时间，避免返回旧答案。

缩短无效上下文。 不把整段聊天史或知识库全文每次都发送。通过总结、检索和上下文工程保留真正相关的信息，既省 token 也降低延迟。

批处理可合并任务。 对不要求即时响应的分类、提取任务，可适度合并；但别把过多不相关内容塞进同一请求，质量会下降。

按任务选择模型。 简单分类或固定格式提取使用轻量模型，复杂推理再升级强模型。详见什么是模型路由。

什么时候该降级或拒绝

服务过载时，不应让每个请求无限等待。可以为不同任务定义策略：

• 聊天：排队提示、缩短回复、切换轻量模型
• 批处理：延后执行、保留任务状态
• 高风险动作：宁可失败并要求稍后重试，也不要在不完整上下文下强行执行
• 核心付费功能：设置容量预留和明确告警

“优雅降级”比“偶尔完全不可用”更能保护用户体验。

总结

限流是 AI 服务的正常运行条件，不是上线后才补的异常处理。识别请求和 token 两种瓶颈，使用指数退避、队列、缓存、上下文压缩和模型路由，就能把 429 从随机事故变成可管理的容量信号。