我见过很多团队一开始只是把 OpenAI Key 写进项目里，后来模型越接越多，账单也越来越乱。
一个接口调 OpenAI，一个接口调 Claude，一个接口调 Gemini，还有人临时加 DeepSeek、OpenRouter、Azure OpenAI。最后代码里到处是 API Key，哪个项目花了多少钱也说不清。
LiteLLM 解决的就是这个问题。
它可以把一堆模型供应商统一成 OpenAI 兼容接口。你的应用只需要请求一个地址，比如：
https://llm.example.com/v1/chat/completions
后面到底转发给 OpenAI、Claude、Gemini、DeepSeek，还是多个 Key 轮询，交给 LiteLLM 管。
这篇按 VPS 自托管来写：怎么用 Docker Compose 跑起来，怎么配置 config.yaml，怎么做虚拟 Key、预算控制、HTTPS、备份，以及它和 One-API / New-API 到底有什么区别。
如果你只是自己用一个 OpenAI Key，LiteLLM 可能有点多余。
但只要出现下面几种情况，它就很有价值：
| 场景 | 为什么适合 LiteLLM |
|---|---|
| 一个项目要接多个模型 | 统一成 OpenAI 格式，代码少改 |
| 团队共用模型 API | 给每个人发虚拟 Key，方便控制预算 |
| 想做 fallback | 一个模型挂了自动切另一个 |
| 想统计花费 | 按 Key、用户、模型看消耗 |
| 想统一入口 | 只暴露一个 API 网关地址 |
我自己的判断很简单：
- 个人单 Key 使用：没必要
- 多项目、多模型、多成员：很有必要
- 想做内部 AI API 平台：值得部署
它不是聊天界面，也不是 AI 应用平台。它更像一个 LLM API 网关。
LiteLLM 本身不重，真正占资源的是 PostgreSQL、Prometheus、请求并发和日志量。
| 用法 | VPS 配置建议 |
|---|---|
| 个人测试 | 1 核 / 1GB / 20GB SSD |
| 小团队共用 | 2 核 / 4GB / 40GB SSD |
| 多项目生产使用 | 4 核 / 8GB / 80GB SSD |
如果只是做代理，不跑本地模型，2C4G 基本够用。
别把它和 Ollama 混在一起算资源。LiteLLM 是转发网关，不负责本地推理。你接的是 OpenAI、DeepSeek、Claude 这些远程 API，它自己的 CPU 压力不大。
别急着复制 Compose。
LiteLLM 有三个东西一开始就要定好：
LITELLM_MASTER_KEYLITELLM_SALT_KEYconfig.yaml里的模型命名规则
MASTER_KEY 是管理员钥匙，必须以 sk- 开头。
SALT_KEY 更重要，它用来加密数据库里的模型 API Key。官方文档也提醒过：添加模型后不要随便改这个值。你改了，旧的加密凭据可能就解不开了。
所以不要写：
LITELLM_SALT_KEY=sk-1234
应该生成一个长一点的随机值：
openssl rand -hex 32
然后写进 .env。
这篇用 Ubuntu / Debian 举例。
apt update && apt upgrade -y
apt install -y ca-certificates curl gnupg ufw nano
安装 Docker：
install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | gpg --dearmor -o /etc/apt/keyrings/docker.gpg
chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" > /etc/apt/sources.list.d/docker.list
apt update
apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
确认一下：
docker --version
docker compose version
mkdir -p /opt/litellm
cd /opt/litellm
生成两个 Key：
echo "sk-$(openssl rand -hex 32)"
echo "sk-$(openssl rand -hex 32)"
一个给 LITELLM_MASTER_KEY，一个给 LITELLM_SALT_KEY。
创建 .env：
cat > .env << 'EOF'
LITELLM_MASTER_KEY="sk-replace-with-master-key"
LITELLM_SALT_KEY="sk-replace-with-long-salt-key"
OPENAI_API_KEY="sk-replace-with-openai-key"
DEEPSEEK_API_KEY="replace-with-deepseek-key"
POSTGRES_PASSWORD="replace-with-postgres-password"
EOF
如果暂时不用 OpenAI 或 DeepSeek，可以先留空，但 MASTER_KEY 和 SALT_KEY 一定要认真填。
config.yaml 是 LiteLLM 的核心。
它决定了：
- 外部看到的模型名叫什么
- 实际转发到哪个供应商
- API Key 从哪里读取
- 数据库和后台设置怎么配
创建文件：
nano config.yaml
写入一个最小可用版本：
model_list:
- model_name: gpt-4o-mini
litellm_params:
model: openai/gpt-4o-mini
api_key: os.environ/OPENAI_API_KEY
- model_name: deepseek-chat
litellm_params:
model: deepseek/deepseek-chat
api_key: os.environ/DEEPSEEK_API_KEY
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
database_url: "postgresql://litellm:${POSTGRES_PASSWORD}@db:5432/litellm"
store_model_in_db: true
litellm_settings:
request_timeout: 600
set_verbose: false
json_logs: true
这里最容易搞混的是：
model_name: gpt-4o-mini
这是你对外暴露的名字。
model: openai/gpt-4o-mini
这是 LiteLLM 内部识别的供应商和模型。
也就是说，你可以对外统一叫：
company-fast-model
但后面实际接的是 DeepSeek、OpenAI 或别的供应商。
创建 docker-compose.yml：
services:
db:
image: postgres:16
container_name: litellm-db
restart: unless-stopped
environment:
POSTGRES_DB: litellm
POSTGRES_USER: litellm
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
volumes:
- ./postgres-data:/var/lib/postgresql/data
ports:
- "127.0.0.1:5432:5432"
healthcheck:
test: ["CMD-SHELL", "pg_isready -U litellm -d litellm"]
interval: 10s
timeout: 5s
retries: 5
litellm:
image: ghcr.io/berriai/litellm-database:main-stable
container_name: litellm
restart: unless-stopped
depends_on:
db:
condition: service_healthy
env_file:
- .env
volumes:
- ./config.yaml:/app/config.yaml:ro
command: ["--config", "/app/config.yaml", "--port", "4000"]
ports:
- "127.0.0.1:4000:4000"
注意我把 4000 和 5432 都绑定到了 127.0.0.1。
很多示例为了方便，会把服务直接暴露到公网。生产环境别这么干。LiteLLM 后面放 Caddy 或 Nginx，数据库更不要直接暴露。
启动：
docker compose up -d
看状态：
docker compose ps
docker logs litellm --tail=100
本机测试：
curl http://127.0.0.1:4000/health
如果健康检查正常，就可以继续配 HTTPS。
假设域名是：
llm.example.com
DNS 里添加 A 记录指向你的 VPS IP。
安装 Caddy：
apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' > /etc/apt/sources.list.d/caddy-stable.list
apt update
apt install -y caddy
编辑配置：
nano /etc/caddy/Caddyfile
写入：
llm.example.com {
reverse_proxy 127.0.0.1:4000
}
检查并重载：
caddy validate --config /etc/caddy/Caddyfile
systemctl reload caddy
浏览器访问：
https://llm.example.com/ui
用你的 LITELLM_MASTER_KEY 登录管理后台。
只开放 SSH、80、443：
ufw allow 22/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable
ufw status
不要开放 4000 和 5432：
ufw deny 4000/tcp
ufw deny 5432/tcp
如果你要给内网系统调用，建议用 Tailscale、WireGuard 或 Cloudflare Tunnel，不要把管理后台裸奔到公网。
用 OpenAI 兼容格式请求 LiteLLM：
curl https://llm.example.com/v1/chat/completions \
-H "Authorization: Bearer sk-your-master-key" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4o-mini",
"messages": [
{"role": "user", "content": "用一句话解释什么是 VPS"}
]
}'
如果你想测试 DeepSeek：
curl https://llm.example.com/v1/chat/completions \
-H "Authorization: Bearer sk-your-master-key" \
-H "Content-Type: application/json" \
-d '{
"model": "deepseek-chat",
"messages": [
{"role": "user", "content": "给我一个 Docker Compose 备份建议"}
]
}'
只要应用本来支持 OpenAI API，大多数情况下把 base_url 改成你的 LiteLLM 地址就能用。
例如：
OPENAI_BASE_URL=https://llm.example.com/v1
OPENAI_API_KEY=sk-your-virtual-key-or-master-key
真正让 LiteLLM 有价值的不是代理转发，而是虚拟 Key。
你可以给不同项目发不同 Key：
project-docs-botproject-customer-supportdeveloper-testmarketing-agent
每个 Key 单独设置：
- 可用模型
- 每分钟请求数
- 每月预算
- 到期时间
- 使用记录
这样比把真实 OpenAI Key 发给所有人安全得多。
实际用的时候，我会这样分：
| Key | 用途 | 限制 |
|---|---|---|
| dev-test | 开发调试 | 小预算、低 RPM |
| prod-api | 线上服务 | 高预算、只给后端用 |
| data-script | 批处理脚本 | 限模型、限并发 |
| demo | 临时演示 | 1 天过期 |
出了问题也好查：到底是谁把钱花完了，哪个项目请求量异常，直接看 Key 维度就行。
如果只是个人用，可以先不加 Prometheus。
如果团队共用，建议加上，因为你迟早会想知道：
- 请求量多少
- 哪个模型最常用
- 延迟高不高
- 是否频繁报错
LiteLLM 官方示例里会用 prometheus.yml，这里有个坑：这个文件必须是真文件。
如果你直接在 Compose 里挂载：
- ./prometheus.yml:/etc/prometheus/prometheus.yml
但本地没有这个文件，Docker 可能会把它当目录创建，Prometheus 就起不来。
先创建：
cat > prometheus.yml << 'EOF'
global:
scrape_interval: 15s
scrape_configs:
- job_name: "litellm"
static_configs:
- targets: ["litellm:4000"]
EOF
然后再扩展 Compose。不要把 Prometheus 面板直接暴露公网，至少也要加 Basic Auth 或只允许内网访问。
至少备三样：
/opt/litellm/.env
/opt/litellm/config.yaml
/opt/litellm/postgres-data
.env 里有密钥，不要随便放进 GitHub。
config.yaml 可以进私有 Git 仓库，但里面不要硬编码真实 API Key，尽量用：
api_key: os.environ/OPENAI_API_KEY
PostgreSQL 备份可以这样做：
cd /opt/litellm
docker exec litellm-db pg_dump -U litellm litellm | gzip > litellm-db-$(date +%F).sql.gz
再把备份同步到对象存储：
rclone copy litellm-db-$(date +%F).sql.gz r2:backup-bucket/litellm/
如果只备份 Compose，不备数据库，虚拟 Key、预算记录、使用统计都会丢。
升级前先备份：
cd /opt/litellm
docker exec litellm-db pg_dump -U litellm litellm | gzip > litellm-before-upgrade-$(date +%F).sql.gz
cp config.yaml config.yaml.bak.$(date +%F)
cp .env .env.bak.$(date +%F)
然后拉新镜像：
docker compose pull
docker compose up -d
看日志：
docker logs litellm --tail=200
LiteLLM 会涉及数据库迁移。生产环境别在高峰期升级，先在测试机验证一遍更稳。
LiteLLM 对 master key 有格式要求。
不要写：
LITELLM_MASTER_KEY="my-password"
写成：
LITELLM_MASTER_KEY="sk-xxxxxxxx"
LITELLM_SALT_KEY 用来加密和解密凭据。
加了模型、创建了 Key 之后，不要随手换。换之前先确认你知道怎么恢复，否则数据库里的加密内容可能解不开。
看到 Compose 里有：
ports:
- "5432:5432"
我建议改成：
ports:
- "127.0.0.1:5432:5432"
或者干脆不映射给宿主机，只让 Docker 网络内部访问。
请求里用的是 model_name，不是 litellm_params.model。
如果配置是：
model_name: deepseek-chat
litellm_params:
model: deepseek/deepseek-chat
那请求时写：
"model": "deepseek-chat"
不是：
"model": "deepseek/deepseek-chat"
启动前先确认：
ls -lah prometheus.yml
它应该是一个文件，不是目录。
如果已经变成目录：
rm -rf prometheus.yml
nano prometheus.yml
再重启。
这几个工具会被放在一起比较。
| 工具 | 更适合 |
|---|---|
| One-API / New-API | 面向用户分发、渠道管理、面板化运营 |
| LiteLLM | 面向开发团队、统一 SDK/API、路由和预算控制 |
| OpenRouter | 不想自建，直接用托管聚合服务 |
如果你是站长，想给用户开 Key、做渠道、看余额，New-API 更像成品面板。
如果你是开发团队，想让内部项目统一走一个 OpenAI 兼容入口，LiteLLM 更顺手。
它俩不是完全替代关系。你也可以让 LiteLLM 接上游 New-API，或者让内部应用都走 LiteLLM，再由 LiteLLM 做 fallback 和预算控制。
如果是我自己给小团队部署 LiteLLM，我会这样来：
- VPS：2 核 4GB 起步
- 部署：Docker Compose + PostgreSQL
- 入口：Caddy HTTPS
- 端口：4000 只监听 127.0.0.1
- 数据库：不暴露公网
- Key：每个项目一个虚拟 Key
- 预算：开发 Key 小预算，生产 Key 单独限额
- 配置：
config.yaml放私有仓库，真实 API Key 放.env - 备份：每天备份 PostgreSQL、
.env和config.yaml
LiteLLM 最适合的不是“我想搭一个聊天网站”，而是“我有多个应用要调用多个模型，但不想每个应用都管一套 API Key 和模型适配”。
当模型供应商越来越多，统一入口会越来越省事。你现在花半小时把网关搭好，后面换模型、加预算、查账单，会少很多麻烦。