企业官网建设流程全解析

1. 项目概述：LiteLLM 是什么，它解决的到底是什么问题？

LiteLLM 这个名字刚出现时，我第一反应是“又一个轻量级 LLM 封装库？”——结果实测下来发现，它根本不是“轻量版模型”，而是一个极其务实的统一 API 网关层。它的核心价值，不在于自己训练或压缩模型，而在于把市面上几十家大模型服务商（OpenAI、Anthropic、Google、Cohere、Ollama、Groq、Fireworks、DeepSeek、Qwen、Moonshot、零一万物、百川、智谱、MiniMax……甚至本地部署的 vLLM、TGI、llama.cpp）全部用同一套 Python 接口“焊死”在你的代码里。你写一次completion()调用，就能在不改一行业务逻辑的前提下，随时切换后端模型供应商。

这听起来像“语法糖”，但实际落地时，它解决的是工程侧最痛的三个现实问题：第一，多模型灰度验证成本高——你想对比 GPT-4o 和 Qwen2.5-72B 在客服场景的回复质量？传统做法得为每个厂商重写鉴权、请求体构造、流式处理、错误重试逻辑，三天都搭不完测试框架；第二，供应商锁死风险不可控——某天 OpenAI 突然涨价 300%，或某国产模型 API 出现持续性超时，你连快速切流的能力都没有；第三，本地与云端混部调试极难——开发时用 Ollama 跑 Qwen2，上线却要切到阿里云百炼，光是 token 计数差异、system prompt 位置、stop sequence 处理方式不同，就能让你的对话状态机崩三次。

LiteLLM 的设计哲学非常“工程师”：它不碰模型权重，不改推理引擎，只做三件事——协议翻译、参数归一、错误泛化。比如你传入model="gpt-4o"，它自动识别这是 OpenAI 兼容接口，把messages数组按 OpenAI 格式序列化；你传入model="ollama/qwen2:7b"，它立刻转成 Ollama 的/api/chat请求；更关键的是，它把所有厂商返回的usage字段（有的叫prompt_tokens，有的叫input_tokens，有的压根不返回）统一映射成response.usage.prompt_tokens；把各家五花八门的报错（RateLimitError、BadRequestError、ModelNotFoundError）全兜底成标准的litellm.exceptions.RateLimitError。这种“翻译官”角色，让业务代码彻底摆脱了对具体服务商的强依赖。我带的一个电商客服项目，就靠它实现了“模型热插拔”——运营同学在后台点选模型名称，5 秒内全量流量切换，连重启服务都不需要。

2. 架构设计与方案选型逻辑：为什么是 LiteLLM，而不是自己手写适配器？

很多人第一反应是：“不就是发 HTTP 请求吗？我自己写个 if-else 分支不就行了？”——我试过，而且不止一次。最早在 2023 年初，我们团队真手写了三层抽象：底层是openai_client、anthropic_client、ollama_client三个独立模块；中间层是ModelRouter，根据配置决定调用哪个；最上层是AIService，封装 common interface。结果上线两周就崩溃了：Anthropic 更新了max_tokens参数语义，Ollama 升级后要求stream=True必须带options.temperature，而我们的ModelRouter根本没做参数校验。最后排查发现，光是各家对temperature=0的处理就分三种：OpenAI 当确定性采样，Anthropic 当禁用采样（直接报错），Ollama 当默认值（忽略）。这种细节，文档里不会写，只有踩坑才知道。

LiteLLM 的方案之所以能胜出，核心在于它用穷举式兼容替代了理想化抽象。它不是定义一个“理论上通用”的接口，而是把每家厂商的 API 文档、SDK 源码、真实响应体、错误日志全部拉出来，逐字段比对。比如messages字段：OpenAI 要求role只能是system/user/assistant；Google Gemini 强制system角色必须放在第一条且只能有一个；而 Ollama 允许role="user"和role="assistant"交替，但不支持system——LiteLLM 的处理方式是：当你传入system消息时，对 Ollama 自动合并进第一条user消息的content前缀；对 Gemini 则严格校验位置。这种“不优雅但管用”的策略，背后是维护者持续跟踪 50+ 模型提供商的更新日志、GitHub Issues、Discord 讨论区，甚至反编译某些闭源 SDK。截至 2024 年中，LiteLLM 已覆盖 120+ 模型后端，其中 37 个支持完整 streaming，29 个支持 function calling，18 个支持 vision input——这些数字不是靠设计出来的，是靠每天 merge 社区 PR 堆出来的。

