企业官网建设流程全解析

1. 项目概述：LiteLLM 是什么，它解决了哪些真实痛点？

LiteLLM 这个名字乍一听像某个轻量级编程语言或小众框架，但其实它是一个在大模型应用开发圈子里迅速走红的开源工具库——它的核心定位非常明确：统一所有主流大模型 API 的调用接口，让开发者写一次代码，就能无缝切换 OpenAI、Anthropic、Google Gemini、Cohere、Ollama、本地 vLLM 甚至国产千问、讯飞星火等数十种后端模型服务。我第一次在某高校实验室的模型服务中试用 LiteLLM，是为了解决一个特别实际的问题：团队里三位同学分别在调试不同模型——A 同学用 OpenAI GPT-4-turbo 做对话评估，B 同学用本地部署的 Qwen2-7B 做中文摘要生成，C 同学则在测试 Anthropic Claude-3-haiku 的长文本推理能力。结果三套代码各自维护一套请求逻辑、参数映射、错误重试、token 计数方式，光是处理system消息位置差异就改了三天。直到有人把 LiteLLM 加进 requirements.txt，三行代码封装出统一的completion()接口，当天下午就完成了多模型 A/B 测试 pipeline 的整合。这就是 LiteLLM 最本质的价值：它不训练模型，不优化推理速度，但它把“对接模型”这件事从工程瓶颈降维成配置项。它适合谁？不是给算法研究员看的底层训练框架，而是给产品侧快速验证想法的 PM、给后端工程师集成 AI 能力的 DevOps、给学生做课程项目的初学者——只要你需要在不同模型间灵活切换、做对比实验、构建可插拔的 AI 服务，LiteLLM 就是那个帮你省下 80% 适配时间的“API 转接头”。它背后没有玄学，只有对各家 API 文档的深度抠细节：比如 OpenAI 把 temperature 放在顶层，而 Anthropic 必须塞进model_params字典；比如 Ollama 默认不返回 usage 字段，LiteLLM 却能通过 prompt 工程反推 token 数；再比如某些国产模型要求messages中必须包含role: system，而 OpenAI 允许省略——这些散落在各厂商文档角落的“坑”，LiteLLM 全部收编进自己的映射表里，暴露给用户的，只剩下一个干净、稳定、符合 OpenAI 风格的 Python 函数。

2. 核心设计思路与方案选型逻辑

2.1 为什么不是自己封装？LiteLLM 的不可替代性在哪？

很多人第一反应是：“不就是发 HTTP 请求吗？我用 requests 写个 wrapper 不就行了？”——我完全理解这种想法，事实上我最早也这么干过。但很快发现，这种“手写适配层”的方案在真实项目中会迅速崩塌。举几个典型场景：当你要支持 streaming 响应时，OpenAI 返回的是text/event-stream，每行是data: {...}；而 Google Gemini 的流式接口返回的是普通 JSON 数组；Ollama 则是分块 chunked transfer encoding。如果自己封装，你得为每个模型写一套 event parser，还要处理连接中断、重连、buffer 管理。再比如错误码：OpenAI 的429是 rate limit，Anthropic 的429可能是 concurrent request 超限，而某些国产模型直接返回500并附一句“服务繁忙”，根本没标准 error code。LiteLLM 的核心设计哲学，就是把所有这些“非功能性需求”全部收口：它内置了统一的 retry 机制（指数退避 + jitter）、统一的 timeout 策略（connect/read 总超时分离）、统一的 fallback 逻辑（主模型失败自动切到备用模型）、统一的 logging 结构（带 model_id、input_tokens、output_tokens、latency 的结构化日志）。更关键的是，它把“模型能力抽象”做到了极致。比如max_tokens参数，在 OpenAI 是硬性截断，在 Anthropic 是 soft limit（可能多生成几个 token），在本地 vLLM 上则对应max_new_tokens。LiteLLM 不是简单地做字符串替换，而是根据目标模型的实际行为，动态调整请求体构造逻辑。它甚至能识别出“这个模型不支持 function calling”，自动把 tools 参数剥离并降级为普通 system message 提示。这种深度语义理解，远超一个简单的 HTTP 封装器。所以 LiteLLM 的不可替代性，不在于它多“高级”，而在于它足够“啰嗦”——它把所有厂商不愿写进文档、用户懒得查的边界 case，全写进了自己的源码里。你用它，不是为了炫技，而是为了少踩坑、少 debug、少半夜被报警电话叫醒。

