什么是开源 AI 网关,为什么选开源
开源 AI 网关是一类源码开放、可自托管的 AI 网关,让你把多家大模型(LLM)与 AI Agent 流量收敛到一个可自主掌控的统一入口来路由、治理与观测。当团队从调用单一模型,发展到同时接入多家大模型、给多个应用与 AI Agent 供能时,分散的密钥、各异的接口、失控的 token 成本与缺失的审计都会成为难题;AI 网关把这些统一收敛到一个入口来解决。选择开源实现,则在此之上多了三点关键收益。
可自托管
把网关部署在自有服务器或 VPC 内,自主掌控版本、配置与升级节奏,不依赖某个托管服务的可用性与地域。
数据驻留
提示词与模型响应可留在自有网络内、不经第三方管控面中转,更契合数据驻留与合规审计的要求。
无供应商锁定
源码开放、协议明确,可自由二次开发与迁移,不被单一厂商的定价、路线或接口变更绑定。
开源 AI 网关清单
以下是 2026 年较为常见、可自托管的开源 AI 网关,按协议、语言与能力侧重逐个说明。
AISIX
Rust · 数据面 Apache-2.0
Rust 编写、数据面 Apache-2.0 的开源 AI 网关,由 Apache APISIX 原班团队打造。在同一网关上提供语义路由、模型合议(ensemble)、提示词 / 响应护栏与 MCP 网关;可部署在自有 VPC 内、仅保留出站连接,提示词与响应不出自有网络,适合对数据驻留与合规有要求的团队。
LiteLLM
Python · MIT
Python 编写、MIT 协议,既是 SDK 也是代理,把 100+ 家供应商统一为 OpenAI 兼容接口。开源版即含语义缓存、虚拟密钥与预算、MCP 网关,以覆盖广度和轻量易接入见长,常用于快速统一多家模型的接入层。
Portkey
TypeScript · 网关 MIT(治理平台商业版)
TypeScript 编写的开源网关(MIT),搭配托管治理平台(商业版),覆盖 1,600+ 模型、20+ 原生护栏(另有合作方集成)与 MCP 网关。开源网关本身可自托管;语义缓存、SSO 等偏企业级的能力主要在其企业 / 托管版本中提供。
Envoy AI Gateway
Go · Apache-2.0
基于 Envoy 的开源 AI 网关,Apache-2.0、Go 编写,面向 Kubernetes 原生场景,提供多模型路由与故障转移、token 限流,并在 v1.0 GA 中支持 MCP。定位偏云原生流量层,不内置原生护栏与语义缓存,护栏等能力通常需外部组件配合。
需要说明的是,One API(Go / MIT)与 New API(Go / AGPL-3.0,在 One API 基础上二次开发)常被一并提及,但它们属于「Token 中转站」,以中转与计费为核心,把多家模型统一到 OpenAI 兼容接口并做令牌额度与渠道负载均衡,通常不提供语义路由、模型合议、护栏、MCP 网关等 AI 原生治理,因此不算完整意义上的 AI 网关。两者的差异可参阅 One API 与 New API 对比。
如何选型
在开源 AI 网关之间做选择,可以从三个角度出发。
自托管与数据驻留
若对数据驻留与合规有要求,优先看能否在自有 VPC 内自托管、提示词与响应是否不出网。例如 AISIX 的数据面为 Apache-2.0,可部署在自有网络内、仅保留出站连接;Envoy AI Gateway 则适合已在 Kubernetes 上、希望复用 Envoy 数据面的团队。
治理需求
若只需中转 + 计费,轻量的 Token 中转站即可;若需要语义路由、模型合议(ensemble)、提示词 / 响应护栏、成本预算乃至 MCP 网关等治理能力,则应选择在开源版即覆盖这些能力的 AI 网关,并留意哪些能力被放在了商业 / 企业版。
协议宽松度
关注开源协议约束:Apache-2.0、MIT 相对宽松,便于自托管与二次开发;AGPL-3.0 则要求「对外提供修改版时需开源」,对以 SaaS 形式对外提供服务的团队有额外义务。同时评估上游模型的兼容协议(OpenAI / Anthropic 等)与是否支持 MCP。
横向对比
以上清单侧重逐个说明各家的协议、语言与特点。若想在协议、语言、语义路由、护栏、MCP、自托管等维度做一张横向对照表,进而快速缩小候选范围,可参阅 AI 网关对比。若你对 AI 网关的定义与核心能力还不熟悉,建议先读 什么是 AI 网关。
