2026/9/7 11:52:48
FEATURED · 精选文章 
这两年做 AI 应用的人基本都感受过同一个痛点模型接口越来越多今天换这家、明天调那家每个供应商的格式、限流、计费逻辑还不一样。早期还能靠代码里写死一个 OpenAI 客户端硬撑可一旦你同时接了 GPT、Claude、Gemini还要跑几个国产开源模型路由就成了躲不开的工程问题。市面上能选的方案也确实多从最轻的 SDK 层路由到 Kubernetes 里自托管网关再到 OpenRouter 这种托管聚合以及这两年很热的智能路由2026 年的选型表格已经铺开了一大片。这篇文章我会把多模型路由的完整选型拆成四层来讲工具侧路由、自托管网关、托管聚合、智能路由。每一层我都会说清楚它解决什么问题、适合什么团队、踩过哪些坑。最关键的结论是这四层不是互斥关系而是一条路径你随着业务体量增长一层一层往上爬。我会结合我这几年实际跑过的方案和改造经历把每一步的取舍、成本和判断标准都写出来。1. 四层架构全景先搞清楚每一层到底管什么多模型路由从字面上看好像就是“把请求转发给合适的模型”但在实际系统里这一句话背后叠加了四个完全不同层面的事情。我平时跟团队聊选型的时候第一件事就是先把这四层拆开定义清楚否则所有人围着“路由”两个字争论半天其实聊的压根不是一个东西。先画一个坐标系。最底层是你代码里的调用层也就是你实际用 SDK 还是 HTTP 裸调去访问模型这一层对应的是工具侧路由。再往上一层是统一的入口所有模型流量在到达大模型服务商之前先进一个团队自己控住的网关这一层就是自托管网关。如果你不想自己运维网关直接买一家托管服务商的聚合 API走的是托管聚合。而智能路由可以理解为横跨前面所有层的决策大脑它负责回答“这个请求到底该发给谁”本身可以做成网关插件也可以做成独立服务。四层之间不是简单的“哪个替代哪个”的关系。工具侧路由是代码层面的灵活性适合个人项目或者早期验证自托管网关是基础设施层面的可控性适合有一定工程能力的团队托管聚合是省心优先适合业务还没到规模、不想投入运维成本的公司智能路由则是在前两者基础之上叠加的优化层用得好能压成本、提质量用不好反而拖慢请求。我给出一个很实际的判断标准你团队现在被模型 API 的什么问题卡住了。如果是“切换供应商要改代码太麻烦”工具侧路由就能解决。如果是“每个服务各自接 API密钥散落各处没法统一治理”你需要的是网关。如果是“完全不想关心底座是谁只想按量付费、稳定可用”托管聚合更合适。如果是“模型很多怎么选最优、怎么控成本”那答案在智能路由里。大多数团队真实的情况是同时卡在好几个地方所以选型千万别只盯着某一个名词。还有一点值得强调这一层一层的演进本质上是在往“把模型供应商当作可替换资源”的方向走。我见过很多团队第一步从工具侧路由起步代码里先用一个简单的 switch 管理模型名到后来某个接口故障导致线上事故才意识到需要网关做故障转移。这不是他们判断力差而是业务规模还没到那个触发点。所以我建议你把四层全部看完再对照自己的现状决定停在哪一层别急着一步到位。2. 工具侧路由最轻量但也最容易给自己埋坑工具侧路由说白了就是在你的代码里、在 SDK 或者 HTTP client 这一层做转发和切换。市面上没有太多独立的产品叫“工具侧路由”它更像是你代码架构里的一个设计模式不引入外部组件靠一段抽象逻辑把多模型调用管起来。2.1 三种常见的代码层实现方式第一种最简单直接在业务代码里封装一个 ModelRouter 类内部维护一个模型配置表然后对外暴露统一的 chat_completion 接口。这个接口接收 model 名、messages、temperature 这些参数内部根据 model 名映射到具体的 SDK client 上。我早期写 AI 应用就是这么干的最开始只接 OpenAI 一个供应商后来要加 Claude就在这个类里增加一个分支几十行代码搞定。第二种是基于社区现成的多模型 SDK比如 LiteLLM 的 Python SDK、Portkey SDK 这类。它们虽然也带网关能力但你完全可以在不部署任何服务的情况下只 import 一个库来用。这种方案比你自己手写 Router 类强在供应商适配层已经帮你做好了统一成了 OpenAI 兼容格式切换模型只需要改模型名比如把gpt-4o换成claude-sonnet-4,官方还处理了不同服务商的参数差异。第三种是我后来才意识到的工具侧路由不一定非要在业务进程里做你的 CI/CD 流程、测试环境、本地开发环境都可以用工具侧路由的思路。比如本地开发时所有请求自动打到 mock 服务或者低成本的模型测试环境走预发布模型配置生产环境才走正式渠道。这种方式我称为“环境级路由”一般通过环境变量加配置文件就能实现。2.2 工具侧路由的红线在哪里工具侧路由看起来轻巧但它有明显的边界。最核心的一条就是它只能在“单实例、单区域”的前提下工作。你的应用一旦有多个副本同时运行每个副本都有自己的一份路由逻辑和模型密钥那你很快就发现无法做全局限流和统一监控。某个副本的 token 消耗超标你得翻到对应 Pod 的日志里才能定位。第二个坑是故障转移能力薄弱。代码层的重试逻辑通常只解决“请求失败重试一次”的问题但对于模型服务商级别的故障比如某个大模型 API 连续五分钟 5xx代码层很难及时感知并自动把流量切走。你可能需要自己写健康检查、自己维护熔断状态而这个维护成本会随着接入的模型数量线性上升。第三个坑是安全位置不对。密钥写在环境变量里比写在代码里安全但依然散落在每个运行实例上。如果你的应用被人拿到了某个 Pod 的持久化环境变量等于拿到了所有模型供应商的钥匙。我见过不止一个团队因为密钥管理不规范在日志里误打了完整的 API key最后只能紧急轮换。所以我的建议是工具侧路由适合三个场景——个人项目、原型验证、还没有多个后端服务的小型单体应用。你的核心目标应该是把事情跑通而不是为了将来的扩展提前设计一个微服务架构。一旦你的业务开始有多个服务都需要调模型或者你开始关注成本分摊、按项目限额就该考虑把路由层往上提了。3. 自托管网关生产环境真正的核心枢纽如果你需要在全公司或者一个多服务架构里统一管模型 API自托管网关基本是绕不开的一环。我这里的“自托管”指你自己控制部署形态可以是一台云主机上的 Docker Compose也可以是 Kubernetes 集群里的 Helm Chart甚至就是一台内网服务器。控制的权力在你手里出事的责任也在你身上。3.1 选型对比LiteLLM、Portkey Gateway 与通用网关2026 年这个时间点自托管网关的头部玩家已经很明确LiteLLM 是事实标准Portkey Gateway 是强力挑战者Kong AI Gateway 和 Higress 是通用网关阵营里专门做 AI 扩展的。LiteLLM 我用了最久它最核心的优势是支持极其广泛的模型供应商列表官方文档号称覆盖 100 家以上实测非常接近。它对外暴露一个 OpenAI 兼容的/chat/completions端点你完全可以把 base_url 指到 LiteLLM 服务现有代码一行都不用改。它还内置了成本追踪、负载均衡、重试和 fallback配合 Redis 可以做多实例共享状态。生产环境我建议部署模式是 LiteLLM PostgreSQL Redis 组合PostgreSQL 存配置和花费数据Redis 做缓存与分布式限流。Portkey Gateway 我在一个需要精细控费的客户项目里用过它最大的差异化是 gateways 天生带可观测性请求日志、token 用量、按 tag 做用量分析都做得很细。它的 guardrails 模块可以做到 request 级的安全检查比如输入的 PII 检测、输出内容的规则校验这在金融和医疗场景很加分。如果你第一诉求是“把模型调用管成标准 API 网关”Portkey 的上手曲线其实比 LiteLLM 更友好。Kong AI Gateway 和 Higress 属于大而全的路线。它们不是为 AI 设计的而是在通用 API 网关上扩展了 AI 插件比如把上游配置成各种模型供应商支持 prompt 模板和限流。这类方案适合什么场景呢你的基础设施里已经重度使用 Kong 或 Higress 了不想为了模型 API 再单独引入一个组件。但反过来说如果你想用它们当模型网关要自己做不少组装工作AI 相关的深度功能比如语义缓存、模型质量评估基本没有需要二次开发。3.2 部署和初始化流程自托管网关的部署本身不复杂难点在配置设计和后续维护。我拿 LiteLLM 举例走一遍完整流程第一步准备部署环境。建议至少 2 核 4G 起步生产环境别省这点资源。用 Docker Compose 的话核心就是三个容器litellm 主服务、postgres、redis。我一般还会加一个 nginx 在最前面做 TLS 终止。Kubernetes 里就用官方 Helm Chart默认参数会拉起 litellm、redis 和 postgres注意把持久化卷配置好否则重启数据就没了。第二步配置模型列表。LiteLLM 的配置文件是一个 YAMLmodel_list下面定义每个模型条目每个条目包含model_name暴露给调用者的名字、litellm_params真实供应商、真实模型名、API key 或 key 环境变量、以及可选的model_info比如支持的最大 token 数、成本定价。我习惯把model_name统一成业务层的命名比如primary-llm、fast-llm、cheap-llm这样以后切换具体模型时调用端完全感知不到。第三步配置密钥和鉴权。LiteLLM 有一个 master key所有请求必须带这个 key 或者用它生成虚拟 key。生产环境我强烈建议给每个服务、甚至每个项目单元生成独立的虚拟 key这样你能精确知道谁的用量是多少。在general_settings里关闭掉不需要的选项比如关闭/sso等管理端路由尽量把管理 API 和模型 API 分开暴露。第四步配置负载均衡、重试与 fallback。router_settings里有routing_strategy可以用simple-shuffle或least-busy。这里我想强调网关的负载均衡不是简单的“轮询”或“随机”你还要考虑每个模型的价格不同、上下文不同。我一般按模型组来配置高能力组、中能力组、低成本组调用方按业务语义指定组名网关在里面做具体模型选择和故障转移。第五步配置可观测性。LiteLLM 天然支持 Prometheus metrics我建议在 Grafana 里配好四个核心面板请求量、p50/p95 延迟、token 消耗、按模型分组的花费。别等出了问题再补监控网关上线第一天就要有这些面板。3.3 网关的隐藏成本和运维细节自托管网关最大的坑不是装不起来而是运维责任全在自己身上。模型供应商 A 的限流策略变了你的重试逻辑要跟着调供应商 B 的某个模型下线了你要在配置里把流量切走Redis 挂了限流和分布式缓存全部失效流量直接打到模型服务商。这些事情每一件都真实发生在我维护过的网关里。安全上有几个点容易被忽略。网关本质上是帮你转发 API key 的中介所有上游模型的 key 都存在它的配置里所以网关所在服务器的安全级别应该等同于你核心数据库的级别。另一个隐蔽问题是 SSRF如果你允许用户传入自定义 base_url攻击者可能让你的网关替他访问内网地址。LiteLLM 有相关防护参数的部署时必须确认开关打开。还有成本问题。网上都说 LiteLLM 免费开源但你要算一下维护成本一个生产网关每月至少需要一个人天来配置变更、盯告警、处理故障。如果你的团队没有专职 SRE网关的维护很容易变成“嘴上说重要、实际没人管”的黑洞。这也是许多小团队最后选择托管聚合的原因之一。4. 托管聚合与智能路由把复杂度交给供应商把决策交还给策略托管聚合和智能路由一个是部署形态的差异一个是决策能力的升级。托管聚合是你不需要自己部署任何组件直接注册一个服务商的账号拿到一个 API key然后把请求打给它的聚合端点由它转发到各家模型。智能路由则是你在路由环节加入了“自动选择模型”的判断逻辑可以发生在你自己代码里、自托管网关里也可以发生在托管聚合服务商那侧。4.1 托管聚合重点服务商盘点OpenRouter 与云端大厂OpenRouter 是我个人项目里用得最多的。它最突出的价值是模型种类极多社区发布的开源模型、各家商业模型的预览版经常第一个在 OpenRouter 上线。它的计费方式是预充值按量扣费对个人开发者很友好不用跟每个模型供应商单独签约。OpenRouter 也有 fallback 参数当你指定一组模型时它会按顺序尝试直到有模型成功返回这在你的应用对某些模型的稳定性没把握时非常有用。AWS Bedrock、Azure OpenAI 这类云端厂商的聚合服务则是企业场景的主导者。它们最大的优势在于模型 API 的契约关系你可以跟企业签一个合同把多家模型的用量都开在一张账单里同时满足数据驻留的合规要求。AWS Bedrock 的用户体验说句实话它的控制台和管理 API 比炫酷的创业公司产品粗糙不少但它的合规审计能力、网络隔离能力、私有化部署演进路径才是大企业买单的理由。Cloudflare AI Gateway 是另一个值得关注的玩家它更像是一个托管形态的网关层你可以在它上面配置自己的上游模型接口它帮你做缓存、限流和可观测性。它的优势是默认在全球边缘节点运行对你的用户来说延迟很低再加上 Cloudflare Workers 的生态AI 网关和你的 Worker 应用可以靠得很近。适合已经在 Cloudflare 生态里做开发的中小型团队。4.2 智能路由从“转发”到“判断”智能路由这个词这几年被说烂了但真实的智能路由其实没有那么多玄学。它的本质是给路由加一个策略决策层在收到请求的时候系统不只是按一个固定配置转发给某个模型而是结合请求内容、上下文长度、成本预算、当前各模型的健康度和响应质量动态选出最合适的模型。具体的实现我拆成三个子模块。第一是请求理解模块它分析请求本身的特点是翻译任务、代码生成任务还是复杂推理任务预估所需的上下文长度判断是否涉及敏感内容。第二是策略引擎它读取一组可配置的规则比如“成本上限 0.01 美元每次请求”“p95 延迟不得超过 3 秒”“所有代码生成请求必须走模型 A”把请求理解模块提取的特征和这些规则做匹配生成候选模型列表。第三是决策模块根据每个候选模型的实时健康度、当前负载、价格和预估精度给候选模型打分选最高分执行。我再解释一下为什么这个架构比简单的“规则路由”更实用。规则路由只能处理你写死的场景比如“客户ID 属于企业版就走模型 A”。但真实请求是连续分布的有些翻译请求简单到小模型就够了有些涉及特定领域的术语小模型会翻译得乱七八糟。硬编码规则没办法穷尽所有情况智能路由可以在运行时根据请求的 token 量和质量反馈动态调整。4.3 智能路由的核心难点质量评估与反馈闭环智能路由最容易翻车的地方就是“你怎么知道这次响应是高质量的”。行业里目前主流做法是 LLM-as-a-judge用一个大模型去给另一个模型的输出打分。这个方法有效但成本高、延迟高不适合在实时链路上做全量评估。我的实践经验是把质量评估做成异步闭环在线请求先按策略路由同时把请求和响应异步推送到评估队列后台用 judge 模型批处理打分分数回写数据库用于下一轮策略的调整。面向用户的实时请求不会被评估逻辑拖慢路由策略又能持续进化。除了质量智能路由的第二个核心输入是成本感知。模型 API 的计费极其复杂按输入 token、输出 token、缓存命中价格、不同地区的价格都不一样。如果你想做成本感知路由必须把每个模型的价格模型建模成一个函数而不是一个常量。更细一点你还可以结合每种任务的 token 消耗规律做预估比如“总结类任务平均输入 3000 token、输出 500 token”再查价格表算出每个模型单次请求的预估成本路由决策时把预估成本作为特征之一。有一个经验我认为值得强调智能路由不是一上来就全自动。我的建议是分三步走第一步只加监控不干预路由先看每个请求落到哪个模型、效果如何、成本多少第二步手工制定一批“必定命中”的硬规则比如“超过 8k 上下文的压缩任务走长上下文模型”把自动化限制在一个安全范围内第三步跑一段时间后再逐步放开策略引擎的自动决策权。很多团队一开始就想做全自动结果模型选错的质量问题直接暴露给用户事后挽回代价巨大。5. 选型决策树与经验谈从哪一层开始在哪一层停下面对这么多的选项团队最常问我的问题就是我们到底该怎么选。我给出一套我个人比较偏好的决策路径供参考。第一步先评估业务量级。日请求量低于一万次、模型调用不超过三个供应商那就先在代码层把路由抽象做好工具侧路由足够。不用过早引入网关因为运维成本可能比模型 API 成本还高。第二步业务量上来了或者你发现需要多团队、多项目共用模型资源那就上自托管网关。选型顺序我建议默认 LiteLLM如果你需要精细的用量分析和审计优先试 Portkey Gateway。这部分不是单项选择题我见过很多团队实际是 LiteLLM 做转发、Portkey 做可观测性两者配合使用。第三步如果你的团队没有足够的 SRE 人力或者业务对稳定性要求极高、但招不到人来维护基础设施那就直接选托管聚合。OpenRouter 适合产品快速迭代期云端厂商的聚合服务适合你有合规和账单整合需求的阶段。这个阶段你可以先不管底层细节所有精力都放在业务逻辑上。第四步当你的模型调用费用开始占业务成本的显著比例或者你实在无法忍受“所有请求都打最强的贵模型”这种花钱方式再引入智能路由。先加监控再做硬规则最后才逐步自动化。别一上来就想要“全智能”。这套路径之外我还想分享几个容易踩的细节。第一无论你选哪一层统一 API 格式都是首要任务。我强烈建议你直接以 OpenAI 兼容格式作为内部标准因为所有主流服务商和开源模型你都能找到一层 OpenAI 兼容适配。这样即使你未来替换掉整个路由层业务代码零改动。第二密切关注上下文缓存带来的计费变化。2026 年多家模型都推出了长上下文缓存比如重复输入的前缀可以打折计费这直接影响智能路由的成本模型。你的成本预估函数必须能区分缓存命中和缓存未命中两种情况否则做出来的成本感知路由完全不靠谱。第三不要把多模型路由当成一个一劳永逸的事。模型能力迭代太快了今天最强的模型三个月后可能排到十名开外你的路由策略配置要允许业务人员方便地调整而不只是工程师改代码发布。我见过做得好的团队会为路由策略配置做一个简单的后台页面运营和算法同学自己就能改某个场景的模型优先级这个投入的回报远高于继续优化路由算法本身。第四路由层虽然解决了很多问题但它绝对无法替代应用层设计。你的应用如果本身没有 prompt 管理、没有输出校验、没有用户反馈收集路由层再智能也救不了产品体验。多模型路由解决的是供给侧问题你要时刻记住需求侧的 prompt 质量、系统稳定性、用户体验才是产品的真正基本功。多模型路由的选型路走到今天已经不是一个“要不要做”的问题而是一个“在哪个层次做”的问题。每一层都有它存在的理由也都有它对应的代价。关键是看清你自己现在所处的位置选一条当前性价比最高的路然后留好往上爬的接口。而我个人的习惯是永远在代码里保留一层轻量的模型抽象同时在上游预留好网关的接入位置——这样无论行业怎么变你都能快速切到最合适的路由方案。
多模型路由选型全解析：从工具侧到智能路由的四层架构
这两年做 AI 应用的人基本都感受过同一个痛点模型接口越来越多今天换这家、明天调那家每个供应商的格式、限流、计费逻辑还不一样。早期还能靠代码里写死一个 OpenAI 客户端硬撑可一旦你同时接了 GPT、Claude、Gemini还要跑几个国产开源模型路由就成了躲不开的工程问题。市面上能选的方案也确实多从最轻的 SDK 层路由到 Kubernetes 里自托管网关再到 OpenRouter 这种托管聚合以及这两年很热的智能路由2026 年的选型表格已经铺开了一大片。这篇文章我会把多模型路由的完整选型拆成四层来讲工具侧路由、自托管网关、托管聚合、智能路由。每一层我都会说清楚它解决什么问题、适合什么团队、踩过哪些坑。最关键的结论是这四层不是互斥关系而是一条路径你随着业务体量增长一层一层往上爬。我会结合我这几年实际跑过的方案和改造经历把每一步的取舍、成本和判断标准都写出来。1. 四层架构全景先搞清楚每一层到底管什么多模型路由从字面上看好像就是“把请求转发给合适的模型”但在实际系统里这一句话背后叠加了四个完全不同层面的事情。我平时跟团队聊选型的时候第一件事就是先把这四层拆开定义清楚否则所有人围着“路由”两个字争论半天其实聊的压根不是一个东西。先画一个坐标系。最底层是你代码里的调用层也就是你实际用 SDK 还是 HTTP 裸调去访问模型这一层对应的是工具侧路由。再往上一层是统一的入口所有模型流量在到达大模型服务商之前先进一个团队自己控住的网关这一层就是自托管网关。如果你不想自己运维网关直接买一家托管服务商的聚合 API走的是托管聚合。而智能路由可以理解为横跨前面所有层的决策大脑它负责回答“这个请求到底该发给谁”本身可以做成网关插件也可以做成独立服务。四层之间不是简单的“哪个替代哪个”的关系。工具侧路由是代码层面的灵活性适合个人项目或者早期验证自托管网关是基础设施层面的可控性适合有一定工程能力的团队托管聚合是省心优先适合业务还没到规模、不想投入运维成本的公司智能路由则是在前两者基础之上叠加的优化层用得好能压成本、提质量用不好反而拖慢请求。我给出一个很实际的判断标准你团队现在被模型 API 的什么问题卡住了。如果是“切换供应商要改代码太麻烦”工具侧路由就能解决。如果是“每个服务各自接 API密钥散落各处没法统一治理”你需要的是网关。如果是“完全不想关心底座是谁只想按量付费、稳定可用”托管聚合更合适。如果是“模型很多怎么选最优、怎么控成本”那答案在智能路由里。大多数团队真实的情况是同时卡在好几个地方所以选型千万别只盯着某一个名词。还有一点值得强调这一层一层的演进本质上是在往“把模型供应商当作可替换资源”的方向走。我见过很多团队第一步从工具侧路由起步代码里先用一个简单的 switch 管理模型名到后来某个接口故障导致线上事故才意识到需要网关做故障转移。这不是他们判断力差而是业务规模还没到那个触发点。所以我建议你把四层全部看完再对照自己的现状决定停在哪一层别急着一步到位。2. 工具侧路由最轻量但也最容易给自己埋坑工具侧路由说白了就是在你的代码里、在 SDK 或者 HTTP client 这一层做转发和切换。市面上没有太多独立的产品叫“工具侧路由”它更像是你代码架构里的一个设计模式不引入外部组件靠一段抽象逻辑把多模型调用管起来。2.1 三种常见的代码层实现方式第一种最简单直接在业务代码里封装一个 ModelRouter 类内部维护一个模型配置表然后对外暴露统一的 chat_completion 接口。这个接口接收 model 名、messages、temperature 这些参数内部根据 model 名映射到具体的 SDK client 上。我早期写 AI 应用就是这么干的最开始只接 OpenAI 一个供应商后来要加 Claude就在这个类里增加一个分支几十行代码搞定。第二种是基于社区现成的多模型 SDK比如 LiteLLM 的 Python SDK、Portkey SDK 这类。它们虽然也带网关能力但你完全可以在不部署任何服务的情况下只 import 一个库来用。这种方案比你自己手写 Router 类强在供应商适配层已经帮你做好了统一成了 OpenAI 兼容格式切换模型只需要改模型名比如把gpt-4o换成claude-sonnet-4,官方还处理了不同服务商的参数差异。第三种是我后来才意识到的工具侧路由不一定非要在业务进程里做你的 CI/CD 流程、测试环境、本地开发环境都可以用工具侧路由的思路。比如本地开发时所有请求自动打到 mock 服务或者低成本的模型测试环境走预发布模型配置生产环境才走正式渠道。这种方式我称为“环境级路由”一般通过环境变量加配置文件就能实现。2.2 工具侧路由的红线在哪里工具侧路由看起来轻巧但它有明显的边界。最核心的一条就是它只能在“单实例、单区域”的前提下工作。你的应用一旦有多个副本同时运行每个副本都有自己的一份路由逻辑和模型密钥那你很快就发现无法做全局限流和统一监控。某个副本的 token 消耗超标你得翻到对应 Pod 的日志里才能定位。第二个坑是故障转移能力薄弱。代码层的重试逻辑通常只解决“请求失败重试一次”的问题但对于模型服务商级别的故障比如某个大模型 API 连续五分钟 5xx代码层很难及时感知并自动把流量切走。你可能需要自己写健康检查、自己维护熔断状态而这个维护成本会随着接入的模型数量线性上升。第三个坑是安全位置不对。密钥写在环境变量里比写在代码里安全但依然散落在每个运行实例上。如果你的应用被人拿到了某个 Pod 的持久化环境变量等于拿到了所有模型供应商的钥匙。我见过不止一个团队因为密钥管理不规范在日志里误打了完整的 API key最后只能紧急轮换。所以我的建议是工具侧路由适合三个场景——个人项目、原型验证、还没有多个后端服务的小型单体应用。你的核心目标应该是把事情跑通而不是为了将来的扩展提前设计一个微服务架构。一旦你的业务开始有多个服务都需要调模型或者你开始关注成本分摊、按项目限额就该考虑把路由层往上提了。3. 自托管网关生产环境真正的核心枢纽如果你需要在全公司或者一个多服务架构里统一管模型 API自托管网关基本是绕不开的一环。我这里的“自托管”指你自己控制部署形态可以是一台云主机上的 Docker Compose也可以是 Kubernetes 集群里的 Helm Chart甚至就是一台内网服务器。控制的权力在你手里出事的责任也在你身上。3.1 选型对比LiteLLM、Portkey Gateway 与通用网关2026 年这个时间点自托管网关的头部玩家已经很明确LiteLLM 是事实标准Portkey Gateway 是强力挑战者Kong AI Gateway 和 Higress 是通用网关阵营里专门做 AI 扩展的。LiteLLM 我用了最久它最核心的优势是支持极其广泛的模型供应商列表官方文档号称覆盖 100 家以上实测非常接近。它对外暴露一个 OpenAI 兼容的/chat/completions端点你完全可以把 base_url 指到 LiteLLM 服务现有代码一行都不用改。它还内置了成本追踪、负载均衡、重试和 fallback配合 Redis 可以做多实例共享状态。生产环境我建议部署模式是 LiteLLM PostgreSQL Redis 组合PostgreSQL 存配置和花费数据Redis 做缓存与分布式限流。Portkey Gateway 我在一个需要精细控费的客户项目里用过它最大的差异化是 gateways 天生带可观测性请求日志、token 用量、按 tag 做用量分析都做得很细。它的 guardrails 模块可以做到 request 级的安全检查比如输入的 PII 检测、输出内容的规则校验这在金融和医疗场景很加分。如果你第一诉求是“把模型调用管成标准 API 网关”Portkey 的上手曲线其实比 LiteLLM 更友好。Kong AI Gateway 和 Higress 属于大而全的路线。它们不是为 AI 设计的而是在通用 API 网关上扩展了 AI 插件比如把上游配置成各种模型供应商支持 prompt 模板和限流。这类方案适合什么场景呢你的基础设施里已经重度使用 Kong 或 Higress 了不想为了模型 API 再单独引入一个组件。但反过来说如果你想用它们当模型网关要自己做不少组装工作AI 相关的深度功能比如语义缓存、模型质量评估基本没有需要二次开发。3.2 部署和初始化流程自托管网关的部署本身不复杂难点在配置设计和后续维护。我拿 LiteLLM 举例走一遍完整流程第一步准备部署环境。建议至少 2 核 4G 起步生产环境别省这点资源。用 Docker Compose 的话核心就是三个容器litellm 主服务、postgres、redis。我一般还会加一个 nginx 在最前面做 TLS 终止。Kubernetes 里就用官方 Helm Chart默认参数会拉起 litellm、redis 和 postgres注意把持久化卷配置好否则重启数据就没了。第二步配置模型列表。LiteLLM 的配置文件是一个 YAMLmodel_list下面定义每个模型条目每个条目包含model_name暴露给调用者的名字、litellm_params真实供应商、真实模型名、API key 或 key 环境变量、以及可选的model_info比如支持的最大 token 数、成本定价。我习惯把model_name统一成业务层的命名比如primary-llm、fast-llm、cheap-llm这样以后切换具体模型时调用端完全感知不到。第三步配置密钥和鉴权。LiteLLM 有一个 master key所有请求必须带这个 key 或者用它生成虚拟 key。生产环境我强烈建议给每个服务、甚至每个项目单元生成独立的虚拟 key这样你能精确知道谁的用量是多少。在general_settings里关闭掉不需要的选项比如关闭/sso等管理端路由尽量把管理 API 和模型 API 分开暴露。第四步配置负载均衡、重试与 fallback。router_settings里有routing_strategy可以用simple-shuffle或least-busy。这里我想强调网关的负载均衡不是简单的“轮询”或“随机”你还要考虑每个模型的价格不同、上下文不同。我一般按模型组来配置高能力组、中能力组、低成本组调用方按业务语义指定组名网关在里面做具体模型选择和故障转移。第五步配置可观测性。LiteLLM 天然支持 Prometheus metrics我建议在 Grafana 里配好四个核心面板请求量、p50/p95 延迟、token 消耗、按模型分组的花费。别等出了问题再补监控网关上线第一天就要有这些面板。3.3 网关的隐藏成本和运维细节自托管网关最大的坑不是装不起来而是运维责任全在自己身上。模型供应商 A 的限流策略变了你的重试逻辑要跟着调供应商 B 的某个模型下线了你要在配置里把流量切走Redis 挂了限流和分布式缓存全部失效流量直接打到模型服务商。这些事情每一件都真实发生在我维护过的网关里。安全上有几个点容易被忽略。网关本质上是帮你转发 API key 的中介所有上游模型的 key 都存在它的配置里所以网关所在服务器的安全级别应该等同于你核心数据库的级别。另一个隐蔽问题是 SSRF如果你允许用户传入自定义 base_url攻击者可能让你的网关替他访问内网地址。LiteLLM 有相关防护参数的部署时必须确认开关打开。还有成本问题。网上都说 LiteLLM 免费开源但你要算一下维护成本一个生产网关每月至少需要一个人天来配置变更、盯告警、处理故障。如果你的团队没有专职 SRE网关的维护很容易变成“嘴上说重要、实际没人管”的黑洞。这也是许多小团队最后选择托管聚合的原因之一。4. 托管聚合与智能路由把复杂度交给供应商把决策交还给策略托管聚合和智能路由一个是部署形态的差异一个是决策能力的升级。托管聚合是你不需要自己部署任何组件直接注册一个服务商的账号拿到一个 API key然后把请求打给它的聚合端点由它转发到各家模型。智能路由则是你在路由环节加入了“自动选择模型”的判断逻辑可以发生在你自己代码里、自托管网关里也可以发生在托管聚合服务商那侧。4.1 托管聚合重点服务商盘点OpenRouter 与云端大厂OpenRouter 是我个人项目里用得最多的。它最突出的价值是模型种类极多社区发布的开源模型、各家商业模型的预览版经常第一个在 OpenRouter 上线。它的计费方式是预充值按量扣费对个人开发者很友好不用跟每个模型供应商单独签约。OpenRouter 也有 fallback 参数当你指定一组模型时它会按顺序尝试直到有模型成功返回这在你的应用对某些模型的稳定性没把握时非常有用。AWS Bedrock、Azure OpenAI 这类云端厂商的聚合服务则是企业场景的主导者。它们最大的优势在于模型 API 的契约关系你可以跟企业签一个合同把多家模型的用量都开在一张账单里同时满足数据驻留的合规要求。AWS Bedrock 的用户体验说句实话它的控制台和管理 API 比炫酷的创业公司产品粗糙不少但它的合规审计能力、网络隔离能力、私有化部署演进路径才是大企业买单的理由。Cloudflare AI Gateway 是另一个值得关注的玩家它更像是一个托管形态的网关层你可以在它上面配置自己的上游模型接口它帮你做缓存、限流和可观测性。它的优势是默认在全球边缘节点运行对你的用户来说延迟很低再加上 Cloudflare Workers 的生态AI 网关和你的 Worker 应用可以靠得很近。适合已经在 Cloudflare 生态里做开发的中小型团队。4.2 智能路由从“转发”到“判断”智能路由这个词这几年被说烂了但真实的智能路由其实没有那么多玄学。它的本质是给路由加一个策略决策层在收到请求的时候系统不只是按一个固定配置转发给某个模型而是结合请求内容、上下文长度、成本预算、当前各模型的健康度和响应质量动态选出最合适的模型。具体的实现我拆成三个子模块。第一是请求理解模块它分析请求本身的特点是翻译任务、代码生成任务还是复杂推理任务预估所需的上下文长度判断是否涉及敏感内容。第二是策略引擎它读取一组可配置的规则比如“成本上限 0.01 美元每次请求”“p95 延迟不得超过 3 秒”“所有代码生成请求必须走模型 A”把请求理解模块提取的特征和这些规则做匹配生成候选模型列表。第三是决策模块根据每个候选模型的实时健康度、当前负载、价格和预估精度给候选模型打分选最高分执行。我再解释一下为什么这个架构比简单的“规则路由”更实用。规则路由只能处理你写死的场景比如“客户ID 属于企业版就走模型 A”。但真实请求是连续分布的有些翻译请求简单到小模型就够了有些涉及特定领域的术语小模型会翻译得乱七八糟。硬编码规则没办法穷尽所有情况智能路由可以在运行时根据请求的 token 量和质量反馈动态调整。4.3 智能路由的核心难点质量评估与反馈闭环智能路由最容易翻车的地方就是“你怎么知道这次响应是高质量的”。行业里目前主流做法是 LLM-as-a-judge用一个大模型去给另一个模型的输出打分。这个方法有效但成本高、延迟高不适合在实时链路上做全量评估。我的实践经验是把质量评估做成异步闭环在线请求先按策略路由同时把请求和响应异步推送到评估队列后台用 judge 模型批处理打分分数回写数据库用于下一轮策略的调整。面向用户的实时请求不会被评估逻辑拖慢路由策略又能持续进化。除了质量智能路由的第二个核心输入是成本感知。模型 API 的计费极其复杂按输入 token、输出 token、缓存命中价格、不同地区的价格都不一样。如果你想做成本感知路由必须把每个模型的价格模型建模成一个函数而不是一个常量。更细一点你还可以结合每种任务的 token 消耗规律做预估比如“总结类任务平均输入 3000 token、输出 500 token”再查价格表算出每个模型单次请求的预估成本路由决策时把预估成本作为特征之一。有一个经验我认为值得强调智能路由不是一上来就全自动。我的建议是分三步走第一步只加监控不干预路由先看每个请求落到哪个模型、效果如何、成本多少第二步手工制定一批“必定命中”的硬规则比如“超过 8k 上下文的压缩任务走长上下文模型”把自动化限制在一个安全范围内第三步跑一段时间后再逐步放开策略引擎的自动决策权。很多团队一开始就想做全自动结果模型选错的质量问题直接暴露给用户事后挽回代价巨大。5. 选型决策树与经验谈从哪一层开始在哪一层停下面对这么多的选项团队最常问我的问题就是我们到底该怎么选。我给出一套我个人比较偏好的决策路径供参考。第一步先评估业务量级。日请求量低于一万次、模型调用不超过三个供应商那就先在代码层把路由抽象做好工具侧路由足够。不用过早引入网关因为运维成本可能比模型 API 成本还高。第二步业务量上来了或者你发现需要多团队、多项目共用模型资源那就上自托管网关。选型顺序我建议默认 LiteLLM如果你需要精细的用量分析和审计优先试 Portkey Gateway。这部分不是单项选择题我见过很多团队实际是 LiteLLM 做转发、Portkey 做可观测性两者配合使用。第三步如果你的团队没有足够的 SRE 人力或者业务对稳定性要求极高、但招不到人来维护基础设施那就直接选托管聚合。OpenRouter 适合产品快速迭代期云端厂商的聚合服务适合你有合规和账单整合需求的阶段。这个阶段你可以先不管底层细节所有精力都放在业务逻辑上。第四步当你的模型调用费用开始占业务成本的显著比例或者你实在无法忍受“所有请求都打最强的贵模型”这种花钱方式再引入智能路由。先加监控再做硬规则最后才逐步自动化。别一上来就想要“全智能”。这套路径之外我还想分享几个容易踩的细节。第一无论你选哪一层统一 API 格式都是首要任务。我强烈建议你直接以 OpenAI 兼容格式作为内部标准因为所有主流服务商和开源模型你都能找到一层 OpenAI 兼容适配。这样即使你未来替换掉整个路由层业务代码零改动。第二密切关注上下文缓存带来的计费变化。2026 年多家模型都推出了长上下文缓存比如重复输入的前缀可以打折计费这直接影响智能路由的成本模型。你的成本预估函数必须能区分缓存命中和缓存未命中两种情况否则做出来的成本感知路由完全不靠谱。第三不要把多模型路由当成一个一劳永逸的事。模型能力迭代太快了今天最强的模型三个月后可能排到十名开外你的路由策略配置要允许业务人员方便地调整而不只是工程师改代码发布。我见过做得好的团队会为路由策略配置做一个简单的后台页面运营和算法同学自己就能改某个场景的模型优先级这个投入的回报远高于继续优化路由算法本身。第四路由层虽然解决了很多问题但它绝对无法替代应用层设计。你的应用如果本身没有 prompt 管理、没有输出校验、没有用户反馈收集路由层再智能也救不了产品体验。多模型路由解决的是供给侧问题你要时刻记住需求侧的 prompt 质量、系统稳定性、用户体验才是产品的真正基本功。多模型路由的选型路走到今天已经不是一个“要不要做”的问题而是一个“在哪个层次做”的问题。每一层都有它存在的理由也都有它对应的代价。关键是看清你自己现在所处的位置选一条当前性价比最高的路然后留好往上爬的接口。而我个人的习惯是永远在代码里保留一层轻量的模型抽象同时在上游预留好网关的接入位置——这样无论行业怎么变你都能快速切到最合适的路由方案。 
