LiteLLM Proxy: 1 API for 100+ LLM-er (15 min Docker-oppsett)

LiteLLM Proxy-oppsett: Nøkler, Kostnader og Hastighetsbegrensninger

Teamet ditt deler OpenAI API-nøkler i Slack-DM-er. Ingen vet hvem som brukte 4 000 kr forrige tirsdag. Det er ingen hastighetsbegrensning, ingen fallback når en leverandør går ned, og å bytte fra GPT-4o til Claude betyr å endre kode på tolv steder. Høres det kjent ut? En selv-hostet LLM-gateway løser alt dette, og LiteLLM-proxy er det mest populære åpen kildekode-alternativet -- ett enkelt OpenAI-kompatibelt endepunkt som ruter forespørsler til 100+ LLM-leverandører.

Denne guiden dekker hele LiteLLM proxy-oppsettet: Docker Compose med PostgreSQL, virtuelle teamnøkler med budsjetter, kostnadssporing, hastighetsbegrensninger og tilkobling av AI-IDE-er som Claude Code og Cursor. Hvis du evaluerer LLM-gateway-verktøy, er dette den praktiske opplæringen som tar deg fra null til produksjon.

En viktig merknad før vi starter: LiteLLM-SDK-en (Python-biblioteket) og Proxy-serveren er forskjellige ting. SDK-en er for en enkelt utvikler som kaller flere LLM-API-er fra Python. Proxy-en er for team -- den sitter som server mellom appene dine og LLM-leverandørene. Hvis du er en solo-utvikler som skriver et skript, er SDK-en nok. Hvis du administrerer nøkler, budsjetter og tilgang for et team, trenger du proxy-en. Det er det vi setter opp her.

LiteLLM Proxy i Korte Trekk

Slik sammenlignes distribusjonsmetodene:

For de fleste team er Docker Compose med PostgreSQL det gyldne middelvei. Det er det vi skal bygge -- men la oss først få en proxy til å kjøre på 60 sekunder.

Forutsetninger og Miljøoppsett

Før du starter, sørg for at du har:

• Docker og Docker Compose installert (Docker Desktop inkluderer begge)
• Minst én LLM API-nøkkel (OpenAI, Anthropic eller en lokal Ollama-instans)
• Grunnleggende terminal / CLI-kunnskap

Verifiser at Docker er klar og eksporter API-nøklene dine:

# Sjekk at Docker er installert
docker --version
docker compose version

# Eksporter LLM API-nøklene dine (legg til shell-profilen for persistens)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Valgfritt: angi en hovednøkkel for proxy-en din (du trenger den senere)
export LITELLM_MASTER_KEY="sk-master-din-hemmelige-nøkkel"

Det er det. Ingen spesiell Python-versjon, ingen OS-spesifikke verktøy. Hvis Docker kjører på maskinen din, er du klar.

Hurtigstart -- Din Første LiteLLM-proxy på 60 Sekunder

Én kommando for å 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 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

# Pek standard OpenAI SDK mot proxy-en din
client = OpenAI(
    api_key="sk-master-din-hemmelige-nøkkel",
    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)

Hva skjedde akkurat? Koden din snakker med localhost:4000 ved hjelp av standard OpenAI SDK-formatet. Proxy-en mottar forespørselen, videresender den til OpenAI API med den ekte nøkkelen og returnerer svaret. Applikasjonskoden din berører aldri den faktiske API-nøkkelen.

Det er kjerneideen. Nå bygger vi et produksjonsoppsett.

Produksjon Docker Compose-oppsett med PostgreSQL

Den enkle docker run-kommandoen fungerer for testing, men produksjonsteam trenger vedvarende kostnadssporing, virtuelle nøkler og ordentlig databaselagring. Det betyr 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   # Monter konfigurasjonsfilen din
    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 virtuelle nøkkeldata i databasen. Dokumentasjonen for LiteLLM produksjonsbest practices anbefaler å angi dette for enhver teamdistribusjon.

Starte Stacken

# Opprett en .env-fil med nøklene dine (ikke commit dette til git)
echo "LITELLM_MASTER_KEY=sk-master-din-hemmelighet" > .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 alt
docker compose up -d

# Sjekk logger
docker compose logs -f litellm

Verifisere at Alt Fungerer

# Helsesjekk
curl http://localhost:4000/health

