跳至主要內容

✨ Enterprise 快速入門

如果您正使用 Enterprise 試用版，請使用本指南來評估 LiteLLM 作為具備企業控制項與預算強制執行的統一 LLM、MCP 與 Agent 閘道。

資訊

部署 + 共用設定​

所有閘道與預算測試都共用同一個部署，以及同一個 org/team/key。請先完成本節。

前置條件​

  • 一組 LLM 提供者 API 金鑰（OpenAI、Azure、Anthropic 等）
  • Postgres — Admin UI、virtual keys、MCP/Agent 註冊與預算追蹤所需
  • 您的 Enterprise 授權金鑰
  • 一個部署目標：Docker Compose、Kubernetes (kubectl) 或 Helm

請遵循 Getting Started Tutorial 中的 Docker Compose 分頁。精簡步驟：

docker pull ghcr.io/berriai/litellm-database:latest
curl -O https://raw.githubusercontent.com/BerriAI/litellm/main/docker-compose.yml

建立 .env：

LITELLM_MASTER_KEY="sk-1234"
LITELLM_SALT_KEY="sk-salt-change-me"
LITELLM_LICENSE="eyJ..."
OPENAI_API_KEY="your-api-key"

建立 config.yaml：

config.yaml
model_list:
  - model_name: gpt-5.5
    litellm_params:
      model: openai/gpt-5.5
      api_key: os.environ/OPENAI_API_KEY

litellm_settings:
  callbacks: ["prometheus"]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: "postgresql://llmproxy:dbpassword9090@db:5432/litellm"
  store_model_in_db: true
docker compose up

驗證 Enterprise 版本​

開啟 http://localhost:4000/ — Swagger 應在描述中顯示 "Enterprise Edition"。請參閱 Enterprise 授權 FAQ。

在 http://localhost:4000/ui 開啟 Admin UI，並使用您的 master key 登入。

共用租戶設定​

在開始 gateway tracks 之前，請先在 Admin UI 完成這些步驟。

步驟動作原因
1建立 Organization 與 TeamOrganizations 用作頂層實體（Department of Computer Science），其下包含多個 Teams（Robotics Club、Frontend Engineering team）
2邀請 Internal Users在 team 內新增多位使用者，並管理支出
2設定 team max_budget（例如 $10、duration 30d）及早建立硬性支出上限，如此即可在執行 LLM calls 後驗證預算強制執行與超出預算時的行為。
3建立具備模型存取權的 team 範圍 virtual key讓管理員與內部使用者可存取 team 模型並強制執行預算。追蹤各個 team 的支出。

→ Multi-tenant Architecture · Virtual Keys

1. LLM 閘道​

證明 LiteLLM 會透過您的 virtual key 路由 LLM requests、追蹤支出，並強制執行 RBAC。

步驟​

  1. 確認模型 gpt-5.5（或您的模型）出現在 model_list（config 或 Admin UI → Models）中。

  2. 使用您的 master key 進行測試：

curl -X POST 'http://localhost:4000/chat/completions' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer sk-1234' \
  -d '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "Hello from LiteLLM Enterprise Gateway"}]
  }'

  1. 使用您的 team virtual key — 使用共用設定中的金鑰重複相同請求。

  2. 驗證回應 — 預期為 200 OK；assistant text 會以 choices[0].message.content 顯示。

  3. 驗證記錄 — 開啟 Logs 分頁；確認金鑰、team、模型、延遲與支出都有顯示。

  4. 驗證 team 支出 — 開啟 Teams 分頁 → 選取您的 team；確認支出已增加至 max_budget。

→ Virtual Keys → Gateway Quickstart → Role-Based Access Control

2. MCP 閘道​

證明 LiteLLM 會註冊 MCP servers、強制執行每個金鑰的存取權限、路由工具 calls，並追蹤 MCP 成本。

步驟​

  1. 註冊 MCP server — Admin UI → MCP Servers → Add New MCP Server：

    • 名稱：deepwiki
    • URL：https://mcp.deepwiki.com/mcp
    • 傳輸：HTTP

    或新增至 config.yaml：

