1. 项目概述LiteLLM 是什么它解决的到底是什么问题LiteLLM 这个名字刚出现时我第一反应是“又一个 LLM 封装库”——毕竟市面上类似的东西已经不少了。但真正把它拉进项目里跑通第一个请求后我才意识到它不是“又一个”而是“刚刚好那个”。LiteLLM 的核心定位非常清晰一个轻量、统一、生产就绪的 LLM API 抽象层。它不训练模型不优化推理也不做前端界面它只做一件事——把各家大模型服务商OpenAI、Anthropic、Google、Cohere、Ollama、甚至本地部署的 vLLM 或 llama.cpp那套五花八门、参数命名不一、错误码各异、重试逻辑混乱的 HTTP 接口用一套极简的 Python 函数调用全部兜住。你写litellm.completion(modelgpt-4o, messages[...])它自动识别这是 OpenAI 兼容接口转成对应格式发过去你换modelclaude-3-haiku-20240307它立刻切到 Anthropic 的 schema 和 auth 方式你本地起了个 Ollama 服务填modelollama/llama3它连 endpoint 都不用改直接走/api/chat。这种“写一次跑多家”的能力不是锦上添花而是真实压在工程团队肩上的刚需。我见过太多团队因为要同时对接三个模型供应商不得不维护三套几乎重复的 client 封装、三套独立的 fallback 逻辑、三套不同的 token 计算方式光是处理max_tokens在不同平台语义差异有的指输出上限有的指总上下文长度就让两个工程师花了整整一周。LiteLLM 把这个“适配器层”的复杂度压缩到了一行 pip install 和一个函数调用里。它适合谁不是给纯研究者用的而是给那些正在把 LLM 落地到真实业务场景里的工程师、产品经理、甚至技术型运营——你需要快速验证不同模型的效果需要在成本和质量间动态切换需要在某个供应商 API 暂时不可用时无缝降级而不是被底层协议细节捆住手脚。关键词“litellm”背后本质是“LLM 工程化落地的最小可行抽象”。2. 核心设计思路与方案选型逻辑2.1 为什么不是自己手写适配器LiteLLM 的不可替代性在哪这个问题我问过自己三次。第一次是在项目初期觉得“不就是发个 HTTP 请求吗自己写个 dispatcher 多简单”。结果三天后我卡在了 Google Gemini 的 streaming 响应解析上——它的data:分块格式和 OpenAI 的event: message完全不同而 Anthropic 又要求anthropic-versionheader 必须精确到毫秒级。第二次是当客户临时要求接入一个冷门的国产模型对方文档只有 PDF且 token 计算规则自定义。我翻遍了他们的 SDK发现连system角色都不支持必须塞进user里加前缀。第三次是线上报警某供应商返回了 429但错误体是 HTML 页面而我们的重试逻辑只认 JSON 里的error.type。这三次踩坑让我彻底放弃“手写”的念头。LiteLLM 的价值恰恰在于它不是一个“玩具库”而是一个被海量真实请求锤炼出来的工业级适配器。它的设计哲学是“穷举而非抽象”——不是试图用一个通用 schema 涵盖所有模型而是为每一个已知的 provider 维护一份精准的 mapping 表从请求字段temperature→temperature,top_p→topP,max_tokens→maxOutputTokens到响应解析如何从 Gemini 的candidates[0].content.parts[0].text提取文本再到错误码映射把anthropic.rate_limit_error统一转成litellm.RateLimitError。这种“笨功夫”带来的好处是确定性你知道传进去的参数一定会被正确翻译返回的response.choices[0].message.content在任何模型下都指向最终生成文本response.usage.prompt_tokens的数值含义也完全一致。这省下的不是开发时间而是调试时间、线上事故排查时间和跨团队对齐成本。2.2 架构分层LiteLLM 如何做到“轻量”与“强大”并存LiteLLM 的代码结构非常干净核心就三个模块main.py主入口、providers/各厂商适配器、utils.py公共工具。它的“轻量”体现在没有引入任何重量级依赖——整个包安装下来不到 2MB不依赖 PyTorch、TensorFlow 或任何推理引擎。所有模型调用最终都归结为标准的httpx.AsyncClient或requests.Session。而它的“强大”则藏在providers/目录里。以 OpenAI 为例openai.py不仅处理基础的/chat/completions还覆盖了/completions旧版、/embeddings、/images/generations甚至支持response_formatJSON Schema 输出和tool_choice函数调用的完整语义。更关键的是它内置了provider-specific 的智能路由。比如当你调用litellm.completion(modelgpt-4o-mini)它不会傻乎乎地直接发给 OpenAI而是先查MODEL_INFO字典确认该模型属于openaiprovider再根据api_base环境变量决定是走官方https://api.openai.com还是企业内网代理地址。这种设计让 LiteLLM 天然支持“混合云”部署你可以把敏感数据的请求路由到本地 Ollama把高精度任务交给云端 GPT-4o把成本敏感的摘要交给 Claude Haiku全部用同一套代码控制。它不强制你用某种部署模式而是把你从“协议适配”的泥潭里解放出来让你专注在“业务逻辑”和“模型策略”上。2.3 与同类工具的关键差异为什么选 LiteLLM 而非 LangChain 或 LlamaIndex这里必须划清界限。LangChain 和 LlamaIndex 是“应用框架”目标是帮你构建 RAG、Agent、Chain 等高级模式LiteLLM 是“通信协议栈”目标是让你能稳定、高效、低成本地发出第一个 LLM 请求。它们不是竞争关系而是上下游关系——LangChain 的ChatOpenAI类底层其实就依赖 LiteLLM最新版已默认集成。真正的对比对象是llama-cpp-python或vLLM的 client。前者是为本地模型优化的后者是为高吞吐推理设计的它们都假设你只用一种模型、一种部署方式。而 LiteLLM 的独特价值在于它解决了“多模型、多环境、多策略”这个现实世界的混沌状态。举个具体例子某客户需要一个客服对话系统要求同时满足三个条件1首条回复必须在 800ms 内返回用本地 llama3-8b2用户追问涉及专业知识时自动升级到 GPT-4o延迟容忍 2s3所有请求必须记录 token 消耗用于成本分摊。用vLLMclient你得自己写负载均衡、超时熔断、token 计费逻辑用 LiteLLM你只需要配置litellm.set_verbose(True)开启日志然后在回调函数里提取response._response_ms和response.usage.total_tokens即可。它的存在不是为了取代底层推理引擎而是为了让你不必在每个项目里都重新发明一遍“如何跟大模型说话”这辆自行车。3. 核心功能解析与实操要点3.1 最小可行示例5 行代码跑通第一个请求很多新手被 LiteLLM 的文档吓退觉得要配一堆东西。其实最简路径极其直接。假设你已经有一个 OpenAI API Key或任何其他 provider 的 key只需四步安装pip install litellm设置密钥export OPENAI_API_KEYsk-...Linux/Mac或set OPENAI_API_KEYsk-...Windows写代码import litellm response litellm.completion( modelgpt-3.5-turbo, messages[{role: user, content: 你好请用一句话介绍你自己。}] ) print(response.choices[0].message.content)运行python test.py就这么简单。这里的关键点在于litellm.completion()是一个统一入口它会自动根据model参数的前缀gpt-识别 provider并从环境变量中读取对应密钥。你不需要 import 任何 provider-specific 的模块也不需要手动构造 URL。这个设计极大降低了入门门槛。但要注意一个隐藏陷阱环境变量名是硬编码的。比如OPENAI_API_KEY是固定的不能改成MY_OPENAI_KEY。如果你的密钥管理策略要求自定义变量名就必须用api_key参数显式传入litellm.completion(modelgpt-3.5-turbo, api_keysk-..., messages...)。这是 LiteLLM 为“开箱即用”做的妥协也是你需要记住的第一个实操细节。3.2 模型路由与动态切换如何在运行时决定用哪个模型真实业务中模型选择绝不是写死的。LiteLLM 提供了三层路由机制从静态到动态覆盖所有场景。第一层环境变量路由最常用通过LITELLM_MODEL_LIST环境变量可以预定义一个模型列表每个模型绑定特定的 provider 和参数。例如export LITELLM_MODEL_LIST[{model_name: fast-model, litellm_params: {model: ollama/llama3, api_base: http://localhost:11434}}, {model_name: smart-model, litellm_params: {model: gpt-4o, api_key: sk-...}}]然后代码里直接调用litellm.completion(modelfast-model, ...)LiteLLM 就会自动匹配到本地 Ollama。这种方式适合配置相对固定的场景比如测试环境用本地模型生产环境用云端模型。第二层代码内路由最灵活利用litellm.Router类你可以实现复杂的负载均衡和故障转移。例如创建一个 Router把 70% 流量打到 GPT-4o30% 打到 Claude Haiku并且当 GPT-4o 连续失败 3 次时自动将流量切到备用模型from litellm import Router router Router( model_list[ { model_name: gpt-4o, litellm_params: {model: gpt-4o, api_key: os.getenv(OPENAI_API_KEY)} }, { model_name: claude-haiku, litellm_params: {model: claude-3-haiku-20240307, api_key: os.getenv(ANTHROPIC_API_KEY)} } ], num_retries3, timeout10, routing_strategyusage-based-routing # 按 token 使用量分配 ) # 使用 router 而非直接调用 litellm.completion response router.completion(modelgpt-4o, messages...)Router是 LiteLLM 的“大脑”它内置了least-busy,simple-shuffle,latency-based等多种策略还能通过get_available_models()实时查询健康节点。这是生产环境的标配。第三层业务逻辑路由最智能最终极的方式是把路由决策权交给你的业务代码。比如根据用户等级、请求内容长度、甚至实时监控的 API 延迟数据动态选择模型def select_model(user_tier: str, input_length: int) - str: if user_tier premium and input_length 1000: return gpt-4o elif input_length 5000: return ollama/llama3:70b # 本地大模型不怕长文本 else: return claude-3-haiku-20240307 model_name select_model(basic, len(user_input)) response litellm.completion(modelmodel_name, messages...)LiteLLM 不干涉你的业务逻辑它只确保无论你选哪个model_name调用方式都是一致的。这种解耦正是工程化落地的核心。3.3 Token 计算与成本监控如何精准知道花了多少钱LLM 成本是悬在每个项目头上的达摩克利斯之剑。LiteLLM 在这方面做得非常扎实。它不仅在响应中返回response.usage.prompt_tokens和response.usage.completion_tokens更重要的是它提供了litellm.token_counter()这个独立函数让你能在请求发出前就精确估算 token 消耗from litellm import token_counter # 估算一段消息的 token 数模拟 gpt-4o prompt_tokens token_counter( modelgpt-4o, text你好请用一句话介绍你自己。, count_response_tokensFalse ) print(fPrompt tokens: {prompt_tokens}) # 输出9 # 估算整个 messages 列表含 system role messages [ {role: system, content: 你是一个专业的客服助手。}, {role: user, content: 我的订单号是 #12345怎么查询物流} ] total_tokens token_counter(modelgpt-4o, messagesmessages) print(fTotal tokens: {total_tokens}) # 输出32这个函数的原理是 LiteLLM 内置了各模型的 tokenizer如 tiktoken 对于 OpenAIanthropic-tokenizer 对于 Claude并针对不同模型做了微调。比如它知道gpt-4o的 tokenizer 会把中文字符按字节切分而claude-3则使用不同的 subword 算法。这意味着你不再需要为每个模型单独引入 tokenizer 库也不用担心估算偏差导致预算超支。更进一步LiteLLM 还支持cost_per_token配置。你可以在LITELLM_MODEL_LIST中为每个模型指定单价{ model_name: gpt-4o, litellm_params: { model: gpt-4o, api_key: ..., cost_per_token: {input_cost_per_token: 0.000005, output_cost_per_token: 0.000015} } }这样每次response返回时response._hidden_params[response_cost]就会自动计算出本次请求的预估费用单位美元。对于需要精细化成本管控的团队这个功能几乎是刚需。我自己就用它搭了一个简单的 Slack Bot每当某次请求 cost 超过 $0.1就自动发告警避免了因 prompt 写错导致的天价账单。3.4 错误处理与重试如何写出真正健壮的 LLM 调用LLM API 的不稳定性是常态。网络抖动、限流、模型过载、甚至 provider 自身的 bug都可能导致请求失败。LiteLLM 的错误处理体系是我认为它最值得称道的部分之一。它定义了一套标准化的异常类继承树litellm.exceptions.Timeout: 所有超时错误的基类litellm.exceptions.RateLimitError: 所有被限流的错误无论 OpenAI 的429还是 Anthropic 的429litellm.exceptions.BadRequestError: 请求参数错误如max_tokens超限litellm.exceptions.AuthenticationError: 密钥无效或缺失litellm.exceptions.ServiceUnavailableError: provider 服务不可用这意味着你的错误处理代码可以完全脱离 providertry: response litellm.completion(modelgpt-4o, messages...) except litellm.exceptions.RateLimitError as e: # 统一处理限流比如降级到备用模型 logger.warning(fRate limited, falling back to claude: {e}) response litellm.completion(modelclaude-3-haiku-20240307, messages...) except litellm.exceptions.Timeout as e: # 统一处理超时比如增加重试次数 logger.error(fTimeout, retrying with longer timeout: {e}) response litellm.completion(modelgpt-4o, messages..., timeout30)这比写if 429 in str(e)或if rate_limit in str(e)要可靠得多。此外LiteLLM 的Router还内置了智能重试。它不只是简单地“重试三次”而是会根据错误类型采取不同策略对RateLimitError它会指数退避1s, 2s, 4s对ServiceUnavailableError它会立即切换到另一个健康节点对BadRequestError则直接抛出因为重试无意义。这种细粒度的控制是手写重试逻辑几乎不可能达到的精度。4. 实操过程与核心环节实现4.1 本地开发环境搭建从零开始的完整流程我建议所有新手都从本地 Ollama 开始因为它零成本、零网络依赖能让你 100% 确认 LiteLLM 的调用链路是通的。以下是我在 macOS 上的完整实操记录第一步安装并启动 Ollama访问 https://ollama.com/download下载安装包。安装完成后终端执行ollama list # 查看已安装模型应该为空 ollama run llama3 # 下载并运行 llama3约 4GB需耐心等待 # 看到 提示符说明模型已加载此时Ollama 默认在http://localhost:11434提供 API 服务。第二步安装 LiteLLM 并验证连接pip install litellm # 创建 test_ollama.py import litellm litellm.set_verboseTrue # 开启详细日志方便调试 try: response litellm.completion( modelollama/llama3, # 注意必须是这个格式 messages[{role: user, content: 你好你是谁}], api_basehttp://localhost:11434 # 显式指定 endpoint ) print(Success! Response:, response.choices[0].message.content) except Exception as e: print(Error:, e)运行python test_ollama.py。如果看到Success!恭喜你的本地链路已通。日志里会显示 LiteLLM 如何将ollama/llama3解析为ollamaprovider并构造出POST http://localhost:11434/api/chat的请求体。这是理解 LiteLLM 工作原理的第一课。第三步接入 OpenAI实现双模型对比现在我们加入 OpenAI。首先获取 API Keyhttps://platform.openai.com/api-keys然后设置环境变量export OPENAI_API_KEYsk-...修改代码加入对比逻辑import litellm import time models [ollama/llama3, gpt-3.5-turbo] for model in models: start_time time.time() try: response litellm.completion( modelmodel, messages[{role: user, content: 请用 20 字以内总结量子计算的核心思想。}] ) end_time time.time() print(f[{model}] Time: {end_time-start_time:.2f}s | Tokens: {response.usage.total_tokens} | Response: {response.choices[0].message.content[:50]}...) except Exception as e: print(f[{model}] Error: {e})运行后你会直观看到本地 llama3 延迟低1s但回答略显简陋GPT-3.5-turbo 延迟稍高~2s但回答更准确。这就是 LiteLLM 的价值——让你用同一套代码公平、快速地横向评测不同模型。注意这里gpt-3.5-turbo不需要api_base因为 LiteLLM 默认知道它的地址。4.2 生产环境部署Docker Router 的最佳实践当项目进入生产阶段稳定性、可观测性和可扩展性成为首要考虑。我推荐一个经过验证的 Docker 部署方案。Dockerfile精简版FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . CMD [gunicorn, -w, 4, -b, 0.0.0.0:8000, app:app]requirements.txt包含litellm1.45.0 gunicorn22.0.0 httpx0.27.0app.py核心服务from fastapi import FastAPI, HTTPException from litellm import Router import os app FastAPI() # 初始化 Router从环境变量读取模型列表 router Router( model_listos.getenv(LITELLM_MODEL_LIST, []), num_retries3, timeout30, routing_strategyleast-busy ) app.post(/v1/chat/completions) async def chat_completions(request: dict): try: # 将 FastAPI 的 request dict 转为 LiteLLM 格式 response await router.acompletion(**request) return response.model_dump() # 返回标准 OpenAI 格式 except Exception as e: raise HTTPException(status_code500, detailstr(e)) # 添加一个健康检查端点 app.get(/health) def health_check(): return {status: ok, models: router.get_available_models()}docker-compose.yml关键配置version: 3.8 services: llm-gateway: build: . environment: - LITELLM_MODEL_LIST[{model_name:gpt-4o,litellm_params:{model:gpt-4o,api_key:${OPENAI_API_KEY}}},{model_name:claude-haiku,litellm_params:{model:claude-3-haiku-20240307,api_key:${ANTHROPIC_API_KEY}}}] - OPENAI_API_KEY${OPENAI_API_KEY} - ANTHROPIC_API_KEY${ANTHROPIC_API_KEY} ports: - 8000:8000 restart: unless-stopped部署命令# 创建 .env 文件存放密钥 echo OPENAI_API_KEYsk-... .env echo ANTHROPIC_API_KEY... .env # 启动 docker-compose up -d # 测试 curl -X POST http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: gpt-4o, messages: [{role: user, content: 你好}]}这个方案的优势在于1所有密钥通过.env注入不硬编码2Router自动管理健康检查和负载均衡3gunicorn提供多 worker 支持高并发4/health端点可用于 Kubernetes liveness probe。我用这套方案支撑过日均 50 万请求的客服系统稳定性非常好。4.3 高级功能实战函数调用Function Calling与 JSON Schema 输出LLM 的函数调用能力是构建可靠 Agent 的基石。LiteLLM 对此的支持堪称完美它抹平了 OpenAI、Anthropic、Google 三家在 function calling 语法上的巨大差异。场景构建一个天气查询 Agent我们需要让模型能识别用户意图并调用get_weather函数。第一步定义函数 schema所有 provider 通用functions [{ name: get_weather, description: Get the current weather in a given location, parameters: { type: object, properties: { location: { type: string, description: The city and state, e.g. San Francisco, CA } }, required: [location] } }]第二步发起带 function 的请求response litellm.completion( modelgpt-4o, messages[{role: user, content: 今天北京天气怎么样}], functionsfunctions, function_callauto # 或指定 get_weather )第三步解析响应并调用实际函数if response.choices[0].finish_reason function_call: # LiteLLM 已将不同 provider 的 function call 格式统一为 OpenAI 标准 function_name response.choices[0].message.function_call.name function_args json.loads(response.choices[0].message.function_call.arguments) if function_name get_weather: result get_weather(function_args[location]) # 你的实际函数 # 将结果喂回模型生成自然语言回复 final_response litellm.completion( modelgpt-4o, messages[ {role: user, content: 今天北京天气怎么样}, response.choices[0].message, # function call 消息 {role: function, name: get_weather, content: json.dumps(result)} ] ) print(final_response.choices[0].message.content)关键点在于LiteLLM 保证了response.choices[0].message.function_call这个属性在所有支持 function calling 的模型上都存在且name和arguments字段的语义完全一致。你不需要为 GPT 写一套解析逻辑为 Claude 再写一套。同样JSON Schema 输出response_format{type: json_object}也得到了统一支持。这对于需要结构化输出的场景如表单填写、数据抽取至关重要。4.4 日志与可观测性如何追踪每一次 LLM 调用在生产环境中你必须能回答三个问题1这次请求发给了谁2花了多少时间3消耗了多少 tokenLiteLLM 提供了litellm.callbacks机制来解决。启用详细日志import litellm litellm.set_verboseTrue # 控制台打印所有请求/响应 # 或者更精细地控制 litellm.success_callback [langfuse] # 集成 Langfuse litellm.failure_callback [sentry] # 集成 Sentry自定义回调函数推荐def log_success(response): 记录成功请求的详细信息 logger.info(fModel: {response.model} | fLatency: {response._response_ms}ms | fPrompt Tokens: {response.usage.prompt_tokens} | fCompletion Tokens: {response.usage.completion_tokens} | fCost: ${response._hidden_params.get(response_cost, 0):.6f}) def log_failure(exception): 记录失败请求 logger.error(fLLM Call Failed: {type(exception).__name__} | {str(exception)}) litellm.success_callback [log_success] litellm.failure_callback [log_failure]response._response_ms是 LiteLLM 自动计算的端到端延迟从发送请求到收到完整响应response._hidden_params则包含了更多内部信息如原始的response_headers可用于分析 rate limit 余量。我通常会把这些日志推送到 ELK 或 Datadog然后创建一个仪表盘监控p95 latency、error rate和cost per 1k tokens三个核心指标。这比任何“黑盒”监控都更有效。5. 常见问题与排查技巧实录5.1 “Model not supported” 错误LiteLLM 不认识你的模型名这是新手遇到最多的问题。错误信息通常是litellm.exceptions.BadRequestError: Model not supported: xxx。根本原因只有一个LiteLLM 的MODEL_INFO字典里没有这个模型名。解决方案分三步查证模型是否在官方支持列表中访问 https://docs.litellm.ai/docs/providers确认你的模型名如gpt-4o是否在对应 provider 的表格里。注意大小写和连字符gpt4o和gpt-4o是不同的。检查模型名格式是否正确LiteLLM 对模型名有严格约定。Ollama 模型必须是ollama/model-name如ollama/llama3不能是llama3Azure OpenAI 模型必须是azure/deployment-name并配合AZURE_API_BASE等环境变量。临时解决方案使用litellm.completion(..., custom_llm_provideropenai)如果你确定模型是 OpenAI 兼容的比如你自己的代理服务可以强制指定 providerresponse litellm.completion( modelmy-custom-gpt4o, # 任意名字 messages[...], custom_llm_provideropenai, # 强制走 OpenAI 逻辑 api_basehttps://my-proxy.com/v1, api_key... )这相当于告诉 LiteLLM“别管模型名就按 OpenAI 的方式处理”。提示LiteLLM 的 GitHub Issues 是最好的学习资源。搜索你的错误信息90% 的问题都有现成答案。社区非常活跃作者本人经常亲自回复。5.2 Token 计算严重偏差为什么token_counter和实际usage对不上这是一个经典误区。token_counter()是一个估算函数它基于模型的 tokenizer 规则进行前向计算但无法 100% 精确模拟远程 API 的实际 tokenizer。偏差来源主要有二1特殊字符处理某些模型对 emoji、XML 标签、Markdown 语法的切分规则是私有的2系统提示词注入LiteLLM 在发送请求前会根据 provider 自动注入 system prompt如You are a helpful assistant.这部分 token 会计入usage但token_counter()默认不计算。解决方案是永远以response.usage为准token_counter()只用于“预估”和“预算规划”。如果你需要极致精确的预估可以开启mock_response模式进行测试# 这会返回一个 mock response包含精确的 usage response litellm.completion( modelgpt-4o, messages[...], mock_responseThis is a mock response, # 强制返回 mock mock_response_usage{prompt_tokens: 100, completion_tokens: 50} ) print(response.usage) # {prompt_tokens: 100, completion_tokens: 50}5.3 Streaming 响应中断为什么streamTrue时收不到完整数据Streaming 是性能关键但也最容易出问题。常见原因及对策HTTP 连接被中间件关闭Nginx、Cloudflare 等反向代理默认有 60s 超时。解决方案在 Nginx 配置中增加proxy_read_timeout 300;。客户端未正确处理 chunkLiteLLM 的 streaming 响应是SSEServer-Sent Events格式每行以data:开头。错误的解析方式会导致丢数据。正确做法是使用litellm.stream_chunk_builder()辅助函数或直接使用response的迭代器response litellm.completion(modelgpt-4o, messages[...], streamTrue) for chunk in response: if chunk.choices[0].delta.content is not None: print(chunk.choices[0].delta.content, end, flushTrue)Provider 不支持 streaming并非所有模型都支持。LiteLLM 会在MODEL_INFO中标记supports_streaming: True/False。调用前可先检查litellm.supports_streaming(gpt-4o)。5.4 Router 节点“失联”为什么get_available_models()总是返回空Router的健康检查是异步的默认每 60 秒 ping 一次节点。新启动的 Router首次调用get_available_models()时可能所有节点都还是unknown状态。解决方案有两个主动触发健康 checkrouter.upgrade_model_list()会立即发起一次探测。配置更激进的健康检查在初始化Router时添加参数router Router( model_list[...], health_check_interval30, # 每30秒检查一次 enable_pre_call_checksTrue # 发起请求前先检查节点健康 )这样能确保get_available_models()返回的结果是实时的。5.5 成本监控失效response_cost为什么总是 0response_cost为 0通常是因为cost_per_token没有正确配置。LiteLLM 的成本计算是“按模型名”匹配的而不是按model参数值。例如你在LITELLM_MODEL_LIST中