2.2 架构分层：从最简调用到企业级部署的演进路径

LiteLLM 的架构设计非常务实，它没有强行搞微服务或复杂中间件，而是按使用深度分三层，每层解决不同阶段的真实问题：

• L1：单机直连层（Local Direct Call）
  这是最常见的入门用法：pip install litellm，然后from litellm import completion，一行代码调用。它默认使用同步 HTTP 客户端，适合脚本、Jupyter Notebook、小型 Web 应用。这一层的核心价值是“零配置启动”。你不需要提前启动任何服务进程，不需要管理端口，不需要配置环境变量——只要 API KEY 正确，completion(model="gpt-4", messages=[...])就能跑通。我带过的几个本科生项目，都是从这一层起步，两天内就搭出了带多模型切换的 demo 网站。

• L2：代理服务层（Proxy Server）
  当你需要集中管理密钥、做访问控制、记录审计日志、实现负载均衡时，LiteLLM 自带的litellm proxy就派上用场了。它本质是一个基于 FastAPI 的轻量级 HTTP 服务，启动命令就一条：litellm --model gpt-4,claude-3-haiku,qwen2-7b --api_key sk-xxx。所有客户端请求都打到这个 proxy，它负责路由、鉴权、限流、日志、监控（支持 Prometheus metrics）。这里有个关键细节：proxy 不是简单转发，它做了请求/响应的双向转换。比如客户端用 OpenAI 格式发请求，proxy 可以把它转成 Anthropic 格式发给后端，再把 Anthropic 的响应转回 OpenAI 格式返回给客户端。这意味着前端完全不用感知后端模型差异。我们某公司内部的 AI 工具平台，就是用这一层统一了研发、测试、产品三个部门的模型调用入口，密钥全部存在 Vault 里，proxy 通过 IAM 角色自动拉取，彻底杜绝了 API KEY 硬编码在代码里的风险。

• L3：编排调度层（Orchestration & Routing）
  这是面向大规模生产环境的设计。LiteLLM 支持基于规则的智能路由：你可以定义if input_tokens > 8000 then route to claude-3-opus else route to gpt-4-turbo，或者if contains_chinese(messages) then route to qwen2-7b else route to gpt-4。它还支持 fallback chain：主模型超时或报错，自动尝试备用模型，并把最终结果和耗时统计一并返回。更进一步，它能接入外部决策系统，比如把 routing logic 写成 Python 函数，实时调用内部风控服务判断当前请求是否高风险，再决定走哪个模型。这一层已经脱离了“工具库”范畴，变成了一个可编程的 AI 网关。我们帮某金融机构做的合规审查助手，就用这一层实现了“敏感词触发时自动切到本地部署的审计专用模型”，整个链路毫秒级响应，且所有决策过程可审计、可回放。

这三层不是割裂的，而是平滑演进的。你从 L1 开始写业务逻辑，随着用户量增长，只需加一行命令启动 proxy，前端几乎不用改；再往后，把 routing rule 写进配置文件，就完成了向 L3 的升级。这种渐进式架构，正是 LiteLLM 在真实世界中被广泛采用的关键原因——它不强迫你一开始就设计完美，而是陪着你一起长大。

2.3 为什么选 Python？生态兼容性如何保障？

