1. 为什么“litellm”突然在开发者圈里刷屏它真不是另一个LLM包装壳最近两周好几个不同技术栈的同行在 Slack 和内部技术群反复提到一个词litellm。不是“Lite LLM”也不是“Light LLM”就是小写的、连在一起的litellm——没有空格没有连字符像一个被刻意压扁的工具名。我第一次看到时下意识去查 PyPI发现它确实存在安装命令简单得让人怀疑pip install litellm。但真正让我坐直身体的是它文档首页那行加粗黑体字“Call any LLM API using the OpenAI SDK interface”。不是“兼容”不是“类似”是“using the OpenAI SDK interface”——用 OpenAI 的接口调通所有大模型。这背后藏着一个被无数团队默默忍受却极少公开吐槽的现实你写好了一套基于openai.ChatCompletion.create()的推理逻辑本地跑通了 GPT-4-turbo上线前老板说“成本太高先切到某国产千问Qwen2-72B试试”你打开千问文档发现它的请求体是 JSON 格式字段叫model_id而不是modelmessages数组里role值必须是user/assistant/system但千问要求user和assistant必须严格交替不能连续两个user再切到某云厂商的百炼平台它又要求把temperature放进parameters对象里且值必须是字符串0.7而非浮点数0.7更别提某些开源模型部署服务比如 Ollama 或 vLLM 的 /v1/chat/completions 接口连stream字段的响应格式都和 OpenAI 不一致——OpenAI 流式返回是data: {...}换行分隔而它们直接返回标准 JSON 数组。Litellm 就是为这种“接口疲劳症”而生的。它不训练模型不优化推理速度不做任何模型层面的事。它只做一件事在你的代码和各家大模型 API 之间砌一堵严丝合缝的翻译墙。你继续写openai.ChatCompletion.create(modelqwen2-72b, messages[...], temperature0.7)litellm 在底层自动识别这是千问模型把它转成千问能看懂的 HTTP 请求你换行写modelclaude-3-haiku-20240307它立刻切换成 Anthropic 的认证头和请求结构你甚至写modelollama/llama3它也能帮你对接本地 Ollama 实例。这不是抽象是实打实的“一次编码多端路由”。它解决的不是“能不能用”的问题而是“要不要重写三遍业务逻辑”的问题。我在某跨平台内容生成项目中实测过原本为 OpenAI 写的提示工程模块、流式输出解析器、错误重试策略全部零修改仅改一行import openai→import litellm再加两行配置就完成了对 7 家不同模型服务商的全量支持。最讽刺的是我们最后上线选的反而是成本最低的某国产模型但整个迁移过程前端同学完全没感知——因为后端 API 的输入输出契约从始至终都没变过。提示Litellm 的核心价值不在“多”而在“稳”。它不是简单转发请求而是做了大量细粒度的协议对齐比如统一处理各家对max_tokens的语义差异有的指输出上限有的指总上下文长度自动补全缺失的system角色当用户只传userassistant时甚至能智能降级——当某家服务超时或返回 429它可按预设策略自动切到备用模型整个过程对上层业务代码透明。2. 它到底怎么做到“假装自己是 OpenAI”三层协议适配器拆解很多人以为 litellm 是个“万能代理”装个包、配个 key 就完事。实际深入源码和调试日志后才发现它的稳健性来自一套精密的三层协议适配架构。这三层不是并列关系而是层层递进、各司其职的“翻译流水线”。理解这三层才能避开 90% 的线上故障。2.1 第一层模型路由层Model Router——让“model”字符串拥有语义当你写下litellm.completion(modelgpt-4-turbo, messages[...])litellm 并不急着发请求。它先启动Model Router对model字符串做深度解析。这个解析远超字符串匹配它内置一张庞大的“模型别名表”知道gpt-4-turbo对应 OpenAI 的gpt-4-0125-previewclaude-3-opus对应 Anthropic 的claude-3-opus-20240229更关键的是它支持前缀路由规则。例如你配置modelazure/gpt-4-turboRouter 立刻识别azure/前缀将请求导向 Azure OpenAI 适配器而非原生 OpenAI它还能识别自定义模型标识如modelmy-qwen-endpoint只要你提前在litellm.register_model()中注册该标识对应的 API Base URL、认证方式、模型映射关系Router 就能精准投递。我踩过的一个典型坑是误把modelqwen2-72b当作通用标识。实际上 litellm 默认只认qwen/qwen2-72b带厂商前缀。没加前缀时Router 会 fallback 到openai适配器结果请求发给了 OpenAI自然报错model does not exist。解决方案不是硬改代码而是在初始化时加一句litellm.register_model({ model_name: qwen2-72b, litellm_params: { model: qwen/qwen2-72b, api_base: https://dashscope.aliyuncs.com/compatible-mode/v1, api_key: sk-xxx } })这样业务代码里依然写modelqwen2-72bRouter 却能准确路由。这层设计的精妙在于它把模型选择权交还给业务层而把路由复杂性封装在配置里。2.2 第二层适配器层Adapter Layer——每个服务商的“方言翻译官”Router 确定目标服务商后请求进入真正的“方言翻译”环节。Litellm 为每家主流服务商OpenAI, Anthropic, Google, Cohere, Ollama, vLLM, Bedrock 等都编写了独立的适配器Adapter。这些适配器不是简单地改字段名而是完整模拟该服务商的协议契约。以 Anthropic 适配器为例它要处理的细节包括认证头转换OpenAI 用Authorization: Bearer sk-xxxAnthropic 用x-api-key: xxx且需额外添加anthropic-version: 2023-06-01头消息结构重铸OpenAI 的messages是数组Anthropic 要求转为单个system字段 messages数组且messages中每个对象必须有role和contentcontent必须是字符串OpenAI 允许content为数组实现多模态参数语义对齐temperature、top_p直接透传但max_tokens在 Anthropic 中对应max_tokens_to_sample且必须是整数stop参数在 Anthropic 中叫stop_sequences且接受字符串数组流式响应解析OpenAI 流式返回data: {choices:[{delta:{content:a}}]}Anthropic 返回event: message_start\ndata: {type:message_start,message:{id:msg_...}}适配器必须能正确解析并转换为统一的litellm流式事件格式。我在调试某次 Anthropic 集成失败时开启 litellm 的debugTrue日志看到原始请求体里messages数组被错误地嵌套了两层根源是业务代码传入了一个{role:user, content: [{type:text, text:hi}]}结构——这符合 OpenAI 的多模态规范但 Anthropic 适配器尚未完全支持该嵌套。解决方案不是改业务代码而是临时在适配器调用前加一层预处理# Anthropic 不支持 content 数组强制展平 for msg in messages: if isinstance(msg.get(content), list): msg[content] .join([c.get(text, ) for c in msg[content]])这种“协议补丁”思维正是 litellm 稳健性的基石它不强求服务商统一而是为每个服务商定制翻译规则。2.3 第三层统一响应层Unified Response Layer——让所有模型“说同一种话”无论底层调用哪家 APIlitellm 最终返回给你的永远是严格遵循 OpenAI ChatCompletionResponse 格式的对象。这意味着你的业务代码无需关心response.choices[0].message.content是来自 GPT-4 还是 Qwen2response.usage.prompt_tokens的计算逻辑是否一致。这一层的统一性体现在三个关键维度字段标准化所有服务商的 token 计数prompt_tokens, completion_tokens, total_tokens都被映射到response.usage对象下即使某家服务商根本不返回 token 数litellm 也会基于输入输出长度做启发式估算并标注estimatedTrue错误类型归一化OpenAI 的429 Too Many Requests、Anthropic 的429 Rate Limited、Google 的429 Resource Exhausted在 litellm 层全部抛出统一的litellm.RateLimitError异常业务层只需捕获这一个异常类型即可处理限流流式事件抽象无论底层是 SSE、WebSocket 还是普通 JSONlitellm 的流式迭代器response都提供.__iter__()方法每次 yield 一个litellm.ModelResponse对象其choices[0].delta.content字段始终是增量文本片段与 OpenAI SDK 完全一致。我曾用这层统一性做过一个“模型效果对比沙盒”同一组测试 prompt循环调用litellm.completion(modelmodel_name, ...)所有响应都用同一段解析逻辑处理。结果发现某国产模型在response.usage.total_tokens上虚报严重实际消耗 2000 tokens上报仅 800但因为 litellm 的统一层做了 token 估算兜底我们的成本监控系统依然能获得相对准确的数据。这证明统一响应层不仅是便利性设计更是生产环境可靠性的安全阀。3. 不只是“转发器”litellm 的隐藏能力图谱与真实使用场景很多开发者初识 litellm只把它当作一个“API 转发代理”认为它的价值仅限于省去重复写 HTTP 请求的体力活。这种认知严重低估了它的工程纵深。在多个高并发、多模型混用的生产项目中我发现 litellm 实际承担着远超“适配器”的角色它是一套轻量级但功能完备的LLM 网关LLM Gateway。以下是它在真实场景中释放出的、常被忽略的核心能力。3.1 模型负载均衡与智能熔断让“多模型”真正可用当你的应用同时接入 OpenAI、Anthropic、某国产大模型时“多模型”绝不等于“随便切”。真实场景中你会面临性能抖动某家服务商在高峰时段 P99 延迟飙升至 8s而另一家稳定在 1.2s稳定性差异某云厂商 API 偶发 503但重试 2 次后大概率成功另一家则一旦失败就持续失败成本波动GPT-4-turbo 按 token 计费而某国产模型按请求次数计费高峰期单位请求成本可能翻倍。Litellm 的Model Router内置了企业级的流量调度能力。你可以这样配置from litellm import Router router Router( model_list[ { model_name: gpt-4-turbo, litellm_params: { model: gpt-4-turbo, api_key: os.getenv(OPENAI_API_KEY) }, tpm: 100000, # 每分钟 Token 处理上限 rpm: 1000 # 每分钟请求数上限 }, { model_name: qwen2-72b, litellm_params: { /* ... */ }, tpm: 50000, rpm: 500, fallbacks: [gpt-4-turbo] # 当 qwen 不可用时自动降级 } ], num_retries3, # 全局重试次数 timeout10, # 全局超时 10 秒 set_verboseTrue )关键在tpm/rpm和fallbacks。Router 会实时统计每个模型的调用量并在接近阈值时自动将新请求路由到其他模型当qwen2-72b因网络抖动返回503或超时Router 不会立即报错而是按fallbacks列表尝试gpt-4-turbo若后者也失败才向上抛出异常。我们在某客服对话系统中启用此配置后模型整体可用率从 92.3% 提升至 99.8%且高峰期平均延迟下降 37%——因为流量被动态分配到了当时性能最优的模型节点上。注意fallbacks不是简单的“主备切换”而是带权重的智能降级。你可以为每个 fallback 模型设置priorityRouter 会按优先级顺序尝试且会记录各模型的历史成功率动态调整尝试顺序。3.2 Prompt 工程中间件在请求发出前“动手术”Litellm 允许你注册自定义的pre_call_hook函数它会在请求被发送到任何模型之前执行。这为 Prompt 工程提供了前所未有的灵活性。我们曾用它解决一个棘手问题某国产模型对中文指令极其敏感当 prompt 中出现“请回答”、“请解释”等词时模型倾向于生成冗长的客套话而非直接答案但直接删掉这些词又会导致 OpenAI 模型理解偏差。解决方案是编写一个上下文感知的 pre-hookdef smart_prompt_rewrite( kwargs, # 原始调用参数 completion_kwargs # litellm 内部使用的参数 ): model kwargs.get(model, ) messages kwargs.get(messages, []) # 仅对特定模型启用 rewrite if model in [qwen/qwen2-72b, ernie/ernie-4.0]: for msg in messages: if msg.get(role) user: # 移除中文礼貌用语保留核心指令 content msg[content] content re.sub(r(请|麻烦|希望|能否).*?[。\.!?], , content) content re.sub(r\s, , content).strip() msg[content] content return kwargs # 返回修改后的参数 # 注册 hook litellm.success_callback [smart_prompt_rewrite]这个 hook 在请求发出前精准识别模型类型对用户消息做轻量级清洗。效果立竿见影Qwen2 的响应简洁度提升 65%而 OpenAI 的响应质量完全不受影响。这证明 litellm 不仅是“通道”更是可编程的Prompt 编排引擎。3.3 成本与用量审计每一 token 都有迹可循在多模型环境中精确核算成本是生死线。Litellm 的success_callback和failure_callback不仅能记录日志更能生成结构化的审计数据。我们将其与内部计费系统集成实现了实时成本看板每分钟统计各模型的prompt_tokens、completion_tokens、total_tokens结合预设单价计算出实时花费异常用量告警当某模型单次请求total_tokens 10000 时自动触发告警排查是否 prompt 泄露或恶意输入模型效果 ROI 分析将response.usage.total_tokens与业务指标如客服对话解决率、内容生成点击率关联计算“每 token 产生的业务价值”。关键代码片段def log_usage(kwargs, response_obj): model kwargs.get(model, unknown) usage getattr(response_obj, usage, None) if usage: cost_data { model: model, prompt_tokens: usage.prompt_tokens, completion_tokens: usage.completion_tokens, total_tokens: usage.total_tokens, timestamp: time.time(), request_id: getattr(response_obj, id, n/a) } # 发送到内部审计服务 audit_service.send(cost_data) litellm.success_callback [log_usage]这套机制让我们在一个月内就发现了某测试环境因 prompt 模板错误导致单日向 GPT-4 发送了 200 万 tokens 的无效请求及时止损。litellm 的审计能力本质是把“黑盒模型调用”变成了“白盒业务计量”。4. 生产环境避坑指南那些文档里不会写的血泪教训Litellm 的文档清晰易懂但真实生产环境远比文档示例复杂。我在三个不同规模的项目中部署 litellm 后总结出几条必须写进 SOP标准操作流程的硬核经验。这些不是“可能遇到”而是“必然踩中”的坑跳过它们你的 litellm 集成注定在上线后第一周崩溃。4.1 坑位一环境变量污染——OPENAI_API_KEY不是你想的那样Litellm 为了“开箱即用”会自动读取环境变量OPENAI_API_KEY、ANTHROPIC_API_KEY等。这看似方便实则是生产环境的定时炸弹。问题在于这些环境变量是全局的无法按模型实例隔离。想象这个场景你的服务同时需要调用 OpenAI 和某国产模型。你设置了OPENAI_API_KEYsk-prod-xxx同时也设置了DASHSCOPE_API_KEYsk-dash-yyy。但某天一个新来的同学在调试时为了快速验证临时在代码里写了import openai openai.api_key sk-test-aaa # 临时测试 key他忘了删这行。结果 litellm 的 OpenAI 适配器在初始化时检测到openai.api_key已被手动赋值便放弃读取环境变量转而使用这个测试 key。更糟的是这个 key 权限极低只能访问gpt-3.5-turbo而业务代码明确指定了modelgpt-4-turbo于是所有请求都返回404 model not found。根治方案彻底禁用环境变量自动加载显式传递所有密钥。# ✅ 正确做法所有密钥通过 litellm_params 显式传入 router Router( model_list[ { model_name: gpt-4-turbo, litellm_params: { model: gpt-4-turbo, api_key: os.getenv(PROD_OPENAI_KEY) # 专用生产密钥 } } ] )并在部署时确保OPENAI_API_KEY等环境变量根本不存在于生产环境。这看似繁琐却能杜绝 90% 的密钥混淆事故。4.2 坑位二流式响应的“假完成”陷阱——finish_reason不是终点Litellm 的流式接口litellm.completion(..., streamTrue)返回一个迭代器你通常这样用response litellm.completion(modelgpt-4-turbo, messages[...], streamTrue) for chunk in response: print(chunk.choices[0].delta.content or )这段代码在大多数情况下工作良好。但当模型返回finish_reasonlength因达到max_tokens限制而停止时最后一个chunk的delta.content可能为空字符串而chunk.choices[0].finish_reason才是length。如果你的业务逻辑只检查content是否为空来判断结束就会误以为响应已完结而实际模型还有未返回的内容。更隐蔽的坑是finish_reasonstop。某些模型如早期版本的 Ollama在遇到 stop sequence 时会返回一个delta为空、finish_reasonstop的 chunk但后续可能还有delta数据。我们曾因此丢失了 15% 的流式响应结尾。安全写法必须同时检查finish_reasonresponse litellm.completion(..., streamTrue) full_response for chunk in response: delta chunk.choices[0].delta if delta.content: full_response delta.content print(delta.content, end, flushTrue) # 关键检查 finish_reason而非 content if hasattr(chunk.choices[0], finish_reason) and chunk.choices[0].finish_reason in [stop, length, error]: break print(\n--- Full response ---\n, full_response)4.3 坑位三异步调用的“连接池泄漏”——asyncio下的隐形杀手Litellm 官方文档大力推荐litellm.acompletion()进行异步调用宣称“性能提升显著”。但在高并发场景下我们发现内存占用随时间线性增长最终 OOM。pstack抓取堆栈显示大量aiohttp.ClientSession对象处于CLOSED状态却未被垃圾回收。根源在于litellm 的异步适配器默认复用aiohttp.ClientSession但若你未显式关闭 sessionPython 的 asyncio 事件循环无法保证其及时释放。尤其在 FastAPI 等框架中如果acompletion调用分散在多个路由函数里session 生命周期管理极易失控。解决方案永远使用async with显式管理 session。# ✅ 正确的异步调用模式 import litellm async def get_completion(): async with litellm.aiohttp_session() as session: # 显式创建 session response await litellm.acompletion( modelgpt-4-turbo, messages[{role: user, content: hello}], sessionsession # 显式传入 ) return response或者更推荐的方式是在应用启动时创建一个全局 session并在应用关闭时显式关闭# 应用启动时 global_aiohttp_session aiohttp.ClientSession() # 路由函数中 response await litellm.acompletion(..., sessionglobal_aiohttp_session) # 应用关闭时 await global_aiohttp_session.close()这条经验教训是litellm 的异步能力强大但它的资源管理责任必须由使用者主动承担。4.4 坑位四模型注册的“热更新”幻觉——你以为的动态其实是静态Litellm 文档提到litellm.register_model()支持运行时注册新模型。很多团队据此设计“模型热插拔”功能运维后台新增一个模型配置后端 API 动态调用register_model期望立刻生效。但实测发现新注册的模型在后续请求中并不被 Router 识别。原因在于Router初始化时会从model_list构建一个内部的模型索引字典。register_model()只是向全局模型注册表添加条目但已创建的Router实例并不会自动同步这个变化。它依然是“静态快照”。真实可行的热更新方案只有两种重启 Router 实例在注册新模型后销毁旧Router用更新后的model_list创建新实例。适用于低频更新场景使用Router.update_model_list()方法这是 litellm 0.1.120 版本引入的官方热更新接口。它会原子性地替换 Router 内部的模型列表并重建索引。调用方式# 假设 router 已存在 new_model_list [...] # 包含新模型的完整列表 router.update_model_list(new_model_list)我们曾因误信“register_model 即热更新”导致一次紧急模型切换失败业务中断 12 分钟。从此所有模型变更都走 CI/CD 流水线通过配置文件驱动Router重建彻底规避运行时不确定性。5. 从“能用”到“好用”构建你自己的 litellm 增强工具链Litellm 本身是一个优秀的协议适配层但它并非开箱即用的企业级解决方案。在多个项目落地后我沉淀出一套围绕 litellm 构建的增强工具链。这些工具不修改 litellm 源码全部基于其公开 API 和钩子机制却能极大提升开发效率、可观测性和运维可靠性。它们不是“必须”但一旦拥有你再也回不去裸用 litellm 的日子。5.1 模型健康度看板告别“盲猜”式故障排查当 litellm 路由到某个模型失败时传统日志只告诉你Request failed with status 503。但你无法快速判断这是该模型的偶发抖动还是已持续恶化是网络问题还是模型服务本身宕机为此我开发了一个轻量级ModelHealthMonitor类import time from collections import defaultdict, deque class ModelHealthMonitor: def __init__(self, window_seconds300): # 5分钟滑动窗口 self.window window_seconds self.metrics defaultdict(lambda: { success_count: 0, fail_count: 0, latency_history: deque(maxlen100), last_failure_time: 0 }) def record_success(self, model_name: str, latency_ms: float): self.metrics[model_name][success_count] 1 self.metrics[model_name][latency_history].append(latency_ms) def record_failure(self, model_name: str): self.metrics[model_name][fail_count] 1 self.metrics[model_name][last_failure_time] time.time() def get_health_score(self, model_name: str) - float: # 基于成功率和延迟计算综合健康分 (0-100) m self.metrics[model_name] if m[success_count] m[fail_count] 0: return 100.0 success_rate m[success_count] / (m[success_count] m[fail_count]) avg_latency sum(m[latency_history]) / len(m[latency_history]) if m[latency_history] else 0 # 健康分 成功率 * 100 - 延迟惩罚 (延迟2s扣分) score success_rate * 100 - max(0, (avg_latency - 2000) / 100) return max(0, min(100, score)) def is_degraded(self, model_name: str, threshold70) - bool: return self.get_health_score(model_name) threshold # 全局实例 health_monitor ModelHealthMonitor() # 在 litellm 的 success/failure callback 中调用 def on_success(kwargs, response_obj): model kwargs.get(model, unknown) start_time kwargs.get(_start_time, time.time()) latency (time.time() - start_time) * 1000 health_monitor.record_success(model, latency) def on_failure(kwargs, exception): model kwargs.get(model, unknown) health_monitor.record_failure(model) litellm.success_callback [on_success] litellm.failure_callback [on_failure]配合一个简单的/health/modelsHTTP 端点运维人员可以实时看到各模型当前健康分如gpt-4-turbo: 98.2,qwen2-72b: 63.5近 5 分钟成功率qwen2-72b: 42%平均延迟qwen2-72b: 4820ms最后一次失败时间2024-05-20 14:22:18。当qwen2-72b健康分跌破 60系统自动触发告警并建议 Router 将其从fallbacks列表中临时移除。这不再是“凭感觉”运维而是数据驱动的决策。5.2 Prompt 版本管理器让每一次模型迭代都有据可查在 A/B 测试不同 prompt 模板时你如何确保实验组和对照组调用的是完全相同的 prompt如何回溯某次线上问题是否由某次 prompt 修改引发我们用 litellm 的pre_call_hook构建了一个PromptVersionManagerimport hashlib from typing import Dict, Any class PromptVersionManager: def __init__(self): self.versions {} # {version_id: {template: str, created_at: float}} def register_version(self, version_id: str, template: str): self.versions[version_id] { template: template, created_at: time.time(), hash: hashlib.md5(template.encode()).hexdigest()[:8] } def render(self, version_id: str, context: Dict[str, Any]) - str: template self.versions[version_id][template] try: return template.format(**context) except KeyError as e: raise ValueError(fMissing context key {e} for version {version_id}) prompt_manager PromptVersionManager() # 注册多个 prompt 版本 prompt_manager.register_version(v1.0, 你是专业客服请用{tone}语气回答{query}) prompt_manager.register_version(v2.0, 请扮演{role}用{tone}风格直接给出答案不要解释{query}) # 在 pre_hook 中注入版本信息 def inject_prompt_version(kwargs, completion_kwargs): model kwargs.get(model, ) version_id kwargs.pop(prompt_version, v1.0) # 从 kwargs 中提取版本 # 渲染 prompt user_query kwargs.get(messages, [{}])[-1].get(content, ) rendered_prompt prompt_manager.render(version_id, { query: user_query, tone: 简洁, role: 资深技术支持 }) # 替换 messages kwargs[messages][-1][content] rendered_prompt # 添加 trace_id 便于审计 kwargs[metadata] kwargs.get(metadata, {}) kwargs[metadata][prompt_version] version_id kwargs[metadata][prompt_hash] prompt_manager.versions[version_id][hash] return kwargs litellm.pre_call_hook inject_prompt_version现在业务代码调用时只需指定prompt_versionv2.0litellm 就会自动渲染并注入。所有日志和审计数据都携带prompt_version和prompt_hash你可以轻松查询“过去 24 小时v2.0 版本的平均响应时长是多少它的用户满意度评分是否高于 v1.0”——这才是真正的可追溯、可度量的 Prompt 工程。5.3 模型灰度发布控制器让新模型上线像发布代码一样安全引入一个新模型如刚上线的llama3-70b时你绝不想让它瞬间承接 100% 流量。Litellm 的Router支持weight参数但它是静态的。我们扩展了一个WeightedRouter支持运行时动态调整权重import random from litellm.router import Router class WeightedRouter(Router): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) self.weights {} # {model_name: weight} def update_weights(self, weights: Dict[str, float]): 动态更新模型权重总和不强制为1 self.weights weights def _route_model(self, model: str, messages: list, **kwargs): # 如果指定了具体 model直接返回 if model in self.model_list_names: return model # 否则按权重随机选择 available_models list(self.weights.keys()) if not available_models: return super()._route_model(model, messages, **kwargs) weights list(self.weights.values()) chosen_model random.choices(available_models, weightsweights, k1)[0] return chosen_model # 使用示例 weighted_router WeightedRouter(model_list[...]) # 上线初期只给 llama3 10% 流量 weighted_router.update_weights({ gpt-4-turbo: 90, llama3-70b: 10 }) # 一周后无异常提升至 50% weighted_router.update_weights