Apr 15, 2026

技术热点落地：LiteLLM 自托管代理 — LLM 模型路由与成本监控实战（2026-04-15）

适用场景与目标

2026 年，AI 推理成本已成为工程团队的必修课。多模型供应商（OpenAI、Anthropic、Azure OpenAI、Claude、本地模型）并行使用、token 消耗不透明、供应商锁定风险——这些问题在中型以上团队中几乎普遍存在。

LiteLLM 是一个开源的 LLM 自托管代理（proxy），用同一套 API 接口对接 100+ LLM 供应商，同时提供内置的 token 级成本追踪、日志记录和模型路由能力。

适合场景：

多模型并行使用，需要统一调用入口
需要在多个供应商之间做成本比较和动态路由
对数据主权有要求，必须自托管但不想放弃多模型能力
需要在组织内部共享 LLM 调用能力

不适合场景：

只需要调用单个模型的简单场景（直接用官方 SDK 更轻量）
对延迟极度敏感的生产路径（proxy 层会带来额外 ~20-50ms 开销）
完全没有运维能力的团队（需要维护 Docker/K8s 环境）

最小可行方案（MVP）步骤

环境准备

# 推荐使用 Docker（避免依赖冲突）
docker --version   # 确保 Docker 已安装

# 创建工作目录
mkdir litellm-setup && cd litellm-setup

第一步：安装 LiteLLM

# 方式一：pip 安装（适合轻量场景）
pip install litellm

# 方式二：Docker 部署（推荐生产使用）
docker pull ghcr.io/berriai/litellm:main

第二步：配置模型供应商密钥

创建 config.yaml：

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: claude-3-5-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: deepseek-chat
    litellm_params:
      model: deepseek/deepseek-chat-v3-0324
      api_key: os.environ/DEEPSEEK_API_KEY
      api_base: https://api.deepseek.com/v1

  - model_name: qwen-3.5
    litellm_params:
      model: qwen/qwen-3.5-72b-instruct
      api_base: https://dashscope.aliyuncs.com/compatible-mode/v1
      api_key: os.environ/DASHSCOPE_API_KEY

litellm_settings:
  drop_params: true
  set_verbose: true

关键建议： 所有密钥使用环境变量注入，不要硬编码在配置文件中。

第三步：启动代理

# Docker 启动
docker run \
  -v $(pwd)/config.yaml:/app/config.yaml \
  -e OPENAI_API_KEY \
  -e ANTHROPIC_API_KEY \
  -e DEEPSEEK_API_KEY \
  -e DASHSCOPE_API_KEY \
  -p 4000:4000 \
  ghcr.io/berriai/litellm:main

代理默认在 http://localhost:4000 运行。

第四步：验证调用

curl http://localhost:4000/v1/models   # 查看可用模型

curl -X POST http://localhost:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "你好，返回 JSON 格式"}]
  }'

第五步：开启成本追踪（可选，推荐开启）

LiteLLM 支持将每次调用的 token 消耗记录到数据库，便于成本分析：

# 使用 SQLite 本地存储（MVP 推荐）
export LITELLM_DATABASE_URL: "sqlite:///litellm.db"

# 或使用 Postgres（生产推荐）
export LITELLM_DATABASE_URL: "postgresql://user:pass@host/litellm"

开启后，每次调用会自动记录：

模型名称
输入/输出 token 数
预估成本（美元）
延迟（ms）
请求时间

关键实现细节

模型路由（Fallback & Load Balancing）

LiteLLM 支持在配置中定义多个模型，同一请求可设置自动降级：

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
    model_info:
      mode: chat

  - model_name: gpt-4o-mini
    litellm_params:
      model: openai/gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY
    model_info:
      mode: chat

  - model_name: deepseek-chat
    litellm_params:
      model: deepseek/deepseek-chat-v3-0324
      api_key: os.environ/DEEPSEEK_API_KEY
      api_base: https://api.deepseek.com/v1
    model_info:
      mode: chat

router_settings:
  retry_policy: {"gpt-4o": 3, "deepseek-chat": 2}
  allowed_fails: 3  # 连续失败次数后自动切换

同一对话格式调用不同模型（多供应商 API 统一入口）

这是 LiteLLM 最有价值的特性——一套代码，切换任意模型：

import os
os.environ["OPENAI_API_KEY"] = "your-key"

# 用 openai SDK 格式，target 模型名任意切换
from openai import OpenAI

client = OpenAI(
    api_key="anything",  # 实际密钥在 LiteLLM 配置中管理
    base_url="http://localhost:4000"  # LiteLLM 代理地址
)

