LiteLLM、Portkey、Cloudflare AI Gateway 与 Kong AI Gateway：智能体与模型之间该摆什么的四种下注

速览

同一件事——在众多厂商前面立一个端点——四种不同的卖法。

四份工作，以及其中哪一份是陷阱

剥掉营销话术，一个网关做四件事。其中三件是毫无歧义的收益，也是值得引入它的全部理由：

• 统一的凭据面。厂商密钥住在网关里，而不是散在十二个服务加一个笔记本里。轮换变成一次操作，撤销某个团队的访问也不再需要一次部署。
• 预算与归因。按团队、按客户、按环境的虚拟密钥，带硬性支出上限。这才是多数团队真正为之而来的东西，而且事后补做确实很难——见成本归因。
• 缓存与一个集中观察点。一个地方记录、计价、并可选地缓存每一次模型调用——包括语义缓存，那是逐服务去造并不现实的东西。

第四件是自动跨厂商故障转移，而它被吹得已经到了误导的程度。它被包装成一个可用性特性，这就引诱你去用可用性算术来推理它：两家 99.9% 的厂商给你 99.9999%。这套算术假设备选做的是同一份工作，而它并不是。

这种失败比一次宕机更糟，因为它看起来不像失败。你的仪表盘一片绿，智能体照跑不误，而某个地方正在吐出一个被另一家厂商以不同方式强转过参数的工具调用——于是你拿到的不是一个干净的报错，而是在谁都腾不出注意力的那个窗口里，安静地、分布式地出错。宕机会呼叫值班；静默的行为变更三周后才变成一份复盘。

这些都不意味着别配故障转移。它意味着把备选当作一份已上线的配置：按与主力相同的节奏对它跑评估集，并持续导一小份线上流量过去，让这条路是热的、被观测的。这正是速率限制与厂商容量里的那个论点，而网关就是你实现它的地方。

LiteLLM——深入

它是什么

一个你自己部署的 MIT 许可代理，在一百多家厂商之上暴露一个 OpenAI 兼容端点，带虚拟密钥、按密钥预算和一个仪表盘。对于既跑自有权重又用托管 API 的团队，它是默认选项，因为它是唯一把一个 vLLM 端点和一个前沿 API 当成同一类东西看待的方案。

它买来什么

没有加价、数据路径上没有第三方、也不必就"你被允许记录什么"去谈判。对任何有数据驻留约束的人来说，这不是偏好，而是唯一合格的形态——与数据驻留与主权是同一套推理。

它的代价

你从此在每一次模型调用的关键路径上运维一个 Python 服务。它需要容量规划、升级、一份值班表，以及一个带共享状态的横向扩缩部署——因为在一个会自动扩缩的集群上按 pod 计的限流器，根本不算限流器。公开基准对"单实例在哪里饱和"的说法差异极大，而这本身就是结论：在你相信任何数字（包括那些基准里的数字）之前，先按你自己的流量形态实测一遍。

Portkey——深入

它是什么

一个托管网关，外围裹着一整套治理件：语义缓存、护栏、提示词管理、链路追踪与预算，都在一个地方。付费档提供自托管——如果你预计会需要它，这就是该早点问清楚的问题。

它买来什么

那些你本来要从四个工具里拼出来的能力，第一天就已经协同工作。语义缓存与护栏尤其是大工程，把它们从路线图变成配置，是实打实转移掉的好几个工程月。

它的代价

提示词与响应会流经第三方。那是一场采购对话、一份数据处理协议，而对受监管的负载来说，有时是一个硬性的"不行"。它同时也是第二个你修不了其事故的厂商，站在第一个你修不了其事故的厂商前面。

Cloudflare AI Gateway——深入

它是什么

立在你现有厂商调用前面的边缘代理，添加缓存、限流、重试、回退与按厂商的分析。接入就是改一个基址 URL；没有东西要部署，也没有东西要扩缩。

它买来什么

近乎零采纳成本的可观测性与管控，这让它成为几乎所有"想搞清楚自己到底需不需要网关"的人的正确第一站。如果结论是你需要按客户的预算和语义缓存，你损失的是一周，而不是一个季度。

它的代价

它的价值在某一个生态内部最高，出了这个生态就掉下来。它也是对数据路径控制最弱的选项：平台给你什么分析你就有什么分析，平台提供多长留存你就有多长留存。

Kong AI Gateway——深入

它是什么

在 Kong 既有的 API 网关上加 AI 专用插件——模型路由、凭据管理、限流、提示词策略——由与你的 REST 流量同一个数据面、同一个控制面来施加。

它买来什么

一套统一的运维叙事。平台团队本来就在跑 Kong、本来就有策略引擎、审计与 RBAC 也早已接好；LLM 流量不再是那个需要自己一套操作手册、自己一位评审人的特例。在大型企业里，这常常比比较表上任何单项功能都更值钱。

它的代价

LLM 专有能力落后于那些专门产品，而且会持续落后——Kong 的重心是 API 管理。如果你要把语义缓存、提示词版本化与评估集成当作一等特性，那你是在要求一个通用网关去当专用网关。

横向比较

谁来运维这一跳，才是那个不可逆的决定

这一品类里的功能对齐来得很快——语义缓存与护栏一年前还是差异点，如今已是标配。不会收敛的是运维与法务上的形态：第三方是否看得见你的提示词、呼机是否挂在你的团队身上、这东西归平台组管还是归产品组管。按这根轴去选，功能比较大体上会自己解决。

你是在一个单点故障前面又加了一个单点故障

这是没人会写在落地页上的那个反对意见。现在每一次模型调用同时依赖厂商和网关，所以网关的可用性必须至少不低于它所保护的对象——否则你买来的多厂商韧性是严格为负的。具体地说：客户端 SDK 需要一条直连厂商的旁路，并且经过演练，好让运维能在不改代码的情况下绕开网关。如果网关是够到模型的唯一途径，那你只是把风险集中了，还管它叫冗余。

延迟开销：去实测，别去读

关于这同一批产品，公开数字彼此相差一个数量级——同一个网关在一份比较里被描述为亚毫秒，在另一份里是几十毫秒。两者都可能是真的，因为开销取决于是否同机房、连接是否复用、响应是否流式，以及是否启用了缓存或护栏检查。相对于一次以秒计的模型调用，个位数毫秒无关紧要；而一次同步的护栏检查则不然。请用你自己的负载形态、并打开你真正会启用的那套特性去做基准，并把每一个公开数字——包括上面那句里的区间——都当成一个待验证的假设。

该选哪一个

延伸阅读

本站：

• 速率限制与厂商容量——这个网关本该施加的那套准入控制。
• 灰度发布、版本化与固定——为什么备选也需要一个带日期的快照。
• 模型路由——按每个请求来选，而不是按每次故障来选。
• 语义缓存——最值得买而不是自己造的那个功能。
• 成本归因——虚拟密钥存在的理由。

项目来源：

• LiteLLM 仓库
• Portkey
• Cloudflare AI Gateway 文档
• Kong AI Gateway