五款大模型网关的企业选型对比

多个团队接入多个模型后，麻烦往往出在模型之外：密钥各管各的，限流规则不一致，故障切换查不到，费用也算不清。LLM gateway 把这些事情收进一个入口，让应用与模型供应商之间多一层统一管理。

原文比较了 Bifrost、LiteLLM、Kong、Apache APISIX 和 Azure API Management。它最有用的部分是把选型拆成能复现的验收项；最需要保留判断的地方，则是文章与 Bifrost 团队合作完成，测试深度和性能证据并不对等。

网关值不值得加，先验收这五件事

第一，能否统一 API。应用发送 OpenAI 格式的请求，由网关处理供应商凭证和格式转换。最直接的验收方式，是现有 OpenAI SDK 只改 base URL 就能工作。但请求格式兼容，不代表所有模型能力都能无损迁移。

第二，故障切换能否看见。主供应商挂了，备用服务接住请求只是起点；响应或日志还应说明谁实际提供了服务，否则团队可能长期使用备用模型却毫不知情。

第三，能否按调用方管费用。团队或应用各领一把 key，分别设置预算、请求数、token 限额和模型白名单。超限后还要返回客户端能处理的状态码。

第四，监控能否接入现有系统。请求量、延迟、token 用量之外，每条日志还应能关联调用方。提示词和回答正文是否记录，也必须明确。

第五，需要维护什么状态。单容器加 SQLite，与 PostgreSQL、Redis 配套运行，是两种运维投入。

作者对可自托管产品使用 Docker 和两个模拟上游测试：一个正常，一个始终返回 503。Azure 部分仅依据 Microsoft Learn，没有实际部署。

这组测试能证明部分功能是否跑通，不能证明真实生产负载下谁更快、更稳。

Bifrost 与 LiteLLM，差别不只在 Go 和 Python

Bifrost 是 Go 编写、Apache 2.0 许可的网关，原文列出 25+ 供应商、10,000+ 模型，以及 11 微秒的基准开销。这个性能数字并非五款产品在同一环境下的对照结果。

作者拉取的 maximhq/bifrost:latest 实际为 v2.3.2，构建于 2026 年 10 月 20 日。它用内置 SQLite 跑通路由、治理、日志和监控，无需外部数据库。

部署脚本需要留意版本变化：v2.2.5 起，首次创建管理员前必须通过 BIFROST_SETUP_TOKEN 或 config.json 提供 setup token；v2.2.6 起，管理员创建前，管理 API 和 /metrics 都被锁定。缺少 token 时，/api 返回 403。

作者把主供应商指向故障上游，请求加入 "fallbacks": ["backup/gpt-4o-mini"] 后得到 200。下面这些响应头解决了「切换发生了却看不见」的问题：

X-Bifrost-Provider: backup
X-Bifrost-Routing-Info-Is-Fallback: true
X-Bifrost-Routing-Info-Primary-Provider: openai
X-Bifrost-Fallback-Index: 1

重点看 X-Bifrost-Routing-Info-Is-Fallback；去掉 fallback 数组，同一请求直接返回上游的 503。

虚拟 key 每分钟限 3 次，第四次返回 429；调用白名单外供应商返回 403，日志记录 virtual_key_name。不过，SQLite 适合单主机，多节点需迁移到 PostgreSQL；集群、SSO、RBAC、审计日志和按实时健康状况选择上游的自适应路由属于 Enterprise。提示词和回答默认存储，可全局、按 key 或按请求关闭。

LiteLLM 的优势是供应商覆盖和路由策略：README 写 100+ 供应商，官网写 140+、1,892 个模型，统计口径并不一致。它支持按忙闲、延迟、用量、成本选部署，也能针对上下文超限、内容策略拒绝配置 fallback。作者实测切换成功，x-litellm-model-api-base 标明备用地址，x-litellm-overhead-duration-ms 则提供每次请求的代理开销。

代价是状态服务。/key/generate 没有数据库会返回 500，要求用 DATABASE_URL 配置 PostgreSQL；生产指南要求超过一个代理实例就引入 Redis，约 1,000 RPS 时增加 Redis 事务缓冲。

供应链也必须进入选型。原文援引 LiteLLM 自身披露：2026 年 3 月 24 日的 1.82.7、1.82.8，以及 10 月 21 日的 1.107.0 曾遭入侵，后者波及 latest、main-latest Docker 标签约两个半小时。作者 10 月 26 日拉到的是恢复后的 1.106.2。其 Rust 核心虽有 0.7 ms p99 基准，但仍是 beta，只覆盖部分端点和供应商，不能代表全部 Python 路径。

