AI API 中转站全景对比：主流 AI Gateway 产品架构与能力比较

1. 引言：为什么现在需要 AI Gateway

大模型生态已经从“单模型调用”进入“多模型、多供应商、多 Agent”阶段。开发者开始同时接入 OpenAI、Anthropic、Google、DeepSeek、Mistral、自建模型等，随之出现几个问题：

• API 格式不统一
• 模型价格差异越来越大
• 同一模型可能有多个 Provider
• 单一模型可能出现限流或故障
• 企业需要统一管理 API Key、预算和权限
• 不同任务其实适合不同模型
• Agent / MCP 场景对路由和治理要求更高

AI Gateway 的作用，已经从简单“API 中转”逐渐演化为模型接入、流量治理、成本控制和智能路由基础设施。市面上的 AI Gateway 到底有哪些不同路线？哪些产品适合个人开发者，哪些适合企业，哪些代表下一阶段的智能模型路由？

2. AI Gateway 到底是什么

graph TD
    A[应用 / Agent] --> B[AI Gateway / Model Router]
    B --> C[OpenAI / Claude / Gemini / DeepSeek / 自建模型]

我们先来搞清楚几个概念：

• AI API 中转站 是指作为 AI API 的统一接入和管理入口，负责处理不同模型的调用请求，进行流量控制、成本管理和智能路由。
• LLM Gateway 是指专门针对大语言模型（LLM）的接入和管理网关，通常提供模型调用、流量控制和成本管理等功能。
• AI Gateway 是指面向更广泛 AI 模型的接入和管理网关，除了 LLM，还可能支持图像、语音等多模态模型。
• Model Router 是指负责根据策略将请求路由到不同模型的组件，通常用于实现智能路由和负载均衡。
• Model Aggregator 是指将多个模型的能力进行聚合，提供统一接口的组件，方便上层应用调用。

“AI API 中转站”是中文开发者语境里的通俗说法；“AI Gateway”更专业；如果核心能力是根据任务自动选择模型，则更接近 Model Router。Model Aggregator 则侧重于能力聚合，为上层应用提供统一接口。

3. 目前 AI Gateway 市场的几条主要路线

① 模型聚合 / Marketplace 型

代表：OpenRouter 重点解决： “我不想分别注册几十家模型供应商。”

② 开源自托管 Gateway

代表：LiteLLM、Bifrost 重点解决： “模型调用必须掌握在自己手里。”

③ 企业治理型

代表：Portkey 重点解决： 权限、预算、Guardrails、审计、日志。

④ Edge / 网络基础设施型

代表：Cloudflare AI Gateway 重点解决： 全球网络、缓存、延迟、流量控制。

⑤ Developer Experience 型

代表：Vercel AI Gateway 重点解决： 让 Web / Next.js / TypeScript 开发者快速接模型。

⑥ API Management 演进型

代表：Kong AI Gateway 重点解决： 把传统 API Gateway 的能力延伸到 LLM。

⑦ Observability / Intelligent Routing 型

代表： Helicone → Observability-first OrcaRouter → Model-routing-first

4. 9 款产品对比

5. 核心能力横向对比

虽然 OpenRouter、LiteLLM、Portkey、Cloudflare AI Gateway、Vercel AI Gateway、Kong AI Gateway、Helicone、OrcaRouter 和 Bifrost 都可以被归入 AI Gateway 或 Model Router 范畴，但它们在能力侧重点上并不一致。部分产品主要解决多模型统一接入问题，部分产品更强调高可用和企业治理，而 OrcaRouter、Kong、Bifrost 等产品则开始进一步将模型选择本身纳入网关层。

因此，在比较这些产品时，不能只看“支持多少模型”，还需要观察统一 API、Provider 管理、负载均衡、故障转移以及模型级智能路由等能力。

5.1 多模型统一接入

AI Gateway 最基础的价值，是在应用和不同模型提供商之间增加一层统一接口。

