开源 LLM Gateway 选型指南：四个项目对比与五个决策点（2026）

「开源」到底改变了 LLM Gateway 的哪几件事

LLM Gateway（大模型网关）位于你的应用与一个或多个模型供应商之间。它统一请求格式、把每次调用路由到某个供应商，并承担这次调用周边的运维工作——密钥、重试、故障转移、限流、缓存、日志与花费统计。

选开源方案会改变三件事，而这三件里哪几件对你成立，值得先说清楚：

流量在哪里落地。 自托管意味着 prompt 与模型返回都经过你自己运行的基础设施。对有数据驻留合规要求、或内部明令禁止走第三方代理的团队，这一条通常就是整个决策的全部理由。
你能改什么。 路由逻辑、自定义鉴权、按团队的预算控制、一段定制的脱敏处理——这些都变成可直接改的代码，而不是提给厂商的需求单。
你从此要运维什么。 这一条最常被低估。网关处在每一次模型调用的关键路径上。自托管意味着它的可用性、升级节奏，以及凌晨三点的故障，都归你。

如果你还没确定自己到底需不需要网关，建议先看什么是 LLM API Gateway、什么时候才需要它——本文默认你已经回答了「需要」。

四个值得进候选名单的项目

开源这一侧已经收敛。四个选项覆盖了绝大多数真实部署。

LiteLLM

采用最广的开源 LLM 代理，也是从零到跑起来最快的一条路。它的核心优势是供应商覆盖面——一百多家供应商统一暴露成 OpenAI 兼容接口，意味着不管后面接的是谁，你的客户端代码只需要说一种协议。

代价在运行时。LiteLLM 是 Python 实现，在高并发压力下，代理层本身会成为延迟预算里可测量的一部分。多数中等流量的团队永远不会碰到这个问题；但如果它在高吞吐的在线链路上，这是第一个该压测的点。

适合： 供应商覆盖面是首要诉求，或者你想今天下午就把代理跑起来。

Portkey Gateway

MIT 协议，故障转移、重试与 guardrails 都在开源内核里，而不是圈在付费档之后。它由托管产品起家、后来把网关组件开源，这一点在设计上看得出来——路由与可靠性原语比自然生长出来的代理更成体系、也更有主张。

它还带语义缓存，按 prompt 相似度而非字符串完全相等来命中。这能不能真省钱，完全取决于你的流量重复度有多高；厂商公布的节省百分比当营销话术看即可，真正该做的是先测你自己的缓存命中率。

适合： 你希望故障转移链、重试、guardrails 是一等公民级别的配置项。

Envoy AI Gateway

基于 Envoy 构建，Apache 2.0 协议。这是已经把 Envoy 和 Kubernetes 作为标准栈的团队的选择——它继承了你本来就在跑、在监控、也知道怎么排障的那一层代理。

这里的理由主要是组织性的而非技术性的。如果平台团队本来就运维 Envoy，加一个 AI 专用 filter，比引入一个全新的 Python 服务（连带它自己的部署方式和自己的值班面）要小得多。

适合： Kubernetes 与 Envoy 已经是团队标准，网关不该成为例外。

Kong 与 Apache APISIX 的 AI 插件

两个成熟 API 网关现在都带 AI-proxy 插件层。逻辑与 Envoy 那条一样：如果其余流量本来就走某个 API 网关，把模型调用也走它，能让鉴权、限流、可观测性留在一个地方而不是两个。

适合： 你已经在运维其中之一，且希望只有一个网关而不是两个。

真正决定选型的五个问题

在这个品类里，功能对照表几乎没用——每个项目列的名词都一样。真正能把它们区分开的是下面五个问题。

1. 你的延迟预算是多少，压测过没有？ 网关会多一跳。问题是在你的并发下，这一跳是 3 毫秒还是 40 毫秒。用真实的报文大小与真实并发压测之后再定；每秒 10 个请求下没问题的运行时，到每秒 500 时未必还行。

2. 你真正需要几家供应商？ 团队常常按「支持 100+ 供应商」筛选，最后上线只用了两家。如果你只需要两家，覆盖面就不是区分点，该把权重换到运行时性能与可运维性上。

3. 它部署在哪里？ 一个 Python 服务、一个 Kubernetes filter、一个可部署到边缘的 worker，是三种完全不同的运维负担。正确答案几乎总是「和你其余基础设施待在同一个地方」。

4. 这个项目说的「可观测性」具体指什么？ 这个词从「一份请求日志」到「按团队的 token 核算与成本归属」都能覆盖。如果你需要按团队分摊成本，请直接验证这项能力是否存在，而不是相信那一行 bullet。成本归属是实际能力最常比宣传单薄的一项。

5. 谁给它值班？ 网关在每一次模型调用的关键路径上。如果「它挂了谁被叫醒」这个问题答不上来，那就是一个论据——要么选平台团队本来就在运维的那个，要么选托管端点。

自托管真实的代价

软件是免费的，你要付出的东西不是：

可用性。 从此模型调用成功与否，你是其中一个原因。冗余与故障切换要你自己建。
升级。 供应商 API 会变。得有人盯着这些变化并把更新发出去。
密钥保管。 供应商密钥现在存在你的基础设施里。这往往正是目的——但它同时也是一份你已经接下的密钥管理责任。
排障。 延迟突刺时，「是供应商还是我这一跳」这个问题归你回答。

以上都不构成反对自托管的理由。它们只是要求你把这些成本诚实地计入对比，而不是把「开源」直接当成「免费」。

什么时候托管端点是更好的答案

当你需要控制力时——对数据路径、路由逻辑或部署位置的控制——自托管网关值这个价。当你真正需要的其实只是一个稳定的、已经在说你的工具所期待的那套协议的 OpenAI 兼容端点时，它值的就少得多。

如果你的诉求更接近「把 Claude Code 或 OpenAI SDK 指向一个能用的端点，然后继续干活」，那么一个托管的 OpenAI 兼容 API 可以把整个运维面去掉。ROIBest AI 提供 OpenAI 协议端点，改一行 base URL 即可配合既有客户端使用，无需部署和维护网关。无论选哪条路，都建议先弄清账单到底被什么推高，免得优化错了层。

说句实在的：网关是基础设施。在你有一个它能解决的问题时才引入它，而不是因为这个品类存在。

常见问题

开源 LLM Gateway 是免费的吗？ 协议是免费的，运行成本不是——算力、值班投入、升级维护都是真实开销。要比的是总成本与托管端点的对比，而不是许可费的对比。

以后还能换网关吗？ 通常可以，这也是这个品类一个真实的加分项。如果你候选名单里的项目都暴露 OpenAI 兼容接口，你的应用代码就与这次选择隔离开了，换网关是改配置而不是重写。

只用一家供应商，还需要网关吗？ 往往不需要。只有一家供应商、又没有路由、故障转移或按团队核算的需求时，网关只是加了一跳和一个运维面，换不来对应的好处。等你加第二家供应商、或需要花费归属时再重新评估。

只是想先评估，从哪个开始？ 从 LiteLLM 开始，理由很实际：它立起来最快——这让它成为一种低成本的方式，去发现你真正需要什么。把第一次部署当成探针，而不是定论。

自托管是不是意味着我的 prompt 就私密了？ 它意味着 prompt 不再经过第三方代理。它们仍然会发到模型供应商，适用该供应商的数据条款。自托管网关缩小了参与方的范围，但没有把供应商从这个范围里移出去。