实测对比 5 款 LLM 网关：LiteLLM、Kong、Portkey 等

当 LLM 应用开始服务真实用户时，调用模型 API 通常很简单。问题往往出现在它周围。某个提供商触发了速率限制，另一个变慢了，某个端点宕机了，重试推高了成本，或者应用需要切换模型却不想重写半个代码库。

这正是 LLM 网关发挥作用的地方。它位于你的应用与模型提供商之间，为你提供一个集中管理路由、可靠性、可观测性和访问权限的位置。我对比了五个广泛使用的方案：LiteLLM、Kong AI Gateway、Portkey、Bifrost 和 Apache APISIX，看看当流量管理、延迟、提供商故障和运维控制等生产环境问题开始变得重要时，它们的做法有何不同。

什么是 LLM 网关？

LLM 网关是一个软件层，位于应用与一个或多个大语言模型提供商之间。

可以把它想象成 AI 请求的交通指挥员。

没有网关时，应用可能需要为 OpenAI、Anthropic、Google、Azure、Amazon Bedrock 或自托管模型等提供商分别做集成。每个提供商可能有不同的 API、认证方式、速率限制、错误响应、模型名称和使用策略。

这种复杂性会迅速蔓延到整个应用中。

LLM 网关提供了一个集中层，可以把大量这类提供商特有的逻辑放在这里。

一个典型的请求流程如下：

应用 → LLM 网关 → 模型提供商 → LLM 网关 → 应用

根据平台不同，网关可以处理：

• 模型与提供商路由
• 负载均衡
• 速率限制
• 重试
• 提供商故障转移
• 认证
• 日志记录
• Token 追踪
• 成本监控
• 请求监控
• 访问控制
• 缓存
• 使用策略

具体功能集因网关而异。

重要的区别在于，LLM 网关不是 AI 模型。它不替代 GPT、Claude、Gemini 或其他模型。相反，它管理围绕这些模型的基础设施。

对于只使用一个提供商的简单应用，网关可能并非必需。对于使用多个提供商或处理大量流量的应用，集中控制会变得有价值得多。

为什么在生产环境中需要 LLM 网关？

直接集成模型 API 在开发阶段完全可以正常工作。

当流量变得不可预测时，情况就会发生变化。

设想一个应用在高峰期收到数千个请求。主模型提供商开始返回 429 限流响应。如果没有网关，应用必须决定是重试、等待、切换提供商，还是返回错误。

有了 LLM 网关，你可以在一个集中式层中处理这些策略。
同样的思路也适用于模型变更。

如果特定于提供商的逻辑分散在多个应用和服务中，切换提供商可能需要大量的开发工作。网关可以提供一致的接口，同时将路由规则和提供商配置分开管理。

可观测性是另一个考量因素。

当请求经过集中式网关时，工程团队可以更清晰地了解延迟、故障、token 用量、提供商行为和流量模式。

一旦 LLM 应用走出实验阶段，这些信息就会变得特别有用。

网关还可以帮助将应用逻辑与基础设施决策分离。开发者可以专注于应用，而平台团队负责管理路由、限额、认证和提供商策略。

这并不意味着每个生产应用都需要网关。如果应用规模小、只使用一个模型提供商、流量有限，那么增加一个基础设施层可能会带来不必要的复杂性。

当提供商多样性、流量规模、可靠性要求或治理变得难以在应用中直接管理时，网关的价值就会增加。

我如何比较这些 LLM 网关

我不会仅凭宣传的每秒请求数来比较这些工具。

网关在受控基准测试中可能表现极佳，但在真实应用负载下表现可能不同。

生产流量会引入简单基准测试常常忽略的变量。请求的提示词大小可能不同，响应可能是流式的，流量可能突发而至，上游提供商在负载下的行为也可能不同。

在这次比较中，我聚焦于五个方面。

提供商抽象

应用程序与不同模型提供商的协作有多容易？

一个有用的网关应当减少开发者需要维护的提供商特定代码量。

流量管理

请求能否按照定义的规则进行路由、负载均衡、限流或定向？

当应用程序使用多个部署或提供商时，这一点很重要。

可靠性

当提供商超时、返回错误或达到速率限制时会发生什么？

重试和回退可以提高韧性，但也会增加延迟和成本。

可观测性

工程师能否理解请求正在发生什么？

有用的可见性包括延迟、错误、token、成本、提供商行为和请求追踪。

运维控制

