一个很典型的演变过程：公司第一个 AI 功能上线时，工程师在代码里配了个 OpenAI Key，直连官方 API，一切都好。半年后，五个团队在用三家模型厂商的接口，Key 散落在十几个配置文件里，没人说得清这个月 token 花在了哪、哪个 Key 有没有泄露、切换模型要改多少处代码。这时候需要的东西，就是 AI 网关（AI Gateway）：一个部署在所有应用和所有模型 API 之间的统一入口。
这篇文章讲清 AI 网关到底解决什么问题、和传统 API 网关差在哪、以及自建和开源方案怎么选。
AI 网关的位置：所有应用只认网关，网关统一面对所有模型厂商。
和传统 API 网关有什么不同
Kong、APISIX 这类传统 API 网关做的是通用流量治理：路由、鉴权、限流、日志。AI 网关在此之上，针对大模型流量的特殊性多做了一层：
- 计量单位是 token 不是请求数：一个请求可能花 0.001 美元也可能花 5 美元，限流和计费必须按 token 算；
- 要理解多家 API 的方言：OpenAI、Anthropic、Gemini、DeepSeek 的请求格式、流式协议、错误码各不相同，网关要做协议归一（通常统一成 OpenAI 兼容格式）；
- 流式响应（SSE）是常态：日志、计量、审计都要在流式转发中完成；
- 内容本身是敏感数据：提示词里可能有客户资料、商业机密，网关是做脱敏、审计、合规拦截的天然位置。
一句话：传统网关看「流量」，AI 网关还要看「内容和成本」。
AI 网关解决的六类真实问题
1. Key 治理：从「满地都是」到「一处收口」
直连模式下，厂商 API Key 散落在各团队的代码和配置里，泄露一个就是真金白银的损失，而且没法快速吊销——你甚至不知道有多少份拷贝。网关模式下，厂商 Key 只存在网关一处，应用拿到的是网关签发的虚拟 Key，可以随时吊销、按应用限额、细粒度审计。
2. 成本可见：知道每一分钱花在哪
没有统一入口，月底账单只有厂商给的总数，分不清哪个产品、哪个团队、哪个功能花的。网关在每次转发时记录 token 用量，按应用/团队/用户维度聚合，成本第一次变得可归因——这通常是企业上网关最直接的动机。
3. 多模型路由与故障切换
模型厂商的可用性并不完美，限流、超时、区域故障时有发生。网关可以做模型路由：主力模型挂了自动切备用；简单任务路由到便宜模型、复杂任务给旗舰模型；新模型上线先切 5% 流量灰度。应用代码零改动。
4. 统一限流与配额
按 token 而不是请求数限流，才能真正控住预算：给每个应用设日预算、给每个终端用户设频次，超了返回明确错误而不是让账单爆炸。内部试用类产品尤其需要——没有配额的免费入口一定会被玩坏。
5. 合规与审计
提示词和回答的留存、敏感信息脱敏、违规内容拦截，在网关做一次，所有应用生效。金融、医疗等行业这是硬要求；出海和数据跨境场景，网关也是落实「哪些数据能出去」的执行点。
6. 协议归一，降低切换成本
应用统一说 OpenAI 方言，网关负责翻译成各厂商格式。换模型从「改代码发版」变成「改一行网关配置」，议价能力和技术自由度都握回自己手里。
成本可归因，是多数企业上 AI 网关的第一动机：谁在花钱、花在哪个模型、值不值。
什么时候该上网关
不是所有团队都需要。判断信号很实际：
- 两个以上团队/应用在调模型 API；
- 用了两家以上模型厂商，或有切换厂商的可能；
- 月度模型账单到了需要向老板解释构成的量级；
- 有 C 端或内部大范围用户，需要防滥用；
- 行业有审计合规要求。
命中两条以上就值得上。反过来，单人项目、单应用单模型，直连完全没问题，别为基建而基建。
方案怎么选：开源、云服务还是自建
| 路线 | 代表 | 适合 |
|---|---|---|
| 开源自部署 | LiteLLM、One API 系（New API 等）、Higress/Kong AI 插件 | 想快速收口 Key 和成本，有基本运维能力 |
| 云厂商托管 | Cloudflare AI Gateway、各大云的模型网关 | 不想运维，流量出海，接受托管 |
| 自建 | 基于 Node/Go 自研 | 有特殊路由/计费/合规逻辑，或网关本身是产品 |
主流起点是开源自部署：LiteLLM（Python 系，模型覆盖广）和 One API 一族（Go 系，国内模型支持好、带计费面板）都能在一天内跑起来。自建看似工作量大，其实核心链路（转发 + 计量 + 限流）一个星期能出可用版本，适合对计费和路由有深度定制需求的团队——具体怎么设计，我们在《从零设计一个 AI API 网关》里给了完整方案。
要警惕的是公网上的第三方「API 中转站」：它们形态上也是网关，但你的提示词和数据要过别人的服务器，Key 和计费都受制于人，稳定性和合规风险都不可控。企业场景应当自部署或用可信云服务，中转站的具体风险见《AI API 中转站避坑指南》和 API 中转站词条。
选型顺序：先明确要解决的是成本、稳定性还是合规，再对着需求挑方案。
落地注意事项
- 网关是单点：所有 AI 流量都过它，可用性要求高于任何单个应用，上线就要考虑多实例和降级路径（网关故障时允许关键应用临时直连）；
- 延迟预算：网关本身增加的延迟应控制在毫秒级，重逻辑（内容审计）尽量异步化，别挡在转发路径上；
- 流式要一等公民：SSE 转发、流中计量、流中断计费，这些细节决定网关能不能用于生产；
- 别一步到位：第一版只做「统一入口 + Key 治理 + 用量记录」三件事，路由、缓存、审计按需求逐步加。
常见问题
Q：AI 网关会成为性能瓶颈吗？ A：大模型生成本身以秒计，网关毫秒级的开销可以忽略。真正要防的是网关的稳定性短板，而不是延迟。
Q：网关能帮我省模型费用吗？ A：能，通过三条路：按任务路由到更便宜的模型、语义缓存重复请求、以及推动 Prompt Caching 的正确使用。但省钱的前提是先有用量数据——这又回到了网关的计量能力。
Q：和 LangChain 这类框架里的「多模型封装」是一回事吗？ A：不是。框架封装解决的是单个应用内的代码复用；网关是基础设施，跨应用、跨团队生效，且不要求应用改用某个框架。
小结
AI 网关的本质是把「模型调用」从各团队的私事变成公司的基础设施：Key 收口、成本可见、路由可控、审计合规一处生效。判断要不要上，看的不是技术潮流，而是你有没有被 Key 散落、账单说不清、切换模型伤筋动骨这些问题咬过。被咬过一次，你就知道它值不值。