# Test en forespørsel
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 vellykket svar, kjører produksjonsstacken din. PostgreSQL lagrer alle kostnadsdata, virtuelle nøkler og bruksmålinger vedvarende på tvers av containeromstarter.

Konklusjon: Docker Compose + PostgreSQL er det anbefalte produksjonsoppsettet. Det gir deg vedvarende lagring, kostnadssporing og virtuelle nøkler med omtrent 10 minutters arbeid. Docker-distribusjonsdokumentasjonen dekker Kubernetes og Helm hvis du trenger auto-skalering senere.

Config.yaml Gjennomgang -- Et Ekte Multi-leverandøroppsett

De fleste opplæringer viser en config.yaml med én modell. Her er hva en ekte teamkonfigurasjon ser ut som med tre leverandører, fallbacks og lastbalansering.

Konfigurasjonsfilen

# config.yaml -- Ekte multi-leverandøroppsett
model_list:
  # Primær: OpenAI GPT-4o
  - model_name: gpt-4o          # Navnet KODEN DIN bruker
    litellm_params:
      model: openai/gpt-4o      # Den faktiske leverandøren/modellen
      api_key: os.environ/OPENAI_API_KEY

  # Sekundær: Anthropic Claude
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

  # Lokal: Ollama for utvikling / kostnadsfri testing
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://host.docker.internal:11434

  # Fallback: rut "gpt-4o" til Claude hvis OpenAI er nede
  - 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    # Lastbalansér over modeller med samme navn
  num_retries: 3
  retry_after: 5                  # Sekunder mellom forsøk
  fallbacks: [{"gpt-4o": ["claude-sonnet"]}]

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  database_url: os.environ/DATABASE_URL

Modellaliaser og Ruting

Legg merke til at gpt-4o vises to ganger i konfigurasjonen -- én gang peker mot OpenAI, én gang mot Anthropic. Når koden din ber om gpt-4o, prøver LiteLLM OpenAI først. Hvis det mislykkes, ruter fallbacks-innstillingen automatisk til Claude. Applikasjonskoden din endres ikke i det hele tatt.

Hvis du bruker produksjonsinferens-backends som vLLM eller SGLang, kan du legge dem til på samme måte -- sett bare api_base til inferensserveren din.

Hurtigreferanse for Leverandører

Innstillingen routing_strategy: least-busy fordeler forespørsler over modeller med samme model_name. Hvis du har to OpenAI-nøkler (kanskje forskjellige organisasjoner med ulike hastighetsbegrensninger), list dem begge under gpt-4o og LiteLLM balanserer lasten.

Virtuelle Nøkler -- Team-API-nøkler med Budsjetter og Hastighetsbegrensninger

Her slutter LiteLLM å være "bare en proxy" og blir et teamadministrasjonsverktøy. Virtuelle nøkler lar deg gi hvert teammedlem eller tjeneste sin egen API-nøkkel med forbruksgrenser og hastighetstak -- alt rutet gjennom ditt enkle sett med leverandør-API-nøkler.

Opprette en Teamnøkkel med Budsjett

# Opprett en virtuell nøkkel med et budsjett på kr 500/måned
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 gir deg en ny nøkkel som sk-team-abc123.... Gi den til frontend-teamet. De kan bruke den akkurat som en OpenAI-nøkkel, men den er begrenset til $50/måned og har bare tilgang til modellene du spesifiserte.

Angi Hastighetsbegrensninger

# Opprett en nøkkel med hastighetsbegrensninger: 100 forespørsler/minutt, 50K tokens/minutt
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"]
  }'

Dokumentasjonen for virtuelle nøkler dekker hver parameter. Du kan også angi budsjetter og hastighetsbegrensninger per bruker for enda mer detaljert kontroll.

Overvåke Nøkkelbruk

import requests

