多模型路由这个东西2026 年再谈已经不是“要不要做”的问题了而是“你到底在哪一层做、做到多复杂”的问题。我见过不少团队初期只是想在两个模型之间做一个 fallback结果一路挖到了自建网关、托管聚合、甚至想上智能路由架构复杂度一下子爆炸。这篇文章我把四个层级——工具侧路由、自托管网关、托管聚合、智能路由——完整拆一遍帮你搞清楚每一层到底解决什么问题、适用什么阶段、成本和风险在哪里以及怎么根据你自己的场景做选型。内容全部基于近两年我在生产环境里实际跑过、踩过、重构过的经验不是纸面对比。需要先说清楚的是多模型路由这四个字从来不是一个单一的技术组件而是一组层叠的关注点。你可以在代码里用一个if-else完成路由也可以在代理层用一套规则引擎完成路由还可以让一个外部平台来帮你完成路由甚至更进一步让系统根据实时反馈自动选择模型。每一层都有自己的适用范围也都有自己的坑。下面一层一层说。1. 先别急着上网关工具侧路由是你绕不开的第一层很多人一提到多模型路由第一反应就是“我要部署一个 gateway”。这个直觉放在 2026 年有点过时了。绝大多数项目哪怕是已经在生产环境跑了几百万次调用的项目真正刚需的路由能力其实在代码里就能解决也就是所谓“工具侧路由”。1.1 工具侧路由管的是哪几件事工具侧路由说白了就是在应用代码内部根据条件选择不同的模型或不同的供应商。它的核心价值不是“高级”而是“薄”和“快”——不引入额外组件不增加网络延迟不需要维护一套独立服务。最常见的场景就三个第一供应商故障时的 fallback。主模型返回 5xx、429、连接超时马上切到备选模型。这个场景在任何一个用了第三方 AI API 的生产项目里几乎必然出现。2025 年之后各家模型厂商的可用性波动越来越大尤其是新模型发布后的头几周限流、超时几乎成了常态。第二按任务类型选模型。代码生成走编码模型摘要走中尺寸通用模型复杂逻辑推理走高阶推理模型。这个策略在入口处写死不做动态决策因为这本来就该由业务方指定不是系统该猜的事。第三按用户或租户走不同的模型。企业客户买了高配套餐那就走更强但更贵的模型免费用户走低成本模型。这是一类典型的业务规则路由。工具侧路由最舒服的一点是它可以做得非常轻量# 一个非常朴素的工具侧路由结构 class ModelRouter: def __init__(self): self.providers { primary: create_client(openai, api_key...), fallback: create_client(anthropic, api_key...), } async def complete(self, messages, taskgeneral): # 第三层按任务选择模型 if task code: model fast-coding-model elif task deep-reasoning: model reasoning-model else: model default-model # 第一层和第二层按可用性做 fallback for name, client in self.providers.items(): try: return await client.chat.completions.create( modelmodel, messagesmessages, timeout30, ) except (TimeoutError, RateLimitError, APIError): continue raise AllProvidersFailedError()这种写法你看着简单但已经解决了 80% 的需求。真正常见的情况是很多团队连这个都没写直接裸调 SDK一旦上游抖动就只能由用户承担报错。1.2 工具侧路由的 fallback 策略没那么简单如果你以为 fallback 就是“失败就换下一个”那你很快会踩坑。工具侧路由的 fallback 策略有三个细节值得认真做。超时设置必须分层。连接超时、读取超时、总超时这三者要分开设。很多 AI SDK 默认不设置超时或者只设一个很大的兜底超时导致故障时请求挂在连接池里迟迟不决。我的建议是连接超时设 5 秒以内读取超时按模型推理时长来总超时兜底 60 到 120 秒。fallback 的触发不能只看总错误而是要看是哪种超时——如果上游只是慢但没挂直接切走可能反而造成浪费。429 限流和 500 故障要区别对待。429 通常意味着上游没有宕机只是配额到了这个时候 fallback 到另一个供应商是合理的。但如果连 fallback 供应商也在被限流你就需要等一段时间再重试而不是即时切换。也就是说fallback 要带一个简单的退避策略避免两个供应商之间反复横跳形成“乒乓效应”。幂等性和重复请求的代价要想清楚。如果你的调用是生成类任务而不是检索类任务fallback 触发时前一个请求可能已经在上游执行了一半甚至已经生成了内容你是放弃它还是接受可能出现的重复在工具侧路由层面我通常建议放弃并接受重复——因为要完全幂等对生成类任务来说基本不可能。你能做的是在业务层对“是否允许重复生成”做标识而不是在路由层强行保证。1.3 代码侧的“模型名映射”和“统一接口”才是长期痛点路由本身简单难的是你面向多个模型、多个供应商时如何让上层代码不被各家 API 差异绑架。2026 年的现状比两年前好很多几乎所有主流供应商都提供 OpenAI 兼容接口通过修改base_url和api_key就能切换。但“几乎兼容”不等于“完全兼容”你迟早会遇到响应格式的小差异或者某个高级参数在一个供应商那有效、在另一个那报错。我的做法是在工具侧封装一个薄的适配层把模型名映射、参数归一化、响应解析收敛到一个模块里。不要让业务代码到处散落着 “如果供应商是 X 就传这个参数” 这种逻辑。模型名映射这件事尤其重要——同一个逻辑模型在不同供应商那有不同的名称名字后缀可能随版本调整而变化。你把映射表集中维护在一个配置文件里改起来会轻松得多。工具侧路由能做到这个程度已经可以支撑到一天几十万调用量的业务。再往上走当你发现以下信号时才需要考虑引入独立网关fallback 逻辑已经在多个服务里被复制了七八遍改一处漏三处你需要在多个团队之间共享同一个模型账号和配额出现预算互相挤占的问题你想给业务方提供统一的 OpenAI 风格端点而不是让他们各自对接各家 SDK审计需求变多需要统一记录每个请求走了哪个模型、哪个供应商、花了多少钱。出现这四个信号里任意两个就说明工具侧路由已经撑不住了该上第二层。2. 自托管网关开源方案的选型与落地成本自托管网关指的是你自己部署、自己运维的一个 AI Gateway 服务它向上游各家模型供应商发起请求向下游应用提供一个统一入口。2026 年这个赛道的成熟度非常高了开源方案里 LiteLLM 是目前社区采用率最高的BentoML Gateway 也在快速爬升Kong 和 Apache APISIX 这类通用 API 网关也都推出了 AI 能力扩展。选型之前先搞清楚自托管网关真正值得做的事。2.1 三个开源方案的真实取舍我这两年深度用过的有 LiteLLM 和 BentoML GatewayKong 的 AI 网关也在几个客户项目里评估过。简单说下区别LiteLLM 是“专为 LLM 调用而生”的网关提供 OpenAI 兼容的/v1/chat/completions端点后端对接上百家模型供应商。它最大的优势是配置驱动核心逻辑都在一个config.yaml里模型定义、密钥映射、限流、预算、负载均衡都能通过配置完成非常适合快速落地。缺点是它本质上还是围绕“代理转发”设计的如果你要做很复杂的请求改写和业务级策略它不太灵活。BentoML Gateway 的思路偏“AI 应用部署平台”它更强调把模型服务、推理运行时和网关放在一起管。如果你的主要诉求不是对接多家 SaaS API而是在自己的 GPU 集群上托管开源模型并且需要一个统一入口BentoML 的贴合度更高。它的网关能力同样具备多模型路由但重心更偏向部署层而不仅仅是代理层。Kong AI Gateway 则是通用 API 网关的 AI 扩展优势在于它和已有的 API 治理体系天然融合签发、限流、审计这些能力都比专用网关成熟。不过它做模型路由的能力相对基础更依赖你写插件去定制落地成本偏高。我的选型结论不复杂如果核心目标是“对接多家 SaaS 模型 统一入口”LiteLLM 最省心如果核心目标是“自托管开源模型 对外统一服务”BentoML 更合适如果你本来就有 Kong 这类 API 网关体系希望 AI 流量纳入同一套治理体系那在 Kong 上做扩展也完全可以。2.2 配置网关时最容易忽略的三件事自托管网关的部署本身不难LLM 网关的复杂点从来不在安装而在配置。我基于 LiteLLM 举例说三个我见过最多团队踩坑的地方。模型映射不是单纯的表。很多人的第一版配置是把模型名一对一映射到供应商模型model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY这个配置没问题但它没有体现出“组”的概念。一组应该是指多个供应商的模型共同服务同一个逻辑模型名网关根据可用性和策略在这组之间做负载均衡model_list: - model_name: chat-model litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY model_info: mode: completion supports_function_calling: true - model_name: chat-model litellm_params: model: anthropic/claude-3-5-haiku-latest api_key: os.environ/ANTHROPIC_API_KEY model_info: mode: completion num_instances: 2这样配置之后下游应用只需要请求modelchat-model网关会在 OpenAI 和 Anthropic 之间按照负载均衡策略分配流量。这里需要特别注意两组模型的能力必须对齐——功能调用、JSON 输出、上下文长度这些能力参数如果不是等价替代强行互切会导致上游报错或者下游出现解析失败。model_info里的能力标注就是给路由逻辑做判断用的。忽视它是非常常见的坑。密钥管理要区分“真实密钥”和“虚拟密钥”。真实密钥是你绑定的各家上游 API Key虚拟密钥是发给下游团队用的。LiteLLM 支持虚拟 API Key下游拿着虚拟 Key 调用你在虚拟 Key 上挂预算、限流、审计。很多团队图省事直接让下游用真实 Key一旦某个下游应用出现循环调用几天内就能把预算烧光你还没法追溯到底是哪个业务在超跑。成本/Token 统计必须从一开始就打开。网关的一个核心价值就是“算清楚账”。你不拍照后面想按业务线分摊成本时就会一头雾水。开启详细的 usage 日志之后你应该能回答出这些问题昨天哪个模型花了多少钱哪个团队调用量涨了哪个供应商的失败率高于阈值2.3 高可用与可观测是网关的隐性成本自托管网关最大的好处是数据面在自己的控制范围内最大的代价是——它本身成了你架构里的新故障点。网关挂了所有下游请求全部失败。所以高可用不是可选项而是必须一开始就考虑的。我的建议是网关至少要部署两个实例前面用负载均衡器分发实例之间无状态化。数据库和 Redis 这类中间件用云上托管服务而不是单机部署。LiteLLM 这类网关注入的重试、限流、预算状态都依赖数据库如果数据库挂了网关的健康检查会频繁失败整个链路会雪崩式地不可用。这块的运维成本经常被小团队低估——你从零部署完网关只要半小时但把它跑得稳如老狗背后是持续的关注。可观测性方面至少要做到三个指标请求成功率按供应商维度拆分、P50/P95/P99 延迟、Token 吞吐和成本趋势。失败率上升时应该能一眼看出是哪个上游供应商出了问题然后快速在配置里把对应供应商的权重调低而不是让流量无止境地撞墙。提示如果你在自托管网关上花了大量精力处理稳定性问题先回头评估一下——是不是你的运维资源根本养不起这个网关如果是那说明你可能更适合直接跳到第三层用托管聚合服务来替你承担这部分成本。3. 托管聚合把路由交给平台你能省下什么、失去什么托管聚合平台比如 OpenRouter、Azure OpenAI 的多模型接入、AWS Bedrock 的模型路由能力、Together AI 的托管 API本质上是在云端把“多模型接入 统一计费 一部分路由策略”作为服务提供。你不需要自己搭建代理层只需要一个 API Key、一个 OpenAI 兼容端点就能访问多个模型调用失败时平台帮你做 retry 或者 fallback。3.1 托管聚合到底帮你做了什么以 OpenRouter 为例它做的最核心的事是把碎片化的模型供应收敛为一个统一入口。你不用再去各家分别开账号、分别配 Key、分别对发票直接在它的控制台里选模型、充余额一个 Endpoint 全走完。它在路由方面提供的基础能力包括跟随上游模型的定价做统一计费、部分模型组合的自动 fallback、以及统一的输出格式。Azure OpenAI 的多模型接入路径略有不同它的场景更偏向企业客户——通过 Azure 的模型目录你可以在同一个工作区里接入 OpenAI 模型、开源模型和 Meta 的 Llama 系列统一走 Azure 的身份认证和网络体系。AWS Bedrock 的做法类似但它的路由策略更突出——支持通过inference profile实现跨区域自动路由根据可用性和靠近用户的位置动态选择推理端点。托管聚合平台最大的价值是帮你省掉一个中间层。你不是自托管一个网关的服务态你只是租用了它的开箱即用能力。如果你的团队没有专门的 AI 基础设施维护人员这是非常现实的选择。3.2 托管聚合的“改造成本”不一定低很多人以为用托管聚合 零成本接入这个理解有偏差。托管聚合可以让你不用写路由代码、不用部署网关但你的代码依然要做适配——你的请求格式、超时策略、错误处理都要跟着平台的行为来。真实遇到过的例子某个模型在 OpenRouter 上的名称后缀和厂商官网不一样某个模型在平台上返回的 usage 字段不如直连时完整还有平台的速率限制策略和上游厂商不一致导致你在一个模型上明明配额充足但因为平台侧 QPS 限制依然被打回 429。这些问题都不致命但每一个都会消耗上手时间。另外托管聚合平台的费用通常会在原模型定价之上加一个平台加成有时这个加成是透明的有时已经包含在单价里。短期看无所谓如果月调用量很大这层加价会变成一笔实打实的成本。我见过的场景是某团队用托管聚合跑了一年体量到了月百万次调用后发现成本比直连厂商 API 高出了 15% 到 20%才动手迁移到自建网关。还有一点容易被忽略托管聚合平台一旦整体故障你连切换都不可能——因为它是单点。而自托管网关或者工具侧路由理论上你可以快速改配置切到另一家。托管平台如果挂了你只能等它恢复。这时候理性的决策不是“托管便宜”或“托管贵”而是你的团队是否有能力承担自托管网关的运维成本以及业务对可用性和成本控制的敏感度有多高。3.3 数据合规视角下的托管路由注意事项聊托管聚合必须谈数据合规。托管聚合平台是第三方你的请求数据会经过它的服务器再转发给上游模型厂商这意味着你的数据面多了一个节点自然也多了数据安全方面的风险。对于处理个人隐私数据、内部业务数据的企业这是一个无法回避的评估项。我自己做选型时一般先问三个问题平台的隐私政策是否允许你的数据类型经过平台是否提供零日志处理或私有网络接入上游模型供应商的数据留存期限是多少这些问题通常需要法务和采购配合来评估而不是技术选型时顺带看一眼。我会在选型文档里把“数据不落第三方”作为硬约束来处理如果无法满足就直接排除托管聚合选项。4. 智能路由当路由从“转发”变成“决策”前三层本质上都是“转发路由”——目标模型名单是确定的策略是预先写好的路由请求只是按规则执行。第四层智能路由的核心变化是模型选择不再是一个预先写死的映射而是由系统根据请求特征、实时状态、历史反馈动态决策的过程。这一层是 2026 年多模型路由赛道里增长最快的部分也是争议最大的部分。4.1 静态路由和智能路由的分界线在哪我见过不少团队把“加权轮询”叫智能路由这个词被严重滥用了。真正的智能路由至少包含三个要素中的一两个基于请求特征的分类决策、基于实时状态的目标优化、基于历史反馈的自适应调整。最典型的智能路由实现是前端加一个分类器。请求进来后先由一个分类任务判断这个请求属于哪种类型——是事实性问答、创意写作、编程辅助还是复杂推理——然后根据分类结果路由到特定模型。这个分类器可以是独立小模型也可以是基于规则的模型标识比如让用户显式声明任务类型。以编程辅助为例一个简单有效的路由策略代码补全类请求走低延迟模型代码讲解、重构建议走中档通用模型复杂架构设计、多文件上下文推理走高阶推理模型。这个策略如果靠应用层写死也可以运行——因为业务方本来就知道这次请求是“补全”还是“重构”。但智能路由的区别在于当业务方来不及显式声明任务类型时系统可以通过请求本身的特征自动判断。进入生产之后路由决策不再依赖人的判断而是依赖一个持续更新的分类模型。4.2 成本、延迟、质量三个目标如何同时优化实际是个多目标问题做智能路由最容易犯的错误是只盯着“省钱”或者只盯着“质量”。真正落地的智能路由必须在成本、延迟、质量三个目标之间找到平衡。这三个目标互相牵制没法靠一个轻量分类器一劳永逸地解决。我举一个具体场景你在做一个客服问答系统。理论上问候语和意图明确的业务咨询完全可以用小模型解决但长尾问题、投诉情绪强烈的对话需要大模型甚至高阶推理模型。如果只用小模型长尾问题回答质量必然垮掉如果全都走高阶模型成本高 20 到 50 倍而且部分简单对话延迟反而更高。解决这个问题我的经验是先建一条“质量底线规则”——先保证不塌再谈优化。高阶模型的调用比例设一个硬上限比如不超过总请求量的 20%对于分类置信度低于某个阈值的请求直接走高阶模型而不是冒险用低阶模型处理。智能路由从来不是“大多数时候选便宜的”而是“在规则约束内动态调整分配”。预算约束也不能只看单请求成本要看整体趋势。按天设置成本预算路由系统在预算充足时可以把更多流量分配给高质量模型预算吃紧时则平滑地降低高成本模型的分配比例。这种“随着实时状态变化”的分配策略比死板的静态配置要健壮得多。4.3 基于提示特征的路由和基于反馈的路由优先做哪个智能路由内部其实还有两个不同的技术方向很多团队把它们混为一谈导致落地时目标不清。一个是基于提示特征的路由。核心逻辑是“看请求的内容判断该用哪个模型”。它基于请求本身的信息做出决策预设规则或者模型分类。优点是可以提前预判不需要等模型跑完再决策缺点是如果请求特征和模型能力之间的关系不明确分类效果会很差。另一个是基于反馈的路由。核心逻辑是“用历史数据说话”。每完成一个请求系统性评估回答质量人工打分、可执行结果验证、自动化规则校验等然后把这些质量反馈信号作为下一次路由决策的依据。它更接近推荐系统里的强化学习。优点是不需要预设分类规则能够逐步逼近最优分配缺点是反馈数据的质量要求极高而且收敛需要时间。如果只能先做一个方向我强烈建议先做基于提示特征的规则型路由。原因很简单它可以快速建立一个不差于静态路由的基线同时积累起来的请求特征数据恰好是后续做基于反馈路由的先验知识。等特征路由稳定运行一段时间积累了足够多的质量和成本日志之后再引入反馈信号做动态调整是更稳妥的路径。直接上来就搞强化学习式路由对数据标注、评估体系、实验设计都是巨大挑战绝大多数团队根本走不到收益阶段就会因为内耗放弃。5. 四层选型决策框架六个问题、三个组合、三个教训聊完每一层的能力边界最后给一套可以直接套用的决策方法。多模型路由的选型本质上是根据你自己的团队规模、调用量、业务复杂度和合规约束为这四层做组合。我先给一套自测问题再给几个高频组合最后复盘几个真实踩坑教训。5.1 开始设计架构前先回答这六个问题你的日均调用量是多少这个直接决定了值不值得引入网关。一万次日调用以下工具侧路由通常绰绰有余十万以上网关的治理收益就能体现出来百万以上智能路由的优化空间才会真正显著。你的业务方数量是多少一个团队自己做工具侧路由最省事三个以上团队共用模型网关的共享密钥、预算分摊、审计价值就出现了。你对模型供应商的切换频率预期是多少计划性很强、一年换不了几次工具侧写映射就行经常有新的模型版本要灰度验证网关的模型映射切换成本更低。你的数据合规约束有多严格严格到不能过第三方平台托管聚合基本出局允许则是省心选项。你的运维人力是否养得起网关有没有专职的人能处理半夜上游故障和组件升级没有的话优先托管聚合。你的成本敏感性多高成本只是“不要离谱”还是“每个百分点都要抠”后者意味着你需要采集真实成本数据才有资格做智能路由。5.2 三个我自己常用的架构组合并不存在唯一的“最佳实践”。2026 年我见到比较合理的组合大概是这三类组合 A轻量起步型工具侧路由 一个供应商的直连最多再加一个备用供应商。适合日均调用量小、团队单一、处于验证业务场景阶段。成本最低最大的缺点是后续迁移到网关时需要把散落在代码里的路由逻辑收拢。组合 B标准治理型工具侧适配层 自托管网关LiteLLM 这类 可选的一份托管聚合作为备份通道。适合日均调用量中等、多个业务方共用、有基础运维能力。这个组合的核心是工具侧负责业务规则网关负责统一入口、密钥配额、成本统计和稳定性的基础托管聚合作为网关故障时的逃生通道。组合 C规模优化型自托管网关 智能路由层 托管聚合部分流量。适合日均调用量高、团队有专门 AI 基础设施和算法工程师。智能路由层不是替代网关而是挂在网关之上的一层决策器网关收到请求后先请求路由决策服务再决定转发给哪个上游。这里的托管聚合已经不是为了省心而是为了补充某个网关已经接不进的高质量模型。5.3 我踩过的三个坑最后分享三个真实踩坑经历希望帮你省掉一点时间。第一个坑是过早为不存在的性能问题做架构。我曾经在一个日调用量只有几千次的项目里花了三周部署自托管网关、配置多节点、写负载均衡。结果上线第一周就发现真正的瓶颈根本不在网关而在某个上游供应商的配额限制。如果当时用工具侧路由加一个配额监控完全就够了。后来我把网关拆掉了干活的还是三层逻辑——这是成本最直接的一次教训。第二个坑是网关配置里过度抽象模型名。为了“让下游不感知模型变化”我把所有逻辑模型名都映射成了一个统一名称包括一些能力差距巨大的模型。结果下游应用在不知道的情况下同一段代码有时得到的是高推理能力模型的回复有时是低能力模型的回复业务表现异常波动。模型映射的粒度一定要能反映能力层级不要把不同能力等级的模型塞进同一个逻辑名。统一是给运维看的不是给业务能力抹平用的。第三个坑是智能路由上线后缺乏评估机制就放量。我做过一个基于反馈的路由实验模型自动把更多流量分配给了“看起来省钱”的路线但因为评估反馈信号有滞后很多低质量回答在评分系统还没反映出问题时已经大面积触达用户。后来我增加了灰度流量对比每次调整路由策略都要和基线对照跑一段时间质量指标没有下滑才允许放量。多模型路由选型不输在技术能力输在阶段匹配。先用工具侧路由把业务跑通数据积累到一定量级之后再考虑网关最后再谈智能路由的优化空间。每一步都要有明确信号驱动不要让架构复杂度跑在业务前面。
多模型路由四层选型指南：从工具侧到智能路由
多模型路由这个东西2026 年再谈已经不是“要不要做”的问题了而是“你到底在哪一层做、做到多复杂”的问题。我见过不少团队初期只是想在两个模型之间做一个 fallback结果一路挖到了自建网关、托管聚合、甚至想上智能路由架构复杂度一下子爆炸。这篇文章我把四个层级——工具侧路由、自托管网关、托管聚合、智能路由——完整拆一遍帮你搞清楚每一层到底解决什么问题、适用什么阶段、成本和风险在哪里以及怎么根据你自己的场景做选型。内容全部基于近两年我在生产环境里实际跑过、踩过、重构过的经验不是纸面对比。需要先说清楚的是多模型路由这四个字从来不是一个单一的技术组件而是一组层叠的关注点。你可以在代码里用一个if-else完成路由也可以在代理层用一套规则引擎完成路由还可以让一个外部平台来帮你完成路由甚至更进一步让系统根据实时反馈自动选择模型。每一层都有自己的适用范围也都有自己的坑。下面一层一层说。1. 先别急着上网关工具侧路由是你绕不开的第一层很多人一提到多模型路由第一反应就是“我要部署一个 gateway”。这个直觉放在 2026 年有点过时了。绝大多数项目哪怕是已经在生产环境跑了几百万次调用的项目真正刚需的路由能力其实在代码里就能解决也就是所谓“工具侧路由”。1.1 工具侧路由管的是哪几件事工具侧路由说白了就是在应用代码内部根据条件选择不同的模型或不同的供应商。它的核心价值不是“高级”而是“薄”和“快”——不引入额外组件不增加网络延迟不需要维护一套独立服务。最常见的场景就三个第一供应商故障时的 fallback。主模型返回 5xx、429、连接超时马上切到备选模型。这个场景在任何一个用了第三方 AI API 的生产项目里几乎必然出现。2025 年之后各家模型厂商的可用性波动越来越大尤其是新模型发布后的头几周限流、超时几乎成了常态。第二按任务类型选模型。代码生成走编码模型摘要走中尺寸通用模型复杂逻辑推理走高阶推理模型。这个策略在入口处写死不做动态决策因为这本来就该由业务方指定不是系统该猜的事。第三按用户或租户走不同的模型。企业客户买了高配套餐那就走更强但更贵的模型免费用户走低成本模型。这是一类典型的业务规则路由。工具侧路由最舒服的一点是它可以做得非常轻量# 一个非常朴素的工具侧路由结构 class ModelRouter: def __init__(self): self.providers { primary: create_client(openai, api_key...), fallback: create_client(anthropic, api_key...), } async def complete(self, messages, taskgeneral): # 第三层按任务选择模型 if task code: model fast-coding-model elif task deep-reasoning: model reasoning-model else: model default-model # 第一层和第二层按可用性做 fallback for name, client in self.providers.items(): try: return await client.chat.completions.create( modelmodel, messagesmessages, timeout30, ) except (TimeoutError, RateLimitError, APIError): continue raise AllProvidersFailedError()这种写法你看着简单但已经解决了 80% 的需求。真正常见的情况是很多团队连这个都没写直接裸调 SDK一旦上游抖动就只能由用户承担报错。1.2 工具侧路由的 fallback 策略没那么简单如果你以为 fallback 就是“失败就换下一个”那你很快会踩坑。工具侧路由的 fallback 策略有三个细节值得认真做。超时设置必须分层。连接超时、读取超时、总超时这三者要分开设。很多 AI SDK 默认不设置超时或者只设一个很大的兜底超时导致故障时请求挂在连接池里迟迟不决。我的建议是连接超时设 5 秒以内读取超时按模型推理时长来总超时兜底 60 到 120 秒。fallback 的触发不能只看总错误而是要看是哪种超时——如果上游只是慢但没挂直接切走可能反而造成浪费。429 限流和 500 故障要区别对待。429 通常意味着上游没有宕机只是配额到了这个时候 fallback 到另一个供应商是合理的。但如果连 fallback 供应商也在被限流你就需要等一段时间再重试而不是即时切换。也就是说fallback 要带一个简单的退避策略避免两个供应商之间反复横跳形成“乒乓效应”。幂等性和重复请求的代价要想清楚。如果你的调用是生成类任务而不是检索类任务fallback 触发时前一个请求可能已经在上游执行了一半甚至已经生成了内容你是放弃它还是接受可能出现的重复在工具侧路由层面我通常建议放弃并接受重复——因为要完全幂等对生成类任务来说基本不可能。你能做的是在业务层对“是否允许重复生成”做标识而不是在路由层强行保证。1.3 代码侧的“模型名映射”和“统一接口”才是长期痛点路由本身简单难的是你面向多个模型、多个供应商时如何让上层代码不被各家 API 差异绑架。2026 年的现状比两年前好很多几乎所有主流供应商都提供 OpenAI 兼容接口通过修改base_url和api_key就能切换。但“几乎兼容”不等于“完全兼容”你迟早会遇到响应格式的小差异或者某个高级参数在一个供应商那有效、在另一个那报错。我的做法是在工具侧封装一个薄的适配层把模型名映射、参数归一化、响应解析收敛到一个模块里。不要让业务代码到处散落着 “如果供应商是 X 就传这个参数” 这种逻辑。模型名映射这件事尤其重要——同一个逻辑模型在不同供应商那有不同的名称名字后缀可能随版本调整而变化。你把映射表集中维护在一个配置文件里改起来会轻松得多。工具侧路由能做到这个程度已经可以支撑到一天几十万调用量的业务。再往上走当你发现以下信号时才需要考虑引入独立网关fallback 逻辑已经在多个服务里被复制了七八遍改一处漏三处你需要在多个团队之间共享同一个模型账号和配额出现预算互相挤占的问题你想给业务方提供统一的 OpenAI 风格端点而不是让他们各自对接各家 SDK审计需求变多需要统一记录每个请求走了哪个模型、哪个供应商、花了多少钱。出现这四个信号里任意两个就说明工具侧路由已经撑不住了该上第二层。2. 自托管网关开源方案的选型与落地成本自托管网关指的是你自己部署、自己运维的一个 AI Gateway 服务它向上游各家模型供应商发起请求向下游应用提供一个统一入口。2026 年这个赛道的成熟度非常高了开源方案里 LiteLLM 是目前社区采用率最高的BentoML Gateway 也在快速爬升Kong 和 Apache APISIX 这类通用 API 网关也都推出了 AI 能力扩展。选型之前先搞清楚自托管网关真正值得做的事。2.1 三个开源方案的真实取舍我这两年深度用过的有 LiteLLM 和 BentoML GatewayKong 的 AI 网关也在几个客户项目里评估过。简单说下区别LiteLLM 是“专为 LLM 调用而生”的网关提供 OpenAI 兼容的/v1/chat/completions端点后端对接上百家模型供应商。它最大的优势是配置驱动核心逻辑都在一个config.yaml里模型定义、密钥映射、限流、预算、负载均衡都能通过配置完成非常适合快速落地。缺点是它本质上还是围绕“代理转发”设计的如果你要做很复杂的请求改写和业务级策略它不太灵活。BentoML Gateway 的思路偏“AI 应用部署平台”它更强调把模型服务、推理运行时和网关放在一起管。如果你的主要诉求不是对接多家 SaaS API而是在自己的 GPU 集群上托管开源模型并且需要一个统一入口BentoML 的贴合度更高。它的网关能力同样具备多模型路由但重心更偏向部署层而不仅仅是代理层。Kong AI Gateway 则是通用 API 网关的 AI 扩展优势在于它和已有的 API 治理体系天然融合签发、限流、审计这些能力都比专用网关成熟。不过它做模型路由的能力相对基础更依赖你写插件去定制落地成本偏高。我的选型结论不复杂如果核心目标是“对接多家 SaaS 模型 统一入口”LiteLLM 最省心如果核心目标是“自托管开源模型 对外统一服务”BentoML 更合适如果你本来就有 Kong 这类 API 网关体系希望 AI 流量纳入同一套治理体系那在 Kong 上做扩展也完全可以。2.2 配置网关时最容易忽略的三件事自托管网关的部署本身不难LLM 网关的复杂点从来不在安装而在配置。我基于 LiteLLM 举例说三个我见过最多团队踩坑的地方。模型映射不是单纯的表。很多人的第一版配置是把模型名一对一映射到供应商模型model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY这个配置没问题但它没有体现出“组”的概念。一组应该是指多个供应商的模型共同服务同一个逻辑模型名网关根据可用性和策略在这组之间做负载均衡model_list: - model_name: chat-model litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY model_info: mode: completion supports_function_calling: true - model_name: chat-model litellm_params: model: anthropic/claude-3-5-haiku-latest api_key: os.environ/ANTHROPIC_API_KEY model_info: mode: completion num_instances: 2这样配置之后下游应用只需要请求modelchat-model网关会在 OpenAI 和 Anthropic 之间按照负载均衡策略分配流量。这里需要特别注意两组模型的能力必须对齐——功能调用、JSON 输出、上下文长度这些能力参数如果不是等价替代强行互切会导致上游报错或者下游出现解析失败。model_info里的能力标注就是给路由逻辑做判断用的。忽视它是非常常见的坑。密钥管理要区分“真实密钥”和“虚拟密钥”。真实密钥是你绑定的各家上游 API Key虚拟密钥是发给下游团队用的。LiteLLM 支持虚拟 API Key下游拿着虚拟 Key 调用你在虚拟 Key 上挂预算、限流、审计。很多团队图省事直接让下游用真实 Key一旦某个下游应用出现循环调用几天内就能把预算烧光你还没法追溯到底是哪个业务在超跑。成本/Token 统计必须从一开始就打开。网关的一个核心价值就是“算清楚账”。你不拍照后面想按业务线分摊成本时就会一头雾水。开启详细的 usage 日志之后你应该能回答出这些问题昨天哪个模型花了多少钱哪个团队调用量涨了哪个供应商的失败率高于阈值2.3 高可用与可观测是网关的隐性成本自托管网关最大的好处是数据面在自己的控制范围内最大的代价是——它本身成了你架构里的新故障点。网关挂了所有下游请求全部失败。所以高可用不是可选项而是必须一开始就考虑的。我的建议是网关至少要部署两个实例前面用负载均衡器分发实例之间无状态化。数据库和 Redis 这类中间件用云上托管服务而不是单机部署。LiteLLM 这类网关注入的重试、限流、预算状态都依赖数据库如果数据库挂了网关的健康检查会频繁失败整个链路会雪崩式地不可用。这块的运维成本经常被小团队低估——你从零部署完网关只要半小时但把它跑得稳如老狗背后是持续的关注。可观测性方面至少要做到三个指标请求成功率按供应商维度拆分、P50/P95/P99 延迟、Token 吞吐和成本趋势。失败率上升时应该能一眼看出是哪个上游供应商出了问题然后快速在配置里把对应供应商的权重调低而不是让流量无止境地撞墙。提示如果你在自托管网关上花了大量精力处理稳定性问题先回头评估一下——是不是你的运维资源根本养不起这个网关如果是那说明你可能更适合直接跳到第三层用托管聚合服务来替你承担这部分成本。3. 托管聚合把路由交给平台你能省下什么、失去什么托管聚合平台比如 OpenRouter、Azure OpenAI 的多模型接入、AWS Bedrock 的模型路由能力、Together AI 的托管 API本质上是在云端把“多模型接入 统一计费 一部分路由策略”作为服务提供。你不需要自己搭建代理层只需要一个 API Key、一个 OpenAI 兼容端点就能访问多个模型调用失败时平台帮你做 retry 或者 fallback。3.1 托管聚合到底帮你做了什么以 OpenRouter 为例它做的最核心的事是把碎片化的模型供应收敛为一个统一入口。你不用再去各家分别开账号、分别配 Key、分别对发票直接在它的控制台里选模型、充余额一个 Endpoint 全走完。它在路由方面提供的基础能力包括跟随上游模型的定价做统一计费、部分模型组合的自动 fallback、以及统一的输出格式。Azure OpenAI 的多模型接入路径略有不同它的场景更偏向企业客户——通过 Azure 的模型目录你可以在同一个工作区里接入 OpenAI 模型、开源模型和 Meta 的 Llama 系列统一走 Azure 的身份认证和网络体系。AWS Bedrock 的做法类似但它的路由策略更突出——支持通过inference profile实现跨区域自动路由根据可用性和靠近用户的位置动态选择推理端点。托管聚合平台最大的价值是帮你省掉一个中间层。你不是自托管一个网关的服务态你只是租用了它的开箱即用能力。如果你的团队没有专门的 AI 基础设施维护人员这是非常现实的选择。3.2 托管聚合的“改造成本”不一定低很多人以为用托管聚合 零成本接入这个理解有偏差。托管聚合可以让你不用写路由代码、不用部署网关但你的代码依然要做适配——你的请求格式、超时策略、错误处理都要跟着平台的行为来。真实遇到过的例子某个模型在 OpenRouter 上的名称后缀和厂商官网不一样某个模型在平台上返回的 usage 字段不如直连时完整还有平台的速率限制策略和上游厂商不一致导致你在一个模型上明明配额充足但因为平台侧 QPS 限制依然被打回 429。这些问题都不致命但每一个都会消耗上手时间。另外托管聚合平台的费用通常会在原模型定价之上加一个平台加成有时这个加成是透明的有时已经包含在单价里。短期看无所谓如果月调用量很大这层加价会变成一笔实打实的成本。我见过的场景是某团队用托管聚合跑了一年体量到了月百万次调用后发现成本比直连厂商 API 高出了 15% 到 20%才动手迁移到自建网关。还有一点容易被忽略托管聚合平台一旦整体故障你连切换都不可能——因为它是单点。而自托管网关或者工具侧路由理论上你可以快速改配置切到另一家。托管平台如果挂了你只能等它恢复。这时候理性的决策不是“托管便宜”或“托管贵”而是你的团队是否有能力承担自托管网关的运维成本以及业务对可用性和成本控制的敏感度有多高。3.3 数据合规视角下的托管路由注意事项聊托管聚合必须谈数据合规。托管聚合平台是第三方你的请求数据会经过它的服务器再转发给上游模型厂商这意味着你的数据面多了一个节点自然也多了数据安全方面的风险。对于处理个人隐私数据、内部业务数据的企业这是一个无法回避的评估项。我自己做选型时一般先问三个问题平台的隐私政策是否允许你的数据类型经过平台是否提供零日志处理或私有网络接入上游模型供应商的数据留存期限是多少这些问题通常需要法务和采购配合来评估而不是技术选型时顺带看一眼。我会在选型文档里把“数据不落第三方”作为硬约束来处理如果无法满足就直接排除托管聚合选项。4. 智能路由当路由从“转发”变成“决策”前三层本质上都是“转发路由”——目标模型名单是确定的策略是预先写好的路由请求只是按规则执行。第四层智能路由的核心变化是模型选择不再是一个预先写死的映射而是由系统根据请求特征、实时状态、历史反馈动态决策的过程。这一层是 2026 年多模型路由赛道里增长最快的部分也是争议最大的部分。4.1 静态路由和智能路由的分界线在哪我见过不少团队把“加权轮询”叫智能路由这个词被严重滥用了。真正的智能路由至少包含三个要素中的一两个基于请求特征的分类决策、基于实时状态的目标优化、基于历史反馈的自适应调整。最典型的智能路由实现是前端加一个分类器。请求进来后先由一个分类任务判断这个请求属于哪种类型——是事实性问答、创意写作、编程辅助还是复杂推理——然后根据分类结果路由到特定模型。这个分类器可以是独立小模型也可以是基于规则的模型标识比如让用户显式声明任务类型。以编程辅助为例一个简单有效的路由策略代码补全类请求走低延迟模型代码讲解、重构建议走中档通用模型复杂架构设计、多文件上下文推理走高阶推理模型。这个策略如果靠应用层写死也可以运行——因为业务方本来就知道这次请求是“补全”还是“重构”。但智能路由的区别在于当业务方来不及显式声明任务类型时系统可以通过请求本身的特征自动判断。进入生产之后路由决策不再依赖人的判断而是依赖一个持续更新的分类模型。4.2 成本、延迟、质量三个目标如何同时优化实际是个多目标问题做智能路由最容易犯的错误是只盯着“省钱”或者只盯着“质量”。真正落地的智能路由必须在成本、延迟、质量三个目标之间找到平衡。这三个目标互相牵制没法靠一个轻量分类器一劳永逸地解决。我举一个具体场景你在做一个客服问答系统。理论上问候语和意图明确的业务咨询完全可以用小模型解决但长尾问题、投诉情绪强烈的对话需要大模型甚至高阶推理模型。如果只用小模型长尾问题回答质量必然垮掉如果全都走高阶模型成本高 20 到 50 倍而且部分简单对话延迟反而更高。解决这个问题我的经验是先建一条“质量底线规则”——先保证不塌再谈优化。高阶模型的调用比例设一个硬上限比如不超过总请求量的 20%对于分类置信度低于某个阈值的请求直接走高阶模型而不是冒险用低阶模型处理。智能路由从来不是“大多数时候选便宜的”而是“在规则约束内动态调整分配”。预算约束也不能只看单请求成本要看整体趋势。按天设置成本预算路由系统在预算充足时可以把更多流量分配给高质量模型预算吃紧时则平滑地降低高成本模型的分配比例。这种“随着实时状态变化”的分配策略比死板的静态配置要健壮得多。4.3 基于提示特征的路由和基于反馈的路由优先做哪个智能路由内部其实还有两个不同的技术方向很多团队把它们混为一谈导致落地时目标不清。一个是基于提示特征的路由。核心逻辑是“看请求的内容判断该用哪个模型”。它基于请求本身的信息做出决策预设规则或者模型分类。优点是可以提前预判不需要等模型跑完再决策缺点是如果请求特征和模型能力之间的关系不明确分类效果会很差。另一个是基于反馈的路由。核心逻辑是“用历史数据说话”。每完成一个请求系统性评估回答质量人工打分、可执行结果验证、自动化规则校验等然后把这些质量反馈信号作为下一次路由决策的依据。它更接近推荐系统里的强化学习。优点是不需要预设分类规则能够逐步逼近最优分配缺点是反馈数据的质量要求极高而且收敛需要时间。如果只能先做一个方向我强烈建议先做基于提示特征的规则型路由。原因很简单它可以快速建立一个不差于静态路由的基线同时积累起来的请求特征数据恰好是后续做基于反馈路由的先验知识。等特征路由稳定运行一段时间积累了足够多的质量和成本日志之后再引入反馈信号做动态调整是更稳妥的路径。直接上来就搞强化学习式路由对数据标注、评估体系、实验设计都是巨大挑战绝大多数团队根本走不到收益阶段就会因为内耗放弃。5. 四层选型决策框架六个问题、三个组合、三个教训聊完每一层的能力边界最后给一套可以直接套用的决策方法。多模型路由的选型本质上是根据你自己的团队规模、调用量、业务复杂度和合规约束为这四层做组合。我先给一套自测问题再给几个高频组合最后复盘几个真实踩坑教训。5.1 开始设计架构前先回答这六个问题你的日均调用量是多少这个直接决定了值不值得引入网关。一万次日调用以下工具侧路由通常绰绰有余十万以上网关的治理收益就能体现出来百万以上智能路由的优化空间才会真正显著。你的业务方数量是多少一个团队自己做工具侧路由最省事三个以上团队共用模型网关的共享密钥、预算分摊、审计价值就出现了。你对模型供应商的切换频率预期是多少计划性很强、一年换不了几次工具侧写映射就行经常有新的模型版本要灰度验证网关的模型映射切换成本更低。你的数据合规约束有多严格严格到不能过第三方平台托管聚合基本出局允许则是省心选项。你的运维人力是否养得起网关有没有专职的人能处理半夜上游故障和组件升级没有的话优先托管聚合。你的成本敏感性多高成本只是“不要离谱”还是“每个百分点都要抠”后者意味着你需要采集真实成本数据才有资格做智能路由。5.2 三个我自己常用的架构组合并不存在唯一的“最佳实践”。2026 年我见到比较合理的组合大概是这三类组合 A轻量起步型工具侧路由 一个供应商的直连最多再加一个备用供应商。适合日均调用量小、团队单一、处于验证业务场景阶段。成本最低最大的缺点是后续迁移到网关时需要把散落在代码里的路由逻辑收拢。组合 B标准治理型工具侧适配层 自托管网关LiteLLM 这类 可选的一份托管聚合作为备份通道。适合日均调用量中等、多个业务方共用、有基础运维能力。这个组合的核心是工具侧负责业务规则网关负责统一入口、密钥配额、成本统计和稳定性的基础托管聚合作为网关故障时的逃生通道。组合 C规模优化型自托管网关 智能路由层 托管聚合部分流量。适合日均调用量高、团队有专门 AI 基础设施和算法工程师。智能路由层不是替代网关而是挂在网关之上的一层决策器网关收到请求后先请求路由决策服务再决定转发给哪个上游。这里的托管聚合已经不是为了省心而是为了补充某个网关已经接不进的高质量模型。5.3 我踩过的三个坑最后分享三个真实踩坑经历希望帮你省掉一点时间。第一个坑是过早为不存在的性能问题做架构。我曾经在一个日调用量只有几千次的项目里花了三周部署自托管网关、配置多节点、写负载均衡。结果上线第一周就发现真正的瓶颈根本不在网关而在某个上游供应商的配额限制。如果当时用工具侧路由加一个配额监控完全就够了。后来我把网关拆掉了干活的还是三层逻辑——这是成本最直接的一次教训。第二个坑是网关配置里过度抽象模型名。为了“让下游不感知模型变化”我把所有逻辑模型名都映射成了一个统一名称包括一些能力差距巨大的模型。结果下游应用在不知道的情况下同一段代码有时得到的是高推理能力模型的回复有时是低能力模型的回复业务表现异常波动。模型映射的粒度一定要能反映能力层级不要把不同能力等级的模型塞进同一个逻辑名。统一是给运维看的不是给业务能力抹平用的。第三个坑是智能路由上线后缺乏评估机制就放量。我做过一个基于反馈的路由实验模型自动把更多流量分配给了“看起来省钱”的路线但因为评估反馈信号有滞后很多低质量回答在评分系统还没反映出问题时已经大面积触达用户。后来我增加了灰度流量对比每次调整路由策略都要和基线对照跑一段时间质量指标没有下滑才允许放量。多模型路由选型不输在技术能力输在阶段匹配。先用工具侧路由把业务跑通数据积累到一定量级之后再考虑网关最后再谈智能路由的优化空间。每一步都要有明确信号驱动不要让架构复杂度跑在业务前面。