如果直接调用模型 API，一个同时使用 OpenAI、Anthropic、Google 和 AWS Bedrock 的应用，往往需要分别维护 SDK、认证方式、请求参数以及错误处理逻辑。AI Gateway 则将这些差异隐藏在统一入口之后，使应用层尽量保持稳定。

在这一能力上，OpenRouter、LiteLLM、Portkey、Vercel AI Gateway、Helicone 和 Bifrost 都已经形成较完整的统一接入体系。

其中，OpenRouter 更接近“模型聚合市场”。开发者通过一个账户和统一 API 即可调用大量模型，而无需分别处理不同模型公司的账户与计费关系。它的优势主要体现在模型覆盖范围和使用门槛，而不是企业内部基础设施控制。

LiteLLM 的路径则不同。它更强调将不同模型供应商转换为统一的 OpenAI-compatible 接口，同时支持 OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、Vertex AI、Ollama 等大量后端。对于已经拥有各家模型 API Key 的企业而言，LiteLLM 更接近一层自有模型代理基础设施。

Portkey 同样提供统一 API，并能够把 OpenAI、Mistral、自托管模型等不同模型放到同一个 Gateway 配置中。它还支持多模态请求，因此其统一层不仅覆盖文本模型，也开始向图像、音频等模型接口扩展。

Helicone 则是从 LLM Observability 逐步延伸到 Gateway。当前其 Gateway 可以通过 OpenAI 兼容接口访问 100+ 模型，同时保留统一日志和监控能力。

Bifrost 采用类似思路，但明显强调高性能和自托管。官方资料显示，其 Gateway 可以通过统一接口访问包括 OpenAI、Anthropic、Bedrock、Vertex、Azure、Gemini、Ollama、vLLM 等在内的模型和推理环境。

从这一层来看，这些产品其实都在解决同一个问题：

让应用不再直接依赖某一家模型公司的 API。

真正拉开差距的，是后续的 Routing 能力。

5.2 Provider Routing：同一个模型应该由谁提供

市面上的 AI Gateway 几乎都宣称支持 Routing，但不同产品所谓的“Routing”并不是同一层次的能力。为了避免简单用“支持/不支持”进行比较，本文将路由能力进一步划分为 Provider Routing、Rule-based Routing、Semantic/Complexity Routing 和 Auto Model Selection 四个层次。

这四层的逻辑可以这样理解：

flowchart TD
Level1[Level 1: Provider Routing]
Level1 -->|已经知道用什么模型，只决定从哪个 Provider 调用| Level2[Level 2: Rule-based Routing]
Level2 -->|按照人工定义的条件决定模型/Provider| Level3[Level 3: Semantic / Complexity Routing]

Level2 -->|按照人工定义的条件决定模型/Provider| Level3[Level 3: Semantic / Complexity Routing]

Level3 -->|根据 Prompt 语义、复杂度等动态判断任务类型| Level4[Level 4: Auto Model Selection]

Level3 -->|根据 Prompt 语义、复杂度等动态判断任务类型| Level4[Level 4: Auto Model Selection]

Level4 -->|综合任务能力需求、质量、成本、延迟等，自动决定最终模型| End[End]

Level4 -->|综合任务能力需求、质量、成本、延迟等，自动决定最终模型| End[End]

在讨论 AI Gateway 时，一个经常被忽略的概念是 Provider 与 Model 并不是一回事。

例如，同一个模型可能存在多个实际运行渠道：

同一个模型
   ↓
Anthropic 官方 API
AWS Bedrock
Google Vertex AI
第三方推理平台

此时应用要求使用的仍然是同一个模型，但 Gateway 可以决定具体把请求发往哪个 Provider。

这类能力可以称为 Provider Routing。

OpenRouter 在这一方面具有较强优势。由于平台本身连接了大量模型和推理供应商，因此可以在同一模型的多个 Provider 之间进行选择，同时结合价格、可用性等因素进行路由。

