LiteLLM：大模型统一API网关与工程化调用中间件

1. 项目概述：LiteLLM不是“轻量版大模型”，而是统一调用层的工程实践

LiteLLM这个词最近在技术社区里出现频率陡增，但很多人第一眼看到它，下意识会以为是某个新出的轻量级大模型——比如参数量压缩到几亿、能在笔记本上跑的“小钢炮”。这其实是个典型误解。LiteLLM本质上完全不训练模型、不修改模型结构、也不生成任何token；它是一层协议转换器+路由调度器+标准化适配器，核心任务只有一个：让开发者写一次代码，就能无缝对接OpenAI、Anthropic、Google Vertex AI、Azure OpenAI、Ollama、本地vLLM服务，甚至包括部分国产模型API（如千问、混元的兼容接口）。我最早在某高校实验室做多模型对比实验时踩过坑：为测3个模型要维护3套请求逻辑，改一个超参就得同步改3份代码，调试日志格式还不统一。后来换成LiteLLM，整个推理服务模块的代码量直接砍掉60%，关键是后续新增模型支持，只用改一行配置。

它的价值不在“模型能力”上，而在“工程效率”上。就像当年MySQL驱动统一了Java对不同数据库的访问方式，LiteLLM正在成为大模型应用层的事实标准接口。你不需要懂Claude的system prompt怎么传、Gemini的max_output_tokens字段叫什么、Ollama的stream响应如何解析——LiteLLM把这些全给你抹平了，对外暴露的永远是OpenAI-style的chat.completions.create()调用。更关键的是，它不是简单转发，而是做了深度语义对齐：比如把Anthropic的max_tokens自动映射成OpenAI的max_completion_tokens，把Google的temperature范围0-1自动线性缩放到0.01-1区间，甚至能智能识别并重写不兼容的tool call格式。这种“翻译”不是字符串替换，而是基于模型厂商文档和大量实测反馈构建的规则引擎。如果你正在搭建RAG系统、Agent工作流或模型评测平台，LiteLLM不是可选项，而是降低维护成本的刚需基础设施。

2. 核心设计思路与方案选型逻辑

2.1 为什么需要LiteLLM？从“胶水代码”到“协议中间件”的演进

在LiteLLM出现前，主流做法是写一堆if-else胶水代码。比如某公司做客服机器人，初期只用OpenAI GPT-3.5，代码很干净：

response = openai.ChatCompletion.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": "你好"}], temperature=0.7, max_tokens=512 )

但业务扩展后要接入Claude处理长文档，代码就变成：

