AI Gateway 对比：开源自建、云原生与云托管怎么选？
简答：一句话结论：小团队先比较 LiteLLM、New API 和 Portkey，已有云原生网关则重点看 APISIX 或 Kong，想减少基础设施维护可看 Cloudflare 或 Vercel。选型不要只看模型数量，还要验证接口兼容、流式响应、Fallback、Token 统计、缓存类型、密钥隔离和 MCP 权限。
定义：AI Gateway 是位于应用与模型提供商之间的流量控制层，用于统一接口、路由模型、管理密钥、执行限流与重试，并记录请求、Token、延迟和成本等信息。
先看速查表：不同团队优先比较什么
如果你只想先缩小候选范围，可以按部署方式和运维边界判断：没有现成云原生基础设施，优先验证轻量自建或托管方案；已经使用 API 网关、Kubernetes 或统一可观测平台，再比较 AI 能力能否融入现有体系。
| 场景 | 优先比较 | 首先验证 |
|---|---|---|
| 个人项目或小团队 | LiteLLM、New API、Portkey | 统一接口、虚拟 Key、模型路由、用量记录和部署复杂度 |
| 已有 API 网关或云原生平台 | Apache APISIX、Kong | AI 插件、Token 限流、流式转发、Provider 路由和权限模型 |
| 希望减少服务器运维 | Cloudflare AI Gateway、Vercel AI Gateway | BYOK、区域、数据保留、账户限额、Fallback 和迁移成本 |
| 需要 Agent 或 MCP 流量治理 | Kong、LiteLLM、Portkey | MCP Server 代理方式、工具级权限、审计和撤销能力 |
| 需要精细成本与配额控制 | LiteLLM、APISIX、Kong、Cloudflare | Token 统计口径、预算维度、缓存命中规则和限流单位 |
本站为第三方指南，非任何 AI Gateway 产品官方，产品能力、版本和授权以各自官网为准。截至2026年10月23日，以上分类只用于缩小候选范围，不代表某个方案在所有项目中都更好。
AI Gateway 和普通 API Gateway 有什么区别？
普通 API Gateway 主要处理 HTTP 路由、认证、限流、负载均衡和日志；AI Gateway 还要处理模型名称、Provider 格式差异、输入输出 Token、流式响应、模型回退和生成式请求成本。
| 维度 | 普通 API Gateway | AI Gateway |
|---|---|---|
| 路由对象 | 服务、域名、路径或版本 | 模型、Provider、能力类型和路由策略 |
| 流量单位 | 请求数、连接数、字节数 | 请求数、输入 Token、输出 Token、缓存 Token和成本 |
| 请求处理 | HTTP、REST、gRPC 等协议 | OpenAI、Anthropic、Gemini 等模型协议及格式转换 |
| 故障处理 | 重试、健康检查和负载均衡 | 判断模型错误是否可重试，并决定是否切换 Provider 或备用模型 |
| 安全边界 | 客户端、服务和路径权限 | 还包括上游 Key、Prompt、工具调用、模型权限和敏感信息 |
Apache APISIX 官方 AI Gateway 说明将 AI Gateway 描述为应用与模型提供商之间的流量控制层，并列出 Provider 代理、Token 限制、重试回退、Prompt 控制和可观测性等能力。实际项目中，OpenAI 兼容只说明入口格式相近，不代表所有参数、工具调用和流式事件都完全一致。
主流方案对比：看清部署和能力边界
| 方案 | 部署路线 | 官方资料可确认的能力 | 更适合谁 | 主要核验项 |
|---|---|---|---|---|
| LiteLLM | 开源自建 Gateway，也有企业授权 | 统一模型入口、虚拟 Key、预算、限速、Spend Tracking、负载均衡、Fallback、Guardrails 和 MCP Gateway | 需要快速聚合多个 Provider，并按用户、团队或项目分发 Key 的团队 | 部署、数据库、日志脱敏、升级方式，以及哪些能力需要 Enterprise 授权 |
| New API | 自建 AI 网关与管理面板 | 统一 API 入口、OpenAI 兼容格式、多渠道路由、自动故障切换、权限和调用审计 | 希望用管理面板集中维护模型、渠道、用户和用量的团队 | 实际版本支持的模型协议、部署安全、上游授权和插件兼容性 |
| Apache APISIX | 开源云原生网关 | Provider 代理、AI 流量负载均衡、Token 限流、重试回退、Prompt 控制、日志和精确或语义缓存 | 已有 APISIX 或希望 AI 流量与普通 API 共用网关的团队 | 插件依赖、Redis 配置、流式响应和具体版本行为 |
| Kong AI Gateway | 托管控制平面加自管数据平面 | LLM、MCP 和 A2A 流量统一治理，支持模型路由、格式转换、权限、Token 成本观测和工具访问控制 | 需要企业级策略、审计、团队权限和多类 AI 流量治理的组织 | 控制平面、数据平面、网络边界以及具体策略的授权条件 |
| Portkey Gateway | 开源 Gateway 与托管服务 | 多模型路由、重试、Fallback、负载均衡、Guardrails 和 MCP Gateway | 希望把模型路由、内容防护和工具治理放在一个入口的团队 | 自建、Hosted 和 Enterprise 能力是否相同 |
| Cloudflare AI Gateway | 云托管 | 日志、分析、缓存、限流、重试和模型回退，并支持多个模型 Provider | 已有 Cloudflare 体系、希望减少网关基础设施维护的应用 | BYOK、请求限制、日志边界、Unified Billing 和区域要求 |
| Vercel AI Gateway | 云托管与 SDK 集成 | Provider 顺序与筛选、Provider 超时、模型 Fallback，以及通过配置启用的缓存策略 | 已经使用 Vercel AI SDK 或需要快速切换 Provider 的应用 | 客户端协议、模型目录、BYOK、缓存配置和平台账户限制 |
New API 官方仓库说明其定位是面向模型、应用和 Agent 的 AI 网关，并提供统一接口、路由、成本管理和安全控制。LiteLLM 官方 Enterprise 文档则明确区分了开源 Gateway 与 Enterprise 能力：SSO、SCIM、审计日志、组织与团队管理员、Secret Manager、IP 白名单和部分 Guardrails 需要按官方授权说明核对，不能默认全部免费。
Kong 官方架构文档显示其 AI Gateway 采用托管控制平面与自管数据平面的混合模式，数据平面负责接收 LLM、MCP 和 A2A 流量。Portkey Gateway 官方仓库同时列出了重试、Fallback、负载均衡、Guardrails 和 MCP Gateway，但自建、Hosted 与 Enterprise 的边界仍需逐项核对。
最容易误判的能力：缓存、Enterprise 和 MCP
| 比较项 | 容易产生的误解 | 正确的核验方式 |
|---|---|---|
| 精确缓存 | 只要写了“支持缓存”就能处理相似问题 | 查看缓存键是否包含 Provider、路径、模型、认证信息和完整请求体 |
| 语义缓存 | 与普通响应缓存完全相同 | 确认是否基于向量或相似度匹配，以及是否适用于工具调用和个性化请求 |
| 开源版功能 | 代码仓库存在就代表所有企业能力免费 | 逐项查看官方版本、插件、授权和 Enterprise 标识 |
| MCP 支持 | 能连接 MCP 就等于有完整工具治理 | 分别核对代理、聚合、工具级权限、身份传递、审计和撤销 |
| OpenAI 兼容 | 所有客户端参数和流式事件都完全兼容 | 用目标客户端实测模型 ID、工具调用、SSE、错误格式和超时 |
Cloudflare 官方缓存文档说明其缓存默认关闭，并且当前按完整请求精确匹配；请求体中的消息、工具或模型参数发生变化，都可能形成不同缓存项。Kong 官方语义缓存文档则说明语义缓存基于请求含义和向量相似度检索，两者不能在对比表里简单合并为“缓存”。
Vercel 的缓存也应按配置理解，而不是当成默认行为。其Provider Options 文档提供了 caching: 'auto' 配置，用于让 AI Gateway 根据 Provider 采用相应缓存策略；上线前仍应确认支持的 Provider、接口类型和缓存边界。
按团队规模做决策：一张可执行的选型树
| 判断问题 | 是 | 否 |
|---|---|---|
| 已经运行 Kubernetes、API 网关或服务网格？ | 优先评估 APISIX、Kong，并核对能否接入现有认证、日志和发布体系 | 继续判断是否愿意自己维护服务器、数据库和升级 |
| 愿意承担网关自建和升级？ | 比较 LiteLLM、New API、Portkey 的最小部署和管理能力 | 比较 Cloudflare、Vercel 等托管方案的账户、区域、数据和计费边界 |
| 需要按团队、项目或用户分发 Key 和预算？ | 重点测试虚拟 Key、预算、限速、日志字段和权限继承 | 先验证单一应用的接口兼容、流式响应和故障处理 |
| 需要 MCP 或 Agent 工具治理？ | 单独测试工具发现、调用权限、审计、撤销和敏感参数处理 | 不要为暂时不用的复杂能力增加额外运维负担 |
这张决策树的核心不是把产品简单分成“好”与“坏”，而是先匹配组织已经具备的基础设施和运维能力。个人项目通常更在意接入速度和配置简单；中大型团队更在意权限、审计、数据边界、升级流程和故障切换。
上线前验证清单：不要只看产品首页
- 验证统一入口：使用目标客户端发送一个最小请求，确认 Base URL、API Key、模型 ID、请求路径和响应结构。
- 验证模型发现：调用网关提供的模型列表接口，确认模型 ID 是当前配置中的实际值，不要直接复制文章或搜索结果里的示例名称。
- 验证流式响应：检查 SSE 是否持续收到事件、是否有结束标志、客户端超时如何处理，以及连接中断后是否能安全重试。
- 验证错误边界：分别测试 400、401、403、404、429、5xx 和超时，记录错误来自网关还是上游 Provider，并确认哪些错误会触发 Fallback。
- 验证成本和配额：确认输入 Token、输出 Token、模型、用户、项目和 Key 是否能被单独统计，预算口径是否与上游账单一致。
- 验证安全：确认上游 Provider Key 只保存在网关侧，客户端拿到的是受限 Key，并检查日志是否暴露 Authorization、Prompt 或敏感响应。
- 验证缓存：确认缓存是否默认关闭、缓存键包含什么、是否会缓存工具调用和个性化请求，以及如何跳过缓存。
- 自测 TTFT 与内存：在相同区域、模型、Prompt 和并发条件下，分别直连 Provider 与经过 Gateway，记录首字节时间、完整响应时间、错误率和进程内存变化。不要把一次测试结果当成通用排名。
- 验证 MCP：确认 MCP Server 是代理、聚合还是转换 REST API，并分别测试工具级授权、身份传递、审计和撤销。
建议将上述项目写成自动化回归测试，在更换 Provider、升级网关版本、修改路由规则或调整缓存策略后重新执行。这样比单纯比较首页功能勾选更容易发现真实兼容性问题。
常见问题
AI Gateway 对比时最应该先看哪三个指标？
先看客户端接口和流式响应是否兼容；再看路由、重试与 Fallback 是否覆盖你的故障场景；最后看 Key、Token、预算、日志和数据保留是否符合要求。模型数量和宣传性能应放在这些基础条件之后。
LiteLLM、New API 和 APISIX 怎么选？
如果重点是快速聚合模型、虚拟 Key、预算和用量统计，可以先验证 LiteLLM 或 New API；如果已经使用 APISIX，希望 AI 与普通 API 共用认证、限流、日志和插件体系，则优先评估 APISIX。最终要用同一套最小请求、流式请求和错误测试验证。
云托管 AI Gateway 一定比自建更便宜吗？
不能直接判断。托管方案减少了服务器、升级和部分故障处理工作，但可能存在平台费用、账户限额、日志费用、区域限制或迁移成本；自建则需要承担基础设施、备份、升级、安全和监控。应按请求量、团队运维能力、合规要求和迁移成本测算。
AI Gateway 的缓存和 CDN 缓存是一回事吗？
不是。AI Gateway 缓存通常要结合 Provider、模型、请求体和参数判断是否命中，还可能涉及 Prompt、工具和响应内容。以 Cloudflare 为例，官方文档明确说明其 AI Gateway 缓存当前面向相同请求，不等同于语义缓存。
支持 MCP 是否代表可以安全代理所有工具？
不代表。需要继续核对服务器代理、工具聚合、工具级权限、用户身份传递、审计日志、撤销机制和敏感参数处理。MCP 连接能力与完整工具治理能力是两个不同层次。
如何验证某个 AI Gateway 是否支持我的客户端？
先确认客户端使用的是 Chat Completions、Responses API 还是 Anthropic Messages，再测试 Base URL、Key、模型 ID、工具调用、流式响应、超时和错误透传。不要因为文档写了 OpenAI compatible，就假定所有参数和事件格式完全一致。
常见问题
AI Gateway 对比时最应该先看哪三个指标？
先看客户端接口和流式响应是否兼容；再看路由、重试与 Fallback 是否覆盖故障场景；最后看 Key、Token、预算、日志和数据保留是否符合要求。
LiteLLM、New API 和 APISIX 怎么选？
需要快速聚合模型、虚拟 Key、预算和用量统计，可以先验证 LiteLLM 或 New API；已有 APISIX 并希望 AI 与普通 API 共用治理体系，则优先评估 APISIX。
云托管 AI Gateway 一定比自建更便宜吗？
不能直接判断。托管方案减少部分基础设施运维，但可能存在平台费用、账户限额、区域限制和迁移成本；自建则需要承担服务器、备份、升级、安全和监控。
AI Gateway 的缓存和 CDN 缓存是一回事吗？
不是。AI Gateway 缓存通常结合 Provider、模型、请求体和参数判断是否命中，可能还涉及工具调用和响应内容；精确缓存与语义缓存也不能混为一谈。
支持 MCP 是否代表可以安全代理所有工具？
不代表。还要核对服务器代理、工具聚合、工具级权限、身份传递、审计、撤销和敏感参数处理。
如何验证某个 AI Gateway 是否支持我的客户端？
先确认客户端使用的 API 类型，再测试 Base URL、Key、模型 ID、工具调用、流式响应、超时和错误透传，不要只依据 OpenAI compatible 这一描述。
相关阅读
参考资料
- New API 官方 GitHub 仓库
- New API 官方 README
- LiteLLM Enterprise 官方文档（docs.litellm.ai）
- Apache APISIX AI Gateway 官方页面（apisix.apache.org）
- Kong AI Gateway 架构文档（developer.konghq.com）
- Kong AI Semantic Cache 官方文档（developer.konghq.com）
- Portkey Gateway 官方 GitHub 仓库
- Cloudflare AI Gateway 缓存文档
- Cloudflare AI Gateway 官方文档
- Vercel AI Gateway Provider Options 文档（vercel.com）