LiteLLM 详解：统一 100+ 大模型的开放 AI 网关

项目里一旦接了两家以上的大模型，麻烦就来了：每家一套 SDK、一套鉴权、一套流式协议，成本与配额还各管各的。BerriAI/litellm（LiteLLM）为此而生：它是一个开源 AI 网关，用 OpenAI 格式统一调用 100 多家 LLM 提供商，既能当 Python 库直接用，也能部署成集中式网关，自带虚拟密钥、花费追踪、负载均衡与护栏。Y Combinator W23 项目，约 56.4k Star。本文从两种形态、快速上手到生产特性，完整拆解。

1、项目概述

LiteLLM 自我定位是"最快、最轻的 AI 网关"——Rust 内核 + Python SDK，官方口径 1k RPS 下 P95 延迟仅 8ms。它解决的核心问题只有一个：把 100+ 家模型提供商收进一个统一接口，全部说 OpenAI 的"方言"。

基本面：

- 约 56.4k Star、10.6k Fork、4.3 万次提交，Y Combinator W23

- 两种形态：Python SDK（进程内调用）与 Proxy Server（集中式网关）

- 统一端点：/chat/completions、/responses、/embeddings、/images、/audio、/batches、/rerank 等

- 文档地址 docs.litellm.ai，另有企业版（商业许可：SSO、专属支持、SLA）

2、两种形态：SDK 与网关怎么选

LiteLLM 的能力分两层，选型取决于团队规模与治理需求。

两种形态：

- Python SDK：import 即用，代码里一行切换提供商，适合个人与小团队

- Proxy Server（AI 网关）：独立部署的服务，所有应用打它一个地址，适合多团队、多项目统一治理

选型建议：

1. 只是想在代码里统一多家模型调用 → SDK 足够

2. 需要集中管密钥、按项目 / 用户算成本、加护栏 → 上网关

3. 两者可平滑过渡：先用 SDK 起步，治理需求出现后再加网关

3、安装与 SDK 快速上手

官方推荐 uv 安装；SDK 的核心就一个 completion 函数，模型名用"提供商/模型"的统一格式。

// 安装 SDK
uv add litellm

// 安装代理服务器
uv tool install 'litellm[proxy]'

from litellm import completion
import os

os.environ["OPENAI_API_KEY"] = "your-openai-key"
os.environ["ANTHROPIC_API_KEY"] = "your-anthropic-key"

// 调 OpenAI
response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Hello!"}])

// 调 Anthropic：只改模型名，其余代码一字不动
response = completion(
    model="anthropic/claude-sonnet-4-20250514",
    messages=[{"role": "user", "content": "Hello!"}])

上手要点：

1. 一个 completion 函数通吃所有提供商，换模型只改字符串

2. 模型名统一为"提供商/模型名"格式，如 openai/、anthropic/ 前缀

3. 各家密钥仍走环境变量，SDK 内部完成协议翻译

4. 请求与响应都是 OpenAI 格式，已有代码几乎零改造

4、统一 100+ 提供商

覆盖面是 LiteLLM 的护城河：从云端大厂到本地推理，主流几乎全数在列。

提供商清单（节选）：

- 云端大厂：OpenAI、Anthropic、Azure（含 Azure AI）、AWS Bedrock、Google Vertex AI、Gemini

- 平台与聚合：Mistral、Cohere、Groq、DeepSeek、xAI、Perplexity、Together、Fireworks、OpenRouter

- 企业与数据栈：Databricks、Snowflake、SageMaker、Nvidia NIM、Watsonx

- 本地与自建：Ollama、vLLM、HuggingFace，另有 Jina、Voyage、Cerebras 等专项能力商

统一的价值：

1. 不再为每家学一套 SDK、维护一套适配层

2. 新提供商上线通常是加一行模型名，而非一轮开发

3. 供应商故障时切换成本低，天然利于多供应商策略

5、网关部署与 OpenAI 兼容调用

代理模式一条命令起服务，之后所有客户端用标准 OpenAI SDK 打网关地址即可。

// 启动网关（默认端口 4000）
litellm --model gpt-4o

import openai

// 客户端不需要 litellm，标准 OpenAI SDK 即可
client = openai.OpenAI(api_key="anything", base_url="http://0.0.0.0:4000")

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "Hello!"}])

部署要点：

1. litellm --model 一条命令起网关，适合本地与开发环境

2. 客户端用原生 OpenAI SDK 指向 base_url 即可，业务代码零依赖

3. 生产部署官方支持 Docker（-stable 标签经 12 小时压测）、Terraform 模块与 Helm

4. 镜像用 Cosign 签名，可验证来源；云上可选 ECS Fargate、Cloud Run 等模块

6、生产特性：密钥、成本、负载与护栏

网关模式的价值在治理：把"谁能用、花多少、走哪条路、守什么规矩"集中管起来。

开箱的生产能力：

- 虚拟密钥：为项目 / 用户 / 团队签发独立密钥，集中鉴权与回收

- 花费追踪：按项目、按用户统计成本与用量，多租户各自对账

- 负载均衡与重试回退：Router 在多个部署间分流，失败自动切备用

- 护栏（guardrails）与缓存：按项目定制内容策略与响应缓存

- 管理面板：自带 Admin Dashboard，可视化看用量与配置

- 日志回调：对接 Langfuse、MLflow、Lunary 等观测平台

治理要点：

1. 真实提供商密钥只留在网关，业务侧只用虚拟密钥

2. 给每个项目设预算上限，超支自动熔断

3. 跨 Azure / OpenAI 等多部署配 fallback，提高可用性

7、路由与代理生态

除了基础转发，LiteLLM 还内置了面向代理（Agent）时代的两个能力。

扩展能力：

- Router：SDK 与网关都可用的智能路由，跨部署重试、回退、分流

- A2A 代理调用：/a2a 端点支持代理间互调协议

- MCP 工具桥接：把 MCP 工具接入 SDK 与网关，代理可统一调用

- 企业版（商业许可）：SSO 单点登录、专属 Slack / Discord 支持、定制 SLA

生态位置：

- 与客户端聚合工具互补：Cherry Studio 把多模型收进一个桌面端，LiteLLM 把多模型收进一个服务端

- Headroom 等压缩层的省钱面板也基于 LiteLLM 统计口径

- 已成为多数团队做多供应商 LLM 架构的默认网关选择

8、总结

LiteLLM 是 BerrAI 开源的统一 AI 网关，56.4k Star、YC W23，Rust 内核 + Python SDK，宣称 1k RPS 下 P95 仅 8ms。它以 OpenAI 格式统一 100+ 提供商——从 OpenAI、Anthropic、Azure、Bedrock 到 Ollama、vLLM；SDK 一个 completion 函数换模型只改字符串，网关一条命令起服务、原生 OpenAI SDK 直连，并自带虚拟密钥、多租户花费追踪、负载均衡、护栏与管理面板，企业版再加 SSO 与 SLA。

落地建议：个人与小团队先用 SDK，一行代码统一各家调用；多项目、多团队的组织部署网关，把密钥收敛到虚拟密钥、按项目核算成本、配好回退与护栏。对于要做多供应商 LLM 架构的团队，把 LiteLLM 当默认网关层，是控制成本、提升可用性的必要基建。

LiteLLM 详解：统一 100+ 大模型的开放 AI 网关