TL;DR

  • 开源 LLM 网关为应用提供了一个连接模型提供商的统一入口。视具体项目而定，它还可以处理路由、重试、预算、访问控制、缓存和请求日志。
  • 这里的五个项目采取了不同的方法：Bifrost、Kong、Agent Router、Apache APISIX 和 LiteLLM。
  • 对于希望拥有一个可自托管、并能控制模型、MCP 和智能体流量的网关的团队来说，Bifrost 是我们的首选。其商业版 Edge 产品还可以路由来自员工设备的 AI 流量。
  • 开源并不意味着所有功能都免费或可自托管。在采用之前，请检查每个项目的许可证和功能边界。

几年前，许多团队采用网关来集中管理提供商密钥和计费。这些需求并未消失，但团队现在还必须考虑模型选择、可靠性、使用限制以及连接到智能体的工具数量不断增加的问题。

本列表中的项目并非可以互换。有些专注于模型路由，而另一些则在更广泛的 API 或服务网格栈之上构建 AI 功能。我比较了五个开源 LLM 网关、它们的部署模式以及无需付费计划即可使用的功能。

开源 LLM 网关的作用

从基本层面来看，开源 LLM 网关是模型请求的反向代理。应用将流量发送到一个共享端点，网关负责处理 OpenAI、Anthropic、AWS Bedrock 和 Google Vertex AI 等服务之间的提供商特定格式、路由和重试。

有些项目增加了预算、访问控制、审计追踪、缓存或 MCP 支持。另一些则专注于以较低的运维开销将请求路由到正确的模型。正确的选择取决于你需要网关完成哪些工作。

如何选择开源 LLM 网关

  • 提供商覆盖范围。确认你的应用当前需要的提供商和 API 格式，然后检查新提供商是如何添加的。
  • 可靠性和延迟。寻找重试、回退和负载均衡功能。将基准测试数字视为起点。
  • 部署和许可证。检查网关本身的许可证，并区分开源组件与付费托管、支持或企业功能。
  • 运维。考虑项目如何处理密钥、预算、访问控制、日志和升级。网关仍然需要有人来运行它。
  • MCP 与智能体支持。如果你的应用会调用工具，请检查网关是否路由或治理 MCP 流量，以及身份和权限如何运作。

五款网关一览

以下是简短版本。Bifrost 和 LiteLLM 是聚焦模型的网关，Kong 将 AI 流量纳入更广泛的 API 平台，Agent Router 围绕 Envoy Gateway 和 Kubernetes 构建，Apache APISIX 则将 AI 插件与通用 API 网关相结合。这五款开源 LLM 网关在部署方式和功能边界上各有不同。

能力 Bifrost Kong AI Gateway Agent Router Apache APISIX LiteLLM
形态 独立的 Go 网关 Kong Gateway 中的 AI 功能 Envoy Gateway 控制平面与 CLI 带 AI 插件的 API 网关 Python SDK 与代理
模型覆盖 25+ 家提供商，10,000+ 个模型 主流托管与自托管 API 托管与自托管提供商 OpenAI、Anthropic、Bedrock 等 100+ 家提供商
路由与可靠性 重试、回退、负载均衡 路由、负载均衡、插件 集中路由、配额与故障转移 多提供商代理、负载均衡与重试 路由、重试、回退
MCP 支持 原生 MCP 网关 AI MCP Proxy 插件 AI 与 MCP 流量 OpenAPI 转 MCP 插件 MCP 网关
部署 自托管；企业版增加私有化选项 自托管或 Konnect Kubernetes 或独立 CLI 自托管 自托管代理
适用场景 你希望用一个网关同时服务模型和智能体 Kong 已经在运行你的 API 你的平台基于 Envoy 构建 你想要一个开源的 API 与 AI 网关 你的技术栈以 Python 为主

以下各节将介绍每个项目的优势、适用场景以及采用前需要检查的事项。

1. Bifrost：面向模型、MCP 和智能体的网关

Bifrost是一个开源的企业级 AI LLM 网关，采用 Apache 2.0 许可，用 Go 编写。它提供统一的 OpenAI 兼容接口，可访问 25+ 家提供商的 10,000+ 个模型。借助其开箱即用的配置，现有应用通常只需更改 base URL 即可切换过来。Bifrost 以单个二进制文件形式发布，可运行在虚拟机、Kubernetes、私有云或隔离网络中。

Bifrost

核心能力

