我们评估了13个用于生产的LLM网关。以下是我们的发现

Source: Dev.to

为什么我们需要它

我们的团队在 Maxim 构建 AI 评估和可观测性工具。
我们与运行 生产 AI 系统 的公司合作，反复出现同一个问题：

“我们应该使用哪个 LLM 网关？”

于是我们决定真正去测试它们——而不是仅仅阅读文档或查看 GitHub 星标。
我们在 13 种不同的 LLM 网关 上运行 真实的生产工作负载，并测量实际表现。

我们测试了什么

我们从 五个维度 评估网关：

• 性能 – 延迟、吞吐量、内存使用
• 功能 – 路由、缓存、可观测性、故障转移
• 集成 – 在现有代码中嵌入的难易程度
• 成本 – 定价模型及隐藏费用
• 生产就绪度 – 稳定性、监控、企业功能

测试工作负载

• 持续 500 RPS 流量
• GPT‑4 与 Claude 请求混合
• 真实的客户支持查询

结果（实话实说）

Tier 1：大规模生产就绪

1. Bifrost (我们自己开发的——但请听我们解释)

我们构建 Bifrost 是因为没有其他方案能满足我们的规模需求。

优点

• 在我们的测试中最快（~11 µs 额外开销，5K RPS）
• 内存使用极其稳固（~1.4 GB 在负载下保持不变）
• 语义缓存真正起作用
• 自适应负载均衡会自动降低性能下降的键的权重
• 开源（MIT 许可证）

缺点

• 社区规模小于 LiteLLM
• 基于 Go（性能好，但对仅使用 Python 的团队来说上手更难）
• 与老工具相比，提供商集成较少

最适合：高吞吐量生产环境（500+ RPS），优先考虑性能和成本效率的团队

2. Portkey

强大的商业产品，具备完善的企业功能。

优点

• 出色的可观测性 UI
• 良好的多提供商支持
• 可靠性特性（回退、重试）
• 企业级支持

缺点

• 随着使用量增长，价格快速上升
• 平台锁定
• 相比开源工具有一定的延迟开销

最适合：希望获得全托管解决方案的企业

3. Kong

拥有 LLM 插件的 API 网关巨头。

优点

• 经过实战检验的基础设施
• 大量插件生态系统
• 企业功能（认证、速率限制）
• 多云支持

缺点

• 对 LLM 特定工作流的设置较为复杂
• 如果仅需要 LLM 路由，功能有点过剩
• 学习曲线陡峭

最适合：已经在使用 Kong 并希望添加 LLM 支持的团队

Tier 2：大多数用例的良好选择

4. LiteLLM

最受欢迎的开源选项。我们在 Bifrost 之前使用过它。

优点

• 社区庞大
• 支持几乎所有提供商
• 对 Python 友好
• 入门容易

缺点

• 在约 300 RPS 以上会出现性能问题（我们正是遇到的）
• 内存使用随时间增长
• 高负载下 P99 延迟会出现尖峰

最适合：原型开发、低流量应用（P50）

评估标准

• 总成本（而非标价） – 基础设施 + LLM 使用费 + 工程时间 + 锁定成本。
• 可观测性 – 能否调试故障、延迟和费用？
• 可靠性 – 故障转移、速率限制、自动恢复。
• 迁移路径 – 以后能否离开？能否自托管？

我们的建议

• 大多数刚起步的团队：先用 LiteLLM → 后期迁移
• 高速增长的初创公司：从第一天起使用 Bifrost 或 Portkey
• 企业级用户：Portkey 或 Kong
• 对成本敏感的团队：Bifrost（开源）或 Helicone（侧重可观测性的方案）