Vercel AI Gateway 也已经将 Provider Routing 做成核心能力。对于存在多个供应渠道的模型，Gateway 默认可以结合近期 uptime 和 latency 动态选择 Provider，开发者也可以通过 order 和 only 明确指定 Provider 的优先顺序或白名单。

例如：

flowchart TD
Claude -->|优先 Anthropic| Anthropic
Anthropic -->|失败| AWS_Bedrock[AWS Bedrock]
AWS_Bedrock -->|失败| Vertex_AI[Vertex AI]

这种机制的价值并不只是降低故障率。不同 Provider 之间还可能存在价格、速率限制、区域合规性和延迟差异，因此 Provider Routing 本质上也是成本与基础设施策略的一部分。

Helicone 同样提供 Provider 层面的自动路由。在未指定具体 Provider 时，Gateway 可以在能够提供同一模型的多个 Provider 中尝试调用，也允许开发者手动定义 Provider fallback chain。

Bifrost 的 Provider Routing 则进一步与实时运行指标结合，其 Adaptive Load Balancing 可以基于 provider health、latency、error rate、rate-limit headroom 等信息调整流量分配。

因此，Provider Routing 解决的是：

“已经决定使用哪个模型以后，到底去哪里运行这个模型？”

这和后面要讨论的 Model Routing 是两个不同的问题。

5.3 Load Balancing：如何把流量分给多个后端

当同一个模型或同一种能力存在多个后端时，AI Gateway 还需要解决流量如何分配的问题。

最简单的是 Round Robin，即轮流分配请求；更进一步则可以根据权重、延迟、成本、RPM/TPM 使用量等动态调整。

LiteLLM 的 Router 已经提供了较完整的负载均衡策略，包括 weighted pick、rate-limit-aware、least-busy、latency-based 和 lowest-cost routing，并可以在 Azure、OpenAI、Bedrock 等多个 deployment 之间分配流量。

Portkey 的做法更偏显式策略配置。开发者可以为不同模型或 Provider 设置权重，例如把 75% 请求发往 OpenAI，25% 发往 Azure OpenAI。

Kong AI Gateway 则延续了其传统 API Gateway 的流量治理思路，目前支持包括 round-robin、lowest-latency 等在内的负载均衡方式，并将模型作为 Gateway 中可治理的上游资源。

Helicone 提供 latency、weighted distribution、cost 等不同路由策略；Bifrost 则将实时错误率、延迟和吞吐等运行指标纳入 adaptive load balancing。

因此，从能力成熟度来看，Load Balancing 已经逐渐成为主流 AI Gateway 的标准能力，而不再是明显的产品差异点。

真正的差别开始出现在“Gateway 根据什么信号调整流量”。

5.4 Retry、Fallback 与高可用

LLM API 的一个现实问题是稳定性并不完全可控。模型提供商可能出现 429 rate limit、5xx、网络错误、超时甚至区域性故障。

因此，生产级 Gateway 通常都会提供两层高可用机制：

flowchart TD
Retry[Retry]
Retry -->|同一个目标失败后重试| Fallback[Fallback]
Fallback -->|当前目标不可用后切换到其他目标| End[End]

这两个概念需要区分。

例如 LiteLLM 中，同一个 model group 内的其他 deployment 通常属于 retry 范畴；当整个 model group 不可用时，再切换到另一个 model group，则属于 fallback。

Cloudflare AI Gateway 可以根据请求失败或者预设 timeout 启动 fallback，并顺序切换到下一个模型或 Provider。例如首先调用 Workers AI，如果失败，再切换到 OpenAI。

Portkey 同样允许按照优先顺序设置 fallback chain，还可以指定只有特定 HTTP 状态码，例如 429，才启动 fallback。

Vercel AI Gateway 的设计则非常清晰地区分了 Provider failover 和 Model fallback。