网关与现有基础设施的契合程度如何？

一个技术上强大的网关如果引入了工程团队不愿维护的运维模式，仍可能是不合适的选择。

这些标准揭示了单次延迟测试无法体现的差异。

LLM 网关对比一览

领先开源 LLM 网关对比

这五个网关对同一个底层问题采取了不同的方法。

LiteLLM 侧重于多提供商抽象和集中式 LLM 管理。Kong AI Gateway 将传统 API 网关能力扩展到 AI 工作负载。Portkey 强调路由、可靠性和可观测性。Bifrost 对网关基础设施采取性能优先的方法。Apache APISIX 将 AI 能力引入更广泛的云原生 API 网关生态。

这使得该对比作为架构评估比作为简单的功能清单更有用。

LiteLLM

LiteLLM 围绕一个简单的理念构建：应用程序应该能够通过一致的接口与不同的 LLM 提供商交互。

其 Proxy Server 提供集中式网关，而其 Python SDK 也可以直接在应用程序内使用。LiteLLM 支持大量 LLM 提供商，并提供 OpenAI 兼容接口。

该平台还提供重试、回退、支出跟踪、身份验证、速率限制、日志记录和监控。

核心优势
最大的优势是提供商抽象。

开发者无需为每个模型提供商实现单独的应用程序逻辑，而是可以使用通用接口，并将大部分提供商特定的配置移到网关层。

当团队正在试验多个模型，或希望避免应用程序代码与某个提供商绑定过紧时，这一点就很有用。

LiteLLM 还提供用于重试和回退的路由能力。当某个部署变得不可用或开始返回错误时，路由规则可以帮助决定接下来发生什么。

集中式控制是该架构的另一个有用部分。

运行多个应用程序的团队可以从集中层管理身份验证、预算、速率限制、日志记录和模型访问，而不必在每个服务内部重新实现这些控制。

最适合
最适合需要广泛模型提供商支持、通用 API 接口以及集中管理 LLM 流量的团队。

生产环境中的主要考量是实际工作负载下的性能。如果延迟至关重要，请对完整应用程序路径进行基准测试，而不是依赖通用网关基准测试。

Kong AI Gateway

Kong 从更广泛的 API 网关视角来处理 LLM 流量。

这使得它与那些已经通过身份验证、路由、安全、流量控制和可观测性等概念来管理 API 的组织息息相关。

Kong AI Gateway 支持多个模型提供商，并将 AI 流量管理集成到其更广泛的网关架构中。

核心优势
Kong 的主要优势在于基础设施层面的流量管理。

其 AI Gateway 支持路由、负载均衡、流式传输、身份验证、访问控制、速率限制、提供商故障转移和可观测性。

当 LLM API 不再是孤立的应用程序依赖项，而是成为更广泛平台的一部分时，这种组合就变得非常有用。

例如，一个组织可能已经拥有用于身份验证、安全和流量管理的 API 网关策略。将 LLM 请求纳入相同的运维模型，可以减少工程师需要管理的独立基础设施系统数量。

Kong 还提供针对请求、token、成本和延迟的 AI 专属可见性。

这让你能够像查看其他 API 一样，通过相同的基础设施视角来查看 AI 流量。

最适合
最适合那些已经使用 API 网关基础设施，并希望 AI 流量遵循既有安全、路由、治理和可观测性模式的组织。

代价是运维复杂性。更广泛的基础设施平台可能比轻量级模型代理需要更多的网关知识。

Portkey

Portkey 专注于当 AI 应用程序使用多个提供商时变得更加明显的运维问题。

其网关提供统一的 API，并支持负载均衡、条件路由、重试和回退等路由策略。

核心优势
Portkey 的方法以可靠性和请求级别的可见性为中心。

假设主提供商返回错误。配置好的回退可以将请求路由到另一个提供商。

这可以帮助应用程序从某些上游故障中恢复，而无需强制每个应用程序服务都实现自己的提供商切换逻辑。

Portkey 还提供对请求和回退尝试的可见性，这可以使生产环境故障排查更加容易。

其负载均衡能力可以在已配置的提供商或部署之间分配流量。

关于回退需要记住的重要一点是：它们并非自动免费。

如果第一个请求失败并由另一个提供商处理该请求，应用可能会经历额外的延迟和模型用量。

回退策略必须平衡可用性、成本和响应时间。

Portkey 还提供日志、追踪、元数据和指标，用于理解单个模型请求。