已有 API 网关，先看功能在哪条许可线后面

Kong 的吸引力是复用现有消费者、路由和插件。作者测试的开源线为 3.9.4，Enterprise 为 3.16.0.1；2026 年 7 月起，Kong AI Gateway 2.x 又采用独立的 Konnect 托管控制面，不能混为同一套部署方式。

开源 ai-proxy 支持 16 家供应商，统一请求格式、token 日志和监控可以使用。但负载均衡、故障切换、熔断位于 ai-proxy-advanced，token 限流、语义缓存、PII 清理和 MCP 代理也在 Enterprise。原文所列 Plus 起价为每月 25 美元，含 100 万请求、最多 5 个 LLM；Enterprise 单独报价。

Apache APISIX 3.19.0 则把 12 个 ai-* 插件放在 Apache 2.0 开源版本中。作者使用 standalone 模式，路由写在 YAML 文件里，无需 etcd。自 3.17 起，插件能识别 OpenAI chat、Responses、embeddings、Anthropic Messages 和 Bedrock Converse 等输入格式并转换。

其 ai-proxy-multi 测试使用主实例 priority 1、备用实例 priority 0，配置 fallback_strategy: ["http_429", "http_5xx"] 和 max_retries: 1，成功返回 200。下面的访问日志把两次上游尝试放在一起：

"POST /multi HTTP/1.1" 200 ... mock-fail:32000, mock-ok:32000 503, 200

重点看末尾的 503, 200。客户端响应没有标明备用实例，需要从网关日志定位切换。

APISIX 的额度按响应 usage 统计。作者设置每分钟 10 token，模拟上游每次报告 6 token，第三次请求被拒绝。这提示我们：它不能被理解为请求前精确预留 token。默认拒绝码是 503，作者改成了 429。

它的额度默认按节点计算，节点增加会扩大有效额度，3.18 才加入 Redis 集群额度策略。美元预算、逐消费者模型白名单、key 管理界面不在开源版中；管理员 RBAC、SSO 和配置审计属于 API7 Enterprise。

Azure 的强项是接入现有治理体系

Azure API Management 的 AI gateway 是现有网关上的策略和后端能力。

llm-token-limit 可按分钟限速、按小时到年设置额度，分别返回 429 和 403；后端池最多容纳 30 个后端，支持权重、优先级和熔断，并遵守 Azure OpenAI 的 Retry-After。托管身份连接模型，调用方用订阅 key 或 Entra token，适合身份和监控已经在 Azure 的组织。

但统一 API 是它的短板：预览中的 unified model API 只转换 OpenAI Chat Completions 与 Anthropic Messages，其他供应商通常仍保留各自 schema。

另外，token 限额不跨网关汇总，多区域部署不能直接当成全局预算。微软负载测试还显示：超过 1,000 RPS 时，开启 Application Insights 日志使吞吐下降 40%–50%。

成本也要连配套服务一起算。原文列出的 East US 月价约为 Basic v2 150 美元、Standard v2 700 美元、Premium v2 2,800 美元，尚未计入 Redis 和 Content Safety；2026 年 7 月宣布的 AI Gateway tier 仍是无 SLA 的预览。

我的判断

原文最可靠的建议，是拿自己的验收项测网关。相比之下，「Bifrost 生产最优」证据不足：11 微秒与 LiteLLM Rust beta 的 0.7 ms p99 不是同口径数据，APISIX 没有 AI 插件公开基准，Azure 也未实测。

开源功能齐全，不等于生产治理免费。

Bifrost 把集群和管理能力划入 Enterprise；APISIX 需要平台团队维护密钥和管理面；LiteLLM 引入数据库、缓存和制品验证成本。已有 Kong 或 Azure 的团队，复用身份、监控和运维流程可能更划算。

小团队只有一个供应商、少量服务时，直接 SDK 加统一服务端封装仍可作为起点。原文没有提供它与网关的成本对照，也没有明确网关应在多大调用规模下引入。

能拿来做什么

• 给 Node 服务评估网关时，先保留现有 SDK 调用，只修改 base URL，逐项验证实际使用的模型接口和参数。
• 准备正常与持续返回 503 的两个模拟上游，检查切换结果、响应头、日志，以及不配置 fallback 时的行为。
• 为日常 AI 编程工具和业务应用分别发 key，验证第四次请求、额度耗尽、模型越权等边界，并确认正文日志的默认设置。
• 上多实例前，查清额度按节点还是全局计算，同时固定部署版本、核验制品，并把数据库、Redis 和商业许可计入预算。