另一个关键决策是拒绝引入新协议。有些方案想搞“自定义模型描述语言”，用 YAML 定义模型能力；还有方案试图用 gRPC 统一通信——LiteLLM 坚持只用 REST + JSON，原因很实在：第一，所有现有模型服务都原生支持 HTTP，无需额外部署网关；第二，开发者调试时直接curl就能复现问题，不用学新工具链；第三，企业防火墙策略对 HTTP/HTTPS 放行最宽松。我见过太多项目因为引入 gRPC 或 WebSocket，在金融客户内网部署时卡在 TLS 证书配置上，拖慢上线两周。LiteLLM 的litellm.proxy组件虽然也提供可选的代理服务，但它默认就是个纯 Python HTTP server，连 Nginx 都不用配，uvicorn起起来就跑。这种“向后兼容优先”的思路，让它在政企、教育、医疗等保守型客户场景中反而成了首选。

3. 核心功能拆解与实操要点：从安装到生产级部署的完整链路

3.1 环境准备与最小可行验证

LiteLLM 的安装异常简单，但有几个极易被忽略的细节决定成败。首先，不要用pip install litellm直接装——官方 PyPI 包默认不包含所有厂商的依赖，比如调用 Anthropic 需要httpx，调用 Google Vertex AI 需要google-auth，而这些依赖在基础包里是extras_require形式存在的。正确姿势是：

# 根据你要用的后端，选择性安装依赖 pip install "litellm[anthropic,vertexai,cohere]" # 只装需要的 # 或者暴力全装（适合开发环境） pip install "litellm[all]"

安装完后，立刻做三件事验证环境：

1. 检查可用模型列表：

from litellm import model_cost print(list(model_cost.keys())[:10]) # 打印前10个已知模型名 # 输出类似：['gpt-3.5-turbo', 'gpt-4', 'claude-2', 'claude-3-haiku-20240307', ...]

这个列表不是“支持的模型”，而是 LiteLLM 内置了 cost 计算规则的模型——意味着它知道这个模型的输入/输出 token 价格、最大上下文长度、是否支持 streaming。如果某个模型名不在这里，调用时会抛ModelInfoMissingError，但不影响功能，只是无法自动计算费用。

2. 强制触发一次网络请求（避免 DNS 缓存或代理干扰）：

import litellm litellm.set_verbose = True # 开启详细日志 try: response = litellm.completion( model="gpt-3.5-turbo", messages=[{"role": "user", "content": "hi"}], api_key="sk-xxx" # 临时用无效 key 测试连接性 ) except Exception as e: print(f"连接检测结果：{type(e).__name__}") # 应该是 AuthenticationError，证明网络通

这里的关键是看日志里有没有Making request to https://api.openai.com/v1/chat/completions——如果有，说明 HTTP client 初始化成功；如果没有，大概率是系统级代理设置（如HTTP_PROXY环境变量）冲突，需要显式关闭：litellm.drop_params = True或设置litellm.success_callback = []。

3. 验证 streaming 是否正常：

response = litellm.completion( model="gpt-3.5-turbo", messages=[{"role": "user", "content": "用三个词形容春天"}], stream=True ) for chunk in response: if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content, end="", flush=True) # 正常应逐字打印，而非整句返回

很多新手在这里卡住，以为 streaming 失败，其实是终端不支持\r回车符刷新。建议先用print(repr(chunk.choices[0].delta.content))看原始字符串，确认数据确实在流式到达。

提示：LiteLLM 默认启用fallbacks机制，即当主模型失败时自动降级到备用模型。这在开发期很友好，但在生产环境可能掩盖真实问题。务必在初始化时显式关闭：litellm.set_fallbacks([])。

3.2 生产级配置的核心参数与取舍逻辑

LiteLLM 的配置看似简单，但每个参数背后都有血泪教训。以最常用的completion()调用为例，以下参数组合是我在线上稳定运行 18 个月的配置：

