1. LiteLLM 项目概述
LiteLLM 是 BerriAI 团队开发的一个开源项目,采用 MIT 许可协议,目前在 GitHub 上已经获得了超过 28,000 颗星。这个项目的核心使命是为开发者提供一个统一的 OpenAI 格式接口,通过这个接口可以接入 100 多家大型语言模型(LLM)提供商的服务。简单来说,它就像是一个万能适配器,让开发者不用再为每家厂商 API 的不同而头疼。
想象一下,你是一个开发者,需要同时使用 OpenAI、Anthropic 和阿里云的通义千问等多个模型。如果没有 LiteLLM,你需要为每个模型学习不同的 API 调用方式、处理不同的返回格式、实现不同的错误处理机制。而有了 LiteLLM,你只需要学会一种调用方式,就能轻松使用所有这些模型。
这个项目可以用一个简单的公式来概括:LiteLLM = 统一 LLM 入口 + 智能路由 + 成本治理 + 可观测性。它不仅仅是一个简单的 API 包装器,还提供了企业级的管理能力,包括用量监控、成本控制、负载均衡等功能。目前已经有不少知名企业在生产环境中使用 LiteLLM,比如 Netflix、Lemonade 和 Rocket Money 等。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. LiteLLM 的核心架构
2.1 Python SDK(嵌入式模式)
Python SDK 是 LiteLLM 最轻量级的使用方式,适合个人开发者或快速原型开发。你只需要通过 pip 安装 litellm 包,就能在 Python 代码中直接调用各种模型。
安装非常简单:
bash复制pip install litellm
使用示例:
python复制from litellm import completion
import os
# 调用 OpenAI 的 GPT-4o 模型
response = completion(model="openai/gpt-4o",
messages=[{"role": "user", "content": "你好"}])
# 调用 Anthropic 的 Claude Sonnet 模型
response = completion(model="anthropic/claude-sonnet-4-20250514",
messages=[{"role": "user", "content": "你好"}])
# 调用本地运行的 Ollama 模型
response = completion(model="ollama/llama2",
messages=[{"role": "user", "content": "你好"}],
api_base="http://localhost:11434")
这种方式的优点是简单直接,不需要额外部署服务,特别适合快速验证想法或小型项目。但它的缺点也很明显:每个应用都需要单独管理 API 密钥和配置,缺乏集中管控能力。
2.2 Proxy Server / LLM Gateway(独立网关模式)
对于企业级应用,更推荐使用 LiteLLM Proxy 模式。这是一个独立的 HTTP 服务,监听在 4000 端口(默认),所有客户端应用都统一访问这个网关,由它负责鉴权、路由、计费和日志记录等工作。
架构示意图:
code复制应用层 (OpenAI SDK / 任意 HTTP 客户端)
↓ POST /v1/chat/completions
LiteLLM Proxy (port 4000)
↓ 路由 / 负载均衡 / 计费
[OpenAI] [Azure] [Qwen] [Ollama] [vLLM] ...
在生产环境中,LiteLLM Proxy 通常以容器形式部署(Docker、Kubernetes、AWS ECS/EKS 等),使用 PostgreSQL 持久化配置数据(如模型列表、API 密钥、预算设置、团队信息等),还可以选用 Redis 实现分布式限速。前端可以加负载均衡器实现高可用。
这种架构的优势在于:
- 集中管理所有模型访问
- 统一鉴权和授权
- 跨项目/团队的用量追踪
- 支持多语言客户端(不仅仅是 Python)
3. SDK 与 Gateway 的核心区别
下表清晰地展示了两种使用方式的差异:
| 维度 | Python SDK | LLM Gateway (Proxy) |
|---|---|---|
| 运行位置 | 应用进程内 | 独立微服务 |
| 共享性 | 单应用使用 | 多应用共享同一入口 |
| 鉴权管理 | 各应用各自持有密钥 | 集中统一管理密钥,应用只拿 Virtual Key |
| 计费追踪 | 单应用内 | 跨项目/团队/用户多维度追踪 |
| 适用场景 | 个人开发者、快速 POC | 平台团队、多部门企业 |
| 运维负担 | 无额外服务 | 需维护 Proxy 服务本身 |
| 支持语言 | Python | 任何语言(HTTP REST) |
选择 Gateway 可以获得集中鉴权与授权、多租户成本追踪与预算管理、Virtual Key 访问控制、管理后台 UI 等企业级功能。而选择 SDK 则适合直接嵌入 Python 代码库,包含 Router 重试/fallback 逻辑和应用级负载均衡。
简单判断标准:如果你的团队里有多个业务方需要使用 LLM,就用 Gateway;如果是个人项目或单一服
