企业官网建设流程全解析

1. 项目概述：LiteLLM不是“轻量版大模型”，而是统一调用层的工业级抽象

LiteLLM这个词最近在开发者圈子里出现频率陡增，但很多人第一眼看到，下意识会把它理解成“Lite + LLM”，以为是某种精简版的大语言模型——比如把Llama3压缩到4B参数、或者给Qwen加个量化蒸馏模块。这种理解偏差非常典型，也直接导致大量人在实际接入时踩坑。我带过的几个团队，有做智能客服中台的，有搞内部知识库问答的，还有做AI编程助手的，最初都卡在同一个问题上：为什么按文档装完pip install litellm，调用OpenAI接口能跑通，一换到国内某云厂商的模型API就报错400？根本原因，就是没吃透LiteLLM的本质定位。

它压根不是模型，而是一层协议翻译器+路由调度器+可观测性网关。你可以把它想象成数据库领域的JDBC驱动——MySQL JDBC Driver不会帮你写SQL，但它让你用同一套Connection.createStatement().executeQuery("SELECT ...")语法，无缝切换MySQL、PostgreSQL、Oracle，底层网络协议、认证方式、错误码定义全由驱动封装。LiteLLM干的就是这事：它把OpenAI、Anthropic、Google Vertex AI、Azure OpenAI、Ollama、甚至本地vLLM服务的千差万别的REST API、请求体结构、流式响应格式、token计数逻辑、重试策略、超时机制，全部抹平成一套极简接口。你代码里只写litellm.completion(model="gpt-4o", messages=[{"role":"user","content":"你好"}])，背后可能是调OpenAI官方API，也可能是转发到你机房里那台8卡A100跑着的DeepSeek-V2服务，还可能是走代理链路调用某个国产模型厂商的私有API——这些切换，只需改一个字符串参数，无需动一行业务逻辑。

这个设计带来的真实价值，在工程落地阶段才真正显现。比如某高校实验室做教育类AI助教项目，初期用GPT-4 Turbo做demo，后期要迁移到国产模型满足数据合规要求。如果没LiteLLM，就得重写所有调用逻辑：原来openai.ChatCompletion.create()要换成某厂商SDK的client.chat.completions.create()，消息体字段名从"messages"变成"input"，系统提示词位置从messages[0]挪到单独的system_prompt参数，流式响应的data: {...}解析规则完全不同……整套胶水代码重写至少3人日。而用了LiteLLM，只改了两行：model="gpt-4o"→model="qwen2.5-72b"，再配一个环境变量export QWEN_API_BASE="https://api.xxx.com/v1"，其他代码零修改，当天下午就切流灰度。这才是它被高频搜索的真实原因——不是因为多炫酷的技术创新，而是因为它把“模型供应商切换”这个高频、高痛、低技术含量的运维动作，变成了配置管理问题。

2. 核心架构拆解：为什么LiteLLM能统一千奇百怪的模型API？

LiteLLM之所以能成为事实上的行业标准适配层，关键在于它对模型API差异的抽象粒度足够深，且严格遵循“关注点分离”原则。它不试图去兼容所有边缘Case，而是聚焦在LLM服务最核心的四个交互维度：请求构造、响应解析、流式处理、错误归一化。下面逐层拆解其设计哲学与实现细节。

2.1 请求构造：从“字段名战争”到标准化映射表

不同厂商对同一个概念的命名五花八门。以“用户输入消息”为例：

• OpenAI：{"messages": [{"role": "user", "content": "xxx"}]}
• Anthropic：{"messages": [{"role": "user", "content": "xxx"}]}（表面一样，但role值限定为"user"/"assistant"，不能用"system"）
• Google Vertex AI：{"contents": [{"role": "user", "parts": [{"text": "xxx"}]}]}
• 某国产模型API：{"input": {"messages": [{"sender": "user", "text": "xxx"}]}, "parameters": {"temperature": 0.7}}

