BerriAI/litellm 是什么？

LiteLLM 用 OpenAI 格式统一了 100 多个 LLM 提供商的调用方式，既提供 Python SDK 也提供可自托管的代理服务器。本文基于仓库与文档，拆解它的机制、上手路径和真正该警惕的地方。

BerriAI/litellm 可以商用吗？

请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。

BerriAI/litellm 还在维护吗？

在维护。仓库在最近一天内有新的提交。

BerriAI/litellm 是用什么编程语言写的？

主要是 Python（依据 GitHub 的语言统计）。

LiteLLM 评测：OpenAI 格式统一 100+ LLM 的网关方案

Q: BerriAI/litellm 还在维护吗？

在维护。仓库在最近一天内有新的提交。

秒懂

它是什么？: LiteLLM 用 OpenAI 格式统一了 100 多个 LLM 提供商的调用方式，既提供 Python SDK 也提供可自托管的代理服务器。本文基于仓库与文档，拆解它的机制、上手路径和真正该警惕的地方。
适合谁用？: LiteLLM 适合那些已经在用 OpenAI SDK、但需要对接多个供应商或自建内部网关的团队。它不适合只有单一模型、且不愿引入额外代理层的项目。
能商用吗？: 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
还在维护吗？: 在维护。仓库在最近一天内有新的提交。
用什么语言写的？: 主要是 Python（依据 GitHub 的语言统计）。

以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。

开源项目深度解析

Hysen Labs 编辑部 · 2026年8月8日 · BerriAI/litellm

它解决的是多供应商调用的碎片化问题

做 AI 应用的人很快会遇到同一个麻烦：OpenAI 用一套请求格式，Anthropic 用另一套，Bedrock 又要走 AWS 的签名。每个 SDK 有自己的错误类型和重试逻辑，代码里写满 if-else。LiteLLM 的做法是把这些全部收拢成一个 OpenAI 兼容的接口。你在代码里写 model="openai/gpt-4o" 或 model="anthropic/claude-sonnet-4-20250514"，剩下的格式转换、认证、错误归一化都由它处理。这不是一个 SDK 包装那么简单，它同时提供了代理服务器模式，让团队可以共享一个网关，而不是每个人各自维护一份供应商配置。

两种使用方式，机制完全不同

LiteLLM 有两条使用路径。第一条是 Python SDK，直接在进程内调用 completion 函数，适合单个应用快速接入。第二条是代理服务器，用 uv tool install 'litellm[proxy]' 安装后运行 litellm --model gpt-4o，它会起一个监听 4000 端口的服务。这个代理把 OpenAI 客户端指向 base_url="http://0.0.0.0:4000" 就能用，密钥随便填，真正的供应商密钥在服务器端配置。代理模式的核心价值在于集中管理：虚拟密钥、成本追踪、负载均衡、guardrails 都在这一层实现。SDK 模式没有这些功能，它只是个轻量转换层。README 里提到的 8ms P95 延迟，指的是代理模式的基准测试，但具体测试条件没有给出，不能直接套用到你自己的环境。

上手：从 SDK 到代理的完整路径

最直接的开始是安装 SDK，README 给的命令是 uv add litellm。然后设置环境变量 OPENAI_API_KEY 和 ANTHROPIC_API_KEY，调用 completion 时用 provider/model 的格式指定模型。代理模式需要先安装：uv tool install 'litellm[proxy]'，然后启动 litellm --model gpt-4o。启动后，任何支持 OpenAI 格式的客户端都能接入，README 里用 openai 库做示例，base_url 指向 4000 端口。如果要部署到云上，README 提供了 Render、Railway、AWS CloudShell、GCP CloudShell 的一键部署链接。这里要注意，代理模式的完整配置，比如虚拟密钥怎么生成、成本追踪怎么开，README 只给了链接，实际细节在 docs.litellm.ai/docs/simple_proxy 里，需要自己去看。

不止聊天：A2A 与 MCP 扩展了网关的边界

LiteLLM 没有停留在聊天补全上。README 展示了 A2A 协议支持，可以用 A2AClient 连接远程 agent，也能把 agent 挂到代理服务器上，通过 /a2a/my-agent 这样的路径访问。MCP 方面，它提供了 experimental_mcp_client，能把 MCP 服务器的工具加载成 OpenAI 格式，然后交给任何 LiteLLM 支持的模型使用。这意味着网关不只是转发请求，还充当了工具调用的适配层。但注意 experimental 这个前缀，说明 MCP 支持还没稳定，生产环境用它要谨慎。A2A 协议本身还在演进，LiteLLM 能同时支持协议版本 1.0 和 0.3，这既是灵活性也是兼容性负担。

真正的限制：代理是新的单点故障

LiteLLM 把复杂度集中到了网关，这带来了运维风险。代理服务器一旦挂了，所有下游模型的调用都会断。README 提到负载均衡和 guardrails，但没说明高可用部署的具体方案，比如多实例怎么同步状态、虚拟密钥怎么共享。成本追踪依赖代理正确记录每次调用的 token 数和价格，如果供应商返回的用量字段不标准，追踪可能不准。另外，它支持 100+ 提供商，但每个提供商的认证方式差异很大，Bedrock 需要 AWS 凭证，Azure 需要特定的 API 版本，这些配置在 README 里只是一笔带过。如果某个新模型不在支持列表里，你可能要等社区更新，或者自己写扩展。

和直接调 SDK 相比，代价是什么

替代方案不是另一个网关，而是直接使用各供应商的官方 SDK。比如只用 Anthropic 的话，直接装 anthropic 包，不需要任何中间层。这个差异很实际：直接调 SDK 延迟最低，没有额外的网络跳转，也没有代理的配置和维护成本。LiteLLM 的代理模式引入了网络开销，虽然 README 声称 8ms P95，但那是基准测试，真实环境取决于你的网络和部署位置。SDK 模式没有代理开销，但它只解决格式统一，不提供成本追踪和负载均衡。所以选择很简单：单供应商、低延迟优先，就绕开 LiteLLM；多供应商、需要集中管控，才值得引入。

维护成本与许可证的未知数

这个仓库的活跃度很高，最后推送是 2026 年 8 月，版本号已经到 v1.100.0-dev.2，说明迭代非常快。快意味着新功能多，但也意味着 API 可能变动，升级时要注意兼容性。默认分支叫 litellm_internal_staging，这暗示开发流程是内部 staging 再合入主分支，对外发布走 rc 和 dev 版本。许可证字段是 unknown，这是个问题。README 自称 open source 和 enterprise-ready，但具体是 MIT、Apache 还是其他，仓库元数据没写。企业采用前必须去 GitHub 仓库的 LICENSE 文件确认，否则法律风险不明。维护成本上，代理模式需要监控、日志、备份，这些 README 都没提，得靠团队自己搭。

编辑结论

LiteLLM 适合那些已经在用 OpenAI SDK、但需要对接多个供应商或自建内部网关的团队。它不适合只有单一模型、且不愿引入额外代理层的项目。部署前先验证三件事：你的目标供应商在支持列表里且认证方式符合预期，代理服务器的虚拟密钥与成本追踪逻辑满足你的审计要求，以及你接受网关本身成为新的故障点。如果这些都能确认，LiteLLM 能省去大量 SDK 适配工作；如果其中任何一条存疑，直接调用供应商 SDK 反而更简单。

官方来源

社区笔记