应用把模型请求交给 AI 网关后，由网关统一处理供应商适配、模型路由、重试、限流、密钥、日志和成本归因。它解决的是“模型请求怎么进入不同推理服务”。
本文比较 应用到模型 API 的流量入口，不比较模型本身、Agent 编排或工具调用。挑模型和 API 额度看模型 API 对比；治理 MCP 工具、企业 API 和 Agent 间调用看 Agent Gateway 与 MCP 网关对比。产品可能跨界，但下表只比较其模型流量能力。
产品对比
通用模型网关与托管服务
| 产品 | 形态 | 主要能力 | 适合场景 |
|---|---|---|---|
| LiteLLM Proxy | 开源、自托管 | 统一接口、fallback、虚拟 Key、预算与日志 | 需要内部统一入口并愿意自运维 |
| Bifrost | 开源、自托管 | 多供应商统一接口、路由、fallback、虚拟 Key 与观测 | 需要自托管网关和集中治理能力 |
| Portkey AI Gateway | 开源网关与托管控制面 | 条件路由、重试、熔断、缓存、Guardrails | 需要配置化路由和治理策略 |
| Helicone AI Gateway | 托管网关 | 多供应商路由、故障转移、请求与成本观测 | 不想维护代理服务 |
| Cloudflare AI Gateway | Cloudflare 托管 | 边缘接入、日志、缓存、限流与 fallback | 已经使用 Cloudflare / Workers |
| Vercel AI Gateway | Vercel 托管 | 多供应商模型入口、路由与 fallback、统一用量观测 | 使用 Vercel / AI SDK，或希望采用托管模型入口 |
| OpenRouter | 托管模型聚合 API | 一个 API 接入多家供应商、选择与 fallback | 个人试用或需要托管聚合入口；模型目录见模型 API 对比 |
API 网关扩展的 AI 能力
这类产品以通用 API 流量管理为基础，再扩展模型代理、令牌限流和 AI 流量治理，适合已经采用对应网关的团队。
| 产品 | 形态 | 主要能力 | 适合场景 |
|---|---|---|---|
| Kong AI Gateway | API Gateway 扩展 | 模型代理与插件治理；部分功能受版本和授权限制 | 已经使用 Kong 管理 API 流量 |
| Envoy AI Gateway | 开源、Kubernetes 数据面 | 模型供应商适配与路由 | 需要在 Kubernetes / Gateway API 平台内运行 |
| Higress | 开源 API 网关与 AI 网关 | 多模型代理、负载均衡、fallback、令牌限流与缓存 | 已经采用 Higress，或需要自托管 AI 流量治理 |
| Apache APISIX AI Gateway | 开源 API 网关扩展 | 多模型代理、负载均衡、重试、fallback、令牌限流与观测 | 已经采用 APISIX，或希望用插件扩展现有 API 网关 |
| Traefik Hub AI Gateway | Traefik Hub 网关扩展 | OpenAI 兼容入口、模型路由、fallback、语义缓存与令牌治理 | 已有 Traefik Hub / Kubernetes 部署；核对授权与功能范围 |
| Azure API Management AI Gateway | API 管理平台扩展；统一模型 API 预览 | 多模型代理、令牌限额、后端负载均衡、内容安全与遥测 | 已用 Azure APIM；能力受服务层级和预览状态影响 |
| Google Apigee AI Gateway | API 管理平台扩展 | Gemini / Vertex AI 代理、动态模型路由与流量治理 | 已使用 Apigee 或 Vertex AI |
本地代理与模型分发
这组项目更专注 CLI / Coding Agent 的 API 适配、本地路由，或自托管模型分发与用量管理；本节只比较其模型请求能力，不展开 MCP 工具治理或 A2A 路由。
| 项目 | 定位 | 适合场景 | 注意 |
|---|---|---|---|
| Switch Router | OpenAI 兼容的模型路由服务 | 自托管 Provider pools、fallback 与熔断 | 项目仍处于 beta 阶段 |
| Magpie | 本地 Agent 模型网关与配置工具 | 统一多个 Coding Agent 的模型入口、协议和配置切换 | OAuth 订阅接入需核对上游规则 |
| CLIProxyAPI | 将多种 CLI 模型入口包装成兼容 API | 需要 CLI OAuth 接入、账户池或本地代理 | 先核对目标客户端和上游授权方式 |
| AstrLink | 面向 Agent 的本地模型网关 | 聚合订阅和 API Provider，并做本机路由 | 早期项目，部署与功能成熟度需实测 |
| opencodex | Coding Agent 的本地 Provider 代理 | 让 Codex、Claude Code 等切换模型供应商 | 主要服务指定 Coding Agent 工作流 |
| New API | 自托管模型分发与用量管理网关 | 统一 API、渠道路由、Key 管理和团队用量统计 | 仅接入有权使用的上游服务 |
| Sub2API | 自托管的订阅额度分发 API 网关 | 多上游账户、API Key 发放、用量计费和账户调度 | 官方提示此类用法可能违反上游服务条款 |
另一个容易混淆的点是产品能力重叠。LiteLLM、Bifrost、Kong、Gravitee 等也提供 MCP 或 A2A 功能；本文只比较它们代理模型推理请求的部分。New API 侧重授权 API 的统一接入和团队用量管理；Sub2API 侧重订阅账户池和额度分发，两者都不等同于 MCP/A2A Gateway。
怎么选
- 需要自托管的多供应商入口：先比较 LiteLLM 和 Bifrost。
- 需要托管路由与观测：比较 Portkey、Helicone、Cloudflare 和 Vercel；直接聚合试用多家模型可看 OpenRouter。
- 已经有 API 网关或 Kubernetes 平台：比较 Kong、Envoy、Higress、APISIX 和 Traefik Hub；云平台方案可看 Azure API Management 或 Apigee。Azure 统一模型 API 仍处预览阶段，其他 AI 能力按服务层级核实。
- 需要自托管模型分发与团队用量管理：看 New API；若涉及订阅账户池，先核对上游服务条款。
- 单家 API 的模型和额度见模型 API 对比。
- 只有一个应用和一个模型供应商时，直连通常更简单。
上线前重点验证模型的工具调用、结构化输出和流式响应差异；记录每次 fallback 与重试；为日志中的提示词和响应设定脱敏、访问与保留策略。MCP 工具授权和 Agent 间流量不由 AI 网关自然解决，见 Agent Gateway 与 MCP 网关对比。