mcp_servers:
  - server_name: deepwiki
    url: https://mcp.deepwiki.com/mcp
    transport: http
    available_on_public_internet: true

  1. 指派給 team/key — 在 virtual key 或 team 的 MCP Settings 中，允許 deepwiki server。請參閱 MCP 權限管理。

  2. 列出工具 — 確認工具會出現在 Admin UI 的 MCP Servers → MCP Tools 下方。

  3. 透過 /v1/chat/completions 呼叫：

curl -X POST 'http://localhost:4000/v1/chat/completions' \
  -H 'Authorization: Bearer sk-team-key' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "TLDR of BerriAI/litellm repo"}],
    "tools": [{
      "type": "mcp",
      "server_url": "litellm_proxy/deepwiki",
      "server_label": "deepwiki",
      "require_approval": "never"
    }]
  }'

  1. 驗證回應 — 內含工具輸出與 assistant 摘要。

  2. 驗證記錄 — Logs 分頁會顯示 MCP tool call，包含具命名空間的工具名稱與成本。

→ MCP 總覽 · MCP 權限管理 · 使用您的 MCP

3. Agent 閘道​

證明 LiteLLM 會註冊 A2A agents、強制執行每個金鑰的存取權限、呼叫 agents，並追蹤歸因於 agent 的支出。

步驟​

  1. 部署範例代理程式 — 使用 使用 A2A 的多代理程式協作（具有串流支援的簡單可部署 A2A 代理程式）。

  2. 在 Admin UI 註冊 — Agents 分頁 → Add Agent → 輸入名稱與 URL。

  3. 指派給 team/key — 在虛擬金鑰的 Agent Settings 下，允許該代理程式。請參閱 Agent Permission Management。

  4. 列出代理程式：

curl -H 'Authorization: Bearer sk-team-key' \
  'http://localhost:4000/v1/agents'
  1. 透過 A2A SDK 呼叫：
invoke_a2a_agent.py
import httpx, asyncio
from uuid import uuid4
from a2a.client import A2ACardResolver, A2AClient
from a2a.types import MessageSendParams, SendMessageRequest

LITELLM_BASE_URL = "http://localhost:4000"
LITELLM_VIRTUAL_KEY = "sk-team-key"

async def main():
    headers = {"Authorization": f"Bearer {LITELLM_VIRTUAL_KEY}"}
    async with httpx.AsyncClient(headers=headers) as client:
        agents = (await client.get(f"{LITELLM_BASE_URL}/v1/agents")).json()
        agent_id = agents[0]["agent_id"]
        base_url = f"{LITELLM_BASE_URL}/a2a/{agent_id}"
        resolver = A2ACardResolver(httpx_client=client, base_url=base_url)
        a2a_client = A2AClient(
            httpx_client=client,
            agent_card=await resolver.get_agent_card(),
        )
        response = await a2a_client.send_message(
            SendMessageRequest(
                id=str(uuid4()),
                params=MessageSendParams(
                    message={
                        "role": "user",
                        "parts": [{"kind": "text", "text": "Hello, what can you do?"}],
                        "messageId": uuid4().hex,
                    }
                ),
            )
        )
        print(response.model_dump(mode="json", exclude_none=True, indent=2))

asyncio.run(main())
  1. 驗證記錄 — Logs 分頁會顯示 key、team、延遲，以及歸因於代理程式的成本。成本會計入第 0 節中的 team/key 支出。

→ Agent Gateway Overview · Invoking A2A Agents · Agent Cost Tracking

4. 預算與支出​

預算強制執行會透過相同的虛擬金鑰在所有三個閘道上運作——同一個控制平面管理 LLM、MCP 與 Agent 支出。

4a. Key 預算 + 速率限制​

  1. 建立一個具有嚴格預算與 RPM 限制的測試 key：
curl -X POST 'http://localhost:4000/key/generate' \
  -H 'Authorization: Bearer sk-1234' \
  -H 'Content-Type: application/json' \
  -d '{
    "max_budget": 0.01,
    "rpm_limit": 1,
    "team_id": "<your-team-id>"
  }'
  1. 第一次請求 使用新 key → 200 OK。
  2. 同一分鐘內的第二次請求 → 速率限制錯誤（超出 RPM）。
  3. 在 Admin UI 的 Virtual Keys 下確認 key 支出。

