先看证据
统一入口也统一了故障与信任边界
AI 网关位于应用与模型服务商之间，让不同服务通过一套 API 调用多个模型，并把路由、重试、故障切换、缓存、预算和日志放到共同控制层。对生产团队而言，这减少了应用分别适配各家模型接口的工作，也让策略有机会集中执行。
但统一入口不是免费的抽象。网关一旦故障、配置出错或遭遇安全问题，受影响的可能不再是某个模型适配器，而是所有经过它的应用流量。选网关因此不只是问“支持哪些模型”，还要问团队愿意把多少权限、可观测性和故障恢复能力交给这个中间层。
排行榜里的性能数字并非同一把尺
这份 2026 年选型指南把 Bifrost 列为自托管性能首选，并引用其 README 数据：在 t3.xlarge、每秒 5,000 次请求的条件下，网关增加的延迟为 11 微秒；在 t3.medium 上则为 59 微秒。指南还列出 Maxim 对比 LiteLLM 的测试结果：每秒 500 次请求时，Bifrost 的 P99 延迟为 1.68 秒，LiteLLM 为 90.72 秒。这些数字很醒目，但材料没有提供足以核对测试环境、请求构成和完整方法的信息，且一项对比来自 Maxim，不能直接当成独立评测结论。
其他项目的数字也各有口径。Portkey 声称延迟低于 1 毫秒、可路由到 1,600 多个模型；LiteLLM 报告自己的基准测试在每秒 1,000 次请求时达到 8 毫秒 P95。额外延迟、P95、P99、模型覆盖量和请求吞吐量回答的是不同问题。把它们并排比较之前，团队至少要确认测量对象、硬件、流量形态，以及数字是否来自同一套测试。
开放、托管与既有平台，代表不同的控制权
材料中的产品并不是同一类部署选择。Bifrost 是 Apache 2.0 授权的 Go 网关，面向需要在 VPC 或隔离网络自托管的团队；LiteLLM 提供 Python SDK 和代理服务，优势是覆盖 100 多家提供商、生态采用广，但团队也需要运行代理。Portkey 采用 MIT 许可，提供路由与护栏能力，指南称其付费方案从每月 49 美元起，并列出免费额度为 10,000 条记录请求。
托管选项则把运维责任和控制权重新分配。指南将 Cloudflare 描述为偏边缘部署、核心功能免费，将 Vercel 描述为零加价，将 OpenRouter 描述为模型访问入口；这几项标签不足以证明它们在治理、私有部署或故障处置上彼此等价。Kong AI Gateway 的定位是把 LLM、MCP 与 A2A 流量纳入既有 API 网关体系，适合把 AI 流量视作平台治理延伸的团队，但现有材料没有给出足够细节来比较其具体部署限制或性能。
治理能力让网关成为策略执行点
网关的价值不止在于把请求转发到正确模型。材料列出的能力包括虚拟密钥、预算、速率限制、权限管理、审计日志、护栏、缓存和故障切换；Bifrost 的开源版本还列出分层预算与速率限制，LiteLLM 支持团队支出跟踪及 RPM、TPM 限制，Portkey 则强调输入和输出护栏以及 MCP 工具调用的访问控制与日志。
这些能力越集中，网关的配置就越接近一份实际生效的访问与成本政策。技术负责人需要确认策略能否按团队、应用和模型分别设置，日志能否接入现有观测流程，护栏误拦或漏拦时由谁处理，以及紧急情况下是否能绕过或切换。材料提到 Bifrost 的 Prometheus 指标和 OpenTelemetry tracing，也提到 LiteLLM 可将日志送往 Langfuse、OpenTelemetry 等系统，但没有给出各产品在策略完整性或执行效果上的独立验证。
所有权与供应链事件已进入选型范围
这份指南把产品归属和安全历史列为生产选型标准，并给出足以改变尽调范围的背景：Palo Alto Networks 于 5 月 29 日完成对 Portkey 的收购，Portkey 正被纳入 Prisma AIRS；Mintlify 收购 Helicone 后，Helicone 进入维护模式；LiteLLM 则在 3 月经历 PyPI 供应链入侵事件。材料没有展开这些事件的影响范围或后续处置细节，因此不能据此断言某个项目当前不安全或某种商业归属必然更稳妥。
更有用的做法，是把这些信息转成具体核查项：依赖和发布包如何验证，安全问题如何披露与修复，项目维护由谁负责，企业支持和产品路线受什么组织影响。对于自托管团队，还要确认能否锁定版本、审计镜像和依赖，并在必要时更换提供商；对于托管服务，则要核对数据处理、可用性承诺和退出路径。排行榜可以帮助缩小候选范围，但最终选择应由团队自己的负载测试、权限模型和风险承受能力决定。