托管访问与企业 Gateway

KeepRouter 对比 Kong AI Gateway：托管模型访问还是 Gateway 基础设施

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

最后复核 2026-08-15 · 编辑复核: KeepRouter Editorial

直接结论

如果你希望使用带聚焦 API 与目录的托管模型访问服务，不想运维企业 Gateway，也不准备自己安排每个 upstream provider 集成，选择 KeepRouter。如果组织已经运行 Kong，或需要自托管与 hybrid、集中凭证、精细流量策略、AI-specific plugins，以及模型、MCP 或 A2A 流量治理，选择 Kong AI Gateway。两款产品处于不同层。KeepRouter 是托管模型访问；Kong 是 Gateway infrastructure 与 control plane。比较 endpoint 语法之前，应先比较运维责任与 provider 合同，因为这两项会决定大部分实现和后续工作。

决策表

决策因素	KeepRouter	Kong AI Gateway
产品类别	托管模型访问服务	建立在 Kong Gateway 上的企业 connectivity 与 governance 层
运维责任	KeepRouter 运行托管服务	用户与 Kong 按 Konnect 或自托管 topology 分担责任
Upstream providers	使用 KeepRouter 当前目录、凭证与计费条款	用户配置 provider accounts、credentials、services、routes 与 plugins
策略范围	使用文档化 KeepRouter Key、model、endpoint 与服务控制	认证、access tiers、transformations、load balancing、prompt controls 与 AI plugins
部署方式	托管	Konnect、自托管、hybrid、DB-less 与 Kubernetes 等选择随组件变化
更适合	希望获得一套托管模型访问工作流的团队	已经运营 API infrastructure 或要求私有 topology 的平台团队

Kong AI Gateway 提供什么

Kong 把 AI Gateway 定位为建立在 Kong Gateway 上的 connectivity 与 governance 层。它可以暴露 provider-agnostic APIs，集中管理 upstream credentials，执行路由与 load balancing，支持 streaming，并应用认证、access controls 和 usage analytics。Konnect 提供托管 control plane，data plane 责任则取决于所选 topology。

AI plugin catalog 进一步提供 semantic caching、semantic routing、prompt guards、RAG injection、MCP Gateway、A2A Gateway、data governance、metrics 与 request transformations。AI Proxy Advanced 支持在多个 model targets 之间路由、OpenAI-style 格式与部分 provider-native pass-through。准确 route 和能力取决于部署的 Kong version、plugin、topology 与 license。

Kong 不会自动变成带模型额度的托管目录或一张统一 inference 账单。官方 quickstart 要求 Kong 或 Konnect 环境、配置工具，以及 upstream provider 账户与 credentials；自托管示例还要求 Enterprise license。当前价格页也把 base Gateway package、付费 AI plugins 与 model proxy limits 分开处理。

KeepRouter 适合的情况

希望通过托管服务直接调用可用模型，而且不想自己部署、升级、保护和观察 Gateway control plane 的团队，更适合 KeepRouter。企业流量策略、MCP 治理、自定义 plugins 和 provider account 所有权都不是要求时，它能减少初始决策。团队只需选择公开模型与文档化 route，再使用 KeepRouter credentials 和预付用量。

不能把 KeepRouter 描述成自动替代所有 Kong policy。现有应用如果依赖 Gateway authentication、transformations、prompt guards、PII 处理、semantic routing、自定义 plugins 或网络 topology controls，迁移后仍必须明确这些职责的位置。KeepRouter 公开契约也没有提供自托管发行版。

Kong AI Gateway 适合的情况

已经通过 Kong 标准化管理 APIs，并希望把 AI traffic 纳入同一基础设施的组织，更容易采用 Kong。要求自托管或 hybrid、集中 provider credentials、自定义访问策略、semantic routing，或同时治理 model、MCP 与 A2A endpoints 的平台团队，也适合它。