if model_provider == "openai": response = openai.ChatCompletion.create(...) elif model_provider == "anthropic": client = anthropic.Anthropic(api_key=...) response = client.messages.create( model="claude-3-haiku-20240307", messages=[{"role": "user", "content": "你好"}], temperature=0.7, max_tokens=512 # 注意：这里叫max_tokens，不是max_completion_tokens )

问题立刻暴露：

• 参数语义不一致：OpenAI的max_tokens包含prompt和completion，Anthropic的max_tokens仅指completion，Google的maxOutputTokens又只管输出。直接照搬会导致Claude实际输出被截断一半。
• 消息格式差异：OpenAI要求{"role": "system", "content": "..."}，Anthropic不支持system role，必须塞进user message开头；Gemini则要求{"role": "user", "parts": ["..."]}。
• 流式响应结构混乱：OpenAI返回data: {"choices": [...]}，Ollama返回{"message": {...}}，vLLM返回{"text": "..."}，前端解析器得写5种分支。

LiteLLM的解法很务实：不做模型抽象，只做API协议抽象。它把所有厂商API看作“方言”，自己定义一套标准“普通话”（即OpenAI API spec），然后为每个厂商写一个“翻译官”。这个设计决策背后有三个硬约束：

1. 零模型耦合：绝不碰模型权重、不改推理逻辑，确保合规性——这对金融、医疗等强监管行业至关重要；
2. 最小学习成本：开发者无需学新SDK，pip install litellm后，litellm.completion()的调用方式和OpenAI SDK一模一样；
3. 动态可插拔：新增模型支持只需提交PR到LiteLLM仓库，社区审核通过后，用户升级包即可用，不用改业务代码。

我参与过某跨平台AI工具链项目，最初想自研类似中间件，花两周写了基础路由，结果发现Anthropic的tool use语法和OpenAI差太多，光是tool call的JSON Schema校验就卡了三天。最后直接切到LiteLLM，当天就跑通全模型链路。这印证了它的核心优势：把重复造轮子的精力，转化成业务逻辑的深度打磨。

2.2 LiteLLM vs. 其他方案：为什么不是LangChain或LlamaIndex？

常有人问：“LangChain也有model wrapper，LiteLLM有什么特别？” 这是个好问题。LangChain的ChatModel抽象层确实能统一调用，但它本质是框架内封装，深度绑定LangChain生态。一旦你的项目不用LangChain（比如用FastAPI直接写API、用Streamlit做前端、或用Rust写高性能服务），LangChain的wrapper就毫无用处。而LiteLLM是进程级代理，它提供两种使用模式：

• SDK模式：作为Python库集成到任意代码中，不依赖任何框架；
• Proxy模式：启动一个独立HTTP服务（litellm --host 0.0.0.0 --port 4000），所有请求发给它，它再转发给后端模型。此时前端完全感知不到后端是OpenAI还是本地vLLM，连curl命令都不用改。

另一个常见对比是LlamaIndex。它的LLM类也做模型适配，但定位是RAG专用管道组件，重点解决检索增强场景下的模型调用，对非RAG场景（如纯文本生成、函数调用、多模态）支持薄弱。LiteLLM则覆盖全场景：文本补全、聊天、嵌入向量、图像生成（兼容Stable Diffusion API）、语音转文字（Whisper兼容），甚至支持模型负载均衡和fallback机制——当主模型超时，自动切到备用模型重试。

最关键的区别在于部署粒度。LangChain/LlamaIndex的wrapper运行在应用进程中，模型故障会导致整个服务重启；LiteLLM Proxy是独立进程，挂了只影响AI调用，不影响主业务。我们在某电商客服系统上线时，把LiteLLM Proxy部署在单独容器里，即使它因网络抖动短暂不可用，客服页面仍能降级显示“人工服务中”，而不是白屏报错。这种故障隔离能力，是框架级wrapper无法提供的。

3. 核心功能拆解与实操要点

3.1 统一API调用：从“写三遍代码”到“写一遍代码”

LiteLLM最直观的价值，就是把N种模型调用收敛成一个函数。以最常用的聊天补全为例，原始代码需要为不同模型写不同逻辑：

# OpenAI原生调用 response = openai.ChatCompletion.create( model="gpt-4-turbo", messages=[{"role": "user", "content": "总结这篇论文"}], temperature=0.3, top_p=0.9, max_tokens=1024 ) # Anthropic原生调用（注意参数名和值域差异） client = anthropic.Anthropic(api_key="...") response = client.messages.create( model="claude-3-sonnet-20240229", messages=[{"role": "user", "content": "总结这篇论文"}], temperature=0.3, # Anthropic温度范围0-1，但0.0效果接近0.3 top_p=0.9, max_tokens=1024 # 此处max_tokens仅指输出长度 )

而LiteLLM只需这样：

import litellm litellm.set_verbose = True # 开启调试日志 response = litellm.completion( model="gpt-4-turbo", # 或 "anthropic/claude-3-sonnet-20240229" messages=[{"role": "user", "content": "总结这篇论文"}], temperature=0.3, top_p=0.9, max_tokens=1024 )

提示：LiteLLM会自动识别model字符串前缀，gpt-4-turbo走OpenAI，anthropic/xxx走Anthropic，google/gemini-pro走Google Vertex。你甚至可以写azure/gpt-4-turbo，它会自动读取AZURE_API_BASE等环境变量。

背后的魔法在于参数归一化引擎。LiteLLM内部维护一张映射表，例如：

更精妙的是消息格式转换。当你传入[{"role": "system", "content": "你是专家"}]，LiteLLM对OpenAI原样透传；对Anthropic则自动转换为[{"role": "user", "content": "你是专家\n\n<user_message>"}]；对Google Gemini则拆成{"role": "user", "parts": ["你是专家", "<user_message>"]}。这种转换不是简单拼接，而是基于各厂商文档的语义理解——比如Anthropic明确要求system prompt必须前置且用换行分隔，LiteLLM就严格遵循。

实操中要注意一个细节：tool call的兼容性。OpenAI的function calling格式是：

{ "tools": [{"type": "function", "function": {"name": "get_weather", "parameters": {...}}}], "tool_choice": "auto" }

而Anthropic的tool use是：

{ "tools": [{"name": "get_weather", "input_schema": {...}}], "tool_choice": {"type": "auto"} }

LiteLLM会自动做字段重命名和结构转换，但input_schema必须是JSON Schema格式（Anthropic强制要求），而OpenAI的parameters可以是简化版。所以如果你用LiteLLM调用Anthropic，tools里的parameters字段会被LiteLLM自动转成input_schema，前提是它能解析成合法JSON Schema。我在测试时发现，如果parameters里用了"type": "integer"（OpenAI允许），LiteLLM会报错，因为Anthropic要求"type": "number"。解决方案是在传参时显式用input_schema字段，或者用LiteLLM的convert_to_anthropic_tool工具函数预处理。

3.2 模型路由与负载均衡：让流量聪明地分配

单一模型总有瓶颈：GPT-4 Turbo贵，Claude 3 Sonnet快但长文本弱，本地vLLM便宜但显存有限。LiteLLM的路由功能，就是让请求自动找到最适合的模型。核心是litellm.Router类，它支持三种策略：

1. 权重轮询（Weighted Round Robin）：按预设权重分发请求。比如你有3台vLLM服务器，A机性能强配权重5，B机中等配权重3，C机老旧配权重1，那么每9次请求，A收5次，B收3次，C收1次。配置很简单：

from litellm import Router router = Router( model_list=[ { "model_name": "llama3-70b", "litellm_params": { "model": "ollama/llama3:70b", "api_base": "http://vllm-server-a:8000" }, "weight": 5 }, { "model_name": "llama3-8b", "litellm_params": { "model": "ollama/llama3:8b", "api_base": "http://vllm-server-b:8000" }, "weight": 3 } ] )

2. 延迟感知路由（Latency-Based Routing）：LiteLLM会持续探测各模型endpoint的P95延迟，自动把新请求发给当前最快的节点。这在混合云场景特别有用——比如OpenAI API偶尔延迟飙升到2s，而本地vLLM稳定在300ms，LiteLLM会瞬间切流。启用方式只需加一个参数：

router = Router( model_list=[...], routing_strategy="latency-based" )

3. 规则路由（Rule-Based Routing）：按请求内容智能分发。比如长于5000字的文档走Claude 3 Opus（擅长长上下文），含代码块的请求走CodeLlama，普通问答走GPT-3.5 Turbo。这需要自定义路由函数：

def custom_route(request): if len(request["messages"][0]["content"]) > 5000: return "anthropic/claude-3-opus-20240229" elif "```" in request["messages"][0]["content"]: return "ollama/codellama:70b" else: return "gpt-3.5-turbo" router = Router(model_list=[...], routing_strategy="usage-based", num_retries=3)

注意：规则路由需配合num_retries，因为首次路由失败（如目标模型超时）会触发重试，LiteLLM会按权重或延迟重新选模型。

我在某法律文书分析系统中用过规则路由。合同文本平均长度8000字，必须用Claude 3 Opus；但用户提问“这份合同违约金条款在哪？”只有10个字，用GPT-3.5 Turbo足够且快3倍。上线后，整体平均延迟从1.8s降到0.7s，成本降了40%。关键经验是：规则要简单、可预测、易测试。我们最初想按关键词路由（含“违约”“赔偿”走Opus），结果发现用户口语化表达太多（“不给钱算不算违约？”），误判率高。改成纯长度判断后，准确率100%，运维也省心。

3.3 Fallback与熔断：让AI服务像水电一样可靠

生产环境最怕什么？不是模型不准，而是服务不可用。OpenAI API可能因限流返回429，Anthropic可能因region故障503，本地vLLM可能OOM崩溃。LiteLLM的fallback机制，就是给AI调用加保险丝。

基本fallback配置：

response = litellm.completion( model="gpt-4-turbo", fallbacks=["gpt-3.5-turbo", "ollama/llama3:8b"], messages=[...], timeout=30 )

当gpt-4-turbo调用失败（HTTP错误、超时、模型拒绝），LiteLLM会自动重试gpt-3.5-turbo，再失败则试ollama/llama3:8b。整个过程对业务代码透明，你拿到的永远是response对象。

但真实场景更复杂。比如某次OpenAI返回429（Rate Limit Exceeded），重试GPT-3.5 Turbo可能也撞上限——因为共享同一个API Key的配额。LiteLLM的智能fallback能规避这点：它会记录每个模型的错误类型，对429错误优先切到不同厂商的模型（如Anthropic），对500错误优先切到同厂商低配模型（如GPT-3.5 Turbo）。

更关键的是熔断器（Circuit Breaker）。LiteLLM内置熔断逻辑：如果某个模型连续3次失败（可配置），就将其标记为“熔断”，10分钟内不再路由请求过去。这避免了雪崩效应——比如vLLM服务器OOM后，所有请求都涌向它，导致整个集群瘫痪。熔断状态实时写入Redis（可配置），支持多实例共享。

实操心得：熔断阈值要根据业务容忍度设。我们做实时客服，要求99.9%请求在2s内返回，所以设熔断为“2次失败+5秒超时”，熔断时间5分钟；而做离线报告生成，可接受10分钟延迟，就设“5次失败+30秒超时”，熔断时间30分钟。没有银弹参数，只有贴合业务SLA的配置。

4. 实操过程与核心环节实现

4.1 从零部署LiteLLM Proxy服务

LiteLLM Proxy是生产环境推荐模式，它把模型调用变成标准HTTP服务。部署分四步，全程在Linux服务器上操作（macOS同理）：

第一步：安装与基础配置

# 创建虚拟环境（推荐，避免包冲突） python3 -m venv litellm-env source litellm-env/bin/activate pip install litellm # 设置环境变量（生产环境务必用文件管理，此处为演示） export OPENAI_API_KEY="sk-xxx" # OpenAI密钥 export ANTHROPIC_API_KEY="xxx" # Anthropic密钥 export GOOGLE_API_KEY="xxx" # Google API密钥

第二步：启动Proxy服务

# 最简启动（监听localhost:4000） litellm --host 0.0.0.0 --port 4000 # 生产环境推荐（带日志、HTTPS、认证） litellm \ --host 0.0.0.0 \ --port 4000 \ --api_key "sk-litellm-xxx" \ # Proxy自身API密钥，用于鉴权 --debug \ # 开启调试日志 --log_level debug \ --timeout 60 \ --drop_params true \ # 自动丢弃不支持的参数，避免报错 --config /path/to/config.yaml # 高级配置文件路径

启动后，你会看到日志：

INFO: Started server process [12345] INFO: Waiting for application startup. INFO: Application startup complete. INFO: Uvicorn running on http://0.0.0.0:4000 (Press CTRL+C to quit)

第三步：验证服务可用性
用curl测试OpenAI兼容接口：

curl -X POST "http://localhost:4000/v1/chat/completions" \ -H "Authorization: Bearer sk-litellm-xxx" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-3.5-turbo", "messages": [{"role": "user", "content": "hello"}], "max_tokens": 100 }'

成功响应包含"choices": [{"message": {"content": "Hello! How can I help you today?"}}]，说明Proxy工作正常。

第四步：配置高级功能（以路由为例）
创建config.yaml：

model_list: - model_name: gpt-3.5-turbo litellm_params: model: gpt-3.5-turbo api_key: ${OPENAI_API_KEY} - model_name: claude-3-haiku litellm_params: model: anthropic/claude-3-haiku-20240307 api_key: ${ANTHROPIC_API_KEY} - model_name: llama3-8b litellm_params: model: ollama/llama3:8b api_base: http://localhost:11434 router_settings: routing_strategy: "latency-based" num_retries: 3 timeout: 60

启动时指定配置：litellm --config config.yaml。LiteLLM会自动加载模型列表，并启用延迟感知路由。

注意：api_base对Ollama是必需的，因为Ollama默认监听http://localhost:11434；对OpenAI则不用，LiteLLM内置默认值。环境变量${OPENAI_API_KEY}会被自动替换，这是Uvicorn的标准特性。

4.2 在FastAPI应用中集成LiteLLM SDK

很多团队用FastAPI写后端，直接集成LiteLLM SDK比调用Proxy更高效（减少网络跳转）。以下是一个完整示例：

from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel import litellm from litellm import completion app = FastAPI() # 配置LiteLLM（生产环境建议用配置文件） litellm.set_verbose = False # 关闭调试日志，生产用 litellm.success_callback = ["langfuse"] # 可选：集成Langfuse追踪 litellm.failure_callback = ["sentry"] # 可选：错误上报Sentry class ChatRequest(BaseModel): model: str messages: list temperature: float = 0.7 max_tokens: int = 1024 @app.post("/v1/chat/completions") async def chat_completions(request: ChatRequest): try: # LiteLLM自动处理model路由、参数归一化、错误重试 response = completion( model=request.model, messages=request.messages, temperature=request.temperature, max_tokens=request.max_tokens, timeout=30, num_retries=2 # 内部重试，非fallback ) return response except Exception as e: # 统一错误处理 raise HTTPException(status_code=500, detail=str(e))

关键点解析：

• num_retries=2：这是LiteLLM内部的HTTP重试，针对网络抖动（如DNS解析失败、连接超时），不是模型fallback。它在单次请求内完成，不改变模型选择。
• success_callback：LiteLLM支持回调，langfuse会自动上报请求ID、输入、输出、延迟到Langfuse平台，用于效果分析和成本核算。
• failure_callback：sentry会捕获所有未处理异常，包括模型返回的400错误（如bad request）、429（限流）、500（服务器错误），方便快速定位问题。

我在某教育平台项目中用此模式，把LiteLLM SDK集成进FastAPI中间件。好处是：

• 请求链路短：FastAPI → LiteLLM SDK → 模型API，比FastAPI → LiteLLM Proxy → 模型API少一次HTTP跳转，P95延迟降了120ms；
• 错误上下文全：SDK能拿到原始HTTP响应头（如x-ratelimit-remaining），便于做精细化限流；
• 调试方便：本地开发时，直接print(response)就能看到完整返回，不用抓Proxy的包。

但要注意：SDK模式下，模型密钥直接写在应用代码里，必须用Secret Manager管理（如AWS Secrets Manager、HashiCorp Vault），绝不能硬编码。

4.3 模型监控与成本核算：看清每一分钱花在哪

LiteLLM内置监控能力，但需主动开启。核心是litellm.callbacks模块，它提供两个关键钩子：

1. success_callback：每次成功调用后触发，参数包含完整请求/响应、耗时、token用量；
2. failure_callback：每次失败后触发，参数包含错误类型、HTTP状态码、原始错误信息。

以下是一个成本核算示例（用SQLite存日志，便于小团队快速落地）：

import sqlite3 from litellm import success_callback, failure_callback # 初始化数据库 conn = sqlite3.connect("litellm_logs.db") conn.execute(""" CREATE TABLE IF NOT EXISTS logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp DATETIME DEFAULT CURRENT_TIMESTAMP, model TEXT, input_tokens INTEGER, output_tokens INTEGER, total_tokens INTEGER, latency REAL, status TEXT, error TEXT ) """) def log_success(kwargs): """成功回调：记录token用量和延迟""" model = kwargs["model"] input_tokens = kwargs["response"]["usage"]["prompt_tokens"] output_tokens = kwargs["response"]["usage"]["completion_tokens"] total_tokens = kwargs["response"]["usage"]["total_tokens"] latency = kwargs["response"]["_response_ms"] # LiteLLM注入的毫秒级延迟 conn.execute( "INSERT INTO logs (model, input_tokens, output_tokens, total_tokens, latency, status) VALUES (?, ?, ?, ?, ?, ?)", (model, input_tokens, output_tokens, total_tokens, latency, "success") ) conn.commit() def log_failure(kwargs): """失败回调：记录错误详情""" model = kwargs["model"] error = str(kwargs["exception"]) status_code = getattr(kwargs["exception"], "status_code", 0) conn.execute( "INSERT INTO logs (model, status, error) VALUES (?, ?, ?)", (model, f"error_{status_code}", error) ) conn.commit() # 注册回调 success_callback.append(log_success) failure_callback.append(log_failure)

每天执行SQL统计：

-- 查看各模型token消耗排名 SELECT model, SUM(total_tokens) as total_tokens FROM logs WHERE timestamp >= datetime('now', '-1 day') GROUP BY model ORDER BY total_tokens DESC; -- 查看错误率 SELECT model, COUNT(*) as total_calls, SUM(CASE WHEN status LIKE 'error%' THEN 1 ELSE 0 END) as error_count, ROUND(100.0 * SUM(CASE WHEN status LIKE 'error%' THEN 1 ELSE 0 END) / COUNT(*), 2) as error_rate FROM logs WHERE timestamp >= datetime('now', '-1 day') GROUP BY model;

实操中发现一个隐藏技巧：**LiteLLM的response对象里，_response_ms字段是精确到毫秒的端到端延迟（从发送请求到收到完整响应），而response_ms是模型内部处理时间（不含网络）。我们曾用_response_ms发现网络延迟占总耗时70%，于是把LiteLLM Proxy从北京机房迁到上海，延迟直降40%。这种细粒度数据，是优化架构的关键依据。

5. 常见问题与排查技巧实录

5.1 典型问题速查表

5.2 我踩过的三个深坑及避坑指南

坑一：环境变量污染导致密钥错乱
现象：本地开发用OpenAI，测试环境用Anthropic，但测试时总报OpenAI认证错误。
排查：print(os.environ.get("OPENAI_API_KEY"))发现测试环境竟有OPENAI_API_KEY残留。
根因：Docker容器启动时，父进程环境变量被继承，而测试环境本不该有OpenAI密钥。
避坑：LiteLLM提供litellm.drop_params = True，但更彻底的是显式清除无关环境变量：

import os # 只保留当前模型需要的密钥 os.environ.pop("OPENAI_API_KEY", None) os.environ.pop("GOOGLE_API_KEY", None) os.environ["ANTHROPIC_API_KEY"] = "xxx" # 只设Anthropic

坑二：token计数偏差引发成本误算
现象：账单显示GPT-4 Turbo消耗token远超预期，但LiteLLM日志里total_tokens却偏低。
排查：对比OpenAI官方Dashboard的token用量，发现差20%。
根因：LiteLLM的response.usage是模型返回的usage字段，但某些模型（如早期Ollama）不返回usage，LiteLLM会估算（基于字符数），而OpenAI Dashboard用更精确的tokenizer。
避坑：对关键模型，强制用官方tokenizer校验。LiteLLM支持get_token_count：

from litellm import get_token_count text = "hello world" tokens = get_token_count(text=text, model="gpt-4-turbo") # 返回12

在日志回调中，用get_token_count重算一次，取max值存入数据库，成本核算误差<1%。

坑三：流式响应中断导致前端白屏
现象：前端用SSE接收流式响应，但LiteLLM Proxy偶尔中断连接，前端收到event: error。
排查：litellm.set_verbose=True发现LiteLLM在转发流式响应时，遇到后端模型超时，会关闭连接但未发送data: [DONE]。
根因：LiteLLM的流式代理逻辑中，异常处理未完善。
避坑：前端必须实现重连机制，且后端加retry: 3000头：

# 在FastAPI中 @app.get("/stream") async def stream(): headers = {"Content-Type": "text/event-stream", "Cache-Control": "no-cache", "Connection": "keep-alive", "Retry-After": "3"} return StreamingResponse(generate_stream(), headers=headers)

同时，LiteLLM Proxy启动时加--stream_timeout 60，确保流式连接至少保持60秒。

5.3 性能调优实战：从200 QPS到2000 QPS

某客户要求客服系统支持2000并发QPS，初始部署LiteLLM Proxy只到200 QPS。我们通过三层优化达成目标：

第一层：Uvicorn参数调优
默认litellm启动用单进程，CPU利用率不足。改用多进程：

litellm \ --host 0.0.0.0 \ --port 4000 \ --workers 8 \ # 启动8个worker进程 --timeout 60 \ --keep-alive 5 \ --limit-concurrency 1000 # 限制每个worker并发数

第二层：连接池复用
LiteLLM默认为每次请求新建HTTP连接，开销大。启用连接池：

import litellm litellm.concurrent_request_limit = 1000 # 全局并发限制 litellm.max_retries = 0 # 关闭内部重试，由上层控制 # 在config.yaml中为每个模型加连接池配置 model_list: - model_name: gpt-4-turbo litellm_params: model: gpt-4-turbo api_base: https://api.openai.com/v1 # LiteLLM自动复用连接池

第三层：异步批处理
对高频小请求（如10字以内问答），用litellm.batch_completion合并：

# 一次性发10个请求，LiteLLM自动batch到同一HTTP请求 requests = [ {"model": "gpt-3.5-turbo", "messages": [{"role": "user",