LiteLLM Proxy: 1 API til 100+ LLM'er (15-minutters Docker-opsætning)

LiteLLM Proxy: 1 API til 100+ LLM'er (15-minutters Docker-opsætning)

Dit team deler OpenAI API-nøgler i Slack DMs. Ingen ved, hvem der brugte $400 sidste tirsdag. Der er ingen hastighedsbegrænsning, ingen fallback, når en udbyder går ned, og skift fra GPT-4o til Claude kræver kodeændringer tolv forskellige steder. Lyder det bekendt? En self-hosted LLM-gateway løser alt dette, og LiteLLM-proxyen er den mest populære open source-løsning: et enkelt OpenAI-kompatibelt endpoint, der routerer anmodninger til over 100 LLM-udbydere.

Denne guide dækker den fulde litellm proxy-opsætning: Docker Compose med PostgreSQL, virtuelle team-nøgler med budgetter, omkostningssporing, hastighedsgrænser og tilslutning af AI IDE'er som Claude Code og Cursor. Hvis du evaluerer LLM gateway-værktøjer, er dette den praktiske tutorial, der tager dig fra nul til produktion.

En vigtig bemærkning, før vi starter: LiteLLM's SDK (Python-biblioteket) og Proxy Serveren er to forskellige ting. SDK'en er beregnet til en enkelt udvikler, der kalder flere LLM API'er fra Python. Proxyen er beregnet til teams; den fungerer som en server mellem dine apps og LLM-udbydere. Hvis du er en enkelt udvikler, der skriver et script, er SDK'en nok. Hvis du administrerer nøgler, budgetter og adgang for et team, har du brug for proxyen. Det er det, vi sætter op her.

LiteLLM Proxy ved første øjekast

Sådan sammenlignes deploymentsmetoderne:

For de fleste teams er Docker Compose med PostgreSQL det optimale valg. Det er det, vi stræber efter, men lad os først få en proxy kørende på 60 sekunder.

Forudsætninger og miljøopsætning

Før du starter, skal du sikre dig, at du har:

• Docker og Docker Compose installeret (Docker Desktop inkluderer begge)
• Mindst én LLM API-nøgle (OpenAI, Anthropic eller en lokal Ollama-instans)
• Grundlæggende kendskab til terminal / CLI

Bekræft at Docker er klar, og eksporter dine API-nøgler:

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

Det var det. Ingen specifik Python-version, ingen OS-specifikke værktøjer. Hvis Docker kører på din maskine, er du klar.

Hurtig start: Din første LiteLLM Proxy på 60 sekunder

Én kommando for at starte en proxy med 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

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

Eller test fra 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)

Hvad skete der lige? Din kode taler med localhost:4000 ved hjælp af standard OpenAI SDK-formatet. Proxyen modtager anmodningen, videresender den til OpenAI's API med den rigtige nøgle og returnerer svaret. Din applikationskode rører aldrig ved den faktiske API-nøgle.

Det er kernepointet. Lad os nu bygge en produktionsopsætning.

Produktionsklar Docker Compose-opsætning med PostgreSQL

Den enkelte docker run-kommando fungerer til test, men produktionsteams har brug for vedvarende omkostningssporing, virtuelle nøgler og korrekt databaselagring. Det betyder Docker Compose med PostgreSQL.

Docker Compose-filen

# 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 krypterer data for virtuelle nøgler i databasen. LiteLLM best practices for produktion anbefaler at indstille denne for enhver team-deployment.

Start af stacken

# 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

Verificering af at alt virker

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

Hvis du ser et succesfuldt svar, kører din produktionsstack. PostgreSQL gemmer alle omkostningsdata, virtuelle nøgler og brugsstatistikker permanent på tværs af container-genstarter.

Konklusion: Docker Compose + PostgreSQL er den anbefalede produktionsopsætning. Det giver dig vedvarende lagring, omkostningssporing og virtuelle nøgler med ca. 10 minutters arbejde. Docker deploymentsdokumentationen dækker Kubernetes og Helm, hvis du får brug for auto-scaling senere.

