一句话定义

AI 网关（AI Gateway） 是放在业务应用和模型服务之间的一层服务。应用不再直接调用某家厂商的接口，而是把请求发给网关，由网关决定用哪个模型、用哪个账号、放不放行、记不记账。

它和 API 网关是同一类东西，只是管的对象从「后端服务」换成了「模型调用」，因此多了 token 计量、模型路由、提示词缓存这些特有的事。

它解决什么问题

模型接入这件事，最初通常是一段几十行的代码：一个密钥、一个接口地址、一个 SDK。问题在规模变大之后才出现：

  • 供应商会换。 涨价、限流、区域可用性、模型下线，每一次都要改业务代码。如果三个系统里各写了一份调用逻辑，就要改三遍。
  • 密钥散落。 每个系统一份密钥，谁在用、用在哪、用了多少，事后查不清。
  • 配额没人管。 某个功能突然跑量，把整个账号的额度吃光，其他功能一起不可用。
  • 出问题定位不了。 没有统一的请求日志，只能靠业务方各自猜。
  • 成本归不了集。 月底只拿到一张总额账单，说不清是哪个功能、哪个区域花的。

网关把这些问题收拢到一个地方：应用只认一个地址、一个协议，剩下的事在这一层解决。

关键做法

  • 统一协议。 对外暴露一套接口（OpenAI 兼容格式事实上已成通用写法），对内适配各家供应商，差异在网关内部消化。
  • 路由与降级。 按模型能力、价格、地域做路由；主供应商超时或报错时切备用。要注意重试的幂等性——生成类请求重试可能重复计费。
  • 限流与配额。 按密钥、租户、门店、功能分别设定速率和总量上限。限流要能分级：先排队、再拒绝，比直接报错体验好。
  • 缓存。 完全相同的请求可短期缓存；更实用的是提示词前缀缓存，固定不变的系统提示和工具定义不必每轮重算。
  • 可观测。 请求日志、token 计数、延迟分位数、错误率。只记平均值没有意义，长尾才是用户抱怨的那部分。
  • 密钥托管与审计。 密钥只存在网关一侧，应用拿的是网关签发的凭证；每次调用留下「谁、什么时候、调了什么」的记录。
  • 插件化。 鉴权、脱敏、内容过滤、日志这些横切能力做成可插拔的插件，而不是写死在转发逻辑里。开源项目 Respan 就是用 Rust 写、以插件为组织方式的一个例子。
  • 想清楚它自己挂了怎么办。 网关在调用链路上，是新增的单点。常见做法是保留一条应急直连通道，或者在网关不可用时降级到规则方案。

用不上的时候

  • 只有一个应用、一个供应商、一个密钥。 多一层转发只会多一个故障点，把配置集中管理就够了。
  • 纯端侧推理。 模型跑在设备本地、不走网络，网关在云侧，管不到这一段。
  • 团队没有运维能力。 网关挂了全线不可用，这一层的可用性要求不低于它所代理的模型服务。
  • 调用量极小。 一年几千次调用，做配额和成本归集的收益抵不上维护成本。

常见误区

  1. 「加了网关模型效果会变好。」 网关不改模型、不改提示词，它只管调用怎么被路由和记账。
  2. 「密钥集中起来就安全了。」 暴露面确实变小了，但网关本身变成高价值目标，它的鉴权、日志脱敏、网络暴露面要单独按安全组件对待。
  3. 「网关就是个反向代理。」 转发只是基础能力，真正的价值在配额、降级、成本归集这些运营能力上——没有这些，它只是一跳多余的延迟。

参考

  • Hacker News Launch HN：Respan (YC W24) – Open-source Rust AI gateway built around plugins（2026-10-20），news.ycombinator.com/item?id=50167583。以插件为组织方式的开源 AI 网关，可作为这一层职责划分的参考实现。

延伸阅读

相关词条

火眼识别提供端侧视觉引擎与设备管理平台，相关方案见 火眼识别官网。