应用直接调用 OpenAI、Anthropic、Gemini 等模型，原型阶段很快，到了生产环境通常会遇到几个问题：API Key 散落在多个服务里，供应商限流时整条链路失败，模型切换要改业务代码，账单也很难按项目和用户拆分。
AI 网关就是放在应用和模型供应商之间的一层代理：应用只调用一个入口，网关负责模型映射、Key 管理、重试、故障转移、限流、日志和成本统计。
业务服务 / Agent
|
v
AI 网关：鉴权、路由、重试、fallback、限流、观测
|
+--> OpenAI / Anthropic / Gemini / 国内模型
+--> Azure / Bedrock / Vertex AI
+--> vLLM / Ollama / 其他自部署模型本文只比较真正位于调用链路上的网关或代理，不把 LangChain 这类编排框架和 vLLM 这类推理引擎混在一起。资料以 2026 年 8 月各家官方文档为准，价格和免费额度不列入比较。
产品对比
| 产品 | 形态 | 路由与容灾 | 治理与观测 | 更适合 |
|---|---|---|---|---|
| LiteLLM Proxy | 开源、自托管 | 多供应商统一 API、fallback、负载均衡 | 虚拟 Key、预算、限流、成本追踪、日志 | 想自己掌控基础设施的团队 |
| Portkey AI Gateway | 开源网关 + 托管控制面 | fallback、条件路由、负载均衡、重试、熔断、Canary | 缓存、Guardrails、预算、限流、观测 | 路由规则复杂、需要生产治理 |
| Helicone AI Gateway | 托管网关，配套开源观测 | 100+ 供应商路由、按成本选择、自动故障转移、BYOK | 日志、指标、缓存、重试、限流、用户维度分析 | 不想维护网关、希望快速接入多供应商 |
| Cloudflare AI Gateway | Cloudflare 托管、边缘入口 | 重试、模型 fallback、动态路由 | Analytics、日志、缓存、限流、预算控制 | 已经使用 Workers / Cloudflare 的应用 |
| Kong AI Gateway | Kong Gateway 的 AI 插件 | OpenAI 协议转换；高级版支持负载均衡、语义路由、重试 | Token 限流、语义缓存、Prompt Guard、AI Analytics | 已有 Kong、API 管理和企业安全体系 |
| Envoy AI Gateway | 开源、Envoy / Kubernetes 数据面 | 统一 API、多供应商路由、Gateway API 集成 | 依托 Envoy 和 Kubernetes 生态组合策略 | Kubernetes 平台团队、需要标准化数据面 |
| OpenRouter | 托管模型聚合服务 | Provider selection、fallback、区域路由 | 统一账单和供应商隐私信息 | 个人项目、原型、多模型试用 |
这里有一个容易混淆的地方：Kong 和 Envoy AI Gateway 首先是流量基础设施，AI 能力是它们在代理层上的扩展；LiteLLM、Portkey 和 Helicone 更贴近 LLM 调用本身。OpenRouter 更像托管的多供应商 API 聚合器，可以解决接入和故障转移，但不等于企业内部的自托管治理层。
顺带提一嘴：New API 更偏用户、Token、额度、渠道和计费后台，不纳入本文的网关横向比较。
1. LiteLLM：自托管的默认选择
LiteLLM Proxy 的优势是简单直接：部署一个代理，把不同供应商转换成统一的 OpenAI 风格接口。官方文档提供了虚拟 Key、认证钩子、日志、成本追踪和限流等能力，也支持通过配置文件维护不同模型和供应商。
如果团队的主要诉求是“所有服务只依赖一个内部地址”，LiteLLM 通常是第一候选。它能把供应商 Key 从业务服务移到网关，并且让模型切换停留在配置层。
它的代价也很明确：网关本身需要自己部署、升级、监控和做高可用。路由配置越复杂，越要把配置当作生产代码管理；不能因为 API 兼容就假设所有模型都支持相同的工具调用、结构化输出和多模态参数。
2. Portkey：路由策略和治理更完整
Portkey 的核心不是“转发一次请求”，而是把 fallback、条件路由、负载均衡、重试、熔断和 Canary 组合成 Gateway Config。它还提供缓存、预算、限流、Guardrails 与观测能力，适合已经开始认真管理模型流量的团队。
Portkey 也提供开源网关，可以本地启动或自托管，再连接 Portkey 的控制面。它更适合这样的场景：同一个模型要在多个供应商之间切换，且不同租户、区域或业务线有不同路由规则。
需要注意的是，策略越丰富，配置和排障成本也越高。一个请求可能经过重试、负载均衡和 fallback 多个环节，必须保留 trace id，并把每一次实际调用记录清楚，否则出了问题只能看到“最终成功”，看不到真正消耗了几个请求。
3. Helicone：托管优先的多供应商路由
Helicone 的 Gateway 重点是托管路由和可观测性。官方文档显示，它可以根据模型注册表在多个供应商之间选择，默认优先使用用户自己的 BYOK，再按成本和可用性选择供应商，并在限流、超时和服务端错误时故障转移。
它适合不想维护代理集群、但又不想在应用里分别接入十几个供应商的团队。接入方式通常只需要替换 Base URL 或模型写法，同时获得请求日志、成本和用户维度的分析。
缺点是数据路径和供应商选择更多地交给平台。涉及敏感提示词、数据驻留或严格供应商白名单时，要先确认日志保留、BYOK、区域路由和数据处理条款；不能只看“支持多少个模型”。
4. Cloudflare AI Gateway：边缘托管和 Cloudflare 生态
Cloudflare AI Gateway 把 AI 请求放进 Cloudflare 的统一入口，提供日志、Analytics、缓存、限流、重试和模型 fallback。它既有统一的 REST API，也支持 OpenAI 风格的 Chat Completions 入口；如果应用本来就在 Workers、WAF 或 Cloudflare 网络上，接入成本很低。
它特别适合两类请求：一类是希望在边缘统一控制访问和供应商 Key 的应用，另一类是存在大量完全相同请求、可以从缓存直接返回的场景。当前官方缓存文档明确说明，默认是精确匹配整个请求，主要支持文本和图像响应；它不是“理解相似问题”的语义缓存，不能把动态对话随便打开缓存。
它的边界也很清楚：你获得的是 Cloudflare 管理的网络入口，换来的是对平台可用性、区域和计费方式的依赖。对已经采用 Cloudflare 的团队这通常是合理交换；对只想在一台服务器上跑个内部代理的项目，则可能偏重。
5. Kong AI Gateway：已有 API 网关就别再造一套
Kong AI Gateway 是 Kong Gateway 的一组 AI 插件。AI Proxy 可以接收 OpenAI 协议并转换到不同 LLM；AI Proxy Advanced 进一步提供多模型负载均衡、语义路由和重试。配套插件还覆盖 Token 维度限流、语义缓存、Prompt Guard、Prompt Decorator 和 AI Analytics。
如果公司已经用 Kong 管理 REST、GraphQL、认证、审计和流量策略，直接扩展 Kong 往往比新增一套 LLM 专用网关更省运维。AI 请求可以沿用已有的路由、插件和发布流程。
Kong 不适合只想快速试模型的个人项目。它的价值在平台统一治理；如果当前只有一个应用、一个供应商，部署完整 API 网关只会增加运维面。还要区分开源 AI Proxy 与需要授权的高级插件，不能把产品页上的整套能力都当成免费能力。
6. Envoy AI Gateway：Kubernetes 数据面的标准化路线
Envoy AI Gateway 建立在 Envoy Gateway 和 Kubernetes Gateway API 生态上，目标是为 LLM 流量提供统一 API、供应商适配和路由能力。官方文档列出了 OpenAI 兼容接口、Anthropic 兼容接口以及多个供应商集成。
它更像“给平台团队使用的 AI 数据面”，而不是开箱即用的托管控制台。它的优势是能放进现有 Kubernetes、Envoy、Gateway API 和平台策略体系；它的短板是需要团队自己组合认证、密钥、可观测性、配额和高可用方案。
已经标准化使用 Kubernetes 的公司可以优先评估 Envoy AI Gateway；没有 Kubernetes 运维能力的项目，使用 LiteLLM 或托管网关会更快到达可用状态。
7. OpenRouter：适合试用，不一定适合内部治理
OpenRouter 用一个 API 连接多个模型和供应商，并提供 Provider selection、fallback 和统一账单。它解决的是“我想用很多模型，但不想为每个供应商写一套接入代码”。
它非常适合个人实验、Demo 和模型横向评估，也可以作为某条业务链路的备用出口。但如果企业要求自托管、固定数据区域、内部租户预算、私有模型和完整审计，它通常应该放在企业网关之后，而不是直接成为唯一入口。
怎么选
- 个人项目、原型、多模型试用：OpenRouter。
- 自托管、内部统一入口、预算和虚拟 Key：LiteLLM Proxy。
- 需要复杂路由、熔断、Canary 和 Guardrails：Portkey。
- 不想运维，重视托管观测和自动切换：Helicone。
- 已经使用 Cloudflare Workers / WAF / CDN：Cloudflare AI Gateway。
- 已经使用 Kong 做企业 API 管理：Kong AI Gateway。
- Kubernetes 平台团队，需要 Gateway API 数据面：Envoy AI Gateway。
我的默认建议是：先用 LiteLLM 把调用入口收拢起来，再根据真实问题增加能力。只有当团队确实需要托管路由、边缘接入、复杂策略或现成的企业 API 体系时，才选择 Portkey、Helicone、Cloudflare 或 Kong；不要因为“支持 100 个模型”就引入一层网关。
上生产前的几个坑
- Fallback 不等于语义等价。 同一个模型名在不同供应商上的工具调用、上下文长度、JSON Schema、多模态和安全策略可能不同。fallback 目标必须经过业务测试。
- 重试可能放大成本。 超时不一定代表供应商没有处理请求；流式请求和带工具调用的请求尤其要记录每次尝试，避免重复执行副作用。
- 日志就是敏感数据。 Prompt、用户输入、工具结果和模型输出可能含有隐私信息。默认脱敏，必要时关闭请求体记录，并明确保留期限和访问权限。
- 网关会变成新的单点。 自托管至少要考虑多副本、健康检查、配置发布和供应商 Key 的轮换；托管方案也要保留直连或备用出口的应急方案。
- 先统一模型契约，再统一 URL。 应用真正依赖的是工具调用、结构化输出、流式事件和错误语义。只把
base_url改成同一个地址，不足以保证迁移成功。
AI 网关的最终目标不是让所有模型看起来一样，而是让模型供应商的变化不会直接扩散到每个业务服务。入口统一只是第一步，路由可解释、失败可追踪、成本可归因，才是它在生产环境里的价值。