大模型网关详解：多模型路由、Fallback、限流与成本控制

当模型调用散落在各个业务代码里，换供应商、查成本、做容灾都会变成全库搜索。这篇教程讲清为什么需要统一的模型入口，拆解 LLM 网关的核心能力——多模型路由、负载均衡与故障转移、密钥托管、语义缓存、Token 审计，并厘清它与传统 API 网关的关系和主流实现形态。

它解决什么问题

很多团队的第一个 AI 功能都是直连模型：Service 里 new 一个供应商 SDK，填上 Key 就上线了。链路短、体验好，但规模稍微起来，问题会集中爆发：

模型名写死：模型升级、下线或换供应商时，要逐个服务改代码。
密钥分散：多个服务各自保存 API Key，轮换困难，泄露面随服务数线性扩大。
限流失控：供应商返回 429 后各业务自行重试，越重试越糟，最终拖垮线程池。
成本不可见：月底只有总账单，无法按租户、功能、Prompt 版本归因。
模型错配：意图分类和复杂推理都走旗舰模型，简单任务浪费钱，关键任务失败时又缺少备用链路。

LLM 网关的作用，就是在应用层与模型供应商之间提供一个统一调用入口，把这些共性逻辑从业务代码里剥离成基础设施。

核心原理

网关的定位：API 网关能力 + 模型控制面

传统 API 网关管通用 HTTP 流量：鉴权、转发、限流、日志。LLM 网关在此之上还要处理模型特有的问题：模型选择、Token 计量与预算、上下文长度、供应商协议差异、流式输出、成本归因。它是 L7 的 AI 专用治理层，与已有 API 网关互补而非替代——像 Kong AI Gateway 这类产品，就是在成熟 API 网关上叠加 AI 插件。

还要区分一个常被混用的概念：Router 只负责「这个请求选哪个模型」，输入是任务类型、预算、上下文长度，输出是目标模型；Gateway 管请求的全生命周期——鉴权、限流、路由、故障转移、日志、成本记录。Router 只是 Gateway 内部的一个环节。只做转发的是代理；开始记录为什么选这个模型、怎么扣预算、失败后怎么兜底，才进入网关的范畴。

深入机制

多模型路由

路由策略按复杂度演进：固定规则（按场景绑定模型层级）→ 级联路由（便宜模型先试，解析失败或置信度不足再升级）→ 语义/分类路由（用轻量分类器判断复杂度）→ 学习型路由（基于历史质量数据训练）。一份典型的规则配置：

routes:
  - scene: intent_classification
    primary: tier-fast
    fallback: [tier-nano, tier-balanced]
    max_output_tokens: 256
  - scene: complex_reasoning
    primary: tier-flagship
    fallback: [tier-pro]
    max_output_tokens: 4096
default:
  primary: tier-balanced

注意 tier-* 是内部能力层级，不是供应商真实模型 ID。由模型注册表把层级映射到当前可用的具体模型，模型升级时只改注册表，不动业务规则。路由日志除模型名外还必须记录 route_reason（命中的规则、估算 Token、候选列表），否则无法还原一次选择的依据。

负载均衡与故障转移

网关在同模型的多个 API Key、多个区域、多家供应商之间分配流量，并把 P95 延迟、429 率纳入健康权重。故障转移的关键是按错误类型决策：

网络瞬断、供应商 5xx：短重试后切备用模型，配合熔断防止雪崩。
429 限流：读 Retry-After，必要时排队或切换同级模型。
上下文超限：不是重试能解决的，应压缩上下文或换长上下文模型。
参数错误、安全拒答：修请求或走业务拒答流程，不要重复打供应商。

两个坑必须提前设计：带副作用的请求（工具执行、扣费）切换前要确认幂等性；流式输出已发给用户的片段，不能把两个模型的输出拼成一段结果。

密钥托管

所有供应商密钥集中在网关（或对接 KMS/Vault），业务服务只持有网关颁发的内部凭证。好处是轮换只改一处、泄露面收敛、可按租户分配独立 Key 做配额隔离。托管网关的 BYOK（自带密钥）模式同理：密钥由你保管，网关只做转发与计量。

语义缓存

