开源 LLM 网关选型：Portkey、Bifrost、LiteLLM，踩完坑说几句真话

你的团队调用大模型 API，一开始可能是直连 OpenAI。后来加了 Claude，再后来又接了 Gemini。每个厂商一套 SDK，一套鉴权，一套错误码。代码里到处是 if-else，运维的人看了想辞职。

这时候你会想：能不能有一层代理，把所有模型统一起来？

能。这就是 LLM 网关干的事。2026 年，开源方案已经不少：Portkey Gateway、Bifrost、LiteLLM，还有更小众的 Envoy Model Router。我过去半年在生产环境里都碰过，说说真实体感。

LiteLLM：用的人最多，坑也最多

LiteLLM 是 Python 写的，Star 数高，文档全，社区活跃。如果你只是本地开发、跑个 Demo，它确实方便——pip install litellm，几行代码就能把 OpenAI、Anthropic、Bedrock 统一成一个接口。

问题出在生产环境。

Hacker News 上有个帖子说得很直白：LiteLLM 的核心 utils.py 超过 7000 行，各种模型的适配逻辑全堆在一起。你想改一个 Anthropic 的参数映射，得在这 7000 行里翻。有人提了 PR 修 Bug，等了三个月没合。

更头疼的是性能。LiteLLM Proxy 模式（作为 HTTP 服务部署）在高并发下延迟明显上升。我们测过：10 QPS 时 P99 延迟增加约 200ms，50 QPS 时偶尔出现请求排队。它的预算控制功能也有 Bug——设了月度上限，实际扣费有时滞后，超支了才告警。

如果你的场景是个人项目、内部工具、日调用量在几千以下，LiteLLM 够用。一旦上量，准备好填坑。

Bifrost 是 2025 年底冒出来的项目，用 Go 写。它的卖点很简单：快。官方数据是 5000 QPS 下平均开销 11 微秒，比 LiteLLM 快 40-50 倍。

我们实测下来，数字没那么夸张，但确实比 LiteLLM 好一个量级。在同等硬件上，Bifrost 的 P99 延迟基本就是上游 API 的延迟加几毫秒，而 LiteLLM 会额外加 50-200ms。

Bifrost 的架构比较干净：每个 Provider 一个 adapter，负载均衡支持轮询和加权。它还有一个 Web UI 可以看实时流量。

短板也明显。社区还小（截至写稿时 1800 Star），文档偏薄。一些高级功能——比如按用户计费、请求审计、Guardrails 集成——还没有。你得自己在上层补。另外它不支持流式输出的中间拦截，想在网关层做内容审核不太方便。

适合场景：你需要一个轻量、高性能的代理层，上层有自己的业务逻辑，不指望网关帮你做太多。

Portkey 是 TypeScript 写的，10500+ Star，功能列表很长：重试、回退、负载均衡、条件路由、Guardrails、缓存、日志、多模态支持。它号称兼容 250+ 模型。

用下来的感受是：功能确实全，但部署和运维成本也高。它不是一个纯代理，更像一个平台。你可以用 Docker 自己跑，也可以用 Portkey Cloud（SaaS 版本）。自部署的话，依赖 Redis 做缓存、PostgreSQL 做日志，还有一套管理界面。

如果你本来就打算建一个内部的 AI 平台，Portkey 省了不少重复开发。但如果你只是想在 Nginx 后面加一层模型路由，它有点重。

另一个要注意的点：Portkey 的开源版和商业版有功能差异。一些企业级能力（比如审计日志导出、SSO）需要付费。开源版够用，但别被功能列表误导。

Envoy Model Router 是个更小众的方案，基于 Envoy Proxy 做的。如果你的基础设施已经在用 Envoy 或 Istio，它的集成成本很低——本质上是给 Envoy 加了一组 LLM 路由的 Filter。

优点是天然支持 Kubernetes 部署、服务网格集成、mTLS。缺点是门槛高，不适合没有云原生经验的团队。Star 数只有个位数，基本算是实验性项目。

我的建议是倒着想：先搞清楚你的痛点是什么。

如果痛点是"接口不统一"：LiteLLM 就够了。它的模型覆盖最广，SDK 级别的适配做得最细。性能不够再换。

如果痛点是"延迟和吞吐"：直接上 Bifrost。Go 的性能天花板高，部署简单，占用资源少。

如果痛点是"缺一个内部 AI 平台"：Portkey 是最接近开箱即用的选择。预算充足可以直接用 SaaS 版。

如果你已经有 Envoy/Istio：看一眼 Envoy Model Router，能省不少胶水代码。

还有一个现实的选项：不用开源网关，直接用商业 API 聚合平台。聚合平台本身就是一个网关，统一接口、负载均衡、计费、监控都替你做了。如果你不想自己运维这层基础设施，这可能是最省事的路。

别跳过压测。网关加的每一毫秒延迟，在用户端都会被放大。上线前用真实流量模型跑一遍，别只看 Hello World 的 Benchmark。
日志要结构化。网关是所有调用的必经之路，在这里做统一日志是最划算的。但日志格式一开始就要想好，后面改很痛。
Key 管理比你想的重要。网关会持有所有上游 API Key。这些 Key 怎么存、怎么轮换、怎么审计，不是小事。
回退策略要测。配了"OpenAI 挂了自动切 Claude"很容易，但两个模型的输出格式、Token 计算方式不一样，下游代码能不能无缝切换？这得实际验证。
版本锁定。上游 API 随时可能改协议。今天能跑的 adapter，明天可能因为 OpenAI 加了个新参数就报错。网关的版本更新要跟紧上游，但也别盲目升级。

相关项目链接