限流应对与优雅降级
429 是你超了配额，529 是上游过载 —— 两者的正确反应不同。指数退避带抖动、尊重 retry-after、熔断后 fallback 到备用模型或降级功能、排队降级而不是直接报错；止血优先，先保核心链路再谈体验。
也叫：限流 · 429 · 529 · 指数退避 · fallback · 熔断 · 优雅降级 · retry-after
二、降级：429 不等于 529出自 T6-3
本节最锋利、也最容易翻车的一刀：
| 状态码 | 含义 | 正确动作 |
|---|---|---|
| 429 | 你超限了 | 读 retry-after 指数退避 + 随机抖动，同厂商重试 |
| 529 | 上游过载 | 重试无用甚至加重雪崩，正确动作是切 fallback |
| 403 / 413 | 配额耗尽 / 请求过大 | 不可重试，降级、拒绝或换大窗口模型 |
| 504 | 处理超时 | 官方建议改用流式或批处理 |
把 429 和 529 一律当限流重试，是典型的没做过生产。 叠加"失败请求也消耗配额"，盲目重试是把自己往雪崩里推。官方在批处理场景给的建议反而是主动注入延迟——限额 20 RPM 就给每个请求加 3 到 6 秒，在天花板附近平稳运行。
跨厂商 fallback 的真实成本是三重的，不是"配一行 config"：
① 缓存归零 跨厂商必然 100% 未命中；即使同厂商跨模型降级，
也可能因最小可缓存长度跳档（旗舰 512 → 小模型 4096 token），
让一批 800 token 的 prompt 从 0.1× 掉回 1.0× —— 输入成本涨 10 倍
② 契约破裂 tool schema、tool_choice、结构化输出、流式事件语义都可能不兼容
③ 合规越界 主链路走签了协议的 A 厂商，故障时自动降到 B 厂商
—— 用户数据在无人察觉时流出了合规边界fallback 不是配置项，是给降级链单独跑一遍输出契约测试 + 单独过一遍合规评审 + 单独算一遍成本模型。 敏感流量的降级目标只能在同等合规级别内选，宁可返回错误也不跨界降级。
以上节选自T6-3 LLM 网关：限流、降级、缓存与路由的四笔账，读全文能看到前后语境。