模型路由策略：什么任务该走哪一档
数据截至 2026-07，价格与限额以各官网为准。
模型路由真正要解决的不是”哪个模型更聪明”，而是”这个任务错了我要付多大代价”。把任务按失败代价分档，再让便宜的档去做那些错了一眼就能看出来、改一遍成本很低的活，贵的档只留给改不动、验不了、错了会往下游传的活——这套分法比任何模型横评榜单都更能直接省钱，而且它不会因为下个月出了新模型就作废。
先说一个很常见的误解：不少人以为路由策略就是”简单任务用小模型、复杂任务用大模型”。这句话不能算错，但它在实操里几乎没有指导意义——因为”复杂”是个事后判断，你在发请求之前并不知道这道题复杂不复杂。真正能在代码里写成 if-else 的，是任务的形状：它的输出可不可以被机器验证？它要读多长的上下文？它错了之后由谁来兜底？这三件事在发请求之前就是已知的，所以它们才配当路由的依据。
先把”档”定义清楚，再谈路由
路由的前提是分档。我一般分三档，判据只看三个信号。
第一个信号：输出可不可验证。 如果输出能被单元测试、schema 校验、正则、编译器直接判对错，那它天然适合低档模型——因为错了会被立刻挡住，你付出的代价只是重跑一次。反过来，如果输出是一段没人能马上判断对错的分析、方案、总结，错了会被人当成真的往下用，那它必须走高档。
第二个信号：上下文长度。 短上下文的任务，小模型和大模型的差距常常没那么大；一旦要塞进十几个文件、几万字的资料，弱模型的表现会掉得比你预期快得多——它不是答错，而是开始漏看、开始只盯着上下文开头那部分。跨文件、跨长文档的任务不要往低档扔。
第三个信号：失败代价谁承担。 有人复核的环节和直接发给客户/直接写进数据库的环节，是两种风险等级。前者可以激进，后者要保守。
按这三个信号，三档大致长这样：
- 低档（跑量档）：格式转换、字段抽取、分类打标、生成测试数据、批量改写文案骨架、把一段代码翻成另一种语言的骨架、commit message 草稿。特征是输出短、可验证、错了重跑就行。
- 中档（主力档）：日常写代码、写单个函数、改一个模块的 bug、写文档初稿、做结构化摘要。它承担你 70% 以上的调用量，是成本大头，也是最值得反复调优的一档。
- 高档（关键档）：跨文件重构、架构方案权衡、复杂 bug 的根因分析、涉及金额和合规的判断、对外直接可见的最终稿。特征是错了很贵、而且不容易当场发现。
这个分法有一个很实际的好处：它跟具体模型解耦。模型清单每隔几个月就会变，但”这道题错了我赔多少”不会变。你只需要在配置里换一下每档对应的模型 ID，策略本身不用重写。
网关层是路由最合适的落点
路由逻辑写在哪儿？三个位置都有人做：写在业务代码里、写在 SDK 封装层里、写在网关里。我的建议是往网关放。
原因很简单：路由是”随时要改”的东西，而业务代码是”不该经常动”的东西。把模型选择硬编码进业务逻辑，意味着每次调整档位都要改代码、走一遍发布流程。放在网关里，业务侧只需要认一个统一端点，换模型、加回退、调比例都是网关侧的配置动作。
开源方案里，OmniRoute 是个比较典型的样本，可以拿来理解网关层能给路由提供什么。它是 MIT 协议的免费 AI 网关，仓库自述接入了 290 多家供应商（其中 90 多家有免费档）、500 多个模型，覆盖 Kimi、Claude、GPT、OpenAI、Gemini、GLM、DeepSeek、MiniMax 等；它由 9router fork 而来，是 Go 项目 CLIProxyAPI 的 TypeScript 移植。它的核心用法是把所有 AI IDE 和 CLI 的接入点统一配置成 http://localhost:20128/v1，之后换模型这件事就不再需要动客户端。
装起来很轻：
npx omniroute@latest
或者用 Docker：
docker run -p 20128:20128 diegosouzapw/omniroute
跑起来后打开 http://localhost:20128 就是面板。常用命令里跟路由关系最直接的是 omniroute models --search <term>，用来查某个模型当前在哪些供应商下可用（同样的信息也可以走 GET /api/models/catalog 拿），omniroute doctor 用来自检，omniroute setup 是首次运行向导。仓库称一共有 80 多条命令。
需要提醒的是，这类第三方聚合网关的本质是把各家凭证交到一个本地代理手里。用之前请自己评估凭证保管、日志留存和所在团队的合规要求，这篇不对任何具体网关做背书。
模型 ID 怎么填：auto 和显式指定各自的边界
网关侧配置路由，绕不开一个选择：模型名到底写死，还是写 auto。
OmniRoute 支持把模型填成 "auto"，由网关自动挑选。这个能力适合两类场景：一是你在做探索性尝试，还没定下用哪家；二是低档的跑量任务，反正输出会被校验挡一道，挑到哪个都不至于出事。
但主力档和关键档我建议显式写死模型 ID。理由是可复现性：如果一段提示词今天效果好、明天变差，你需要能确认”到底是提示词变了还是模型换了”。auto 会让这个排查变得很难。写死之后，模型变更就是一次显式的配置改动，有记录、可回滚。
填 ID 时用供应商的原生格式，仓库里给的示例形如 claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5。有些名字带点号版本号看着别扭，那是上游 API 本身就要求的写法，别自己”规范化”成横杠。填错模型名的表现通常是一个 model not found 类的报错，先去 models --search 里核一遍名字，比在代码里猜省时间。
回退链：路由策略里最容易做歪的一环
多接几家供应商就能启用自动回退（fallback），OmniRoute 的回退是配额感知的——某家额度用完了会自动往下一家走。这个能力很实用，但排回退链的时候有个原则经常被忽略：回退链上的每一档，能力都必须够用。
常见的错误做法是按价格从低到高排回退，觉得”先试便宜的，不行再往上”。问题在于 API 层面的失败大多是限流、超时、额度耗尽这类信号，而不是”答得不好”——网关没法判断答案质量，它只能判断请求成没成功。所以便宜模型答了一个平庸但格式合法的结果，回退链根本不会触发，你以为自己走的是高档，实际上一直在低档上跑。
正确的排法是：同一档内横向回退，不跨档降级。关键档的回退链上挂的应该是另外几家能力相当的模型，而不是把跑量档塞进去兜底。如果你确实需要”贵的挂了就用便宜的顶一下”，那要在业务侧显式标记这次结果是降级产出的，让下游知道它的可信度不一样。这部分展开可以看站内的 多模型 fallback 怎么设计。
免费档在回退链里是个不错的补位。OmniRoute 的目录声称有 90 多家带免费档、40 多家永久免费，免费选项包括 Kiro、OpenCode Free、Pollinations，文档建议新手从 Kiro AI 起步——免费、不需要 API key、可以用到 Claude 系模型。仓库还给过一个零成本组合示例：gemini-cli/gemini-3-flash-preview（每月 180K 免费）→ if/kimi-k2（无限免费）→ qw/qwen3-coder-plus（无限免费）。
这里必须泼一盆冷水：免费额度类信息变动极快，上面这些名称和额度以仓库文档当前版本为准，“无限免费”是仓库的表述，不是任何人对你的承诺。把它当成”今天恰好能省钱的备选”可以，把它当成生产链路的地基不行。相关的免费档组合思路，站内另有一篇 OmniRoute 免费组合怎么搭 讲得更细。
上下文长度也要参与路由决策
前面提过上下文是分档信号之一，这里补一个实操层面的做法：把”进不进得下”和”该不该进”分开看。
很多任务之所以被迫走高档，不是因为难，而是因为塞了太多没用的上下文。把无关文件、历史对话、重复的系统提示先削掉，任务的实际难度往往会掉一档。OmniRoute 内置了 RTK + Caveman 压缩，仓库称能省 15% 到 95% 的 token——这个区间跨度很大，说明省多少完全取决于你原本冗余到什么程度，别把上限当预期。
我的做法是：先靠上下文治理把请求瘦下来，再决定路由档位。顺序反了的话，你会为一堆无效 token 支付高档价格。这块的系统方法可以看 Token 成本怎么优化 和 上下文工程怎么做。
怎么验证这套路由真的省了钱
路由策略最怕的状态是”感觉省了”。要让它变成可核对的事实，至少做三件事。
第一，按档记账，不要只看总花费。 分档统计每档的调用次数和 token 消耗。如果发现高档的调用占比远超你的预期，说明分档规则在实际业务里没落实，或者有人为了省事把所有请求都往高档扔。
第二，给低档设一道验证闸。 低档之所以敢用，前提就是输出可验证。所以每一条走低档的链路都要配上对应的校验（schema 校验、跑测试、格式检查），并且统计校验失败率。失败率长期偏高，说明这类任务不该在低档，该往上挪一档——这是数据驱动的调档，比争论”哪个模型更强”有用。
第三，做一次固定样本的对照。 挑二三十条真实历史请求当固定样本，换档位时用同一批样本跑一遍，人工抽检结果。样本固定下来之后，你就有了一把尺子，以后每次模型变更都能量一下，而不是靠记忆判断”好像变差了”。
成本核算方面还有个提醒：本文不列任何具体单价。各家价格调整频率很高，写死在文章里的数字过两个月就是错的，请以你实际调用的那家官方计费页为准，网关面板里显示的用量也只是参考口径。站内的 API 成本监控怎么做 讲了怎么把这件事变成日常动作。
涉及海外厂商的一个前提
路由表里如果排进了 OpenAI、Gemini、Claude、Grok 这类海外厂商的模型，有件事要提前说清楚：这几家官方并未把中国大陆列为受支持地区，注册、控制台与 API 端点都在境外。 其中 Anthropic 的官方受支持地区列表不含中国大陆（anthropic.com/supported-countries），xAI 也没有面向中国大陆的官方开放渠道。
市面上确实存在第三方中转、聚合类服务，但其合规性、稳定性与数据处理方式需要使用者自行核实并承担风险，本文不提供也不背书任何具体渠道。准入政策会变，请以各厂商官网当前的地区政策页为准。这一点对路由策略的实际影响是：不要把准入不确定的模型排在关键档回退链的唯一位置上，否则一旦链路断掉，你的高风险任务会失去兜底。
这套策略的局限，得说清楚
第一，路由解决的是”用哪个”，解决不了”提示词写得烂”。一段结构混乱、目标模糊的提示词，换到高档模型上只是把错答得更流畅。分档之前先把提示词整理清楚，收益比调路由大。
第二，任务分档在边界地带一定会有争议。比如”写一个中等复杂度的函数”到底算中档还是高档，不同团队会有不同答案。别追求精确，先定一个粗规则跑起来，靠上面说的校验失败率去调整，比在会议室里论证一个月有用。
第三，网关本身也是一个故障点。所有流量收敛到一个本地端点，这个端点挂了就是全线中断。做关键业务的话，至少要有一条绕过网关直连的应急路径，并且定期演练一次。
第四，本文引用的 OmniRoute 相关能力和数字都来自仓库自述与其文档，供应商数量、星标数在不同来源口径并不一致，免费额度更是随时可能调整。把它当成”理解网关能做什么”的样本读，具体配置以你安装的那个版本的文档为准。想先动手把它跑起来，可以看 OmniRoute 上手。
小结
模型路由的核心判据是失败代价，不是模型排名——先问”错了谁兜底”，再问”用哪个模型”。分成低中高三档，判据只看输出可否验证、上下文多长、失败由谁承担，这套分法跟具体模型解耦，模型换代也不用重写。路由逻辑落在网关层最合适，业务侧只认一个统一端点，换模型是配置动作而不是发布动作；跑量档可以用 auto，主力档和关键档建议显式写死模型 ID 以保证可复现。回退链要同档横向排，不要跨档降级，否则你以为在走高档、实际一直在低档上跑。最后，路由省下来的钱要靠分档记账、校验失败率和固定样本对照来证明，“感觉省了”不算数。