8.0
热点
AI SCORE
工具产品2026-09-24 02:37
五大LLM网关工具生产环境横评
dev.to · AI#LLM网关#生产级AI#工具评测
Editor brief · 编辑速览
对比LiteLLM、Kong AI Gateway、Portkey、Bifrost、Apache APISIX在流量管理、延迟、容错和运维控制上的差异，提供选型依据。
当一个 LLM 应用开始处理真实用户时，调用模型 API 通常并不难。问题往往出在周边。一个提供商触发了速率限制，另一个变慢了，某端点宕机了，重试导致成本上升，或者应用需要切换模型但又不想重写半个代码库。
这就是 LLM 网关的用武之地。它位于应用和模型提供商之间，提供了一个集中管理路由、可靠性、可观测性和访问控制的中心点。我对比了五个广泛使用的方案——LiteLLM、Kong AI Gateway、Portkey、Bifrost 和 Apache APISIX——来观察当流量管理、延迟、提供商故障和运营控制等生产级需求开始发挥作用时，它们的处理方式有何不同。
LLM 网关是位于应用和一个或多个大语言模型提供商之间的软件层。
可以把它想象成 AI 请求的交通控制器。
没有网关的情况下，应用可能需要为 OpenAI、Anthropic、Google、Azure、Amazon Bedrock 或自托管模型等提供商分别做集成。每个提供商可能有不同的 API、认证方式、速率限制、错误响应、模型名称和使用策略。
这种复杂性会迅速蔓延到整个应用中。
LLM 网关提供了一个集中层，使大量提供商相关的逻辑可以驻留其中。
一个典型的请求流程如下：
应用 → LLM 网关 → 模型提供商 → LLM 网关 → 应用
根据平台的不同，网关可以处理：
确切的特性集因网关而异。
重要的是，LLM 网关不是一个 AI 模型。它不能替代 GPT、Claude、Gemini 或其他模型。相反，它管理的是围绕这些模型的基础设施。
对于使用单一提供商的简单应用，网关可能并非必需。对于使用多个提供商或处理大量流量的应用，集中控制会变得更有价值。
直接集成模型 API 在开发阶段可以完美运行。
当流量变得不可预测时，情况就变了。
想象一个应用在高峰期收到数千个请求。主要模型提供商开始返回 429 速率限制响应。没有网关的情况下，应用必须决定是重试、等待、切换提供商还是返回错误。
有了 LLM 网关，可以在集中层处理这些策略。模型变更同样适用。
如果提供商相关的逻辑分散在多个应用和服务中，切换提供商可能需要大量开发工作。网关可以提供一致的接口，同时将路由规则和提供商配置分开管理。
可观测性是另一个需要考虑的因素。
当请求通过集中式网关时，工程团队可以更清晰地了解延迟、故障、token 使用量、提供商行为和流量模式。
这些信息在 LLM 应用超越实验阶段后尤其有用。
网关还可以帮助将应用逻辑与基础设施决策分离。开发者可以专注于应用，而平台团队管理路由、限制、认证和提供商策略。
这并不意味着每个生产应用都需要网关。如果应用规模较小、使用单一模型提供商且流量有限，添加另一层基础设施可能会带来不必要的复杂性。
当提供商多样性、流量规模、可靠性要求或治理变得难以直接在应用中管理时，网关的价值就会增加。
我不会纯粹根据宣传的每秒请求数来比较这些工具。
网关在受控基准测试中可能表现极佳，但在真实应用负载下表现可能截然不同。
生产流量引入了简单基准测试经常忽略的变量。请求可能有不同的提示词大小，响应可以是流式的，流量可能突发性到达，上游提供商在负载下可能有不同的行为。
在这次对比中，我重点关注五个方面。
一个有用的网关应该减少开发者需要维护的提供商相关代码。
当应用使用多个部署或提供商时，这很重要。
重试和降级可以提高韧性，但也会增加延迟和成本。
有用的可观测性包括延迟、错误、token、成本、提供商行为和请求追踪。
如果网关引入了工程团队不想维护的运营模式，那么技术能力再强的网关可能仍然不适合。
这些标准揭示了单一延迟测试无法揭示的差异。
主流开源 LLM 网关对比
这五个网关对同一底层问题采取了不同的方法。
LiteLLM 重点关注多提供商抽象和集中式 LLM 管理。Kong AI Gateway 将传统 API 网关能力扩展到 AI 工作负载。Portkey 强调路由、可靠性和可观测性。Bifrost 采用性能优先的网关基础设施方法。Apache APISIX 将 AI 能力引入更广泛的云原生 API 网关生态。
这使得对比作为架构评估比作为简单的功能清单更有价值。
LiteLLM 的构建围绕一个简单的理念：应用应该能够通过一致的接口与不同的 LLM 提供商交互。
其代理服务器（Proxy Server）提供了集中式网关，而 Python SDK 也可以直接在应用中使用。LiteLLM 支持大范围的 LLM 提供商，并提供 OpenAI 兼容的接口。
该平台还提供重试、降级、成本追踪、认证、速率限制、日志记录和监控。
核心优势 最大的优势是提供商抽象。
开发者无需为每个模型提供商实现单独的应用逻辑，而是可以使用通用接口，并将大量提供商相关配置迁移到网关层。
当团队正在试验多个模型或希望避免将应用代码过度绑定到某一提供商时，这变得非常有用。
LiteLLM 还为重试和降级提供路由能力。当某个部署变得不可用或开始返回错误时，路由规则可以帮助决定下一步发生什么。
集中式控制是架构的另一个有用部分。
运行多个应用的团队可以从一个集中层管理认证、预算、速率限制、日志记录和模型访问，而无需在每个服务中重新创建这些控制。
最适合 最适合需要广泛模型提供商支持、统一 API 接口以及 LLM 流量集中管理的团队。
主要的生产考虑是在实际工作负载下的性能。如果延迟至关重要，应该对完整应用路径进行基准测试，而不是依赖通用网关基准测试。
Kong 从更广泛的 API 网关角度处理 LLM 流量。
这使其与已经通过认证、路由、安全、流量控制和可观测性等概念管理 API 的组织相关。
Kong AI Gateway 支持多个模型提供商，并将 AI 流量管理集成到更广泛的网关架构中。
核心优势 Kong 的主要优势是基础设施级流量管理。
其 AI 网关支持路由、负载均衡、流式传输、认证、访问控制、速率限制、提供商故障转移和可观测性。
这种组合在 LLM API 不再是孤立的应用程序依赖，而是成为更广泛平台的一部分时变得有用。
例如，一个组织可能已经有 API 网关策略来处理认证、安全和流量管理。将 LLM 请求纳入相同的运营模式可以减少工程师需要管理的独立基础设施系统数量。
Kong 还提供针对请求、token、成本和延迟的 AI 特定可观测性。
这让你可以通过与查看其他 API 相同的基础设施视角来查看 AI 流量。
最适合 最适合已经使用 API 网关基础设施并希望 AI 流量遵循既定安全、路由、治理和可观测性模式的组织。
权衡是运营复杂性。更广泛的基础设施平台可能需要比轻量级模型代理更多的网关知识。
Portkey 专注于当 AI 应用使用多个提供商时变得更加突出的运维问题。
其网关提供统一 API，支持负载均衡、条件路由、重试和降级等路由策略。
核心优势 Portkey 的方法以可靠性和请求级可观测性为中心。
假设主提供商返回错误。配置好的降级策略可以将请求路由到另一个提供商。
这可以帮助应用从某些上游故障中恢复，而无需让每个应用服务都实现自己的提供商切换逻辑。
Portkey 还提供对请求和降级尝试的可视化，这可以简化生产环境故障排查。
其负载均衡能力可以在配置的提供商或部署之间分配流量。
使用降级时需要记住一个重要点：降级并非自动免费。
如果第一个请求失败，另一个提供商处理了请求，应用可能会承受额外的延迟和模型用量。
降级策略必须在可用性、成本和响应时间之间取得平衡。
Portkey 还提供日志、链路追踪、元数据和指标，用于理解单个模型请求。
最佳场景 适合将路由、提供商可靠性、降级和对 LLM 请求的详细可观测性作为优先事项的团队。
希望自托管、开源网关的团队也应将 Portkey 的部署和许可模式与其需求进行对比评估。
Bifrost 采用以性能为核心的 LLM 网关基础设施方法。
该项目使用 Go 编写，在多个提供商之间提供 OpenAI 兼容接口。其记录的集成包括 OpenAI、Anthropic、AWS Bedrock、Google Vertex、Azure、Mistral 和 Ollama。
核心优势 低网关开销和高吞吐量基础设施是 Bifrost 定位的核心。
Bifrost 发布了性能基准测试，在特定测试条件下显示出非常低的网关开销。这些结果可以帮助你了解其性能目标，但你不应将其视为通用的生产保证。
实际延迟取决于许多因素，包括硬件、并发数、负载大小、网络条件、流式行为和上游模型提供商。
Bifrost 还提供自动故障转移、负载均衡、语义缓存、请求日志、分析和治理。
对于处理大量请求量的团队，最小化基础设施开销可能是评估中的一个重要部分。
最佳场景 适合高度重视网关性能、高请求量和基于 Go 的基础设施的团队。
部署前，应测试应用实际使用的提供商和请求模式。当工作负载大量依赖流式传输或提供商特定 API 功能时，这一点尤为重要。
Apache APISIX 来自传统的云原生 API 网关生态系统。
这使其在 LLM 网关领域处于不同的位置。团队无需为 AI 构建完全独立的基础设施层，而是可以扩展现有 API 网关架构来处理模型流量。
APISIX 的 AI 网关能力包括模型路由、负载均衡、重试、降级、令牌限流、安全、日志和可观测性。
核心优势 最大优势在于更广泛的 API 网关生态系统中的灵活性。
APISIX 支持加权模型路由、健康检查、基于令牌的限流、重试、降级提供商和 AI 特定的可观测性。这可以帮助已经运行 APISIX 处理传统 API 的组织。
团队无需为常规应用流量维护一个网关，再为 AI 请求维护另一个专用网关，而是可能通过通用基础设施层来管理两者。
插件架构还为基础设施团队提供了对流量处理方式的相当大的控制权。
最佳场景 适合希望通过通用开源网关架构管理传统 API 流量和 LLM 流量的云原生团队。
权衡之处在于复杂性。使 APISIX 变得有用的灵活性也意味着更多的配置和运维责任。
比较 LLM 网关的最大教训是，生产流量改变了评估方式。
开发环境可能每隔几秒发送一个请求。
生产环境可以产生突发并发请求、长时间流式响应、重试、提供商限流和突然的流量变化。
这正是网关行为变得更加重要的地方。
例如，提供商可能在流量高峰期间返回 429。
重试可以恢复请求，但也可能增加延迟并消耗额外资源。
降级可以提高可用性，但将请求发送到另一个提供商可能会增加模型用量和成本。
负载均衡引入了另一个考量因素。
在提供商之间分配流量可以减少对单个部署的依赖，但提供商可能有不同的响应时间、价格、上下文限制和模型行为。
这意味着路由不仅仅是基础设施决策。它可能影响应用的用户体验和运营成本。
缓存也是如此。
缓存在工作负载具有可预测或重复提示时可能减少重复的模型请求，但对于响应高度依赖上下文或时效性的应用，你需要仔细评估。
因此，生产测试应复现对实际应用重要的条件，而不是依赖一种人工流量模式。
对于严肃的 LLM 网关比较，我建议测量不仅仅是原始吞吐量。
平均延迟 显示典型请求体验，并为正常流量提供有用的基准。
尾部延迟 在生产环境中通常更重要，因为它展示了真实工作负载下较慢请求的样子。
在正常和峰值流量下跟踪错误。在可行的情况下，将网关错误与上游提供商错误区分开来。
429 和超时频率
限流和超时是 LLM 应用可靠性问题的常见原因。
吞吐量有助于建立网关在特定配置下可以处理的流量。
网关 CPU 和内存
网关不应该仅仅为了代理模型请求而消耗不相称的基础设施资源。
令牌用量影响性能和成本，尤其是在涉及重试和降级时。
提供商降级频率
高降级率可能表示提供商可靠性问题、路由问题或过于激进的降级策略。
测量重试次数，因为它们可以提高成功请求率，同时也会增加延迟和用量。
每次成功请求的成本
这是最有用的生产指标之一，因为技术上的成功请求不一定是经济上高效的。
流式性能
流式应用应测量首 token 时间、持续响应行为、中断和完成时间，而不是将整个请求视为一个延迟数字。
最重要的是，测试故障场景。
在每个提供商都健康时表现良好的网关只能告诉你故事的一部分。
更有说服力的测试是：当主提供商变慢、返回错误、达到限流或暂时不可用时会发生什么。
这五个网关解决了重叠的问题，但它们的优先级不同。
LiteLLM 以提供商抽象和集中式 LLM 管理为中心。
Kong AI Gateway 将 LLM 流量与更广泛的 API 网关、安全和治理基础设施连接起来。
Portkey 强调路由、可靠性、降级和请求级可观测性。
Bifrost 强调性能和低网关开销。
Apache APISIX 提供可扩展的云原生网关方法，可以覆盖传统 API 和 AI 流量。
因此，有用的问题不仅仅是"哪个网关功能最多？"
更好的问题是：
哪个网关与应用的基础设施、提供商组合、可靠性要求和运维模式相匹配？
使用单一模型提供商的小型应用可能不需要所有这些能力。
具有重要流量的大型多提供商 AI 平台可能需要更多的控制。
当应用有多个模型提供商、有意义的流量，或在应用代码中越来越难以管理的可靠性和可观测性要求时，LLM 网关变得越来越有用。
这五个网关对同一底层问题采取了不同的方法。
LiteLLM 专注于多 Provider 抽象和集中式 LLM 管理。Kong AI Gateway 将 AI 流量纳入更广泛的 API 网关模型。Portkey 强调路由、可靠性、降级和请求可见性。Bifrost 强烈关注网关性能和吞吐量。Apache APISIX 将 AI 网关能力与更广泛的云原生 API 基础设施相结合。
在生产环境测试方面没有有用的捷径。
使用具有代表性的流量进行测试。测量 p95 和 p99 延迟。触发 Provider 故障。测试速率限制。监控重试和降级。追踪 Token 消耗。测量网关资源使用情况。然后计算每种可靠性机制的实际成本。
这样得到的认知远比功能列表或单一基准测试清晰得多。
LLM 网关最终应该让模型基础设施更易于控制、观察和变更，而不会将这种复杂性推入每个应用服务。
常见问题 (FAQs)
LLM 网关是应用程序与一个或多个大型语言模型 Provider 之间的软件层。它可以管理模型路由、认证、速率限制、重试、降级、日志记录、监控、Token 使用情况以及其他运维任务。
LLM 网关可以集中化 Provider 集成和流量管理逻辑。它可以更轻松地切换 Provider、处理某些上游故障、控制使用量、监控请求以及管理多个模型，而无需在应用程序间重复基础设施逻辑。
传统 API 网关管理通用应用程序 API 流量。LLM 网关增加了围绕模型流量的能力，例如 Provider 路由、基于 Token 的限制、模型降级、Token 追踪和 LLM 特定的可见性。一些平台（包括 Kong 和 Apache APISIX）在传统 API 网关架构基础上扩展了 AI 特定能力。
LiteLLM、Kong AI Gateway、Portkey、Bifrost 和 Apache APISIX 都可以管理涉及多个 LLM Provider 的流量，尽管 Provider 覆盖范围、集成方式、部署模型和能力有所不同。团队在部署前应验证对其应用程序所需的具体模型和 API 的支持情况。
使用与真实应用程序相似的流量测试网关，包括正常请求、峰值并发、流式响应、速率限制、超时和 Provider 故障。测量 p50、p95 和 p99 延迟；错误率；吞吐量；资源使用情况；重试；降级；Token 消耗；以及每个成功请求的成本。