性能是 Bifrost 的主要卖点之一。其已发布的基准测试显示，在单台 t3.xlarge 上、每秒 5,000 次请求时开销约为 11 微秒，成功率为 100%。在另一项 AWS EC2 对比中，500 个并发用户持续 60 秒，Bifrost 处理了每秒 424 次请求，而 LiteLLM 为 44.84。报告的 P99 延迟分别为 1.68 秒和 90.72 秒。

在治理方面，虚拟密钥让团队可以按密钥、团队、客户或模型设置预算和速率限制。企业版可连接 Okta、Microsoft Entra、Keycloak、Zitadel、Auth0 和 Google Workspace 等身份提供商，以及其他 OIDC 提供商。它还增加了 SCIM 2.0 目录同步、细粒度的基于角色的访问控制、数据访问控制和可复用的访问配置文件。路由支持加权负载均衡、带退避的重试以及自动回退。语义缓存由 Redis、Qdrant、Weaviate 或 Pinecone 支持，可为相似提示返回已存储的答案。

该MCP 网关控制智能体可以使用哪些 MCP 服务器和工具。访问可在客户端、请求和虚拟密钥级别进行过滤，并支持按用户 OAuth，让每个人使用自己的账户连接。Code Mode 对大型工具集采取了不同方法：不是将每个工具定义都加载到模型上下文中，而是由模型编写一段简短脚本以协调其所需的工具。Bifrost 报告称，这可将输入 token 使用量最多减少 92.8%。在一项 508 个工具的测试中，报告的成本从 377 美元降至 29 美元，且所有任务均通过。MCP 网关文章中有完整结果。

Bifrost Edge将这些控制扩展到员工设备上运行的 AI 工具。它适用于 macOS、Windows 和 Linux，在一次性 SSO 登录后，将来自桌面聊天应用、基于浏览器的 AI、终端编码智能体及其 MCP 服务器的流量路由到 Bifrost 网关。Edge 仅路由 AI 流量，不检查其他设备活动。网关虚拟密钥、预算和护栏然后可以应用于这些工具，包括对请求和响应的内容安全、PII 和密钥检测，以及与 AWS Bedrock Guardrails、Azure Content Safety、Google Model Armor、CrowdStrike AIDR 和 Check Point Guard 的集成。管理员可以允许或阻止应用以及MCP 服务器进行集中管理。规则在设备上强制执行。部署可以使用现有的设备管理工具，如 Jamf、Intune、Kandji、Omnissa Workspace ONE 或 JumpCloud。

对于受监管环境，Enterprise 层级增加了集群、带断路器的自适应负载均衡、签名的审计日志，以及与 AWS Secrets Manager、GCP Secret Manager 和 HashiCorp Vault 的集成。它还支持 VPC 内、本地和物理隔离部署，提示和响应可以留在你的基础设施内。Bifrost 列出的SOC 2 Type II、ISO 27001、HIPAA 和 GDPR是其合规资质，并表示财富 500 强公司在多个行业的生产环境中使用该产品。

适用场景

在做出承诺之前有几件事需要确认。基于身份治理、集群、自适应负载均衡、护栏和 vault 集成，以及 VPC 内部署都属于付费的 Enterprise 层级，而非开源核心。Edge 还需要 Enterprise 网关，并按端点计价。由于它仍处于早期访问阶段，在更广泛推广之前进行有限的试点是合理的。

最适合：需要从一个网关管理模型、MCP 和智能体流量的团队，尤其是当他们有严格的部署或治理要求时。Bifrost 支持自托管、VPC 隔离、本地和物理隔离环境。

💎 查看 Bifrost 仓库 ☆

2. Kong AI Gateway：成熟 API 平台中的 AI 功能

Kong AI Gateway 为 Kong 成熟的 API 网关添加了 AI 特定功能。如果你的 API 已经运行在 Kong 上，你可以对模型流量使用相同的控制平面、插件模型和运维设置。AI 功能包括提供商路由、基于 token 的速率限制、提示护栏插件、语义缓存和跨模型的语义路由。

Kong

核心能力

Kong 于 2025 年 10 月在 Gateway 3.12 中新增了对 MCP 的支持。其 AI MCP Proxy 插件可以将 REST API 暴露为 MCP 工具，或置于 MCP 服务器之前。访问控制在客户端发现工具和调用工具时都会生效。配套的 OAuth2 插件负责处理 MCP 流量的身份认证。

适用场景

