AI API 频繁 429 怎么办？
AI API 接入后频繁 429，应按并发、队列、指数退避、用户提示、request_id 和调用日志分层排查，避免重复消耗。
适用场景：不是所有 429 都该立刻重试
这篇适合已经把聊天、摘要、客服工单、AI 自动化办公或开发者 AI 调用接入业务系统的人。页面偶尔返回 429 并不一定是平台故障，更多时候是同一时间并发过高、重试策略太急、批处理没有排队，或者模型调用管理没有区分免费试用、正式用户和后台任务。永沃云枢在 https://ai.jn83.com 整理 AI API 接入经验时，会先把 429 当成容量和节流信号，而不是简单理解成“接口坏了”。
很多新手会搜“GPT 中转 429 怎么解决”，更规范的说法是 AI 模型接口接入后的限流退避和调用队列治理。排查重点不是换一个模型名就结束，而是要知道谁在请求、请求从哪里来、失败后有没有自动重放、用户界面有没有提示等待，以及队列里的任务是否还能被取消。
先看失败形态，再决定处理方式
第一类是瞬时高峰。比如客服集中导入一批会话，或者运营在同一分钟批量生成商品文案，调用曲线会突然抬高。此时应限制前端并发，把批任务切成小批次，并给每个任务写入 request_id、user_id、biz_tag 和 model 字段，方便在日志里还原来源。
第二类是重试放大。后端收到 429 后立即重试，前端超时后用户又点一次，队列消费者也把同一条任务重新投递，最后一次真实请求变成三四次模型调用。处理方法是给任务加幂等键，429 只进入指数退避，不允许无间隔循环重试。可以用 rg request_id logs、后台调用记录或网关日志检查同一个请求是否被重复执行。
第三类是权限和配额混用。测试环境、正式环境、Codex 接入脚本和 CCSwitch 配置共用同一把 Key 时，一个定时批处理就可能把交互式用户挤掉。建议按环境和业务拆分 profile，给批任务单独限速，正式聊天或办公流程保留更高优先级。
操作步骤：把退避、队列和提示串起来
第一步，固定错误日志字段。至少记录时间、request_id、用户或任务标签、模型名、输入长度、HTTP 状态、上游错误码、重试次数和最终状态。没有这些字段时，看到 429 只能凭感觉处理。
第二步，建立分级队列。交互式聊天、Codex 接入排错、后台批量摘要、AI 自动化办公报表不要挤在一个队列里。交互式任务可以短等待并明确提示，后台任务可以低速排队，超过最大等待时间就标记为可重新提交。
第三步，设置指数退避和最大次数。常见做法是第一次等待几秒，随后按倍数增长，并增加少量随机抖动，避免所有任务同一秒再次冲上去。最大次数到达后不要继续消耗，应把失败原因写到任务记录，并给用户一个可理解的提示。
第四步，检查 CCSwitch 配置是否把所有业务路由到同一个供应商或同一个高成本模型。多模型不是为了盲目切换，而是为了按任务类型、成本阈值和可接受延迟做备用。切换后还要保留原模型名和备用模型名，方便复盘。
常见问题/避坑：不要用无限重试掩盖容量问题
第一个坑是把 429 当成 500 处理，失败就立刻重试，结果把限流变成雪崩。第二个坑是前端只显示“生成失败”，用户不知道该等一会儿还是重新提交。第三个坑是后台批量任务没有暂停按钮，队列堆积后只能等它慢慢烧完。第四个坑是没有按业务标签统计，最后只能看到总量上升，却找不到具体功能。
还有一个容易忽略的点是输出保存。生成类任务如果在第二次重试成功，第一次半成品不能被当作最终结果；如果用户取消任务，消费者也要能识别取消状态，不能继续调用模型。涉及发邮件、写入工单、改 CRM 字段的自动化流程，要把“模型输出”和“业务写入”拆开验收。
检查清单：上线前做一次限流演练
检查项包括：日志有 request_id；队列能按业务分级；429 进入指数退避；重试有幂等键；前端提示包含等待和重试建议；后台批任务能暂停；CCSwitch profile 区分测试和正式；调用记录能按用户、模型、业务标签聚合；失败结果不会覆盖成功结果。
验收时可以人为把并发调低，连续提交 20 个小任务，观察页面提示、队列长度、重试次数和最终费用记录。再用一个后台批量任务挤压队列，确认交互式任务不会被完全饿死。永沃云枢建议把这类演练记录成固定样本，之后更换 AI 模型接口或调整模型调用管理策略时重复执行。
FAQ：429 能不能直接换备用模型？
可以，但要有边界。备用模型适合临时容量不足、低风险摘要和草稿任务；不适合在没有抽检的情况下处理合同、财务、客服承诺或代码变更。Codex 可以帮你整理调用日志、生成排查清单和修改配置草稿，但涉及生产 Key、预算、正式写入和发布动作时，仍应人工确认。