模型网关与多模型路由
企业里很少「一个应用直连一个模型」——通常是几十个应用调十几个模型（GPT/Claude/Qwen/DeepSeek/自部署 vLLM）。在应用和模型之间加一层模型网关（LLM Gateway），统一接入、鉴权、限流、路由、计费、观测，是后端工程师最能发挥老本行的 AI 基建岗位方向。本文讲清网关解决什么、核心能力清单、多模型路由与降级策略、以及 OneAPI / LiteLLM / Higress 等选型。应用开发见 LLM 应用开发实战，运营见 LLMOps 生产运营。
面试先背这几句话
- 模型网关 = API 网关思想在 LLM 场景的落地：对上提供统一 OpenAI 兼容接口，对下对接多家模型，中间做鉴权、限流、路由、重试、计费、审计。
- 核心价值：应用与模型解耦——换模型/加模型/切流量不改业务代码。
- 多模型路由的四个经典策略：按能力路由（难度分层）、按成本路由、按可用性降级（failover）、按租户/场景定向。
- 高可用三板斧：多 Key 轮询 + 多厂商 failover + 请求重试与熔断，应对单一厂商限流/宕机。
- 开源选型：OneAPI/NewAPI（Key 分发与计费管理）、LiteLLM（Python 网关+SDK，100+ 模型统一接口）、Higress/Kong AI Gateway（云原生网关插件路线）。
一、为什么需要模型网关
没有网关时的痛点（多应用直连多模型）：
- 每个应用各自管理 API Key，泄漏风险高、轮换困难。
- 各厂商 API 格式不一（OpenAI/Anthropic/百炼/火山……），业务代码耦合厂商 SDK。
- 没有全局视角：谁在花钱、花了多少、调了什么，无从统计。
- 单厂商限流/故障直接打挂业务，没有统一的降级和重试。
- 合规要求（审计日志、敏感词过滤、数据出境）无法集中实施。
网关把这些横切关注点收拢到一层，正是后端熟悉的「API 网关 + 服务治理」模式在 LLM 上的复刻。
二、模型网关的核心能力清单 ★
| 能力域 | 具体功能 | 类比传统后端 |
|---|---|---|
| 统一接入 | 对上暴露 OpenAI 兼容 API，对下适配各厂商协议 | 协议转换/适配器 |
| 密钥管理 | 集中托管上游 Key，给应用发虚拟 Key；轮换、配额、过期 | 凭证中心 |
| 流量治理 | 限流（RPM/TPM 双维度）、排队、超时、重试、熔断 | 服务治理 |
| 多模型路由 | 按模型名/规则/权重把请求路由到不同后端 | 负载均衡/灰度 |
| 降级容灾 | 主模型失败自动切备用模型/备用厂商 | failover |
| 计费与配额 | 按 token 计量、按租户/应用配额与账单 | 计量计费 |
| 观测审计 | 请求日志、延迟/成本指标、trace、内容审计 | 可观测性 |
| 安全合规 | 敏感词过滤、PII 脱敏、提示注入检测 | WAF |
| 缓存 | 语义缓存/精确缓存，命中直接返回 | 网关缓存 |
面试表达：网关的本质是把「调模型」从每个应用的私事变成平台的公共服务。
三、限流的特殊性：RPM 与 TPM 双维度 ★
LLM 限流和普通 API 不同，要同时管两个维度：
- RPM（Requests Per Minute）：请求数——防打爆并发。
- TPM（Tokens Per Minute）：token 数——LLM 的真实成本/容量单位；一个超长请求可能顶几百个短请求。
实现要点：
- 上游厂商的配额本身就是 RPM+TPM 双限，网关要按上游配额做全局配额分配（多个下游应用共享一个上游 Key 的额度）。
- token 数在请求前只能估算（输入可算，输出未知），常用「预扣 + 完成后校正」的记账方式。
- 超限策略：排队（适合离线）、快速失败（适合在线）、降级到低优模型。
四、多模型路由策略 ★
4.1 四种经典路由
| 策略 | 做法 | 例子 |
|---|---|---|
| 能力路由（难度分层） | 简单任务走小/便宜模型，复杂任务走强模型 | 分类/抽取→Qwen-7B；复杂推理→DeepSeek-R1 |
| 成本路由 | 同能力档位选当前最便宜/有折扣的 | 高峰用包年私有部署，溢出走按量 API |
| 可用性降级 | 主选失败/超时/限流 → 自动切备选链 | GPT 限流 → Claude → 自部署 Qwen |
| 定向路由 | 按租户/业务/合规要求固定通道 | 金融客户数据只走私有化模型 |
4.2 难度分层怎么判断
- 规则：按任务类型/输入长度/关键字（可控、简单，推荐先用）。
- 小模型打分：先用便宜模型判断难度再分发（增加一跳延迟）。
- 级联（cascade）：先让小模型答，置信度不足再升级大模型（省钱但难点在置信度评估）。
4.3 降级链设计要点
- 备选模型提示词可能要适配（各模型指令遵循风格不同），降级不是简单换 URL。
- 记录「降级命中率」：频繁降级说明主通道容量/稳定性有问题。
- 幂等与重试预算：LLM 请求贵，重试要有上限并区分可重试错误（429/超时）与不可重试（400 内容违规）。
五、成本与观测
- 计量：每请求记录 model、输入/输出 token、单价、租户；聚合出每应用/每租户/每场景的成本报表——这是老板最关心的图。
- 预算与告警：租户配额、日预算熔断，防止代码 bug 循环调用烧穿预算。
- 缓存降本：精确缓存（同 prompt 直接返回）+ 语义缓存（相似问题返回历史答案，阈值要保守）；配合上游的 Prompt Caching（前缀缓存计费优惠）。
- 观测：P95 首 token 延迟、错误率、各上游可用性、成本趋势；接入 OpenTelemetry / Langfuse 做 trace（见 LLMOps 生产运营）。
六、开源选型对比 ★
| 项目 | 定位 | 特点 | 适合 |
|---|---|---|---|
| OneAPI / NewAPI | Key 分发与计费网关（Go） | 部署简单、渠道管理、令牌配额、国内生态适配好；NewAPI 是活跃分支 | 中小团队统一管 Key 与计费 |
| LiteLLM | Python SDK + Proxy | 100+ 模型统一 OpenAI 格式、路由/重试/预算/回调齐全、社区活跃 | Python 技术栈、需要程序化路由 |
| Higress AI 网关 | 云原生网关插件（阿里开源） | 基于 Envoy，网关级性能，AI 插件（多模型/限流/缓存/安全） | 已有云原生网关体系的企业 |
| Kong AI Gateway | 传统 API 网关的 AI 扩展 | 沿用 Kong 插件生态 | Kong 存量用户 |
| 自研 | 基于 Spring Cloud Gateway / Nginx 等 | 完全可控，工作量大 | 有强定制需求的大厂 |
Java 后端面试可说：用 Spring Cloud Gateway 自研过滤器链实现虚拟 Key 鉴权 + TPM 限流 + 多渠道 failover，这是把老技能迁移到 AI 基建的绝佳叙事。
七、落地架构示例
应用A/B/C ──虚拟Key──► LLM 网关
├─ 鉴权/限流(RPM+TPM)/审计
├─ 语义缓存 ──命中──► 直接返回
├─ 路由器：能力分层 + 成本 + failover
│ ├─► OpenAI / Claude（外部 API）
│ ├─► 火山/百炼/DeepSeek API
│ └─► 自部署 vLLM 集群（内网）
└─ 计量计费 + trace ──► 报表/告警设计审查清单：虚拟 Key 是否可细粒度回收？TPM 记账是否防超卖？降级链是否验证过提示词兼容？预算熔断是否演练过？敏感数据是否只走合规通道？
八、系统设计题怎么答
题目：「设计一个公司内部统一模型网关，支持多个业务接入 OpenAI、Claude、Qwen、DeepSeek 和自部署 vLLM。」
可以按这个顺序答：
- 澄清需求：多少业务接入、QPS/RPM/TPM、是否支持流式、是否需要私有化和审计。
- 对上接口：提供 OpenAI-compatible API，业务只拿虚拟 Key，不直接接触上游 Key。
- 对下适配：每个供应商做 adapter，统一消息格式、错误码、token 统计和流式协议。
- 路由策略：按模型名、能力、成本、租户、可用性选择上游；支持灰度和权重路由。
- 流量治理：RPM/TPM 双限流、排队、超时、重试、熔断、failover。
- 计费观测：按租户/应用/model 记录 token、成本、延迟、错误率、降级命中率。
- 安全合规：虚拟 Key 回收、PII 脱敏、敏感内容审计、数据出境策略。
- 演进路径：先做统一接入和 key 管理，再做路由降级，最后接语义缓存、评测和自动调度。
一句话总结：
模型网关不是为了多包一层 HTTP，而是把模型调用变成可治理的平台能力：谁能调、调哪个、花多少钱、失败怎么办、出了问题怎么查，都在网关层统一解决。
高频追问
- 为什么要模型网关，直连不行吗？ 多应用×多模型下，Key 安全、协议差异、限流降级、成本审计都是横切问题，集中到网关一层解决，应用与模型解耦。
- LLM 限流和普通 API 限流有什么不同？ 双维度：RPM 管并发、TPM 管真实成本容量；输出 token 未知需预扣+校正记账。
- 多模型路由有哪些策略？ 能力分层、成本路由、可用性降级（failover 链）、租户/合规定向；级联方案可进一步省钱。
- 降级到备用模型有什么坑？ 各模型提示词风格与能力差异，需适配验证；重试要区分错误类型并设预算；监控降级命中率。
- 怎么防止 LLM 成本失控？ 租户配额+日预算熔断+成本报表+缓存（精确/语义/上游 Prompt Caching）+ 简单任务路由小模型。
- OneAPI 和 LiteLLM 怎么选？ OneAPI/NewAPI 偏 Key 分发计费、部署简单；LiteLLM 偏程序化路由与 Python 生态、功能更全；云原生体系选 Higress/Kong 插件路线。
- 后端工程师在这个方向的优势是什么？ 网关本质是 API 网关+服务治理+计量计费的组合，全是后端成熟技能，只是治理对象从微服务变成了模型。