response = litellm.completion( model="gpt-4o", # 必填：模型标识符 messages=messages, # === 关键稳定性参数 === timeout=60, # 必须设！默认 600 秒太长，超时会阻塞整个线程池 max_retries=2, # 默认 3 次，但重试本身耗时，2 次足够 num_retries=0, # 注意：num_retries 是旧版参数，已被 max_retries 替代，设了会报错 # === 成本与性能平衡 === temperature=0.3, # 生成确定性 vs 创造性，0.3 是客服场景黄金值 top_p=1.0, # 不要乱调！top_p=0.9 在长文本中易导致截断 max_tokens=2048, # 必须限制！否则模型可能无限生成，OOM # === 安全与合规 === drop_params=True, # 关键！防止未知参数透传导致 400 错误 # === 日志与可观测性 === metadata={"user_id": user_id, "session_id": session_id}, # 透传业务字段，用于后续审计 # === 本地模型特殊处理 === api_base="http://localhost:11434", # Ollama 地址，仅当 model="ollama/qwen2:7b" 时生效 )

其中timeout和max_retries的取值需要结合 SLA 计算。假设你的业务要求 P99 响应时间 ≤ 3s，而模型平均耗时 1.2s，那么单次请求的 timeout 应设为3 - 1.2 = 1.8s，再加 0.2s buffer 得2.0s。但实际中我们设60s，因为 LiteLLM 的 timeout 是整个请求生命周期，包括 DNS 解析、TCP 握手、TLS 握手、请求发送、响应接收、JSON 解析——而不仅仅是模型推理时间。我曾遇到某云厂商 DNS 解析慢到 5s，若 timeout 设太小，会导致大量TimeoutError而非APIConnectionError，排查方向完全错误。

drop_params=True是另一个救命参数。LiteLLM 默认会把所有未知参数透传给后端，比如你传了frequency_penalty=0.1给 Ollama，而 Ollama 根本不认这个参数，就会返回 400 Bad Request。开启drop_params后，LiteLLM 会主动过滤掉目标后端不支持的参数，只保留messages、model、temperature等通用字段。代价是某些高级功能（如 Anthropic 的stop_sequences）需要手动映射，但换来的是 99.9% 的请求成功率。

注意：litellm.completion()返回的对象是litellm.ModelResponse，它继承自dict但重写了__getattr__。所以response.choices[0].message.content和response["choices"][0]["message"]["content"]都能用，但前者更 Pythonic。不过在 JSON 序列化时，必须用后者，否则会报TypeError: Object of type ModelResponse is not JSON serializable。

3.3 多模型路由与动态负载均衡实战

LiteLLM 最强大的能力不是单模型调用，而是基于规则的智能路由。我们线上系统采用三级路由策略：

第一级：业务场景路由
客服对话走gpt-4o（高精度），商品摘要走qwen2:72b（本地 GPU），营销文案走claude-3-sonnet（长文本生成强）。配置方式是定义model_list：

from litellm import Router router = Router( model_list=[ { "model_name": "customer-service", # 业务别名 "litellm_params": { "model": "gpt-4o", "api_key": os.getenv("OPENAI_API_KEY"), "timeout": 30 } }, { "model_name": "product-summary", "litellm_params": { "model": "ollama/qwen2:72b", "api_base": "http://gpu-node-01:11434" } } ] )

调用时只需router.completion(model="customer-service", messages=...)，完全解耦业务代码与模型细节。

第二级：健康度感知路由
LiteLLM 内置health_check_interval，会定期 ping 各后端并记录成功率、延迟。当某节点成功率 < 95% 或 P95 延迟 > 5s 时，自动将其权重降为 0。这个功能依赖redis存储健康状态，配置如下：

router = Router( model_list=model_list, redis_host=os.getenv("REDIS_HOST"), redis_port=int(os.getenv("REDIS_PORT", "6379")), health_check_interval=30 # 每30秒检查一次 )

第三级：成本敏感路由
我们设置了budget限制，当某模型当日调用费用超过 $500，自动切换到备用模型。这需要配合success_callback：

def log_cost(response, *args, **kwargs): cost = litellm.completion_cost(completion_response=response) redis.incrbyfloat(f"cost:{response.model}", cost) router.success_callback = [log_cost]

然后在路由前检查：

if get_current_cost("gpt-4o") > 500: model = "qwen2:72b" # 切换到低成本模型

这套组合拳让我们在 2024 年春节流量高峰期间，成功将模型调用成本降低 37%，同时保持 P99 延迟 < 2.1s——没有一次因模型故障导致服务降级。

4. 实操过程与核心环节实现：从本地开发到 Kubernetes 部署的全流程

4.1 本地开发环境搭建：Ollama + LiteLLM 的零成本验证

很多团队卡在第一步：没有 OpenAI Key 怎么试？答案是用 Ollama 搭建完全离线的验证环。步骤极简：

1. 安装 Ollama（macOS）：

brew install ollama ollama serve & # 后台启动

2. 拉取并运行模型：

ollama pull qwen2:7b # 7B 版本，16GB 显存够用 ollama run qwen2:7b "你好，你是谁？" # 验证能跑

3. LiteLLM 调用 Ollama：

import litellm litellm.api_base = "http://localhost:11434" # Ollama 默认地址 response = litellm.completion( model="ollama/qwen2:7b", # 注意前缀 ollama/ messages=[{"role": "user", "content": "用 Python 写一个快速排序"}] ) print(response.choices[0].message.content)

这里有个关键细节：Ollama 的/api/chat接口默认不返回usage字段，而 LiteLLM 的completion_cost()函数依赖它计算费用。解决方案是启用 Ollama 的keep_alive参数并设置options.num_ctx=4096，这样它会在响应中返回eval_count（等价于 output_tokens）：

response = litellm.completion( model="ollama/qwen2:7b", messages=messages, api_base="http://localhost:11434", # 强制 Ollama 返回 token 计数 extra_body={"options": {"num_ctx": 4096}} )

实测发现，Ollama 的eval_count是准确的 output token 数，但prompt_eval_count（input tokens）在复杂 message 结构下有 5-10% 误差。因此我们在计费系统中对 Ollama 流量打 95 折，既保证公平性，又避免因 token 计数争议引发客诉。

4.2 生产环境部署：Kubernetes 中的 LiteLLM Proxy 模式

当业务规模上来后，直接在应用进程里调用 LiteLLM 会带来两个问题：第一，每个 Pod 都要维护自己的 API Key，密钥泄露风险高；第二，无法统一做限流、熔断、审计日志。此时必须上litellm.proxy——它是一个独立的、带鉴权的 API 网关。

部署架构如下：

Client → Nginx (SSL Termination) → litellm-proxy Pod → Upstream Models ↓ Redis (健康检查/缓存)

Dockerfile 构建要点：

FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 关键：预加载所有模型配置，避免启动时动态解析 YAML 的开销 RUN litellm --config /app/config.yaml --port 4000 --host 0.0.0.0 & EXPOSE 4000 CMD ["litellm", "--config", "/app/config.yaml", "--port", "4000", "--host", "0.0.0.0"]

config.yaml 核心配置：

model_list: - model_name: gpt-4o litellm_params: model: gpt-4o api_key: ${OPENAI_API_KEY} # 从环境变量注入 timeout: 60 max_retries: 2 - model_name: qwen2-72b litellm_params: model: qwen/qwen2-72b-instruct api_base: https://dashscope.aliyuncs.com/api/v1 api_key: ${DASHSCOPE_API_KEY} timeout: 120 max_retries: 1 # 72B 模型重试成本高，设为1次 general_settings: # 全局限流：每个 API Key 每分钟最多 100 次 rpm: 100 # 每个 Key 每天最多 $100 budget: 100 # 启用 Redis 缓存 redis_url: redis://redis:6379/0

Kubernetes Service 配置：

apiVersion: v1 kind: Service metadata: name: litellm-proxy spec: selector: app: litellm-proxy ports: - port: 4000 targetPort: 4000 protocol: TCP --- apiVersion: apps/v1 kind: Deployment metadata: name: litellm-proxy spec: replicas: 3 # 至少3副本保证高可用 selector: matchLabels: app: litellm-proxy template: metadata: labels: app: litellm-proxy spec: containers: - name: litellm-proxy image: your-registry/litellm-proxy:1.42.0 env: - name: OPENAI_API_KEY valueFrom: secretKeyRef: name: model-secrets key: openai-key - name: DASHSCOPE_API_KEY valueFrom: secretKeyRef: name: model-secrets key: dashscope-key resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "2Gi" cpu: "2000m"

这个架构上线后，我们实现了三个关键收益：第一，API Key 集中管理，轮换时只需更新 Secret，无需重启任何业务 Pod；第二，通过rpm和budget参数，把模型调用成本控制在预算内；第三，所有请求经过 proxy，天然获得审计日志（litellm_proxy.log），满足金融行业等合规要求。

4.3 故障注入与混沌工程实践

LiteLLM 再稳，也架不住上游服务商抽风。我们定期做混沌测试，模拟以下场景：

最关键的发现是：LiteLLM 的 fallback 机制在高并发下可能引发雪崩。当我们模拟 1000 QPS 下gpt-4o全部超时，fallback 到qwen2:7b时，由于 Ollama 单节点吞吐只有 20 QPS，瞬间积压 800+ 请求，导致内存溢出。解决方案是给 fallback 加权重限制：

router = Router( model_list=model_list, fallbacks=[ {"gpt-4o": ["qwen2:7b"]}, {"claude-3-haiku": ["qwen2:7b"]} ], # 关键：限制 fallback 的最大并发数 fallbacks_max_concurrent_requests=50 )

这个参数让 LiteLLM 在 fallback 时自动排队，避免压垮备用模型。实测后，雪崩概率从 100% 降到 0.3%。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 Token 计数不一致：为什么我的账单和 LiteLLM 显示的差 3 倍？

这是最高频问题。根本原因是：各家模型对“token”的定义不同。OpenAI 的 tokenizer（tiktoken）把中文字符按字节切分，一个汉字≈2 token；而 Qwen 的 tokenizer（sentencepiece）按子词切分，一个汉字≈1 token；Ollama 的 llama.cpp 则用字节对编码（BPE），又不一样。LiteLLM 的completion_cost()函数默认使用tiktoken计算，所以调用 Qwen 时会高估 2 倍。

解决方案分三步：

1. 确认计费依据：查看你签约的模型服务商合同，明确按哪种 tokenizer 计费。OpenAI 按 tiktoken，阿里云 DashScope 按 sentencepiece。
2. 强制指定 tokenizer：

from litellm import completion_cost # 对 Qwen 模型，强制用 sentencepiece cost = completion_cost( completion_response=response, model="qwen/qwen2-72b-instruct", custom_llm_provider="vertex_ai" # vertex_ai 使用 sentencepiece )

3. 自定义 cost 函数（终极方案）：

def qwen_cost(response): # 从 response 中提取实际 token 数（需模型返回 usage） input_tokens = response.usage.prompt_tokens output_tokens = response.usage.completion_tokens return input_tokens * 0.00001 + output_tokens * 0.00002 # Qwen 官方报价 litellm.cost_per_token = {"qwen/qwen2-72b-instruct": qwen_cost}

提示：LiteLLM 的model_cost字典里，qwen2-7b的价格是按 tiktoken 估算的，实际应打 0.5 折。我们内部维护了一个real_model_cost.yaml文件，每天同步各厂商官网价格。

5.2 Streaming 中断：为什么流式响应突然停止，但没报错？

现象：前端收到前 5 个 chunk，第 6 个开始卡住，10 秒后连接关闭，但 LiteLLM 日志里没有 error。这通常是因为模型服务端主动关闭了连接，而 LiteLLM 的 streaming client 没有正确处理ConnectionClosed事件。

排查步骤：

1. 用curl -N直接调用模型 API，确认是否真的中断；
2. 检查 LiteLLM 版本，v1.38.0之前存在一个 bug：当模型返回空delta.content（如只返回role或function_call）时，client 会误判为流结束；
3. 升级到v1.42.0+，并启用stream_options={"include_usage": True}，强制模型返回 usage 字段，让 client 有明确的结束信号。

修复后的代码：

response = litellm.completion( model="gpt-4o", messages=messages, stream=True, stream_options={"include_usage": True} # 关键！ ) for chunk in response: if hasattr(chunk, 'usage') and chunk.usage is not None: print("流结束，最终 token 数：", chunk.usage.total_tokens) break if chunk.choices[0].delta.content: print(chunk.choices[0].delta.content)

5.3 本地模型幻觉：为什么 Ollama 的 Qwen2 总是胡说八道？

这不是 LiteLLM 的问题，但新手常误以为是它导致的。真相是：Ollama 默认启用num_ctx=2048，而 Qwen2-7B 的原生上下文是 32768，小窗口导致模型“失忆”。

验证方法：用ollama show qwen2:7b查看模型参数，会发现num_ctx是 2048。解决方案是启动时指定：

ollama run qwen2:7b --num_ctx 32768 "请总结以下内容：..."

或者在 LiteLLM 调用时透传：

response = litellm.completion( model="ollama/qwen2:7b", messages=messages, extra_body={"options": {"num_ctx": 32768}} # 强制扩大上下文 )

实测显示，num_ctx从 2048 提升到 32768 后，Qwen2-7B 在长文档摘要任务中的事实准确率从 63% 提升到 89%。这个参数的影响远超temperature，却被绝大多数教程忽略。

5.4 权限错误：为什么设置了 API Key 还是报 401？

LiteLLM 的鉴权逻辑是“就近原则”：它会按以下顺序查找 API Key：

1. litellm.completion(..., api_key="xxx")参数
2. litellm.api_key全局变量
3. 环境变量OPENAI_API_KEY（仅对 OpenAI 兼容模型）
4. ~/.litellm/.env文件里的OPENAI_API_KEY

最容易踩的坑是：你在.env文件里写了OPENAI_API_KEY=sk-xxx，但调用的是model="anthropic/claude-3-haiku"，而 Anthropic 需要ANTHROPIC_API_KEY。LiteLLM 不会自动把OPENAI_API_KEY映射过去，必须显式传参或设对应环境变量。

快速诊断命令：

import litellm print("当前全局 key：", litellm.api_key) print("环境变量：", {k:v for k,v in os.environ.items() if "KEY" in k.upper()})

5.5 性能瓶颈：为什么并发 100 QPS 时延迟飙升到 10s？

LiteLLM 本身是 CPU-bound 的，但真正的瓶颈往往在DNS 解析和HTTP 连接池。默认的httpx.AsyncClient每个域名只维持 10 个空闲连接，当并发突增时，大量请求卡在“等待连接”阶段。

解决方案是显式配置连接池：

import httpx from litellm import completion # 创建自定义 client client = httpx.AsyncClient( limits=httpx.Limits( max_connections=1000, max_keepalive_connections=100, keepalive_expiry=60 ), timeout=httpx.Timeout(60.0, connect=10.0) ) response = completion( model="gpt-4o", messages=messages, client=client # 传入自定义 client )

我们线上将max_connections设为 1000，keepalive_expiry设为 60 秒，P99 延迟从 10.2s 降到 1.8s。这个优化不需要改 LiteLLM 源码，纯配置层面就能搞定。

6. 进阶技巧与未来演进：超越基础 API 调用的深度用法

6.1 模型能力探测：如何在运行时动态判断模型是否支持某功能？

LiteLLM 提供get_supported_openai_params()函数，但它返回的是静态配置。真正实用的是运行时探测。我们封装了一个ModelCapabilityChecker：

import litellm from litellm import completion class ModelCapabilityChecker: def __init__(self, model_name: str): self.model_name = model_name def supports_vision(self) -> bool: """探测是否支持多模态""" try: response = completion( model=self.model_name, messages=[{ "role": "user", "content": [{"type": "text", "text": "描述这张图"}, {"type": "image_url", "image_url": {"url": "https://example.com/test.jpg"}}] }], timeout=10 ) return True except Exception as e: return "image" in str(e).lower() def supports_function_calling(self) -> bool: """探测是否支持 function calling""" try: response = completion( model=self.model_name, messages=[{"role": "user", "content": "获取北京天气"}], functions=[{"name": "get_weather", "parameters": {}}], timeout=10 ) return True except Exception as e: return "function" in str(e).lower() # 使用 checker = ModelCapabilityChecker("gpt-4o") print("支持视觉：", checker.supports_vision()) # True print("支持函数调用：", checker.supports_function_calling()) # True

这个探测逻辑被集成到我们的模型管理后台，每次新增模型时自动运行，生成能力矩阵表，避免业务方盲目调用不支持的功能。

6.2 自定义模型注册：如何让 LiteLLM 认识一个全新模型？

当某家新厂商发布模型，LiteLLM 还未支持时，你可以用register_model()注册：

from litellm import register_model register_model({ "model_name": "my-custom-model", # 业务中使用的名称 "litellm_params": { "model": "custom/my-model", # 实际调用的标识 "api_base": "https://api.my-ai.com/v1", "api_version": "2024-01-01" }, "tiers": ["high_performance"], # 自定义标签，用于路由 "input_cost_per_token": 0.00001, "output_cost_per_token": 0.00002 }) # 然后就可以像普通模型一样调用 response = litellm.completion( model="my-custom-model", messages=[{"role": "user", "content": "hello"}] )

更进一步，你可以注册自定义api_call