最适合
最适合那些优先考虑路由、提供商可靠性、回退以及对 LLM 请求详细可见性的团队。

寻求自托管、开源网关的团队还应结合自身需求评估 Portkey 的部署和许可模式。

Bifrost

Bifrost 对 LLM 网关基础设施采取了以性能为核心的方法。

该项目用 Go 编写，并在多个提供商之上提供 OpenAI 兼容接口。其文档中列出的集成包括 OpenAI、Anthropic、AWS Bedrock、Google Vertex、Azure、Mistral 和 Ollama。

核心优势
低网关开销和高吞吐基础设施是 Bifrost 定位的核心。

Bifrost 发布了性能基准测试，显示在特定测试条件下网关开销极低。这些结果可以帮助你了解其性能目标，但不应将其视为通用的生产环境保证。

真实世界的延迟取决于许多因素，包括硬件、并发、负载大小、网络状况、流式行为以及上游模型提供商。

Bifrost 还提供自动故障转移、负载均衡、语义缓存、请求日志、分析和治理。

对于处理大量请求的团队来说，最小化基础设施开销可能是评估中的重要一环。

最适合
最适合那些高度重视网关性能、高请求量和基于 Go 的基础设施的团队。

在部署前，请测试应用实际使用的确切提供商和请求模式。当工作负载严重依赖流式传输或提供商特定的 API 功能时，这一点尤为重要。

Apache APISIX

Apache APISIX 来自传统的云原生 API 网关生态。

这让它在 LLM 网关领域占据了不同的位置。团队无需为 AI 构建一个完全独立的基础设施层，而是可以扩展现有的 API 网关架构来处理模型流量。

APISIX 的 AI Gateway 能力包括模型路由、负载均衡、重试、回退、token 速率限制、安全、日志和可观测性。

核心优势
最大的优势是在更广泛的 API 网关生态系统中具备灵活性。

APISIX 支持加权模型路由、健康检查、基于 token 的速率限制、重试、回退提供商以及 AI 专属的可观测性。
这可以帮助那些已经在使用 APISIX 处理传统 API 的组织。

团队无需为普通应用流量维护一个网关、再为 AI 请求单独维护另一个网关，而是有可能通过一个共同的基础设施层来管理两者。

插件架构还让基础设施团队在处理流量方式上拥有相当大的控制权。

最适合
最适合那些希望通过统一的开源网关架构来管理传统 API 流量和 LLM 流量的云原生团队。

代价是复杂性。让 APISIX 有用的灵活性也可能意味着更多的配置和运维责任。

真实生产流量揭示了什么

对比 LLM 网关最大的收获是，生产流量会改变评估结果。

开发环境可能每隔几秒才发送一个请求。

生产环境则可能产生并发请求突发、长时间流式响应、重试、提供商速率限制以及流量规模的突然变化。

这正是网关行为变得重要得多的场景。

例如，提供商可能在流量高峰期间返回 429。

重试可以恢复该请求，但也会增加延迟并消耗额外资源。

回退可以提高可用性，但将请求发送到另一个提供商可能会增加模型使用量和成本。

负载均衡引入了另一个考量因素。

在多个提供商之间分配流量可以减少对单一部署的依赖，但不同提供商可能具有不同的响应时间、价格、上下文限制和模型行为。

这意味着路由不仅仅是一个基础设施决策。它会影响应用的用户体验和运营成本。

缓存也是如此。

在提示词可预测或重复的工作负载中，缓存可以减少重复的模型请求，但对于响应高度依赖上下文或新鲜度的应用，你需要仔细评估。

因此，生产测试应该复现对实际应用有意义的条件，而不是依赖某一种人为的流量模式。

你应该测量什么？

对于一次严肃的 LLM 网关对比，我会测量比原始吞吐量更多的东西。

p50 延迟

这展示了典型的请求体验，并为正常流量提供了一个有用的基线。

p95 和 p99 延迟

在生产环境中，尾部延迟往往更重要，因为它展示了真实工作负载下较慢请求的表现。

错误率

在正常流量和峰值流量下都要跟踪错误。如果可能，还要将网关错误与上游提供商错误区分开。

429 和超时频率

速率限制和超时是 LLM 应用中可靠性问题的常见原因。

每秒请求数

吞吐量有助于确定网关在特定配置下能处理多少流量。

网关 CPU 和内存

网关不应仅仅为了代理模型请求而消耗不成比例的基础设施资源。

Token 消耗