LiteLLM 选择 Python 作为唯一实现语言，是个经过深思熟虑的决定，而非技术惯性。首先，Python 是目前 AI/ML 领域事实上的胶水语言，从数据预处理（pandas）、模型训练（PyTorch/TensorFlow）、到部署（FastAPI/Flask），整个链条都重度依赖 Python。如果 LiteLLM 用 Rust 或 Go 写，虽然性能可能更好，但会立刻失去与 HuggingFace Transformers、LangChain、LlamaIndex 等主流生态的无缝集成能力。举个例子：LangChain 的ChatOpenAI类，底层就是调用 OpenAI SDK；而 LiteLLM 提供了原生的ChatLiteLLM类，它完全兼容 LangChain 的所有 chain、agent、retriever 接口。你只需要把llm = ChatOpenAI(model="gpt-4")换成llm = ChatLiteLLM(model="gpt-4")，整个 RAG pipeline 就能无缝切换模型后端。这种“无感迁移”能力，是其他语言难以提供的。其次，Python 的动态特性极大降低了适配新模型的成本。当某家新厂商发布 API 时，LiteLLM 团队通常能在 24 小时内提交 PR，新增支持。这是因为它的模型适配逻辑高度模板化：每个模型对应一个ModelAdapter类，只需实现convert_messages_to_model_format()和convert_model_response_to_openai_format()两个方法。这种设计让社区贡献变得极其容易，目前 LiteLLM 支持的 100+ 模型中，超过 40% 来自社区 PR。最后，Python 的成熟异步生态（asyncio + httpx）让它能高效处理高并发 streaming 请求。LiteLLM 的 async completion 接口，实测在单机 32 核上能稳定支撑 500+ 并发流式响应，延迟抖动控制在 50ms 以内。这不是靠语言本身多快，而是靠对 asyncio event loop 的精细控制——比如它会为每个 streaming 连接分配独立的 task，避免一个慢连接阻塞整个 loop；它还会预分配 response buffer，减少内存碎片。这些细节，才是 Python 版 LiteLLM 能在生产环境站稳脚跟的真正原因。

3. 核心功能解析与实操要点

3.1 统一 API 接口：从 OpenAI 风格到全模型兼容的映射原理

LiteLLM 的核心魔法，藏在它对 OpenAI API 的“精准模仿”里。它不是粗暴地把所有模型都塞进openai.ChatCompletion.create()的壳子里，而是深入到每个字段的语义层面，做了一套精密的“语义对齐”。我们以最常用的messages参数为例，来拆解这个映射过程：

