LiteLLM：把 100+ 模型服务商收成一个接口

接入多家模型服务商这件事，麻烦程度和接入家数成正比。

每家的 SDK 不一样、认证方式不一样、请求体格式不一样、错误类型不一样、限流策略不一样。你要在业务代码里为每家写适配层，还要处理"这家挂了自动切那家"的容错逻辑。等到要加第五家的时候，那堆代码已经没人愿意动了。

LiteLLM 的目标就是把这一层收掉。官方定位：开源 AI 网关，为 100+ LLM 提供统一接口，支持自托管，企业可用，用 OpenAI 格式调用任何模型。

它有两种用法，这是理解它的关键：既可以作为 Python SDK 直接在代码里调用，也可以部署成 AI 网关（Proxy Server），作为团队或组织的集中式服务。

每接一家，就多一套代码

一个性能数字，值得单独看

README 里列了一组信息，其中有一条很具体：

1k RPS 下 P95 延迟 8ms

并且给了基准测试的链接。

这个数字值得琢磨。每秒 1000 请求、95% 的请求在 8 毫秒内完成——说明网关层本身引入的开销很小。

为什么这个指标重要？因为引入网关最常见的顾虑就是"多一层转发会不会变慢"。如果网关本身吃掉几百毫秒，那它对所有请求都是净损失。8ms 这个量级意味着，相比调用模型的实际耗时（通常几百毫秒到几秒），网关的引入基本可以忽略。

当然，这是官方公布的基准，测试条件需要看基准页面。但至少它敢给出这个量级的数字并附上复现方式。

两种形态，两种场景

Python SDK 的用法非常直接：

from litellm import completion

# OpenAI
response = completion(model="openai/gpt-4o", messages=[...])

# Anthropic
response = completion(model="anthropic/claude-sonnet-4-20250514", messages=[...])

注意这里的设计：同一套 completion 函数，通过模型名前缀来区分服务商。密钥从环境变量读。换成另一家的模型，只需要改 model 字符串。

这是它"drop-in OpenAI compatibility"的具体体现——已有的 OpenAI 调用代码，改一下模型名就能切到别家。

AI Gateway（Proxy Server） 则是把这个能力做成一个服务，团队共享。README 里列的网关能力包括：

  • Virtual keys（虚拟密钥）——给每个使用者或项目发一把独立密钥，而不是把上游真实密钥散出去
  • 费用追踪（spend tracking）
  • 护栏（guardrails）
  • 负载均衡
  • 管理面板

这四项对应的是团队使用时最实际的四个问题：密钥怎么发、钱花了多少、内容要不要拦、流量怎么分。

支持的端点

README 列出的端点覆盖面比很多人以为的宽：

/chat/completions、/responses、/embeddings、/images、/audio、/batches、/rerank、/a2a、/messages 等。

不只是对话。嵌入、图像、音频、批处理、重排都有对应端点。这意味着它可以作为整个 AI 能力的统一入口，而不只是聊天网关。

值得单独说的是 /a2a——这是 Agent-to-Agent 协议的端点。说明它在跟 Agent 生态的标准往前走。/messages 是 Anthropic 风格的接口形态。

关于采用者

README 里有一个"OSS Adopters"（开源采用者）区块，开头列的是 Netflix。

这类信息通常被当成营销素材，但它的实际参考价值在另一面：能出现在大型企业的技术栈里，说明项目在稳定性、可运维性、社区响应上过了某个门槛。玩具项目不会有这种采用者。

当然，具体到你的场景，还是要看自己的压测结果。

先有统一网关，再谈多模型策略

什么规模该上网关

这句话不是绝对的，但可以作为一个判断参考：

单人使用没必要上网关。SDK 就够了，多一层服务是纯粹的开销。密钥在自己手里，不用管配额分配。

小团队可以开始考虑。当有两个以上的人、两把以上的 key、需要知道"上个月花了多少钱"的时候，集中管理就开始有价值了。

多项目、多环境基本需要。开发、测试、生产各自的密钥和预算要分开；不同项目要用不同模型；某家服务商挂了不能影响业务——这些需求会自然把网关变成必选项。

企业级则是刚需。虚拟密钥、配额、审计、护栏，这些在合规和成本管理上是硬要求。

需要澄清一个常见误解：网关不是只有"多供应商"场景才需要。即使你只用一家，虚拟密钥、费用追踪、防护栏这些能力也依然有用。

适合谁用

要接多家模型的团队。这是它最直接的价值——一次接入，后面加供应商只改配置。

需要控制 AI 成本的团队。费用追踪和配额管理是控制成本的起点，没有这两个，支出基本是黑盒。

已有代码基于 OpenAI 接口的项目。迁移成本接近零。

想让 Agent 工具链统一走一个入口的开发者。多模态端点 + A2A 支持，让它可以作为能力总线的角色。

不太适合：

  • 单一项目、单一模型的个人开发者。直接调用官方 SDK 更简单，少一层故障点。
  • 对延迟有极致要求的场景。虽然官方基准显示开销很小，但自建网关仍然增加了一层需要运维的组件。
  • 没有运维能力的团队想完全自托管企业级功能。README 也提到有托管版本和企业版，可以根据团队能力选择。

项目地址： https://github.com/BerriAI/litellm 官方文档： https://docs.litellm.ai

本文依据项目官方仓库 README 整理编写。文中性能数据为官方公布口径，实际表现请以自己的场景实测为准。