Token 使用量既影响性能也影响成本，尤其是在涉及重试和回退时。

提供商回退频率

高回退率可能表明提供商可靠性问题、路由问题，或过于激进的回退策略。

重试频率

测量重试，因为它们可以提高成功请求率，同时也会增加延迟和使用量。

每个成功请求的成本

这是最有用的生产指标之一，因为技术上成功的请求不一定在经济上高效。

流式性能

流式应用应测量首个 token 的时间、持续响应行为、中断和完成时间，而不是把整个请求当作一个延迟数字。

最重要的是，测试故障场景。

一个在所有提供商都健康时表现良好的网关只能告诉你部分情况。

一个更能说明问题的测试是：当主提供商变慢、返回错误、触发速率限制或暂时不可用时会发生什么。

哪种 LLM 网关方案适合你的架构？

这五种网关解决的是相互重叠的问题，但它们的侧重点不同。

• LiteLLM 以提供商抽象和集中式 LLM 管理为核心。
• Kong AI Gateway 将 LLM 流量与更广泛的 API 网关、安全和治理基础设施连接起来。
• Portkey 强调路由、可靠性、回退和请求级可观测性。
• Bifrost 强调性能和低网关开销。
• Apache APISIX 提供了一种可扩展的云原生网关方案，可同时覆盖传统 API 和 AI 流量。

因此，有用的问题不是简单的“哪个网关功能最多？”

更好的问题是：

哪个网关与应用程序的基础设施、提供商组合、可靠性要求和运营模式相匹配？

只有一个模型提供商的小型应用可能不需要所有这些能力。

一个拥有大量流量的多提供商 AI 平台可能需要多得多的控制能力。

结论

当应用程序拥有多个模型提供商、有实际的生产流量，或者可靠性和可观测性需求在应用程序代码中变得越来越难以管理时，LLM 网关就会变得越来越有用。

这五种网关对同一个底层问题采取了不同的方法。

LiteLLM 专注于多提供商抽象和集中式 LLM 管理。Kong AI Gateway 将 AI 流量纳入更广泛的 API 网关模型。Portkey 强调路由、可靠性、回退和请求可见性。Bifrost 非常注重网关性能和吞吐量。Apache APISIX 将 AI 网关能力与更广泛的云原生 API 基础设施相结合。

在生产环境中测试是绕不开的，没有捷径可走。

使用有代表性的流量。测量 p95 和 p99 延迟。触发提供商故障。测试速率限制。监控重试和回退。跟踪 token 消耗。测量网关资源使用情况。然后计算每种可靠性机制的实际成本。

这比一份功能列表或单个基准测试能给你更清晰的图景。

LLM 网关最终应让模型基础设施更易于控制、观测和变更，而不必将这种复杂性推给每一个应用服务。

常见问题解答（FAQ）

1. 什么是 LLM 网关？

LLM 网关是应用程序与一个或多个大语言模型提供商之间的软件层。它可以管理模型路由、身份验证、速率限制、重试、回退、日志记录、监控、token 用量以及其他运维任务。

2. 为什么在生产环境中使用 LLM 网关？

LLM 网关可以集中管理提供商集成和流量管理逻辑。它可以让你更轻松地切换提供商、处理某些上游故障、控制用量、监控请求，并管理多个模型，而无需在各应用程序中重复基础设施逻辑。

3. LLM 网关和 API 网关有什么区别？

传统 API 网关管理通用的应用程序 API 流量。LLM 网关增加了围绕模型流量设计的能力，例如提供商路由、基于 token 的限制、模型回退、token 跟踪以及 LLM 特有的可观测性。一些平台（包括 Kong 和 Apache APISIX）通过 AI 特有的能力扩展了传统 API 网关架构。

4. 哪些 LLM 网关支持多个 AI 提供商？

LiteLLM、Kong AI Gateway、Portkey、Bifrost 和 Apache APISIX 都可以管理涉及多个 LLM 提供商的流量，尽管它们在提供商覆盖范围、集成、部署模式和能力上有所不同。团队在部署前应验证其对应用程序所需的确切模型和 API 的支持情况。

5. 如何针对生产环境测试 LLM 网关？

用接近真实应用的流量测试网关，包括正常请求、峰值并发、流式响应、速率限制、超时和提供商故障。测量 p50、p95 和 p99 延迟；错误率；吞吐量；资源使用；重试；回退；token 消耗；以及每次成功请求的成本。