LiteLLM Proxy: 1 API pro 100+ LLM (nastavení v Dockeru za 15 minut)

LiteLLM Proxy: 1 API pro 100+ LLM (nastavení v Dockeru za 15 minut)

Váš tým sdílí API klíče OpenAI v soukromých zprávách na Slacku. Nikdo neví, kdo minulé úterý utratil 400 dolarů. Neexistuje žádné omezování rychlosti, žádná záložní možnost, když poskytovatel vypadne, a přechod z GPT-4o na Claude znamená změnu kódu na dvanácti místech. Zní to povědomě? Samostatně hostovaná LLM brána toto vše řeší a proxy server LiteLLM je nejpopulárnější open-source možností – jediný koncový bod kompatibilní s OpenAI, který směruje požadavky ke více než 100 poskytovatelům LLM.

Tento průvodce pokrývá kompletní nastavení proxy litellm: Docker Compose s PostgreSQL, virtuální týmové klíče s rozpočty, sledování nákladů, limity rychlosti a připojení AI IDE, jako jsou Claude Code a Cursor. Pokud hodnotíte nástroje LLM gateway, toto je praktický tutoriál, který vás dostane od nuly do produkce.

Jedna důležitá poznámka, než začneme: SDK LiteLLM (knihovna Pythonu) a Proxy Server jsou dvě různé věci. SDK je určeno pro jednotlivého vývojáře, který volá více LLM API z Pythonu. Proxy je určena pro týmy; funguje jako server mezi vašimi aplikacemi a poskytovateli LLM. Pokud jste sólový vývojář píšící skript, SDK vám stačí. Pokud spravujete klíče, rozpočty a přístup pro tým, potřebujete proxy. Právě tu zde budeme nastavovat.

LiteLLM Proxy v kostce

Zde je porovnání metod nasazení:

Pro většinu týmů je Docker Compose s PostgreSQL ideální volbou. K tomu směřujeme, ale nejprve si spusťme proxy za 60 sekund.

Požadavky a nastavení prostředí

Než začnete, ujistěte se, že máte:

• Nainstalovaný Docker a Docker Compose (Docker Desktop obsahuje oba)
• alespoň jeden API klíč LLM (OpenAI, Anthropic nebo lokální instance Ollama)
• Základní znalost terminálu / CLI

Ověřte, že je Docker připraven, a exportujte své API klíče:

# 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"

To je vše. Žádná speciální verze Pythonu, žádné nástroje specifické pro operační systém. Pokud vám na stroji běží Docker, jste připraveni.

Rychlý start: Vaše první proxy LiteLLM za 60 sekund

Jeden příkaz ke spuštění proxy s GPT-4o:

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

Otestujte ji pomocí 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"}]
  }'

Nebo otestujte z Pythonu:

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)

Co se právě stalo? Váš kód komunikuje s localhost:4000 pomocí standardního formátu SDK OpenAI. Proxy přijme požadavek, předá jej API OpenAI se skutečným klíčem a vrátí odpověď. Kód vaší aplikace se nikdy nedotkne skutečného API klíče.

To je ta hlavní myšlenka. Nyní si postavme produkční nastavení.

Produkční nastavení Docker Compose s PostgreSQL

Jediný příkaz docker run funguje pro testování, ale produkční týmy potřebují trvalé sledování nákladů, virtuální klíče a řádné ukládání do databáze. To znamená Docker Compose s PostgreSQL.

Soubor 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 šifruje data virtuálních klíčů v databázi. Dokumentace osvědčených postupů pro produkci LiteLLM doporučuje toto nastavit pro jakékoli týmové nasazení.

Spuštění stacku

# 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

Ověření funkčnosti

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

Pokud uvidíte úspěšnou odpověď, váš produkční stack běží. PostgreSQL trvale ukládá všechna data o nákladech, virtuální klíče a metriky využití i při restartech kontejnerů.

Verdikt: Docker Compose + PostgreSQL je doporučené produkční nastavení. Poskytuje vám trvalé úložiště, sledování nákladů a virtuální klíče s asi 10 minutami práce. Dokumentace k nasazení Dockeru pokrývá Kubernetes a Helm, pokud budete později potřebovat automatické škálování.

Průvodce config.yaml, skutečné nastavení pro více poskytovatelů