→ Virtual Keys · Docker Quick Start — RPM test

4b. Team 預算​

第 0 節中已設定 Team max_budget。完成第 1–3 節後：

  1. 開啟 Teams 分頁 → 選取您的 PoC team。
  2. 確認跨 LLM、MCP 與 Agent 呼叫累積的 支出。
  3. 可選負向測試 — 將 team max_budget 設得非常低（例如 $0.0001），發出一次 LLM 呼叫，確認超出預算錯誤。

→ Multi-tenant Architecture

4c. 標籤預算​

  1. 將 tag_budget_config 加到 config.yaml，並重新啟動 proxy：
litellm_settings:
  tag_budget_config:
    poc:chat-app:
      max_budget: 0.000000000001
      budget_duration: 1d
  1. 發出一個帶標籤的請求：
curl -X POST 'http://localhost:4000/chat/completions' \
  -H 'Authorization: Bearer sk-team-key' \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "gpt-5.5",
    "messages": [{"role": "user", "content": "Hello"}],
    "metadata": {"tags": ["poc:chat-app"]}
  }'

  1. 第一次呼叫 成功；第二次呼叫 使用相同標籤會因超出預算而失敗。

  2. 查詢標籤支出：

curl -X GET 'http://localhost:4000/spend/tags' \
  -H 'Authorization: Bearer sk-1234'

驗證： 回應會列出 poc:chat-app，以及 total_spend 和 log_count。

接著探索： Projects · Temporary budget increases · Soft budget alerts · Spend reports · Budget Routing · Enterprise Spend Tracking

5. 企業控制​

在運作中的閘道與預算之上，疊加安全性與合規性。

稽核記錄​

透過您的 config.yml 的 litellm_settings 下的 store_audit_logs: true 啟用。透過 API 或 UI 刪除虛擬金鑰，然後檢查 Audit Logs 分頁。

→ Audit Logs

Team/key 防護欄​

  1. Guardrails → 建立一個 guardrail（機密偵測或內容審核）
  2. Policies → 將 guardrail 附加到 team 或 key
  3. 傳送應該被封鎖的請求；確認 guardrail 觸發

→ Guardrail Policies → Guardrails Quick Start

Admin UI 的 SSO​

SSO 控制的是 Admin UI 登入 — 與 API 驗證（虛擬金鑰或 JWT）分開。請在您的 IdP 中註冊此重新導向 URI：

https://<your-proxy-base-url>/sso/callback
GOOGLE_CLIENT_ID="<your-client-id>"
GOOGLE_CLIENT_SECRET="<your-client-secret>"
PROXY_BASE_URL="https://<your-proxy-base-url>"

驗證： 透過您的身分識別提供者登入 Admin UI。

另可使用： Custom SSO · CLI SSO · SCIM provisioning

→ SSO for Admin UI

JWT/OIDC 驗證​

使用您的身分識別提供者的 JWT 權杖來驗證應用程式請求，而非靜態虛擬金鑰。

→ JWT-based Authentication

密鑰管理器​

將 LiteLLM 指向您的 secret manager，讓提供者金鑰從 vault 讀取，而不是從設定檔讀取。

→ Secret Managers Overview

7. 其他企業價值​

💰
治理與成本
標籤預算、軟性預算提醒、支出報告，以及暫時性預算增加。
📡
可觀測性
以 team 為基礎的記錄、記錄匯出到 GCS/Azure Blob、每個 team 的 Langfuse 路由。
🌐
AI Hub
供您的使用者使用的可公開品牌化模型與代理程式頁面。
🏗️
多區域
多區域部署、授權，以及 admin/worker 分離。
🔒
資料安全
SOC 2、ISO 27001、資料區域，以及合規常見問題。
✨
完整企業目錄
完整功能參考、部署選項，以及支援 SLA。

8. 需要協助？​

每份 Enterprise 授權都包含一個與我們工程團隊聯繫的專屬 Slack 或 Teams 頻道。請與我們聯繫 support@berri.ai，我們非常樂意協助您！

請參閱 Professional Support。

🚅
LiteLLM Enterprise
為正式環境打造的 SSO/SAML、稽核記錄、支出追蹤、多團隊管理與防護欄。
深入瞭解 →