网关的降级策略：主力模型挂了之后
数据截至 2026-07，价格与限额以各官网为准。
降级策略的价值不在于”备用模型比主力差多少”，而在于故障发生的那几十秒里，你的系统是自己换了条路继续走，还是把一堆红色报错原样甩给用户。这两种结果的差距，通常比换用一个能力弱一档的模型带来的质量损失大得多。
有个常见误解是把降级理解成”多配一个备用 key 就行了”。备用 key 只解决了”有没有第二条路”，没解决”什么时候切、切过去之后行为变成什么样、切回来的条件是什么”。真正让人半夜爬起来的故障，往往不是完全没有备份，而是备份在错误的时机被触发、或者触发之后没人知道，等到月底看账单或者看到用户投诉才发现系统已经用降级路径跑了一星期。
这篇按四类故障、链条设计、落地配置、自动挑选与手工链条的取舍、副作用、演练、局限的顺序讲一遍。示例以 MIT 协议的开源网关 OmniRoute 为主，它由 9router fork 而来，是 Go 项目 CLIProxyAPI 的 TypeScript 移植，本身带配额感知的自动回退能力，用来说明问题比较方便；但下面讲的判断逻辑跟具体用哪个网关关系不大。
一、先把”挂了”拆成四类，反应完全不同
把所有失败都当成同一种事情处理，是降级策略最常见的设计错误。至少要分开这四类：
第一类，额度耗尽。 免费档用完、付费账户到了消费上限、当月配额跑光。这类的特点是：短时间内重试几乎肯定还是失败，而且往往要等到下一个计费周期才恢复。对它的正确反应是立刻切走，且在相当长一段时间里不要再试这个供应商——每分钟重试一次除了刷日志没有任何用。
第二类，瞬时故障。 限速（HTTP 429）、上游临时抖动、连接超时。这类的特点是过一会儿大概率能好。正确反应是带退避的重试，而不是马上切换。如果响应头里给了建议等待时间，就按它等；没给就用指数退避。这类故障如果一撞上就切换，你会发现降级链上的第二档被频繁误触发，成本和质量都在莫名其妙地漂。
第三类，供应商长时间不可用。 上游整体出问题，或者你这边的网络到不了对方端点。特点是重试几次都不行，但也不是额度问题。正确反应是熔断：连续失败到一定次数就把这个供应商标记为不健康，暂时从候选里摘掉，隔一段时间再放一个探测请求进去看看恢复没有。
第四类，模型下线或改名。 这类最阴——它不是”服务挂了”，而是你要的那个模型 ID 不存在了，报的通常是模型找不到之类的参数错误。重试和熔断都救不了它，只有改配置。它跟前三类的区别在于：前三类会自己恢复，这一类不会。
区分这四类的价值在于，每一类对应的动作是互斥的。额度耗尽时重试是浪费，瞬时故障时切换是过度反应，模型改名时无论重试还是切换都只是把错误推迟。网关能帮你做的是识别和执行，但哪类归哪类的边界，得你自己想清楚。
二、降级链怎么排：先对齐能力，再考虑便宜
排降级链的时候最容易犯的毛病，是按价格从低到高倒着排——主力挂了就掉到最便宜的那个。这在很多场景下会直接把功能打断。
更稳的排法是先问一句：这条链上的每一档，是不是都能完成这个任务的最低要求。这里的”最低要求”通常包括几项硬约束：
- 上下文长度够不够。 如果你的请求经常带十几万 token 的上下文，降级到一个上下文窗口小一大截的模型，结果不是质量下降，是直接报错。这不叫降级，叫换一种方式失败。
- 要用的接口能力在不在。 工具调用、结构化输出、流式返回、多模态输入，这几样但凡你的应用依赖了一个，降级目标就必须支持。一个不支持工具调用的模型接在带 Agent 逻辑的链路后面，链路会当场断掉。
- 响应格式解析得动。 各家在结构化输出上的严格程度不一样，有的会额外包一层解释性文字。如果你的下游是硬解析 JSON，降级之后解析失败的概率要提前想到。
把这三项过一遍，能进候选的模型通常就没几个了。这时候再在候选里按成本和速度排序，才是有意义的。
OmniRoute 仓库里给过一组零成本组合示例，可以拿来理解链条的形状：gemini-cli/gemini-3-flash-preview（每月 180K 免费）→ if/kimi-k2（无限免费）→ qw/qwen3-coder-plus（无限免费）。注意它的结构是”有限额度的放前面，标称无限免费的垫底”，这符合直觉——把额度有限的先用掉，用完自动往后掉。但这类免费额度信息变动很快，仓库里的”无限免费”是目录当时的口径，不构成任何承诺，实际排链前请以仓库文档当前版本和各供应商官网为准。
还有一点常被忽略：降级链上不要出现两个共用同一个上游的供应商。 有些聚合渠道背后是同一家的服务，主力挂了备用也一起挂，你以为有两条路，实际只有一条。判断方法很朴素——真到出事那天，两条路是不是会同时红。
三、落地时实际要配的几件事
以 OmniRoute 为例，网关本身跑起来不复杂：npx omniroute@latest 或者 Docker 拉 diegosouzapw/omniroute 映射 20128 端口，起来之后面板在 http://localhost:20128，各类 AI IDE 和 CLI 统一把地址指向 http://localhost:20128/v1。加供应商走面板左侧的 Providers → Add Provider，搜到点选，免费供应商无需凭证直接 Connect，然后 Test Connection 验一下。认证类型分四种：OAuth（由网关代管登录，不用自己填 key）、web cookie、API key、Local（Ollama、LM Studio、vLLM 这类本地推理）。仓库的说法是接了多个免费供应商就能启用自动回退。
但把供应商接上只是第一步，下面这几件事得自己盯：
逐个 Test Connection，不要只测主力。 降级链上第二第三档平时不走流量，最容易出现”配的时候没验、真需要的时候发现凭证早就失效了”。每次改完配置，把链上每一档都单独打通一次。omniroute doctor 可以做整体自检，omniroute models --search <关键词> 用来确认某个模型当前在不在可用清单里（也可以走 GET /api/models/catalog）——第一类和第四类故障的排查都靠它。
模型 ID 按供应商原生格式填。 仓库示例里像 claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5 这样的写法，有的带点号版本号，是因为上游 API 本来就那么要求。降级链上写错一个 ID，平时完全无感，等主力挂了那一刻才暴露。
回退触发要留痕。 网关切没切、切到了哪一档、什么原因切的，这些必须能事后查。降级最坏的形态是”静默成功”——请求都返回 200，用户感知到质量变了但你的监控一片绿。关于该盯哪些指标，可以看AI 网关的监控该看哪几个指标那篇，回退触发率是其中很关键的一项。
顺带说一句成本。 OmniRoute 有 RTK+Caveman 压缩，仓库自述能省 15-95% token，这个区间很宽、且是项目自述口径，没有可交叉验证的公开基准，不建议当成选型的决定性依据。真要评估，还是在自己的流量上开关对比一次更靠谱。
四、auto 和手工链条，分别适合什么时候
OmniRoute 支持把模型填成 "auto"，由网关自动挑选。这个能力好用，但适用边界要划清楚。
auto 适合的场景：任务本身对模型差异不敏感、输出能被程序验证（比如生成的代码能跑测试、返回的 JSON 能通过 schema 校验）、失败了重来一次成本很低。这类场景交给网关自动挑，省事而且通常挑得不差。
手工排链条更适合：输出要给用户直接看、任务对特定模型的风格或长上下文有依赖、或者你需要在事后精确知道每一次调用走的是哪一档。手工链条的代价是维护——上游模型改名下线的时候，要你自己去改。
实际项目里这两者经常并存：核心链路手工指定并排好回退顺序，边缘的批量任务交给 auto。怎么按任务分档，模型路由策略：什么任务该走哪一档那篇讲得更细。
五、降级之后，你的应用会以什么方式变怪
这一节是最容易被跳过、事后又最疼的部分。切换成功不等于万事大吉，下游会以几种不太直观的方式受影响：
输出长度和风格变了。 不同模型对同一段提示词的展开程度差别很大。如果你的前端按固定高度渲染、或者下游按行数切分，降级之后可能撑爆布局或者切错。
工具调用的参数拼法变了。 同样是工具调用，各家在参数命名严格程度、是否会自作主张补默认值上并不一致。Agent 链路对这个特别敏感。
提示词的适配度掉了。 你的提示词大概率是围着主力模型调出来的，那些精心加的约束句在别的模型上未必同样有效。稳妥做法是给降级档准备一份稍微保守一点的提示词——把隐式约束写成显式要求，别指望备用模型能领会同样的暗示。
长度限制不一样。 主力能吃下的请求，备用档可能超限。这是第二节讲的上下文对齐没做好时的典型症状。
用户侧要不要告知，得提前定。 不是所有场景都需要提示，但如果你的产品对输出质量有明确承诺，静默降级会带来预期落差。至少在内部日志里，这次调用走的是哪一档必须是可查的。
六、演练：别让第一次回退发生在真出事的时候
降级路径是典型的”平时不跑、跑的时候必须对”的代码，这类代码腐烂速度极快。建议做两件事：
定期主动触发一次。 最简单的做法是临时把主力供应商的配置改坏或者禁用，跑一遍完整业务流程，看降级链是不是真的接住了、下游解析有没有炸、日志里的归因对不对。做完记得恢复配置——这一步最容易忘。
关注恢复路径，不只是切走路径。 主力恢复之后，流量会不会自动切回去？切回去的条件是什么？如果没有自动切回机制，就得有人记得手动改回来，那这件事就必须进你的运维清单，而不是靠记性。
演练频率不用太高，但每次改动降级链配置之后都该跑一遍。至于跑的时候撞上的各种报错，OmniRoute 常见问题排查里整理了一批。
七、诚实说三点局限
第一，网关本身也是单点。 把所有流量收敛到一个本地网关，网关自己挂了，全线一起停。这不是不能接受，但要意识到你只是把风险从”多家供应商”挪到了”一个进程”上。要不要给网关本身做冗余，取决于你的业务能忍多久。
第二，凭证集中带来的风险是真实的。 这类第三方聚合网关的工作方式，是把各家的凭证交给一个本地代理统一管理。方便的另一面是集中——一处泄露影响面比分散存放大。企业环境里用之前，凭证怎么存、谁能访问面板、审计怎么做，这些得先有说法。这篇不为任何具体网关的安全性背书。
第三，免费档撑不起生产可用性承诺。 免费额度类信息变动极快，目录里标称的”永久免费""无限免费”是仓库当时的口径，不构成任何一方的服务承诺。拿免费链路做个人开发或者试验完全可以，但如果你要对外承诺可用性，降级链里至少得有一档是有商业协议兜底的。想拼零成本组合的话，用 OmniRoute 拼一套零成本模型组合那篇有更具体的做法，也同样标注了这个边界。
另外，降级链上如果排了海外厂商的模型，要先确认准入前提。这几家官方并未面向中国大陆开放，注册、控制台与 API 端点都在境外，具体以各自官网的地区政策页当前版本为准；本文不提供也不背书任何第三方中转渠道。排链之前先确认链上每一档在你的实际网络和合规环境下是不是真的能用，别把一个根本连不上的供应商写进链条里当保险——那种”保险”只会在出事那天再失败一次。
小结
降级策略的核心不是备胎有多好，而是切换时机判断得准不准。先把额度耗尽、瞬时故障、长时间不可用、模型下线这四类分开，各给各的动作，比堆多少个备用供应商都管用。排链条时先过上下文长度、接口能力、输出格式这三道对齐，剩下的候选再按成本排序。配好之后逐档验证凭证、让回退动作留痕，并且定期主动触发一次演练，否则这条路会在你最需要的时候第一次运行。最后记住网关自己也是单点、凭证集中有代价、免费档不构成可用性承诺——这三件事想清楚了，降级策略才算真正成立。