主要的权衡在于许可和运维范围。Kong 的文档将 MCP 插件列为其 AI Gateway Enterprise 产品的一部分，并将 OAuth2 插件标记为技术预览。如果你的技术栈中尚未使用 Kong，仅为模型流量而部署完整的 API 网关平台可能超出你的需求。

最适合：已在使用 Kong、并希望通过现有控制平面管理 AI 流量的组织。

3. Agent Router：面向 Kubernetes 的基于 Envoy 的路由

Agent Router（前身为 Envoy AI Gateway）是一个 Apache 2.0 项目，用于管理对托管模型、自托管推理和 MCP 服务器的访问。它提供兼容 OpenAI 的 API，并围绕 Envoy Gateway 构建。代码仓库已迁移至 theagentrouter，但项目文档称 API 资源、API 组、CLI 名称和镜像路径均保持不变。

Agent Router

核心能力

该项目描述了一种双层模式：一个网关负责共享认证、路由和全局限流，另一个网关则可以管理发往自托管推理的流量。它还提供用于本地使用的独立 CLI，使得在部署 Kubernetes 组件之前就能试用该 API。

适用场景

权衡在于其平台侧重。已经运行 Envoy Gateway 和 Kubernetes 的团队有清晰的评估路径。对于只需要轻量代理的小型应用，更简单的网关可能意味着更少的配置工作。其文档和发布说明是查看特定提供商和功能当前状态的最佳途径。

最适合：使用 Envoy Gateway 或 Kubernetes、希望为模型和工具流量提供开源控制平面的平台团队。

4. Apache APISIX：API 网关中的开源 AI 插件

核心能力

Apache APISIX 是 Apache Software Foundation 的项目，采用 Apache 2.0 许可证。其开源 API 网关包含 AI 插件，用于连接模型提供商、在实例间路由请求、负载均衡流量、重试失败请求以及按 token 限制用量。该ai-proxy插件支持文档中列出的提供商以及 OpenAI 兼容 API，而ai-proxy-multi增加了多实例负载均衡和回退行为。该ai-rate-limiting插件用于施加 token 配额。

Apache APISIX

APISIX 还有一个openapi-to-mcp插件，可将 OpenAPI 文档中的操作暴露为 MCP 工具。这与 Kong 形成了有用的对比：APISIX 的 AI 插件是其开源项目的一部分，而 Kong 将其 MCP Proxy 插件记录为企业版功能。

适用场景

由于 APISIX 是一个完整的 API 网关，团队为 AI 流量采用它时，也要承担其更广泛的网关配置和运维工作。其插件模型适合希望将 API 流量和模型流量统一管理的团队，且 AI 能力在开源项目中即可使用。

最适合：希望获得开源 API 与 AI 网关、支持多提供商路由、token 限制和 MCP 的平台团队。

5. LiteLLM：广泛的提供商支持与 Python 优先的工作流

核心能力

LiteLLM 是团队构建语言模型应用的常见起点。它结合了 MIT 许可的 Python SDK 与自托管代理，支持 100 多个提供商、虚拟密钥、预算、路由、回退、护栏以及 MCP 网关。语义缓存支持 Qdrant、Valkey 和 Redis。其文档建议将该功能用于单轮提示，而非多轮智能体流量。付费企业许可证增加了 SCIM、审计日志以及部分护栏集成。管理 UI 的 SSO 对最多 5 个用户免费。

LiteLLM

权衡

有两点值得进一步审视。在 Bifrost 的已发布基准测试中，在 500 并发用户、持续 60 秒的 AWS EC2 测试里，LiteLLM 处理了 44.84 请求/秒，P99 延迟为 90.72 秒。在同一对比中，Bifrost 处理了 424 请求/秒，P99 延迟为 1.68 秒。这些是厂商发布的结果；性能因工作负载而异。

还有一起供应链事件。恶意的 PyPI 版本 1.82.7 和 1.82.8 于 2026 年 3 月 24 日发布；LiteLLM 表示，一名维护者的 PyPI 账户可能已被入侵，依据是其安全更新。受影响的版本已被移除。该事件涉及的是被入侵的软件包发布，而非 LiteLLM 网关代码中的漏洞，这也凸显了固定依赖版本和在内部镜像软件包的价值。

最适合：流量适中、重视广泛提供商生态、且能够运营并保障自托管服务安全的 Python 团队。

部署与许可对比

此表只是起点，不能替代查阅当前的许可证和功能矩阵。若干项目将部分企业功能保留在开源网关之外。

