LiteLLM
免费
LiteLLM 是 BerriAI 维护的开源 AI Gateway 与 Python SDK，面向 100+ LLM Provider 提供 OpenAI 兼容接口、代理网关、虚拟密钥、预算控制、负载均衡、回退、日志与 MCP Gateway 能力，适合把多模型调用治理成统一基础设施。
LiteLLM 的核心参数与统计
LiteLLM 的官方定位是开源 AI Gateway：用 OpenAI 格式调用 100+ LLM Provider，并通过 Proxy Server 把认证、成本、路由、负载均衡、日志和管理面集中在一个网关层。它不负责训练模型，也不是面向终端用户的聊天产品；核心价值在于让工程团队把多模型调用从“散落在各业务服务里的 SDK 代码”治理成统一基础设施。
| 项目 | 公开信息 |
|---|---|
| 产品形态 | Python SDK、Proxy Server / AI Gateway、企业托管与自托管 |
| 官方仓库 | BerriAI/litellm |
| 公开版本 | v1.89.2（2026-06-18，GitHub Releases / PyPI） |
| Provider 覆盖 | 官方 README 描述为 100+ LLMs |
| API 兼容 | OpenAI format / OpenAI-compatible errors |
| 网关能力 | Virtual keys、spend tracking、guardrails、load balancing、admin dashboard |
| 支持端点 | Chat Completions、Responses、Embeddings、Images、Audio、Batches、Rerank、Messages 等 |
| 社区规模 | 约 50,971 stars、9,019 forks（GitHub API，2026-06-21） |
| 代码语言 | Python 为主 |
| 开源许可 | GitHub API 未给出 SPDX 标识；仓库存在 LICENSE 文件，具体条款以仓库实时文件为准 |
定位边界：LiteLLM 更像“模型访问控制层”，不是 RAG 框架、Agent 编排框架或模型训练平台。它适合解决多 Provider 接入、密钥隔离、预算治理和可观测性问题；如果只调用一个模型、没有团队预算和审计需求，直接使用官方 SDK 的复杂度更低。
LiteLLM 的用户与市场认可
LiteLLM 的市场认可主要来自开发者社区和基础设施采用信号。GitHub API 显示 BerriAI/litellm 拥有约 50,971 stars、9,019 forks，说明它已经进入主流 LLMOps 与 AI Gateway 工具栈讨论范围。仓库 README 还展示了 OSS adopters，包括 Stripe、Google ADK、Greptile、OpenHands、Netflix、OpenAI Agents SDK 等标识或名称；这类信息说明其接口兼容与网关治理能力已被多个工程生态关注，但具体部署规模、合同客户数和收入未公开。
社区信号：超过 50K stars 对基础设施项目而言意味着较强的外部验证，尤其是 Provider 适配类项目需要持续处理 API 差异、错误类型、鉴权方式和模型命名变化。高 fork 数也表明团队自托管、二次开发和企业内部分支需求较多。
采用前提：LiteLLM 的价值随模型供应商数量、业务团队数量和预算治理需求上升而上升。单应用、单 Provider 的小团队可能感受不到网关层收益；拥有多团队、多 key、多云模型和成本归集需求的组织更容易获得回报。
LiteLLM 的成本优势：把模型费用从黑盒调用变成可治理账本
LiteLLM 不直接降低底层模型单价，它的成本优势来自“统一入口 + 预算与路由控制”。当多个团队同时使用 OpenAI、Anthropic、Bedrock、Vertex AI、Azure OpenAI 或本地推理服务时，网关可以把调用记录、虚拟 key、团队预算、回退策略和成本归集放到同一层，减少重复接入与失控消耗。
C 端/个人：个人开发者可使用开源 SDK 或本地 Proxy，软件本身可免费试用，主要成本来自所调用的底层 LLM API、服务器资源和维护时间。若只是本地脚本调用，LiteLLM 的价值在于统一 Provider 写法和异常处理。
API/开发者：开发团队的显性成本仍是模型 API 费用，隐性成本是多 Provider SDK 维护、错误处理、日志接入和 key 管理。LiteLLM 通过 OpenAI 兼容格式、Router、callbacks 和虚拟 key 降低重复工程量，适合把模型接入沉淀成公共服务。
企业/私有化：企业版涉及 SSO、SCIM、OIDC、RBAC、审计日志、企业支持、托管 Proxy 或自托管部署等条款，公开页面以联系销售为主，最终价格、SLA 与部署责任边界以官方实时报价和合同为准。
| 成本层级 | 费用构成 | LiteLLM 的作用 |
|---|---|---|
| 开源本地使用 | 底层 LLM API、服务器、运维 | 统一 Provider 接口与异常处理 |
| 团队网关 | Proxy 运行资源、数据库、日志系统、模型调用 | 预算、虚拟 key、团队归集、路由 |
| 企业采购 | 企业授权、支持、SSO/SCIM/OIDC、审计、托管服务 | 规模化治理与合规能力 |
LiteLLM 的主要功能
LiteLLM 的功能不是围绕模型能力本身，而是围绕“调用入口治理”展开。
- OpenAI 兼容统一接口：业务代码可用 OpenAI 格式调用 100+ Provider，减少因供应商 SDK 差异导致的迁移成本。
- Proxy Server / AI Gateway：把模型调用集中到一个服务入口，便于统一鉴权、日志、预算和团队策略。
- Virtual Keys：用 LiteLLM 管理面签发虚拟 key，避免直接把上游 Provider key 分发给业务团队。
- Spend Tracking 与预算控制：按 key、用户、团队或项目追踪消耗，适合做成本归集和配额管理。
- Router、Retry 与 Fallback：在不同模型或部署之间配置路由、重试和回退，降低单供应商故障对业务的影响。
- Load Balancing：在多个部署之间分摊请求，适合 Azure/OpenAI 多部署或多区域场景。
- Guardrails 与日志回调：通过回调与第三方观测系统连接，把安全策略、审计和实验数据接入现有平台。
- Admin Dashboard：提供团队、key、预算、Provider 与使用记录的可视化管理入口。
- MCP Gateway：官方 release notes 已展示团队级 MCP Tools 控制视觉，表明其网关边界从 LLM API 扩展到 Agent 工具访问治理。
这些功能的验收重点不是“能否发出一次请求”，而是高并发、失败回退、预算封顶、日志完整性和权限隔离是否能在真实业务链路里稳定运行。
LiteLLM 的模型与版本演进
LiteLLM 的演进可以看成三条主线：SDK 统一调用、Proxy 网关治理、企业与 Agent 工具治理。
SDK 与统一调用阶段
- 2023-07-27：GitHub 仓库创建，项目以 Python SDK 方式统一不同 LLM Provider 的调用格式。这个阶段的核心价值是“少写供应商适配代码”。
Proxy Server 与 AI Gateway 阶段
- 2024-2025：README 与文档逐步把 LiteLLM 定位为 AI Gateway，能力扩展到 virtual keys、spend tracking、load balancing、guardrails、admin dashboard。它从库变成了可部署的模型访问控制层。
企业治理与 MCP Gateway 阶段
- v1.78.0（2025-09-12）：官方 release notes 展示 MCP Gateway 的团队级工具控制视觉，说明 LiteLLM 开始把 MCP tools、vector stores、成员权限和 logging settings 纳入同一治理界面。
- v1.89.2（2026-06-18）：GitHub Releases 与 PyPI 当前公开版本，显示项目仍在高频发布。生产环境应固定稳定版本、使用官方稳定镜像策略，并在 staging 中验证 Provider、日志回调和预算规则。
LiteLLM 的技术优势
兼容层机制：LiteLLM 把不同 Provider 的认证、模型命名、请求参数、响应结构和异常类型转换为统一格式。效果是业务代码更容易保持稳定，适合需要在 OpenAI、Anthropic、Gemini、Bedrock、Vertex AI、Azure OpenAI 与本地模型之间切换的团队。
网关集中治理：Proxy Server 将模型调用从应用代码中抽离出来，统一处理 key、预算、团队、日志和路由。效果是平台团队可以横向治理所有 AI 应用，而不是逐个服务追查模型消耗。
路由与回退机制：Router 支持多个部署之间的 retry、fallback 与 load balancing。效果是在供应商限流、区域故障或模型价格变化时，团队可以通过配置调整流量，而不必立刻改业务代码。
观测与安全连接：callbacks、guardrails、logging settings 与 admin dashboard 让模型调用进入常规工程监控链路。效果是请求、成本、延迟和失败原因可追踪，适合需要审计与成本复盘的企业环境。
代价与约束：网关层会增加部署、升级、数据库、网络延迟和策略维护成本。LiteLLM README 提到 1k RPS 下 8ms P95 latency 的 benchmark 信号，但真实延迟仍取决于部署环境、网络路径、日志回调和上游 Provider 响应。
如何使用 LiteLLM
LiteLLM 有两种主路径：作为 Python SDK 嵌入应用，或作为 Proxy Server 部署成团队级 AI Gateway。
| 使用方式 | 入口 | 适合场景 | 关注点 |
|---|---|---|---|
| Python SDK | pip install litellm / PyPI |
单应用、多 Provider 快速接入 | Provider key、异常处理、成本记录 |
| Proxy Server | litellm[proxy]、Docker、Helm |
多团队统一网关 | 数据库、master key、虚拟 key、日志、预算 |
| Enterprise / Hosted Proxy | 官方企业入口 | 企业治理、托管、SSO、审计 | SLA、数据边界、支持响应、合同条款 |
| MCP Gateway | 官方文档与 release notes | Agent 工具访问控制 | 工具权限、团队隔离、日志完整性 |
典型落地路径可以分三步。第一步用 SDK 或本地 Proxy 跑通 2 到 3 个 Provider 的同一业务请求，验证 OpenAI 兼容格式能否覆盖参数需求。第二步把团队 key、预算和日志接入 Proxy，检查消耗归集是否准确。第三步再扩展 Router、fallback、guardrails、SSO 与 MCP Gateway，避免一开始就把所有治理项压到生产链路。
LiteLLM 的产品定价
LiteLLM 的公开商业结构可分为开源使用、团队自托管和企业服务三层。开源 SDK 与 Proxy 可免费使用，底层模型 API 费用由所连接的 Provider 收取；企业版、托管 Proxy、SSO、SCIM/OIDC、支持服务和 SLA 等以官方实时页面与销售合同为准。
- 开源层：适合个人开发者和小团队，用于统一模型调用与本地验证。显性软件订阅成本为 $0，实际成本来自模型 API、机器资源和维护。
- 团队自托管层：适合已经有平台工程能力的组织。成本包括数据库、网关运行、日志系统、监控、升级和内部支持。
- 企业层：适合需要 SSO、SCIM、OIDC、RBAC、审计日志、托管服务或专属支持的组织。公开页面通常要求联系销售，具体价格未公开。
定价评估不能只看软件价格。LiteLLM 的收益应与多 Provider 接入工时、预算失控风险、模型切换成本和日志审计成本一起衡量。
LiteLLM 的应用场景
- 多模型统一入口：AI 平台团队为多个业务线提供统一
base_url和虚拟 key，业务侧保持 OpenAI 兼容调用，平台侧统一配置上游 Provider 与模型路由。 - 成本治理与预算封顶：企业按团队、项目、用户或 key 追踪调用费用，设置预算和配额，减少共享 Provider key 导致的账单不透明。
- 高可用模型路由：在 OpenAI、Azure OpenAI、Bedrock、Vertex AI 或本地模型之间做 fallback 和 load balancing，降低单点供应商故障影响。
- 合规与审计：将 LLM 请求、响应、延迟、错误、成本和用户归属纳入日志系统，便于安全审计和问题复盘。
- Agent 工具治理：通过 MCP Gateway 和团队权限管理，把 Agent 可调用工具纳入访问控制，避免工具权限随业务代码扩散。
每个场景都需要验证关键系统：Provider 凭证管理、日志脱敏、失败重试策略、预算生效时的用户体验，以及回退模型带来的输出质量差异。
LiteLLM 的适用人群
- AI 平台与基础设施团队：需要把多业务线模型调用统一到一个网关，关注成本、权限、可用性和审计。
- 后端工程团队：需要减少供应商 SDK 差异，保持 OpenAI 兼容接口，同时保留切换 Provider 的余地。
- 企业安全与财务团队：需要看清谁在调用什么模型、花了多少预算、是否触达权限边界。
- Agent 平台团队：需要把 MCP 工具、vector store、成员权限和日志策略纳入团队级控制。
不适配边界也很明确：单人项目、单模型调用、极低延迟敏感链路、或没有运维能力的团队，不一定需要引入网关层。对于强监管行业，LiteLLM 只是治理组件之一，仍需单独确认数据驻留、日志脱敏、密钥轮换、供应商合规和企业合同条款。
LiteLLM 的总结与展望
LiteLLM 的核心竞争力在于把“多模型接入”升级为“模型访问治理”。它用 OpenAI 兼容格式降低业务接入成本，用 Proxy Server、virtual keys、budget、Router、logging 和 admin dashboard 支撑团队级治理，再通过 MCP Gateway 向 Agent 工具权限扩展。对于已经有多 Provider、多团队和成本审计需求的组织，它能成为 AI 应用基础设施中的关键控制点。
当前限制主要集中在四点：第一，开源许可的 SPDX 标识未能通过 GitHub API 明确识别，最终条款需以仓库 LICENSE 文件为准；第二，企业价格、托管服务细项和 SLA 未公开，需商务确认；第三，网关层会带来额外部署与运维复杂度；第四，Provider API 变化频繁，生产环境必须建立版本冻结、回归测试和日志审计流程。
落地建议是先从低风险业务流量试点：选取两个以上 Provider、一个统一业务接口、一个团队预算和一套日志回调作为最小闭环，验证调用成功率、P95 延迟、成本归集准确率和 fallback 触发行为。试点稳定后，再扩展到企业 SSO、SCIM/OIDC、MCP Gateway 和跨团队权限治理。
版本信息
- LiteLLM v1.89.2 ：GitHub Releases 与 PyPI 均显示的当前公开版本，延续 LiteLLM AI Gateway、Proxy Server、Provider 适配与企业治理能力的高频迭代。
- LiteLLM v1.88.3 ：v1.89.x 前一日发布的稳定版本，反映项目在 Provider 兼容、代理稳定性与网关治理上保持密集补丁节奏。
- LiteLLM v1.78.0 ：官方 release notes 公开的版本节点，包含 MCP Gateway 与团队级工具控制相关产品视觉，显示 LiteLLM 从 LLM Proxy 扩展到 Agent 工具治理。
- LiteLLM GitHub 公开仓库 ：GitHub 仓库创建时间，公开项目以 Python SDK 与 OpenAI 兼容多 Provider 调用为基础，随后演进为 Proxy Server 与 AI Gateway。
用户评价