# Sjekk nøkkelens nåværende forbruk og grenser
response = requests.get(
    "http://localhost:4000/key/info",
    headers={"Authorization": f"Bearer {MASTER_KEY}"},
    params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Brukt: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM brukt: {info['rpm_limit_used']} / {info['rpm_limit']}")

Trenger du å tilbakekalle en kompromittert nøkkel? Ett API-kall:

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

Konklusjon: Virtuelle nøkler gjør LiteLLM til et teamverktøy, ikke bare en personlig proxy. Uten dem legger du bare til ett hopp mellom koden din og LLM-en. Med dem har du tilgangskontroll, budsjettikketering og bruksattribusjon -- den typen ting som holder CFO-en din fra å få panikk.

Kostnadssporing og LiteLLM-dashbordet

Når PostgreSQL er tilkoblet, sporer LiteLLM automatisk kostnadene for hver forespørsel. Du trenger ikke å konfigurere noe -- det kjenner til pris per token for hver støttet modell.

Dashbordet

Gå til det innebygde grensesnittet på http://localhost:4000/ui (logg inn med hovednøkkelen din). Du ser:

• Totalt forbruk på tvers av alle team og nøkler
• Per-modell-fordeling -- hvilke modeller spiser budsjettet ditt
• Per-team-forbruk -- hvem bruker hva
• Forespørselsvolum over tid

For team som er seriøse om å redusere LLM API-kostnader, rettferdiggjør dashbordet alene å kjøre proxy-en. Du kan også koble LiteLLM til eksterne AI-observabilitetsplattformer som Langfuse eller Helicone for dypere analyse.

Kostnadssammenligning per Leverandør

Her er hva de store modellene koster per million tokens (april 2026):

Når du ser disse tallene i dashbordet fordelt per team, blir samtalene om "bør vi bruke en billigere modell for dette brukstilfellet?" veldig konkrete.

Konklusjon: Kostnadssporing alene rettferdiggjør proxy-en for ethvert team som bruker mer enn kr 1 000/måned på LLM API-er. Du kan ikke optimalisere det du ikke kan måle.

Koble til AI-IDE-er -- Claude Code, Cursor og Continue

Her er noe de fleste LiteLLM-guider hopper over helt: du kan også peke AI-kodingsverktøyene dine mot proxy-en. Én proxy, alle IDE-verktøyene dine, samlet fakturering.

Claude Code

# Angi at Claude Code skal bruke LiteLLM-proxy-en din
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-din-virtuelle-nøkkel

Det er det. Claude Code sender forespørsler til proxy-en din, som ruter dem til Anthropic (eller dit konfigurasjonen sier) mens kostnader spores under den virtuelle nøkkelen din.

Cursor

I Cursors innstillinger, legg til et tilpasset OpenAI-kompatibelt endepunkt:

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-din-virtuelle-nøkkel"
}

Continue (VS Code)

I Continue sin config.json:

{
  "models": [
    {
      "title": "GPT-4o via LiteLLM",
      "provider": "openai",
      "model": "gpt-4o",
      "apiBase": "http://localhost:4000/v1",
      "apiKey": "sk-team-din-virtuelle-nøkkel"
    }
  ]
}

Hvorfor bry seg? Fordi nå går hver utvikleres IDE-bruk gjennom proxy-en. Du får kostnadssporing per person for AI-kodingsassistenter, hastighetsbegrensninger slik at ingen ved et uhell brenner 5 000 kr i en kodingsøkt, og ett sted å bytte modeller hvis du finner et bedre alternativ.

Feilsøking av Vanlige Problemer

"Konfigurasjonsfil ikke funnet"

Dette betyr vanligvis at volummonteringsbanen er feil i Docker. Sørg for at config.yaml er i katalogen du monterer fra:

# Sjekk at filen eksisterer der du tror
ls -la ./config.yaml

# Volummonteringen i docker-compose.yml bør stemme
# volumes:
#   - ./config.yaml:/app/config.yaml

"Tilkobling nektet" til PostgreSQL

Docker-nettverk tar alle minst én gang. Hvis LiteLLM ikke kan nå Postgres, sjekk at:

• Tjenestenavnet i DATABASE_URL samsvarer med Docker Compose-tjenestenavnet (postgres, ikke localhost)
• depends_on med condition: service_healthy er angitt (slik at LiteLLM venter til Postgres er klar)
• Begge tjenestene er på samme Docker-nettverk (de er det som standard i Compose)

"Ugyldig API-nøkkelformat"

Den vanligste forvirringen: LITELLM_MASTER_KEY er for admin-operasjoner (opprette virtuelle nøkler, få tilgang til dashbordet). Virtuelle nøkler (sk-team-...) er det applikasjonene dine bruker. Ikke bland dem.

"Modell ikke funnet"

