LiteLLM Proxy 是什么
LiteLLM Proxy 提供统一的 OpenAI 兼容入口：一份 YAML 把多个上游（自托管推理引擎、云厂商 API）映射成对外模型别名，并附带密钥管理、配额、负载均衡与日志钩子。它的价值在于把「换模型」从改代码变成改配置，同时把多后端之间的差异收拢到一个网关里。
基本信息
| 角色 | 统一 OpenAI 兼容入口 |
|---|---|
| 配置文件 | YAML 声明模型与上游 |
| 上游类型 | 自托管引擎、云 API |
| 附带能力 | 密钥、配额、负载均衡、日志 |
| 部署形态 | 按无状态服务部署 |
典型使用场景
- 业务代码只认一个入口与模型别名
- 把云 API 与自建引擎放在同一入口下做灰度
- 集中管理上游密钥，不落进业务代码
- 按调用方标识做配额与用量统计
- 把网关自身的指标接入监控，便于区分「网关问题」与「上游问题」
配置骨架
配置骨架
model_list:
- model_name: local-8b # 对外模型名
litellm_params:
model: openai/<上游模型名>
api_base: http://127.0.0.1:8000/v1
api_key: os.environ/LOCAL_KEY
# 启动：litellm --config config.yaml --port 4000配置里各管什么
| 层级 | 关注点 | 说明 |
|---|---|---|
| 模型别名 | 对外稳定命名 | 换上游不改业务 |
| 上游配置 | 地址与密钥 | 密钥从环境变量取 |
| 配额 | 按标识计量 | 需要持久化计费数据 |
| 网关自身 | 高可用 | 多副本加探活 |
网关自身要按无状态服务部署：多副本、探活与配置版本化一起配，避免它变成整个系统的单点。
别名与上游的映射关系要写进文档：出问题时第一件事是确认这个请求最终打到了哪个上游。
多上游时给每个上游单独设置超时与重试次数：云 API 与自建引擎的合理区间差别很大，用一套值必然有一边不合适。
配置变更要走版本管理：改错一行就能让所有模型不可用，回滚必须足够快，所以旧版本要随时可取。