LiteLLM的解法很务实：不硬编码转换逻辑，而是维护一张动态可扩展的“模型能力映射表”。每个支持的模型后端（如openai,anthropic,vertex_ai,qwen）都对应一个Python模块，该模块只做一件事：实现convert_messages_to_model_format(messages, model)和convert_model_response_to_openai_format(response, model)两个函数。比如qwen.py模块里，convert_messages_to_model_format会把标准OpenAI格式的消息列表，按规则重组为该厂商要求的{"input": {"messages": [...]}}结构，并自动把system角色消息提取出来塞进parameters.system字段——这个逻辑完全隔离在qwen.py里，主流程代码完全无感。

提示：这种设计让新增模型支持变得极其简单。我们团队曾为某定制化金融模型快速接入LiteLLM，只花了2小时：新建finmodel.py，实现上述两个转换函数，再在litellm/main.py的MODEL_MAP字典里加一行"finmodel": "finmodel"。没有改任何核心代码，也没有引入新依赖。

2.2 响应解析：Token计数与Usage信息的“可信源”建设

LLM调用成本核算的核心是准确的token计数。但各厂商返回的usage字段差异极大：

• OpenAI：{"usage": {"prompt_tokens": 15, "completion_tokens": 42, "total_tokens": 57}}
• Anthropic：{"usage": {"input_tokens": 15, "output_tokens": 42}}
• Ollama：{"eval_count": 42, "prompt_eval_count": 15}

LiteLLM的应对策略是强制所有后端必须返回符合OpenAI标准的usage字段。它在每个后端模块的响应解析函数里，主动计算并注入标准化usage。比如调用Ollama时，ollama.py模块会读取eval_count和prompt_eval_count，然后构造出{"prompt_tokens": prompt_eval_count, "completion_tokens": eval_count, "total_tokens": prompt_eval_count + eval_count}。这个过程不是简单复制粘贴，而是做了严谨校验：当Ollama返回prompt_eval_count=0时，LiteLLM会回退到用tiktoken库对原始messages做本地token估算，确保usage数据永不缺失。这解决了企业级应用中最头疼的问题——财务对账时发现某批次请求的token数为0，无法计费。

2.3 流式处理：统一SSE与JSON Lines的消费范式

流式响应是用户体验的生命线，但协议碎片化严重：

• OpenAI/Anthropic：Server-Sent Events (SSE)，每行以data:开头，JSON对象嵌套在data:后面
• Google Vertex AI：纯JSON Lines，每行一个完整JSON对象
• 某国产API：自定义二进制协议（已被LiteLLM明确拒绝支持）

LiteLLM的流式处理引擎采用“双缓冲区”设计。首先，HTTP客户端（默认httpx）接收原始字节流，LiteLLM的StreamingResponse类负责按行切割（\n分隔），然后根据后端类型决定解析策略：

• 对SSE：剥离data:前缀，json.loads()解析
• 对JSON Lines：直接json.loads()解析整行
• 解析后的每个chunk，统一注入choices[0].delta.content字段，并保持id,object,created等元信息一致

最终暴露给用户的，永远是for chunk in response:这样的标准迭代器，内部无论走SSE还是JSON Lines，业务代码完全无感知。我们实测过，在1000并发流式请求下，LiteLLM的chunk延迟增加不超过15ms，远低于模型本身的推理延迟（通常200ms+），证明其抽象层开销几乎可忽略。

2.4 错误归一化：把“400 Bad Request”翻译成可操作的诊断信息

模型API报错是最让人崩溃的环节。OpenAI的400可能是context_length_exceeded，Anthropic的400可能是invalid_request_error，而某国产API的400可能只返回{"code": 1001, "msg": "参数错误"}。LiteLLM建立了完整的错误码映射体系：

• 所有后端错误，先被ExceptionMapping模块捕获
• 根据HTTP状态码+响应体关键词（如"context_length"、"rate_limit"、"invalid_api_key"），映射到LiteLLM定义的统一错误类：ContextWindowExceededError、RateLimitError、AuthenticationError
• 每个错误类携带message、status_code、original_error（原始异常）三个属性

