LiteLLM Proxy: 1 API för 100+ LLM:er (15 Min Docker-Installation)

LiteLLM Proxy-installation: Nycklar, Kostnader och Hastighetsbegränsningar

Ditt team delar OpenAI API-nycklar i Slack-DM:ar. Ingen vet vem som spenderade 4 000 kr förra tisdagen. Det finns ingen hastighetsbegränsning, ingen fallback när en leverantör går ner, och att byta från GPT-4o till Claude innebär att ändra kod på tolv ställen. Låter det bekant? En självhostad LLM-gateway löser allt det här, och LiteLLM-proxy är det mest populära alternativet med öppen källkod -- en enda OpenAI-kompatibel slutpunkt som dirigerar förfrågningar till 100+ LLM-leverantörer.

Den här guiden täcker hela LiteLLM proxy-installationen: Docker Compose med PostgreSQL, virtuella teamnycklar med budgetar, kostnadsspårning, hastighetsbegränsningar och anslutning av AI-IDE:er som Claude Code och Cursor. Om du utvärderar LLM-gateway-verktyg är det här den praktiska handledningen som tar dig från noll till produktion.

En viktig notering innan vi börjar: LiteLLM:s SDK (Python-biblioteket) och Proxyservern är olika saker. SDK:n är för en enskild utvecklare som anropar flera LLM-API:er från Python. Proxy:n är för team -- den sitter som en server mellan dina appar och LLM-leverantörer. Om du är en ensam utvecklare som skriver ett skript räcker SDK:n. Om du hanterar nycklar, budgetar och åtkomst för ett team behöver du proxy:n. Det är vad vi sätter upp här.

LiteLLM Proxy i Korthet

Så här jämförs driftsättningsmetoderna:

För de flesta team är Docker Compose med PostgreSQL den gyllene medelvägen. Det är vad vi ska bygga -- men låt oss först få en proxy att köra på 60 sekunder.

Förutsättningar och Miljökonfiguration

Innan du börjar, se till att du har:

• Docker och Docker Compose installerat (Docker Desktop inkluderar båda)
• Minst en LLM API-nyckel (OpenAI, Anthropic eller en lokal Ollama-instans)
• Grundläggande terminal / CLI-kunskaper

Verifiera att Docker är redo och exportera dina API-nycklar:

# Kontrollera att Docker är installerat
docker --version
docker compose version

# Exportera dina LLM API-nycklar (lägg till i ditt shell-profil för persistens)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Valfritt: ange en huvudnyckel för din proxy (du behöver den senare)
export LITELLM_MASTER_KEY="sk-master-din-hemliga-nyckel"

Det är allt. Ingen speciell Python-version, inga OS-specifika verktyg. Om Docker körs på din maskin är du redo.

Snabbstart -- Din Första LiteLLM-proxy på 60 Sekunder

Ett kommando för att starta 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

Testa 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 testa från Python:

from openai import OpenAI

# Peka standard OpenAI SDK mot din proxy
client = OpenAI(
    api_key="sk-master-din-hemliga-nyckel",
    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)

Vad hände just? Din kod pratar med localhost:4000 med hjälp av standard OpenAI SDK-formatet. Proxy:n tar emot förfrågan, vidarebefordrar den till OpenAI:s API med den riktiga nyckeln och returnerar svaret. Din programkod rör aldrig den faktiska API-nyckeln.

Det är grundtanken. Nu bygger vi en produktionskonfiguration.

Produktionskonfiguration med Docker Compose och PostgreSQL

Det enda docker run-kommandot fungerar för testning, men produktionsteam behöver beständig kostnadsspårning, virtuella nycklar och ordentlig databaslagring. Det innebär 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   # Montera din konfigurationsfil
    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 krypterar virtuella nyckeldata i databasen. Dokumentationen för LiteLLM:s produktionsbästa praxis rekommenderar att ange detta för alla teamdriftsättningar.

Starta Stacken

# Skapa en .env-fil med dina nycklar (committa inte detta till git)
echo "LITELLM_MASTER_KEY=sk-master-din-hemlighet" > .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