# 调用 GPT-4o
response = client.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user", "content": "解释什么是 MoE 架构"}]
)
print(response.choices[0].message.content)

# 一行切换到 DeepSeek（成本约为 GPT-4o 的 1/10）
response = client.chat.completions.create(
    model="deepseek-chat",
    messages=[{"role": "user", "content": "解释什么是 MoE 架构"}]
)

OpenAI 兼容 endpoint 映射

# 原有 OpenAI 代码，无需修改即可接入 LiteLLM
OPENAI_BASE_URL=http://localhost:4000/v1

这意味着 LangChain、LlamaIndex、RAG 应用等主流框架可以零代码改动接入。

常见坑与规避清单

坑	说明	规避方法
密钥未设环境变量	config.yaml 中硬编码密钥被提交到 Git	始终使用 `os.environ/KEY_NAME` 语法
API Base URL 遗漏	国内模型（DeepSeek、Qwen）必须配置 `api_base`，否则默认走 OpenAI	逐个确认每个供应商的 endpoint
403/401 报错	通常是模型名拼写错误（如 `gpt-4` 而非 `gpt-4o`）	用 `/v1/models` 端点先验证所有模型可用性
代理延迟影响交互	LiteLLM 会增加 ~20-50ms 延迟	对实时性要求高的场景，直接走官方 SDK，LiteLLM 用于非关键路径
成本追踪漏记	SQLite 不支持并发写入，高并发下数据丢失	生产环境使用 Postgres + 连接池
config.yaml 语法错误	litellm_params 的 YAML 嵌套容易出错	用 `litellm --config /path/to/config.yaml --test` 先测试配置
模型属地合规	DeepSeek、Qwen 等模型的 API 可能不符合部分企业的数据合规要求	确认内部合规要求后再接入
并发限制未配置	大量请求时未设置 `rpm`（每分钟请求数）限制导致账户被限流	在 router_settings 中配置 `rpm_limit_per_model`

成本/性能/维护权衡

成本维度

LiteLLM 本身免费（开源），成本来自两个方面：

自托管的计算成本：代理层约占用 512MB-1GB 内存，单核 CPU 足够。自己的服务器约 $5-20/月。
供应商 API 成本：LiteLLM 不降低 API 费用本身，但通过路由到更便宜的模型实现节省。

实测节省效果（以日均 10 万 token 对话为例）：

纯 GPT-4o：约 $6/天 → $180/月
简单问题路由到 GPT-4o-mini，复杂问题路由到 GPT-4o：约节省 40-60%

性能维度

延迟增加：代理层额外 ~20-50ms P99
吞吐：LiteLLM 支持异步并发，单实例 QPS 可达 200-500（取决于下游模型响应速度）
扩展：水平扩展通过 K8s Deployment 多副本 + 负载均衡实现

维护维度

更新频率：LiteLLM 活跃开发，约每 2 周一个版本，需定期更新
日志管理：生产环境建议对接 S3 或 Loki，避免本地磁盘爆满
监控接入：可与 Langfuse、Opik 等可观测性工具集成

一周内可执行行动清单

Day 1：本地环境搭建

安装 Docker，拉取 LiteLLM 镜像
创建 config.yaml，配置 2-3 个已持有密钥的模型
启动服务，验证 /v1/models 和一个 chat completions 调用成功

Day 2-3：成本追踪与路由测试

开启 SQLite 成本追踪，运行一天的真实流量
配置 simple streaming fallback（一个模型失败时自动切换）
用 Python 脚本对比不同模型对同一问题的回答质量与成本

Day 4-5：接入现有应用

选定一个 RAG 或 Agent 项目，将 API base URL 指向本地 LiteLLM
验证所有原有功能正常，观察延迟变化
接入 Langfuse（或自建），观察 token 消耗分布

Day 6-7：生产化准备

将 SQLite 替换为 Postgres（如果并发 > 50 QPS）
配置日志收集（推荐 Loki + Grafana）
编写团队接入文档：如何使用统一 API 调用不同模型
评估是否需要 Docker Compose 或 K8s 部署

参考资源

LiteLLM 官方文档：https://docs.litellm.ai
GitHub 仓库：https://github.com/BerriAI/litellm
模型供应商完整列表：https://docs.litellm.ai/docs/providers
Langfuse 集成指南：https://langfuse.com/docs

LiteLLM 解决了 AI 工程中”供应商碎片化”这个真实痛点。一周内可以完成从零到稳定运行，是目前 AI 工程化落地性价比最高的工具之一。