假设请求 Claude Sonnet： 首先可以执行：

flowchart TD
Anthropic -->|失败| Bedrock
Bedrock -->|失败| Vertex

如果所有 Provider 都无法提供 Claude Sonnet，再切换模型：

flowchart TD
Claude_Sonnet --> GPT
GPT --> Gemini

Vercel 官方文档已经支持同时配置这两层 fallback。

Bifrost 的处理也采用分层机制：首先在 Provider 内部进行 retry 和 API Key 轮换，当重试预算耗尽后，再进入下一个 Provider 的 fallback chain。

这一能力对于生产环境非常重要，因为它意味着开发者不需要在每一个业务服务内部重复编写：

flowchart TD
try_OpenAI[try OpenAI]
try_OpenAI -->|失败| retry[retry]
retry -->|失败| Anthropic[Anthropic]
Anthropic -->|失败| Gemini[Gemini]

这些可靠性逻辑可以统一下沉到 Gateway。

5.5 Rule-based Routing：从“故障切换”走向主动调度

Fallback 本质上是被动路由：只有出现失败后才改变目标。

更进一步的 Gateway 开始支持主动路由，即根据预先定义的规则，在请求发送之前就决定目标。

Portkey 的 Conditional Routing 是典型例子。它可以根据请求携带的 metadata 决定模型，例如：

flowchart TD
Paid[付费用户] --> HighPerf[高性能模型]
Free[免费用户] --> LowCost[低成本模型]
EU[欧盟用户] --> EURegion[EU Region 模型]
Test[测试用户] --> Preview[Preview Model]

这一过程发生在 Gateway 层，而不需要业务应用自己维护大量 if / else。

Vercel 在 2026 年也引入了 Gateway-level Routing Rules，可以直接在网关层进行模型 rewrite 或 deny。例如应用仍然请求昂贵模型，但 Gateway 可以将其统一重写到成本较低的模型；或者直接禁止团队使用未经批准的模型。

Bifrost 同样提供基于表达式的 routing rules，可以根据 request header、参数、team、customer、capacity usage 和 budget headroom 等条件决定 Provider、模型以及 fallback chain。

这种路由方式已经开始让 AI Gateway 从简单的“代理服务器”变成真正的 AI traffic control plane。

5.6 Model Routing：真正决定“应该用哪个模型”

如果说 Provider Routing 是：

“Claude 应该从哪里调用？”

那么 Model Routing 解决的则是：

“这条请求本身到底应该用 Claude、GPT、Gemini，还是更便宜的小模型？”

这是当前 AI Gateway 领域最值得关注的一项能力。

传统开发方式通常是在应用代码里固定模型：model = "xxx"

此后所有请求都会进入同一个模型，无论任务只是简单分类，还是复杂代码推理。

这种方式存在明显问题。高性能模型成本高、延迟高，但很多请求并不需要如此强的模型；而统一使用廉价模型，又可能损失复杂任务的质量。

因此出现了一种新的思路：

flowchart TD
Prompt --> 分析任务复杂度_能力需求[分析任务复杂度 / 能力需求]
分析任务复杂度_能力需求 --> 选择最合适模型[选择最合适模型]

OpenRouter 当前已经提供 Auto Router。官方将其描述为 task-aware router：系统首先对请求进行分类，再结合用户选择的 cost-quality tradeoff，将请求分配给适合该任务的模型。

Kong AI Gateway 目前也已经支持多种模型级路由策略，包括 lowest-latency、lowest-usage、semantic 和 priority。其中 semantic routing 可以根据 Prompt 与模型能力描述之间的语义相似度决定目标模型。

OrcaRouter 则把这一能力放在产品定位的中心。

它的开源 OrcaRouter Lite 支持：model="auto"

Gateway 会检查请求是否需要 tools、vision、JSON mode 等能力，然后从已配置 Provider 中选择满足这些能力要求的低成本模型。

