一个请求经过网关，多花几微秒，没人会察觉。但当智能体把四十次调用串成一条链，这几微秒就会被放大成肉眼可见的等待。企业AI网关的选型，最终绕不开这个问题：它挡在每一次模型调用前面，自己到底要吃掉多少时间。
一份面向企业AI网关的对比梳理给出了一个具体数字：在AWS EC2上进行的对比测试中，500个并发用户、单轮运行60秒，Bifrost跑出了每秒424个请求，LiteLLM是44.84个；P99延迟分别是1.68秒和90.72秒。同一份材料里，Bifrost公布的另一组基准显示，单台t3.xlarge上、每秒5000个请求时，其额外开销约为11微秒，成功率100%。
网关不只是转发
把AI网关理解成一个反向代理，只说对了一半。应用只面对一个兼容OpenAI的端点，网关负责翻译、路由，并在OpenAI、Anthropic、AWS Bedrock、Google Vertex AI等供应商之间重试。真正让它变成“企业级”的，是代理之外的东西：身份认证与角色、按团队或客户划分的预算、能交给合规人员的审计记录、部署在自己网络内部，以及一套对服务、智能体和人同样生效的策略。
这也解释了为什么平台团队的问题变难了。哪些MCP服务器可以被智能体访问、是谁批准的、某个团队的支出为什么一周翻了三倍、销售同事往没人配置过的桌面聊天应用里粘贴了什么——这些问题的答案，要么在网关里，要么本该在网关里。
选型先看五件事
在列出候选名单之前，有几项检查绕不过去：
- 真实负载下的开销。每个请求都经过网关，它的处理时间会加到每一次模型调用上。
- 治理深度。按团队的预算、速率限制、基于角色的访问和审计日志，应该在基础设施层强制执行，而不是指望每个应用团队自觉。
- 部署位置。受监管的团队往往需要VPC内、本地或气隙部署，只有托管服务形态的网关对他们直接出局。
- MCP支持。如果智能体要调用工具，网关需要控制它们能触达哪些服务器和工具，以及用谁的凭证。
- 覆盖面。网关只能治理到达它的流量，那些员工自己安装的AI工具怎么办，是必须回答的问题。
五个候选各自的位置
这份梳理比较了五个企业AI网关：Bifrost、Kong AI Gateway、Azure API Management、Portkey和LiteLLM。其中Bifrost被作者列为综合首选，理由是它把模型调用、MCP工具调用和智能体流量放在同一个网关里，完全跑在自有基础设施内，并且是这几个当中唯一通过Bifrost Edge覆盖员工笔记本上AI工具的一个。需要说明的是，Bifrost由Maxim AI开发，这份梳理也由该公司发布，排名需要放在这个背景下看待。
Bifrost本身是Apache 2.0开源、用Go编写的网关，提供统一接口接入25家以上供应商的10000多个模型，迁移现有应用只需改一个base URL。它以单个二进制文件交付，可运行在虚拟机、Kubernetes、私有云或完全断网的网络中。治理方面，虚拟密钥可携带按密钥、团队、客户或模型设定的预算与速率限制；企业版可对接Okta、Microsoft Entra、Keycloak、Zitadel、Auth0、Google Workspace或任意OIDC提供商，支持SCIM 2.0目录同步和细粒度RBAC。路由上组合了加权负载均衡、带退避的重试和自动故障转移，语义缓存可复用相似提示的既有答案，后端支持Redis、Qdrant、Weaviate或Pinecone。
其余四个各有更窄的适用场景。此外，这份梳理提醒，有两件事应该进入今年的采购讨论：Palo Alto Networks收购了Portkey，以及LiteLLM在3月发生了一起PyPI供应链事件。
热门跟贴