# Starta allt
docker compose up -d

# Kontrollera loggar
docker compose logs -f litellm

Verifiera att Allt Fungerar

# Hälsokontroll
curl http://localhost:4000/health

# Testa en förfrågan
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"}]}'

Om du ser ett lyckat svar körs din produktionsstack. PostgreSQL lagrar all kostnadsdata, virtuella nycklar och användningsmätvärden beständigt över containeromstarter.

Slutsats: Docker Compose + PostgreSQL är den rekommenderade produktionskonfigurationen. Den ger dig beständig lagring, kostnadsspårning och virtuella nycklar med ungefär 10 minuters arbete. Docker-driftsättningsdokumentationen täcker Kubernetes och Helm om du behöver autoskalning senare.

Genomgång av Config.yaml -- En Verklig Multi-leverantörskonfiguration

De flesta handledningar visar en config.yaml med en modell. Så här ser en verklig teamkonfiguration ut med tre leverantörer, fallbacks och lastbalansering.

Konfigurationsfilen

# config.yaml -- Verklig multi-leverantörskonfiguration
model_list:
  # Primär: OpenAI GPT-4o
  - model_name: gpt-4o          # Namnet som DIN kod använder
    litellm_params:
      model: openai/gpt-4o      # Den faktiska leverantö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 för utveckling / kostnadsfri testning
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://host.docker.internal:11434

  # Fallback: dirigera "gpt-4o" till Claude om OpenAI är nere
  - 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    # Lastbalansera över modeller med samma namn
  num_retries: 3
  retry_after: 5                  # Sekunder mellan försök
  fallbacks: [{"gpt-4o": ["claude-sonnet"]}]

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

Modellalias och Dirigering

Observera att gpt-4o förekommer två gånger i konfigurationen -- en gång pekar det mot OpenAI, en gång mot Anthropic. När din kod begär gpt-4o försöker LiteLLM OpenAI först. Om det misslyckas dirigerar fallbacks-inställningen automatiskt till Claude. Din programkod förändras inte alls.

Om du använder produktionsinfluensbackends som vLLM eller SGLang kan du lägga till dem på samma sätt -- ange bara api_base till din inferensserver.

Snabbreferens för Leverantörer

Inställningen routing_strategy: least-busy fördelar förfrågningar över modeller med samma model_name. Om du har två OpenAI-nycklar (kanske olika organisationer med olika hastighetsbegränsningar), lista dem båda under gpt-4o och LiteLLM balanserar lasten.

Virtuella Nycklar -- Team-API-nycklar med Budgetar och Hastighetsbegränsningar

Det är här LiteLLM slutar vara "bara en proxy" och blir ett teamhanteringsverktyg. Virtuella nycklar låter dig ge varje teammedlem eller tjänst sin egen API-nyckel med utgiftsgränser och hastighetstak -- allt dirigerat genom ditt enda set av leverantörs-API-nycklar.

Skapa en Teamnyckel med Budget

# Skapa en virtuell nyckel med en budget på 500 kr/månad
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 ger dig en ny nyckel som sk-team-abc123.... Ge den till frontend-teamet. De kan använda den precis som en OpenAI-nyckel, men den är begränsad till $50/månad och har bara åtkomst till de modeller du angav.

Ange Hastighetsbegränsningar

# Skapa en nyckel med hastighetsbegränsningar: 100 förfrågningar/minut, 50K tokens/minut
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 för virtuella nycklar täcker varje parameter. Du kan också ange budgetar och hastighetsbegränsningar per användare för ännu mer detaljerad kontroll.

Övervaka Nyckelanvändning

import requests