Gennemgang af config.yaml: En rigtig multi-udbyder opsætning

De fleste tutorials viser en config.yaml med én model. Her er, hvordan en rigtig team-konfiguration ser ud med tre udbydere, fallbacks og load balancing.

Konfigurationsfilen

# 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

Model-aliasser og routing

Bemærk, at gpt-4o vises to gange i konfigurationen: én gang pegende på OpenAI, én gang på Anthropic. Når din kode anmoder om gpt-4o, prøver LiteLLM først OpenAI. Hvis det fejler, routerer fallbacks-indstillingen automatisk til Claude. Din applikationskode ændres slet ikke.

Hvis du bruger produktions-inference backends som vLLM eller SGLang, kan du tilføje dem på samme måde; sæt blot api_base til din inference-server.

Hurtig reference til udbydere

Indstillingen routing_strategy: least-busy fordeler anmodninger på tværs af modeller med samme model_name. Hvis du har to OpenAI-nøgler (måske forskellige organisationer med forskellige hastighedsgrænser), kan du liste dem begge under gpt-4o, og LiteLLM balancerer belastningen.

Virtuelle nøgler: Per-team API-nøgler med budgetter og hastighedsgrænser

Her stopper LiteLLM med at være "bare en proxy" og bliver et team-administrationsværktøj. Virtuelle nøgler lader dig give hvert teammedlem eller service deres egen API-nøgle med udgiftsgrænser og hastighedscaps, alt sammen routeret gennem dit ene sæt af udbyder-API-nøgler.

Oprettelse af en team-nøgle med budget

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

Svaret giver dig en ny nøgle som sk-team-abc123.... Giv den til frontend-teamet. De kan bruge den præcis som en OpenAI-nøgle, men den er begrænset til $50/måned og har kun adgang til de modeller, du har angivet.

Indstilling af hastighedsgrænser

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

Dokumentationen for virtuelle nøgler dækker alle parametre. Du kan også indstille budgetter og hastighedsgrænser per bruger for endnu mere granular kontrol.

Overvågning af nøgleforbrug

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

Har du brug for at tilbagekalde en kompromitteret nøgle? Én API-kald:

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

Konklusion: Virtuelle nøgler er det, der gør LiteLLM til et teamværktøj, ikke bare en personlig proxy. Uden dem tilføjer du blot et hop mellem din kode og LLM'en. Med dem har du adgangskontrol, budgethåndhævelse og forbrugstilskrivning – den slags ting, der holder din CFO fra at gå i panik.

Omkostningssporing og LiteLLM Dashboard

Når PostgreSQL er tilsluttet, sporer LiteLLM automatisk omkostningerne for hver anmodning. Du behøver ikke konfigurere noget; det kender prisen per token for hver understøttet model.

Dashboardet

Få adgang til den indbyggede UI på http://localhost:4000/ui (log ind med din master-nøgle). Du vil se:

• Samlede udgifter på tværs af alle teams og nøgler
• Opdeling per model, hvilke modeller der æder dit budget
• Forbrug per team, hvem der bruger hvad
• Anmodningsvolumen over tid

For teams, der er seriøse omkring at reducere LLM API-omkostninger, retfærdiggør dashboardet alene kørslen af proxyen. Du kan også forbinde LiteLLM til eksterne AI observabilitetsplatforme som Langfuse eller Helicone for dybere analyser.

Omkostningssammenligning per udbyder

Her er, hvad de store modeller koster per million tokens (pr. april 2026):

Når du ser disse tal i dashboardet opdelt efter team, bliver samtalerne om "skal vi bruge en billigere model til dette use case?" meget konkrete.

Konklusion: Omkostningssporing alene retfærdiggør proxyen for ethvert team, der bruger >$100/måned på LLM API'er. Du kan ikke optimere, hvad du ikke kan måle.

