多模型回退怎么设计：别等主力挂了才想起来
数据截至 2026-07，价格与限额以各官网为准。
多模型回退真正难的地方不是”再接一个模型”，而是想清楚三件事：什么信号才算主力不可用、切过去之后你的提示词和输出解析还成不成立、以及这条链路平时有没有人验证过。绝大多数所谓的回退方案在真出事那天不生效，原因不是代码写错了，而是备用那条路从配好之后就再没跑过一次。
一个常见的误解是把回退等同于 try / except 里换个模型名重试一次。这个写法在演示里当然能跑，但它默认了一个很强的前提：备用模型跟主力模型接口一致、输出风格一致、上下文长度够用、当时确实可用。这四条只要有一条不成立，回退的结果就是从”一次失败”变成”两次失败加一倍延迟”。下面按真实排查顺序把这件事拆开讲。
先决定回退做在哪一层
回退可以放在三个位置，选错了后面全是返工。
放在业务代码里：在调用模型的函数里写 for 循环遍历候选列表。好处是逻辑透明、想加什么判断都行；代价是每个服务、每个语言、每个团队都要写一遍，而且供应商的鉴权配置会散落到各处。适合只有一两个调用点的小项目。
放在自建的服务层：团队内部包一个统一的推理服务，业务只调你自己的接口，回退在服务里做。好处是账单、审计、限流都能收口；代价是你得自己运维这层，出故障时排查链路多了一跳。团队规模上来之后这条路基本是必然的，取舍细节可以看AI 网关怎么选：自建、聚合平台与本地代理的取舍。
放在本地网关 / 代理里：不改一行业务代码，把 base_url 指向一个本地端点，由它负责选路和回退。开源项目 OmniRoute 走的就是这条路——它是 MIT 协议的开源 AI 网关，仓库自述一个端点聚合 290+ 供应商、500+ 模型，配置统一填 http://localhost:20128/v1，Claude Code、Cursor、Cline 这类工具都指过来。它本身由 9router fork 而来，是 Go 项目 CLIProxyAPI 的 TypeScript 移植。
对个人开发者和小团队，第三条路上手成本最低，因为你要改的只是一处 base_url。但要提前认清它的性质：这是把各家凭证交给一个跑在本机的第三方代理，凭证管理和合规风险得自己评估，不能因为它开源就默认无风险。
什么信号才算”该切了”
这是回退设计里最容易糊弄过去的一步。粗暴的做法是”只要抛异常就切下一个”，结果往往是本来能重试成功的临时抖动被无谓地降级到了更弱的模型，甚至把一个你自己写错的请求在整条链路上依次撞一遍。
建议把错误分成三类，分别对待：
- 限流类（典型是 HTTP 429、或者返回体里明确写了配额耗尽）：这类是最该触发回退的信号。同一个供应商此刻就是没有余量，原地重试只是排队。如果响应头里带了建议的等待时间，短的可以等，长的直接切。
- 服务端故障类（5xx、网关超时、连接被重置）：先原地退避重试一到两次，因为这类经常是几秒内自愈的抖动；重试仍失败再切下一个。
- 请求本身有问题类（鉴权失败、参数非法、模型名不存在、内容被策略拦截）：不要回退。换个供应商结果还是一样错，只是把一次报错变成 N 次报错，还把日志搅浑了。鉴权和参数问题应该直接抛出来让人看到。
另外补一类容易漏的信号：没报错但结果不可用。比如返回了空字符串、返回内容无法按你要求的 JSON 解析、或者迟迟不吐第一个 token。这类”软失败”要不要触发回退，取决于你的场景能不能接受多花一倍时间。做交互式产品建议设一个首字节超时，超过就切；做离线批处理则更适合原地重试。
回退链的顺序怎么排
排序的原则是：每往后退一格，都要明确你在牺牲什么。常见有三种排法。
按成本排：先用免费或便宜的，扛不住再上贵的。适合个人开发者和试验性项目。OmniRoute 仓库给过一个零成本组合的示例，是 gemini-cli/gemini-3-flash-preview（每月 180K 免费）→ if/kimi-k2（无限免费）→ qw/qwen3-coder-plus（无限免费）这样一条链。这里必须说明白：免费档信息变动极快，上面这几项是仓库文档里的示例写法，实际还在不在、额度还是不是这样，一律以仓库文档当前版本和各家官网为准，不能当成承诺。
按质量排：主力用你验证过效果最好的那个，回退到次一档。适合线上业务——宁可慢一点、贵一点，也别让用户拿到明显变差的答案。
按可达性排：把网络链路上最稳的放前面。这一点在国内环境下权重经常比前两条都高，因为一个模型再强，连不上就是零分。
实操上更推荐的是混合排法：第一格是”质量够 + 平时能连上”的主力，第二格是跟主力不同供应商、不同网络路径的同档模型，第三格才是明显更弱但一定能出结果的兜底。注意第二格那个”不同供应商”很关键——如果你的一二档其实托管在同一家背后，那家一挂两格一起没，链路等于只有一格。
切换之后，别让上下文和格式先崩
这是回退方案上线后翻车最多的地方。模型切了，可你的提示词还是照着主力模型的脾气写的。
上下文长度要按链路里最短的那个模型来设计。如果主力吃得下很长的上下文，你的代码就敢一次塞进去，等回退到一个窗口更小的模型时，请求会直接被拒。稳妥做法是给整条链路定一个统一的输入上限，超了就先做截断或摘要，而不是指望每个模型都接得住。
输出格式要做防御式解析。同一段”请返回 JSON”的指令，不同模型的听话程度差别很大，有的会老老实实吐纯 JSON，有的会在外面裹一层代码块或者加一句解释。解析代码应该先剥掉常见的包裹再解析，解析失败时能重试一次并附上错误提示，而不是直接把异常抛给用户。
模型 ID 的写法也是个坑。走网关时，模型名通常用供应商的原生格式，比如 OmniRoute 仓库示例里出现的 claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5，其中带点号的版本号是因为上游 API 本来就那么要求。硬编码这些字符串意味着上游一改你就得跟着改，建议在配置文件里集中管理，别散落在业务代码各处。OmniRoute 也支持把模型填成 "auto" 让网关自动挑选，省事，但代价是你放弃了对”这次到底用了哪个模型”的直接控制，做质量归因时会麻烦一些。
别忘了成本和质量的可观测性：每次调用记下实际落到了哪个供应商、哪个模型、耗时多少。没有这份日志，你既不知道回退有没有在悄悄发生，也解释不了某天用户为什么觉得”变笨了”。
用 OmniRoute 落一条链路的具体步骤
如果你决定走本地网关这条路，最短路径大致是这样：
- 起服务。
npx omniroute@latest，或者用 Docker：docker run -p 20128:20128 diegosouzapw/omniroute，然后打开http://localhost:20128。首次跑可以用omniroute setup走向导，装完不放心用omniroute doctor自检一遍。 - 加供应商。面板左侧 Providers → + Add Provider → 搜索点选，免费供应商无需凭证可直接 Connect，加完务必点 Test Connection 验一下。认证类型分四种：OAuth（由网关代管登录、不用 API key）、web cookie、API key、以及 Local（Ollama、LM Studio、vLLM 这类本地推理）。
- 接够两个以上能用的供应商，自动回退才有意义——只接一个，网关就只是个转发器。
- 查模型可用性用
omniroute models --search <term>，别凭印象猜某个模型在不在。 - 业务侧把 base_url 指到
http://localhost:20128/v1。想先试手感可以直接omniroute chat开个交互式 TUI。
更细的安装与面板操作可以看OmniRoute 上手，专门讲免费档怎么串成零成本链路的在用 OmniRoute 拼一套零成本模型组合。
网关另外提供了配额感知的自动回退，以及仓库称能省 15-95% token 的 RTK+Caveman 压缩。压缩这类功能建议先小范围验证再全量开——省 token 的另一面往往是信息损失，你的任务对上下文完整性有多敏感，只有你自己测得出来。
演练：回退方案最缺的一环
写完不等于能用。给三个成本很低但有效的验证动作：
- 人为断掉主力：把主力供应商的凭证临时改错，或者在网关里把它禁用，看请求是不是真的落到了第二格，落过去之后结果还能不能用。
- 看日志里的降级比例：如果某天回退触发率突然上升，说明主力已经在悄悄出问题了，这比等用户投诉早得多。
- 定期复查上游是否还在：免费档尤其如此。仓库自述有 90+ 供应商带免费档、40+ 永久免费，但这类信息变动极快，最好每隔一段时间跑一次连通性测试，而不是等真出事那天才发现备用那条早就断了。
什么情况下不该做多模型回退
诚实说几个不适用的场景：
- 对输出一致性要求极高的任务。比如结构化抽取要跟历史数据严格对齐，换模型带来的风格漂移可能比一次失败更麻烦，这种情况更适合失败就报警重试，而不是静默降级。
- 合规和数据边界严格的业务。回退意味着你的数据可能流向另一家供应商，如果合同或内部规范限定了数据只能给谁处理，回退链必须先过合规这一关。
- 调用量极小的个人脚本。一天跑几次的东西，出错手动重试一下就好，为它维护一条回退链纯属过度设计。
还有一件必须诚实说明的事：OpenAI、Gemini、Anthropic 等厂商官方并不支持中国大陆直连，这是准入层面的现实，不是网络慢的问题。市面上确实存在第三方中转和聚合服务，但其合规性、计费透明度、数据处理方式都需要使用者自行核实和承担风险，本文不做背书、也不推荐具体渠道。做回退设计时，把”这一格在我的网络环境下到底连不连得上”当成硬约束来排，比事后补救省心得多。
小结
回退不是备胎，是你系统里第二条真正会被走的路。信号要分类，限流和服务端抖动才值得切，请求本身的错误切了也没用。链路顺序要明确每退一格牺牲了什么，且相邻两格最好不在同一家背后。切换之后上下文上限按最短的那个模型定、输出解析写成防御式的，否则模型切成功了业务照样崩。落地上，本地网关能让你不改业务代码就把这套跑起来，OmniRoute 是这条路上一个可选项，但它同样是把凭证交给一层代理，值不值得由你的场景决定。最后，定期演练一次比方案写得多漂亮都重要。