# Kontrollera en nyckels aktuella utgifter och begränsningar
response = requests.get(
    "http://localhost:4000/key/info",
    headers={"Authorization": f"Bearer {MASTER_KEY}"},
    params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Spenderat: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM använt: {info['rpm_limit_used']} / {info['rpm_limit']}")

Behöver du återkalla en komprometterad nyckel? Ett API-anrop:

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

Slutsats: Virtuella nycklar gör LiteLLM till ett teamverktyg, inte bara en personlig proxy. Utan dem lägger du bara till ett hopp mellan din kod och LLM:en. Med dem har du åtkomstkontroll, budgetupprätthållande och användningsattribution -- det slag av saker som håller din ekonomichef från att få panik.

Kostnadsspårning och LiteLLM-instrumentpanelen

När PostgreSQL är anslutet spårar LiteLLM automatiskt kostnaden för varje förfrågan. Du behöver inte konfigurera något -- det känner till priset per token för varje modell som stöds.

Instrumentpanelen

Gå till det inbyggda gränssnittet på http://localhost:4000/ui (logga in med din huvudnyckel). Du ser:

• Total utgift över alla team och nycklar
• Per-modell-uppdelning -- vilka modeller äter upp din budget
• Per-team-utgift -- vem använder vad
• Förfrågningsvolym över tid

För team som är seriösa om att minska LLM API-kostnader motiverar instrumentpanelen ensamt att köra proxy:n. Du kan också ansluta LiteLLM till externa AI-observabilitetsplattformar som Langfuse eller Helicone för djupare analyser.

Kostnadsjämförelse per Leverantör

Här är vad de stora modellerna kostar per miljon tokens (april 2026):

När du ser dessa siffror i instrumentpanelen uppdelade per team blir samtalen om "borde vi använda en billigare modell för det här användningsfallet?" väldigt konkreta.

Slutsats: Kostnadsspårning ensamt motiverar proxy:n för alla team som spenderar mer än 1 000 kr/månad på LLM API:er. Du kan inte optimera det du inte kan mäta.

Ansluta AI-IDE:er -- Claude Code, Cursor och Continue

Här är något som de flesta LiteLLM-guider hoppar över helt: du kan även peka dina AI-kodningsverktyg mot proxy:n. En proxy, alla dina IDE-verktyg, enhetlig fakturering.

Claude Code

# Ange att Claude Code ska använda din LiteLLM-proxy
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-din-virtuella-nyckel

Det är allt. Claude Code skickar förfrågningar till din proxy, som dirigerar dem till Anthropic (eller dit din konfiguration säger) medan kostnader spåras under din virtuella nyckel.

Cursor

I Cursors inställningar, lägg till en anpassad OpenAI-kompatibel slutpunkt:

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-din-virtuella-nyckel"
}

Continue (VS Code)

I Continue:s config.json:

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

Varför bry sig? För att nu går varje utvecklares IDE-användning genom proxy:n. Du får kostnadsspårning per person för AI-kodningsassistenter, hastighetsbegränsningar så att ingen av misstag bränner 5 000 kr i en kodningssession, och ett enda ställe att byta modell om du hittar ett bättre alternativ.

Felsökning av Vanliga Problem

"Konfigurationsfilen hittades inte"

Det innebär vanligtvis att sökvägen för volymmonteringen är fel i Docker. Se till att din config.yaml finns i katalogen du monterar från:

# Kontrollera att filen finns där du tror
ls -la ./config.yaml

# Volymmonteringen i docker-compose.yml bör matcha
# volumes:
#   - ./config.yaml:/app/config.yaml

"Anslutning nekad" till PostgreSQL

Docker-nätverkande fångar alla minst en gång. Om LiteLLM inte kan nå Postgres, kontrollera att:

• Tjänstenamnet i DATABASE_URL matchar Docker Compose-tjänstenamnet (postgres, inte localhost)
• depends_on med condition: service_healthy är inställt (så att LiteLLM väntar tills Postgres är redo)
• Båda tjänsterna befinner sig i samma Docker-nätverk (de är det som standard i Compose)

"Ogiltigt API-nyckelformat"

Den vanligaste förvirringen: din LITELLM_MASTER_KEY är för administratörssoperationer (skapa virtuella nycklar, komma åt instrumentpanelen). Virtuella nycklar (sk-team-...) är vad dina applikationer använder. Blanda inte ihop dem.

"Modell hittades inte"

