1. 项目概述与核心定位litellm 这个项目简单来说就是一个统一的大模型调用中间层。它的核心价值在于你不需要为每个模型厂商单独写一套 SDK 调用代码而是通过 litellm 这一层用同一套接口格式去调用不同厂商的模型。OpenAI、Anthropic、Cohere、HuggingFace、Ollama、Azure OpenAI 等等全部统一成 OpenAI 的接口格式来调用。我第一次接触 litellm 是在一个多模型对比测试的需求里。当时项目需要同时调用三四个不同厂商的模型做效果对比如果每个都单独对接光是 API Key 管理、请求格式转换、返回结果解析这些琐事就够烦的。litellm 解决的就是这个痛点——一次接入到处调用。它适合什么人用我总结下来主要是三类第一类是做大模型应用开发的工程师需要在不同模型之间切换或做 fallback第二类是做模型评测和对比的研究人员需要快速批量调用多个模型第三类是想在自己的工具链里集成多种模型能力的开发者比如做一个聊天机器人后端可以灵活切换模型供应商。litellm 本质上是一个 Python 库同时它也提供了一个代理服务Proxy Server可以把统一接口包装成一个 HTTP 服务让非 Python 环境也能用。这个设计思路很务实既照顾了 Python 生态的开发者也照顾了其他语言或工具的调用需求。2. 核心架构与设计思路拆解2.1 为什么需要统一接口层大模型厂商的 API 格式各不相同。OpenAI 用的是chat.completions.create那套Anthropic 用的是messages.create参数命名、返回结构、错误码都有差异。如果你在一个项目里要支持多个厂商代码里就会充斥大量的 if-else 分支和适配逻辑。litellm 的做法是在中间做一层抽象。它定义了一套统一的输入输出格式基本上以 OpenAI 的格式为基准然后在内部做转换。你调用的时候只需要写completion(modelgpt-4, messages[...])或者completion(modelclaude-3-opus, messages[...])剩下的转换工作 litellm 帮你做。这个设计的好处很明显代码简洁、切换成本低、维护方便。但也要注意抽象层不可能覆盖所有厂商的所有特性。有些厂商特有的参数litellm 可能不支持或者需要通过extra_body之类的字段透传。这是使用这类统一层时要有心理准备的地方。2.2 核心模块与工作流程litellm 的核心模块大致可以分为几块模型路由层根据 model 参数判断应该调用哪个厂商的 SDK 或 API。格式转换层把统一的输入格式转换成各厂商要求的格式再把返回结果转回统一格式。认证管理层处理各厂商的 API Key、Base URL 等认证信息。重试与降级层支持失败重试、多模型 fallback。代理服务层提供 HTTP 接口支持非 Python 调用。工作流程上当你调用litellm.completion()时它会先解析 model 名称确定厂商和具体模型然后加载对应的配置转换请求格式发送请求接收响应后再转换回统一格式返回。注意model 名称的写法有约定。比如 OpenAI 的模型直接写gpt-4Anthropic 的写claude-3-opus-20240229Ollama 的写ollama/llama2。这个命名规则要记清楚写错了会报错。2.3 与直接调用 SDK 的对比直接调用各厂商 SDK 的优势是控制力强、特性支持完整。厂商出了新功能SDK 第一时间支持而 litellm 需要跟进适配。但劣势也很明显代码重复、维护成本高、切换模型要改代码。litellm 的优势是开发效率高、切换灵活、统一管理。劣势是可能有特性滞后、抽象层可能带来额外调试成本。我的建议是如果你的项目只需要调用一个厂商的模型直接用官方 SDK 就行没必要引入 litellm。但如果你需要调用两个以上厂商的模型或者需要做模型 fallback、负载均衡那 litellm 的价值就体现出来了。3. 环境准备与基础配置实操3.1 安装与版本选择litellm 的安装很简单pip install litellm如果你需要用到代理服务功能还需要安装额外的依赖pip install litellm[proxy]版本选择上litellm 迭代比较快建议用较新的稳定版。我一般会指定一个具体版本避免自动升级带来的意外问题pip install litellm1.40.0提示litellm 的版本更新频率很高不同版本之间 API 可能有细微变化。生产环境建议锁定版本升级前先在测试环境验证。3.2 API Key 管理litellm 支持通过环境变量读取 API Key这是最推荐的方式export OPENAI_API_KEYyour-openai-key export ANTHROPIC_API_KEYyour-anthropic-key export COHERE_API_KEYyour-cohere-key也可以在代码里直接传import litellm response litellm.completion( modelgpt-4, messages[{role: user, content: 你好}], api_keyyour-key )但硬编码 Key 不安全不建议在生产环境这么做。环境变量或者配置文件是更好的选择。3.3 基础调用示例最简单的调用长这样import litellm response litellm.completion( modelgpt-4, messages[ {role: system, content: 你是一个有用的助手。}, {role: user, content: 用一句话解释什么是机器学习。} ] ) print(response.choices[0].message.content)切换模型只需要改model参数response litellm.completion( modelclaude-3-sonnet-20240229, messages[{role: user, content: 你好}] )这就是 litellm 最核心的用法。你不需要改其他任何代码只需要改模型名称。4. 进阶功能与实战技巧4.1 多模型 Fallback 配置这是 litellm 很实用的一个功能。你可以配置一个模型列表当第一个模型调用失败时自动尝试下一个response litellm.completion( modelgpt-4, messages[{role: user, content: 你好}], fallbacks[claude-3-sonnet-20240229, command-r-plus] )这个功能在实际生产环境里很有价值。比如 OpenAI 偶尔会限流或宕机配置了 fallback 之后服务不会直接挂掉而是自动切换到备用模型。我实测下来的经验是fallback 列表不要配太多两到三个就够了。太多的话一旦主模型和第一备用都挂了请求会依次尝试延迟会累积得很高。另外不同模型的输出风格可能差异较大fallback 切换后用户可能会感知到回复风格的变化这点要有预期。4.2 流式输出与异步调用litellm 支持流式输出用法和 OpenAI SDK 类似response litellm.completion( modelgpt-4, messages[{role: user, content: 写一首短诗}], streamTrue ) for chunk in response: content chunk.choices[0].delta.content if content: print(content, end)异步调用用acompletionimport asyncio import litellm async def main(): response await litellm.acompletion( modelgpt-4, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content) asyncio.run(main())异步在批量调用场景下很有用。比如你要同时调用 10 个模型做对比用异步可以并发发送请求总耗时取决于最慢的那个而不是所有请求耗时之和。4.3 代理服务模式部署如果你需要让非 Python 环境也能调用统一接口可以启动 litellm 的代理服务litellm --model gpt-4 --port 8000或者用配置文件model_list: - model_name: gpt-4 litellm_params: model: gpt-4 api_key: os.environ/OPENAI_API_KEY - model_name: claude-3 litellm_params: model: claude-3-sonnet-20240229 api_key: os.environ/ANTHROPIC_API_KEY启动litellm --config config.yaml --port 8000然后就可以用 HTTP 请求调用了curl http://localhost:8000/chat/completions \ -H Content-Type: application/json \ -d { model: gpt-4, messages: [{role: user, content: 你好}] }代理模式的好处是统一入口、集中管理 Key、支持多语言调用。但也要注意代理服务本身需要做好安全防护不要直接暴露在公网。4.4 成本追踪与预算控制litellm 内置了成本追踪功能。每次调用后可以通过response._hidden_params或者回调机制获取本次调用的成本估算from litellm import completion, completion_cost response completion( modelgpt-4, messages[{role: user, content: 你好}] ) cost completion_cost(completion_responseresponse) print(f本次调用成本: ${cost:.6f})这个功能在做成本敏感型应用时很有用。你可以设置预算上限超过后自动拒绝请求litellm.max_budget 10.0 # 最大预算 10 美元注意成本计算是基于 litellm 内置的价格表可能和厂商实际计费有细微差异。价格表更新也可能滞后建议定期核对。5. 常见问题与排查技巧实录5.1 模型名称写错导致调用失败这是最常见的问题。litellm 的模型命名有约定写错了会报BadRequestError或NotFoundError。排查方法先确认厂商再确认模型名称。比如 Anthropic 的模型通常带日期后缀claude-3-sonnet-20240229和claude-3-sonnet可能行为不同。Ollama 的模型需要加ollama/前缀。5.2 API Key 未正确加载如果报认证错误先检查环境变量是否设置正确echo $OPENAI_API_KEY在 Python 里也可以检查import os print(os.environ.get(OPENAI_API_KEY))如果用的是代理模式检查配置文件里的api_key字段是否正确引用了环境变量。5.3 超时与重试配置默认超时可能不够用特别是调用较慢的模型时。可以这样配置response litellm.completion( modelgpt-4, messages[{role: user, content: 你好}], timeout60, num_retries3 )num_retries控制重试次数timeout控制单次请求超时时间。重试策略上我一般设置 2-3 次太多会拖长整体响应时间。5.4 常见问题速查表问题现象可能原因解决方法认证失败API Key 未设置或错误检查环境变量或配置文件模型不存在模型名称写错核对厂商和模型命名规则请求超时网络问题或模型响应慢增加 timeout配置重试返回格式异常厂商 API 变更升级 litellm 版本成本计算不准价格表滞后手动核对厂商价格流式输出中断网络不稳定增加重试检查网络5.5 独家避坑经验第一个坑不要在生产环境用最新版。litellm 更新快新版本可能引入不兼容变更。我一般会等新版本发布一两周后再升级。第二个坑fallback 模型的输出格式可能不一致。不同模型对同一 prompt 的回复风格差异很大如果你的应用对输出格式有严格要求fallback 后可能需要额外的格式校验。第三个坑代理模式的并发性能。litellm 代理服务默认是单进程的高并发场景下需要配合 gunicorn 或 uvicorn 多 worker 部署。第四个坑成本追踪的精度。litellm 的成本计算是基于 token 数量和内置价格表但有些厂商的计费规则更复杂比如缓存命中、批量折扣实际成本和估算可能有偏差。6. 实际项目中的集成建议6.1 在 Web 应用中的集成模式如果你在做一个 Web 应用我建议把 litellm 封装成一个服务层而不是在业务代码里直接调用。这样可以统一处理错误、日志、成本追踪等横切关注点。class LLMService: def __init__(self, default_modelgpt-4): self.default_model default_model def chat(self, messages, modelNone, **kwargs): model model or self.default_model try: response litellm.completion( modelmodel, messagesmessages, **kwargs ) return response.choices[0].message.content except Exception as e: # 统一错误处理 raise LLMServiceError(f调用失败: {e})6.2 批量评测场景的用法做模型评测时litellm 的优势特别明显。你可以写一个循环遍历所有待测模型models [gpt-4, claude-3-sonnet-20240229, command-r-plus] test_prompts [解释什么是过拟合, 写一个快速排序] for model in models: for prompt in test_prompts: response litellm.completion( modelmodel, messages[{role: user, content: prompt}] ) # 记录结果如果数据量大建议用异步并发能显著缩短总耗时。6.3 与 LangChain 等框架的配合litellm 可以和 LangChain 配合使用。LangChain 有 litellm 的集成包可以把 litellm 作为 LangChain 的 LLM 后端from langchain_community.chat_models import ChatLiteLLM llm ChatLiteLLM(modelgpt-4) response llm.invoke(你好)这样你既能用 LangChain 的链式编排能力又能用 litellm 的多模型统一调用能力。7. 性能优化与生产部署要点7.1 连接池与并发控制litellm 底层用的是 httpx支持连接池。在高并发场景下合理配置连接池可以显著提升性能import litellm litellm.client_session httpx.Client( limitshttpx.Limits(max_connections100, max_keepalive_connections20) )并发控制上建议根据厂商的限流策略设置合理的并发数。OpenAI 的限流比较严格并发太高会触发 429 错误。7.2 缓存策略litellm 支持缓存可以把相同请求的结果缓存起来避免重复调用import litellm from litellm.caching import Cache litellm.cache Cache(typeredis, hostlocalhost, port6379)缓存对成本敏感型应用很有价值。但要注意缓存 key 是基于请求参数的如果 prompt 有细微变化缓存就不会命中。7.3 日志与监控生产环境建议开启详细日志方便排查问题import litellm litellm.set_verbose True也可以配置回调把调用记录发送到监控系统def log_callback(kwargs, completion_response, start_time, end_time): # 记录日志 pass litellm.success_callback [log_callback] litellm.failure_callback [log_callback]7.4 部署架构建议小规模使用直接 pip 安装代码里调用就行。中等规模建议用代理模式配合 gunicorn 多 worker 部署。大规模生产环境建议在 litellm 代理前面加一层网关做认证、限流、监控litellm 代理本身做多实例部署后端接 Redis 做缓存和状态共享。我在实际项目里踩过的一个坑是代理服务默认没有认证如果直接暴露在公网任何人都能调用你的模型消耗你的额度。一定要加上认证层或者只在内网使用。8. 版本演进与生态观察litellm 的迭代速度很快几乎每周都有新版本。从我用下来的感受看它在几个方向上持续投入支持的模型厂商越来越多、代理服务功能越来越完善、成本追踪和预算控制越来越精细。但快速迭代也带来一些问题。文档有时候跟不上代码变化某些功能的用法在不同版本间有差异。我的建议是关注官方 GitHub 的 Release Notes升级前先看变更说明重要项目锁定版本。生态方面litellm 已经和不少工具链做了集成比如 LangChain、LlamaIndex、Flowise 等。这意味着你可以在这些工具里直接选用 litellm 作为模型调用层而不需要自己写适配代码。从趋势上看统一模型调用层这个需求是真实存在的而且会越来越强烈。模型厂商越来越多应用层不可能为每个厂商都写一套适配。litellm 这类项目解决的是基础设施层面的问题价值会随着模型生态的碎片化而增加。不过也要看到这个领域竞争也在加剧。有些云厂商自己在做统一接口有些开源项目也在做类似的事情。litellm 能不能保持优势取决于它的适配速度、稳定性和社区活跃度。从我目前的使用体验看它在这几个方面做得还不错。最后分享一个小技巧如果你在调试时遇到问题可以把litellm.set_verbose True打开它会打印详细的请求和响应信息对排查问题很有帮助。但生产环境记得关掉否则日志量会很大。
1. 项目概述与核心定位litellm 这个项目简单来说就是一个统一的大模型调用中间层。它的核心价值在于你不需要为每个模型厂商单独写一套 SDK 调用代码而是通过 litellm 这一层用同一套接口格式去调用不同厂商的模型。OpenAI、Anthropic、Cohere、HuggingFace、Ollama、Azure OpenAI 等等全部统一成 OpenAI 的接口格式来调用。我第一次接触 litellm 是在一个多模型对比测试的需求里。当时项目需要同时调用三四个不同厂商的模型做效果对比如果每个都单独对接光是 API Key 管理、请求格式转换、返回结果解析这些琐事就够烦的。litellm 解决的就是这个痛点——一次接入到处调用。它适合什么人用我总结下来主要是三类第一类是做大模型应用开发的工程师需要在不同模型之间切换或做 fallback第二类是做模型评测和对比的研究人员需要快速批量调用多个模型第三类是想在自己的工具链里集成多种模型能力的开发者比如做一个聊天机器人后端可以灵活切换模型供应商。litellm 本质上是一个 Python 库同时它也提供了一个代理服务Proxy Server可以把统一接口包装成一个 HTTP 服务让非 Python 环境也能用。这个设计思路很务实既照顾了 Python 生态的开发者也照顾了其他语言或工具的调用需求。2. 核心架构与设计思路拆解2.1 为什么需要统一接口层大模型厂商的 API 格式各不相同。OpenAI 用的是chat.completions.create那套Anthropic 用的是messages.create参数命名、返回结构、错误码都有差异。如果你在一个项目里要支持多个厂商代码里就会充斥大量的 if-else 分支和适配逻辑。litellm 的做法是在中间做一层抽象。它定义了一套统一的输入输出格式基本上以 OpenAI 的格式为基准然后在内部做转换。你调用的时候只需要写completion(modelgpt-4, messages[...])或者completion(modelclaude-3-opus, messages[...])剩下的转换工作 litellm 帮你做。这个设计的好处很明显代码简洁、切换成本低、维护方便。但也要注意抽象层不可能覆盖所有厂商的所有特性。有些厂商特有的参数litellm 可能不支持或者需要通过extra_body之类的字段透传。这是使用这类统一层时要有心理准备的地方。2.2 核心模块与工作流程litellm 的核心模块大致可以分为几块模型路由层根据 model 参数判断应该调用哪个厂商的 SDK 或 API。格式转换层把统一的输入格式转换成各厂商要求的格式再把返回结果转回统一格式。认证管理层处理各厂商的 API Key、Base URL 等认证信息。重试与降级层支持失败重试、多模型 fallback。代理服务层提供 HTTP 接口支持非 Python 调用。工作流程上当你调用litellm.completion()时它会先解析 model 名称确定厂商和具体模型然后加载对应的配置转换请求格式发送请求接收响应后再转换回统一格式返回。注意model 名称的写法有约定。比如 OpenAI 的模型直接写gpt-4Anthropic 的写claude-3-opus-20240229Ollama 的写ollama/llama2。这个命名规则要记清楚写错了会报错。2.3 与直接调用 SDK 的对比直接调用各厂商 SDK 的优势是控制力强、特性支持完整。厂商出了新功能SDK 第一时间支持而 litellm 需要跟进适配。但劣势也很明显代码重复、维护成本高、切换模型要改代码。litellm 的优势是开发效率高、切换灵活、统一管理。劣势是可能有特性滞后、抽象层可能带来额外调试成本。我的建议是如果你的项目只需要调用一个厂商的模型直接用官方 SDK 就行没必要引入 litellm。但如果你需要调用两个以上厂商的模型或者需要做模型 fallback、负载均衡那 litellm 的价值就体现出来了。3. 环境准备与基础配置实操3.1 安装与版本选择litellm 的安装很简单pip install litellm如果你需要用到代理服务功能还需要安装额外的依赖pip install litellm[proxy]版本选择上litellm 迭代比较快建议用较新的稳定版。我一般会指定一个具体版本避免自动升级带来的意外问题pip install litellm1.40.0提示litellm 的版本更新频率很高不同版本之间 API 可能有细微变化。生产环境建议锁定版本升级前先在测试环境验证。3.2 API Key 管理litellm 支持通过环境变量读取 API Key这是最推荐的方式export OPENAI_API_KEYyour-openai-key export ANTHROPIC_API_KEYyour-anthropic-key export COHERE_API_KEYyour-cohere-key也可以在代码里直接传import litellm response litellm.completion( modelgpt-4, messages[{role: user, content: 你好}], api_keyyour-key )但硬编码 Key 不安全不建议在生产环境这么做。环境变量或者配置文件是更好的选择。3.3 基础调用示例最简单的调用长这样import litellm response litellm.completion( modelgpt-4, messages[ {role: system, content: 你是一个有用的助手。}, {role: user, content: 用一句话解释什么是机器学习。} ] ) print(response.choices[0].message.content)切换模型只需要改model参数response litellm.completion( modelclaude-3-sonnet-20240229, messages[{role: user, content: 你好}] )这就是 litellm 最核心的用法。你不需要改其他任何代码只需要改模型名称。4. 进阶功能与实战技巧4.1 多模型 Fallback 配置这是 litellm 很实用的一个功能。你可以配置一个模型列表当第一个模型调用失败时自动尝试下一个response litellm.completion( modelgpt-4, messages[{role: user, content: 你好}], fallbacks[claude-3-sonnet-20240229, command-r-plus] )这个功能在实际生产环境里很有价值。比如 OpenAI 偶尔会限流或宕机配置了 fallback 之后服务不会直接挂掉而是自动切换到备用模型。我实测下来的经验是fallback 列表不要配太多两到三个就够了。太多的话一旦主模型和第一备用都挂了请求会依次尝试延迟会累积得很高。另外不同模型的输出风格可能差异较大fallback 切换后用户可能会感知到回复风格的变化这点要有预期。4.2 流式输出与异步调用litellm 支持流式输出用法和 OpenAI SDK 类似response litellm.completion( modelgpt-4, messages[{role: user, content: 写一首短诗}], streamTrue ) for chunk in response: content chunk.choices[0].delta.content if content: print(content, end)异步调用用acompletionimport asyncio import litellm async def main(): response await litellm.acompletion( modelgpt-4, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content) asyncio.run(main())异步在批量调用场景下很有用。比如你要同时调用 10 个模型做对比用异步可以并发发送请求总耗时取决于最慢的那个而不是所有请求耗时之和。4.3 代理服务模式部署如果你需要让非 Python 环境也能调用统一接口可以启动 litellm 的代理服务litellm --model gpt-4 --port 8000或者用配置文件model_list: - model_name: gpt-4 litellm_params: model: gpt-4 api_key: os.environ/OPENAI_API_KEY - model_name: claude-3 litellm_params: model: claude-3-sonnet-20240229 api_key: os.environ/ANTHROPIC_API_KEY启动litellm --config config.yaml --port 8000然后就可以用 HTTP 请求调用了curl http://localhost:8000/chat/completions \ -H Content-Type: application/json \ -d { model: gpt-4, messages: [{role: user, content: 你好}] }代理模式的好处是统一入口、集中管理 Key、支持多语言调用。但也要注意代理服务本身需要做好安全防护不要直接暴露在公网。4.4 成本追踪与预算控制litellm 内置了成本追踪功能。每次调用后可以通过response._hidden_params或者回调机制获取本次调用的成本估算from litellm import completion, completion_cost response completion( modelgpt-4, messages[{role: user, content: 你好}] ) cost completion_cost(completion_responseresponse) print(f本次调用成本: ${cost:.6f})这个功能在做成本敏感型应用时很有用。你可以设置预算上限超过后自动拒绝请求litellm.max_budget 10.0 # 最大预算 10 美元注意成本计算是基于 litellm 内置的价格表可能和厂商实际计费有细微差异。价格表更新也可能滞后建议定期核对。5. 常见问题与排查技巧实录5.1 模型名称写错导致调用失败这是最常见的问题。litellm 的模型命名有约定写错了会报BadRequestError或NotFoundError。排查方法先确认厂商再确认模型名称。比如 Anthropic 的模型通常带日期后缀claude-3-sonnet-20240229和claude-3-sonnet可能行为不同。Ollama 的模型需要加ollama/前缀。5.2 API Key 未正确加载如果报认证错误先检查环境变量是否设置正确echo $OPENAI_API_KEY在 Python 里也可以检查import os print(os.environ.get(OPENAI_API_KEY))如果用的是代理模式检查配置文件里的api_key字段是否正确引用了环境变量。5.3 超时与重试配置默认超时可能不够用特别是调用较慢的模型时。可以这样配置response litellm.completion( modelgpt-4, messages[{role: user, content: 你好}], timeout60, num_retries3 )num_retries控制重试次数timeout控制单次请求超时时间。重试策略上我一般设置 2-3 次太多会拖长整体响应时间。5.4 常见问题速查表问题现象可能原因解决方法认证失败API Key 未设置或错误检查环境变量或配置文件模型不存在模型名称写错核对厂商和模型命名规则请求超时网络问题或模型响应慢增加 timeout配置重试返回格式异常厂商 API 变更升级 litellm 版本成本计算不准价格表滞后手动核对厂商价格流式输出中断网络不稳定增加重试检查网络5.5 独家避坑经验第一个坑不要在生产环境用最新版。litellm 更新快新版本可能引入不兼容变更。我一般会等新版本发布一两周后再升级。第二个坑fallback 模型的输出格式可能不一致。不同模型对同一 prompt 的回复风格差异很大如果你的应用对输出格式有严格要求fallback 后可能需要额外的格式校验。第三个坑代理模式的并发性能。litellm 代理服务默认是单进程的高并发场景下需要配合 gunicorn 或 uvicorn 多 worker 部署。第四个坑成本追踪的精度。litellm 的成本计算是基于 token 数量和内置价格表但有些厂商的计费规则更复杂比如缓存命中、批量折扣实际成本和估算可能有偏差。6. 实际项目中的集成建议6.1 在 Web 应用中的集成模式如果你在做一个 Web 应用我建议把 litellm 封装成一个服务层而不是在业务代码里直接调用。这样可以统一处理错误、日志、成本追踪等横切关注点。class LLMService: def __init__(self, default_modelgpt-4): self.default_model default_model def chat(self, messages, modelNone, **kwargs): model model or self.default_model try: response litellm.completion( modelmodel, messagesmessages, **kwargs ) return response.choices[0].message.content except Exception as e: # 统一错误处理 raise LLMServiceError(f调用失败: {e})6.2 批量评测场景的用法做模型评测时litellm 的优势特别明显。你可以写一个循环遍历所有待测模型models [gpt-4, claude-3-sonnet-20240229, command-r-plus] test_prompts [解释什么是过拟合, 写一个快速排序] for model in models: for prompt in test_prompts: response litellm.completion( modelmodel, messages[{role: user, content: prompt}] ) # 记录结果如果数据量大建议用异步并发能显著缩短总耗时。6.3 与 LangChain 等框架的配合litellm 可以和 LangChain 配合使用。LangChain 有 litellm 的集成包可以把 litellm 作为 LangChain 的 LLM 后端from langchain_community.chat_models import ChatLiteLLM llm ChatLiteLLM(modelgpt-4) response llm.invoke(你好)这样你既能用 LangChain 的链式编排能力又能用 litellm 的多模型统一调用能力。7. 性能优化与生产部署要点7.1 连接池与并发控制litellm 底层用的是 httpx支持连接池。在高并发场景下合理配置连接池可以显著提升性能import litellm litellm.client_session httpx.Client( limitshttpx.Limits(max_connections100, max_keepalive_connections20) )并发控制上建议根据厂商的限流策略设置合理的并发数。OpenAI 的限流比较严格并发太高会触发 429 错误。7.2 缓存策略litellm 支持缓存可以把相同请求的结果缓存起来避免重复调用import litellm from litellm.caching import Cache litellm.cache Cache(typeredis, hostlocalhost, port6379)缓存对成本敏感型应用很有价值。但要注意缓存 key 是基于请求参数的如果 prompt 有细微变化缓存就不会命中。7.3 日志与监控生产环境建议开启详细日志方便排查问题import litellm litellm.set_verbose True也可以配置回调把调用记录发送到监控系统def log_callback(kwargs, completion_response, start_time, end_time): # 记录日志 pass litellm.success_callback [log_callback] litellm.failure_callback [log_callback]7.4 部署架构建议小规模使用直接 pip 安装代码里调用就行。中等规模建议用代理模式配合 gunicorn 多 worker 部署。大规模生产环境建议在 litellm 代理前面加一层网关做认证、限流、监控litellm 代理本身做多实例部署后端接 Redis 做缓存和状态共享。我在实际项目里踩过的一个坑是代理服务默认没有认证如果直接暴露在公网任何人都能调用你的模型消耗你的额度。一定要加上认证层或者只在内网使用。8. 版本演进与生态观察litellm 的迭代速度很快几乎每周都有新版本。从我用下来的感受看它在几个方向上持续投入支持的模型厂商越来越多、代理服务功能越来越完善、成本追踪和预算控制越来越精细。但快速迭代也带来一些问题。文档有时候跟不上代码变化某些功能的用法在不同版本间有差异。我的建议是关注官方 GitHub 的 Release Notes升级前先看变更说明重要项目锁定版本。生态方面litellm 已经和不少工具链做了集成比如 LangChain、LlamaIndex、Flowise 等。这意味着你可以在这些工具里直接选用 litellm 作为模型调用层而不需要自己写适配代码。从趋势上看统一模型调用层这个需求是真实存在的而且会越来越强烈。模型厂商越来越多应用层不可能为每个厂商都写一套适配。litellm 这类项目解决的是基础设施层面的问题价值会随着模型生态的碎片化而增加。不过也要看到这个领域竞争也在加剧。有些云厂商自己在做统一接口有些开源项目也在做类似的事情。litellm 能不能保持优势取决于它的适配速度、稳定性和社区活跃度。从我目前的使用体验看它在这几个方面做得还不错。最后分享一个小技巧如果你在调试时遇到问题可以把litellm.set_verbose True打开它会打印详细的请求和响应信息对排查问题很有帮助。但生产环境记得关掉否则日志量会很大。
