模型路由这件事，本质是个后端问题

最近在做一个 side project，需要同时调好几个大模型的 API。一开始很简单，就是一个 HTTP 请求包一层，后来需求慢慢变复杂：简单任务走便宜的模型、复杂推理走强的、高峰期自动切备选、不同地区走不同云。写到第三个 if-else 的时候我就意识到，这东西不应该手搓。

正好最近几条新闻放在一起看挺有意思的。

7 月 1 号，GitHub Copilot CLI 上线了自动模型选择，能根据任务类型、模型实时可用性和成本自动路由到最优模型。7 月 10 号，OpenAI 发了 GPT-5.6，号称性能全面超越 Claude，但最炸的点是价格——最低只有竞品的十六分之一。再往前几天，腾讯混元 Hy3 发布，MoE 架构、激活参数 21B，推理成本压到了旗舰模型的几分之一。

这三件事指向同一个趋势：模型不再稀缺了，选择变多了，但「选哪个」这件事本身变成了新的复杂度。

模型多了，麻烦也多了

一年前大部分人的用法很简单：接一个最强的模型，完事。现在不一样了。真实业务里你大概率会遇到这些场景：

• 简单问答走低成本模型，复杂代码任务走强模型
• 敏感数据走私有化部署，普通请求走公有云
• 海外用户走海外模型，国内用户走国内模型
• 高峰期某个模型挂了或限流了，自动切到备选

这还没算上 Token 消耗监控、按团队/项目计费、合规审计这些企业级需求。

如果你只有一个模型，你写一个 HTTP Client 就够了。但当你有五个模型、三个云、两个区域，这件事就从「调 API」变成了「做网关」。而做网关，是后端工程师的老本行。

LiteLLM：一个值得关注的方案

说到模型网关，LiteLLM 是目前社区最活跃的开源方案。240M+ Docker 拉取量、10 亿+请求量、1000+贡献者，Netflix 也在用。

它的核心思路很简单：把 100+ LLM Provider 的接口统一成 OpenAI 格式。你不管是调 GPT、Claude、Gemini 还是混元，代码里写的都是同一套 litellm.completion()。支持流式输出、function calling、embeddings，对现有代码的侵入性很小。

但我更关注的是它的 Proxy Server 模式。在这种模式下，LiteLLM 就是一个自托管的 AI Gateway，能做的事情远不止接口翻译：

• 负载均衡：多个模型实例之间按 RPM/TPM 分配流量
• 故障转移：主模型挂了自动切备选，用户无感知
• 预算和限流：按 key、用户、团队维度设置消费上限
• 花费追踪：自动统计每个维度用了多少 Token、花了多少钱
• Guardrails：请求和响应两端做内容过滤

说白了，这就是把微服务网关那套东西搬到了 LLM 场景里。鉴权、限流、路由、降级、监控——每一样都是后端工程师做了十几年的活。

GitHub Copilot 的选择：让用户别选了

GitHub 的做法更激进一些。Copilot 的自动模型选择直接帮你屏蔽了「选模型」这个步骤：用户只看到「Auto」一个选项，系统根据任务复杂度、模型实时健康状况和可用性自动决定用哪个。

他们的判断逻辑大致是这样的：评估当前任务需要多强的推理能力、代码生成复杂度、bug 诊断难度、工具编排需求，然后结合各模型的实时延迟和错误率，选一个最优的。而且路由决策会沿着自然缓存边界走，避免频繁切换导致缓存失效带来的额外成本。

这个设计思路我很认同。用户真的不需要知道背后调的是 GPT-5.6 还是 Claude 还是 Gemini，他只需要知道「这活能干好」。就像你用搜索引擎不会关心它调了哪个索引、走了哪条检索链路一样。

不过我猜很多团队抄不了这个作业。GitHub 能这么做是因为它是模型消费者，自己不做模型，可以没有包袱地在各家的模型之间横跳。但国内很多公司是自己训模型的，或者跟某个云厂商有深度绑定，模型选择就不是纯技术问题。

这件事到底难在哪

我觉得模型路由难的不是算法——你不需要一个神经网络来帮你选模型。难的是一套稳定的工程基础设施。

第一是协议一致性。虽然大部分 Provider 的 API 都长得像 OpenAI，但总有各种小差异。有的不支持 streaming 下的某个参数，有的 function calling 格式稍有不同，有的返回的 token usage 字段名不一样。LiteLLM 的 1000+ 贡献者，一大半的 PR 都在填这种坑。

第二是可观测性。当你同时跑了五个模型，你必须知道每次请求走了哪个模型、花了多少 Token、延迟多少、失败原因是什么、有没有触发敏感数据规则。这些数据不光是运维用的，也是算账用的——你可能需要按团队、按项目、按功能模块来分摊模型成本。

第三是灰度能力。大模型更新很快，新版本上线前你得先切 5% 流量试试水。这不就是微服务体系里的金丝雀发布吗？模型切换不应该靠改代码重新部署，应该靠配置中心动态下发。

我的建议

如果你现在只有一个模型、用量也不大，别急着上网关。一个 HTTP Client 加两三个 if-else 够用了。过度设计在早期项目里是毒药。

但如果你已经开始对接多个模型，或者用量在快速增长，我建议早点把模型路由做成一个独立的层。不一定非要用 LiteLLM，自己写一个轻量的也可以，关键是要把「选模型」这个逻辑从业务代码里抽出来。

具体来说，这一层至少要能回答三个问题：

1. 当前请求应该走哪个模型？
2. 如果首选模型不可用，备选是什么？
3. 这次调用花了多少 Token、多少成本？

这三个问题回答清楚了，你的模型接入就从一个「能用」的状态进入了「可运维」的状态。至于后面加限流、加灰度、加预算控制，都是在这个基础上自然生长的。

最后多说一句：别被「AI Gateway」这个名字唬住。它不是什么高深的 AI Infra，它就是一个带业务路由的反向代理。用的全是 Nginx、Kong、Envoy 那套老知识。模型很新，但工程问题很老。