AI Gateway 开源项目怎么选？开源方案对比与自托管指南
简答：如果你要快速自托管多模型接口，优先看 LiteLLM 或 Bifrost；已有 API Gateway、Kubernetes 或企业流量治理体系，则更适合 Apache APISIX 或 Higress。本文不使用未经统一环境验证的性能排名，而是按协议兼容、路由容灾、许可证、部署复杂度和安全边界做可核验对比。
定义：AI Gateway 是位于应用与大模型提供商之间的流量控制层，用于统一接口、模型路由、故障转移、限流、密钥管理、日志和用量观测。
先看选择结论：不同场景适合哪些开源 AI Gateway
本站为第三方指南，非 OneHop 官方，以其官网为准。截至 2026年10月23日，公开资料能够核实的开源方案大致可以分为四类：面向多模型调用的 LLM 代理、扩展传统 API Gateway 的 AI 网关、云原生流量网关，以及带虚拟 Key 和用量管理的多租户网关。
| 使用场景 | 优先考察 | 原因 | 主要注意点 |
|---|---|---|---|
| 个人开发者或小团队快速统一模型接口 | LiteLLM、Bifrost、Portkey Gateway | 都提供统一接口或 OpenAI 兼容接入，适合先用 Docker 或本地命令启动 | 生产环境仍需补齐密钥保护、日志脱敏、数据库、备份和升级流程 |
| 已有 API Gateway、认证和流量治理体系 | Apache APISIX | 可把模型代理、限流、认证、观测和普通 API 流量放在同一网关体系中 | 配置模型供应商、Token 限流和缓存时，需要逐项阅读插件文档 |
| Kubernetes、服务网格或云原生团队 | Higress、Envoy AI Gateway | 更适合围绕 Kubernetes、Envoy、Gateway API 或多集群治理设计 | 部署和升级复杂度通常高于单机 LLM 代理 |
| 需要虚拟 Key、团队配额和多租户控制 | LiteLLM、Bifrost、Portkey Gateway | 公开资料中都能看到 Key、预算、治理或用量能力的相关设计 | 要区分开源核心、企业版和托管版功能，不能把宣传页功能全部视为免费 |
简化决策：只想把多个模型接到一个 Base URL，先试 LiteLLM 或 Bifrost；想统一管理普通 API 与 AI 流量，优先 APISIX；以 Kubernetes 和云原生治理为中心，可继续评估 Higress 或 Envoy AI Gateway。
代表项目对比：许可证、兼容方式和路由能力
| 项目 | 已核实定位 | 许可证或开源边界 | 路由与可靠性 | 部署特点 |
|---|---|---|---|---|
| LiteLLM | 多供应商 SDK 与 Proxy Server | 仓库非 enterprise 目录内容标为 MIT；enterprise 目录需单独核对 | 官方文档列出多部署负载均衡、cooldown、fallback、timeout 和重试，并可使用 Redis 协调状态 | 可用 Docker 启动；接入数据库后再配置虚拟 Key、预算和持久化治理 |
| Bifrost | 高性能统一 AI Gateway，也覆盖 MCP 和 Agent Gateway 场景 | 仓库显示 Apache-2.0；企业能力仍需按项目文档逐项核对 | 官方文档列出多供应商统一 API、failover、load balancing、semantic caching 和监控能力 | 支持 NPX 和 Docker；官方快速开始示例使用本地 8080 端口 |
| Apache APISIX | 传统 API Gateway 加 AI 插件体系 | Apache 2.0 | 官方 AI Gateway 页面列出多供应商代理、负载均衡、Token 限流、重试、fallback、Prompt Guard 和缓存插件 | 适合已经使用 APISIX、NGINX、etcd 或统一网关运维体系的团队 |
| Higress | 基于 Istio 与 Envoy 的云原生 AI Gateway | Apache-2.0 | 官方仓库列出统一 LLM 协议、多模型负载均衡、Token 限流、缓存、AI 可观测性和 MCP 管理 | 支持 Docker 快速启动，也提供 Kubernetes 与 Helm 部署方式 |
| Portkey Gateway | 轻量级开源 AI Gateway，带路由、重试、fallback 和 Guardrails 能力 | 仓库显示 MIT；企业、托管和高级治理能力要区分查看 | 官方仓库列出重试、fallback、负载均衡、超时、Guardrails 和多模态接入 | 可通过 NPX 启动，默认示例地址为本地 8787 端口 |
上表没有给出“谁最快”的结论。不同网关的性能会受到模型供应商、请求体、流式响应、并发、网络距离、日志级别和缓存命中率影响；没有统一实验环境时，不应把项目自述的吞吐或延迟数字当作横向排名。
New API、Envoy AI Gateway 等项目的当前功能矩阵、许可证边界和部署方式，应在实际选型时直接核对对应仓库的 README、LICENSE、发行说明和部署文档。本文不对未完成同等资料核验的项目给出性能或商业使用结论。
开源 AI Gateway 的核心能力，应该逐项核对什么
1. 协议兼容
先确认你的客户端到底使用哪种接口：OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、Gemini 接口，还是某个 OpenAI-compatible Provider。所谓“兼容 OpenAI”通常只代表部分路径、字段或响应格式兼容，不等于工具调用、视觉输入、流式输出、JSON Schema、批处理和 Responses API 都能直接使用。
建议先用一个简单模型完成最小请求，再单独验证流式响应、工具调用、错误格式和模型列表接口。模型名不要硬编码成某个未经核实的型号，优先从网关的模型列表或项目配置中确认可用 ID。
2. 路由、fallback 与重试
把“重试”和“故障转移”分开看：重试是在同一目标或同一模型组再次发送请求，fallback 是切换到备用部署、供应商或模型。需要确认触发条件、最大次数、超时、退避方式，以及流式响应已经开始后是否还能切换。
不可重试的错误通常包括认证失败、请求字段错误、模型不存在和权限不足；限流、部分网络错误或上游暂时不可用才可能适合有限重试。生产环境要设置最大尝试次数、指数退避和熔断，避免网关故障时放大上游压力。
3. Key、租户和日志安全
不要把上游 API Key 直接放进前端、代码仓库或聊天记录。网关至少应支持环境变量或密钥管理系统、入站虚拟 Key、权限分组、配额和审计日志。日志默认只保留请求元数据更稳妥；Prompt、响应和工具参数可能包含敏感数据，应提供脱敏、关闭正文记录或按租户隔离的配置。
4. 可观测性与成本
至少记录请求时间、响应状态、模型标识、上游供应商、首 Token 时间、总耗时、输入输出 Token 和重试次数。成本统计必须核对价格表版本、Token 计算方式和缓存命中情况，不能只看请求数量。LiteLLM 官方配置文档明确提供日志、回调、请求超时、成本和 fallback 等配置项；其他项目也应逐项查看其文档，不要从宣传页面推断全部能力。
从零开始的最小部署与验证步骤
- 先确定接口目标：列出客户端、目标路径、是否需要流式响应、工具调用、视觉输入和模型切换。
- 选一个最小项目：个人测试可从 LiteLLM、Bifrost 或 Portkey Gateway 开始；已有 API 网关体系再考虑 APISIX；Kubernetes 团队再评估 Higress 或 Envoy AI Gateway。
- 固定版本：不要直接依赖不受控的 latest 标签，记录镜像、包版本、配置文件和数据库迁移方式。
- 只通过环境变量注入 Key：本地 shell 可用
read -s，生产环境使用密钥管理系统；验证时只检查变量是否存在，不要打印 Key 内容。 - 完成最小请求：先使用一个已确认存在的模型 ID，测试非流式请求；成功后再测试流式、工具调用和错误响应。
- 验证路由：配置两个上游或两个模型部署，分别模拟超时、限流和认证失败，确认只有适合重试的错误会触发重试。
- 验证配额与日志：检查虚拟 Key、请求计数、Token 统计、错误分类和日志脱敏是否生效。
- 再进入生产：补齐 TLS、访问控制、数据库备份、Redis 或其他共享状态、健康检查、监控告警和回滚方案。
| 验证项 | 通过标准 | 未通过时先查什么 |
|---|---|---|
| 400 | 错误信息能指出字段或请求体问题 | 请求路径、JSON 字段、Content-Type 和模型参数 |
| 401/403 | Key 存在但不会出现在日志正文 | 入站 Key、上游 Key、权限范围和环境变量 |
| 404 | 模型或路径不存在时能快速定位 | Base URL、API 前缀、模型 ID 和版本 |
| 429 | 有明确限流信息，不发生无限重试 | 重试次数、退避、并发、RPM/TPM 配额 |
| unsupported_parameter | 不支持的字段被识别并记录 | 客户端版本、供应商能力和字段转换规则 |
| 超时或流式中断 | 超时可控，连接断开后不会重复扣费或无限重放 | 上游超时、代理缓冲、SSE 配置和客户端重试 |
许可证与商业使用：开源不等于所有功能免费
许可证要看仓库中的 LICENSE，而不是只看项目首页。MIT 和 Apache 2.0 通常允许在满足通知、版权和专利条款等条件下使用、修改和分发，但具体义务仍应由法务结合项目文件确认。若仓库把 enterprise、hosted、cloud、commercial 或插件目录单独授权，就不能把整个产品的宣传功能都当成开源核心能力。
实际部署前建议做四项核对：一是主仓库和依赖仓库的许可证；二是镜像中是否包含额外闭源组件；三是企业版功能是否改变数据流向；四是上游模型供应商是否允许你的转发、缓存、日志和多租户场景。对于 Key 转发、Prompt 记录、缓存和模型输出保存，还应单独核对相关服务条款。
给个人、小团队和企业的最终建议
个人开发者：优先选择配置文件清晰、能快速 Docker 启动、支持 OpenAI 兼容接口的方案，先验证请求链路，不要一开始就引入完整 Kubernetes 架构。
小团队：重点看多上游路由、fallback、虚拟 Key、预算、日志脱敏和数据库依赖。LiteLLM、Bifrost、Portkey Gateway 都值得从最小部署开始比较，但需要逐项区分社区功能、企业功能和托管功能。
企业 API 平台团队：如果已有认证、限流、观测和配置中心，Apache APISIX 的统一治理思路更自然；如果基础设施以 Kubernetes、Istio、Envoy 或 Gateway API 为中心，则应评估 Higress 和 Envoy AI Gateway 的控制面、数据面和升级流程。
最终不要只看项目数量或 GitHub Star：把你的真实请求样本、模型协议、并发曲线、故障场景、日志要求和许可证要求写成验收清单，再用同一套脚本比较。这样得到的结果比任何未经复现的“最佳排名”更可靠。
常见问题
AI Gateway 开源项目哪个最适合新手？
如果目标只是把多个模型统一到一个 Base URL，LiteLLM、Bifrost 或 Portkey Gateway 更适合作为起点。先完成单机或 Docker 最小部署，再验证流式、工具调用、重试和日志脱敏，不建议一开始就部署复杂的 Kubernetes 网关。
开源 AI Gateway 能直接兼容 OpenAI API 吗？
部分项目提供 OpenAI 兼容接口，但兼容范围需要按路径、字段和响应格式逐项验证。Chat Completions 能调用，不代表 Responses、工具调用、视觉输入、流式响应和错误格式都完全一致。
LiteLLM、Bifrost 和 APISIX 应该怎么选？
LiteLLM 更偏多供应商代理和模型路由；Bifrost 更强调统一 AI Gateway、故障转移和多种 AI 生态接入；APISIX 更适合已经使用 API Gateway、认证、限流和观测体系的团队。
开源许可证允许直接商用吗？
不能只根据“开源”二字判断。应检查主仓库 LICENSE、enterprise 或 hosted 目录、容器镜像依赖和插件授权，并确认上游模型服务条款是否允许你的转发、缓存、日志和多租户场景。
为什么不直接按性能排名选择 AI Gateway？
因为网关延迟和吞吐会受到模型供应商、网络距离、请求体大小、并发、流式响应、日志和缓存影响。没有统一硬件、版本、模型、请求样本和测试脚本时，跨项目性能排名不可直接复用。
相关阅读
- 继续看 AI Gateway 对比：LiteLLM、New API、APISIX 与云托管方案
- 先了解 AI Gateway 与普通 API Gateway 的区别
- 浏览更多 AI API 接入与排错指南
参考资料
- LiteLLM 官方文档：Router 与负载均衡（docs.litellm.ai）
- LiteLLM 官方仓库：许可证
- LiteLLM 官方文档：Docker 快速开始
- Bifrost 官方 GitHub 仓库
- Bifrost 官方文档：功能概览
- Bifrost 官方文档：网关部署
- Apache APISIX 官方页面：AI Gateway（apisix.apache.org）
- Apache APISIX 官方页面：插件中心（apisix.apache.org）
- Higress 官方 GitHub 仓库
- Portkey Gateway 官方 GitHub 仓库
- Envoy AI Gateway 官方 GitHub 仓库