Tilslutning af AI IDE'er: Claude Code, Cursor og Continue

Her er noget, de fleste LiteLLM-guides springer helt over: Du kan også pege dine AI-kodningsværktøjer mod proxyen. Én proxy, alle dine IDE-værktøjer, samlet fakturering.

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

Det var det. Claude Code sender anmodninger til din proxy, som routerer dem til Anthropic (eller hvor din konfiguration siger), mens omkostninger spores under din virtuelle nøgle.

Cursor

I Cursors indstillinger skal du tilføje et brugerdefineret OpenAI-kompatibelt endpoint:

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

Continue (VS Code)

I Continues config.json:

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

Hvorfor bother? Fordi nu går hver udviklers IDE-forbrug gennem proxyen. Du får omkostningssporing per person for AI-kodningsassistenter, hastighedsgrænser, så ingen ved et uheld brænder $500 af i en kodningssession, og ét sted at skifte modeller, hvis du finder en bedre mulighed.

Fejlfinding af almindelige problemer

"Config file not found"

Dette betyder normalt, at sti-mountingen i Docker er forkert. Sørg for, at din config.yaml ligger i den mappe, du mounter fra:

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

Docker-netværk fanger alle mindst én gang. Hvis LiteLLM ikke kan nå Postgres, skal du kontrollere, at:

• Servicenavnet i DATABASE_URL matcher Docker Compose-servicenavnet (postgres, ikke localhost)
• depends_on med condition: service_healthy er indstillet (så LiteLLM venter på, at Postgres er klar)
• Begge tjenester er på samme Docker-netværk (det er de som standard i Compose)

"Invalid API key format"

Den mest almindelige forvirring: Din LITELLM_MASTER_KEY er til admin-operationer (oprettelse af virtuelle nøgler, adgang til dashboardet). Virtuelle nøgler (sk-team-...) er det, dine applikationer bruger. Bland dem ikke sammen.

"Model not found"

Feltet model i din anmodning skal matche et model_name i config.yaml. Hvis din konfiguration definerer gpt-4o, men din kode anmoder om openai/gpt-4o, matcher det ikke. Tjek den nøjagtige stavemåde.

Proxyen starter, men anmodninger hænger

Normalt et firewall- eller portbindingsproblem. Bekræft, at port 4000 er eksponeret og ikke blokeret:

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

Sikkerhed: Undgå version 1.82.7 og 1.82.8

I marts 2026 påvirkede et supply chain-incident LiteLLM-versionerne 1.82.7 og 1.82.8. De kompromitterede versioner blev trukket tilbage, og en ren release blev sendt ud som 1.83.0. Pin altid dit Docker-image til en specifik version, og tjek den officielle sikkerhedsopdatering før opgradering. Hvis du er på 1.82.7 eller 1.82.8, skal du opdatere med det samme.

Hvilken LiteLLM-opsætningsmetode skal du vælge?

Hvis du læser denne guide for første gang, skal du starte med Docker Compose + PostgreSQL. Du kan altid migrere til Kubernetes senere; config.yaml forbliver den samme.

FAQ

Hvad er LiteLLM proxy, og hvordan virker det?

LiteLLM proxy er en open source AI gateway-server, der sidder mellem dine applikationer og LLM-udbydere som OpenAI og Anthropic. Den eksponerer et enkelt OpenAI-kompatibelt endpoint, så din kode taler med én URL, mens proxyen håndterer routing, nøgleadministration, omkostningssporing og fallbacks i baggrunden.

Hvordan opsætter jeg LiteLLM proxy med Docker Compose?

Opret en docker-compose.yml med LiteLLM proxy-image og en PostgreSQL-database, mount din config.yaml, indstil dine API-nøgler som miljøvariabler, og kør docker compose up -d. Afsnittet om Produktions-Docker Compose ovenfor har en komplet, copy-paste-klar fil.