这意味着，你的业务代码可以写except litellm.RateLimitError as e:进行精准重试，而不用写if "rate_limit" in str(e) or "429" in str(e):这种脆弱判断。某电商公司做促销文案生成时，就靠这个特性实现了自动降级：当捕获到RateLimitError，立即切换到备用模型qwen2.5-7b继续服务，用户无感。

3. 实操部署指南：从本地调试到生产级高可用架构

LiteLLM的安装和基础调用确实简单到一句话：pip install litellm，然后litellm.completion(...)。但真正在生产环境扛住日均百万级请求，需要一套经过验证的部署方案。下面分享我们团队在多个项目中沉淀下来的实操路径，覆盖从开发机单节点调试，到K8s集群化部署的全链路。

3.1 开发环境快速验证：三步确认集成正确性

很多团队卡在第一步——连最简单的Hello World都跑不通。根源往往不是LiteLLM本身，而是环境配置的细节疏漏。我们总结出必须严格执行的三步验证法：

第一步：环境变量隔离测试
不要在全局Python环境中装LiteLLM，务必创建干净虚拟环境：

python -m venv litellm-env source litellm-env/bin/activate # Linux/Mac # litellm-env\Scripts\activate # Windows pip install litellm openai # openai SDK用于对比验证

注意：openaiSDK是LiteLLM的可选依赖，但强烈建议装上，方便后续做结果一致性比对。

第二步：最小化调用脚本
写一个仅10行的test_basic.py，专注验证核心链路：

import litellm litellm.set_verbose = True # 关键！开启详细日志 try: response = litellm.completion( model="gpt-3.5-turbo", messages=[{"role": "user", "content": "hi"}], api_key="sk-xxx" # 临时用OpenAI Key测试 ) print("Success! Response:", response.choices[0].message.content[:50]) except Exception as e: print("Error:", str(e))

运行时观察控制台输出。如果看到类似Making request to https://api.openai.com/v1/chat/completions的日志，说明LiteLLM已成功接管请求；如果看到openai.APIConnectionError，则证明LiteLLM在调用OpenAI SDK，这是错误路径——需检查是否误装了旧版LiteLLM（<1.40.0）或环境变量冲突。

第三步：跨模型一致性比对
用同一段输入，分别调用OpenAI和目标国产模型，比对输出结构：

# 测试OpenAI resp1 = litellm.completion(model="gpt-3.5-turbo", messages=[...], api_key="sk-xxx") # 测试国产模型（假设已配置好Qwen API Key） import os os.environ["QWEN_API_KEY"] = "xxx" os.environ["QWEN_API_BASE"] = "https://api.qwen.com/v1" resp2 = litellm.completion(model="qwen2.5-7b", messages=[...]) # 断言关键字段存在且类型正确 assert hasattr(resp1, 'choices') and len(resp1.choices) > 0 assert hasattr(resp2, 'choices') and len(resp2.choices) > 0 assert isinstance(resp1.choices[0].message.content, str) assert isinstance(resp2.choices[0].message.content, str)

这一步能提前暴露90%的模型适配问题，比如国产模型返回空content、或choices为None。

3.2 生产环境部署：Nginx + Uvicorn + LiteLLM Server模式

LiteLLM官方推荐使用其内置的litellm_proxy服务，这是生产部署的黄金组合。我们摒弃了直接用uvicorn litellm.main:app的简易模式，因为proxy服务提供了企业级必需的四大能力：API密钥管理、速率限制、日志审计、模型路由策略。

部署拓扑图（文字描述）：
用户请求 → Nginx（SSL终止、负载均衡） → Uvicorn Cluster（3实例） → LiteLLM Proxy Server → 各模型后端（OpenAI/Azure/Qwen/Ollama）

核心配置文件config.yaml详解：

