做 AI 应用开发这段时间，我最大的一个体会是：模型 API 的连接层，远比想象中容易变成一团乱麻。最初项目只需要接一家模型服务，一套 SDK 用到底也还行。可等你要同时对接几家主流模型、内部还要做灰度对比和成本核算时，那个“适配层”就会越写越别扭。要统一消息格式，要处理各家不同的超时和重试逻辑，还要手动记请求日志，整套东西写下来，少说几百行。后来我换成了 LiteLLM，这一换，直接把连接层从“自己造的轮子”变成了“一个配置项”。LiteLLM 说白了，就是一个面向大模型 API 的统一网关。它对外暴露一个标准接口，把各家模型供应商的差异统统吸收掉。你可以把它当库用，在 Python 里直接调用统一的completion()方法；也可以把它跑成一个代理服务，内部团队通过 HTTP 请求访问它，由它做路由、限流、费用统计和失败切换。这个定位，恰好卡在“业务代码”和“底层模型 API”之间，属于标准的 LLM 网关层。适合正在做多模型接入、模型切换、或者要给团队提供一个统一模型入口的场景，无论你是个人开发者还是小团队的后端负责人，这套东西都值得了解一下。1. 项目定位：这到底是个什么工具1.1 解决的真实痛点先讲一个很具体的场景。你在开发一个智能客服机器人，发布时用了 A 家模型。上线半个月，老板说 A 家打包价格太贵，或者评测出来 B 家回答质量更好，要换。你怎么办？正常做法是改代码。因为 A、B 两家的接口约定不一样，请求体里的字段不同，返回的结构也不同，错误码更是各讲各的。这一改，牵一发动全身。更要命的还不是换模型，而是多模型并行。你希望用户问题先走贵的优质模型，命中某些关键词就降级到便宜模型；或者按概率分配一部分流量给新模型做灰度。这些需求一旦出现，手写适配层的复杂度就上来了。LiteLLM 的思路，是学“通用充电口”的做法。不管底下的模型长什么样，你需要输入的都是一套统一参数：模型名、消息列表、温度等。你得到的返回，也统一成一个结构。相当于给不同厂家提供的充电协议套上同一个物理接口，你的业务方只需要认识这一种接口就行。1.2 核心能力矩阵LiteLLM 不是一个单点小工具，它的功能是成体系的。我把它常用的能力整理成一张表：能力模块解决的问题通俗解释统一接口多家 API 格式不一致所有模型都用一套参数调用，返回统一格式模型路由 Router选哪个模型处理请求按预算、按延迟、按优先级做分发负载均衡单模型压力过大多个 Key 或多个供应商之间轮询分配流量失败切换接口挂了不会崩请求失败自动换下一个可用模型日志与费用统计花了多少钱心里有数每次请求的输入输出 token 数、费用自动记录Mock 测试不想花真钱调接口返回预先写好的模拟结果，方便联调Key 管理与配额多人共用不混乱分别给不同人、不同项目分配不同额度我自己最看重的，是它的“统一接口”和“费用追踪”这两块。前者解决了写代码时的头疼，后者解决了汇报时的头疼。剩下那些能力，都是在生产环境中滚过之后才会切实感受到价值的。2. 半小时跑通：安装部署与初始配置2.1 安装与启动LiteLLM 安装很简单，核心就是 pip 装一个包。如果你要跑代理服务，建议把扩展依赖一起装上。pip install 'litellm[proxy]'装完之后，最快的方式是先跑通一个单模型配置。不需要额外写文件，直接用命令行传参也行：litellm --model gpt-3.5-turbo --port 4000这样它会起一个本地 HTTP 服务，监听 4000 端口，然后把/chat/completions路径代理给目标模型。你本地可以用任何一个 OpenAI 风格的 SDK 去连它，只要把 base_url 改成http://localhost:4000。但实际项目里我更推荐用配置文件的方式，因为配置是“可版本管理”的资产，后面改路由、改限额都在文件里改，不用改代码。启动命令变成了：litellm --config config.yaml --port 40002.2 配置文件拆解新建一个config.yaml，内容大概长这样：model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/ANTHROPIC_API_KEY - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY rpm: 60这里有一个很关键的概念区分：model_name是“别名”，是你暴露给你的业务方的名字；litellm_params.model才是真正请求供应商时用的完整模型名。它前面那个前缀，比如openai/、anthropic/，是 LiteLLM 识别供应商的依据，千万别省。api_key填os.environ/XXX表示从环境变量读取，这样不会把密钥写进仓库。你可以在.env文件里配好，然后启动时让它加载。2.3 为什么推荐走网关而不是 SDK 直连有人可能会问：我直接在代码里用 LiteLLM 的 Python SDK 不就好了，何必再套一层 HTTP 代理？两种方式都有用，但适用阶段不同。SDK 方式适合单体应用，你只需要在自己的 Python 代码里统一调用，省去起服务的运维成本。但如果你所在的项目有多个服务，比如一个用 Python 写的分析服务，一个用 Node.js 写的客服后端，还有一个跑在定时任务里的脚本，都要调模型，SDK 方式就得每种语言各写一遍适配。HTTP 代理方案解决的是“语言无关的团队级统一入口”。所有服务只要会发 HTTP 请求，就能用统一的接口接入。再加上代理层可以统一做限流、审计、费用统计，这就不是一个 SDK 能做到的事了。所以在真正的生产环境里，我倾向于把 LiteLLM 跑成一个独立网关服务，而不是塞进某个业务进程里。3. 核心功能实操：路由策略与负载均衡3.1 用 Router 做智能分发除了代理模式，LiteLLM 还提供 Python 的 Router 类。它和网关的底层路由逻辑是一样的，但适合在你自己的代码里做更精细的控制。看一个简单例子：from litellm import Router router = Router( model_list=[ { "model_name": "gpt-4o-mini", "litellm_params": {"model": "openai/gpt-4o-mini", "api_key": "sk-xxxx"}, "model_info": {"rpm": 60, "input_cost_per_token": 0.00000015, "output_cost_per_token": 0.0000006}, }, { "model_name": "gpt-4o", "litellm_params": {"model": "openai/gpt-4o", "api_key": "sk-xxxx"}, "model_info": {"rpm": 30}, }, ], routing_strategy="simple-shuffle" ) resp = await router.acompletion( model="gpt-4o-mini", messages=[{"role": "user", "content": "给我讲个冷笑话"}] )Router 会维护一个可用模型列表，每次请求时根据路由策略选一个去执行。simple-shuffle是洗牌式轮询，压力均匀分散；还有least-busy，会看并发数最少优先，更适合处理长任务；usage-based-routing则可以根据实时 token 消耗来做成本敏感路由。3.2 失败自动切换：不能让一个接口拖垮全部多模型接入最大的好处，是一家接口挂了，另一家还能顶上。LiteLLM 的 Router 支持fallbacks参数，可以配置一组备用模型。router = Router( model_list=[...], fallbacks=[{"model": "gpt-4o", "fallbacks": ["claude-3-5-sonnet"]}], )意思是，当 gpt-4o 请求失败时，自动重试 claude-3-5-sonnet。如果 claude 也失败，还可以继续往下排。需要留意的是，fallbacks列表是优先顺序，不是随机选择。这个能力对生产环境非常实用，因为模型供应商偶尔还会出现限流，自己写重试和切换逻辑的话，考虑的点特别多，用现成的路由配置省心省力。3.3 成本预算与限流配置LiteLLM 在 Router 和代理模式里都支持max_budget。比如一个项目每天的消耗不能超过 10 美元，配置一个全局预算就行：general_settings: master_key: sk-1234 database_url: os.environ/DATABASE_URL max_budget: 10当所有 Key 的累计费用超过预算后，新的请求会直接返回预算超限的错误。如果你把database_url配好，它能持久化记录 spend 数据；否则只是内存中的临时计数，一重启就清零，这个要注意。限流方面，我测下来最需要注意的是rpm和tpm。rpm是每分钟请求数，tpm是每分钟 token 数。在litellm_params里给不同模型配置自己的rpm，代理层会自动排队或拒绝超限请求。实际生产里，建议把rpm设置成低于供应商限流阈值的 80%，宁可自己先限，也别让上游先 429。4. 生产级监控：日志、配额与费用追踪4.1 请求日志与用量汇总用过一段时间之后你会发现，模型调用记录的价值不亚于模型本身。谁在调、调的什么模型、花了多少钱、成功失败情况，这些信息如果散落在业务日志里，排查问题就会非常痛苦。LiteLLM 的解决方式是内置回调机制。你在配置里声明要写到哪里，它就会在每次请求完成时把用量数据推过去。常见做法是把日志写到数据库里，入库后自己做查询和可视化。配置示例：litellm_settings: drop_params: true success_callback: ["postgres"] failure_callback: ["postgres"]用到一个数据库连接串后，你就能查到每一笔请求的模型名、token 数量、费用估算。我实际查得最多的是“某个接口某一天各模型的调用次数和费用”，有了统一日志以后，这类问题从翻日志变成了写一条 SQL。4.2 给不同成员设置独立配额如果你在团队内部用了代理模式，最直接的需求是：不同成员或不同项目，预算不能混在一起。比如前端项目组这个月有 50 美元额度，后端实验组有 100 美元额度。LiteLLM 支持在代理里创建虚拟 Key，每个 Key 绑定自己的配额和预算。操作上，先通过/key/generate接口生成一个 Key：curl -X POST http://localhost:4000/key/generate \ -H "Authorization: Bearer sk-1234" \ -H "Content-Type: application/json" \ -d '{ "key": "sk-project-howard", "max_budget": 50, "models": ["gpt-4o-mini", "claude-3-5-sonnet"] }'生成的这个 Key 能调用的模型列表就是被限定死的，而且它单独计算预算，不会和全局混在一起。团队里每个人用一个独立 Key，月底看报表时哪些项目超支了，一目了然，不用再追着人问。4.3 Mock 模式：不花一分钱做联调开发调试时反复调用真实模型，既费钱又费时间。LiteLLM 支持mock_response参数，可以直接返回一个你写死的模拟结果。from litellm import completion resp = completion( model="gpt-4o-mini", messages=[{"role": "user", "content": "你好"}], mock_response="模拟返回：我很好！", )这个特性特别适合前端联调和自动化测试。前端需要调后端接口，但后端还没配好真实 API Key，或者不想消耗真实 token 时，直接在网关层把 mock_response 写进配置，整个链路就能跑通。等真正接上游时，只是把 mock_response 去掉而已，代码层面完全不用动。5. 踩坑实录与排查速查5.1 高频报错与解决现象可能原因解决方式401 Authentication Error上游 API Key 没配置或配错检查环境变量名是否和配置对应，打印确认环境变量是否加载成功ModelNotFoundErrormodel_name对应的配置不存在确认配置文件里model_list是否有这个别名，注意大小写响应延迟翻倍重试策略配置过密，失败后秒级重试多次调大重试间隔，或限制fallbacks数量token 统计稀疏未配置 cost 相关参数在model_info里补上input_cost_per_token等字段，否则无法估算费用429 限流频繁上游限制低于你的配置值降低rpm/tpm配置，或在路由层做次数衰减5.2 几个真实有用的配置细节第一，环境变量加载顺序是坑。直接用os.environ/XXX语法时，LiteLLM 会去读进程的环境变量。如果你用.env文件，要确认框架在启动时真的加载了它。我测试时经常是 .env 文件没被读进去，换成显式导出环境变量之后立刻就好了。第二，drop_params值得开。这个配置可以自动过滤掉某些模型不支持的参数。不同的模型对temperature、top_p的支持程度不一样，开了drop_params: true以后，LiteLLM 会把目标供应商不认识的参数在请求发出前剔除掉，能避免很多奇怪的入参报错。但注意也要全局验证一下效果，因为某些功能确实依赖特定参数。第三，模型名不要想当然。你在配置里写的anthropic/claude-3-5-sonnet，供应商侧是有严格拼写的。如果模型名写错了，LiteLLM 不会替你纠正，它会原样发给上游，然后报错。建议照着各家文档的完整模型标识来填。5.3 测试环境与线上环境隔离很多团队把 LiteLLM 部署之后，测试和线上共用一个网关，这在我眼里是大忌。你想做模型灰度，结果灰度的配置被线上请求一并带走了，事故就是这么来的。推荐的做法是拆成两个配置文件，一个config.dev.yaml，里面模型全用 mock_response 或者只接一个便宜的测试模型；另一个config.prod.yaml，走真实模型和完整配额。启动时用不同的端口侦听，测试环境也可以单独设一个较短的超时时间，让联调时问题暴露得更快。6. 一点个人体会和后续用法最后说一下我自己的实际感受。LiteLLM 这个项目最打动我的，不是某个单一功能有多强大，而是它把“接入多家模型”这件事从“开发难题”变成了“运维配置”。以前我接一个新模型，要写对接代码、测试兼容性、改异常处理；现在只需要在config.yaml里加一段，启动一下，就能在业务代码里用同一个接口调起来了。这种体验上的变化，用过一次就回不去。还有一个容易被忽略的价值是“模型选型的自由度”。因为适配层被 LiteLLM 吸收了，业务方不再被某一家模型绑死。今天觉得这家效果好就切这家，明天觉得价格高就换另一家，对业务代码几乎零侵入。这一点在一个项目生命周期里，意义远比省几百行代码大。如果你已经跑通了基础功能，我建议下一个可以尝试的方向是给自己的网关配一个可视化的用量面板，把 LiteLLM 记录的数据源接到图表工具里，每天扫一眼成本曲线和调用量变化。再用路由把不同流量分给不同模型，灰度效果直接量化。工具本身不难，难的是你有没有想清楚网关这一层到底要解决哪些问题。想明白了，LiteLLM 会是一个非常省心的底座。
做 AI 应用开发这段时间，我最大的一个体会是：模型 API 的连接层，远比想象中容易变成一团乱麻。最初项目只需要接一家模型服务，一套 SDK 用到底也还行。可等你要同时对接几家主流模型、内部还要做灰度对比和成本核算时，那个“适配层”就会越写越别扭。要统一消息格式，要处理各家不同的超时和重试逻辑，还要手动记请求日志，整套东西写下来，少说几百行。后来我换成了 LiteLLM，这一换，直接把连接层从“自己造的轮子”变成了“一个配置项”。LiteLLM 说白了，就是一个面向大模型 API 的统一网关。它对外暴露一个标准接口，把各家模型供应商的差异统统吸收掉。你可以把它当库用，在 Python 里直接调用统一的completion()方法；也可以把它跑成一个代理服务，内部团队通过 HTTP 请求访问它，由它做路由、限流、费用统计和失败切换。这个定位，恰好卡在“业务代码”和“底层模型 API”之间，属于标准的 LLM 网关层。适合正在做多模型接入、模型切换、或者要给团队提供一个统一模型入口的场景，无论你是个人开发者还是小团队的后端负责人，这套东西都值得了解一下。1. 项目定位：这到底是个什么工具1.1 解决的真实痛点先讲一个很具体的场景。你在开发一个智能客服机器人，发布时用了 A 家模型。上线半个月，老板说 A 家打包价格太贵，或者评测出来 B 家回答质量更好，要换。你怎么办？正常做法是改代码。因为 A、B 两家的接口约定不一样，请求体里的字段不同，返回的结构也不同，错误码更是各讲各的。这一改，牵一发动全身。更要命的还不是换模型，而是多模型并行。你希望用户问题先走贵的优质模型，命中某些关键词就降级到便宜模型；或者按概率分配一部分流量给新模型做灰度。这些需求一旦出现，手写适配层的复杂度就上来了。LiteLLM 的思路，是学“通用充电口”的做法。不管底下的模型长什么样，你需要输入的都是一套统一参数：模型名、消息列表、温度等。你得到的返回，也统一成一个结构。相当于给不同厂家提供的充电协议套上同一个物理接口，你的业务方只需要认识这一种接口就行。1.2 核心能力矩阵LiteLLM 不是一个单点小工具，它的功能是成体系的。我把它常用的能力整理成一张表：能力模块解决的问题通俗解释统一接口多家 API 格式不一致所有模型都用一套参数调用，返回统一格式模型路由 Router选哪个模型处理请求按预算、按延迟、按优先级做分发负载均衡单模型压力过大多个 Key 或多个供应商之间轮询分配流量失败切换接口挂了不会崩请求失败自动换下一个可用模型日志与费用统计花了多少钱心里有数每次请求的输入输出 token 数、费用自动记录Mock 测试不想花真钱调接口返回预先写好的模拟结果，方便联调Key 管理与配额多人共用不混乱分别给不同人、不同项目分配不同额度我自己最看重的，是它的“统一接口”和“费用追踪”这两块。前者解决了写代码时的头疼，后者解决了汇报时的头疼。剩下那些能力，都是在生产环境中滚过之后才会切实感受到价值的。2. 半小时跑通：安装部署与初始配置2.1 安装与启动LiteLLM 安装很简单，核心就是 pip 装一个包。如果你要跑代理服务，建议把扩展依赖一起装上。pip install 'litellm[proxy]'装完之后，最快的方式是先跑通一个单模型配置。不需要额外写文件，直接用命令行传参也行：litellm --model gpt-3.5-turbo --port 4000这样它会起一个本地 HTTP 服务，监听 4000 端口，然后把/chat/completions路径代理给目标模型。你本地可以用任何一个 OpenAI 风格的 SDK 去连它，只要把 base_url 改成http://localhost:4000。但实际项目里我更推荐用配置文件的方式，因为配置是“可版本管理”的资产，后面改路由、改限额都在文件里改，不用改代码。启动命令变成了：litellm --config config.yaml --port 40002.2 配置文件拆解新建一个config.yaml，内容大概长这样：model_list: - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_key: os.environ/OPENAI_API_KEY - model_name: claude-3-5-sonnet litellm_params: model: anthropic/claude-3-5-sonnet api_key: os.environ/ANTHROPIC_API_KEY - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_key: os.environ/OPENAI_API_KEY rpm: 60这里有一个很关键的概念区分：model_name是“别名”，是你暴露给你的业务方的名字；litellm_params.model才是真正请求供应商时用的完整模型名。它前面那个前缀，比如openai/、anthropic/，是 LiteLLM 识别供应商的依据，千万别省。api_key填os.environ/XXX表示从环境变量读取，这样不会把密钥写进仓库。你可以在.env文件里配好，然后启动时让它加载。2.3 为什么推荐走网关而不是 SDK 直连有人可能会问：我直接在代码里用 LiteLLM 的 Python SDK 不就好了，何必再套一层 HTTP 代理？两种方式都有用，但适用阶段不同。SDK 方式适合单体应用，你只需要在自己的 Python 代码里统一调用，省去起服务的运维成本。但如果你所在的项目有多个服务，比如一个用 Python 写的分析服务，一个用 Node.js 写的客服后端，还有一个跑在定时任务里的脚本，都要调模型，SDK 方式就得每种语言各写一遍适配。HTTP 代理方案解决的是“语言无关的团队级统一入口”。所有服务只要会发 HTTP 请求，就能用统一的接口接入。再加上代理层可以统一做限流、审计、费用统计，这就不是一个 SDK 能做到的事了。所以在真正的生产环境里，我倾向于把 LiteLLM 跑成一个独立网关服务，而不是塞进某个业务进程里。3. 核心功能实操：路由策略与负载均衡3.1 用 Router 做智能分发除了代理模式，LiteLLM 还提供 Python 的 Router 类。它和网关的底层路由逻辑是一样的，但适合在你自己的代码里做更精细的控制。看一个简单例子：from litellm import Router router = Router( model_list=[ { "model_name": "gpt-4o-mini", "litellm_params": {"model": "openai/gpt-4o-mini", "api_key": "sk-xxxx"}, "model_info": {"rpm": 60, "input_cost_per_token": 0.00000015, "output_cost_per_token": 0.0000006}, }, { "model_name": "gpt-4o", "litellm_params": {"model": "openai/gpt-4o", "api_key": "sk-xxxx"}, "model_info": {"rpm": 30}, }, ], routing_strategy="simple-shuffle" ) resp = await router.acompletion( model="gpt-4o-mini", messages=[{"role": "user", "content": "给我讲个冷笑话"}] )Router 会维护一个可用模型列表，每次请求时根据路由策略选一个去执行。simple-shuffle是洗牌式轮询，压力均匀分散；还有least-busy，会看并发数最少优先，更适合处理长任务；usage-based-routing则可以根据实时 token 消耗来做成本敏感路由。3.2 失败自动切换：不能让一个接口拖垮全部多模型接入最大的好处，是一家接口挂了，另一家还能顶上。LiteLLM 的 Router 支持fallbacks参数，可以配置一组备用模型。router = Router( model_list=[...], fallbacks=[{"model": "gpt-4o", "fallbacks": ["claude-3-5-sonnet"]}], )意思是，当 gpt-4o 请求失败时，自动重试 claude-3-5-sonnet。如果 claude 也失败，还可以继续往下排。需要留意的是，fallbacks列表是优先顺序，不是随机选择。这个能力对生产环境非常实用，因为模型供应商偶尔还会出现限流，自己写重试和切换逻辑的话，考虑的点特别多，用现成的路由配置省心省力。3.3 成本预算与限流配置LiteLLM 在 Router 和代理模式里都支持max_budget。比如一个项目每天的消耗不能超过 10 美元，配置一个全局预算就行：general_settings: master_key: sk-1234 database_url: os.environ/DATABASE_URL max_budget: 10当所有 Key 的累计费用超过预算后，新的请求会直接返回预算超限的错误。如果你把database_url配好，它能持久化记录 spend 数据；否则只是内存中的临时计数，一重启就清零，这个要注意。限流方面，我测下来最需要注意的是rpm和tpm。rpm是每分钟请求数，tpm是每分钟 token 数。在litellm_params里给不同模型配置自己的rpm，代理层会自动排队或拒绝超限请求。实际生产里，建议把rpm设置成低于供应商限流阈值的 80%，宁可自己先限，也别让上游先 429。4. 生产级监控：日志、配额与费用追踪4.1 请求日志与用量汇总用过一段时间之后你会发现，模型调用记录的价值不亚于模型本身。谁在调、调的什么模型、花了多少钱、成功失败情况，这些信息如果散落在业务日志里，排查问题就会非常痛苦。LiteLLM 的解决方式是内置回调机制。你在配置里声明要写到哪里，它就会在每次请求完成时把用量数据推过去。常见做法是把日志写到数据库里，入库后自己做查询和可视化。配置示例：litellm_settings: drop_params: true success_callback: ["postgres"] failure_callback: ["postgres"]用到一个数据库连接串后，你就能查到每一笔请求的模型名、token 数量、费用估算。我实际查得最多的是“某个接口某一天各模型的调用次数和费用”，有了统一日志以后，这类问题从翻日志变成了写一条 SQL。4.2 给不同成员设置独立配额如果你在团队内部用了代理模式，最直接的需求是：不同成员或不同项目，预算不能混在一起。比如前端项目组这个月有 50 美元额度，后端实验组有 100 美元额度。LiteLLM 支持在代理里创建虚拟 Key，每个 Key 绑定自己的配额和预算。操作上，先通过/key/generate接口生成一个 Key：curl -X POST http://localhost:4000/key/generate \ -H "Authorization: Bearer sk-1234" \ -H "Content-Type: application/json" \ -d '{ "key": "sk-project-howard", "max_budget": 50, "models": ["gpt-4o-mini", "claude-3-5-sonnet"] }'生成的这个 Key 能调用的模型列表就是被限定死的，而且它单独计算预算，不会和全局混在一起。团队里每个人用一个独立 Key，月底看报表时哪些项目超支了，一目了然，不用再追着人问。4.3 Mock 模式：不花一分钱做联调开发调试时反复调用真实模型，既费钱又费时间。LiteLLM 支持mock_response参数，可以直接返回一个你写死的模拟结果。from litellm import completion resp = completion( model="gpt-4o-mini", messages=[{"role": "user", "content": "你好"}], mock_response="模拟返回：我很好！", )这个特性特别适合前端联调和自动化测试。前端需要调后端接口，但后端还没配好真实 API Key，或者不想消耗真实 token 时，直接在网关层把 mock_response 写进配置，整个链路就能跑通。等真正接上游时，只是把 mock_response 去掉而已，代码层面完全不用动。5. 踩坑实录与排查速查5.1 高频报错与解决现象可能原因解决方式401 Authentication Error上游 API Key 没配置或配错检查环境变量名是否和配置对应，打印确认环境变量是否加载成功ModelNotFoundErrormodel_name对应的配置不存在确认配置文件里model_list是否有这个别名，注意大小写响应延迟翻倍重试策略配置过密，失败后秒级重试多次调大重试间隔，或限制fallbacks数量token 统计稀疏未配置 cost 相关参数在model_info里补上input_cost_per_token等字段，否则无法估算费用429 限流频繁上游限制低于你的配置值降低rpm/tpm配置，或在路由层做次数衰减5.2 几个真实有用的配置细节第一，环境变量加载顺序是坑。直接用os.environ/XXX语法时，LiteLLM 会去读进程的环境变量。如果你用.env文件，要确认框架在启动时真的加载了它。我测试时经常是 .env 文件没被读进去，换成显式导出环境变量之后立刻就好了。第二，drop_params值得开。这个配置可以自动过滤掉某些模型不支持的参数。不同的模型对temperature、top_p的支持程度不一样，开了drop_params: true以后，LiteLLM 会把目标供应商不认识的参数在请求发出前剔除掉，能避免很多奇怪的入参报错。但注意也要全局验证一下效果，因为某些功能确实依赖特定参数。第三，模型名不要想当然。你在配置里写的anthropic/claude-3-5-sonnet，供应商侧是有严格拼写的。如果模型名写错了，LiteLLM 不会替你纠正，它会原样发给上游，然后报错。建议照着各家文档的完整模型标识来填。5.3 测试环境与线上环境隔离很多团队把 LiteLLM 部署之后，测试和线上共用一个网关，这在我眼里是大忌。你想做模型灰度，结果灰度的配置被线上请求一并带走了，事故就是这么来的。推荐的做法是拆成两个配置文件，一个config.dev.yaml，里面模型全用 mock_response 或者只接一个便宜的测试模型；另一个config.prod.yaml，走真实模型和完整配额。启动时用不同的端口侦听，测试环境也可以单独设一个较短的超时时间，让联调时问题暴露得更快。6. 一点个人体会和后续用法最后说一下我自己的实际感受。LiteLLM 这个项目最打动我的，不是某个单一功能有多强大，而是它把“接入多家模型”这件事从“开发难题”变成了“运维配置”。以前我接一个新模型，要写对接代码、测试兼容性、改异常处理；现在只需要在config.yaml里加一段，启动一下，就能在业务代码里用同一个接口调起来了。这种体验上的变化，用过一次就回不去。还有一个容易被忽略的价值是“模型选型的自由度”。因为适配层被 LiteLLM 吸收了，业务方不再被某一家模型绑死。今天觉得这家效果好就切这家，明天觉得价格高就换另一家，对业务代码几乎零侵入。这一点在一个项目生命周期里，意义远比省几百行代码大。如果你已经跑通了基础功能，我建议下一个可以尝试的方向是给自己的网关配一个可视化的用量面板，把 LiteLLM 记录的数据源接到图表工具里，每天扫一眼成本曲线和调用量变化。再用路由把不同流量分给不同模型，灰度效果直接量化。工具本身不难，难的是你有没有想清楚网关这一层到底要解决哪些问题。想明白了，LiteLLM 会是一个非常省心的底座。