比较 AI 网关的运行模式，而不是口号

AI 网关真正的差异在于：谁持有供应商账户、谁负责部署、路由策略、计费、可观测性和故障响应。我们的对比会明确这些边界，并链接每个产品的当前官方资料。

先用按适配场景组织的候选清单和运行模式指南缩小范围，再打开符合部署、计费、可观测性与迁移约束的产品对比。这里不会宣布一个适合所有人的赢家。

选型指南

  1. 按场景选择 AI Gateway

    不存在对所有团队都有效的通用冠军。KeepRouter 适合希望通过边界明确的公开目录获得托管预付模型访问的团队；Vercel AI Gateway 适合需要 BYOK 与供应商控制的 Vercel 和 AI SDK 工作流；OpenRouter 提供更广的托管路由控制面；Portkey 与 Helicone 更强调控制和可观测；LiteLLM 适合愿意自己运营代理的团队；Cloudflare 与 Kong 则更适合已经由其平台管理流量策略的组织。

  2. OpenRouter 替代选项

    选择 OpenRouter 替代方案时，先说清需要改变哪种控制。KeepRouter 提供边界更明确的托管目录与预付账户；Vercel AI Gateway 把托管路由连接到 AI SDK 与 BYOK；Portkey 与 Helicone 更强调网关控制面和可观测；LiteLLM 把代理移入团队自己的基础设施；Cloudflare 在流量平台中增加 AI 控制，而 Hugging Face 更重视模型与任务发现。

  3. 托管与自托管 AI Gateway

    托管 AI Gateway 由服务运营方负责网关部署、扩缩容和大部分故障链路；自托管则把基础设施、凭证、存储、升级和可用性放到团队自己手中。托管访问通常更快进入生产；只有基础设施位置、自定义策略或供应商账户控制值得持续运维时，自托管才更合理。

  4. AI Gateway 对比供应商直连 API

    供应商直连 API 提供到原生能力、合同与支持的最短路径。只有多个应用需要共享凭证、模型访问、路由、消费策略或请求证据时，AI Gateway 增加的一跳才值得。单一稳定供应商或独有原生能力适合直连；重复接入与治理已经成为实际运行成本时，适合使用网关。

产品对比

  1. KeepRouter 对比 OpenRouter

    KeepRouter 是带公开用户价格的托管预付费模型目录，受支持聊天模型可走 OpenAI 与 Anthropic 兼容路由，上游路由由运营方管理且不公开。OpenRouter 是多供应商 API，其当前文档提供请求级供应商选择、排序、fallback、数据策略与 BYOK 控制。需要边界明确的目录和更简单采购路径时更适合 KeepRouter；必须由应用直接控制供应商路由时更适合 OpenRouter。

  2. KeepRouter 对比 Portkey

    KeepRouter 通过预付额度和 KeepRouter Key 销售公开目录中的托管模型访问。Portkey 当前文档说明原 Virtual Keys 已迁移到 Model Catalog，团队可添加供应商凭据，并管理组织级预算、限流、模型白名单与访问权限。希望模型采购层也被托管时更适合 KeepRouter；希望治理自己掌控的供应商关系时更适合 Portkey。

  3. KeepRouter 对比 LiteLLM

    KeepRouter 是托管模型访问服务，提供边界明确的公开目录和预付费用户计费，用户无需运营代理基础设施。LiteLLM 是可作为 Python SDK 或 Proxy Server 使用的软件；官方文档记录了供应商协议转换、重试与 fallback 路由、Virtual Key、预算、日志、成本追踪和限流。需要购买一条托管路径时选 KeepRouter；必须自行掌控网关与供应商配置时评估 LiteLLM。

  4. KeepRouter 对比 Cloudflare AI Gateway

    KeepRouter 是面向用户的托管模型服务，提供公开模型价格、预付额度、限定 Key 与专用 API 路由。Cloudflare AI Gateway 是 Cloudflare 的控制与可观测层，其当前文档覆盖日志、分析、缓存、限流、消费上限、重试、fallback、动态路由、供应商原生路径，以及使用 Cloudflare 认证和 Unified Billing 的 REST API。Cloudflare 已将旧版 Universal Endpoint 标记为弃用，并将 /compat/chat/completions Unified API 标记为不再用于标准单模型调用，但动态路由仍使用后者。两者解决不同问题；只有明确架构与计费边界后才适合分层。

  5. KeepRouter 对比 Vercel AI Gateway

    需要聚焦的托管模型目录与 API 时选择 KeepRouter。应用已经采用 Vercel 或 AI SDK，或者明确需要 BYOK、provider 顺序、自动 provider 选择与网关预算时，选择 Vercel AI Gateway。两者都是托管服务，但路由控制和生态责任不同。

  6. KeepRouter 对比 Helicone

    主要需求是通过聚焦 API 与目录获得托管模型访问时，选择 KeepRouter。路由必须与详细请求可观测性、成本追踪、sessions、prompt operations、缓存和自定义限流放在一起时，选择 Helicone。Helicone 当前既有托管 AI Gateway，也有开源 observability 平台，不能再把它只描述成日志代理。

  7. KeepRouter 对比 Kong AI Gateway

    希望使用托管模型访问服务，而且不想运维企业 Gateway 或分别配置每个上游 provider 时，选择 KeepRouter。组织已经运行 Kong，或需要自托管与 hybrid、集中凭证、流量策略、AI plugins，以及模型、MCP 或 A2A 流量治理时，选择 Kong AI Gateway。两者位于不同产品层。

  8. KeepRouter 对比 Amazon Bedrock

    如果你需要托管模型目录、一个 KeepRouter 账户和更小的接入面，选择 KeepRouter。若 AWS IAM、区域部署、模型与 Agent 服务以及 AWS 原生治理属于硬性要求，则选择 Amazon Bedrock。Bedrock 当前记录了 Responses、Messages、Chat Completions、Converse 与 Invoke 等多种推理接口，但具体支持仍随模型和端点而变。

  9. KeepRouter 对比 Gemini Enterprise Agent Platform

    KeepRouter 更聚焦于通过公开目录和 KeepRouter 凭证提供托管模型访问。Gemini Enterprise Agent Platform 是 Google Cloud 当前产品名称，现已包含原 Vertex AI 能力、Model Garden、Agent Studio、Agent Runtime、评估、调优与云治理。旧称 Vertex AI 只应作为迁移与搜索提示保留。

  10. KeepRouter 对比 Microsoft Foundry

    KeepRouter 适合需要 KeepRouter 凭证和边界明确公开目录的托管模型 API 团队。Microsoft Foundry 原名 Azure AI Foundry，是覆盖模型、Agents、Tools、Projects、评估、Tracing、Monitoring 与企业策略的 Azure 平台。Foundry 存在多种端点族，不能把一个 OpenAI SDK 示例理解成适用于所有工作负载的通用端点。

  11. KeepRouter 对比 Hugging Face Inference Providers

    KeepRouter 是聚焦的托管模型 API，拥有自己的公开目录、路由、凭证与预付账本。Hugging Face Inference Providers 是集成在 Hub 中的代理，使用一个 HF token，提供供应商选择策略、统一计费或自定义供应商 Key，并覆盖多种推理任务。其 OpenAI 兼容端点明确用于 chat，更广任务则使用 Hugging Face client 或任务专属 HTTP 调用。

实时模型目录 · 快速开始 · 阅读 Markdown 版本