LiteLLM 是什么？一站式调用 100+ 大模型的统一接口工具
如果你最近在做 AI 应用开发，是否遇到过这样的困扰：
-
今天用 OpenAI，明天想试 Groq 或 Anthropic，接口格式完全不一样 -
要同时支持多个供应商的模型，代码里 if-else 越写越多 -
公司要统一管理所有模型的 key、花费、权限，维护成本直线上升 -
想快速切换模型做对比实验，但每次都要改一堆配置
这些问题其实指向同一个核心需求：能不能有一个统一的接口，像调用 OpenAI 那样调用几乎所有主流大模型？
LiteLLM 就是为了解决这件事而诞生的工具。
它目前可以让开发者用几乎完全相同的代码调用 100+ 家 大模型供应商，包括但不限于：
OpenAI、Anthropic、Azure、Google Vertex AI / Gemini、Bedrock、Groq、Mistral、Cohere、Together AI、Deepseek、火山引擎、DeepInfra、Ollama、本地 vLLM 等等。
下面我们一步一步来看它到底能做什么、怎么用，以及为什么很多人把它当作项目标配。
LiteLLM 能帮你解决哪些真实场景？
-
想快速实验不同模型，不想每次改一堆代码
同一套 messages 结构，直接把 model 字符串改一下就能调用不同厂商。 -
公司 / 团队需要中心化的模型网关
统一鉴权、虚拟 key、按项目 / 用户统计 token 消耗、设置预算、记录日志、加 guardrail。 -
生产环境要做多模型容灾 / 智能路由
主模型挂了自动切换备用模型，或者根据延迟、价格、区域智能选模型。 -
想把本地模型或自托管模型也当成 OpenAI 接口使用
Ollama、vLLM、Llamafile、LM Studio、Xinference 等都能无缝接入。 -
需要接入新兴的 Agent 协议或工具调用生态
支持 A2A Agent 协议、MCP 工具桥接等前沿接口。
一句话总结：LiteLLM 让你用最小的代码改动，获得最大的模型选择自由度，同时还能把管理复杂度从应用层下沉到基础设施层。
核心功能一览（2026 年 1 月现状）
| 功能类别 | 是否支持 | 典型场景举例 |
|---|---|---|
| 统一 chat/completions 接口 | 是 | 最常用的对话接口，几乎所有模型都支持 |
| embeddings 接口 | 部分支持 | 文本向量化（OpenAI、Voyage、Cohere 等） |
| image generations | 部分支持 | DALL·E 3、Stable Diffusion 等 |
| audio speech / transcription | 部分支持 | TTS、语音转文字 |
| rerank 接口 | 部分支持 | 召回结果重排序（Cohere、Bedrock 等） |
| batches 批量处理 | 部分支持 | 大规模异步任务 |
| A2A Agent 协议 | 是 | LangGraph、Vertex Agent、Bedrock Agent 等 |
| MCP 工具桥接 | 是 | 把外部工具服务器接入任意 LLM |
| 虚拟 key + 预算控制 | 是（Proxy） | 多租户、部门级费用分摊 |
| 负载均衡 + 自动 failover | 是（Router） | 多部署、多供应商高可用 |
| 详细使用量统计 | 是（Proxy） | 按 key / 项目 / 用户 / 模型维度统计 |
两种主要使用方式对比
LiteLLM 提供了两条主要路径，适用人群和场景差异很大。
| 维度 | Python SDK | LiteLLM Proxy（AI Gateway） |
|---|---|---|
| 主要使用者 | 个人开发者、早期项目 | 中大型团队、平台组、GenAI 基础设施团队 |
| 部署方式 | 直接 pip install 进项目 | 部署成独立服务（docker / render / railway） |
| 管理复杂度 | 低（都在代码里） | 中～高（但功能强大） |
| 统一鉴权与配额 | 基本没有 | 支持虚拟 key、预算、团队、RBAC |
| 多模型路由 / 容灾 | 支持 Router 类 | 支持更细粒度的路由规则 + 缓存 + 限流 |
| 监控仪表盘 | 靠 callback 送给第三方 | 自带 Admin UI |
| 典型部署时间 | 5 分钟 | 15–60 分钟 |
| 适合阶段 | PoC、个人项目、小团队 | 正式上线、多租户、成本敏感场景 |
大多数人会先从 Python SDK 开始试用，觉得好用后再把流量切到 Proxy 模式。
方式一：Python SDK 快速上手（推荐 90% 开发者第一步）
安装
pip install litellm
最简单调用示例
from litellm import completion
import os
# 只需设置对应厂商的环境变量即可
os.environ["OPENAI_API_KEY"] = "sk-..."
os.environ["ANTHROPIC_API_KEY"] = "sk-ant-..."
os.environ["GROQ_API_KEY"] = "gsk_..."
# 想换模型？只改这一行
response = completion(
model="openai/gpt-4o", # 或 "anthropic/claude-3-5-sonnet-20241022"
messages=[{"role": "user", "content": "今天新加坡天气怎么样？"}]
)
print(response.choices[0].message.content)
换成 Groq 的 Llama 3.1 405B 只需改一行：
model="groq/llama-3.1-405b-reasoning"
再换成本地 Ollama：
model="ollama/llama3.1"
同一套代码，模型随便换，这就是 LiteLLM 最吸引人的地方。
更多支持的模型写法请参考：https://docs.litellm.ai/docs/providers
方式二：部署 LiteLLM Proxy（AI Gateway）——中心化管理神器
当项目变大、团队变多、模型调用量上来后，很多人会转向 Proxy 模式。
一分钟启动体验（仅用于本地测试）
pip install 'litellm[proxy]'
litellm --model openai/gpt-4o
然后用 OpenAI SDK 调用（注意 base_url 变了）
import openai
client = openai.OpenAI(
api_key="sk-1234", # Proxy 里随便写，真正鉴权靠虚拟 key
base_url="http://0.0.0.0:4000"
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "你好呀"}]
)
真实生产建议使用 docker 部署（最常见方式）
docker run \
-v $(pwd)/litellm_config.yaml:/app/config.yaml \
-v $(pwd)/.env:/app/.env \
-p 4000:4000 \
ghcr.io/berriai/litellm:main-stable \
--config /app/config.yaml --detailed_debug
配置文件示例（config.yaml 片段）
model_list:
- model_name: gpt-4o
litellm_params:
model: azure/gpt-4o-east
api_base: https://your-azure.openai.azure.com/
api_key: os.environ/AZURE_API_KEY
rpm: 300
- model_name: claude-3-5-sonnet
litellm_params:
model: anthropic/claude-3-5-sonnet-20241022
api_key: os.environ/ANTHROPIC_API_KEY
general_settings:
master_key: sk-1234567890abcdef # 管理员 master key
更多部署方式（Render / Railway / Kubernetes / Helm）可参考官方文档快速开始章节。
LiteLLM Proxy 真正强大的几个功能
-
虚拟 key + 预算控制
可以给前端产品、内部不同小组、外部客户生成不同的 key，并设置每天 / 每月 token 上限。 -
按项目 / 用户统计消耗
支持把 token 消耗精确归属到某个项目、团队、用户，便于内部结算。 -
智能路由 + 自动 fallback
可以设置多个同质量模型，当某个模型 429 / 500 时自动切到下一个。 -
缓存（semantic cache / exact match）
相同问题直接返回缓存结果，大幅降低成本和延迟。 -
Admin UI 仪表盘
查看调用量、错误率、慢查询、token 消耗趋势，支持导出。 -
支持 MCP 工具桥接
可以把 GitHub、数据库、内部系统等工具通过 MCP 协议接入任意模型。 -
支持 A2A Agent 协议
可以把 LangGraph、Vertex Agent 等 Agent 当作普通模型一样调用。
常见问题（FAQ）
Q1：LiteLLM 会不会把我的 prompt 发给第三方？
不会。LiteLLM 只做格式转换和路由，实际请求还是直接打到你配置的供应商 endpoint。
Q2：性能怎么样？会不会成为瓶颈？
官方 benchmark 显示 P95 延迟 ≈ 8ms @ 1000 QPS，绝大部分场景下可以忽略不计。
Q3：支持本地完全离线部署吗？
支持。只要你用 Ollama / vLLM / Llamafile 等本地模型，Proxy 也可以完全内网运行。
Q4：我想同时用 Azure 和 OpenAI，谁便宜用谁，怎么做？
用 Proxy + Router 规则，或者在 SDK 里使用 Router 类，设置优先级 / 权重 / 降级逻辑。
Q5：Cursor、Continue 等 IDE 怎么用 LiteLLM？
直接把 LiteLLM Proxy 的地址和 key 填到 IDE 的 OpenAI 兼容接口配置里即可。
快速决策指南：我该现在就用 LiteLLM 吗？
| 你的情况 | 推荐方式 | 建议行动 |
|---|---|---|
| 个人做 side project 或 PoC | Python SDK | 今天就 pip install 试试 |
| 小团队，模型调用量 < 100万 tokens/月 | SDK + Router | 先用 SDK，后面视情况加 Proxy |
| 中大型团队 / 需要费用分摊 / 多租户 | Proxy 模式 | 尽快部署 Proxy + 虚拟 key 体系 |
| 已经有很多模型 key，想统一管理 | Proxy 模式 | 优先级最高 |
| 主要用本地模型，但想兼容 OpenAI 格式 | Proxy + Ollama/vLLM | 强烈推荐 |
最后：为什么它在 2025–2026 年变得越来越重要？
大模型供应商越来越多，价格战、性能差异、区域限制、审查策略各不相同。
单一依赖一家厂商的风险越来越大，而开发者最不想做的事情就是不停地改适配代码。
LiteLLM 的价值就在于：把模型选择的自由还给开发者，把管理复杂度留给基础设施。
希望这篇文章能帮你快速判断它是否适合你的当前阶段。
如果已经决定要试试，建议从最简单的 Python SDK 一行代码开始——很可能你试过之后就回不去了。
有任何部署或使用中的具体问题，欢迎留言，我们可以继续深入聊。
（完）