Fältet model i din förfrågan måste matcha ett model_name i config.yaml. Om din konfiguration definierar gpt-4o men din kod begär openai/gpt-4o matchar det inte. Kontrollera exakt stavning.

Proxy:n startar men förfrågningar hänger sig

Vanligtvis ett brandväggs- eller portbindningsproblem. Verifiera att port 4000 är exponerad och inte blockerad:

# Kontrollera om porten lyssnar
docker port litellm-proxy
# Bör visa: 4000/tcp -> 0.0.0.0:4000

Säkerhet: Undvik Versionerna 1.82.7 och 1.82.8

I mars 2026 drabbades LiteLLM-versionerna 1.82.7 och 1.82.8 av en leveranskedjehändelse. De komprometterade versionerna drogs tillbaka och en ren release skeppades på 1.83.0. Fäst alltid din Docker-avbild till en specifik version och kontrollera den officiella säkerhetsuppdateringen innan du uppgraderar. Om du är på 1.82.7 eller 1.82.8, uppdatera omedelbart.

Vilken LiteLLM-installationsmetod Bör Du Välja?

Om du läser den här guiden för första gången, börja med Docker Compose + PostgreSQL. Du kan alltid migrera till Kubernetes senare -- config.yaml förblir densamma.

Vanliga Frågor

Vad är LiteLLM-proxy och hur fungerar det?

LiteLLM-proxy är en öppen källkod AI-gatewayserver som sitter mellan dina applikationer och LLM-leverantörer som OpenAI och Anthropic. Den exponerar en enda OpenAI-kompatibel slutpunkt, så din kod pratar med en URL medan proxy:n hanterar routing, nyckelhantering, kostnadsspårning och fallbacks bakom kulisserna.

Är LiteLLM-proxy säkert att använda i produktion?

Ja, med ett förbehåll: undvik versionerna 1.82.7 och 1.82.8 som drabbades av en leveranskedjehändelse i mars 2026. Använd version 1.83.0 eller senare. Fäst din Docker-avbildsversion, ange LITELLM_SALT_KEY för kryptering och följ de officiella produktionsbästa praxis.

Vad är skillnaden mellan LiteLLM SDK och LiteLLM-proxy?

SDK:n är ett Python-bibliotek för att anropa flera LLM-API:er från din kod. Proxy:n är en fristående server som hela ditt team ansluter till. Använd SDK:n när du är en ensam dev som skriver ett skript. Använd proxy:n när du behöver delad åtkomstkontroll, kostnadsspårning och hastighetsbegränsning över ett team.

Kan jag använda LiteLLM-proxy med Ollama och lokala modeller?

Absolut. Lägg till en post i din config.yaml med model: ollama/llama3.1 och api_base: http://host.docker.internal:11434 (eller din Ollama-värd). Ditt team kan sedan komma åt lokala modeller via samma proxy-slutpunkt, vilket är utmärkt för utveckling och kostnadsfri testning.

Hur mycket kostar LiteLLM-proxy?

LiteLLM-proxy är gratis och öppen källkod (MIT-licens). Du är värd för det själv på din egen infrastruktur. De enda kostnaderna är din server (en liten VPS räcker för de flesta team) och LLM API-kostnaderna du redan betalar. BerriAI erbjuder också en hanterad molnversion om du inte vill vara värd för den själv.

Slutvärdering och Nästa Steg

Om ditt team spenderar pengar på LLM API:er och du inte har en proxy ännu, börja med Docker Compose + Postgres idag. Konfigurationen tar 15 minuter och du har kostnadssynlighet och åtkomstkontroll när du är klar.

När du väl är igång, utforska att lägga till guardrails i din LLM-pipeline för innehållsfiltrering och säkerhetskontroller. Proxy:n är grunden -- allt annat byggs ovanpå.

Källor

• LiteLLM Proxy Snabbstart -- Officiell dokumentation
• LiteLLM Docker Driftsättningsguide
• LiteLLM Dokumentation för virtuella nycklar
• LiteLLM Produktionsbästa praxis
• LiteLLM Säkerhetsuppdatering -- Mars 2026
• BerriAI/litellm -- GitHub-förråd