控制项 Bifrost Kong AI Gateway Agent Router Apache APISIX LiteLLM
许可证 Apache 2.0 核心；企业功能需付费 Apache 2.0 Kong Gateway；部分 AI 插件需付费 Apache 2.0 Apache 2.0 MIT 核心；部分企业功能需付费
运行位置 自托管；Enterprise 中提供私有部署选项 自托管、混合或 Konnect Kubernetes 或独立 CLI 自托管 自托管代理
主要权衡 部分治理和部署功能需要 Enterprise 高级 AI 功能可能需要许可证 最适合 Envoy 和 Kubernetes 技术栈 需要配置和运维的更广泛 API 网关 基于 Python 的运维和安全维护

哪个 AI 网关适合你的团队

如果你要为生产环境选择网关，请从对团队最重要的约束条件开始。Bifrost 提供多提供商路由、智能体工作流和私有部署选项。其公布的基准测试报告11 µs 的开销。

LiteLLM 是以 Python 为中心的团队的天然选择。Kong 适合已经在运行 Kong 的组织，而 Agent Router 适合围绕 Envoy Gateway 和 Kubernetes 构建的团队。Apache APISIX 为开源 API 网关增加了 AI 能力。最佳选择是那个契合你现有平台、且与团队准备承担的网关运维量相匹配的方案。

常见问题

什么是开源 LLM 网关？

一个开源 LLM 网关位于应用与一个或多个模型提供商之间。根据项目的不同，它可以提供共享 API、路由请求、重试失败请求、施加用量限制并记录流量。请查看许可证和功能列表，因为商业托管或企业级管控可能是单独提供的。

LLM 网关与 API 网关有何不同？

传统 API 网关侧重于为通用 API 流量提供路由和身份验证。LLM 网关则增加了针对模型请求的特定功能，例如提供商路由、基于 token 的限制、模型回退和用量报告。一些 API 网关现在也提供 AI 插件，因此区别取决于具体产品。

我们应该自托管还是使用托管网关？

自托管让团队对提示词、密钥和日志拥有更多控制权，但也意味着要自行运维该服务。托管网关可以更快采用，不过流量会经过供应商的网络。正确的选择取决于你的安全要求以及团队可获得的运维支持。

LLM 网关支持 MCP 吗？

MCP 支持情况各不相同。Bifrost 有原生的MCP 网关，Kong 提供 AI MCP Proxy 插件，Agent Router 处理 AI 和 MCP 流量，Apache APISIX 提供一个openapi-to-mcp插件，LiteLLM 在其代理中包含 MCP 支持。请比较身份验证和工具级权限，而不是把支持与否当作非是即否的功能。

LLM 网关会增加多少延迟？

答案取决于网关、工作负载和启用的功能。Bifrost 在其已发布的基准测试中报告，在单台 t3.xlarge 上、每秒 5,000 个请求时，开销约为 11 微秒。与许多模型的响应时间相比这很小，但当智能体进行一长串调用时，增加的延迟可能会有影响。

我们能否在不重写代码的情况下从 LiteLLM 迁移走？

通常可以。两个产品都提供兼容 OpenAI 的 API，Bifrost 为 LiteLLM SDK 提供了可直接替换的适配器。使用 LiteLLM 代理的团队还可以迁移模型、密钥、团队和用户。流程及其细节见LiteLLM 迁移指南。

LLM 网关能否管控使用 ChatGPT 或 Claude 桌面应用的员工？

只有当流量经过该网关时才会如此。标准网关通常只能看到开发者配置为使用它的那些请求。Bifrost Edge旨在将来自桌面应用、浏览器和编码智能体的流量通过 Bifrost 路由，从而让网关策略得以生效。

Bifrost 是开源的吗？Enterprise 版增加了什么？

Bifrost 的核心以 Apache 2.0 协议开源，可免费自托管。Enterprise 版增加了高可用性、基于身份治理、护栏与密钥库集成、签名审计日志，以及 VPC 内或气隙部署。它包含 14 天免费试用。Bifrost Edge 需要 Enterprise 网关，并按端点计费。

结论

没有哪一个网关适合所有技术栈。请根据你使用的提供商、你的部署方式，以及你想要的是专用模型代理还是现有 API 平台内的 AI 功能来做选择。查看每个开源项目包含哪些功能，并在做出决定前用你自己的负载测试这五个网关。如果 Bifrost 在你的候选名单上，它的文档和演示涵盖了其部署方式和 Enterprise 选项。

资源：

感谢阅读本文！❤️

我很想在评论区听到你对此的看法！

Thanks!

💎 来看看 Bifrost 仓库 ☆