• OpenAI 原生格式：

  messages = [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Hello!"}, {"role": "assistant", "content": "Hi there!"} ]

• Anthropic 格式：
  Anthropic 不允许systemrole 出现在 messages 数组里，而是要求把 system prompt 单独提出来，作为system字段传入：

  # Anthropic SDK 要求 messages = [{"role": "user", "content": "Hello!"}] system = "You are a helpful assistant."

• LiteLLM 的处理逻辑：
  当你调用completion(model="claude-3-haiku", messages=messages)时，LiteLLM 的AnthropicAdapter会：

  1. 扫描messages数组，找到第一个role == "system"的 item；
  2. 将其content提取出来，赋值给system字段；
  3. 过滤掉所有role == "system"的 item，只保留user/assistant；
  4. 将处理后的messages和system一起传给 Anthropic SDK。

这个过程看似简单，但背后有大量边界 case 需要处理。比如：如果messages里有多个system消息怎么办？LiteLLM 的策略是“取第一个”，并记录 warning 日志。如果system消息出现在user消息之后呢？LiteLLM 会强制把它移到最前面，因为 Anthropic 的语义要求 system prompt 必须在上下文最开始。再比如tool_calls字段：OpenAI 用function_call，Anthropic 用tool_use，Google Gemini 用functionResponse。LiteLLM 定义了一套中间表示LiteLLM_ToolCall，所有模型 adapter 都要把它转成自己能理解的格式。这种“中间表示 + 双向转换”的设计，保证了上层业务代码的绝对纯净。你永远不需要写if model.startswith("claude"): ... elif model.startswith("gemini"): ...这样的分支判断。

提示：LiteLLM 对temperature、top_p、max_tokens等参数的处理同样遵循语义对齐原则。例如max_tokens在 OpenAI 中表示最大输出 token 数，而在 Anthropic 中，它对应的是max_tokens_to_sample，且必须是整数。LiteLLM 会自动做类型转换和字段名映射，你传max_tokens=1024，它会确保在 Anthropic 请求中变成"max_tokens_to_sample": 1024。这种“参数即服务”的理念，让开发者可以真正专注于 prompt engineering 和业务逻辑。

3.2 模型路由与智能 fallback：不只是简单的负载均衡

LiteLLM 的路由能力，远超传统负载均衡器的轮询或哈希。它的核心是“上下文感知路由”，即根据请求的实时内容、元数据、甚至外部状态，动态决定由哪个模型处理。我们来看几个真实场景下的配置案例：

• 基于输入长度的路由：
  大模型的上下文窗口差异巨大：GPT-4-turbo 支持 128K，Claude-3-opus 支持 200K，而本地 Qwen2-7B 只有 32K。如果用户上传了一份 100 页的 PDF，硬塞给 Qwen2-7B 必然失败。LiteLLM 允许你定义litellm_settings.yaml：

  model_list: - model_name: long-context-model litellm_params: model: claude-3-opus-20240229 api_key: sk-... - model_name: short-context-model litellm_params: model: qwen2-7b api_base: http://localhost:11434 router_settings: routing_strategy: usage-based-routing num_retries: 3

  然后在代码中：

  from litellm import Router router = Router(model_list=..., routing_strategy="usage-based-routing") # 自动根据 input_tokens 选择模型 response = router.completion( model="long-context-model", messages=[{"role": "user", "content": long_text}], max_tokens=2048 )

  usage-based-routing策略会先估算long_text的 token 数（用 tiktoken 或 jieba 分词），如果超过 64K，就优先路由到long-context-model。

• 基于内容语义的路由：
  更进一步，你可以写一个自定义 routing function：

  def semantic_router(request): # 简单关键词匹配，实际可用轻量级分类模型 if "金融" in request["messages"][-1]["content"] or "股票" in request["messages"][-1]["content"]: return "finance-specialist" elif "代码" in request["messages"][-1]["content"] or "python" in request["messages"][-1]["content"].lower(): return "code-assistant" else: return "general-assistant" router = Router( model_list=[ {"model_name": "finance-specialist", "litellm_params": {"model": "qwen2-72b-finance"}}, {"model_name": "code-assistant", "litellm_params": {"model": "deepseek-coder-33b"}}, {"model_name": "general-assistant", "litellm_params": {"model": "gpt-4-turbo"}} ], routing_strategy="custom-routing", custom_routing_function=semantic_router )

  这种路由方式，让同一个/chat/completions接口，能根据用户提问的领域，自动调用最合适的模型，用户体验上毫无感知。

• Fallback Chain 的实战价值：
  Fallback 不是简单的“A 挂了切 B”，而是带状态的智能降级。LiteLLM 的 fallback 支持多级、带条件的链式切换。例如：

  fallbacks = [ {"model": "gpt-4-turbo", "fallbacks": ["claude-3-haiku"]}, {"model": "claude-3-haiku", "fallbacks": ["qwen2-7b"]} ] response = completion( model="gpt-4-turbo", messages=[...], fallbacks=fallbacks, num_retries=2 # 每个模型最多重试2次 )

  它的工作流程是：先用gpt-4-turbo请求，如果返回429（限流）或500（服务端错误），则立即用claude-3-haiku重试；如果claude-3-haiku也失败，则再用qwen2-7b重试。最关键的是，LiteLLM 会把每次重试的耗时、token 数、错误信息都记录在response._hidden_params里，你可以据此做故障分析。我们在某 SaaS 产品的客服机器人中就用了这个机制：白天高峰时段，主模型gpt-4-turbo偶尔超时，fallback 到claude-3-haiku后，平均响应时间只增加 120ms，但成功率从 92% 提升到 99.8%，用户完全感觉不到切换。

3.3 本地模型集成：Ollama、vLLM、LM Studio 的零门槛接入

LiteLLM 对本地模型的支持，是它区别于其他 API 网关的最大亮点之一。它不假设你有 Kubernetes 集群或专业运维团队，而是让一个笔记本电脑也能成为 AI 服务节点。我们以最流行的 Ollama 为例，说明接入的极简性：

• Ollama 集成：
  Ollama 默认监听http://localhost:11434，提供类 OpenAI 的/api/chat接口。LiteLLM 只需两步：

  1. ollama pull qwen2:7b下载模型；
  2. litellm --model ollama/qwen2:7b --api_base http://localhost:11434启动 proxy。 此时，你的completion(model="ollama/qwen2:7b", ...)就能直接调用本地模型。LiteLLM 会自动处理 Ollama 特有的字段，比如 Ollama 的stream响应是纯文本流，LiteLLM 会把它 parse 成标准的 OpenAI streaming chunks；Ollama 不返回usage，LiteLLM 会通过 prompt 和 response 的字符数，结合模型的 tokenizer，估算出近似 token 数（误差在 ±5% 内，对计费和限流已足够）。

• vLLM 集成：
  vLLM 是高性能推理引擎，它暴露的是/v1/chat/completions接口。LiteLLM 的适配更进一步：它能利用 vLLM 的guided_decoding（JSON Schema 强制输出）和logprobs（token 概率）等高级特性。你只需：

  python -m vllm.entrypoints.api_server --model Qwen/Qwen2-7B-Instruct --host 0.0.0.0 --port 8000 litellm --model vllm/Qwen/Qwen2-7B-Instruct --api_base http://localhost:8000/v1

  然后在代码中：

  response = completion( model="vllm/Qwen/Qwen2-7B-Instruct", messages=[...], guided_json={"type": "object", "properties": {"answer": {"type": "string"}}} # LiteLLM 会自动转成 vLLM 的 guided_decoding 参数 )

  这种深度集成，让 LiteLLM 成为了连接前沿推理引擎和上层应用的“最佳翻译官”。

• LM Studio / Text Generation WebUI 的兼容：
  这些桌面 GUI 工具，本质上是把本地模型包装成 OpenAI 兼容 API。LiteLLM 对它们的支持，就是“开箱即用”。你启动 LM Studio，选择模型，开启OpenAI Compatible Server，LiteLLM 就能像调用真正的 OpenAI 一样调用它。我们某客户的数据标注团队，就用这种方式，让每个标注员的 Windows 笔记本都运行一个qwen2-1.5b实例，LiteLLM proxy 统一调度，既保证了数据不出内网，又实现了算力的弹性伸缩。

注意：本地模型集成最大的坑是“环境隔离”。Ollama、vLLM、LM Studio 各自管理自己的模型缓存和 CUDA 显存。LiteLLM 本身不管理这些，它只是个 HTTP 客户端。因此，务必确保你的本地模型服务已正确启动、端口未被占用、GPU 显存充足。一个实用技巧是：在启动 LiteLLM proxy 前，先用curl http://localhost:11434/api/tags测试 Ollama 是否就绪；用nvidia-smi检查 GPU 使用率。这些看似琐碎的检查，能帮你避开 80% 的“模型调用失败”问题。

4. 实操过程与核心环节实现

4.1 从零开始：五分钟搭建一个多模型 playground

下面是一个完整的、可直接复制粘贴运行的实操指南。它将带你从安装到运行一个支持 GPT-4、Claude-3-haiku 和本地 Qwen2-7B 的交互式 playground。整个过程无需任何云服务，全部在本地完成。

第一步：环境准备与依赖安装
确保你已安装 Python 3.9+ 和 pip。创建虚拟环境（推荐，避免包冲突）：

python -m venv litellm_env source litellm_env/bin/activate # Linux/Mac # litellm_env\Scripts\activate # Windows pip install --upgrade pip pip install litellm openai anthropic

注意：anthropic包是可选的，LiteLLM 会自动 fallback 到 httpx，但显式安装能获得更好的错误提示。

第二步：获取 API KEY 并配置环境变量

• OpenAI KEY：登录 platform.openai.com ，在 API Keys 页面创建新 key，复制下来。
• Anthropic KEY：同理，在 console.anthropic.com 获取。
• 设置环境变量（Linux/Mac）：

  export OPENAI_API_KEY="sk-..." export ANTHROPIC_API_KEY="sk-ant-api03-..."

  （Windows 用户用set OPENAI_API_KEY=...）

第三步：启动 LiteLLM Proxy 服务
这是最核心的一步。我们启动一个支持三个模型的 proxy：

litellm \ --model gpt-4-turbo \ --model claude-3-haiku-20240307 \ --model ollama/qwen2:7b \ --api_base http://localhost:11434 \ --port 4000 \ --debug

解释参数：

• --model：声明支持的模型名，可以多次使用；
• --api_base：指定 Ollama 的地址，LiteLLM 会自动识别ollama/前缀；
• --port 4000：proxy 监听端口，后续所有请求都打到这里；
• --debug：开启详细日志，方便排查问题。

提示：如果你还没有安装 Ollama，现在去 ollama.com 下载安装，然后运行ollama run qwen2:7b下载模型。首次运行会较慢，耐心等待。

第四步：编写 playground 脚本
创建一个playground.py文件：

import os import time from litellm import completion # 配置 LiteLLM 使用本地 proxy os.environ["OPENAI_API_BASE"] = "http://0.0.0.0:4000" os.environ["OPENAI_API_KEY"] = "anything" # proxy 模式下，KEY 可以是任意值 def chat_with_model(model_name: str, user_input: str): """与指定模型进行单轮对话""" try: start_time = time.time() response = completion( model=model_name, messages=[ {"role": "system", "content": "你是一个专业的 AI 助手，请用中文回答。"}, {"role": "user", "content": user_input} ], temperature=0.3, max_tokens=512 ) end_time = time.time() print(f"\n--- {model_name} 回答 ---") print(response.choices[0].message.content) print(f"[耗时: {end_time - start_time:.2f}s | 输入token: {response.usage.prompt_tokens} | 输出token: {response.usage.completion_tokens}]") except Exception as e: print(f"\n--- {model_name} 调用失败 ---") print(f"错误: {str(e)}") if __name__ == "__main__": print("=== LiteLLM 多模型 Playground ===") print("支持模型: gpt-4-turbo, claude-3-haiku-20240307, ollama/qwen2:7b") print("输入 'quit' 退出\n") while True: user_input = input("你: ").strip() if user_input.lower() in ["quit", "exit", "q"]: break if not user_input: continue # 并行调用三个模型，展示差异 print("\n正在并行调用三个模型...") for model in ["gpt-4-turbo", "claude-3-haiku-20240307", "ollama/qwen2:7b"]: chat_with_model(model, user_input)

第五步：运行并体验
在另一个终端中，运行python playground.py。输入一个问题，比如“请用一句话解释量子纠缠”，你会看到三个模型几乎同时返回答案，每个答案下方都清晰标注了耗时和 token 数。你会发现：

• gpt-4-turbo回答最全面，但耗时最长（约 1.8s）；
• claude-3-haiku速度最快（约 0.6s），回答简洁准确；
• ollama/qwen2:7b在本地运行，无网络延迟，但回答稍显简略（约 0.4s）。

这个 playground 不仅是一个玩具，它直接复现了真实产品中的多模型对比测试流程。你可以随时添加新模型（如--model gemini/gemini-1.5-flash），只需一行命令，无需修改任何业务代码。

4.2 生产环境部署：Docker + Nginx + Prometheus 的完整栈

当你的 LiteLLM proxy 从 playground 走向真实用户，就必须考虑高可用、安全、可观测性。下面是一个经过某金融科技公司生产环境验证的部署方案。

架构概览：

用户请求 → Nginx (SSL Termination + Rate Limiting) → LiteLLM Proxy (Docker Container, Multi-Replica) → 后端模型服务 (OpenAI, Anthropic, Ollama Cluster) ← Prometheus (Metrics Scraping) + Grafana (Dashboard)

Docker Compose 部署：
创建docker-compose.yml：

version: '3.8' services: litellm-proxy: image: ghcr.io/berriai/litellm:latest ports: - "4000:4000" environment: - LITELLM_LOG_LEVEL=INFO - LITELLM_MODEL_LIST=[{"model_name":"gpt-4-turbo","litellm_params":{"model":"gpt-4-turbo","api_key":"${OPENAI_API_KEY}"}},{"model_name":"claude-3-haiku","litellm_params":{"model":"claude-3-haiku-20240307","api_key":"${ANTHROPIC_API_KEY}"}}] - LITELLM_PORT=4000 - LITELLM_PROXY_CONFIG_PATH=/app/config.yaml volumes: - ./config.yaml:/app/config.yaml - ./logs:/app/logs deploy: replicas: 3 # 三副本，防止单点故障 restart_policy: condition: on-failure resources: limits: memory: 2G cpus: '1.0' nginx: image: nginx:alpine ports: - "443:443" - "80:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./ssl:/etc/nginx/ssl depends_on: - litellm-proxy prometheus: image: prom/prometheus:latest ports: - "9090:9090" volumes: - ./prometheus.yml:/etc/prometheus/prometheus.yml

关键配置文件：

• config.yaml（LiteLLM 高级配置）：

  model_list: - model_name: gpt-4-turbo litellm_params: model: gpt-4-turbo api_key: ${OPENAI_API_KEY} api_base: https://api.openai.com/v1 max_retries: 2 timeout: 60 - model_name: claude-3-haiku litellm_params: model: claude-3-haiku-20240307 api_key: ${ANTHROPIC_API_KEY} max_retries: 2 timeout: 60 general_settings: # 全局限流：每个 API KEY 每分钟最多 100 次请求 rpm: 100 tpm: 100000 # 每分钟总 token 数限制

• nginx.conf（安全与性能）：

  events { worker_connections 1024; } http { upstream litellm_backend { least_conn; server litellm-proxy:4000; server litellm-proxy:4000; server litellm-proxy:4000; } server { listen 443 ssl; ssl_certificate /etc/nginx/ssl/fullchain.pem; ssl_certificate_key /etc/nginx/ssl/privkey.pem; location / { 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; # 关键：传递原始 client IP，用于 LiteLLM 的 IP-based rate limiting proxy_set_header X-Forwarded-Proto $scheme; # 限流：每个 IP 每分钟最多 10 次 limit_req zone=ip_limit burst=5 nodelay; } } limit_req_zone $binary_remote_addr zone=ip_limit:10m rate=10r/m; }

Prometheus 监控：
LiteLLM 内置/metrics端点，暴露了丰富的指标：

• litellm_request_total{model="gpt-4-turbo",status_code="200"}：成功请求数
• litellm_request_duration_seconds_bucket{model="gpt-4-turbo",le="2.0"}：耗时分布
• litellm_token_usage_total{model="gpt-4-turbo",type="prompt"}：输入 token 总数

在prometheus.yml中添加 job：

scrape_configs: - job_name: 'litellm' static_configs: - targets: ['litellm-proxy:4000']

然后用 Grafana 导入官方 LiteLLM Dashboard（ID: 18222），你就能实时看到：

• 各模型的 QPS、P95 延迟、错误率；
• 每个 API KEY 的调用量排名；
• Token 消耗的 TOP 10 用户；
• Fallback 的触发频率（监控litellm_fallback_total）。

这套栈的部署成本极低：一台 8C16G 的云服务器，就能支撑日均 50 万次请求。关键是，它把原本需要数周开发的“AI 网关”功能，压缩到了一个docker-compose up -d命令里。

4.3 高级技巧：自定义 Adapter 与私有模型接入

当 LiteLLM 官方尚未支持某个新模型，或者你需要对接公司内部的私有模型 API 时，编写自定义 Adapter 就成了必备技能。这个过程并不神秘，核心就是实现两个方法。以下是一个对接某国产大模型（假设 API 为