只想获得一个托管 API Key、不想运维 Gateway infrastructure，也不准备分别持有 upstream provider contracts 的开发者，采用 Kong 会更绕。即使使用 Konnect，团队仍要决定 data-plane topology、provider credentials、model routes、plugin set、logging、upgrades 与 license package。

从 Kong AI Gateway 迁入 KeepRouter

盘点每个 Kong control plane、data plane、service、route、plugin、transformation、authentication rule、secret reference 与 upstream provider。
把模型访问与 Gateway policy 分开。只有模型访问部分可能直接迁入 KeepRouter。
按实时 KeepRouter 目录映射必要模型，并比较准确请求 contract。Kong model 与 route identifiers 不是 KeepRouter IDs。
找出 KeepRouter 文档没有提供的 access control、prompt guards、caching、PII 处理、request transformation、MCP、A2A 或 custom plugins。
在移除 Kong 前，把仍然必要的 policies 移到应用或其他 Gateway。
轮换 credentials，确认哪些 upstream provider contracts 可以停止。测试 streaming、errors、tools 与仍在使用的 provider-native 行为。
分阶段切流，在 policy 行为、usage evidence 与 billing 都验证完成前保留 Kong route。

从 KeepRouter 迁出到 Kong AI Gateway

在 Konnect、自托管、hybrid、DB-less、Kubernetes 或其他受支持 topology 中做选择，并指定 control plane 与 data plane 责任。
对照实际 Kong version，确认 AI Proxy Advanced 与每个必要 AI plugin 的 license。
创建或确认 upstream provider accounts，再通过所选 Kong secret mechanism 存储 credentials。
配置 Gateway Services、Routes、model mappings、authentication、load balancing、retries 与 fallback policy。
只有明确需求存在时，才加入 semantic routing、caching、prompt controls、RAG、MCP 或 A2A plugins。
定义 Gateway logging、retention、monitoring、upgrades、incident response 与成本责任。
在实际 topology 上测试 provider-native 与 OpenAI-style routes，再运行分阶段流量与失败场景测试。

能力边界

Kong 功能可用性随 version、plugin、deployment mode 与 license 变化。Plugin catalog 中出现某项能力，不等于特定 topology 已安装或获得许可。Provider-native pass-through 只覆盖文档化 providers 与 formats。Gateway policy 可以集中控制，但不能消除 upstream quotas、terms、model lifecycle 或区域可用性。

没有确定 topology、资源分配、网络路径、provider 与工作负载，就不能给自托管 Kong 与托管 API 做性能排名。两者的成本中心也不同。Kong infrastructure、license 与 provider invoices 不是 KeepRouter 预付 usage ledger。

选择 runtime owner 之前，应阅读托管与自托管 Gateway。AI Gateway 对比、模型路由与评估指南可以把剩余决策变成有边界测试。

常见问题

Kong AI Gateway 自带模型额度吗？

不要这样假设。Kong 是 Gateway infrastructure，官方 quickstart 需要 upstream provider 账户与 API Key。Kong 与 provider 商业条款应分别核对。

Kong AI Gateway 可以自托管吗？

Kong 记录了 Konnect、自托管、hybrid、DB-less 与 Kubernetes 部署选项。准确 plugin 支持、license 与责任随 topology 和 version 而变。

Kong AI Gateway 需要 Enterprise license 吗？

官方自托管 quickstart 使用 Enterprise license，AI Proxy Advanced 与多项高级 plugins 也采用付费 package。应把准确 topology 和 plugin list 与当前定价核对。

Kong 能直接替代 KeepRouter 吗？

不能直接替代。Kong 可以处理相邻路由与治理需求，但把 Gateway 运维和 upstream provider 关系交给用户；KeepRouter 提供托管模型访问。

离开 Kong 时需要重建什么？

应盘点 authentication、access policy、transformations、prompt controls、caching、routing、observability、secrets、MCP 或 A2A policy 与 rollback。模型 endpoint 不会在无文档时替代这些能力。

参考的一手资料

来源复核日期 2026-08-15