VPS 搭建 LiteLLM 教程：统一 LLM API 网关 | 2026

我见过很多团队一开始只是把 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 到底有什么区别。

LiteLLM 适合什么场景

如果你只是自己用一个 OpenAI Key，LiteLLM 可能有点多余。

但只要出现下面几种情况，它就很有价值：

场景	为什么适合 LiteLLM
一个项目要接多个模型	统一成 OpenAI 格式，代码少改
团队共用模型 API	给每个人发虚拟 Key，方便控制预算
想做 fallback	一个模型挂了自动切另一个
想统计花费	按 Key、用户、模型看消耗
想统一入口	只暴露一个 API 网关地址

我自己的判断很简单：

个人单 Key 使用：没必要
多项目、多模型、多成员：很有必要
想做内部 AI API 平台：值得部署

它不是聊天界面，也不是 AI 应用平台。它更像一个 LLM API 网关。

VPS 配置怎么选

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_KEY
LITELLM_SALT_KEY
config.yaml 里的模型命名规则

MASTER_KEY 是管理员钥匙，必须以 sk- 开头。

SALT_KEY 更重要，它用来加密数据库里的模型 API Key。官方文档也提醒过：添加模型后不要随便改这个值。你改了，旧的加密凭据可能就解不开了。

所以不要写：

LITELLM_SALT_KEY=sk-1234

应该生成一个长一点的随机值：

openssl rand -hex 32

然后写进 .env。

安装 Docker

这篇用 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

创建 LiteLLM 目录

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

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 部署

创建 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。

配 Caddy 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，不要把管理后台裸奔到公网。

用 curl 测试模型调用

用 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

虚拟 Key 和预算控制怎么用

真正让 LiteLLM 有价值的不是代理转发，而是虚拟 Key。

你可以给不同项目发不同 Key：

project-docs-bot
project-customer-support
developer-test
marketing-agent

每个 Key 单独设置：

可用模型
每分钟请求数
每月预算
到期时间
使用记录

这样比把真实 OpenAI Key 发给所有人安全得多。

实际用的时候，我会这样分：

Key	用途	限制
dev-test	开发调试	小预算、低 RPM
prod-api	线上服务	高预算、只给后端用
data-script	批处理脚本	限模型、限并发
demo	临时演示	1 天过期

出了问题也好查：到底是谁把钱花完了，哪个项目请求量异常，直接看 Key 维度就行。

加 Prometheus 监控

如果只是个人用，可以先不加 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 会涉及数据库迁移。生产环境别在高峰期升级，先在测试机验证一遍更稳。

常见坑

1. Master Key 不以 sk- 开头

LiteLLM 对 master key 有格式要求。

不要写：

LITELLM_MASTER_KEY="my-password"

写成：

LITELLM_MASTER_KEY="sk-xxxxxxxx"

2. Salt Key 后面改了

LITELLM_SALT_KEY 用来加密和解密凭据。

加了模型、创建了 Key 之后，不要随手换。换之前先确认你知道怎么恢复，否则数据库里的加密内容可能解不开。

3. PostgreSQL 暴露到公网

看到 Compose 里有：

ports:
  - "5432:5432"

我建议改成：

ports:
  - "127.0.0.1:5432:5432"

或者干脆不映射给宿主机，只让 Docker 网络内部访问。

4. config.yaml 模型名写错

请求里用的是 model_name，不是 litellm_params.model。

如果配置是：

model_name: deepseek-chat
litellm_params:
  model: deepseek/deepseek-chat

那请求时写：

"model": "deepseek-chat"

不是：

"model": "deepseek/deepseek-chat"

5. Prometheus 挂载文件变目录

启动前先确认：

ls -lah prometheus.yml

它应该是一个文件，不是目录。

如果已经变成目录：

rm -rf prometheus.yml
nano prometheus.yml

再重启。

LiteLLM 和 One-API / New-API 怎么选

这几个工具会被放在一起比较。

工具	更适合
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 和模型适配”。

当模型供应商越来越多，统一入口会越来越省事。你现在花半小时把网关搭好，后面换模型、加预算、查账单，会少很多麻烦。

场景

为什么适合 LiteLLM

一个项目要接多个模型

统一成 OpenAI 格式，代码少改

团队共用模型 API

给每个人发虚拟 Key，方便控制预算

想做 fallback

一个模型挂了自动切另一个

想统计花费

按 Key、用户、模型看消耗

想统一入口

只暴露一个 API 网关地址

用法

VPS 配置建议

个人测试

1 核 / 1GB / 20GB SSD

小团队共用

2 核 / 4GB / 40GB SSD

多项目生产使用

4 核 / 8GB / 80GB SSD

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

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

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

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"

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

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"} ] }'

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 备份建议"} ] }'

Key

用途

限制

dev-test

开发调试

小预算、低 RPM

prod-api

线上服务

高预算、只给后端用

data-script

批处理脚本

限模型、限并发

demo

临时演示

1 天过期

工具

更适合

One-API / New-API

面向用户分发、渠道管理、面板化运营

LiteLLM

面向开发团队、统一 SDK/API、路由和预算控制

OpenRouter

不想自建，直接用托管聚合服务

LiteLLM 适合什么场景

VPS 配置怎么选

部署前先想清楚这三件事

安装 Docker

创建 LiteLLM 目录

写 config.yaml

Docker Compose 部署

配 Caddy HTTPS

防火墙怎么开

用 curl 测试模型调用

虚拟 Key 和预算控制怎么用

加 Prometheus 监控

备份要备什么

升级怎么做

常见坑

1. Master Key 不以 sk- 开头

2. Salt Key 后面改了

3. PostgreSQL 暴露到公网

4. config.yaml 模型名写错

5. Prometheus 挂载文件变目录

LiteLLM 和 One-API / New-API 怎么选

我会怎么部署

Loading...

LiteLLM 适合什么场景

VPS 配置怎么选

部署前先想清楚这三件事

安装 Docker

创建 LiteLLM 目录

写 config.yaml

Docker Compose 部署

配 Caddy HTTPS

防火墙怎么开

用 curl 测试模型调用

虚拟 Key 和预算控制怎么用

加 Prometheus 监控

备份要备什么

升级怎么做

常见坑

1. Master Key 不以 sk- 开头

2. Salt Key 后面改了

3. PostgreSQL 暴露到公网

4. config.yaml 模型名写错

5. Prometheus 挂载文件变目录

LiteLLM 和 One-API / New-API 怎么选

我会怎么部署