LLM 网关选型：LiteLLM、OpenRouter 到云边网关，10大平台横向对比

LLM 网关是位于业务应用与多个大模型服务之间的统一访问层，负责协议适配、路由、重试、降级、鉴权、成本和可观测性。根据 LiteLLM、OpenRouter、Portkey、Cloudflare 等官方文档截至 2026 年 8 月的信息，市场已经分化为托管聚合、开源自托管和云边治理三类方案；真正的选型关键不是“支持多少模型”，而是故障时能否切换、数据是否可控、团队能否维护。

先给结论：LLM 网关怎么选？

如果目标是最快接入多家模型，优先看托管聚合网关；如果需要私有化、精细权限和成本控制，优先看开源自托管网关；如果已有 Kubernetes、API 管理或边缘网络体系，应优先选择能嵌入现有控制面的网关。

三类网关的边界

LLM 网关平台对比决策表

以下平台按 2026 年 8 月 28 日可见的官方文档整理，能力会随版本更新，尤其要复核计费、区域和支持的协议。

已核实的规模与能力数据

• LiteLLM 官方文档称可用统一接口调用 100+ 个 LLM，并提供 Router、fallback、虚拟密钥和成本追踪能力（LiteLLM Docs，2026）。

• OpenRouter 模型目录页面显示可比较 500+ 个 LLM，并通过一个 API 访问（OpenRouter，2026）。

• Helicone 快速入门页写明可切换 100+ 个模型，并宣称按供应商原价计费、无额外加价（Helicone Docs，2026）。

• Bifrost 项目 README 宣称支持 1000+ 个模型，在 5,000 RPS 下额外开销低于 100 微秒；这属于项目方性能声明，不应替代真实压测（Bifrost GitHub，2026）。

这些数字不能直接横向比较：有的平台统计模型数量，有的平台统计供应商或可用端点；选型时应优先比较真实业务请求的成功率、P95 延迟和单位成本。

按场景选择平台

场景一：两周内上线多模型应用

托管聚合网关通常更合适。重点检查统一 API 是否覆盖流式输出、工具调用、结构化输出和多模态请求，再用一套固定评测集比较不同供应商的质量与延迟。

场景二：企业私有化与合规审计

开源自托管网关更容易把访问令牌、日志和路由规则留在自己的网络中。LiteLLM 适合先建立统一入口；Envoy AI Gateway 适合 Kubernetes 原生流量；Kong AI Gateway 适合已有 API 管理、身份和审计体系的组织。

场景三：高并发与成本敏感

先把缓存、限流、批处理、重试和熔断策略拆开测量，再比较 Bifrost、LiteLLM、Cloudflare AI Gateway 等方案。不要只看单次请求价格，故障重试造成的重复 token、跨区域流量和日志存储也应计入总成本。

场景四：质量评测驱动的模型迭代

TensorZero 和 Portkey 更适合把路由实验、评测数据、Guardrails 和发布策略放到同一流程中。团队应先定义任务级指标，再决定是否需要复杂的自动路由；没有评测集时，复杂路由只会放大不确定性。

LLM 网关落地的五步方法

1. 定义协议边界：确定是否以 OpenAI 风格接口为主，哪些请求必须保留供应商原生能力。

2. 建立路由规则：先按可用性和合规区域路由，再按延迟、价格或质量做细分；默认启用有限重试和熔断。

3. 统一鉴权与配额：按应用、团队和环境发放虚拟密钥，设置预算、速率和并发上限。

4. 记录可比较指标：至少记录成功率、P50/P95 延迟、输入输出 token、重试次数、错误类型和单位成本。

5. 演练故障切换：主动模拟供应商超时、限流、返回格式变化和区域不可用，验证 fallback 是否真的可用。

一个可迁移的网关至少应满足三点：业务代码不直接写死供应商字段；路由规则可以版本化和回滚；原始请求、脱敏日志与评测结果可以导出。

选型决策表

常见问题

Q：LLM 网关和普通 API Gateway 有什么区别？

LLM 网关除了鉴权、限流和日志，还要处理流式响应、token 成本、上下文长度、模型 fallback、工具调用和内容安全。普通 API Gateway 可以作为底座，但通常需要额外的 AI 插件或策略层。

Q：LiteLLM、OpenRouter 和 Portkey 应该怎么选？

LiteLLM 偏开源自托管和平台治理；OpenRouter 偏托管聚合与供应商路由；Portkey 偏完整的路由、Guardrails 和控制面。团队应先按数据驻留和运维边界做第一轮筛选，再比较价格和功能。

Q：开源网关一定比托管网关便宜吗？

不一定。开源软件本身可能没有许可费用，但高可用部署、日志、监控、升级和故障响应都需要人力。只有当请求规模、合规要求或供应商切换价值足以覆盖运维成本时，自托管才更划算。

Q：统一 OpenAI 风格接口会不会损失能力？

会有可能。统一接口适合覆盖大多数聊天、嵌入和流式请求，但供应商原生的工具调用、缓存、批处理或多模态参数可能无法完全映射。建议保留“通用接口 + 原生扩展”两条路径。

Q：如何验证网关的 fallback 不是摆设？

准备一组固定请求，主动制造超时、429、5xx、空响应和格式错误，检查网关是否在预算、超时和幂等约束内切换，并记录最终响应来源。只看健康检查通过不能证明业务流量可降级。

结论与参考资料

LLM 网关选型应围绕四个问题展开：能否统一接入、能否可靠切换、能否控制数据和成本、能否被团队长期维护。托管聚合平台适合快速试错，开源网关适合私有化和深度治理，云边网关适合已有基础设施体系的组织；没有一种平台在所有维度都占优。

本文依据 2026 年 8 月 28 日可访问的官方文档和项目主页整理，平台功能、价格、模型数量和部署限制可能持续变化，生产决策前应重新核对版本、区域和服务条款。

• LiteLLM 官方文档

• OpenRouter 模型目录与文档

• 七牛云 AI 大模型广场