Většina tutoriálů ukazuje config.yaml s jedním modelem. Zde je, jak vypadá skutečná týmová konfigurace se třemi poskytovateli, záložními možnostmi a vyvažováním zátěže.

Konfigurační soubor

# 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

Aliasy modelů a směrování

Všimněte si, že gpt-4o se v konfiguraci objevuje dvakrát, jednou směřuje na OpenAI, podruhé na Anthropic. Když váš kód požádá o gpt-4o, LiteLLM nejprve zkusí OpenAI. Pokud to selže, nastavení fallbacks automaticky přesměruje požadavek na Claude. Kód vaší aplikace se vůbec nemění.

Pokud používáte produkční inference backends, jako je vLLM nebo SGLang, můžete je přidat stejným způsobem, stačí nastavit api_base na váš inference server.

Rychlá reference poskytovatelů

Nastavení routing_strategy: least-busy distribuuje požadavky napříč modely se stejným model_name. Pokud máte dva klíče OpenAI (možná různé organizace s různými limity rychlosti), uvedete je oba pod gpt-4o a LiteLLM vyváží zátěž.

Virtuální klíče, API klíče pro jednotlivé týmy s rozpočty a limity rychlosti

Zde přestává být LiteLLM „jen proxy“ a stává se nástrojem pro správu týmů. Virtuální klíče vám umožňují dát každému členovi týmu nebo službě jejich vlastní API klíč s limity utrácení a omezením rychlosti, vše směrované prostřednictvím vaší jediné sady API klíčů poskytovatele.

Vytvoření týmového klíče s rozpočtem

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

Odpověď vám poskytne nový klíč, například sk-team-abc123.... Předejte ho frontendovému týmu. Mohou ho používat přesně jako klíč OpenAI, ale je omezen na 50 USD/měsíc a má přístup pouze k modelům, které jste zadali.

Nastavení limitů rychlosti

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

Dokumentace k virtuálním klíčům pokrývá každý parametr. Můžete také nastavit rozpočty a limity rychlosti pro jednotlivé uživatele pro ještě jemnější kontrolu.

Sledování využití klíčů

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

Potřebujete zrušit kompromitovaný klíč? Jeden API call:

curl -X POST http://localhost:4000/key/delete \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"keys": ["sk-team-abc123..."]}'

Verdikt: Virtuální klíče dělají z LiteLLM týmový nástroj, nejen osobní proxy. Bez nich pouze přidáváte další hop mezi vaším kódem a LLM. S nimi máte řízení přístupu, vynucování rozpočtu a přiřazování využití, což jsou věci, které udrží vašeho CFO v klidu.

Sledování nákladů a dashboard LiteLLM

Jakmile je PostgreSQL připojeno, LiteLLM automaticky sleduje náklady na každý požadavek. Nemusíte nic konfigurovat, zná cenu za token pro každý podporovaný model.

Dashboard

Přístup k vestavěnému UI získáte na adrese http://localhost:4000/ui (přihlaste se svým hlavním klíčem). Uvidíte:

• Celkové výdaje napříč všemi týmy a klíči
• Rozpis podle modelu, které modely požírají váš rozpočet
• Výdaje podle týmu, kdo co používá
• Objem požadavků v čase

Pro týmy, které to myslí vážně se snížením nákladů na LLM API, samotný dashboard ospravedlňuje provoz proxy. Můžete také připojit LiteLLM k externím platformám AI observability, jako jsou Langfuse nebo Helicone, pro hlubší analýzu.

Porovnání nákladů podle poskytovatele

Zde jsou ceny hlavních modelů za milion tokenů (k dubnu 2026):

Když tato čísla uvidíte v dashboardu rozdělená podle týmů, konverzace na téma „měli bychom pro tento případ použití použít levnější model?“ se stanou velmi konkrétními.

Verdikt: Samotné sledování nákladů ospravedlňuje proxy pro jakýkoli tým, který utrácí >100 USD měsíčně za LLM API. Nemůžete optimalizovat to, co nemůžete měřit.

Propojení AI IDE, Claude Code, Cursor a Continue

Zde je něco, co většina průvodců LiteLLM zcela ignoruje: své nástroje pro AI kódování můžete také nasměrovat na proxy. Jedna proxy, všechny vaše nástroje IDE, sjednocené fakturace.

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