Hvordan administrerer jeg team-API-nøgler med LiteLLM?

Brug virtuelle nøgler. Ram /key/generate-endpointet med din master-nøgle for at oprette nøgler per team eller per bruger. Hver virtuel nøgle kan have sit eget månedlige budget, hastighedsgrænser (RPM og TPM) og modeladgangsbegrænsninger. Afsnittet om Virtuelle Nøgler dækker hele workflowet.

Hvordan tilføjer jeg omkostningssporing og hastighedsgrænser til min LLM API?

Forbind PostgreSQL til proxyen (via DATABASE_URL), og omkostningssporing sker automatisk. For hastighedsgrænser skal du indstille rpm_limit og tpm_limit, når du genererer virtuelle nøgler. Det indbyggede dashboard på /ui viser forbrug per team og per model.

Er LiteLLM proxy sikker at bruge i produktion?

Ja, med én forbehold: Undgå versionerne 1.82.7 og 1.82.8, som blev påvirket af et supply chain-incident i marts 2026. Brug version 1.83.0 eller nyere. Pin din Docker-image-version, indstil LITELLM_SALT_KEY til kryptering, og følg de officielle best practices for produktion.

Hvad er forskellen mellem LiteLLM SDK og LiteLLM proxy?

SDK'en er et Python-bibliotek til at kalde flere LLM API'er fra din kode. Proxyen er en selvstændig server, som hele dit team forbinder til. Brug SDK'en, når du er en enkelt udvikler, der skriver et script. Brug proxyen, når du har brug for delt adgangskontrol, omkostningssporing og hastighedsbegrænsning på tværs af et team.

Kan jeg bruge LiteLLM proxy med Ollama og lokale modeller?

Absolut. Tilføj en post til din config.yaml med model: ollama/llama3.1 og api_base: http://host.docker.internal:11434 (eller din Ollama-host). Dit team kan derefter få adgang til lokale modeller gennem samme proxy-endpoint, hvilket er fantastisk til udvikling og omkostningsfri test.

Hvor meget koster LiteLLM proxy?

LiteLLM proxy er gratis og open source (MIT-licens). Du hoster den selv på din egen infrastruktur. De eneste omkostninger er din server (en lille VPS er nok til de fleste teams) og de LLM API-omkostninger, du allerede betaler. BerriAI tilbyder også en administreret cloud-version, hvis du ikke vil self-hoste.

Hvilke udbydere understøtter LiteLLM?

Over 100, herunder OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Ollama, Hugging Face, Cohere, Replicate og mange flere. Den fulde liste findes på LiteLLM GitHub-repositoriet.

Hvordan opdaterer jeg LiteLLM proxy sikkert?

Pin altid en specifik version i dit Docker-image-tag (f.eks. ghcr.io/berriai/litellm:v1.83.2-stable). Før opgradering skal du tjekke changeloggen for breaking changes. Brug aldrig latest i produktion. Og verificér altid, at den nye version ikke er på listen over sikkerhedsrådgivninger; incidenten i marts 2026 beviste, at selv betroede pakker kan blive kompromitteret.

Endelig konklusion og næste skridt

Hvis dit team bruger penge på LLM API'er, og du ikke har en proxy endnu, skal du starte med Docker Compose + Postgres i dag. Opsætningen tager 15 minutter, og du vil have omkostningssynlighed og adgangskontrol, når du er færdig.

Når du er i gang, kan du udforske tilføjelse af guardrails til din LLM-pipeline for indholdsfiltrering og sikkerhedstjek. Proxyen er fundamentet; alt andet bygger ovenpå det.

Kilder

• LiteLLM Proxy Quick Start, Officiel Docs
• LiteLLM Docker Deployment Guide
• LiteLLM Virtual Keys Documentation
• LiteLLM Production Best Practices
• LiteLLM Security Update, March 2026
• BerriAI/litellm, GitHub Repository