1. 项目概述：LiteLLM不是“轻量版大模型”，而是一把精准适配所有大模型API的万能扳手
LiteLLM这个词最近在开发者圈里突然密集出现，不是因为又出了个新模型，而是因为它彻底改变了我们调用大模型的方式。它不训练模型，不压缩参数，也不做推理加速——它干的是更底层、更务实的事：统一接口。你写一次代码，就能无缝切换OpenAI、Anthropic、Google Gemini、Cohere、Ollama本地模型，甚至包括国内几家主流云厂商提供的大模型服务接口。这不是“兼容层”，而是真正意义上的协议翻译器：把OpenAI格式的messages数组、temperature参数、stream流式开关，实时翻译成Claude需要的system+content结构、Gemini要求的contents嵌套格式、Ollama必须的model字段位置……整个过程对上层业务逻辑完全透明。
我最早在做一个教育类SaaS系统时踩过坑：初期只接入了OpenAI，但客户分布在不同地区，有的因网络策略无法稳定访问，有的出于数据合规要求必须用本地部署的Qwen模型，还有的预算有限想试用免费的Llama3-Ollama方案。结果就是，后端要维护四套几乎重复的调用逻辑，每新增一个模型就得重写请求构造、响应解析、错误重试、token计数——光是处理{"error": {"message": "rate_limit_exceeded"}}和{"status": "error", "reason": "quota_exceeded"}这两种报错格式，就让我写了三版if-else。LiteLLM出现后，我把原来散落在5个文件里的模型调用逻辑，全部收束到一行litellm.completion()调用里，连日志打印的模型名称都自动从openai/gpt-4o变成anthropic/claude-3-haiku-20240307，根本不用改业务代码。它解决的不是“能不能跑”的问题，而是“要不要为每个模型单独招个工程师来维护SDK”的组织成本问题。适合正在做AI应用落地的产品经理、全栈开发者、技术负责人，尤其适合那些已经跑通MVP、正面临多模型灰度发布或客户定制化需求的团队——你不需要懂模型原理，但必须让系统足够灵活。
2. 核心设计思路拆解：为什么是“协议翻译”而非“模型抽象”？
2.1 不碰模型内核，只动API表皮：LiteLLM的哲学边界
很多人第一眼看到LiteLLM，会下意识把它和LangChain、LlamaIndex这类框架归为一类，这是典型误解。LangChain解决的是“怎么编排AI能力”，比如把检索、总结、生成串成流水线；LlamaIndex专注“怎么让大模型读懂你的私有文档”。而LiteLLM的使命极其纯粹：做HTTP请求与响应之间的语法转换器。它的核心代码里没有一行涉及模型权重加载、KV Cache管理、RoPE位置编码计算——这些全交给底层模型服务。它只关心三件事：请求发出去前怎么包装，响应回来后怎么拆包，出错了怎么映射错误码。
这种“只动协议不动内核”的设计，直接决定了它的轻量级本质。实测安装包大小仅1.2MB（pip install litellm），依赖极简：httpx（异步HTTP客户端）、pydantic（数据校验）、tenacity（重试逻辑）——没有PyTorch、没有Transformers、没有任何GPU相关依赖。这意味着你可以在树莓派上跑它调用Ollama，也可以在无GPU的CI服务器上用它做自动化测试。我曾在一个边缘计算项目中，把LiteLLM嵌入到只有128MB内存的ARM设备里，它负责把现场传感器数据组装成prompt，转发给局域网内的Llama3模型服务，整个进程常驻内存仅占用8MB。如果它试图去抽象模型本身，这个内存 footprint 绝对翻倍不止。
提示：LiteLLM的定位不是替代模型服务，而是成为模型服务之上的“交通警察”。它不管车（模型）是谁造的、马力多大，只管让所有车按同一套红绿灯规则（OpenAI API标准）上路。
2.2 为什么选择OpenAI作为事实标准？一场开发者心智的博弈
LiteLLM默认以OpenAI API为基准协议，这并非技术最优选，而是最务实的选择。你可以打开任意一个主流AI应用的源码，搜索openai.ChatCompletion.create，大概率能找到调用痕迹。为什么？因为OpenAI的API设计成了事实上的行业模板：messages数组封装对话历史，response_format控制JSON输出，tools字段支持函数调用——这套范式已被开发者广泛接受。LiteLLM选择它，等于选择了最低的迁移成本。
但这里有个关键细节常被忽略：LiteLLM不是简单地“把其他模型塞进OpenAI壳子”。它做了深度语义对齐。比如Anthropic的max_tokens实际对应OpenAI的max_completion_tokens（而非max_tokens），Gemini的stopSequences需映射为OpenAI的stop，而Ollama的num_ctx参数根本不存在于OpenAI协议中，LiteLLM会直接忽略或抛出警告。这种对齐不是字符串替换，而是基于各厂商官方文档的逐字段语义分析。我对比过LiteLLM v1.42.1的源码，其litellm/llms/目录下每个模型都有独立的completion()方法实现，里面密密麻麻全是条件判断：当model == "claude-3-opus"且stream == True时，必须在headers里加X-Accept-Content-Type: text/event-stream；当调用gemini-pro且response_mime_type == "application/json"时，需在body里插入"response_mime_type": "application/json"——这些全是厂商文档里藏得很深的硬性要求，LiteLLM把它变成了开箱即用的配置。
2.3 动态路由：让“一个API调所有模型”真正落地的关键机制
LiteLLM最被低估的能力，是它的动态路由（Dynamic Routing）模块。很多教程只教你怎么用litellm.completion(model="gpt-4o", messages=...)，却没说清背后发生了什么。当你传入model="azure/gpt-4o"时，LiteLLM会先查路由表：这个azure/前缀对应哪个Azure OpenAI endpoint？API key存在哪？超时时间设多少？如果配置了多个Azure endpoint，它还能根据litellm.set_verbose=True开启的负载均衡策略，把请求分发到不同区域的实例上。
更实用的是故障转移（Fallback）。我在生产环境配置了三级回退：主用gpt-4o→ 备用claude-3-haiku→ 最终保底ollama/llama3。当某次gpt-4o返回503 Service Unavailable时，LiteLLM不会直接报错，而是自动重试claude-3-haiku，且把原始prompt、temperature等参数原样透传过去。整个过程对上层业务无感，日志里只多了一行[INFO] Fallback triggered from gpt-4o to claude-3-haiku。这种能力不是靠运气，而是LiteLLM内置的ModelRouter类在运行时维护着每个模型的健康状态——它会记录最近10次请求的成功率、平均延迟，当成功率低于90%时自动降权，延迟超过2s则暂时剔除路由池。你不需要自己写熔断器，它已经把混沌工程的最佳实践封装好了。
3. 核心细节解析与实操要点：从零配置到生产就绪
3.1 环境准备：三行命令搞定最小可行环境
LiteLLM的安装门槛低得惊人，但生产环境的配置细节决定成败。以下是我在三个不同场景验证过的最小可行配置：
# 场景1：纯Python脚本快速验证（无需虚拟环境） pip install litellm # 验证是否安装成功 python -c "import litellm; print(litellm.__version__)" # 场景2：Docker容器化部署（推荐生产用） # Dockerfile FROM python:3.11-slim RUN pip install litellm[extra] # 安装带额外依赖的版本（含redis、prometheus等） COPY . /app WORKDIR /app CMD ["python", "server.py"] # 场景3：与FastAPI深度集成（高并发API服务） pip install litellm[fastapi] # 自动安装fastapi、uvicorn、pydantic注意[extra]和[fastapi]这两个可选依赖组。[extra]包含Redis（用于分布式缓存）、Prometheus（监控指标导出）、SQLAlchemy（数据库支持），而[fastapi]则预装了Web框架所需组件。很多新手直接pip install litellm后发现litellm.proxy命令报错，就是因为漏装了[extra]——proxy服务依赖Redis做请求队列和缓存，这是LiteLLM企业级能力的基础设施。
注意：LiteLLM默认不启用任何外部服务。
litellm.completion()在单机模式下完全离线运行，只有当你显式调用litellm.proxy或配置REDIS_URL时，才启动网络依赖。这点对安全审计极其友好——你可以先在内网验证功能，再逐步开放监控和缓存。
3.2 模型配置：环境变量 vs 配置文件的取舍逻辑
LiteLLM支持三种模型配置方式：环境变量、代码内硬编码、YAML配置文件。我的经验是：开发阶段用环境变量，测试阶段用YAML，生产环境用加密配置中心。
环境变量：适合本地调试。只需设置
OPENAI_API_KEY、ANTHROPIC_API_KEY等，LiteLLM会自动识别。但要注意，环境变量名有严格规范：AZURE_API_KEY对应Azure，GEMINI_API_KEY对应Gemini，OLLAMA_API_BASE对应Ollama地址（默认http://localhost:11434）。我见过最多的问题是把OLLAMA_API_BASE写成OLLAMA_BASE_URL，导致连接超时却报KeyError: 'model'这种误导性错误。YAML配置文件：这是生产部署的黄金标准。创建
config.yaml：
model_list: - model_name: gpt-4o litellm_params: model: gpt-4o api_key: sk-... api_base: https://api.openai.com/v1 - model_name: claude-3-haiku litellm_params: model: claude-3-haiku-20240307 api_key: sk-ant-... - model_name: llama3-local litellm_params: model: ollama/llama3 api_base: http://ollama-server:11434然后启动代理：litellm --config config.yaml --port 4000。YAML的优势在于：模型可热更新（修改后kill -SIGHUP进程即可重载）、支持复杂路由策略（如按用户ID哈希分发）、便于Git版本管理。我们团队就把config.yaml纳入CI/CD流水线，每次模型升级都触发全自动回归测试。
- 代码内硬编码：仅限POC演示。例如：
from litellm import completion response = completion( model="gpt-4o", messages=[{"role": "user", "content": "你好"}], api_key="sk-..." # 显式传入key )这种方式最大的风险是密钥泄露。LiteLLM虽支持api_key参数，但官方文档明确警告：“Never commit api keys in code”。生产环境必须通过环境变量或配置文件注入。
3.3 Token计算与成本控制：看不见的隐形成本杀手
几乎所有LiteLLM新手都会忽略一个致命细节：不同模型的token计数方式天差地别。OpenAI用tiktoken库，Anthropic用anthropic-tokens，Gemini用google.generativeai内置计数器，而Ollama根本没提供标准API——LiteLLM必须自己实现近似算法。这直接导致两个严重后果：
- 账单误差：你按OpenAI的token数付费，但LiteLLM返回的
response['usage']['total_tokens']可能是Ollama估算值，误差高达±15%； - 上下文截断失效：当
max_tokens=1000时，LiteLLM会尝试把prompt压缩到剩余空间，但如果token计数不准，可能把本该保留的prompt内容粗暴截断。
我的解决方案是：强制使用模型原生计数器，并在配置中显式声明。在config.yaml里为每个模型添加tpm（tokens per minute）和rpm（requests per minute）限制：
model_list: - model_name: gpt-4o litellm_params: model: gpt-4o tpm: 100000 rpm: 1000 - model_name: llama3-local litellm_params: model: ollama/llama3 tpm: 5000 # 本地模型实际TPM更低，此处设保守值然后在代码中启用litellm.token_counter：
from litellm import token_counter # 手动计算prompt token数（确保与模型一致） prompt_tokens = token_counter( model="gpt-4o", text="你好，今天天气如何？" ) print(f"Prompt tokens: {prompt_tokens}") # 输出准确值LiteLLM的token_counter会根据model参数自动选择对应计数器，比自己调用tiktoken.encoding_for_model("gpt-4o")更可靠。我们线上系统就靠这个精确控制每个用户的日token配额，误差稳定在±2%以内。
4. 实操过程与核心环节实现：从单次调用到企业级API网关
4.1 单模型调用：五分钟上手的完整链路
让我们从最简单的场景开始：用LiteLLM调用本地Ollama的Llama3模型。这不需要任何云服务，是验证LiteLLM工作流的黄金起点。
第一步：确认Ollama已运行
# 启动Ollama（如未安装，请先brew install ollama或下载官方客户端） ollama run llama3 # 在另一个终端检查服务状态 curl http://localhost:11434/api/tags # 应返回包含"llama3"的JSON第二步：编写LiteLLM调用脚本
# llama3_call.py from litellm import completion import os # LiteLLM会自动读取OLLAMA_API_BASE环境变量 os.environ["OLLAMA_API_BASE"] = "http://localhost:11434" try: response = completion( model="ollama/llama3", # 必须带"ollama/"前缀 messages=[ {"role": "system", "content": "你是一个严谨的助手，回答要简洁准确"}, {"role": "user", "content": "Python中如何获取当前时间戳？"} ], temperature=0.3, # 控制随机性 max_tokens=200 # 限制输出长度 ) print("=== 响应内容 ===") print(response.choices[0].message.content) print("\n=== Token统计 ===") print(f"输入tokens: {response.usage.prompt_tokens}") print(f"输出tokens: {response.usage.completion_tokens}") print(f"总tokens: {response.usage.total_tokens}") except Exception as e: print(f"调用失败: {e}") # LiteLLM的错误类型很明确，可针对性捕获 if "ConnectionError" in str(e): print("检查Ollama服务是否运行，或OLLAMA_API_BASE地址是否正确")第三步：执行并观察输出
python llama3_call.py预期输出：
=== 响应内容 === 可以使用 time.time() 函数获取当前时间戳（秒级浮点数），或 time.time_ns() 获取纳秒级时间戳。 === Token统计 === 输入tokens: 42 输出tokens: 38 总tokens: 80这个看似简单的例子，其实完成了LiteLLM的核心价值闭环：协议转换（Ollama的JSON格式→OpenAI标准）、错误映射（Ollama的500 Internal Server Error→LiteLLM的litellm.RateLimitError）、Token计数（调用Ollama内置计数器）。整个过程你不需要知道Ollama的API文档长什么样，只需要记住ollama/llama3这个模型名。
4.2 多模型路由：构建智能降级的AI服务网关
当业务需要同时支持多个模型时，LiteLLM的ModelRouter就展现出真正的威力。以下是我们为客服系统设计的生产级路由策略：
# router_config.py from litellm import Router import os # 从环境变量读取密钥（生产环境建议用Vault等密钥管理服务） os.environ["OPENAI_API_KEY"] = "sk-..." os.environ["ANTHROPIC_API_KEY"] = "sk-ant-..." os.environ["OLLAMA_API_BASE"] = "http://ollama-prod:11434" # 定义模型路由池 router = Router( model_list=[ { "model_name": "premium-gpt4o", # 业务层使用的逻辑模型名 "litellm_params": { "model": "gpt-4o", "api_key": os.getenv("OPENAI_API_KEY"), "timeout": 60, "max_retries": 2 } }, { "model_name": "balanced-claude", "litellm_params": { "model": "claude-3-haiku-20240307", "api_key": os.getenv("ANTHROPIC_API_KEY"), "timeout": 45, "max_retries": 1 } }, { "model_name": "economy-llama3", "litellm_params": { "model": "ollama/llama3", "api_base": os.getenv("OLLAMA_API_BASE"), "timeout": 120, # 本地模型响应慢，放宽超时 "max_retries": 0 # Ollama不稳定，不重试避免雪崩 } } ], # 路由策略：按模型性能分级 routing_strategy="usage-based-routing", # 根据历史成功率和延迟自动选最优 num_retries=1, # 全局重试次数 fallbacks=[ # 降级链 {"model_name": "premium-gpt4o", "fallbacks": ["balanced-claude"]}, {"model_name": "balanced-claude", "fallbacks": ["economy-llama3"]} ] ) # 封装成业务友好的调用函数 def get_ai_response(user_query: str, user_tier: str = "basic") -> str: """ 根据用户等级智能选择模型 - premium用户：优先gpt-4o，失败降级claude - basic用户：直接走claude，节省成本 - free用户：强制走llama3本地模型 """ if user_tier == "premium": model = "premium-gpt4o" elif user_tier == "basic": model = "balanced-claude" else: model = "economy-llama3" try: response = router.completion( model=model, messages=[{"role": "user", "content": user_query}], temperature=0.5 ) return response.choices[0].message.content except Exception as e: # 记录详细错误日志，便于后续优化路由策略 print(f"模型{model}调用失败: {e}") raise这个路由配置实现了三个关键能力：
- 智能选型：
usage-based-routing策略会持续学习各模型的实时表现，把高优先级请求自动导向延迟最低的模型； - 成本分层：不同用户等级走不同模型，避免免费用户消耗昂贵的GPT-4o配额；
- 故障隔离：当Ollama集群整体宕机时，
economy-llama3的失败不会影响premium-gpt4o的正常调用，因为路由是模型粒度的。
我们在压测中验证过：当故意停掉Ollama服务时，get_ai_response(..., user_tier="free")会报错，但user_tier="premium"的请求依然100%成功，证明路由隔离有效。
4.3 生产级Proxy服务：一键启动企业级AI网关
LiteLLM最强大的形态是litellm.proxy——一个开箱即用的企业级API网关。它不只是转发请求，而是集成了鉴权、限流、审计、监控的完整解决方案。
启动命令（带关键参数说明）：
# 最小启动（仅启用基础功能） litellm --port 4000 --config config.yaml # 生产推荐启动（启用全功能） litellm \ --port 4000 \ --config config.yaml \ --database_url "sqlite:///./litellm.db" \ # 本地SQLite存储审计日志 --redis_url "redis://localhost:6379/0" \ # Redis用于分布式限流和缓存 --telemetry False \ # 关闭遥测（隐私敏感场景必关） --health_check_interval 30 # 每30秒检查模型健康状态关键功能实测效果：
| 功能 | 配置方式 | 实测效果 | 我的使用心得 |
|---|---|---|---|
| API Key鉴权 | 在config.yaml中配置general_settings: {"require_api_key": true}，然后用litellm create-key --duration 1h --models gpt-4o,claude-3-haiku生成密钥 | 所有请求必须带Authorization: Bearer sk-xxx，否则返回401 Unauthorized | 密钥支持按模型、按有效期、按用户ID生成，比自己写JWT鉴权省心太多 |
| 请求限流 | general_settings: {"rpm": 100, "tpm": 10000}设置全局限额；或在model_list中为单个模型设置rpm/tpm | 当1分钟内请求超100次，后续请求返回429 Too Many Requests | 限流基于Redis原子操作，多实例部署时仍能精准控制总QPS |
| 审计日志 | --database_url参数启用 | 所有请求/响应（可选脱敏）存入SQLite，包含时间、模型、token数、IP、耗时 | 日志表spend_logs可直接用SQL分析各模型成本占比，财务对账神器 |
| Prometheus监控 | --proxy_host 0.0.0.0+--metrics True | 启动后/metrics端点暴露litellm_request_total、litellm_latency_seconds等指标 | 我们用Grafana看板监控litellm_latency_seconds_bucket{le="2"}，当95%请求超2秒就自动告警 |
一个真实运维场景：上周我们发现gpt-4o的平均延迟从800ms飙升到3.2s。通过Proxy的Prometheus指标，快速定位到是某个客户批量提交了超长文档（平均12000 tokens）。我们立即登录Proxy管理后台（litellm --admin_ui），临时将该客户的API Key加入黑名单，并调整其tpm限额至500。整个过程不到2分钟，而传统方案需要改代码、发版、重启服务。
5. 常见问题与排查技巧实录：那些文档里不会写的坑
5.1 连接超时类问题：90%的“调不通”都源于这三处
LiteLLM报错信息往往很“优雅”，但背后原因可能千差万别。我整理了最常遇到的连接问题及根因分析：
| 报错信息 | 真实原因 | 排查步骤 | 解决方案 |
|---|---|---|---|
litellm.exceptions.Timeout: Request timed out | 1. 模型服务网络不可达 2. timeout参数设得太小3. 模型本身响应慢（如长文本生成） | 1.curl -v http://your-model-endpoint/health2. 查看LiteLLM日志中的 timeout值3. 用 time curl ...测原始服务延迟 | 1. 检查防火墙/DNS 2. 在 litellm.completion()中显式加大timeout3. 对Ollama等慢模型，在 config.yaml中设timeout: 120 |
litellm.exceptions.AuthenticationError: Invalid API key | 1. 环境变量名拼写错误（如OPENAI_API_KEY写成OPEN_AI_API_KEY）2. 密钥已过期或被撤销 3. Azure配置中 AZURE_API_VERSION版本号不匹配 | 1.print(os.environ.get("OPENAI_API_KEY", "NOT SET"))2. 用Postman直接调用模型API验证密钥 | 1. 严格按LiteLLM文档的环境变量名书写 2. Azure用户务必确认 AZURE_API_VERSION与文档一致（如2024-02-01） |
litellm.exceptions.BadRequestError: model does not exist | 1. 模型名格式错误（如gpt-4o写成gpt4o）2. 未在 config.yaml中注册该模型3. Ollama未拉取对应模型（ ollama list不显示） | 1.litellm --model_list查看LiteLLM识别的模型2. ollama list确认本地模型存在 | 1. Ollama模型必须用ollama/llama3格式2. Azure模型必须用 azure/gpt-4o格式，且config.yaml中api_base指向正确的region endpoint |
实操心得：LiteLLM的
--debug模式是排错神器。启动时加--debug参数，它会在日志中打印原始HTTP请求头、请求体、响应头、响应体（脱敏后）。我曾靠这个发现一个隐藏bug：Gemini API要求Content-Type: application/json，但LiteLLM在某些版本里漏加了这个header，导致415错误。--debug日志直接暴露了缺失的header，比查文档快十倍。
5.2 Token与计费异常：成本失控的元凶
Token计算不准是LiteLLM生产环境中最隐蔽的成本漏洞。以下是三个真实案例：
案例1：Ollama的“幽灵token”
- 现象：调用
ollama/llama3时，response.usage.total_tokens比实际多出200+ tokens - 根因：Ollama的
/api/chat接口返回的context_length字段被LiteLLM误认为是本次请求的token数，而它其实是模型上下文窗口总长度 - 解决：升级LiteLLM到v1.40.0+，该版本已修复Ollama token计数逻辑，改用
response.message.content长度估算
案例2：Azure的“双计费陷阱”
- 现象：同一请求在Azure OpenAI和普通OpenAI上token数相差30%
- 根因：Azure的
api_version=2024-02-01返回的usage对象结构与OpenAI不同，LiteLLM旧版本解析错误 - 解决：在
config.yaml中为Azure模型显式指定api_version，并确保LiteLLM版本≥1.38.0
案例3：流式响应的“token黑洞”
- 现象：开启
stream=True时，response.usage始终为None - 根因：流式响应中，token统计只能在流结束时获得，LiteLLM默认不等待流结束就返回响应对象
- 解决：两种方案：
1. 改用非流式调用（牺牲实时性）
2. 用litellm.stream_chunk_builder手动聚合流式块并计算token（需自行实现）
注意：LiteLLM的
token_counter函数在流式场景下不可用。如果你必须用流式且要精确计费，唯一可靠方案是：关闭LiteLLM的流式支持，用completion(..., stream=False)，然后在前端用SSE模拟流式体验。这是很多团队踩坑后的共识方案。
5.3 模型行为差异：为什么“同样的prompt，不同模型结果天差地别”
LiteLLM解决了API协议问题，但没解决模型本身的“性格差异”。这是开发者最容易忽视的认知盲区。
| 差异维度 | OpenAI GPT-4o | Anthropic Claude | Google Gemini | Ollama Llama3 |
|---|---|---|---|---|
| System Prompt处理 | 严格遵循messages[0]["role"]=="system" | 必须用system字段，且不能出现在messages数组中 | system_instruction字段独立于contents | 无视system role，全部当作user消息 |
| Stop Sequences | stop=["\n\n"]会停在第一个双换行 | stop_sequences=["\n\n"]但实际停在\n | stop_sequences需转为stop字段 | stop参数被忽略，需在prompt末尾加特殊标记 |
| JSON Mode | response_format={"type": "json_object"} | system中声明Respond in JSON format | response_mime_type="application/json" | 不支持，需用prompt约束 |
实战技巧：
- 写prompt时永远假设模型“不懂system role”，把关键指令放在第一条user消息里；
- 需要精确停顿时，不要依赖
stop参数，改用prompt结尾加<|eot_id|>等模型特有标记； - JSON输出场景，优先选Gemini（原生支持）或GPT-4o（
response_format最稳定），避免用Claude或Llama3。
我曾为一个金融报告生成系统做过AB测试：同一份财报数据，GPT-4o JSON输出准确率98%，Claude因system prompt解析问题导致23%的字段缺失，Llama3则完全无法保证JSON格式。最终方案是：用LiteLLM路由，对JSON需求强制走Gemini，其他场景再按成本路由。
6. 进阶能力与扩展方向：超越API网关的更多可能
6.1 自定义模型支持：把私有模型接入LiteLLM生态
LiteLLM最被低估的能力是custom_llm_provider机制。它允许你把任何HTTP API封装成LiteLLM可调用的模型，无需修改LiteLLM源码。
场景：接入公司自研的风控大模型（API格式：POST /v1/risk/analyze）
# custom_risk_provider.py from litellm import CustomLLM import httpx class RiskModelProvider(CustomLLM): def completion(self, model, messages, **kwargs): # 构造风控模型专用请求体 risk_payload = { "text": messages[-1]["content"], # 只取最后一条user消息 "risk_threshold": kwargs.get("risk_threshold", 0.7), "return_explanation": True } # 调用私有API response = httpx.post( "https://risk-api.internal/v1/risk/analyze", json=risk_payload, headers={"Authorization": "Bearer " + kwargs["api_key"]}, timeout=30 ) # 将风控API响应映射为OpenAI格式 if response.status_code == 200: risk_data = response.json() return { "choices": [{ "message": { "content": f"风险评分: {risk_data['score']:.2f}\n解释: {risk_data['explanation']}" } }], "usage": { "prompt_tokens": len(risk_payload["text"].split()), "completion_tokens": 50, "total_tokens": 100 } } else: raise Exception(f"Risk API error: {response.status_code}") # 注册自定义provider from litellm import register_model register_model({ "model_name": "internal/risk-analyzer", "litellm_params": { "model": "internal/risk-analyzer", "api_base": "https://risk-api.internal", "api_key": "your-risk-api-key" } })现在就可以像调用GPT一样使用：
from litellm import completion response = completion( model="internal/risk-analyzer", messages=[{"role": "user", "content": "用户申请贷款100万，月收入2万，负债50万"}], risk_threshold=0.85 # 传递自定义参数 )这个机制让LiteLLM从“模型API路由器”升级为“AI能力集成平台”。我们已用它接入了内部的OCR服务、语音转写API、甚至一个用Flask写的Python代码解释器——所有AI能力都统一用litellm.completion()调用，前端完全无感知。
6.2 与向量数据库协同：构建RAG系统的统一入口
LiteLLM常与Chroma、Pinecone等向量数据库搭配使用。但多数教程把检索和生成拆成两步，导致错误处理复杂。LiteLLM的litellm.rerank()和litellm.embedding()提供了更优雅的方案。
典型RAG流程重构：
from litellm import embedding, rerank, completion #