精确缓存（请求完全一致时命中）适合 FAQ；语义缓存把语义相近的问题映射到旧答案，命中率更高但风险也更大——「我的订单为什么没发货」和「我的订单能不能退款」在向量空间里很接近，业务含义却完全不同。因此缓存键必须隔离租户、权限范围、数据版本和 Prompt 版本，向量相似度只能作为候选条件，不能替代这些边界。带权限、实时状态、私密上下文的请求应直接绕过缓存。

Token 审计与配额

只看请求数限流是不够的：500 Token 的调用和 80K Token 的调用成本差几十倍。稳妥的做法是四步闭环：估算 → 预留 → 真实 usage → 对账修正。调用前按估算值在用户、租户、模型、供应商四个维度预扣预算，调用结束后用供应商返回的真实 usage 结算。同时把 request_id、租户、场景、Prompt 版本、模型层级、输入输出 Token、成本、延迟逐笔落库——成本优化的前提永远是知道钱花在哪。

工程实践

实现形态按团队规模递进：

应用内轻量模块：单团队、单供应商时，一个统一封装超时、重试、日志的 LLMClient 就足够，不必引入额外组件。
配置化网关模块：多场景共用模型后，补路由规则、Fallback、Token 预算。
独立部署或引入成熟方案：多团队、多租户、按租户计费时，再考虑 LiteLLM 或独立网关服务。

对外暴露 OpenAI 兼容接口是常见选择：业务方改个 base_url 就能切换。但要注意这只是入口形状统一，Anthropic 的 thinking、Gemini 的 grounding 等专属能力仍需 Provider Adapter 做扩展字段转换。

对比与权衡

方案	优势	适用场景	局限
自研轻量模块	可控、贴合内部权限与计费体系	有后端能力、需求明确	功能深度靠自己积累
LiteLLM	多供应商接入快、OpenAI 兼容、生态成熟	快速集成、多模型实验	深度企业治理需改造；生产要锁版本、扫漏洞
Cloudflare AI Gateway	托管入口、日志缓存限流开箱即用	已用 Cloudflare 的团队	数据与审计不完全自控
Kong AI Gateway	复用企业 API 治理体系	已有 Kong 基础设施	对小团队偏重，部分插件需企业授权

选型的顺序不要反：先解决工程治理（收口、日志、Fallback、预算），再追求智能路由。没有稳定评测集和线上 Trace，学习型路由无法证明自己比规则路由更好。

面试视角

为什么需要 LLM 网关？ 它把供应商 API 差异收敛到一处，统一管理路由、密钥、限流、Fallback、成本归因与观测。没有网关，这些逻辑会散落在每个业务调用点，换模型、查成本、排故障都要全库搜索。

网关会增加多少延迟？ 路由、预算估算、日志写入在同机房完成，开销有限；端到端延迟的大头是模型推理、输出 Token 数和跨区域网络。网关反而能通过语义缓存、快模型路由、上下文压缩降低整体延迟。

Fallback 设计要注意什么？ 按错误类型决定是否切换（429/5xx 可切，参数错误不可重试）；带副作用的请求先确认幂等；流式场景不能拼接两个模型的输出；降级到低配模型时要显式标记，高风险任务宁可返回「稍后再试」也不悄悄降质。

语义缓存有什么风险？ 相似不等于相同，可能把用户带进错误流程；缓存键必须隔离租户、权限、数据版本与 Prompt 版本，命中率要和投诉率、转人工率一起评估。

Router 和 Gateway 的区别？ Router 只回答「选哪个模型」；Gateway 管请求全生命周期的治理。可以只有 Router 没有 Gateway（一个按任务返回模型名的函数），但解决不了密钥、限流、审计与成本问题。

小结

LLM 网关把模型调用从业务代码剥离成可治理的基础设施，价值不在「接了多少模型」，而在路由、容灾、配额与审计的收口。
核心能力五件套：多模型路由、负载均衡与故障转移、密钥托管、语义缓存、Token 审计；Token 配额走估算-预留-对账闭环。
它与 API 网关互补：一个管通用流量，一个管模型特有治理；Router 只是它内部的一环。
落地从应用内轻量模块起步，按真实流量演进到独立部署或 LiteLLM 等成熟方案；先工程治理，再智能路由。