LiteLLM：一个 SDK 调用 100+ 大模型的统一网关

选型前先抽根烟：90 个 SDK 统一到 1 个，听起来很美，但怎么选？

你的代码库里已经有 3 个 OpenAI SDK 的封装、2 个自写的重试逻辑、还有一堆因为模型厂商涨价被迫迁移的临时补丁。
现在老板说"接入 DeepSeek 试试"，你意识到又要写一套新的 provider adapter。为了不让未来的每个人重复造轮子，你想做一个 LLM 网关——然后打开 GitHub 搜索，发现同样是做"统一调用"的方案从 SaaS 到开源代理有十几种。
选错网关的代价比想象中大：锁死在一套协议上换不掉。所以这篇文章只回答一个问题：按你的实际情况，该选哪家。

竞品全景

直接对标"LLM 统一网关"的知名方案主要有三个：LiteLLM、Portkey、OpenRouter，加上一个边界略有差异的 MLflow AI Gateway（现在叫 Generative AI Gateway）。

LiteLLM：SDK + 代理双形态的开源网关

Python 优先，也提供 OpenAPI 兼容的 REST / 代理网关模式。核心卖点不是某个厂商连接器，而是把 100+ 家的请求、重试、成本统计、集成商切割成统一的 AI SDK 接口。嵌入运行和独立部署皆可，Apache 2.0 协议。

Portkey：带可观测性的企业级 SaaS 网关

更偏"治理和控制平面"：流量路由、缓存、限流、追踪、护栏。开源版本（MIT）是 core library，但完整能力绑定其 SaaS 平台。AI 应用开发时如果团队持续集成和快速调试更重要，Portkey 的 dashboard 体验领先。

OpenRouter：聚合市场的托管 API

完全 SaaS，不是可自建的网关。它把多个模型的访问聚合在一个 API key 后面，核心优势是流量灵活性：负载均衡、按价格/能力路由。但数据要经过 OpenRouter，合规门槛高的团队直接出局。

MLflow AI Gateway：MLOps 玩家顺手的扩展

MLflow 生态的网关模块，适合已经用 MLflow 做实验追踪的团队，但模型覆盖面和更新速度明显慢于专业网关，更接近"顺手用"而非核心平台。

对比维度

以下维度按选型中的权重排序：协议统一度（决定迁移成本）、部署模式（决定合规边界）、企业与治理功能（决定生产可能性）、模型覆盖与更新速度（决定长期可用性）、社区与商业后盾（决定踩坑时能不能自救）。性能方面，由于各家都有网关转发逻辑，未做基准测试前不做硬性比较。

核心对比表

深度分析

差异一：协议"统一"到什么程度

LiteLLM 的关键设计是用 OpenAI SDK 作为统一基准，厂商差异全部收敛在底层 adapter。换成 DeepSeek 或 Gemini，你只需要改 model 和 api_key：

from litellm import completion

resp = completion(
    model="deepseek/deepseek-chat",  # 前缀决定厂商
    messages=[{"role": "user", "content": "hello"}],
    fallbacks=["openai/gpt-4o-mini", "claude/sonnet"],  # 自动 fallback
)
print(resp.choices[0].message.content)

而 OpenRouter 也是"OpenAI 兼容"，但它本质是帮你代发请求，不是代码库。如果你希望网关是一个进程、一个配置了 fallback 策略的组件，LiteLLM 的形式更有优势。

差异二：治理和控制能力的边界

Portkey 把可观测性做到引擎层面：一次的 prompt 延迟、token 成本、多级的缓存策略，在 SaaS 后台开箱即用。LiteLLM 也提供 cost tracking 和 budget 管理，但和 Portkey 的可视化、追踪体感差距明显。

但是——如果你们有数据合规审计要求，Portkey SaaS 带来的效率优势会被安全问题抵消。要控制平面能力，选 Portkey 开源版；要开发体验又不介意自己补监控，选 LiteLLM。

差异三：模型的"活着"程度

OpenRouter 声称聚合了很多模型，但它的商业模式是流量加价和路由；如果你需要的是一个随时能切到"用户没听过但便宜 50%"冷门模型的机会，LiteLLM 的 provider 列表更新节奏（每周都有新增）比 MLflow 这类 MLOps 平台的模块快得多。
MLflow 网关更适合用它做 MLflow 内部路由，而非面向生产的多模型策略中心。

按场景选型

• 场景：团队是 Python 背景，想要一个轻量库而不是体量庞杂的平台 → 选 LiteLLM，按需引 SDK，不需要微服务。
• 场景：运维团队需要可观测性和流量精细控制，倾向托管服务 → 选 Portkey SaaS。
• 场景：数据不能出私有网络，必须有网关独立部署 → 选 LiteLLM 或 Portkey 开源版分开部署；前者轻、后者更全。
• 场景：只想做一次性评测、快速试几个模型，不建长期系统 → 选 OpenRouter 注册个 key 就行，不要基础设施。但注意不要在生产使用。

结语

我的明确推荐：在多数生产场景里，优先选 LiteLLM。理由不是它功能最全——恰恰相反，它比 Portkey 轻，也没有 OpenRouter 的流量套利模式，但它兼顾了三种关键约束：
一是协议以 OpenAI SDK 为兼容基准，让团队现有代码迁移成本最低；二是Apache 2.0 自托管，架构上不会因为商业服务商策略变动而被迫调整；三是模型覆盖广且更新快，意味着它不会成为你换模型的瓶颈，而是各模型之外的一层"语义适配层"。

如果你的团队更依赖"一屏看全观测数据和流量追踪"的开发体验，且数据边界允许 SaaS，Portkey 更适合你们。
如果你的需求只是"临时用一个服务调用几个大模型测效果"，OpenRouter 最快——但请在做好锁死准备的前提下用，不要神话它。

一句话收尾：LiteLLM 是那个你能拿源码、改逻辑、塞进自家部署环境还不跑偏的基础设施；Portkey 是那个 UI 更好看但边界在别人手里的平台；OpenRouter 是那个用一个 key 换来多个模型的便利工具。先明确边界再选工具。