model-feltet i forespørselen din må samsvare med et model_name i config.yaml. Hvis konfigurasjonen din definerer gpt-4o men koden din ber om openai/gpt-4o, vil det ikke samsvare. Sjekk nøyaktig stavemåte.

Proxy-en starter men forespørsler henger

Vanligvis et brannmur- eller portbindingsproblem. Verifiser at port 4000 er eksponert og ikke blokkert:

# Sjekk om porten lytter
docker port litellm-proxy
# Bør vise: 4000/tcp -> 0.0.0.0:4000

Sikkerhet: Unngå Versjonene 1.82.7 og 1.82.8

I mars 2026 rammet en forsyningskjedehendelse LiteLLM-versjonene 1.82.7 og 1.82.8. De kompromitterte versjonene ble trukket tilbake og en ren utgivelse ble sendt på 1.83.0. Fests alltid Docker-bildet ditt til en spesifikk versjon og sjekk den offisielle sikkerhetsoppdateringen før oppgradering. Hvis du er på 1.82.7 eller 1.82.8, oppdater umiddelbart.

Hvilken LiteLLM-installasjonsmetode Bør Du Velge?

Hvis du leser denne guiden for første gang, start med Docker Compose + PostgreSQL. Du kan alltid migrere til Kubernetes senere -- config.yaml forblir den samme.

Vanlige Spørsmål

Hva er LiteLLM-proxy og hvordan fungerer det?

LiteLLM-proxy er en åpen kildekode AI-gatewayserver som sitter mellom applikasjonene dine og LLM-leverandører som OpenAI og Anthropic. Den eksponerer et enkelt OpenAI-kompatibelt endepunkt, slik at koden din snakker med én URL mens proxy-en håndterer ruting, nøkkelbehandling, kostnadssporing og fallbacks bak kulissene.

Er LiteLLM-proxy trygt å bruke i produksjon?

Ja, med ett forbehold: unngå versjonene 1.82.7 og 1.82.8 som ble rammet av en forsyningskjedehendelse i mars 2026. Bruk versjon 1.83.0 eller nyere. Fest Docker-bildeversjon, angi LITELLM_SALT_KEY for kryptering og følg de offisielle produksjonsbest practices.

Hva er forskjellen mellom LiteLLM SDK og LiteLLM-proxy?

SDK-en er et Python-bibliotek for å kalle flere LLM-API-er fra koden din. Proxy-en er en frittstående server som hele teamet ditt kobler til. Bruk SDK-en når du er en solo-dev som skriver et skript. Bruk proxy-en når du trenger delt tilgangskontroll, kostnadssporing og hastighetsbegrensning på tvers av et team.

Kan jeg bruke LiteLLM-proxy med Ollama og lokale modeller?

Absolutt. Legg til en oppføring i config.yaml med model: ollama/llama3.1 og api_base: http://host.docker.internal:11434 (eller Ollama-verten din). Teamet ditt kan da få tilgang til lokale modeller gjennom det samme proxy-endepunktet, noe som er utmerket for utvikling og kostnadsfri testing.

Hvor mye koster LiteLLM-proxy?

LiteLLM-proxy er gratis og åpen kildekode (MIT-lisens). Du er vert for det selv på din egen infrastruktur. De eneste kostnadene er serveren din (en liten VPS er nok for de fleste team) og LLM API-kostnadene du allerede betaler. BerriAI tilbyr også en administrert skyversjon hvis du ikke vil være vert for det selv.

Sluttvurdering og Neste Steg

Hvis teamet ditt bruker penger på LLM API-er og du ikke har en proxy ennå, start med Docker Compose + Postgres i dag. Oppsettet tar 15 minutter, og du vil ha kostnadssynlighet og tilgangskontroll på slutten av det.

Når du er i gang, utforsk å legge til guardrails i LLM-pipelinen din for innholdsfiltrering og sikkerhetskontroller. Proxy-en er grunnlaget -- alt annet bygger på det.

Kilder

• LiteLLM Proxy Hurtigstart -- Offisiell dokumentasjon
• LiteLLM Docker Distribusjonsveiledning
• LiteLLM Dokumentasjon for virtuelle nøkler
• LiteLLM Produksjonsbest practices
• LiteLLM Sikkerhetsoppdatering -- Mars 2026
• BerriAI/litellm -- GitHub-repositorie