To je vše. Claude Code posílá požadavky na vaši proxy, která je směruje na Anthropic (nebo kamkoli říká vaše konfigurace) a zároveň sleduje náklady pod vaším virtuálním klíčem.

Cursor

V nastavení Cursoru přidejte vlastní koncový bod kompatibilní s OpenAI:

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-your-virtual-key"
}

Continue (VS Code)

V config.json pro Continue:

{
  "models": [
    {
      "title": "GPT-4o via LiteLLM",
      "provider": "openai",
      "model": "gpt-4o",
      "apiBase": "http://localhost:4000/v1",
      "apiKey": "sk-team-your-virtual-key"
    }
  ]
}

Proč se obtěžovat? Protože nyní veškeré využití IDE každého vývojáře prochází přes proxy. Získáte sledování nákladů na osobu pro asistenty AI kódování, limity rychlosti, aby nikdo náhodou neutratil 500 USD během jedné coding session, a jedno místo pro přepínání modelů, pokud najdete lepší možnost.

Řešení běžných problémů

„Config file not found“ (Konfigurační soubor nenalezen)

To obvykle znamená, že cesta k mountování svazku v Dockeru je špatná. Ujistěte se, že váš config.yaml je v adresáři, ze kterého mountujete:

# 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.yaml

„Connection refused“ (Spojení odmítnuto) k PostgreSQL

Síťování Dockeru chytne každého alespoň jednou. Pokud se LiteLLM nemůže připojit k Postgres, zkontrolujte, zda:

• Název služby v DATABASE_URL odpovídá názvu služby Docker Compose (postgres, nikoli localhost)
• Je nastaveno depends_on s condition: service_healthy (aby LiteLLM počkal, až bude Postgres připraven)
• Obě služby jsou ve stejné síti Dockeru (ve výchozím nastavení Compose jsou)

„Invalid API key format“ (Neplatný formát API klíče)

Nejčastější zmatek: váš LITELLM_MASTER_KEY je pro administrativní operace (vytváření virtuálních klíčů, přístup k dashboardu). Virtuální klíče (sk-team-...) jsou to, co používají vaše aplikace. Nezaměňujte je.

„Model not found“ (Model nenalezen)

Pole model ve vašem požadavku musí odpovídat model_name v config.yaml. Pokud vaše konfigurace definuje gpt-4o, ale váš kód požaduje openai/gpt-4o, nebude to sedět. Zkontrolujte přesné pravopis.

Proxy se spustí, ale požadavky visí

Obvykle jde o problém s firewallem nebo bindováním portu. Ověřte, že je port 4000 vystaven a není blokován:

# Check if the port is listening
docker port litellm-proxy
# Should show: 4000/tcp -> 0.0.0.0:4000

Bezpečnost: Vyhněte se verzím 1.82.7 a 1.82.8

V březnu 2026 postihl incident dodavatelského řetězce verze LiteLLM 1.82.7 a 1.82.8. Kompromitované verze byly staženy a čistá release byla vydána jako 1.83.0. Vždy pinujte svůj Docker image na konkrétní verzi a před upgradem zkontrolujte oficiální bezpečnostní aktualizaci. Pokud používáte 1.82.7 nebo 1.82.8, okamžitě aktualizujte.

Jakou metodu nastavení LiteLLM byste měli zvolit?

Pokud tento průvodce čtete poprvé, začněte s Docker Compose + PostgreSQL. Později můžete vždy migrovat na Kubernetes, config.yaml zůstane stejný.

FAQ

Co je proxy LiteLLM a jak funguje?

Proxy LiteLLM je open-source AI gateway server, který sedí mezi vašimi aplikacemi a poskytovateli LLM, jako jsou OpenAI a Anthropic. Exponuje jediný koncový bod kompatibilní s OpenAI, takže váš kód komunikuje s jednou URL, zatímco proxy za scénou řeší směrování, správu klíčů, sledování nákladů a záložní možnosti.

Jak nastavit proxy LiteLLM s Docker Compose?

