1. 从一个真实困境说起多模型调用的碎片化之痛如果你正在做AI应用开发大概率遇到过这样的场景项目初期用OpenAI的接口跑通了原型效果不错上线后想接入Claude做备用模型或者想用国产模型降低推理成本结果发现每家的SDK、鉴权方式、请求格式、返回结构都不一样。你不得不为每个模型写一套适配层代码里到处是if-else分支维护成本直线上升。更麻烦的是当你想要对比不同模型在同一个任务上的表现时需要反复切换API Key、改base_url、调整参数格式测试脚本改到怀疑人生。团队里如果有人想从OpenAI切到其他模型做A/B测试光是环境配置就能耗掉半天。这就是litellm要解决的核心问题。它本质上是一个统一的LLM调用层用一套OpenAI风格的接口去调用市面上几乎所有主流大模型。你只需要把base_url和API Key换一下代码几乎不用动就能在OpenAI、Anthropic、Cohere、HuggingFace、Ollama以及各类兼容OpenAI协议的服务之间自由切换。这篇文章适合三类人看一是正在做多模型集成的后端开发者二是需要快速对比模型效果做技术选型的算法工程师三是想在自己项目里加一个模型热插拔能力的独立开发者。我会从实际使用角度出发把litellm的核心机制、配置细节、踩坑经验和进阶玩法讲透让你看完就能直接上手。2. litellm到底做了什么统一接口背后的映射逻辑2.1 核心设计思路用一套协议吃掉所有差异litellm最核心的价值在于它定义了一套标准化的请求与响应格式然后为每个支持的模型提供商写了一个适配器。当你调用completion(modelclaude-3-sonnet, messages[...])时litellm内部会做几件事第一解析model参数识别出这是Anthropic的模型找到对应的适配器。第二把你传入的OpenAI格式的messages转换成Anthropic要求的格式比如system消息要单独提取出来不能放在messages数组里。第三把参数名做映射比如OpenAI的max_tokens在Anthropic里叫max_tokens_to_samplelitellm会自动转换。第四发送请求后把返回结果再转回OpenAI的响应结构让你拿到的response.choices[0].message.content和调OpenAI时一模一样。这个映射逻辑听起来简单但实际覆盖的细节非常多。比如流式响应的处理不同厂商的SSE格式差异很大litellm在中间做了一层归一化保证你拿到的chunk结构一致。再比如function callingOpenAI叫toolsAnthropic叫tools但参数结构不同litellm也做了统一。2.2 支持的模型范围与路由策略litellm目前支持的模型列表相当长我整理了几类常用的提供商类型代表模型接入方式闭源商业APIGPT-4o、Claude-3.5、Gemini Pro官方API Key开源模型托管Llama-3、Mistral、QwenTogether、Fireworks等平台本地部署Ollama、vLLM、LM Studio本地endpoint兼容OpenAI协议各类自建推理服务自定义base_url路由策略上litellm支持几种模式。最简单的是直接指定模型名它会自动路由到对应的提供商。你也可以用modelopenai/gpt-4o这种带前缀的写法显式指定提供商避免歧义。更高级的用法是配置fallback列表当主模型调用失败时自动切换到备用模型这对生产环境的稳定性很有帮助。2.3 为什么不用LangChain的LLM抽象很多人会问LangChain不是也有多模型支持吗为什么还要用litellm我的实际体验是LangChain的抽象层太重了。它把LLM调用和Chain、Agent、Memory等概念耦合在一起你只想调个模型却要引入一大堆依赖。而且LangChain的版本迭代快API经常变升级一次可能就要改代码。litellm的定位更纯粹它就是一层薄薄的适配器不涉及编排逻辑不强制你用什么框架。你可以把它当成一个独立的工具库在FastAPI、Flask、Django或者纯脚本里都能用。这种只做一件事的设计哲学在实际项目中反而更灵活。3. 环境搭建与最小可运行示例3.1 安装与依赖管理安装litellm很简单pip install litellm但这里有个坑要注意litellm的依赖包比较多如果你在一个已有项目里安装可能会和现有的openai、anthropic等SDK版本冲突。我的建议是在虚拟环境里先装litellm再装其他包让它自己决定依赖版本。如果你只需要用某几个提供商可以按需安装pip install litellm[openai,anthropic]这样能减少不必要的依赖。litellm的extras机制做得不错支持[proxy]、[all]等多种组合。3.2 环境变量配置的规范做法litellm读取API Key的方式是环境变量。每个提供商对应的变量名不同export OPENAI_API_KEYsk-xxx export ANTHROPIC_API_KEYsk-ant-xxx export COHERE_API_KEYxxx我习惯用.env文件管理这些密钥配合python-dotenv加载from dotenv import load_dotenv load_dotenv() from litellm import completion response completion( modelgpt-4o, messages[{role: user, content: 用一句话解释什么是向量数据库}] ) print(response.choices[0].message.content)注意不要把API Key硬编码在代码里也不要把.env提交到Git仓库。我见过太多因为密钥泄露导致账单暴涨的案例。3.3 第一个跨模型调用示例下面这段代码演示了如何用同一个函数调用三个不同厂商的模型from litellm import completion def ask(model, question): response completion( modelmodel, messages[{role: user, content: question}], temperature0.7, max_tokens500 ) return response.choices[0].message.content models [gpt-4o, claude-3-5-sonnet-20241022, command-r-plus] for m in models: print(f--- {m} ---) print(ask(m, 解释一下Transformer的自注意力机制))实测下来这段代码可以直接跑通不需要为每个模型写额外的适配代码。唯一需要注意的是不同模型的max_tokens上限不同如果设得太大某些模型会报错。4. 参数映射与响应结构的那些坑4.1 参数名不一致的自动转换litellm帮你做了参数名的映射但不是所有参数都能完美对应。我整理了几个常见的差异OpenAI参数Anthropic对应注意事项max_tokensmax_tokens必填且上限不同temperaturetemperature范围都是0-1top_ptop_p一致stopstop_sequences参数名不同presence_penalty不支持会被忽略当你传入一个目标模型不支持的参数时litellm默认会忽略它而不是报错。这个行为有利有弊好处是代码兼容性好坏处是你可能以为参数生效了实际上被静默丢弃了。我的做法是在关键参数上做显式检查比如response completion( modelclaude-3-5-sonnet-20241022, messagesmessages, max_tokens1000, temperature0.5 )对于不支持的参数我会在代码注释里标明避免团队成员误用。4.2 流式响应的统一处理流式输出是很多应用的刚需。litellm的流式接口用起来和OpenAI一致response completion( modelgpt-4o, messages[{role: user, content: 写一首关于秋天的诗}], streamTrue ) for chunk in response: content chunk.choices[0].delta.content if content: print(content, end, flushTrue)但这里有个细节不同厂商的流式chunk结构在litellm归一化之前差异很大。比如Anthropic的流式响应里第一个chunk可能是message_start类型最后一个可能是message_stop中间才是content_block_delta。litellm把这些都转成了统一的delta结构你不需要关心底层差异。不过实测中发现某些国产模型的流式实现不太规范可能会出现chunk丢失或顺序错乱的情况。如果遇到这种问题建议先用非流式模式验证功能再排查流式实现。4.3 错误处理与重试机制生产环境里API调用失败是常态。litellm内置了重试逻辑可以通过参数控制response completion( modelgpt-4o, messagesmessages, num_retries3, timeout30 )num_retries指定重试次数timeout指定超时时间。litellm会对某些错误类型自动重试比如速率限制429和服务器错误5xx。但对于认证失败401这种错误重试没有意义litellm会直接抛出异常。我建议在调用层再包一层自己的异常处理from litellm.exceptions import RateLimitError, APIError try: response completion(...) except RateLimitError: # 触发降级逻辑或排队等待 pass except APIError as e: # 记录日志切换到备用模型 pass5. 进阶玩法代理服务与模型路由5.1 用litellm proxy搭建统一网关如果你在团队里推广litellm不可能让每个人都去配环境变量。这时候可以用litellm的proxy模式起一个本地服务所有请求都走这个网关litellm --model gpt-4o --port 8000然后你的代码里只需要把base_url指向这个服务from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000, api_keyanything) response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: hello}] )这样做的好处是密钥集中在网关管理团队成员不需要各自配置可以在网关上做统一的日志、限流、计费统计切换模型时只需要改网关配置客户端代码不动。proxy模式还支持配置文件可以定义多个模型、路由规则、fallback策略。配置文件用YAML格式model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: claude litellm_params: model: anthropic/claude-3-5-sonnet-20241022 api_key: os.environ/ANTHROPIC_API_KEY router_settings: fallbacks: [{gpt-4o: [claude]}]这个配置定义了两个模型并且设置了fallback当gpt-4o调用失败时自动切换到claude。5.2 基于成本的智能路由litellm的router支持更复杂的路由策略比如根据成本选择最便宜的可用模型from litellm import Router router Router( model_list[ {model_name: cheap, litellm_params: {model: gpt-4o-mini}}, {model_name: expensive, litellm_params: {model: gpt-4o}}, ], routing_strategycost-based-routing )不过说实话成本路由在实际项目里用得不多因为不同模型的能力差异太大单纯看价格选模型往往效果不好。更实用的是基于延迟的路由把请求发给响应最快的模型。5.3 缓存机制减少重复调用litellm支持多种缓存后端包括内存、Redis、磁盘。开启缓存后相同的请求会直接返回缓存结果省时省钱import litellm litellm.cache litellm.Cache(typeredis, hostlocalhost, port6379) response completion( modelgpt-4o, messages[{role: user, content: 什么是RAG}], cachingTrue )缓存的key是根据请求参数生成的哈希值。如果你希望某些请求不走缓存可以设置cachingFalse。需要注意的是缓存对温度参数敏感temperature0的请求缓存命中率最高。6. 实战中的经验与避坑清单6.1 模型名称的坑litellm的模型命名规则有时候不太直观。比如Claude的模型名要带日期后缀claude-3-5-sonnet-20241022和claude-3-5-sonnet可能指向不同的版本。我建议始终使用完整的模型名避免因为版本更新导致行为变化。另外某些模型需要通过特定前缀指定提供商。比如ollama/llama3表示用Ollama本地部署的Llama3together_ai/meta-llama/Llama-3-70b表示用Together平台托管的Llama3。如果不加前缀litellm可能会猜错提供商。6.2 Token计数与成本估算litellm提供了token计数功能from litellm import token_counter count token_counter(modelgpt-4o, messages[{role: user, content: hello}]) print(count)但要注意不同模型的tokenizer不同计数结果会有差异。litellm内部用的是tiktoken做估算对于OpenAI系列模型比较准对于其他模型可能偏差较大。如果需要精确计费建议以提供商返回的usage字段为准。成本估算方面litellm内置了价格表可以通过completion_cost函数计算from litellm import completion_cost cost completion_cost(completion_responseresponse)这个价格表更新不一定及时如果对成本敏感建议自己维护一份价格配置。6.3 并发调用与速率限制批量调用多个模型时很容易触发速率限制。我的做法是用asyncio配合信号量控制并发import asyncio from litellm import acompletion async def call_model(model, question, semaphore): async with semaphore: response await acompletion( modelmodel, messages[{role: user, content: question}] ) return response.choices[0].message.content async def main(): semaphore asyncio.Semaphore(5) tasks [call_model(m, test, semaphore) for m in models] results await asyncio.gather(*tasks) return results信号量设为5表示最多同时5个请求。具体数值要根据提供商的速率限制调整。OpenAI的免费额度通常限制比较严付费账户会宽松很多。6.4 日志与可观测性litellm可以输出详细的调用日志方便排查问题import litellm litellm.set_verbose True开启后每次调用都会打印请求参数、响应内容、耗时等信息。生产环境建议把日志接入统一的日志系统而不是直接打印到控制台。另外litellm支持回调机制可以在调用前后执行自定义逻辑def log_callback(kwargs, completion_response, start_time, end_time): # 记录到数据库或监控系统 pass litellm.success_callback [log_callback]这个机制可以用来做用量统计、异常告警、性能监控等。7. 我对litellm的实际使用体会用了一年多litellm最大的感受是它确实解决了多模型调用的碎片化问题但也不是银弹。它的优势在于轻量、灵活、上手快适合快速原型和中小型项目。但如果你的项目对性能要求极高或者需要深度定制某个提供商的特性可能还是直接调原生SDK更合适。另外litellm的版本迭代比较快升级时要注意看changelog有些breaking change不会在文档里特别标注。我的习惯是锁定版本号在测试环境验证后再升级生产环境。最后分享一个小技巧如果你不确定某个模型名怎么写可以用litellm.model_list查看所有支持的模型或者直接看源码里的model_prices_and_context_window.json文件里面列出了所有模型及其参数。这个文件也是更新价格表的地方如果发现价格不对可以手动改。
1. 从一个真实困境说起多模型调用的碎片化之痛如果你正在做AI应用开发大概率遇到过这样的场景项目初期用OpenAI的接口跑通了原型效果不错上线后想接入Claude做备用模型或者想用国产模型降低推理成本结果发现每家的SDK、鉴权方式、请求格式、返回结构都不一样。你不得不为每个模型写一套适配层代码里到处是if-else分支维护成本直线上升。更麻烦的是当你想要对比不同模型在同一个任务上的表现时需要反复切换API Key、改base_url、调整参数格式测试脚本改到怀疑人生。团队里如果有人想从OpenAI切到其他模型做A/B测试光是环境配置就能耗掉半天。这就是litellm要解决的核心问题。它本质上是一个统一的LLM调用层用一套OpenAI风格的接口去调用市面上几乎所有主流大模型。你只需要把base_url和API Key换一下代码几乎不用动就能在OpenAI、Anthropic、Cohere、HuggingFace、Ollama以及各类兼容OpenAI协议的服务之间自由切换。这篇文章适合三类人看一是正在做多模型集成的后端开发者二是需要快速对比模型效果做技术选型的算法工程师三是想在自己项目里加一个模型热插拔能力的独立开发者。我会从实际使用角度出发把litellm的核心机制、配置细节、踩坑经验和进阶玩法讲透让你看完就能直接上手。2. litellm到底做了什么统一接口背后的映射逻辑2.1 核心设计思路用一套协议吃掉所有差异litellm最核心的价值在于它定义了一套标准化的请求与响应格式然后为每个支持的模型提供商写了一个适配器。当你调用completion(modelclaude-3-sonnet, messages[...])时litellm内部会做几件事第一解析model参数识别出这是Anthropic的模型找到对应的适配器。第二把你传入的OpenAI格式的messages转换成Anthropic要求的格式比如system消息要单独提取出来不能放在messages数组里。第三把参数名做映射比如OpenAI的max_tokens在Anthropic里叫max_tokens_to_samplelitellm会自动转换。第四发送请求后把返回结果再转回OpenAI的响应结构让你拿到的response.choices[0].message.content和调OpenAI时一模一样。这个映射逻辑听起来简单但实际覆盖的细节非常多。比如流式响应的处理不同厂商的SSE格式差异很大litellm在中间做了一层归一化保证你拿到的chunk结构一致。再比如function callingOpenAI叫toolsAnthropic叫tools但参数结构不同litellm也做了统一。2.2 支持的模型范围与路由策略litellm目前支持的模型列表相当长我整理了几类常用的提供商类型代表模型接入方式闭源商业APIGPT-4o、Claude-3.5、Gemini Pro官方API Key开源模型托管Llama-3、Mistral、QwenTogether、Fireworks等平台本地部署Ollama、vLLM、LM Studio本地endpoint兼容OpenAI协议各类自建推理服务自定义base_url路由策略上litellm支持几种模式。最简单的是直接指定模型名它会自动路由到对应的提供商。你也可以用modelopenai/gpt-4o这种带前缀的写法显式指定提供商避免歧义。更高级的用法是配置fallback列表当主模型调用失败时自动切换到备用模型这对生产环境的稳定性很有帮助。2.3 为什么不用LangChain的LLM抽象很多人会问LangChain不是也有多模型支持吗为什么还要用litellm我的实际体验是LangChain的抽象层太重了。它把LLM调用和Chain、Agent、Memory等概念耦合在一起你只想调个模型却要引入一大堆依赖。而且LangChain的版本迭代快API经常变升级一次可能就要改代码。litellm的定位更纯粹它就是一层薄薄的适配器不涉及编排逻辑不强制你用什么框架。你可以把它当成一个独立的工具库在FastAPI、Flask、Django或者纯脚本里都能用。这种只做一件事的设计哲学在实际项目中反而更灵活。3. 环境搭建与最小可运行示例3.1 安装与依赖管理安装litellm很简单pip install litellm但这里有个坑要注意litellm的依赖包比较多如果你在一个已有项目里安装可能会和现有的openai、anthropic等SDK版本冲突。我的建议是在虚拟环境里先装litellm再装其他包让它自己决定依赖版本。如果你只需要用某几个提供商可以按需安装pip install litellm[openai,anthropic]这样能减少不必要的依赖。litellm的extras机制做得不错支持[proxy]、[all]等多种组合。3.2 环境变量配置的规范做法litellm读取API Key的方式是环境变量。每个提供商对应的变量名不同export OPENAI_API_KEYsk-xxx export ANTHROPIC_API_KEYsk-ant-xxx export COHERE_API_KEYxxx我习惯用.env文件管理这些密钥配合python-dotenv加载from dotenv import load_dotenv load_dotenv() from litellm import completion response completion( modelgpt-4o, messages[{role: user, content: 用一句话解释什么是向量数据库}] ) print(response.choices[0].message.content)注意不要把API Key硬编码在代码里也不要把.env提交到Git仓库。我见过太多因为密钥泄露导致账单暴涨的案例。3.3 第一个跨模型调用示例下面这段代码演示了如何用同一个函数调用三个不同厂商的模型from litellm import completion def ask(model, question): response completion( modelmodel, messages[{role: user, content: question}], temperature0.7, max_tokens500 ) return response.choices[0].message.content models [gpt-4o, claude-3-5-sonnet-20241022, command-r-plus] for m in models: print(f--- {m} ---) print(ask(m, 解释一下Transformer的自注意力机制))实测下来这段代码可以直接跑通不需要为每个模型写额外的适配代码。唯一需要注意的是不同模型的max_tokens上限不同如果设得太大某些模型会报错。4. 参数映射与响应结构的那些坑4.1 参数名不一致的自动转换litellm帮你做了参数名的映射但不是所有参数都能完美对应。我整理了几个常见的差异OpenAI参数Anthropic对应注意事项max_tokensmax_tokens必填且上限不同temperaturetemperature范围都是0-1top_ptop_p一致stopstop_sequences参数名不同presence_penalty不支持会被忽略当你传入一个目标模型不支持的参数时litellm默认会忽略它而不是报错。这个行为有利有弊好处是代码兼容性好坏处是你可能以为参数生效了实际上被静默丢弃了。我的做法是在关键参数上做显式检查比如response completion( modelclaude-3-5-sonnet-20241022, messagesmessages, max_tokens1000, temperature0.5 )对于不支持的参数我会在代码注释里标明避免团队成员误用。4.2 流式响应的统一处理流式输出是很多应用的刚需。litellm的流式接口用起来和OpenAI一致response completion( modelgpt-4o, messages[{role: user, content: 写一首关于秋天的诗}], streamTrue ) for chunk in response: content chunk.choices[0].delta.content if content: print(content, end, flushTrue)但这里有个细节不同厂商的流式chunk结构在litellm归一化之前差异很大。比如Anthropic的流式响应里第一个chunk可能是message_start类型最后一个可能是message_stop中间才是content_block_delta。litellm把这些都转成了统一的delta结构你不需要关心底层差异。不过实测中发现某些国产模型的流式实现不太规范可能会出现chunk丢失或顺序错乱的情况。如果遇到这种问题建议先用非流式模式验证功能再排查流式实现。4.3 错误处理与重试机制生产环境里API调用失败是常态。litellm内置了重试逻辑可以通过参数控制response completion( modelgpt-4o, messagesmessages, num_retries3, timeout30 )num_retries指定重试次数timeout指定超时时间。litellm会对某些错误类型自动重试比如速率限制429和服务器错误5xx。但对于认证失败401这种错误重试没有意义litellm会直接抛出异常。我建议在调用层再包一层自己的异常处理from litellm.exceptions import RateLimitError, APIError try: response completion(...) except RateLimitError: # 触发降级逻辑或排队等待 pass except APIError as e: # 记录日志切换到备用模型 pass5. 进阶玩法代理服务与模型路由5.1 用litellm proxy搭建统一网关如果你在团队里推广litellm不可能让每个人都去配环境变量。这时候可以用litellm的proxy模式起一个本地服务所有请求都走这个网关litellm --model gpt-4o --port 8000然后你的代码里只需要把base_url指向这个服务from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000, api_keyanything) response client.chat.completions.create( modelgpt-4o, messages[{role: user, content: hello}] )这样做的好处是密钥集中在网关管理团队成员不需要各自配置可以在网关上做统一的日志、限流、计费统计切换模型时只需要改网关配置客户端代码不动。proxy模式还支持配置文件可以定义多个模型、路由规则、fallback策略。配置文件用YAML格式model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: claude litellm_params: model: anthropic/claude-3-5-sonnet-20241022 api_key: os.environ/ANTHROPIC_API_KEY router_settings: fallbacks: [{gpt-4o: [claude]}]这个配置定义了两个模型并且设置了fallback当gpt-4o调用失败时自动切换到claude。5.2 基于成本的智能路由litellm的router支持更复杂的路由策略比如根据成本选择最便宜的可用模型from litellm import Router router Router( model_list[ {model_name: cheap, litellm_params: {model: gpt-4o-mini}}, {model_name: expensive, litellm_params: {model: gpt-4o}}, ], routing_strategycost-based-routing )不过说实话成本路由在实际项目里用得不多因为不同模型的能力差异太大单纯看价格选模型往往效果不好。更实用的是基于延迟的路由把请求发给响应最快的模型。5.3 缓存机制减少重复调用litellm支持多种缓存后端包括内存、Redis、磁盘。开启缓存后相同的请求会直接返回缓存结果省时省钱import litellm litellm.cache litellm.Cache(typeredis, hostlocalhost, port6379) response completion( modelgpt-4o, messages[{role: user, content: 什么是RAG}], cachingTrue )缓存的key是根据请求参数生成的哈希值。如果你希望某些请求不走缓存可以设置cachingFalse。需要注意的是缓存对温度参数敏感temperature0的请求缓存命中率最高。6. 实战中的经验与避坑清单6.1 模型名称的坑litellm的模型命名规则有时候不太直观。比如Claude的模型名要带日期后缀claude-3-5-sonnet-20241022和claude-3-5-sonnet可能指向不同的版本。我建议始终使用完整的模型名避免因为版本更新导致行为变化。另外某些模型需要通过特定前缀指定提供商。比如ollama/llama3表示用Ollama本地部署的Llama3together_ai/meta-llama/Llama-3-70b表示用Together平台托管的Llama3。如果不加前缀litellm可能会猜错提供商。6.2 Token计数与成本估算litellm提供了token计数功能from litellm import token_counter count token_counter(modelgpt-4o, messages[{role: user, content: hello}]) print(count)但要注意不同模型的tokenizer不同计数结果会有差异。litellm内部用的是tiktoken做估算对于OpenAI系列模型比较准对于其他模型可能偏差较大。如果需要精确计费建议以提供商返回的usage字段为准。成本估算方面litellm内置了价格表可以通过completion_cost函数计算from litellm import completion_cost cost completion_cost(completion_responseresponse)这个价格表更新不一定及时如果对成本敏感建议自己维护一份价格配置。6.3 并发调用与速率限制批量调用多个模型时很容易触发速率限制。我的做法是用asyncio配合信号量控制并发import asyncio from litellm import acompletion async def call_model(model, question, semaphore): async with semaphore: response await acompletion( modelmodel, messages[{role: user, content: question}] ) return response.choices[0].message.content async def main(): semaphore asyncio.Semaphore(5) tasks [call_model(m, test, semaphore) for m in models] results await asyncio.gather(*tasks) return results信号量设为5表示最多同时5个请求。具体数值要根据提供商的速率限制调整。OpenAI的免费额度通常限制比较严付费账户会宽松很多。6.4 日志与可观测性litellm可以输出详细的调用日志方便排查问题import litellm litellm.set_verbose True开启后每次调用都会打印请求参数、响应内容、耗时等信息。生产环境建议把日志接入统一的日志系统而不是直接打印到控制台。另外litellm支持回调机制可以在调用前后执行自定义逻辑def log_callback(kwargs, completion_response, start_time, end_time): # 记录到数据库或监控系统 pass litellm.success_callback [log_callback]这个机制可以用来做用量统计、异常告警、性能监控等。7. 我对litellm的实际使用体会用了一年多litellm最大的感受是它确实解决了多模型调用的碎片化问题但也不是银弹。它的优势在于轻量、灵活、上手快适合快速原型和中小型项目。但如果你的项目对性能要求极高或者需要深度定制某个提供商的特性可能还是直接调原生SDK更合适。另外litellm的版本迭代比较快升级时要注意看changelog有些breaking change不会在文档里特别标注。我的习惯是锁定版本号在测试环境验证后再升级生产环境。最后分享一个小技巧如果你不确定某个模型名怎么写可以用litellm.model_list查看所有支持的模型或者直接看源码里的model_prices_and_context_window.json文件里面列出了所有模型及其参数。这个文件也是更新价格表的地方如果发现价格不对可以手动改。
