AI 模型网关的通用架构：从 API 代理到推理治理层

最初接入大模型时，直接在业务里配置一个 Base URL 和 API Key，往往就够了。问题出现在模型越来越多之后：不同供应商的协议和错误格式不一样，密钥散落在各个服务里，模型切换要改业务配置，用量和成本也很难统一统计。

这时，系统中间多出一层模型网关（AI Gateway）就有了意义。但网关不应该只是「把请求转发到另一个 URL」；它还要回答一系列治理问题：谁可以调用哪个模型？请求应该走哪个渠道？出错时能不能安全切换？费用如何归属？

本文从通用架构角度拆解这些问题，并以 ai-gateway 作为一份具体实现的例子。关注的是可复用的设计思路，而不是某一种技术栈的标准答案。

从反向代理到推理治理层

普通反向代理主要关心转发、负载均衡和连接管理。模型网关当然也要转发请求，但模型调用还带着一些特殊语义：

请求里有模型名、采样参数、工具调用、流式选项等模型概念；
上游计费通常基于 token 或其他 usage，而不是单纯的请求次数；
不同渠道可能提供同一个逻辑模型，也可能有不同的价格、能力和稳定性；
流式响应开始返回后，客户端已经看见部分内容，重试不能再当作透明操作。

因此，网关更像一个推理治理层：把身份、权限、路由、可靠性、成本和审计集中在请求路径上，让业务不必逐家供应商实现这些能力。

它不一定需要负责训练模型、提供公开的用户付费系统，或实现无限规模的服务发现。边界由使用场景决定；关键是让业务接入面稳定，同时让内部策略有清晰的归属。

先分清控制面和数据面

把管理配置和实际推理请求分开，是一种有用的思考方式：

      text
      
    


1
2
3
4
5
6
7
8
9


控制面（管理与配置）
供应商 / 渠道 / 模型 / 密钥 / 价格 / 限额 / 运行参数
                     │
                     │ 配置快照或变更通知
                     ▼
数据面（在线请求路径）
客户端 → 协议入口 → 策略处理 → 路由与适配 → 上游模型
                     │
                     └→ 用量、成本、日志与指标

控制面负责维护「系统应该怎样运行」；数据面负责让一条具体请求经过这些规则并得到响应。小型单体服务可以把二者放在同一个进程里，但职责仍然值得分开：管理接口不应绕过统一的配置入口，在线请求也不应该随意到处读取和修改管理状态。

多实例部署时还要回答一个问题：控制面修改了配置，数据面实例何时看到新值？每次请求都查数据库，语义直观但会把数据库放进热路径；本地缓存则减少依赖和延迟，但需要解决更新传播与消息丢失。常见折中是本地快照 + 变更通知 + 定时刷新兜底。这不是唯一解，配置规模、更新频率和一致性要求才决定选择。

请求链路：先统一入口，再分阶段处理

一个典型的数据面可以抽象成这样：

      text
      
    


 1
 2
 3
 4
 5
 6
 7
 8
 9
10


客户端协议
    │
    ▼
解析与归一化 → 鉴权 / 权限 → 配额与成本预估 → 隐私处理
    │
    ▼
路由准备 → 上游调用（适配 / 重试 / 熔断 / 降级）
    │
    ▼
响应归一化 → usage 结算 → 日志 / 审计 / 指标

这张图是职责图，不要求所有实现都严格按同一种顺序执行。例如有些检查可以并行，有些策略只在特定请求上启用。重要的是把每个阶段的输入、输出和失败语义定义清楚：鉴权失败不该进入上游调用；成本预估失败时是拒绝请求还是走降级预算；客户端断开时已预扣的额度由谁释放。

把处理步骤定义为过滤器、拦截器或责任链都可以。形式不是重点，重点是避免把鉴权、路由、计费和 HTTP 细节全部塞进一个巨大方法里，也不要让每个适配器各自重复一遍公共策略。

协议归一化：统一核心，不要假装差异不存在

多协议入口通常需要一个内部请求模型。例如 OpenAI 风格的 Chat Completions 和 Anthropic Messages，可以各自解析外部请求，再转换成内部的 ChatRequest，进入同一条鉴权和路由路径：

      text
      
1
2
3

OpenAI 请求 ─────┐
                 ├─→ 内部请求模型 → 策略链 → 上游适配器
Anthropic 请求 ──┘

这样可以避免每增加一种客户端协议，就复制一套完整网关逻辑。但「归一化」不等于「所有协议完全相同」。工具调用、思考内容、图片输入、缓存 usage、流式事件等能力可能只有部分协议或供应商支持。如果内部模型只保留最小交集，能力会丢失；如果无限制地塞入供应商专属字段，内部模型又会退化成杂物袋。

较稳妥的做法是：稳定的通用字段进入核心模型；差异能力通过明确的能力声明、扩展字段或协议适配层处理；不支持的功能要显式拒绝或说明，而不是静默丢弃。供应商适配器负责把内部模型转换成上游请求，并把响应、错误和 usage 翻译回来。

扩展点要放在变化的边界上

模型网关里有几类变化特别频繁：供应商协议、路由策略、限流策略和计费口径。把它们放在明确的扩展边界上，能减少新增能力对已有代码的影响。

以供应商适配器为例，可以定义类似这样的能力边界：

      text
      
    


1
2
3
4
5


ProviderAdapter
  ├─ 声明支持的能力（chat / embedding / streaming 等）
  ├─ 构造上游请求
  ├─ 解析普通响应和流式事件
  └─ 统一错误与 usage

新增供应商时，理想情况是增加一个适配器，而不是在路由、计费、管理页面里同时加入大量 if provider == ...。但抽象也不必过度：如果两个供应商协议完全兼容，复用兼容适配器比为每一家创建空壳类更简单。

用一个具体实现校验架构

ai-gateway 采用 Java 21、Spring WebFlux，内部把 OpenAI 和 Anthropic 入站请求收敛到统一处理链，并通过上游适配器接入多类模型协议。它将管理配置与在线请求处理分开组织，热路径主要使用配置快照，而不是每次请求都重新查询完整配置。

这些选择是一个项目的落地方式，不是架构定律。小型个人工具可能不需要多实例配置广播；只接 OpenAI 兼容服务时，也可能不需要独立的协议归一层。判断标准不是模块数量，而是变化是否集中在合理边界、请求链路是否可理解、失败行为是否可预测。

小结

设计 AI Gateway 时，可以先抓住四件事：

把它定位为推理治理层，而不只是反向代理；
区分管理配置的控制面和处理在线请求的数据面；
用统一内部请求模型复用公共策略，同时明确保留协议差异；
把适配器、路由和策略放在清楚的变化边界上，并写明失败语义。

做好这些，后续再增加计费、故障恢复或合规能力时，才有一个可扩展而不是越改越乱的骨架。

项目地址：liku-yu/ai-gateway。

相关阅读：

多模型路由与故障恢复：重试、熔断和降级的边界 —— 聚焦请求如何选择上游，以及失败后如何处理
模型网关的治理设计：计费、密钥与隐私保护 —— 聚焦成本、安全与运营治理