这意味着开发者不再一定需要提前指定：

GPT
Claude
Gemini

而是可以只描述：

我要完成一个任务

至于最终由哪个模型执行，则交给 Router。

Bifrost 也已经引入 complexity router，可以按照任务复杂度将请求划分到不同层级，再分发给不同模型。

从趋势上看，这可能是下一阶段 AI Gateway 最重要的竞争方向之一。

5.7 Provider Routing 与 Model Routing 必须区分

在比较这些产品时，最容易出现的误区，就是把所有“routing”能力放在一起讨论。

实际上至少需要区分两个层次。

第一层是 Provider Routing：

flowchart TD
Claude[Claude Sonnet] --> Anthropic[Anthropic / Bedrock / Vertex]

模型已经确定，Gateway 只决定从哪个基础设施提供。

第二层是 Model Routing：

flowchart TD
用户请求 --> GPT[GPT]
用户请求 --> Claude[Claude]
用户请求 --> Gemini[Gemini]
用户请求 --> 小模型[小模型]

模型本身尚未确定，由 Router 根据任务、成本、性能或规则完成选择。

前者的主要目标通常是：

• 高可用
• 降低延迟
• 避免 rate limit
• Provider 成本优化

后者的主要目标则是：

• 模型成本优化
• 质量与价格平衡
• 根据任务匹配模型能力
• 减少业务代码中的模型选择逻辑

从当前产品状态来看，大多数成熟 AI Gateway 已经具备较完善的 Provider Routing、Retry、Fallback 和 Load Balancing；真正能够把“自动选择模型”作为核心能力的产品仍然相对较少。

这也是 OpenRouter Auto Router、OrcaRouter、Kong semantic routing 以及 Bifrost complexity router 值得重点观察的原因。

5.8 核心能力对比

综合来看，九款产品目前可以形成如下大致结构：

需要说明的是，“自动模型选择”并不是一个简单的有或无功能。不同产品背后的路由逻辑差别很大。

有的主要依赖人工配置规则，有的根据 latency 或 cost 动态选择，有的进行 semantic routing，有的则试图直接分析请求复杂度。因此，不能仅因为产品提供了 Router，就认为其具备真正的 task-aware model selection。

从整体演进来看，AI Gateway 的能力正在经历这样一条路径：

flowchart TD
统一_API[统一 API] --> 多_Provider[多 Provider]
多_Provider --> Load_Balancing[Load Balancing / Fallback]
Load_Balancing --> 规则路由[规则路由]
规则路由 --> 动态_Provider_Routing[动态 Provider Routing]
动态_Provider_Routing --> 自动_Model_Routing[自动 Model Routing]

前几项正在逐渐成为生产级 AI Gateway 的基础能力，而最后一步——根据任务本身动态决定模型——仍然是当前产品之间差异最大、也最值得继续观察的领域。

总结：没有“最好”的 AI Gateway

AI Gateway 市场实际上已经分化。 OpenRouter解决模型获取问题。 LiteLLM解决控制权问题。 Portkey解决企业治理问题。 Cloudflare解决网络层问题。 Vercel解决开发体验问题。 Kong解决企业 API 管理问题。 Helicone解决可观测性问题。 OrcaRouter解决模型选择问题。 Bifrost则代表高性能开源 Gateway。

因此，这些 AI Gateway 产品的使用场景可以大致划分如下： 个人开发者适合使用OpenRouter / Vercel AI Gateway。 独立 AI 产品建议：OpenRouter / Cloudflare / Vercel 企业内部统一 AI API 建议：LiteLLM / Portkey / Kong 强调自托管：LiteLLM / Bifrost 强调 Observability：Helicone 强调智能选模：OrcaRouter 强调 Web / Next.js：Vercel AI Gateway

下一阶段 AI Gateway 的竞争重点，很可能从“接多少模型”转向“如何在质量、成本、延迟和可靠性之间自动做出最优模型选择”。