Vytvořte docker-compose.yml s obrazem proxy LiteLLM a databází PostgreSQL, namontujte svůj config.yaml, nastavte své API klíče jako proměnné prostředí a spusťte docker compose up -d. Sekce Produkční Docker Compose výše obsahuje kompletní soubor připravený ke zkopírování.

Jak spravovat týmové API klíče s LiteLLM?

Použijte virtuální klíče. Zavolejte endpoint /key/generate se svým hlavním klíčem a vytvořte klíče pro jednotlivé týmy nebo uživatele. Každý virtuální klíč může mít svůj vlastní měsíční rozpočet, limity rychlosti (RPM a TPM) a omezení přístupu k modelům. Sekce Virtuální klíče pokrývá celý pracovní postup.

Jak přidat sledování nákladů a limity rychlosti k mému LLM API?

Připojte PostgreSQL k proxy (prostřednictvím DATABASE_URL) a sledování nákladů probíhá automaticky. Pro limity rychlosti nastavte rpm_limit a tpm_limit při generování virtuálních klíčů. Vestavěný dashboard na /ui zobrazuje výdaje podle týmů a modelů.

Je proxy LiteLLM bezpečné pro použití v produkci?

Ano, s jednou výhradou: vyhněte se verzím 1.82.7 a 1.82.8, které byly postiženy incidentem v dodavatelském řetězci v březnu 2026. Používejte verzi 1.83.0 nebo novější. Pinujte verzi svého Docker image, nastavte LITELLM_SALT_KEY pro šifrování a dodržujte oficiální osvědčené postupy pro produkci.

Jaký je rozdíl mezi SDK LiteLLM a proxy LiteLLM?

SDK je knihovna Pythonu pro volání více LLM API z vašeho kódu. Proxy je samostatný server, ke kterému se připojuje celý váš tým. Použijte SDK, když jste sólový vývojář píšící skript. Použijte proxy, když potřebujete sdílené řízení přístupu, sledování nákladů a omezování rychlosti napříč týmem.

Mohu používat proxy LiteLLM s Ollama a lokálními modely?

Rozhodně. Přidejte položku do svého config.yaml s model: ollama/llama3.1 a api_base: http://host.docker.internal:11434 (nebo váš hostitel Ollama). Váš tým pak může přistupovat k lokálním modelům prostřednictvím stejného koncového bodu proxy, což je skvělé pro vývoj a testování bez nákladů.

Kolik stojí proxy LiteLLM?

Proxy LiteLLM je zdarma a open-source (licence MIT). Hostujete si ji sami na své vlastní infrastruktuře. Jediné náklady jsou váš server (malý VPS stačí pro většinu týmů) a náklady na LLM API, které již platíte. BerriAI také nabízí spravovanou cloudovou verzi, pokud nechcete hostovat sami.

Jaké poskytovatele LiteLLM podporuje?

Více než 100, včetně OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Ollama, Hugging Face, Cohere, Replicate a mnoha dalších. Úplný seznam je na GitHub repozitáři LiteLLM.

Jak bezpečně aktualizovat proxy LiteLLM?

Vždy pinujte konkrétní verzi v tagu svého Docker image (např. ghcr.io/berriai/litellm:v1.83.2-stable). Před upgradem zkontrolujte changelog kvůli změnám, které mohou rozbít kompatibilitu. Nikdy nepoužívejte latest v produkci. A vždy ověřte, že nová verze není na seznamu bezpečnostních upozornění, incident z března 2026 prokázal, že i důvěryhodné balíčky mohou být kompromitovány.

Závěrečný verdikt a další kroky

Pokud váš tým utrácí peníze za LLM API a ještě nemáte proxy, začněte dnes s Docker Compose + Postgres. Nastavení zabere 15 minut a na konci budete mít viditelnost nákladů a řízení přístupu.

Jakmile budete v provozu, prozkoumejte přidání guardrails do vašeho LLM pipeline pro filtrování obsahu a bezpečnostní kontroly. Proxy je základem, vše ostatní se staví na ní.

Zdroje

• Rychlý start LiteLLM Proxy, Oficiální dokumentace
• Průvodce nasazením LiteLLM Docker
• Dokumentace virtuálních klíčů LiteLLM
• Osvědčené postupy pro produkci LiteLLM
• Bezpečnostní aktualizace LiteLLM, březen 2026
• BerriAI/litellm, GitHub repozitář