如果你曾经同时对接过OpenAI、Anthropic、Google Gemini和Amazon Bedrock这几家的API，大概会对一件事深有体会——每家厂商的接口格式、鉴权方式、错误码、流式响应结构都不太一样，切换模型往往意味着要重写一遍调用代码。LiteLLM要解决的正是这个痛点。它把这些五花八门的接口，全部包装成OpenAI风格的统一格式，让开发者用一套代码就能调用一百多家厂商、一千八百多个模型。
这个项目诞生于2023年7月，由YC W23孵化的创业公司BerriAI主导开发，如今在GitHub上已经收获了超过5.6万颗星、上万次分支，社区活跃度相当高。它已经不只是一个开发者玩具，Netflix、NVIDIA、Okta、Zapier这些公司都在生产环境里用它来管理AI基础设施。
🧭 LiteLLM到底是什么
用最朴素的话来说，LiteLLM是一个AI网关（AI Gateway）。它站在你的应用和各家大模型服务商之间，做三件事——统一格式、统一管理、统一观测。
它的核心引擎最近做了一次重要升级，从纯Python转向了Rust核心加Python SDK的组合架构，官方给自己的定位是"最快、最轻量的AI网关"。Rust负责处理高并发下的性能瓶颈，Python则保留了原有的易用性和生态兼容性，这种混合架构在追求性能的基础设施类项目里越来越常见。
LiteLLM提供两种使用形态，适合不同角色的团队，具体差异可以看下表。
| 维度 | Python SDK | Proxy Server（AI网关） |
|---|---|---|
| 使用场景 | 直接嵌入Python代码库 | 独立部署的中心化服务 |
| 目标用户 | 开发者，构建LLM应用 | 平台团队、AI赋能团队 |
| 核心能力 | Router重试与故障转移、成本追踪、异常统一处理 | 鉴权与权限、多租户计费、虚拟密钥、管理后台UI |
| 部署方式 | pip install litellm直接导入 | Docker容器或云平台一键部署 |
两者共享同一套底层逻辑，只是暴露的形式不同——SDK面向代码集成，Proxy面向组织级的集中治理。
🏗️ 整体架构一图看懂
LiteLLM的架构可以用下面这张图来概括，请求从应用侧发出，经过网关层的一系列处理后，才真正抵达具体的模型提供商。
flowchart TB
A[你的应用 / Agent / 开发者] -->|OpenAI格式请求| B[LiteLLM 网关]
B --> C{鉴权与虚拟密钥}
C --> D{预算与限流检查}
D --> E{护栏 Guardrails}
E --> F[Router 路由决策]
F -->|负载均衡| G1[OpenAI]
F -->|负载均衡| G2[Anthropic]
F -->|负载均衡| G3[Amazon Bedrock]
F -->|负载均衡| G4[Google Vertex AI]
F -->|失败自动切换| G5[备用模型组]
G1 --> H[统一格式响应返回]
G2 --> H
G3 --> H
G4 --> H
G5 --> H
H --> I[日志 / 计费 / 可观测性]
I --> A
这张图里藏着LiteLLM最核心的价值——它把复杂的多厂商适配逻辑，全部下沉到网关这一层，应用侧完全不需要关心背后到底调用的是哪家模型。
🔧 核心功能模块逐一拆解
统一接口，一套格式打天下
LiteLLM最基础也是最重要的能力，是把各家的输入输出都翻译成OpenAI的Chat Completions格式。不管你调用的是/chat/completions、/embeddings、/images还是/audio，返回的结构都是一致的。
举个例子，下面这段Python代码展示了最基本的调用方式。
from litellm import completion
import os
os.environ["OPENAI_API_KEY"] = "your-api-key"
response = completion(
model="openai/gpt-5",
messages=[{"content": "Hello, how are you?", "role": "user"}]
)
如果想换成Anthropic的Claude，理论上只需要把model参数改成anthropic/claude-sonnet-4-5，其余代码几乎不用动。Okta的一位架构师就提到过这种切换体验——换后端模型只是配置文件里改一行，不需要动代码，也不用走一遍安全评审流程。
对于像GPT-5、o3这类支持推理链的新一代模型，LiteLLM还专门提供了responses()接口，可以单独取出模型的思考过程和最终答案。
from litellm import responses
response = responses(
model="gpt-5-mini",
messages=[{"content": "What is the capital of France?", "role": "user"}],
reasoning_effort="medium"
)
print(response.choices[0].message.content) # 最终回答
print(response.choices[0].message.reasoning_content) # 推理过程
Router，让请求学会自己找活路
如果说统一格式解决的是能不能调的问题，Router解决的就是调得稳不稳的问题。LiteLLM的Router模块专门负责在多个模型部署之间做负载均衡、失败重试、冷却和故障转移。
它的运作逻辑大致是这样——你可以给同一个模型能力配置多个后端部署，比如同时挂着Azure的GPT-4实例和OpenAI官方的GPT-4实例，Router会根据延迟、错误率等指标动态分配流量。一旦某个部署连续报错达到设定的重试次数，Router会自动把请求切到下一个可用的模型组，这个过程叫做Fallback。
sequenceDiagram
participant App as 应用
participant Router as LiteLLM Router
participant M1 as 主力模型（Azure GPT-4）
participant M2 as 备用模型（OpenAI GPT-4）
App->>Router: 发起请求
Router->>M1: 转发请求
M1-->>Router: 超时 / 报错
Router->>Router: 达到num_retries上限
Router->>M2: 自动切换至备用模型组
M2-->>Router: 返回成功响应
Router-->>App: 统一格式返回结果
更细一点的机制里还有优先级分层（order）的概念——每一层重试次数用尽后才会降级到下一层，所有层级都失败才会真正报错。这套设计对于生产环境的稳定性来说很关键，毕竟没人希望因为某个云厂商临时抽风就导致整个应用瘫痪。
虚拟密钥与多租户治理
对于平台团队而言，LiteLLM Proxy最有价值的地方在于它把权限管理这件麻烦事标准化了。管理员可以为不同的团队、项目或应用创建虚拟密钥（Virtual Keys），每个密钥可以单独设定可访问的模型范围、预算上限和速率限制。
从官网展示的管理后台截图能看到，一个典型的密钥管理界面会列出密钥归属团队、最近活跃时间、以及当前花费相对预算的比例，甚至能标记出哪些密钥已经被限流或过期。这种颗粒度的控制，对于一个可能有几十个团队同时在用AI能力的大公司来说几乎是刚需。
预算控制与费用追踪
AI调用的账单往往是笔糊涂账，尤其是团队一多，谁在用什么模型、花了多少钱很容易失控。LiteLLM内置了细致的Spend Tracking能力，可以按项目、按用户、按团队维度分别统计支出，并支持设置软硬预算上限。
NVIDIA的产品团队评价说，LiteLLM给了工程师们一种统一、一致的方式去接入超过一百个模型端点，这背后其实就是计费和权限系统在支撑，否则光是接口统一是不够的，真正让平台团队敢放心开放访问权限的，是背后这套可控可审计的费用体系。
缓存、护栏与安全策略
除了路由和计费，LiteLLM还内置了几个偏治理属性的模块。
- 缓存（Caching）支持OpenAI和Anthropic的Prompt Caching机制，重复或相似的请求可以直接命中缓存，省去真实调用的开销
- 护栏（Guardrails）可以在请求进出网关时做内容审查、敏感信息过滤等策略拦截，一共细分了8个子模块
- 策略模板（Policies）允许把一组规则打包复用，避免每个团队都重复配置一遍安全策略
Admin UI 与 MCP网关
LiteLLM自带一套可视化的管理后台，涵盖密钥管理、端点管理、模型列表、团队与成员管理等模块，非技术背景的运营或财务人员也能直接在界面上查看花费和调整预算，不需要写一行代码。
比较新的一个方向是MCP网关能力——MCP（Model Context Protocol）是近来Agent生态里很火的一种工具调用协议，LiteLLM把Jira、GitLab、GitHub这些MCP服务器也接入到了同一个网关背后，意味着不只是模型调用，连Agent要用到的外部工具访问也能统一走一套鉴权和日志体系。这对于正在探索Agent落地的团队来说是个挺实用的补充。
📊 谁在用，用来解决什么问题
从官网列出的客户案例能大致看出LiteLLM的典型应用场景，整理如下表。
| 公司 | 反馈要点 |
|---|---|
| Netflix | 新模型发布后通常一天内就能上线给用户使用，节省了数月的对接工作量 |
| NVIDIA | 工程师获得统一、一致的方式访问超过100个模型端点 |
| Okta | 切换后端模型只需改配置，无需代码变更或走安全评审流程 |
| Lemonade | 简化了管理多个LLM模型的复杂度 |
这些反馈其实都指向同一个诉求——大模型迭代速度太快了，业务团队不想每次都被绑死在某一家供应商的接口细节上。LiteLLM相当于在应用和模型之间垫了一层缓冲垫，让上层业务逻辑可以尽量少地感知底层模型的变化。
🚀 快速上手路径
如果你想亲自跑起来试试，大致的路径是这样的。
作为SDK直接使用，装包之后几行代码就能跑通，非常适合个人项目或者快速验证想法。
uv add litellm
作为独立网关部署，官方提供了Docker、Render、Railway等多种一键部署方案，也支持在AWS、GCP上用云端Shell直接拉起。部署完成后，通过config.yaml来声明你要接入哪些模型、设置什么样的路由策略和预算规则。
model_list:
- model_name: gpt-5
litellm_params:
model: openai/gpt-5
api_key: os.environ/OPENAI_API_KEY
- model_name: claude-sonnet
litellm_params:
model: anthropic/claude-sonnet-4-5
api_key: os.environ/ANTHROPIC_API_KEY
配置好之后，代理会在本地或服务器上暴露一个兼容OpenAI SDK的HTTP端点，任何原本用OpenAI SDK写的代码，把base_url指向这个代理地址，几乎不用改动就能跑起来。
💡 写在最后
LiteLLM能在短短两三年内积累这么大的用户基数，核心原因大概不是它做了什么特别炫酷的技术创新，而是它精准地卡在了一个所有做AI应用的团队都会撞上的真实痛点——多模型接入的碎片化成本。无论是个人开发者图省事用SDK，还是大公司平台团队用Proxy来做集中治理，它提供的都是同一套哲学，把复杂性收敛到一层，让上层专注于业务本身。
如果要给还在纠结要不要引入这类网关层的团队一点建议，可以按团队规模简单判断——单人或小团队项目，直接用Python SDK就够了，几乎零成本；一旦涉及多团队、多项目共享AI资源，或者需要对费用和权限做精细管控，Proxy Server模式带来的治理价值就会迅速体现出来。
