
LiteLLM Proxy:單一 API 接入 100+ LLM(15 分鐘 Docker 部署)
你的團隊正在 Slack 私訊中共享 OpenAI API 金鑰。沒人知道上週二誰花掉了 400 美元。沒有速率限制,當服務供應商宕機時沒有備援機制,而從 GPT-4o 切換到 Claude 意味著要在十二個地方修改程式碼。聽起來很熟悉嗎?自託管 LLM 閘道器可以解決所有這些問題,而 LiteLLM Proxy 是最受歡迎的開源選項,它提供一個單一的 OpenAI 相容端點,將請求路由到 100 多個 LLM 供應商。
本指南涵蓋完整的 litellm proxy 設定:使用 Docker Compose 搭配 PostgreSQL、具備預算控制的虛擬團隊金鑰、成本追蹤、速率限制,以及連接如 Claude Code 和 Cursor 等 AI IDE。如果你正在評估 LLM 閘道器工具,這是一份從零開始到生產環境的實戰教程。
在開始之前有一個重要說明:LiteLLM 的 SDK(Python 函式庫)與 Proxy Server 是不同的東西。SDK 適用於單一開發人員從 Python 呼叫多個 LLM API。Proxy 則適用於團隊,它作為伺服器位於你的應用程式與 LLM 供應商之間。如果你是獨自撰寫腳本的開發人員,SDK 就足夠了。但如果你需要為團隊管理金鑰、預算和存取權限,你需要的是 Proxy。這正是我們在此要設定的內容。
LiteLLM Proxy 概覽
| 屬性 | 詳細資訊 |
|---|---|
| 它是什麼 | 支援 100+ LLM 供應商的 OpenAI 相容 Proxy 伺服器 |
| 適用對象 | 需要管理多個 LLM API 金鑰、預算和存取權限的團隊 |
| 授權條款 | MIT(開源) |
| GitHub Stars | 20,000+ |
| 支援供應商 | OpenAI, Anthropic, Azure, AWS Bedrock, Google Vertex, Ollama 等 100+ 家 |
| 核心功能 | 虛擬金鑰、成本追蹤、速率限制、模型備援、負載平衡 |
| 設定方式 | Docker, Docker Compose, pip, Kubernetes/Helm |
| 最新穩定版本 | v1.83+(避免使用 1.82.7 和 1.82.8 -- 請參閱疑難排解) |
| 設定檔格式 | config.yaml |
| 儀表板 | 內建 UI,用於監控成本和用量 |
以下是各種部署方式的比較:
| 方式 | 複雜度 | 最適合 | 設定時間 |
|---|---|---|---|
docker run | 低 | 快速測試、個人開發 | 60 秒 |
| Docker Compose + Postgres | 中 | 團隊(2-50 人) | 10-15 分鐘 |
| Kubernetes / Helm | 高 | 企業級、自動擴縮 | 30-60 分鐘 |
| pip install | 低 | 僅限本地開發 | 5 分鐘 |
對大多數團隊而言,Docker Compose 搭配 PostgreSQL 是最佳選擇。我們將以此為目標進行建構,但首先,讓我們在 60 秒內啟動一個 Proxy。
先決條件與環境設定
在開始之前,請確保你擁有:
- 已安裝 Docker 和 Docker Compose(Docker Desktop 已包含兩者)
- 至少一個 LLM API 金鑰(OpenAI、Anthropic 或本地 Ollama 实例)
- 基本的終端機 / CLI 操作知識
驗證 Docker 是否就緒並匯出你的 API 金鑰:
# Check Docker is installed
docker --version
docker compose version
# Export your LLM API keys (add to your shell profile for persistence)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."
# Optional: set a master key for your proxy (you'll need this later)
export LITELLM_MASTER_KEY="sk-master-your-secret-key"就是這麼簡單。不需要特定的 Python 版本,也不需要作業系統專屬的工具。只要你的機器能運行 Docker,你就準備好了。
快速開始,60 秒內啟動你的第一個 LiteLLM Proxy
只需一個命令即可啟動帶有 GPT-4o 的 Proxy:
docker run -d \
--name litellm-proxy \
-p 4000:4000 \
-e OPENAI_API_KEY=$OPENAI_API_KEY \
-e LITELLM_MASTER_KEY=$LITELLM_MASTER_KEY \
ghcr.io/berriai/litellm:main-stable \
--model openai/gpt-4o使用 curl 進行測試:
curl http://localhost:4000/v1/chat/completions \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "openai/gpt-4o",
"messages": [{"role": "user", "content": "Say hello from LiteLLM"}]
}'或從 Python 進行測試:
from openai import OpenAI
# Point the standard OpenAI SDK at your proxy
client = OpenAI(
api_key="sk-master-your-secret-key",
base_url="http://localhost:4000/v1"
)
response = client.chat.completions.create(
model="openai/gpt-4o",
messages=[{"role": "user", "content": "Say hello from LiteLLM"}]
)
print(response.choices[0].message.content)剛才發生了什麼事?你的程式碼使用標準的 OpenAI SDK 格式與 localhost:4000 通訊。Proxy 接收請求,使用真實金鑰將其轉發給 OpenAI 的 API,並返回回應。你的應用程式程式碼從未接觸到實際的 API 金鑰。
這就是核心概念。 現在讓我們建構一個生產環境設定。
搭配 PostgreSQL 的生產環境 Docker Compose 設定
單一的 docker run 命令適用於測試,但生產環境團隊需要持久的成本追蹤、虛擬金鑰和適當的資料庫儲存。這意味著需要使用 Docker Compose 搭配 PostgreSQL。
Docker Compose 檔案
# docker-compose.yml
version: "3.9"
services:
litellm:
image: ghcr.io/berriai/litellm:main-stable
container_name: litellm-proxy
ports:
- "4000:4000" # Proxy API port
volumes:
- ./config.yaml:/app/config.yaml # Mount your config file
environment:
- LITELLM_MASTER_KEY=${LITELLM_MASTER_KEY}
- OPENAI_API_KEY=${OPENAI_API_KEY}
- ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
- DATABASE_URL=postgresql://litellm:litellm_password@postgres:5432/litellm
- LITELLM_SALT_KEY=${LITELLM_SALT_KEY:-sk-salt-random-string}
command: --config /app/config.yaml --detailed_debug
depends_on:
postgres:
condition: service_healthy
restart: unless-stopped
postgres:
image: postgres:16-alpine
container_name: litellm-db
environment:
POSTGRES_DB: litellm
POSTGRES_USER: litellm
POSTGRES_PASSWORD: litellm_password
volumes:
- litellm_pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U litellm"]
interval: 5s
timeout: 5s
retries: 5
restart: unless-stopped
volumes:
litellm_pgdata:LITELLM_SALT_KEY 用於加密資料庫中的虛擬金鑰資料。LiteLLM 生產環境最佳實踐文件建議在任何團隊部署中設定此參數。
啟動堆疊
# Create a .env file with your keys (don't commit this to git)
echo "LITELLM_MASTER_KEY=sk-master-your-secret" > .env
echo "OPENAI_API_KEY=sk-..." >> .env
echo "ANTHROPIC_API_KEY=sk-ant-..." >> .env
echo "LITELLM_SALT_KEY=sk-salt-$(openssl rand -hex 16)" >> .env
# Start everything
docker compose up -d
# Check logs
docker compose logs -f litellm驗證一切運作正常
# Health check
curl http://localhost:4000/health
# Test a request
curl http://localhost:4000/v1/chat/completions \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"model": "gpt-4o", "messages": [{"role": "user", "content": "ping"}]}'如果你看到成功的回應,表示你的生產環境堆疊正在運行。PostgreSQL 會在容器重啟之間持久儲存所有成本資料、虛擬金鑰和用量指標。
結論:Docker Compose + PostgreSQL 是推薦的生產環境設定。 它只需約 10 分鐘的工作量,就能提供持久儲存、成本追蹤和虛擬金鑰。如果你日後需要自動擴縮,Docker 部署文件涵蓋了 Kubernetes 和 Helm 的相關資訊。
Config.yaml 詳解,真實的多供應商設定
大多數教程展示的 config.yaml 只包含一個模型。以下是一個真實團隊設定的範例,包含三個供應商、備援機制和負載平衡。
設定檔
# config.yaml -- Real multi-provider setup
model_list:
# Primary: OpenAI GPT-4o
- model_name: gpt-4o # The name YOUR code uses
litellm_params:
model: openai/gpt-4o # The actual provider/model
api_key: os.environ/OPENAI_API_KEY
# Secondary: Anthropic Claude
- model_name: claude-sonnet
litellm_params:
model: anthropic/claude-sonnet-4-20250514
api_key: os.environ/ANTHROPIC_API_KEY
# Local: Ollama for development / cost-free testing
- model_name: local-llama
litellm_params:
model: ollama/llama3.1
api_base: http://host.docker.internal:11434
# Fallback: route "gpt-4o" to Claude if OpenAI is down
- model_name: gpt-4o
litellm_params:
model: anthropic/claude-sonnet-4-20250514
api_key: os.environ/ANTHROPIC_API_KEY
router_settings:
routing_strategy: least-busy # Load balance across same-name models
num_retries: 3
retry_after: 5 # Seconds between retries
fallbacks: [{"gpt-4o": ["claude-sonnet"]}]
general_settings:
master_key: os.environ/LITELLM_MASTER_KEY
database_url: os.environ/DATABASE_URL模型別名與路由
請注意,gpt-4o 在設定檔中出現了兩次,一次指向 OpenAI,一次指向 Anthropic。當你的程式碼請求 gpt-4o 時,LiteLLM 會先嘗試 OpenAI。如果失敗,fallbacks 設定會自動將請求路由到 Claude。你的應用程式程式碼完全不需要更改。
如果你使用的是 生產環境推論後端 如 vLLM 或 SGLang,你可以用相同的方式添加它們,只需將 api_base 設定為你的推論伺服器即可。
供應商快速參考
| 供應商 | model_name 範例 | 環境變數 | 端點 |
|---|---|---|---|
| OpenAI | openai/gpt-4o | OPENAI_API_KEY | 預設 (api.openai.com) |
| Anthropic | anthropic/claude-sonnet-4-20250514 | ANTHROPIC_API_KEY | 預設 |
| Ollama | ollama/llama3.1 | 無需設定 | http://localhost:11434 |
| Azure OpenAI | azure/gpt-4o | AZURE_API_KEY | 你的 Azure 端點 |
| AWS Bedrock | bedrock/anthropic.claude-v2 | AWS 憑證 | 你的區域 |
routing_strategy: least-busy 設定會將請求分發到具有相同 model_name 的模型上。如果你有兩個 OpenAI 金鑰(例如不同組織拥有不同的速率限制),將它們都列在 gpt-4o 下,LiteLLM 就會平衡負載。
虛擬金鑰,具備預算和速率限制的每團隊 API 金鑰
這是 LiteLLM 從「僅僅是一個 Proxy」轉變為團隊管理工具的關鍵所在。虛擬金鑰允許你為每個團隊成員或服務提供各自的 API 金鑰,並設定支出上限和速率限制,所有流量都透過你單一的供應商 API 金鑰進行路由。
建立具備預算的團隊金鑰
# Create a virtual key with a $50/month budget
curl http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"team_id": "frontend-team",
"max_budget": 50.0,
"budget_duration": "1mo",
"models": ["gpt-4o", "claude-sonnet"],
"metadata": {"purpose": "frontend AI features"}
}'回應會給你一個新的金鑰,如 sk-team-abc123...。將此金鑰交給前端團隊。他們可以像使用 OpenAI 金鑰一樣使用它,但它每月限制為 50 美元,且只能存取你指定的模型。
設定速率限制
# Create a key with rate limits: 100 requests/minute, 50K tokens/minute
curl http://localhost:4000/key/generate \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{
"team_id": "backend-team",
"max_budget": 200.0,
"budget_duration": "1mo",
"rpm_limit": 100,
"tpm_limit": 50000,
"models": ["gpt-4o", "claude-sonnet", "local-llama"]
}'虛擬金鑰文件涵蓋了每個參數。你也可以設定每用戶預算和速率限制以實現更細粒度的控制。
監控金鑰用量
import requests
# Check a key's current spend and limits
response = requests.get(
"http://localhost:4000/key/info",
headers={"Authorization": f"Bearer {MASTER_KEY}"},
params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Spent: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM used: {info['rpm_limit_used']} / {info['rpm_limit']}")需要撤銷洩露的金鑰嗎?只需一個 API 呼叫:
curl -X POST http://localhost:4000/key/delete \
-H "Authorization: Bearer $LITELLM_MASTER_KEY" \
-H "Content-Type: application/json" \
-d '{"keys": ["sk-team-abc123..."]}'結論:虛擬金鑰讓 LiteLLM 成為團隊工具,而不僅僅是個人 Proxy。 沒有它們,你只是在程式碼和 LLM 之間增加了一個跳躍點。有了它們,你就擁有了存取控制、預算執行和用量歸因,這些功能能讓你的財務長安心。
成本追蹤與 LiteLLM 儀表板
一旦連接 PostgreSQL,LiteLLM 就會自動追蹤每個請求的成本。你無需配置任何內容,它知道每個支援模型的每 Token 定價。
儀表板
在 http://localhost:4000/ui 存取內建 UI(使用你的主金鑰登入)。你會看到:
- 所有團隊和金鑰的總支出
- 每模型細分,哪些模型正在消耗你的預算
- 每團隊支出,誰在使用什麼
- 隨時間變化的請求量
對於認真希望降低 LLM API 成本的團隊來說,僅憑儀表板就足以證明運行 Proxy 的價值。你還可以將 LiteLLM 連接到外部的 AI 可觀測性平台,如 Langfuse 或 Helicone,以進行更深入的分析。
每供應商成本比較
以下是主要模型每百萬 Token 的成本(截至 2026 年 4 月):
| 供應商 | 模型 | 輸入 $/1M tokens | 輸出 $/1M tokens |
|---|---|---|---|
| OpenAI | GPT-4o | $2.50 | $10.00 |
| OpenAI | GPT-4o mini | $0.15 | $0.60 |
| Anthropic | Claude Sonnet 4 | $3.00 | $15.00 |
| Anthropic | Claude Haiku 3.5 | $0.80 | $4.00 |
| Gemini 2.0 Flash | $0.10 | $0.40 | |
| Ollama | Llama 3.1 (本地) | $0.00 | $0.00 |
當你在儀表板上看到按團隊細分的這些數字時,關於「我們是否應該為此用例使用更便宜的模型?」的對話變得非常具體。
結論:僅成本追蹤這一項功能,就足以讓任何每月在 LLM API 上支出超過 100 美元的團隊採用 Proxy。 你無法優化你無法衡量的事物。
連接 AI IDE,Claude Code、Cursor 和 Continue
這裡有一個大多數 LiteLLM 指南完全忽略的事情:你也可以將你的 AI 編碼工具指向 Proxy。一個 Proxy,所有你的 IDE 工具,統一計費。
Claude Code
# Set Claude Code to use your LiteLLM proxy
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-your-virtual-key就是這麼簡單。Claude Code 將請求發送到你的 Proxy,Proxy 將其路由到 Anthropic(或你設定檔中指定的任何地方),同時在你的虛擬金鑰下追蹤成本。
Cursor
在 Cursor 的設定中,添加一個自訂的 OpenAI 相容端點:
{
"openai.apiBaseUrl": "http://localhost:4000/v1",
"openai.apiKey": "sk-team-your-virtual-key"
}Continue (VS Code)
在 Continue 的 config.json 中:
{
"models": [
{
"title": "GPT-4o via LiteLLM",
"provider": "openai",
"model": "gpt-4o",
"apiBase": "http://localhost:4000/v1",
"apiKey": "sk-team-your-virtual-key"
}
]
}為什麼要這麼做?因為現在每個開發人員的 IDE 用量都經過 Proxy。你可以獲得 AI 編碼助手的每人成本追蹤、防止有人在編碼過程中意外燒掉 500 美元的速率限制,以及在你找到更好選項時切換模型的單一位置。
疑難排解常見問題
「找不到設定檔」
這通常意味著 Docker 中的卷掛載路徑錯誤。確保你的 config.yaml 位於你掛載的目錄中:
# Check the file exists where you think it does
ls -la ./config.yaml
# The volume mount in docker-compose.yml should match
# volumes:
# - ./config.yaml:/app/config.yamlPostgreSQL 「連線被拒絕」
Docker 網路問題經常困擾開發者。如果 LiteLLM 無法連接 Postgres,請檢查:
DATABASE_URL中的服務名稱是否與 Docker Compose 服務名稱匹配(使用postgres,而不是localhost)- 是否設定了帶有
condition: service_healthy的depends_on(這樣 LiteLLM 會等待 Postgres 準備就緒) - 兩個服務是否在同一個 Docker 網路上(在 Compose 中預設如此)
「無效的 API 金鑰格式」
最常見的混淆:你的 LITELLM_MASTER_KEY 用於管理操作(建立虛擬金鑰、存取儀表板)。虛擬金鑰(sk-team-...)才是你的應用程式使用的金鑰。不要搞混了。
「找不到模型」
請求中的 model 欄位必須與 config.yaml 中的 model_name 匹配。如果你的設定檔定義了 gpt-4o 但你的程式碼請求 openai/gpt-4o,則不會匹配。請檢查確切的拼寫。
Proxy 啟動但請求掛起
通常是防火牆或端口綁定問題。驗證端口 4000 已公開且未被阻止:
# Check if the port is listening
docker port litellm-proxy
# Should show: 4000/tcp -> 0.0.0.0:4000安全性:避免使用版本 1.82.7 和 1.82.8
2026 年 3 月,一起供應鏈事件影響了 LiteLLM 版本 1.82.7 和 1.82.8。受影響的版本已被撤回,並在 1.83.0 發布了乾淨的版本。始終將你的 Docker 映像固定到特定版本,並在升級前檢查官方安全更新。如果你使用的是 1.82.7 或 1.82.8,請立即更新。
你應該選擇哪種 LiteLLM 設定方式?
| 如果你需要... | 選擇 | 原因 |
|---|---|---|
| 快速測試、個人開發者實驗 | docker run 單行命令 | 零設定,60 秒內運行 |
| 2-10 人團隊且需成本追蹤 | Docker Compose + PostgreSQL | 持久數據、虛擬金鑰、預算限制 |
| 10-50 人團隊且有多個環境 | Docker Compose + Redis 快取 | 為重複提示添加快取,提高吞吐量 |
| 需要合規性/自動擴縮的企業 | Kubernetes + Helm chart | 自動擴縮、滾動更新、RBAC 整合 |
| 無需 Docker 的本地開發 | pip install litellm + CLI | Python 開發者本地測試最快 |
如果你是第一次閱讀本指南,請從 Docker Compose + PostgreSQL 開始。你以後隨時可以遷移到 Kubernetes,config.yaml 保持不變。
FAQ
什麼是 LiteLLM Proxy,它是如何運作的?
LiteLLM Proxy 是一個開源 AI 閘道器伺服器,位於你的應用程式與 OpenAI 和 Anthropic 等 LLM 供應商之間。它暴露一個單一的 OpenAI 相容端點,因此你的程式碼只需與一個 URL 通訊,而 Proxy 會在後台處理路由、金鑰管理、成本追蹤和備援。
如何使用 Docker Compose 設定 LiteLLM Proxy?
建立一個包含 LiteLLM Proxy 映像和 PostgreSQL 資料庫的 docker-compose.yml,掛載你的 config.yaml,將 API 金鑰設定為環境變數,然後運行 docker compose up -d。上面的「生產環境 Docker Compose 設定」部分有一個完整、可直接複製貼上的檔案。
如何使用 LiteLLM 管理團隊 API 金鑰?
使用虛擬金鑰。使用你的主金鑰呼叫 /key/generate 端點來建立每團隊或每用戶的金鑰。每個虛擬金鑰都可以有自己的每月預算、速率限制(RPM 和 TPM)以及模型存取限制。「虛擬金鑰」部分涵蓋了完整的工作流程。
如何為我的 LLM API 添加成本追蹤和速率限制?
將 PostgreSQL 連接到 Proxy(透過 DATABASE_URL),成本追蹤就會自動發生。對於速率限制,在生成虛擬金鑰時設定 rpm_limit 和 tpm_limit。位於 /ui 的內建儀表板顯示每團隊和每模型的支出。
LiteLLM Proxy 在生產環境中使用安全嗎?
是的,但有一個注意事項:避免使用版本 1.82.7 和 1.82.8,它們受到了 2026 年 3 月一起供應鏈事件的影響。請使用版本 1.83.0 或更高版本。固定你的 Docker 映像版本,設定 LITELLM_SALT_KEY 進行加密,並遵循官方的生產環境最佳實踐。
LiteLLM SDK 和 LiteLLM Proxy 有什麼區別?
SDK 是一個用於從你的程式碼呼叫多個 LLM API 的 Python 函式庫。Proxy 是一個獨立的伺服器,你的整個團隊都連接到它。如果你是獨自撰寫腳本的開發人員,請使用 SDK。如果你需要在團隊範圍內共享存取控制、成本追蹤和速率限制,請使用 Proxy。
我可以將 LiteLLM Proxy 與 Ollama 和本地模型一起使用嗎?
絕對可以。在你的 config.yaml 中添加一個條目,設定 model: ollama/llama3.1 和 api_base: http://host.docker.internal:11434(或你的 Ollama 主機)。你的團隊然後可以透過相同的 Proxy 端點存取本地模型,這非常適合開發和免費測試。
LiteLLM Proxy 的成本是多少?
LiteLLM Proxy 是免費且開源的(MIT 授權條款)。你需要在自己的基礎設施上自行託管。唯一的成本是你的伺服器(小型 VPS 對大多數團隊來說就足夠了)以及你已經支付的 LLM API 成本。BerriAI 也提供託管雲端版本,如果你不想自行託管。
LiteLLM 支援哪些供應商?
超過 100 家,包括 OpenAI、Anthropic、Azure OpenAI、AWS Bedrock、Google Vertex AI、Ollama、Hugging Face、Cohere、Replicate 等等。完整列表可在 LiteLLM GitHub 儲存庫 上找到。
如何安全地更新 LiteLLM Proxy?
始終在 Docker 映像標籤中固定特定版本(例如 ghcr.io/berriai/litellm:v1.83.2-stable)。在升級之前,檢查變更日誌是否有重大變更。永遠不要在生產環境中使用 latest。並且始終驗證新版本不在安全諮詢列表中,2026 年 3 月的事件證明即使是受信任的套件也可能被入侵。
最終結論與下一步
| 類別 | 建議 | 備註 |
|---|---|---|
| 快速開始 | docker run 單行命令 | 完美適合首次測試 |
| 團隊設定 | Docker Compose + PostgreSQL | 90% 團隊的預設選擇 |
| 設定 | 多供應商搭配備援 | 不要依賴單一供應商 |
| 金鑰管理 | 每團隊虛擬金鑰 | 為每個金鑰設定預算 + 速率限制 |
| 成本可見性 | 內建儀表板 + Postgres | 在優化之前先監控 |
| IDE 整合 | 將 Claude Code / Cursor 指向 Proxy | 所有工具統一計費 |
| 安全性 | 固定版本,設定鹽值金鑰 | 避免 1.82.7 和 1.82.8 |
如果你的團隊在 LLM API 上花費資金且尚未擁有 Proxy,請今天就開始使用 Docker Compose + Postgres。設定只需 15 分鐘,結束時你將擁有成本可見性和存取控制。
一旦運行起來,請探索為你的 LLM 管道添加防護欄以進行內容過濾和安全檢查。Proxy 是基礎,其他一切都建立在其之上。