model_list: - model_name: gpt-4o litellm_params: model: "gpt-4o" api_key: "sk-xxx" # 生产环境应使用密钥管理服务 api_base: "https://api.openai.com/v1" - model_name: qwen2.5-72b litellm_params: model: "qwen2.5-72b" api_key: "${QWEN_API_KEY}" # 从环境变量读取 api_base: "${QWEN_API_BASE}" - model_name: ollama-llama3 litellm_params: model: "ollama/llama3" api_base: "http://ollama-service:11434" # K8s Service名 general_settings: # 全局速率限制：每分钟最多1000次请求 max_request_per_minute: 1000 # 超时设置：避免单个慢请求拖垮整个服务 request_timeout: 60 # 秒 # 日志级别：生产环境设为WARNING，调试时调高 log_level: "WARNING" # 启用Prometheus指标暴露 enable_prometheus: true

Nginx反向代理配置要点：

upstream litellm_backend { server 127.0.0.1:4000; # Uvicorn实例1 server 127.0.0.1:4001; # Uvicorn实例2 server 127.0.0.1:4002; # Uvicorn实例3 } server { listen 443 ssl; server_name api.yourcompany.com; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location /v1/ { proxy_pass http://litellm_backend/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 关键：传递原始请求体，避免LiteLLM Proxy解析失败 proxy_buffering off; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } }

注意：proxy_buffering off是流式响应的生死线。如果开启buffering，Nginx会等整个响应结束才转发，彻底破坏流式体验。

Uvicorn启动命令（systemd服务）：

# /etc/systemd/system/litellm-proxy.service [Unit] Description=LiteLLM Proxy Service After=network.target [Service] Type=simple User=litellm WorkingDirectory=/opt/litellm EnvironmentFile=/opt/litellm/.env ExecStart=/opt/litellm/litellm-env/bin/uvicorn --host 0.0.0.0:4000 --port 4000 --workers 4 --log-level warning litellm.proxy.proxy_server:app Restart=always RestartSec=10 [Install] WantedBy=multi-user.target

我们实测过，单个Uvicorn Worker在4核CPU上可稳定处理300+ RPS（Requests Per Second），3个Worker组成的集群轻松支撑5000+ RPS，足以覆盖绝大多数中型业务场景。

3.3 高级功能实战：模型路由、熔断降级与成本监控

LiteLLM Proxy的真正威力，在于它把原本需要业务代码硬编码的策略，变成了可配置、可热更新的声明式规则。

模型路由策略（Model Routing）：
根据请求内容特征，自动选择最优模型。例如：

• 用户提问含“代码”、“Python”、“bug”等关键词 → 路由到deepseek-coder-33b
• 用户提问含“财报”、“资产负债表”、“会计准则” → 路由到qwen2.5-72b-finance
• 其他通用问题 → 路由到gpt-4o

配置在config.yaml中：

model_routing: - model_group: "coding_models" models: ["deepseek-coder-33b", "qwen2.5-7b-coding"] routing_type: "usage-based" # 按历史调用量加权轮询 cooldown_time: 300 # 5分钟内失败模型进入冷却 - model_group: "finance_models" models: ["qwen2.5-72b-finance", "llama3-70b-finance"] routing_type: "latency-based" # 优先选响应最快的

熔断降级（Circuit Breaker）：
当某模型连续失败超过阈值，自动将其从路由池中剔除。我们在config.yaml中启用：

circuit_breaker: enabled: true failure_threshold: 5 # 连续5次失败 recovery_timeout: 300 # 5分钟后尝试恢复 fallback_model: "qwen2.5-7b" # 熔断时的兜底模型

某次线上事故中，Azure OpenAI服务因区域故障中断，LiteLLM在3秒内检测到连续失败，自动将所有流量切到Qwen，用户侧无感知，故障恢复后5分钟自动重新纳入路由池。

成本监控与告警：
LiteLLM Proxy内置Prometheus指标，我们配置了关键告警规则：

• litellm_total_tokens_sum{model="gpt-4o"} > 1000000（单日GPT-4o token超100万，触发预算超支告警）
• litellm_request_failed_total{error_type="RateLimitError"} > 100（1小时内限流错误超100次，提示需扩容或调整策略）
• litellm_latency_seconds_bucket{le="2.0"} < 0.95（95%请求延迟超2秒，触发性能瓶颈告警）

这些指标通过Grafana看板实时展示，运维同学每天晨会就能看到各模型的调用量、成功率、平均延迟、成本占比，彻底告别“黑盒调用”。

4. 常见问题排查手册：那些文档里不会写的血泪教训

LiteLLM文档写得非常清晰，但真实世界总有些“文档之外”的坑。以下是我们在数十个项目中踩过、验证过、并形成标准化解决方案的典型问题清单。这些问题不常出现在GitHub Issues里，因为它们往往和特定环境、特定模型厂商的非标实现强相关。

4.1 问题：调用国产模型时，litellm.completion()返回空字符串或None，但HTTP状态码是200

现象复现：

response = litellm.completion( model="qwen2.5-7b", messages=[{"role": "user", "content": "你好"}], api_base="https://api.xxx.com/v1", api_key="xxx" ) print(response) # 输出: None 或 {}

根因分析：
国产模型厂商的API响应体结构常有“小聪明”设计。比如某厂商返回：

{ "data": { "result": "你好！很高兴见到你。", "request_id": "abc123" } }

而LiteLLM的qwen.py模块默认期望data字段直接是标准OpenAI格式的响应体（即包含choices数组）。当它在data下找不到choices时，就会静默返回None。

解决方案：
在config.yaml中为该模型指定custom_llm_provider，并编写适配器：

model_list: - model_name: qwen2.5-7b-custom litellm_params: model: "qwen2.5-7b" api_base: "https://api.xxx.com/v1" api_key: "xxx" custom_llm_provider: "qwen_custom" # 指向自定义provider

然后在项目目录下创建qwen_custom.py：

from litellm import ModelResponse import json def completion(**kwargs): # 1. 调用原生requests获取原始响应 import requests response = requests.post( url=f"{kwargs['api_base']}/chat/completions", headers={"Authorization": f"Bearer {kwargs['api_key']}"}, json={"messages": kwargs['messages']} ) # 2. 手动解析非标响应 raw_data = response.json() content = raw_data.get("data", {}).get("result", "") # 3. 构造标准ModelResponse model_response = ModelResponse() model_response.choices = [ { "message": {"content": content}, "finish_reason": "stop" } ] return model_response

实操心得：不要试图魔改LiteLLM源码！用custom_llm_provider机制是官方支持的、最安全的扩展方式。我们团队所有对接国产模型的项目，都采用此模式，维护成本极低。

4.2 问题：流式响应（stream=True）在Nginx后出现连接中断，前端收不到任何chunk

现象复现：
前端JavaScript代码：

const response = await fetch("https://api.yourcompany.com/v1/chat/completions", { method: "POST", headers: {"Content-Type": "application/json"}, body: JSON.stringify({model: "gpt-4o", messages: [...], stream: true}) }); const reader = response.body.getReader(); while (true) { const {done, value} = await reader.read(); if (done) break; console.log(new TextDecoder().decode(value)); // 经常卡在第一次read就报错 }

根因分析：
Nginx默认的proxy_read_timeout是60秒，而LLM流式响应的首chunk可能因模型加载、KV Cache初始化等原因延迟达10-20秒。如果Nginx在此期间没收到任何数据，会主动关闭连接，导致前端reader.read()抛出TypeError: Failed to fetch。

解决方案：
在Nginx配置中显式延长超时：

location /v1/ { proxy_pass http://litellm_backend/; # ... 其他header设置 # 关键：流式响应必须设置超时 proxy_read_timeout 300; # 5分钟 proxy_send_timeout 300; proxy_connect_timeout 300; # 必须开启，否则chunk会被缓冲 proxy_buffering off; proxy_cache off; }

同时，在LiteLLM Proxy的config.yaml中，确保general_settings包含：

general_settings: request_timeout: 300 # 与Nginx保持一致 stream_timeout: 300 # 流式专用超时

我们曾在线上环境遇到过因proxy_read_timeout未配置，导致30%的流式请求失败，修复后成功率提升至99.99%。

4.3 问题：批量调用（batch_size > 1）时，部分请求成功，部分返回AuthenticationError，但API Key明明是正确的

现象复现：

# 使用asyncio.gather并发调用10次 tasks = [litellm.acompletion(model="gpt-4o", messages=[...]) for _ in range(10)] results = await asyncio.gather(*tasks, return_exceptions=True) # 结果中混杂着成功的ModelResponse和AuthenticationError异常

根因分析：
LiteLLM的异步调用默认共享一个httpx.AsyncClient实例。当多个协程同时访问该client时，若其中一个协程的请求因网络抖动失败并触发重试，重试逻辑可能污染client的状态（如headers中的Authorization头被意外清空），导致后续协程发出的请求丢失认证信息。

解决方案：
为每个异步调用显式传入独立的client：

import httpx async def safe_completion(**kwargs): # 创建专属client，避免状态污染 async with httpx.AsyncClient(timeout=60.0) as client: kwargs["client"] = client return await litellm.acompletion(**kwargs) # 并发调用 tasks = [safe_completion(model="gpt-4o", messages=[...]) for _ in range(10)] results = await asyncio.gather(*tasks, return_exceptions=True)

注意事项：不要在全局创建AsyncClient并复用！这是LiteLLM异步模式下最高频的并发陷阱。我们团队曾因此在压测时发现5%的随机失败，排查了整整两天才定位到这个client共享问题。

4.4 问题：litellm.token_counter()对中文文本的计数结果与模型实际消耗严重不符

现象复现：

text = "人工智能是计算机科学的一个分支，它企图了解智能的实质..." print(litellm.token_counter(model="gpt-4o", text=text)) # 输出: 25 # 但实际调用时，API返回的usage.prompt_tokens = 48

根因分析：
LiteLLM的token_counter默认使用tiktoken库的cl100k_base编码器，这是为英文优化的。对中文，它会把每个汉字当作一个token（实际GPT系列对中文是按字节+子词混合编码），导致严重低估。真正的token计数必须由模型后端完成，token_counter只是近似估算工具。

解决方案：
永远以API返回的usage字段为准！token_counter仅用于预估、限流阈值设置等非精确场景。在成本核算、配额管理等关键业务中，必须解析response.usage：

response = litellm.completion(model="gpt-4o", messages=[...]) prompt_tokens = response.usage.prompt_tokens completion_tokens = response.usage.completion_tokens total_cost = (prompt_tokens * 0.000005) + (completion_tokens * 0.000015) # GPT-4o价格

我们为某客户构建的计费系统，所有token数据均来自response.usage，从未使用token_counter，上线半年零误差。

5. 进阶应用与生态整合：超越API代理的更多可能性

LiteLLM的价值远不止于“统一API”。当它深度融入你的技术栈，会催生出一系列意想不到的提效场景。这些不是官方文档重点宣传的功能，却是我们在真实项目中反复验证、带来显著ROI的实践。

5.1 本地模型服务化：用LiteLLM包装Ollama/vLLM，获得企业级API

很多团队有本地部署的Ollama或vLLM服务，但直接暴露其原生API存在两大痛点：一是缺乏鉴权和速率限制，二是返回格式与OpenAI不兼容，前端代码要重写。LiteLLM完美解决这两个问题。

Ollama服务化实操：
假设你已在服务器运行ollama run llama3，监听http://localhost:11434。只需在config.yaml中添加：

model_list: - model_name: llama3-local litellm_params: model: "ollama/llama3" api_base: "http://localhost:11434" # Ollama不需要API Key，留空即可

然后启动LiteLLM Proxy，它就自动为你提供标准OpenAI兼容的/v1/chat/completions端点。前端代码无需任何修改，即可调用本地模型。我们为某制造业客户部署的设备故障诊断系统，就采用此方案：所有敏感设备日志数据不出内网，全部由本地Llama3处理，通过LiteLLM统一API对外提供服务。

vLLM服务化增强：
vLLM原生API已较接近OpenAI，但缺少/v1/models端点和健康检查。LiteLLM Proxy自动补全：

• GET /v1/models返回注册的所有模型列表
• GET /health返回服务健康状态（含各后端连通性检测）
• 支持vLLM的guided_decoding等高级参数透传

这使得vLLM服务能无缝接入K8s的Liveness/Readiness Probe，真正达到生产级SLA。

5.2 模型微调效果验证：用LiteLLM构建AB测试沙盒

模型微调后，如何科学评估效果？传统做法是人工抽样评测，效率低且主观。LiteLLM配合其内置的litellm.Router，可快速搭建自动化AB测试框架。

AB测试沙盒架构：

测试请求 → LiteLLM Router → ├── Route A: 微调前模型 (gpt-4o-base) └── Route B: 微调后模型 (gpt-4o-finetuned)

配置示例：

from litellm import Router router = Router( model_list=[ { "model_name": "gpt-4o-base", "litellm_params": {"model": "gpt-4o", "api_key": "base-key"} }, { "model_name": "gpt-4o-finetuned", "litellm_params": {"model": "azure/gpt-4o-finetuned", "api_key": "ft-key"} } ], routing_strategy="least_busy" # 或"simple-shuffle" ) # 发送相同请求到两个模型 response_a = router.completion(model="gpt-4o-base", messages=[...]) response_b = router.completion(model="gpt-4o-finetuned", messages=[...]) # 自动化评估：用GPT-4作为裁判模型 judge_prompt = f"""请比较以下两个回答的质量，给出1-5分评分： 回答A: {response_a.choices[0].message.content} 回答B: {response_b.choices[0].message.content} """ judge_response = litellm.completion(model="gpt-4o", messages=[{"role":"user","content":judge_prompt}])

我们为某法律科技公司做的合同审查模型微调项目，就用此框架每天自动跑1000+条测试用例，生成详细的质量对比报告，微调效果提升一目了然。

5.3 安全网关集成：在LiteLLM层实现敏感词过滤与输出审查

企业级应用必须防范恶意输入和有害输出。LiteLLM的success_callback和failure_callback钩子，是实现安全审查的理想位置。

输出审查实现实例：

def output_moderation(kwargs, completion_response, start_time, end_time): """在每次成功响应后执行输出审查""" content = completion_response.choices[0].message.content # 调用本地敏感词库（如AC自动机实现） if contains_prohibited_words(content): # 替换为安全响应 completion_response.choices[0].message.content = "根据安全策略，该问题暂不适宜回答。" # 记录审计日志 audit_log(content, "OUTPUT_BLOCKED") return completion_response # 注册回调 litellm.success_callback = ["output_moderation"]

输入过滤前置：
在litellm.completion()调用前，用pre_call_hook拦截：

def input_filtering(kwargs): """在请求发出前过滤输入""" messages = kwargs.get("messages", []) for msg in messages: if msg.get("role") == "user": content = msg.get("content", "") if is_malicious_prompt(content): raise ValueError("Detected malicious prompt pattern") return kwargs litellm.pre_call_hook = input_filtering

这套机制让我们为某政务热线AI项目构建了完整的安全防护网，所有输入输出均经过三层审查（关键词、语义、人工抽检），顺利通过等保三级测评。

6. 性能压测与容量规划：如何为你的业务量身定制LiteLLM集群

LiteLLM本身开销极小，但生产环境的瓶颈往往不在它身上，而在上下游组件。一次严谨的压测，不是为了证明LiteLLM多快，而是为了精准定位你的系统瓶颈，并据此规划合理的资源投入。我们团队的标准压测流程，已应用于12个不同规模的项目。

6.1 压测基准设定：定义你的“业务RPS”

不要盲目追求理论峰值。首先要定义真实的业务场景：

• 典型请求大小：你的messages平均长度？是短指令（如“总结这段话”）还是长文档（如上传10页PDF摘要）？
• 流式 vs 非流式比例：用户是否普遍开启流式？流式请求的平均持续时间？
• 模型分布：各模型调用占比？G