1. 从一个真实困境说起：多模型调用为什么让人头疼
如果你正在做AI应用开发，大概率遇到过这样的场景：产品需要同时接入好几个大模型服务，有的任务用这个模型效果好，有的任务用那个模型成本低，还有的需要做故障切换。结果代码里到处都是不同厂商的SDK调用、不同的认证方式、不同的返回格式，维护起来简直是一场噩梦。
我最早接触这类需求是在一个内部工具项目上，当时只需要调用两个模型服务，觉得写两套调用逻辑也没什么。后来需求不断膨胀，要支持流式输出、要统计token消耗、要做重试和降级、要统一日志格式，代码量直接翻了三倍，而且每加一个新模型就要重新写一遍适配层。这种重复劳动不仅浪费时间，还特别容易出bug。
litellm就是为了解决这个问题而生的。它的核心思路非常直接：用一套统一的OpenAI格式接口，去调用市面上几乎所有主流的大模型服务。你不需要记住每个厂商的SDK怎么用，不需要为每个模型写不同的请求体，只需要把模型名称改一下，其他代码几乎不用动。对于需要快速迭代、频繁切换模型的团队来说，这个价值是巨大的。
这篇文章我会从实际使用的角度出发，把litellm的安装配置、核心用法、代理模式、成本追踪、避坑经验全部讲清楚。不管你是刚接触大模型API的新手，还是已经用过一段时间想深入了解的老手，都能从中找到有用的东西。
2. litellm到底解决了什么问题：统一接口的底层逻辑
2.1 没有litellm之前，开发者面对的是什么
在litellm出现之前，如果你想在项目里支持多个模型服务，通常有几种做法。第一种是直接用各家官方SDK，比如这个模型用某个库，那个模型用另一个库，代码里到处是import和不同的调用方式。第二种是自己写一层封装，把不同厂商的接口统一成自己定义的格式。第三种是用一些框架自带的抽象层，但往往绑定太深，不够灵活。
这几种方式都有明显的痛点。直接用官方SDK的话，每个厂商的认证方式不一样，有的用API key放在header里，有的用Bearer token，有的还要额外的secret。请求参数也不一样，有的叫max_tokens，有的叫max_output_tokens，有的叫max_new_tokens。返回格式更是五花八门，有的返回choices数组，有的返回output字段，有的直接返回文本。你每接一个新模型，就要重新读一遍文档，重新写一遍适配代码。
自己写封装层的话，初期看起来可控，但随着支持的模型越来越多，维护成本会指数级上升。每个厂商的API版本更新、参数变化、错误码调整，你都要跟着改。而且很多细节问题，比如流式输出的chunk格式、函数调用的参数结构、多模态输入的处理方式，不同厂商的实现差异很大，自己封装很难做到全面覆盖。
2.2 litellm的统一抽象层是怎么设计的
litellm的核心设计思想可以用一句话概括：把所有大模型服务的调用都映射到OpenAI的接口格式上。OpenAI的Chat Completions接口是目前事实上的行业标准，大部分开发者都熟悉它的参数和返回结构。litellm做的事情就是，当你用OpenAI格式发起请求时，它在内部把你的请求翻译成目标厂商的格式，发送出去，再把返回结果翻译回OpenAI格式。
这个翻译层的关键在于模型名称的映射机制。litellm用“provider/model_name”的格式来标识一个具体的模型，比如“openai/gpt-4o”、“anthropic/claude-3-5-sonnet”、“gemini/gemini-1.5-pro”等等。当你指定模型名称后，litellm会自动识别provider，加载对应的适配器，处理认证、请求转换、响应转换、错误映射等一系列工作。
这种设计的好处是显而易见的。你的业务代码只需要写一套逻辑，切换模型时只改一个字符串。新增模型支持时，只需要在配置里加一行，不需要动业务代码。而且因为统一到了OpenAI格式，很多现成的工具和库可以直接复用，比如LangChain、LlamaIndex这些框架都原生支持OpenAI接口，接上litellm就能用。
2.3 哪些场景最适合用litellm
litellm并不是所有场景都适用。如果你整个项目只用一家厂商的模型，而且不打算换，那直接用官方SDK可能更简单。但以下几种场景，litellm的优势非常明显。
第一种是多模型对比和路由。比如你想测试同一个prompt在不同模型上的效果，或者根据任务类型自动选择最合适的模型。litellm的统一接口让这种切换变得非常轻松，你可以在配置里定义路由规则，根据请求内容、用户等级、成本预算等条件自动选择模型。
第二种是故障降级和容灾。任何模型服务都可能出现临时不可用的情况，如果你的应用只依赖一个模型，一旦出问题整个服务就挂了。用litellm可以配置多个备用模型，主模型调用失败时自动切换到备用模型，对上层业务透明。
第三种是成本追踪和预算控制。litellm内置了成本计算功能，可以记录每次调用的token消耗和对应费用。对于需要控制AI成本的项目来说，这个功能非常实用。你可以设置预算上限，超过后自动拒绝请求或降级到更便宜的模型。
第四种是统一日志和监控。当你的应用调用多个模型时，日志格式不统一会给排查问题带来很大困难。litellm可以把所有模型的调用日志统一成一种格式，方便接入现有的监控系统。
3. 从零开始搭建litellm环境：安装与基础配置
3.1 安装方式的选择与对比
litellm提供了多种安装方式，最基础的是通过pip安装。如果你只是想在Python项目里用它的SDK功能，直接执行pip install litellm就可以了。这个包会安装核心依赖，支持大部分主流模型服务的基本调用。
但如果你需要用到代理服务器功能，也就是把litellm当作一个统一的API网关来用，那还需要安装额外的依赖。官方提供了pip install 'litellm[proxy]'这个命令，会安装FastAPI、Uvicorn等Web框架相关的包。代理模式的好处是你可以在一个独立的服务里管理所有模型配置，其他服务通过HTTP请求调用，语言无关，架构更清晰。
还有一种方式是用Docker部署代理服务。官方提供了Docker镜像，你可以直接拉取运行，把配置文件挂载进去就行。这种方式适合生产环境，隔离性好，部署也方便。不过对于本地开发和测试来说，直接用pip安装更轻量。
我个人的建议是，初期先用pip安装SDK版本，在代码里直接调用，快速验证效果。等确认要长期使用后，再考虑部署代理服务。这样学习曲线更平缓，不会一上来就被一堆配置搞晕。
3.2 API Key的管理策略
litellm本身不提供API Key，你需要自己去各家厂商申请。这里有一个重要的经验：不要把API Key硬编码在代码里，也不要在配置文件里明文写。正确的做法是用环境变量来管理。
litellm会自动读取特定名称的环境变量。比如OpenAI的Key读OPENAI_API_KEY，Anthropic的读ANTHROPIC_API_KEY，Gemini的读GEMINI_API_KEY。你只需要在运行环境里设置好这些变量，litellm就能自动识别。
对于本地开发，可以用.env文件配合python-dotenv来管理。对于生产环境，建议用密钥管理服务，比如各大云厂商提供的Secrets Manager。如果团队规模较大，还需要考虑Key的权限分级和轮换机制。
注意：如果你在代理模式下运行，litellm还支持设置一个主密钥（master key）来保护代理服务本身。这个密钥和模型厂商的API Key是两回事，前者用于客户端访问代理服务时的认证，后者用于代理服务访问模型厂商时的认证。两者不要混淆。
3.3 最小可用示例：三行代码跑通第一个调用
litellm的入门非常简单。安装完成后，设置好环境变量，然后写三行代码就能跑通。
from litellm import completion response = completion( model="openai/gpt-4o", messages=[{"role": "user", "content": "用一句话解释什么是统一接口"}] ) print(response.choices[0].message.content)这段代码的结构和OpenAI官方SDK几乎一模一样，唯一的区别是model参数需要加上provider前缀。如果你之前用过OpenAI的接口，几乎不需要学习成本就能上手。
切换模型也很简单，只需要改model参数。比如换成Anthropic的模型：
response = completion( model="anthropic/claude-3-5-sonnet-20241022", messages=[{"role": "user", "content": "用一句话解释什么是统一接口"}] )其他代码完全不用动。这就是litellm最核心的价值所在。
3.4 配置文件的结构与常用参数
如果你用代理模式，需要写一个配置文件。litellm支持YAML格式的配置，结构清晰，可读性好。一个典型的配置文件包含model_list、general_settings、litellm_settings等几个部分。
model_list定义了你要暴露的模型。每个条目包含model_name（对外暴露的名称）和litellm_params（实际调用的参数）。你可以给同一个实际模型起多个别名，也可以给不同的实际模型起相同的对外名称来实现负载均衡。
general_settings里可以配置master_key、database_url等全局设置。litellm_settings里可以配置drop_params、set_verbose、cache等行为参数。其中drop_params特别有用，它的作用是自动丢弃目标模型不支持的参数。比如你传了OpenAI特有的参数给Anthropic的模型，开启这个选项后litellm会自动忽略不支持的参数，而不是报错。
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 litellm_settings: drop_params: true set_verbose: false general_settings: master_key: sk-your-master-key这个配置文件定义了两个模型，对外名称分别是gpt-4o和claude。客户端调用时用这两个名称即可，不需要知道背后实际用的是哪家厂商。
4. 核心API的实战用法：从基础调用到高级特性
4.1 completion接口的参数详解
completion是litellm最常用的接口，对应OpenAI的Chat Completions。它的参数和OpenAI基本一致，但有一些额外的扩展。
messages参数是必须的，格式和OpenAI一样，是一个包含role和content的字典列表。role可以是system、user、assistant、tool等。content通常是字符串，但在多模态场景下可以是包含text和image_url的列表。
model参数指定要调用的模型，格式是provider/model_name。如果你在代理模式下配置了别名，也可以直接用别名。
temperature、max_tokens、top_p这些采样参数和OpenAI一致，litellm会自动转换成目标模型支持的格式。比如Anthropic的max_tokens是必填的，而OpenAI是可选的，litellm会处理这些差异。
stream参数控制是否流式输出。开启后返回的是一个迭代器，每次yield一个chunk。不同厂商的流式格式差异很大，但litellm统一成了OpenAI的chunk格式，处理起来很方便。
除了这些标准参数，litellm还支持一些扩展参数。比如fallbacks可以指定备用模型列表，主模型失败时自动切换。metadata可以附加自定义元数据，用于日志和追踪。timeout可以设置超时时间，避免请求卡死。
4.2 流式输出的正确处理方式
流式输出是提升用户体验的关键特性，但处理起来有一些坑。litellm的流式接口返回的是一个生成器，你需要遍历它来获取每个chunk。
response = completion( model="openai/gpt-4o", messages=[{"role": "user", "content": "写一段关于统一接口的说明"}], stream=True ) for chunk in response: content = chunk.choices[0].delta.content if content: print(content, end="", flush=True)这里有几个细节需要注意。第一，不是每个chunk都有content，有些chunk只包含role信息或者结束标记，所以要判断content是否存在。第二，流式输出的最后一个chunk通常包含finish_reason，可以用来判断是否正常结束。第三，如果开启了流式，错误处理会更复杂，因为错误可能在流的中途发生，需要捕获异常并妥善处理。
还有一个容易忽略的点是，流式输出下的token计数。非流式调用可以直接从response的usage字段拿到token数，但流式调用默认不返回usage。litellm提供了一个选项可以在流式结束时返回usage，需要在请求时加上stream_options={"include_usage": True}。这个功能对于成本追踪很重要，建议开启。
4.3 函数调用与结构化输出
函数调用（Function Calling）是构建Agent类应用的基础能力。litellm统一了各家的函数调用格式，你只需要按照OpenAI的方式定义tools参数即可。
tools = [ { "type": "function", "function": { "name": "get_weather", "description": "获取指定城市的天气", "parameters": { "type": "object", "properties": { "city": {"type": "string", "description": "城市名称"} }, "required": ["city"] } } } ] response = completion( model="openai/gpt-4o", messages=[{"role": "user", "content": "北京今天天气怎么样"}], tools=tools, tool_choice="auto" )不同厂商对函数调用的支持程度不一样。OpenAI和Anthropic支持得比较好，一些开源模型可能不支持或者支持有限。litellm会尽量做转换，但如果目标模型完全不支持，就会报错。所以在设计多模型应用时，要考虑到这个差异，对不支持函数调用的模型做降级处理。
结构化输出是另一个实用特性。你可以用response_format参数指定输出格式，比如JSON。litellm会把这个参数转换成目标模型支持的格式。不过要注意，不是所有模型都支持结构化输出，使用前最好查一下文档。
4.4 嵌入与图像生成的统一调用
除了文本生成，litellm还统一了嵌入（Embedding）和图像生成的接口。
嵌入接口用embedding函数，参数和OpenAI的Embeddings接口一致。你传入模型名称和文本列表，返回的是向量列表。不同厂商的嵌入维度不一样，切换模型时要注意向量数据库的兼容性。
from litellm import embedding response = embedding( model="openai/text-embedding-3-small", input=["这是第一段文本", "这是第二段文本"] ) vectors = [item["embedding"] for item in response.data]图像生成用image_generation函数，参数和OpenAI的Images接口类似。你传入prompt和尺寸等参数，返回的是图像URL或base64数据。目前支持图像生成的厂商还不多，litellm主要覆盖了OpenAI和少数几家。
这两个接口的使用频率相对较低，但统一之后确实方便。特别是做RAG应用时，嵌入模型的切换会很频繁，用litellm可以省去很多适配工作。
5. 代理模式：把litellm变成团队共用的API网关
5.1 为什么需要代理模式
SDK模式适合个人开发和小型项目，但当团队规模扩大后，会面临几个问题。第一，每个开发者都要自己配置API Key，管理起来很麻烦，而且有泄露风险。第二，不同项目的调用日志分散在各处，难以统一监控。第三，成本分摊不清晰，不知道哪个项目用了多少。第四，模型配置变更时，需要通知所有人改代码。
代理模式解决了这些问题。你把litellm作为一个独立服务部署，所有模型配置和API Key都集中在服务端。客户端只需要知道代理服务的地址和一个访问密钥，用OpenAI格式发起请求即可。模型切换、Key轮换、成本控制都在服务端完成，对客户端透明。
从架构上看，代理模式相当于在你的应用和模型厂商之间加了一层网关。这层网关可以做很多事情：认证鉴权、限流限速、日志记录、成本追踪、缓存、路由、降级等等。对于中大型团队来说，这层网关几乎是必备的。
5.2 启动代理服务的完整步骤
启动代理服务需要先准备好配置文件，然后运行启动命令。配置文件里至少要定义model_list和general_settings。
litellm --config /path/to/config.yaml --port 4000这个命令会启动一个HTTP服务，默认监听4000端口。你可以用--host参数指定监听地址，用--num_workers指定工作进程数。生产环境下建议用Gunicorn或Uvicorn来管理进程，配置多worker提高并发能力。
启动后，你可以用curl测试一下：
curl http://localhost:4000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-your-master-key" \ -d '{ "model": "gpt-4o", "messages": [{"role": "user", "content": "你好"}] }'如果返回正常的响应，说明代理服务已经跑起来了。客户端的代码只需要把base_url指向代理地址，api_key换成master key，其他都不用改。
5.3 多模型路由与负载均衡配置
代理模式的一个强大功能是路由和负载均衡。你可以在配置文件里定义多个实际模型，给它们相同的对外名称，litellm会自动做负载均衡。
model_list: - model_name: chat-model litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY - model_name: chat-model litellm_params: model: anthropic/claude-3-5-sonnet-20241022 api_key: os.environ/ANTHROPIC_API_KEY这样配置后，客户端调用chat-model时，请求会轮流分发到两个实际模型上。你可以通过routing_strategy参数控制分发策略，比如simple-shuffle（随机）、least-busy（最少繁忙）等。
除了负载均衡，还可以配置降级策略。当主模型调用失败时，自动切换到备用模型。这个功能对于提高服务可用性非常重要。配置方式是在litellm_params里加fallbacks字段，或者在litellm_settings里配置全局的fallback规则。
5.4 用虚拟密钥做细粒度权限控制
代理模式支持虚拟密钥（Virtual Key）功能。你可以为每个用户或每个项目生成一个独立的密钥，设置不同的权限和预算。
虚拟密钥可以限制可访问的模型列表、设置预算上限、设置速率限制、设置过期时间等。这些信息存储在数据库中，litellm通过数据库来验证和管理。
要使用虚拟密钥，需要配置database_url，litellm支持PostgreSQL等主流数据库。配置好后，你可以通过管理接口创建密钥，指定允许的模型和预算。
这个功能对于多租户场景特别有用。比如你是一个平台方，给不同客户提供AI能力，每个客户一个密钥，独立计费和限流。或者在公司内部，给不同部门分配不同的预算和模型权限。
提示：虚拟密钥的预算控制是基于litellm自己计算的成本，不是厂商的实际账单。两者可能有细微差异，但对于内部管理来说足够用了。
6. 成本追踪与预算控制：让每一分钱都花得明白
6.1 litellm的成本计算机制
litellm内置了一个成本映射表，记录了各个模型的输入和输出token单价。每次调用完成后，它会根据实际消耗的token数计算费用，并附加在返回结果的usage字段里。
这个成本计算是自动的，你不需要额外配置。但要注意，成本映射表需要保持更新，因为厂商会调整价格。litellm会定期更新这个表，所以建议保持litellm版本较新。
成本计算的准确性取决于token计数的准确性。大部分厂商会在返回结果里包含usage信息，litellm直接使用这些数据。但有些厂商或某些接口可能不返回usage，这时候litellm会尝试自己计算，但可能有偏差。
6.2 如何查看和分析成本数据
在SDK模式下，你可以直接从response的usage字段拿到成本信息。在代理模式下，litellm会把每次调用的成本记录到数据库，你可以通过管理接口查询。
response = completion( model="openai/gpt-4o", messages=[{"role": "user", "content": "你好"}] ) print(response.usage)usage字段包含prompt_tokens、completion_tokens、total_tokens，以及litellm额外添加的cost字段。cost是以美元为单位的浮点数。
如果你需要更详细的分析，可以把这些数据导出到自己的监控系统。litellm支持多种回调机制，可以在每次调用后触发自定义函数，把数据发送到你的日志平台或数据仓库。
6.3 设置预算上限和告警
代理模式下，你可以为每个虚拟密钥设置预算上限。当累计消费超过预算时，litellm会拒绝后续请求，返回预算超限的错误。
预算可以按天、按周、按月设置，也可以设置总预算。配置方式是在创建虚拟密钥时指定max_budget参数。
除了硬性预算，还可以设置告警阈值。当消费达到预算的一定比例时，触发告警通知。litellm支持通过Webhook发送告警，你可以接到自己的告警系统里。
这个功能对于防止意外超支非常有用。特别是当你的应用可能被滥用时，预算上限是一道重要的防线。
6.4 缓存策略对成本的影响
litellm支持缓存功能，可以把相同的请求结果缓存起来，避免重复调用。对于重复性高的场景，缓存可以显著降低成本。
缓存支持内存、Redis等多种后端。内存缓存适合单机部署，Redis缓存适合多机部署。你可以设置缓存的TTL（过期时间），控制缓存的新鲜度。
litellm_settings: cache: true cache_params: type: redis host: localhost port: 6379 ttl: 3600这个配置开启了Redis缓存，TTL设置为1小时。相同的请求在1小时内会直接返回缓存结果，不消耗token。
不过缓存也有副作用。如果模型输出需要实时性，缓存可能导致返回过时的结果。所以要根据业务场景决定是否开启缓存，以及设置合理的TTL。
7. 踩坑实录：那些文档里不会告诉你的问题
7.1 参数不兼容导致的报错与解决
不同厂商的API参数差异是使用litellm时最常遇到的问题。比如OpenAI支持frequency_penalty和presence_penalty，但Anthropic不支持。如果你把这些参数传给Anthropic的模型，就会报错。
litellm提供了一个drop_params选项，开启后会自动丢弃目标模型不支持的参数。这个选项在litellm_settings里配置，建议默认开启。
但drop_params也不是万能的。有些参数虽然名字相同，但语义有差异。比如max_tokens在OpenAI里是可选的，在Anthropic里是必填的。如果你不传max_tokens，litellm会用一个默认值，但这个默认值可能不符合你的预期。所以最好还是显式指定max_tokens。
还有一个坑是temperature的取值范围。大部分模型是0到2，但有些模型是0到1。litellm会做一定的转换，但如果你传了超出范围的值，可能会被截断或报错。
7.2 流式输出中断的排查思路
流式输出中断是一个比较棘手的问题。表现是客户端收到部分内容后，连接突然断开，没有收到结束标记。
这个问题可能有几个原因。第一是网络问题，连接不稳定导致中断。第二是模型服务端的超时，如果生成时间太长，服务端可能主动断开。第三是litellm代理的超时配置，如果代理的timeout设置太短，也会导致中断。
排查的时候，先看litellm的日志，确认请求是否正常发送和接收。然后检查代理的timeout配置，适当调大。如果是模型服务端的超时，可以尝试减少max_tokens，或者换一个更快的模型。
还有一个容易忽略的点是，某些厂商的流式接口在遇到内容过滤时会直接断开，不返回错误信息。这种情况下，客户端需要做好异常处理，给用户一个友好的提示。
7.3 模型名称映射错误的常见原因
模型名称映射错误通常表现为“model not found”或“provider not supported”。原因可能有几个。
第一是provider名称拼写错误。litellm的provider名称是固定的，比如OpenAI是openai，Anthropic是anthropic，Google是gemini。拼错了就找不到对应的适配器。
第二是模型名称本身错误。不同厂商的模型命名规则不一样，有些带版本号，有些带日期。建议直接查litellm的文档或源码里的模型列表，确认正确的名称。
第三是环境变量没设置。litellm需要读取对应厂商的API Key环境变量，如果没设置，会报认证错误。这个错误信息有时候不太直观，容易被误认为是模型名称问题。
第四是代理模式下的配置问题。如果你在代理模式下用了别名，但配置文件里没定义这个别名，也会报错。检查配置文件的model_list，确认别名拼写正确。
7.4 代理模式下的认证与超时问题
代理模式下，认证分两层。第一层是客户端到代理的认证，用master key或虚拟密钥。第二层是代理到模型厂商的认证，用厂商的API Key。
常见的问题是master key没设置或设置错误。如果general_settings里没配master_key，代理服务可能不要求认证，这在生产环境下是危险的。如果配了但客户端没传，会返回401错误。
超时问题也很常见。代理服务默认的超时可能不够长，特别是对于生成大量内容的请求。你可以在litellm_settings里配置request_timeout，或者在启动命令里加--timeout参数。
还有一个坑是，代理服务重启后，如果用了数据库存储虚拟密钥，需要确保数据库连接正常。如果数据库连不上，虚拟密钥验证会失败，所有请求都会被拒绝。
8. 进阶玩法：把litellm接入现有技术栈
8.1 与LangChain等框架的集成
LangChain和LlamaIndex这些框架都支持OpenAI接口，所以可以直接接litellm的代理服务。你只需要把base_url指向代理地址，api_key换成master key，其他代码不用改。
from langchain_openai import ChatOpenAI llm = ChatOpenAI( model="gpt-4o", base_url="http://localhost:4000/v1", api_key="sk-your-master-key" )这样LangChain的所有功能都能用，而底层实际调用的是litellm代理，可以享受多模型路由、成本追踪等能力。
如果你不想部署代理服务，也可以在LangChain里直接用litellm的SDK。LangChain有一个ChatLiteLLM的集成，可以直接用litellm作为后端。
8.2 自定义回调与日志接入
litellm支持自定义回调，可以在请求前后、成功或失败时触发。这个功能对于接入现有监控系统很有用。
你可以写一个Python函数，接收litellm传递的参数，然后把数据发送到你的日志平台。比如发送到Elasticsearch、Datadog或者自建的日志服务。
def my_callback(kwargs, response, start_time, end_time): # 自定义日志逻辑 print(f"Model: {kwargs['model']}, Cost: {response.usage.cost}") litellm.success_callback = [my_callback]回调函数可以拿到请求参数、响应结果、时间戳等信息。你可以根据需要记录不同的字段。
8.3 多租户场景下的密钥管理
如果你是一个平台方，需要给多个客户提供AI能力，litellm的虚拟密钥功能可以帮你实现多租户管理。
每个客户分配一个虚拟密钥，设置独立的预算和模型权限。客户用这个密钥调用代理服务，litellm会自动记录消费并扣减预算。
你还可以设置团队（Team）概念，把多个密钥归到一个团队下，统一管理预算和权限。团队可以有管理员，管理团队内的密钥。
这个功能需要数据库支持，配置好database_url后，通过管理接口创建团队和密钥。管理接口的文档在litellm的官方文档里有详细说明。
8.4 性能优化与并发调优
当请求量增大时，代理服务的性能会成为瓶颈。有几个优化方向。
第一是增加worker数量。litellm代理基于FastAPI，可以用Uvicorn启动多个worker。启动命令加--num_workers参数，根据CPU核心数设置合适的值。
第二是开启缓存。对于重复性高的请求，缓存可以大幅减少对模型厂商的调用，提高响应速度。
第三是配置连接池。litellm底层用httpx发送请求，可以配置连接池大小，避免频繁建立连接的开销。
第四是异步调用。litellm支持异步接口，用acompletion代替completion。在异步框架里使用可以显著提高并发能力。
from litellm import acompletion import asyncio async def main(): response = await acompletion( model="openai/gpt-4o", messages=[{"role": "user", "content": "你好"}] ) print(response.choices[0].message.content) asyncio.run(main())异步接口的用法和同步几乎一样，只是加了await。在高并发场景下，异步调用的吞吐量比同步高很多。
9. 我个人的一些使用体会
用了litellm一段时间后，有几个感受比较深。
第一，它确实解决了多模型调用的核心痛点。以前切换模型要改一堆代码，现在只改一个字符串。这个价值在快速迭代的项目里特别明显。
第二，代理模式是团队协作的正确姿势。把模型配置和密钥管理集中到服务端，客户端只管调用，职责清晰，安全性也好很多。
第三，成本追踪功能比想象中更有用。以前不太关注token消耗，用了litellm之后能看到每次调用的具体成本，对优化prompt和控制预算很有帮助。
第四，不要指望litellm能抹平所有差异。不同模型的能力边界、参数语义、输出风格还是有区别的。litellm解决的是接口层面的统一，业务层面的适配还是需要自己处理。
第五，保持版本更新很重要。litellm的迭代速度很快，新模型支持、bug修复、功能增强都在持续更新。建议定期升级，但升级前要在测试环境验证，避免引入不兼容的变更。
最后分享一个小技巧：如果你在调试阶段，可以开启set_verbose选项，litellm会打印详细的请求和响应日志，方便排查问题。但生产环境记得关掉，否则日志量会很大。
