开源 LLM 网关项目解决什么问题

LLM 网关不是“再包一层 API”这么简单。它把多供应商接口、路由、密钥、限流、预算和调用日志集中到一个边界；只有这些问题真实存在时，新增网关才值得。

两个项目代表两条路径

LiteLLM以 Python 生态中的统一 SDK/Proxy 为核心，强调多模型兼容、路由、预算与管理能力。Envoy AI Gateway建立在 Envoy/Kubernetes 网关思路上，更适合已有平台与流量治理基础的团队。前者偏应用接入，后者偏基础设施控制面。

LiteLLM 证据卡

• 技术栈：Python 为主，包含 SDK、Proxy 与管理相关组件。
• 发布：Releases用于锁定版本；仓库 tests/CI 展示维护者的自动化资产。
• 文档与 demo：官方文档和 proxy 示例说明统一接口、路由、预算等入口。
• 许可：开源部分采用 MIT，但仓库存在 enterprise 目录和商业功能边界；必须按使用文件与部署能力核对，不能把整个产品笼统标为 MIT。
• 上手预算：先用一小时在单模型前加代理，验证错误与日志；多模型路由另开阶段。

Envoy AI Gateway 证据卡

• 技术栈：Go、Envoy 与 Kubernetes/Gateway API 生态。
• 发布：Releases、测试/CI 与仓库状态可用于版本审计。
• 文档与 demo：docs和 examples/manifests 展示部署入口。
• 许可：Apache-2.0，仍需检查依赖与部署镜像。
• 上手预算：已有 Kubernetes/Envoy 经验的团队可先做半天概念验证；没有平台基础时不适合作为第一个网关练习。

网关真正解决的五件事

统一接口减少供应商差异；路由与回退处理可用性和策略；限流保护预算和下游；密钥管理避免凭证散落；日志把模型、用户、延迟、token、成本和错误关联起来。任何一项都需要业务规则，安装项目不会自动生成正确策略。

一句话解读：网关集中的是治理责任，不只是请求地址。

假设客服草稿和内部摘要两个应用共用网关：客服要求稳定的结构化输出，摘要允许降级到便宜模型。上游服务超时时，客服不能悄悄换成不支持同一 schema 的模型，摘要却可以在日志中标记降级后继续。网关若只有一条全局 fallback 规则，就没有真正表达业务差异。

这个场景还要求身份跟随请求。日志至少能回答哪个应用、哪个租户、走了哪条路由、为何回退、花费归到哪里；密钥轮换时两个应用不应同时停机。验证这些问题后，团队才能说网关在治理。只把 OpenAI 风格路径换成代理地址，得到的是兼容层，不是完整网关收益。

最小试用步骤

先让一个现有应用通过网关调用同一模型，比较加入前后的错误码、超时和日志；再增加备用模型，故意制造上游失败；最后验证预算或限流触发时用户看到什么。没有故障注入，回退能力只停留在配置文件。

公开证据不等于生产证明

Release 说明项目发布过版本，tests 说明仓库有验证资产，docs/demo 说明维护者提供了使用路径。它们不能证明高并发、计费准确、供应商兼容或故障恢复已在你的环境通过。本文核验日期为 2026-07-15，未报告虚构压测结果。

何时不需要网关

只有一个模型、调用量小、应用自身已经能处理密钥和日志时，直接 SDK 更少故障面。若团队没有人维护集中入口，网关可能把局部问题升级成全局单点。

常见失败：把回退写成“换个模型继续”

两个模型即使都支持聊天接口，结构化输出、工具调用、上下文长度、错误码和内容策略也可能不同。只配置备用模型，不验证契约，主模型超时后可能得到格式正确但业务语义不同的结果。网关返回 200，并不等于应用完成任务。

另一个失败是所有应用共用一个网关身份。这样虽然密钥集中，租户额度、审计和撤销却失去边界。试用时必须给两个调用方不同身份，分别触发限流和撤销，确认一个租户的问题不会耗尽另一个租户的预算。

替代方案与是否值得投入

少量应用可以先做一个内部模型适配模块，统一错误、日志和密钥读取；已有 API Gateway 的团队也可以先扩展现有流量治理，而不是另起平台。LiteLLM 适合应用团队快速验证供应商兼容与预算路由，Envoy AI Gateway 适合已经用 Kubernetes、Envoy 和 Gateway API 的平台团队。没有对应基础时，后者的学习成本本身就是主要风险。

当模型供应商超过一个、调用方超过一个，且密钥轮换、额度或审计已经反复出现时，网关值得投入。若需求只是“以后可能换模型”，先保留应用层接口即可，不要提前制造全局依赖。

选择建议

应用团队先用 LiteLLM 的最小 Proxy 验证统一接口；已有 Kubernetes 网关治理的平台团队再评估 Envoy AI Gateway。最终选择应由现有运维能力决定，不由功能清单长度决定。

上线前检查清单

确认应用身份如何传到网关、供应商密钥由谁轮换、租户额度如何隔离、日志是否包含敏感提示、回退是否改变模型能力、网关故障时应用如何降级。LiteLLM 和 Envoy AI Gateway 都要用相同故障用例验证，不能只比较正常请求。

迁移边界

统一 API 会隐藏供应商差异，也可能掩盖结构化输出、工具调用和错误码的不兼容。迁移时保留供应商特有能力清单，并为关键调用做契约测试。网关可以减少接入代码，无法保证模型行为互换。

运维归属必须在试用前写清。应用团队负责业务路由规则，平台团队负责网关可用性，财务或运营负责人确认额度策略，安全团队审查密钥和日志。若所有问题最后都落到“网关管理员”，集中治理会变成集中等待。还要演练网关自身故障：应用是拒绝请求、绕过直连还是进入只读降级，必须由业务风险决定，不能临时手工切换。

最后保存一张迁移清单：哪些接口完全兼容，哪些能力仍绑定供应商，哪些调用不能回退，以及撤掉网关时应用如何恢复直连。只有可进入也可退出，网关才是可控基础设施，而不是新的锁定点。

上线评审还要指定网关配置的变更流程。路由、额度和回退规则都属于生产代码，应有版本、审查、灰度与回滚，不能在管理界面里无记录修改。