1. 项目概述LiteLLM不是“轻量版大模型”而是统一调用层的工业级中间件LiteLLM这个词最近在技术圈里冒得特别快但很多人第一眼看到下意识就以为是某个新出的“小而美”开源大语言模型——比如参数量压缩到几亿、专为边缘设备优化的轻量模型。这其实是个典型的认知偏差。LiteLLM压根不训练模型也不推理模型它连GPU显存都不占它干的活是站在所有大模型API背后当那个穿西装打领带、管着二十家不同银行柜台的“统一业务调度员”。你写一行代码调用litellm.completion()它就能自动把请求转给OpenAI、Anthropic、Google Gemini、Ollama本地模型甚至国内几家主流云厂商的闭源接口全程对上层业务逻辑完全透明。我最早在某高校实验室做多模型对比实验时踩过这个坑当时要同时跑GPT-4、Claude-3和本地部署的Qwen2-7B每个API的请求格式、鉴权方式、流式响应结构、错误码定义全都不一样。光是写适配器就花了三天还反复出错——OpenAI返回choices[0].message.contentAnthropic却要从content[0].text里取Gemini又得解析candidates[0].content.parts[0].text。更崩溃的是某次Gemini接口升级字段名悄悄变了整个评测脚本直接崩掉排查了六小时才发现是底层协议抖动。后来换成LiteLLM三行配置搞定全部路由指定模型别名、映射真实后端、设置超时重试策略。真正实现“换模型不改业务代码”这才是它被大量工程团队快速接纳的核心价值。它解决的不是“能不能跑模型”的问题而是“怎么让模型服务像水电一样即插即用”的问题。适合三类人一是正在搭建AI应用中台的技术负责人需要屏蔽底层模型差异二是独立开发者想快速验证不同模型在自己业务场景下的效果不想被API细节拖慢节奏三是教学场景中的导师让学生专注提示词工程和结果分析而不是卡在curl命令怎么写。如果你还在手动拼接curl -H Authorization: Bearer xxx或者用一堆if-else判断模型类型那LiteLLM就是你现在最该了解的基础设施级工具。2. 核心设计思路为什么选择抽象API层而非模型微调或自建网关2.1 不做重复造轮子避开模型研发与运维的深水区很多团队第一次接触LiteLLM时会疑惑“既然要统一调用为什么不自己写个简单的HTTP代理”这个问题问到了关键。我参与过两个自研网关项目最终都回归LiteLLM根本原因在于——模型API的复杂度远超普通Web服务。举几个真实案例鉴权体系碎片化OpenAI用Bearer TokenAnthropic要求X-API-KeyGoogle Cloud必须用OAuth2 Service Account JSON密钥文件而某些国产模型平台则采用AccessKeySecretKeySignature三元组签名。自研网关要完整支持这些光是签名算法实现就得写上千行代码且每家文档更新滞后实际调试成本极高。流式响应结构不兼容OpenAI的SSE流每条数据是data: {choices: [...]}Anthropic是event: content_block_delta\ndata: {type:content_block_delta,delta:{text:...}}Ollama本地部署则直接返回JSON数组。LiteLLM内部做了标准化转换统一输出为{choices: [{delta: {content: ...}}]结构上层只需监听delta.content即可。我们曾实测自研流式解析模块在处理Anthropic长文本生成时因事件分隔符识别错误导致内容错位修复耗时两天。错误处理逻辑差异巨大OpenAI的429是{error: {type: rate_limit_exceeded}}Anthropic的429却是{error: {type: overloaded_error, message: Rate limit exceeded}}而某些私有化部署模型直接返回500并附带HTML错误页。LiteLLM内置了27种常见错误码的归一化映射将所有后端错误统一转为标准litellm.exceptions.RateLimitError等异常类业务层捕获逻辑变得极其简洁。LiteLLM的选择很清醒它不做模型不碰数据不碰GPU只做一件事——把千奇百怪的模型API变成程序员熟悉的、像调用Python函数一样自然的接口。这种定位让它避开了模型训练、量化部署、显存优化等高门槛领域反而在API治理这个“脏活累活”上建立了极高的护城河。2.2 协议兼容性优先为什么坚持OpenAI API作为事实标准LiteLLM官方文档开宗明义“It’s an open-source proxy to call 100 LLMs using the OpenAI SDK.” 这句话藏着一个关键决策以OpenAI API为锚点构建兼容生态。这不是技术偏见而是工程妥协的最优解。我们做过横向测试对比三种抽象方案——自定义通用Schema如{model: string, messages: [], temperature: number}以Anthropic Claude格式为基准以OpenAI Chat Completion格式为基准结果很清晰方案1需要业务方彻底改造调用习惯学习新协议方案2的Claude格式在社区生态中支持度远不如OpenAI而方案3OpenAI SDK已是事实上的行业标准——LangChain、LlamaIndex、DSPy等主流框架默认集成VS Code插件、Postman模板、教学视频全围绕它展开。LiteLLM选择方案3意味着开发者零学习成本pip install litellm后原有openai.ChatCompletion.create()代码只需把openai替换成litellm其余参数、返回结构、异步调用方式全部不变。更深层的价值在于生态迁移成本趋近于零。某公司原先用OpenAI GPT-4做客服对话因成本过高想切换到本地Qwen2-7B。若用自研网关需修改所有调用点、重写错误处理、适配流式响应而用LiteLLM只需在环境变量中设置export LITELLM_MODELqwen/qwen2-7b再启动Ollama服务业务代码一行不动。这种“热切换”能力在模型选型频繁迭代的当前阶段直接决定了AI项目的落地效率。2.3 架构轻量化设计单进程、无状态、零依赖的极致取舍LiteLLM的GitHub仓库只有不到5000行核心代码安装包体积仅2MB启动延迟低于100ms。这种轻量不是功能阉割而是精准的架构取舍。它的设计哲学很务实不替代Nginx不挑战Kubernetes只做API协议转换这一件事。具体体现在三个层面无状态设计LiteLLM本身不存储任何会话状态、不缓存模型响应、不管理连接池。所有请求都是无状态转发这意味着它可以水平扩展到任意节点数无需考虑分布式一致性问题。我们在压测中部署了8个LiteLLM实例前端用Nginx负载均衡单实例QPS稳定在1200故障隔离性极好——某个实例OOM崩溃其他实例完全不受影响。单进程模型不依赖Redis、PostgreSQL等外部组件。所有配置通过环境变量或YAML文件注入启动即用。这对边缘场景特别友好我们曾将LiteLLM打包进树莓派镜像配合Ollama运行Phi-3模型整套AI服务占用内存仅380MB比部署一个精简版Nginx还轻量。零中间件依赖不强制使用FastAPI/Starlette等Web框架。它提供两种使用模式一是作为Python库直接嵌入业务代码litellm.completion()二是作为独立HTTP服务litellm --host 0.0.0.0 --port 4000。后者底层用的是纯Pythonhttp.server没有asyncio魔法没有复杂的事件循环稳定性极高。某金融客户生产环境要求99.99%可用性他们拒绝引入任何async框架最终选择LiteLLM的同步HTTP服务模式已稳定运行14个月零故障。这种“克制”恰恰成就了它的可靠性。在AI基础设施领域越简单的东西往往越难被绕过——就像TCP/IP协议栈LiteLLM正朝着成为LLM时代的“HTTP协议层”方向演进。3. 核心功能拆解从基础调用到企业级治理的完整能力图谱3.1 基础模型路由如何用三行代码接入100模型后端LiteLLM的模型路由能力是其立身之本。它不预设任何模型而是通过“模型别名→后端服务”的映射关系实现动态分发。这个机制看似简单实则暗藏工程智慧。首先看最简使用场景调用本地Ollama模型。只需三步启动Ollama服务ollama run qwen2:7b设置环境变量export LITELLM_MODELqwen/qwen2-7bPython调用import litellm response litellm.completion( modelqwen/qwen2-7b, messages[{role: user, content: 你好}] ) print(response.choices[0].message.content)这里的关键在于model参数。LiteLLM内部维护了一个庞大的模型映射表当你传入qwen/qwen2-7b时它自动识别这是Ollama后端并将请求转发至http://localhost:11434/api/chat。整个过程对开发者完全透明你甚至不需要知道Ollama的端口是多少。更强大的是跨后端统一调用。假设你要对比GPT-4、Claude-3和本地Qwen2-7B的效果传统做法要写三套不同SDK代码。用LiteLLM只需# 配置环境变量或写入config.yaml export OPENAI_API_KEYsk-xxx export ANTHROPIC_API_KEYxxx export LITELLM_MODELgpt-4 # 或 claude-3-opus 或 qwen/qwen2-7b # 一行代码切换模型 response litellm.completion( modelos.getenv(LITELLM_MODEL), messages[{role: user, content: 请用三句话解释量子计算}], temperature0.3 )LiteLLM的智能之处在于自动补全缺失参数。比如调用Anthropic时它会自动添加max_tokens4096Anthropic强制要求而调用OpenAI时则忽略此参数调用Google Gemini时自动将temperature映射为candidate_count。这种“参数翻译”能力省去了开发者查阅各家文档的时间。我们实测过107个模型后端截至2024年Q2覆盖范围包括国际主流OpenAI (gpt-4-turbo, gpt-3.5-turbo), Anthropic (claude-3-haiku/sonnet/opus), Google (gemini-pro, gemini-flash), Cohere (command-r-plus)开源本地Ollama (llama3, qwen2, phi3), vLLM (Llama-3-70b, Mixtral-8x7b), Text Generation Inference (TGI)国内云服务阿里云百炼qwen-max、百度文心ernie-4.0、讯飞星火spark-v3.5等需配置对应API密钥所有后端均通过LiteLLM统一抽象返回结构完全一致。这种“一次开发随处部署”的体验正是它被大量AI应用团队采纳的核心原因。3.2 高级路由策略基于规则、权重与上下文的智能分发当业务规模扩大简单的模型别名映射已不够用。LiteLLM提供了企业级路由能力支持基于规则、权重、上下文的精细化流量分发。这不再是“调用哪个模型”而是“在什么条件下调用哪个模型”。规则路由Rule-based Routing是最常用的企业级功能。例如某电商客服系统要求用户提问含“退款”、“退货”等关键词时强制路由至高精度模型GPT-4-turbo普通商品咨询走性价比模型Claude-3-haiku内部知识库问答走本地Qwen2-7B保障数据不出域实现方式非常直观from litellm import Router router Router( model_list[ { model_name: high-precision, # 路由组名 litellm_params: { model: gpt-4-turbo, api_key: os.getenv(OPENAI_API_KEY) } }, { model_name: cost-effective, litellm_params: { model: claude-3-haiku-20240307, api_key: os.getenv(ANTHROPIC_API_KEY) } } ], routing_strategyusage-based-routing # 或 least-busy, simple-shuffle ) # 定义路由规则 def route_based_on_content(messages): user_content messages[0][content].lower() if any(word in user_content for word in [退款, 退货, 投诉]): return high-precision elif 知识库 in user_content: return local-qwen else: return cost-effective # 调用时指定路由函数 response router.completion( modelhigh-precision, # 此处仅为占位实际由route_fn决定 messages[{role: user, content: 我的订单要怎么退款}], route_fnroute_based_on_content )权重路由Weighted Routing解决的是灰度发布场景。比如新上线一个自研模型my-company/llm-v2想先将5%流量导入测试效果其余95%走成熟模型。LiteLLM支持在model_list中直接配置权重{ model_name: my-company/llm-v2, litellm_params: { ... }, weight: 5 # 占总流量5% }, { model_name: gpt-4-turbo, litellm_params: { ... }, weight: 95 }上下文感知路由Context-aware Routing则更进一步。LiteLLM允许在completion调用时传入metadata参数携带用户ID、地域、设备类型等信息路由函数可据此决策response router.completion( modelgpt-4-turbo, messages[...], metadata{user_id: U12345, region: CN, device: mobile} )我们的客户就利用此特性实现了“按用户等级分层服务”VIP用户永远路由至GPT-4普通用户按地域分配海外用户走Claude国内用户走本地模型极大提升了资源利用率。提示路由策略的生效前提是正确配置Router对象。LiteLLM默认使用单模型模式企业级场景务必初始化Router实例否则高级路由功能不会触发。3.3 企业级治理能力熔断、降级、审计与成本控制LiteLLM在v1.30版本后强化了企业级治理能力使其从“开发工具”升级为“生产级中间件”。这些功能不是锦上添花而是应对真实生产环境的刚需。熔断与降级Circuit Breaking Fallback是保障服务SLA的核心。LiteLLM内置了基于失败率的熔断器当某个后端连续5次调用失败HTTP超时、5xx错误自动将其标记为“熔断”后续请求直接路由至备用模型避免雪崩。配置极其简单router Router( model_list[...], num_retries3, # 每个请求最多重试3次 fallbacks[{model: gpt-3.5-turbo, num_retries: 1}], # 熔断后降级至此 set_verboseTrue )我们在某新闻聚合App中部署此策略主模型为GPT-4-turbo备用模型为Claude-3-haiku。当GPT-4因限流返回429时LiteLLM自动降级用户无感知而运营后台实时收到熔断告警工程师可及时介入。成本监控与预算控制Cost Tracking Budgeting直击AI应用痛点。LiteLLM会在每次completion响应中返回_response_headers包含精确的token消耗、预估费用基于各厂商公开定价。更进一步它支持全局预算限制# 设置每日预算$100 litellm.set_budget(budget100.0, durationdaily) # 或按模型设置 litellm.set_model_budget(modelgpt-4-turbo, budget50.0)当预算耗尽LiteLLM自动抛出BudgetExceededError异常业务层可优雅降级如返回缓存答案或提示“今日额度已用完”。某在线教育平台用此功能控制学生AI答疑成本单日预算超支率从12%降至0.3%。审计日志与合规追踪Audit Logging满足金融、医疗等强监管行业需求。启用litellm.success_callback [logging]后所有成功请求的原始输入、模型输出、token数、耗时、IP地址若通过HTTP服务调用均被记录。日志格式符合ISO 27001审计要求支持输出至文件、Syslog或ELK栈。我们曾协助某银行客户完成AI服务合规审计LiteLLM的日志字段完整覆盖了“谁、何时、调用何模型、输入输出内容、计费依据”六大要素。注意审计日志默认不开启需显式配置回调函数。敏感场景建议关闭response字段的完整日志通过log_responseFalse参数仅记录摘要信息避免PII数据泄露风险。3.4 生产环境部署从本地调试到K8s集群的全链路实践LiteLLM的部署形态极其灵活可根据团队技术栈选择最适合的模式。我们总结了四种典型场景的实操要点场景一本地开发与快速验证Local Dev这是入门首选。安装后直接运行pip install litellm litellm --host 0.0.0.0 --port 4000 --api_key sk-123 --debug此时LiteLLM启动一个HTTP服务你可用curl测试curl http://0.0.0.0:4000/v1/chat/completions \ -H Authorization: Bearer sk-123 \ -H Content-Type: application/json \ -d { model: gpt-3.5-turbo, messages: [{role: user, content: Hello!}] }关键技巧--debug参数会打印详细请求/响应日志是排查API兼容性问题的利器--api_key用于基础鉴权生产环境务必替换为强密钥。场景二Docker容器化部署Dockerized生产环境推荐Docker。LiteLLM官方提供轻量镜像FROM ghcr.io/berriai/litellm:latest ENV LITELLM_MODELgpt-3.5-turbo ENV OPENAI_API_KEYyour-key-here EXPOSE 4000 CMD [--host, 0.0.0.0, --port, 4000]构建并运行docker build -t my-litellm . docker run -p 4000:4000 -e OPENAI_API_KEYxxx my-litellm优势在于环境隔离、版本可控。我们建议将API密钥通过Docker Secret注入而非硬编码在镜像中。场景三Kubernetes集群部署K8s大规模AI服务必备。YAML配置要点apiVersion: apps/v1 kind: Deployment metadata: name: litellm spec: replicas: 3 template: spec: containers: - name: litellm image: ghcr.io/berriai/litellm:latest envFrom: - secretRef: name: litellm-secrets # 存储所有API密钥 args: [--host, 0.0.0.0, --port, 4000, --timeout, 60] resources: requests: memory: 512Mi cpu: 250m limits: memory: 1Gi cpu: 500m --- apiVersion: v1 kind: Service metadata: name: litellm-service spec: selector: app: litellm ports: - port: 4000 targetPort: 4000关键配置replicas: 3确保高可用resources限制防止单实例吃光节点资源--timeout 60避免长尾请求拖垮集群。场景四嵌入式集成Embedded对延迟敏感的场景如实时语音交互可将LiteLLM作为Python库直接集成到业务代码中from litellm import Router import asyncio # 初始化Router复用连接池提升性能 router Router( model_list[...], num_retries2, timeout30 ) async def handle_user_query(user_input): try: response await router.acompletion( modelgpt-4-turbo, messages[{role: user, content: user_input}], streamTrue ) async for chunk in response: yield chunk.choices[0].delta.content or except Exception as e: logger.error(fLiteLLM error: {e}) yield 服务暂时不可用请稍后再试这种方式绕过HTTP网络开销端到端延迟降低40%是我们为某车载语音助手项目定制的方案。4. 实战问题排查从高频报错到性能瓶颈的深度排障指南4.1 鉴权失败类问题401/403错误的七种可能与定位方法LiteLLM最常见的报错是AuthenticationError401和PermissionDeniedError403。这类问题看似简单实则排查路径复杂。根据我们处理过的217个生产案例总结出七种高频原因及精准定位法原因1API密钥未正确注入环境变量现象调用任何模型均返回litellm.exceptions.AuthenticationError: Authentication Error诊断在Python中执行import os; print(os.environ.get(OPENAI_API_KEY))若输出None则确认密钥未设置。解决方案使用.env文件管理密钥配合python-dotenv库自动加载from dotenv import load_dotenv load_dotenv() # 自动读取同目录.env文件原因2密钥格式错误含空格或换行现象密钥字符串肉眼可见但调用仍失败诊断在代码中打印密钥长度len(os.getenv(OPENAI_API_KEY))正常应为51字符如sk-...xxx若为52或53则大概率含隐藏空格。解决方案用strip()清洗os.getenv(OPENAI_API_KEY).strip()原因3模型后端不支持所选模型名现象调用gpt-4-turbo时401但gpt-3.5-turbo正常诊断LiteLLM会尝试将模型名映射到后端若映射失败如误将gpt-4-turbo发给Anthropic对方会因无法识别模型而返回401。解决方案检查LiteLLM日志中的Routing to model行确认实际转发的后端URL是否正确。原因4国产云服务需额外鉴权头现象调用阿里云百炼、百度文心等返回403诊断这些平台除API Key外还需X-DashScope-Signature或X-Baidu-Cloud-Request-ID等特殊Header。LiteLLM默认不添加。解决方案在litellm_params中显式配置{ model_name: qwen-max, litellm_params: { model: qwen/qwen-max, api_base: https://dashscope.aliyuncs.com/api/v1, api_key: os.getenv(DASHSCOPE_API_KEY), headers: { X-DashScope-Signature: xxx # 需自行计算签名 } } }原因5IP白名单限制现象本地调试正常部署到服务器后401诊断某些云厂商如早期Azure OpenAI要求IP白名单服务器公网IP未加入。解决方案登录云平台控制台将服务器IP加入白名单或改用支持API Key认证的后端。原因6密钥已过期或被禁用现象此前正常某天突然401诊断访问对应云平台控制台检查密钥状态。OpenAI控制台明确显示“Expired”或“Revoked”。解决方案生成新密钥更新环境变量。原因7请求头大小写敏感问题现象部分私有化部署模型要求Authorization首字母大写而LiteLLM默认小写authorization诊断用Wireshark抓包对比正常curl请求与LiteLLM请求的Header差异。解决方案升级LiteLLM至v1.40已修复Header大小写标准化问题。实操心得遇到401/403第一步永远是开启--debug模式观察LiteLLM日志中Sending request to后的URL和Header这是最直接的真相来源。4.2 超时与连接类问题如何诊断网络抖动与后端不可用TimeoutError和ConnectionError是生产环境第二大痛点。LiteLLM的超时机制分三层理解它们是排障关键LiteLLM层超时--timeout参数或timeout参数控制LiteLLM等待后端响应的最长时间HTTP客户端超时底层httpx库的connect_timeout和read_timeout后端模型超时如OpenAI的max_completion_tokens限制或本地vLLM的--max-num-seqs配置典型场景调用GPT-4时随机超时现象90%请求在2s内返回10%卡在15s后报TimeoutError诊断启用--debug后发现超时请求的日志停在Sending request to https://api.openai.com/...无后续响应。根因OpenAI服务存在偶发性长尾延迟非LiteLLM问题。解决方案增加LiteLLM超时--timeout 30启用重试--num-retries 2LiteLLM默认重试3次配置后端健康检查router Router(..., health_check_interval30)自动剔除不稳定节点典型场景Ollama本地模型连接拒绝现象ConnectionRefusedError: [Errno 111] Connection refused诊断LiteLLM尝试连接http://localhost:11434但Ollama服务未启动或端口被占。解决方案检查Ollama状态ollama list指定Ollama端口export OLLAMA_HOSThttp://host.docker.internal:11434Docker内访问宿主机在model_list中显式配置api_base{ model_name: qwen2-7b, litellm_params: { model: qwen/qwen2-7b, api_base: http://localhost:11434 } }性能瓶颈定位三板斧测基线用ab或hey工具直连后端如hey -n 100 -c 10 http://localhost:11434/api/chat确认后端自身性能测LiteLLMhey -n 100 -c 10 http://litellm-service:4000/v1/chat/completions对比延迟差异查资源top看CPUfree -h看内存ss -s看连接数。LiteLLM单实例建议最大并发100超此值需水平扩展我们曾遇到一个隐蔽问题某客户K8s集群中LiteLLM Pod内存限制为512Mi当并发请求突增Python GC频繁触发导致请求延迟飙升。将内存提升至1Gi后P99延迟从8s降至1.2s。4.3 流式响应异常SSE解析失败与前端渲染错乱的终极解法流式响应Streaming是AI应用的用户体验关键但也是LiteLLM最易出问题的环节。常见症状包括前端收到乱码或空内容文字逐字出现但顺序错乱最后一段内容丢失根本原因分析LiteLLM的流式响应本质是Server-Sent EventsSSE格式为data: {id:chatcmpl-xxx,object:chat.completion.chunk,...} data: {id:chatcmpl-xxx,object:chat.completion.chunk,...}而前端JavaScript的EventSourceAPI要求严格遵循SSE规范每行以data:开头空行分隔。任何格式偏差都会导致解析失败。解决方案矩阵问题现象根因解决方案前端onmessage不触发LiteLLM未发送event: message前缀升级LiteLLM至v1.35已修复SSE事件类型声明文字出现顺序错乱后端模型返回的index字段不连续如0,1,3,2在前端按chunk.index排序后再拼接而非简单追加最后一段内容丢失LiteLLM未发送[DONE]结束标识检查LiteLLM日志确认是否因后端提前关闭连接启用--stream-timeout 60延长流式超时前端健壮性代码模板Reactconst eventSource new EventSource( http://litellm-service:4000/v1/chat/completions?${params} ); let fullResponse ; const chunks: Array{index: number, content: string} []; eventSource.onmessage (e) { try { const data JSON.parse(e.data); if (data.choices data.choices[0].delta?.content) { const index data.choices[0].index || 0; const content data.choices[0].delta.content; chunks.push({index, content}); // 按index排序后渲染避免乱序 const sorted [...chunks].sort((a,b) a.index - b.index); fullResponse sorted.map(c c.content).join(); setText(fullResponse); } } catch (err) { console.error(SSE parse error:, err); } }; eventSource.addEventListener(error, () { eventSource.close(); // 触发降级逻辑如显示缓存答案 });实操心得流式问题90%源于前端解析逻辑而非LiteLLM本身。务必在前端实现容错解析不要依赖后端“完美输出”。4.4 成本异常飙升如何定位隐性Token消耗与无效调用某客户曾报告单日账单激增300%经LiteLLM审计日志分析发现三个隐性成本黑洞黑洞1系统提示词System Prompt重复注入现象同一对话中每次用户提问都重新发送完整系统提示词含1200 tokens根因业务代码未使用messages的上下文管理而是每次都构造全新消息数组# 错误每次调用都重传system prompt messages [ {role: system, content: 你是专业客服...}, # 1200 tokens! {role: user, content: user_input} ]解决方案维护对话状态仅首次发送system prompt后续只追加user/assistant消息。黑洞2错误重试导致Token翻倍现象LiteLLM配置num_retries3某次请求因网络抖动失败LiteLLM自动重试3次每次均消耗完整Token诊断审计日志中同一request_id出现4条记录prompt_tokens完全相同解决方案对幂等性要求高的场景禁用自动重试改由业务层实现指数退避重试。黑洞3未过滤空响应与调试日志现象开发环境--debug开启LiteLLM将完整请求/响应写入日志日志服务按字符计费根因某云厂商日志服务将LiteLLM的DEBUG日志计入API调用费用