LiteLLM Proxy: 1 API voor 100+ LLMs (setup in 15 minuten)

LiteLLM Proxy Instellen: Sleutels, Kosten en Snelheidslimieten

Uw team deelt OpenAI API-sleutels in Slack DM's. Niemand weet wie er vorige dinsdag €400 heeft uitgegeven. Er zijn geen snelheidslimieten, geen fallback als een provider uitvalt, en overstappen van GPT-4o naar Claude betekent code op twaalf plekken aanpassen. Klinkt bekend? Een zelf-gehoste LLM-gateway lost dit allemaal op, en de LiteLLM proxy is de populairste open-sourceoptie -- één enkel OpenAI-compatibel eindpunt dat verzoeken routeert naar 100+ LLM-providers.

Deze handleiding behandelt de volledige LiteLLM proxy installatie: Docker Compose met PostgreSQL, virtuele teamsleutels met budgetten, kostenbeheer, snelheidslimieten en het verbinden van AI-IDE's zoals Claude Code en Cursor. Als u LLM-gateway-tools evalueert, is dit de hands-on tutorial die u van nul naar productie brengt.

Een belangrijke opmerking voor we beginnen: LiteLLM's SDK (de Python-bibliotheek) en de Proxy-server zijn verschillende dingen. De SDK is voor een solo-ontwikkelaar die meerdere LLM-API's vanuit Python aanroept. De proxy is voor teams -- hij staat als server tussen uw apps en LLM-providers. Als u een solo-ontwikkelaar bent die een script schrijft, is de SDK voldoende. Als u sleutels, budgetten en toegang voor een team beheert, heeft u de proxy nodig. Dat is wat we hier instellen.

LiteLLM Proxy in één Oogopslag

Zo vergelijken de deploymethoden zich:

Voor de meeste teams is Docker Compose met PostgreSQL de gouden middenweg. Dat is wat we gaan bouwen -- maar eerst laten we een proxy in 60 seconden draaien.

Vereisten en Omgevingsinrichting

Zorg voor het starten dat u het volgende heeft:

• Docker en Docker Compose geïnstalleerd (Docker Desktop bevat beide)
• Minimaal één LLM API-sleutel (OpenAI, Anthropic of een lokale Ollama-instantie)
• Basiskennis van terminal / CLI

Controleer of Docker klaar is en exporteer uw API-sleutels:

# Controleer of Docker is geïnstalleerd
docker --version
docker compose version

# Exporteer uw LLM API-sleutels (voeg toe aan uw shell-profiel voor persistentie)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Optioneel: stel een mastersleutel in voor uw proxy (u heeft dit later nodig)
export LITELLM_MASTER_KEY="sk-master-uw-geheime-sleutel"

Dat is alles. Geen speciale Python-versie, geen OS-specifieke tooling. Als Docker op uw machine draait, bent u klaar.

Snelstart -- Uw Eerste LiteLLM Proxy in 60 Seconden

Één commando om een proxy met GPT-4o te starten:

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

Of test vanuit Python:

from openai import OpenAI

# Wijs de standaard OpenAI SDK naar uw proxy
client = OpenAI(
    api_key="sk-master-uw-geheime-sleutel",
    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)

Wat is er net gebeurd? Uw code spreekt met localhost:4000 via het standaard OpenAI SDK-formaat. De proxy ontvangt het verzoek, stuurt het door naar OpenAI's API met de echte sleutel, en geeft het antwoord terug. Uw applicatiecode raakt de daadwerkelijke API-sleutel nooit aan.

Dat is het kernconcept. Nu bouwen we een productieopstelling.

Productie Docker Compose Setup met PostgreSQL

Het enkele docker run-commando werkt voor testen, maar productieteams hebben persistente kostenbeheer, virtuele sleutels en goede databaseopslag nodig. Dat betekent Docker Compose met PostgreSQL.

Het Docker Compose-bestand

# docker-compose.yml
version: "3.9"

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    container_name: litellm-proxy
    ports:
      - "4000:4000"         # Proxy API-poort
    volumes:
      - ./config.yaml:/app/config.yaml   # Uw configuratiebestand koppelen
    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:

De LITELLM_SALT_KEY versleutelt virtuele sleutelgegevens in de database. De LiteLLM productie-best-practices documentatie raadt aan dit in te stellen voor elke teamdeployment.

De Stack Starten

# Maak een .env-bestand aan met uw sleutels (commit dit niet naar git)
echo "LITELLM_MASTER_KEY=sk-master-uw-geheim" > .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 alles op
docker compose up -d

# Controleer logs
docker compose logs -f litellm

Alles Controleren

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

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

Als u een succesvolle reactie ziet, draait uw productiestack. PostgreSQL slaat alle kostengegevens, virtuele sleutels en gebruiksmetrieken persistent op over containerherstart heen.

Oordeel: Docker Compose + PostgreSQL is de aanbevolen productie-setup. Het geeft u persistente opslag, kostenbeheer en virtuele sleutels met ongeveer 10 minuten werk. De Docker deployment-documentatie behandelt Kubernetes en Helm als u later auto-scaling nodig heeft.

Config.yaml Uitleg -- Een Echte Multi-Provider Setup

De meeste tutorials tonen een config.yaml met één model. Hier is hoe een echte teamconfiguratie eruit ziet met drie providers, fallbacks en taakverdeling.

Het Configuratiebestand

# config.yaml -- Echte multi-provider setup
model_list:
  # Primair: OpenAI GPT-4o
  - model_name: gpt-4o          # De naam die UW code gebruikt
    litellm_params:
      model: openai/gpt-4o      # De daadwerkelijke provider/model
      api_key: os.environ/OPENAI_API_KEY

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

  # Lokaal: Ollama voor ontwikkeling / kosteloos testen
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://host.docker.internal:11434

  # Fallback: route "gpt-4o" naar Claude als OpenAI down is
  - 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    # Taakverdeling over modellen met dezelfde naam
  num_retries: 3
  retry_after: 5                  # Seconden tussen herhaalpogingen
  fallbacks: [{"gpt-4o": ["claude-sonnet"]}]

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

Modelaliassen en Routering

Let op dat gpt-4o twee keer in de configuratie voorkomt -- eenmaal wijzend naar OpenAI, eenmaal naar Anthropic. Wanneer uw code gpt-4o aanvraagt, probeert LiteLLM eerst OpenAI. Als dat mislukt, routeert de fallbacks-instelling automatisch naar Claude. Uw applicatiecode verandert helemaal niet.

Als u productie-inferentiebackends zoals vLLM of SGLang gebruikt, kunt u die op dezelfde manier toevoegen -- stel gewoon de api_base in op uw inferentieserver.

Snelle Providernaslaglijst

De instelling routing_strategy: least-busy verdeelt verzoeken over modellen met dezelfde model_name. Als u twee OpenAI-sleutels heeft (misschien verschillende organisaties met verschillende snelheidslimieten), vermeld ze beide onder gpt-4o en LiteLLM verdeelt de last.

Virtuele Sleutels -- Team-API-sleutels met Budgetten en Snelheidslimieten

Dit is waar LiteLLM ophoudt "gewoon een proxy" te zijn en een teambeheertool wordt. Virtuele sleutels stellen u in staat om elk teamlid of elke dienst zijn eigen API-sleutel te geven met bestedingslimieten en snelheidsplafonds -- alles gerouteerd via uw enkele set provider-API-sleutels.

Een Teamsleutel met Budget Aanmaken

# Maak een virtuele sleutel aan met een budget van $50/maand
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"}
  }'

Het antwoord geeft u een nieuwe sleutel zoals sk-team-abc123.... Geef die aan het frontend-team. Ze kunnen het precies als een OpenAI-sleutel gebruiken, maar het is beperkt tot $50/maand en heeft alleen toegang tot de modellen die u heeft opgegeven.

Snelheidslimieten Instellen

# Maak een sleutel aan met snelheidslimieten: 100 verzoeken/minuut, 50K tokens/minuut
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"]
  }'

De documentatie over virtuele sleutels behandelt elke parameter. U kunt ook budgetten en snelheidslimieten per gebruiker instellen voor nog gedetailleerdere controle.

Sleutelgebruik Monitoren

import requests

# Controleer de huidige uitgaven en limieten van een sleutel
response = requests.get(
    "http://localhost:4000/key/info",
    headers={"Authorization": f"Bearer {MASTER_KEY}"},
    params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Uitgegeven: ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM gebruikt: {info['rpm_limit_used']} / {info['rpm_limit']}")

Moet u een gecompromitteerde sleutel intrekken? Één API-aanroep:

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

Oordeel: Virtuele sleutels maken LiteLLM een teamtool, niet alleen een persoonlijke proxy. Zonder hen voegt u alleen maar een stap toe tussen uw code en het LLM. Met hen heeft u toegangscontrole, budgethandhaving en gebruikstoewijzing -- het soort dingen dat uw CFO gerust stelt.

Kostenbeheer en het LiteLLM-dashboard

Zodra PostgreSQL is verbonden, volgt LiteLLM automatisch de kosten van elk verzoek. U hoeft niets te configureren -- het kent de prijs per token voor elk ondersteund model.

Het Dashboard

Ga naar de ingebouwde interface op http://localhost:4000/ui (log in met uw mastersleutel). U ziet:

• Totale uitgaven over alle teams en sleutels
• Per-model uitsplitsing -- welke modellen uw budget opeten
• Per-team uitgaven -- wie wat gebruikt
• Verzoekvolume in de tijd

Voor teams die serieus zijn over het verminderen van LLM API-kosten, rechtvaardigt het dashboard alleen al het draaien van de proxy. U kunt LiteLLM ook verbinden met externe AI-observabiliteitsplatforms zoals Langfuse of Helicone voor diepere analyses.

Kostensvergelijking per Provider

Dit kosten de belangrijkste modellen per miljoen tokens (april 2026):

Wanneer u deze cijfers ziet in het dashboard opgesplitst per team, worden de gesprekken over "moeten we een goedkoper model gebruiken voor dit gebruik?" heel concreet.

Oordeel: Kostenbeheer alleen al rechtvaardigt de proxy voor elk team dat meer dan $100/maand uitgeeft aan LLM-API's. U kunt niet optimaliseren wat u niet kunt meten.

AI-IDE's Verbinden -- Claude Code, Cursor en Continue

Hier is iets dat de meeste LiteLLM-handleidingen volledig overslaan: u kunt uw AI-codeertools ook naar de proxy laten wijzen. Één proxy, al uw IDE-tools, geünificeerde facturering.

Claude Code

# Stel Claude Code in om uw LiteLLM-proxy te gebruiken
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-uw-virtuele-sleutel

Dat is het. Claude Code stuurt verzoeken naar uw proxy, die ze naar Anthropic stuurt (of waar uw configuratie dat aangeeft) terwijl de kosten worden bijgehouden onder uw virtuele sleutel.

Cursor

Voeg in de instellingen van Cursor een aangepast OpenAI-compatibel eindpunt toe:

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-uw-virtuele-sleutel"
}

Continue (VS Code)

In Continue's config.json:

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

Waarom de moeite doen? Omdat nu het IDE-gebruik van elke ontwikkelaar door de proxy gaat. U krijgt kostenbeheer per persoon voor AI-codeerassistenten, snelheidslimieten zodat niemand per ongeluk €500 verbrandt in een codeersessie, en één plek om van model te wisselen als u een betere optie vindt.

Veelvoorkomende Problemen Oplossen

"Configuratiebestand niet gevonden"

Dit betekent meestal dat het volume-koppelpad onjuist is in Docker. Zorg ervoor dat uw config.yaml zich bevindt in de map waaruit u koppelt:

# Controleer of het bestand bestaat waar u denkt dat het is
ls -la ./config.yaml

# De volume-koppeling in docker-compose.yml moet overeenkomen
# volumes:
#   - ./config.yaml:/app/config.yaml

"Verbinding geweigerd" naar PostgreSQL

Docker-netwerken pakken iedereen minimaal één keer. Als LiteLLM Postgres niet kan bereiken, controleer dan of:

• De servicenaam in DATABASE_URL overeenkomt met de Docker Compose-servicenaam (postgres, niet localhost)
• De depends_on met condition: service_healthy is ingesteld (zodat LiteLLM wacht tot Postgres klaar is)
• Beide services zich op hetzelfde Docker-netwerk bevinden (dat zijn ze standaard in Compose)

"Ongeldig API-sleutelformaat"

De meest voorkomende verwarring: uw LITELLM_MASTER_KEY is voor beheerbewerkingen (virtuele sleutels aanmaken, het dashboard openen). Virtuele sleutels (sk-team-...) zijn wat uw applicaties gebruiken. Verwar ze niet.

"Model niet gevonden"

Het model-veld in uw verzoek moet overeenkomen met een model_name in config.yaml. Als uw configuratie gpt-4o definieert maar uw code openai/gpt-4o aanvraagt, komt het niet overeen. Controleer de exacte spelling.

Proxy start maar verzoeken hangen

Gewoonlijk een firewall- of poortbindingsprobleem. Controleer of poort 4000 beschikbaar is en niet geblokkeerd:

# Controleer of de poort luistert
docker port litellm-proxy
# Zou moeten tonen: 4000/tcp -> 0.0.0.0:4000

Beveiliging: Vermijd Versies 1.82.7 en 1.82.8

In maart 2026 trof een supply chain-incident de LiteLLM-versies 1.82.7 en 1.82.8. De gecompromitteerde versies werden ingetrokken en een schone release werd uitgebracht op 1.83.0. Pin uw Docker-image altijd aan een specifieke versie en controleer de officiële beveiligingsupdate voor het upgraden. Als u op 1.82.7 of 1.82.8 zit, update onmiddellijk.

Welke LiteLLM-installatiemethode Moet U Kiezen?

Als u deze handleiding voor het eerst leest, begin dan met Docker Compose + PostgreSQL. U kunt altijd later naar Kubernetes migreren -- de config.yaml blijft hetzelfde.

FAQ

Wat is de LiteLLM-proxy en hoe werkt het?

De LiteLLM-proxy is een open-source AI-gatewayserver die tussen uw applicaties en LLM-providers zoals OpenAI en Anthropic staat. Het biedt één enkel OpenAI-compatibel eindpunt, zodat uw code met één URL communiceert terwijl de proxy routering, sleutelbeheer, kostenbeheer en fallbacks achter de schermen afhandelt.

Hoe stel ik de LiteLLM-proxy in met Docker Compose?

Maak een docker-compose.yml aan met het LiteLLM-proxy-image en een PostgreSQL-database, koppel uw config.yaml, stel uw API-sleutels in als omgevingsvariabelen en voer docker compose up -d uit. De sectie "Productie Docker Compose Setup" hierboven bevat een compleet, kopieerklaar bestand.

Hoe beheer ik team-API-sleutels met LiteLLM?

Gebruik virtuele sleutels. Roep het /key/generate-eindpunt aan met uw mastersleutel om per-team of per-gebruiker sleutels aan te maken. Elke virtuele sleutel kan zijn eigen maandelijkse budget, snelheidslimieten (RPM en TPM) en modeltoegangsrestricties hebben. De sectie "Virtuele Sleutels" behandelt de volledige workflow.

Hoe voeg ik kostenbeheer en snelheidslimieten toe aan mijn LLM-API?

Verbind PostgreSQL met de proxy (via DATABASE_URL) en kostenbeheer gebeurt automatisch. Voor snelheidslimieten stelt u rpm_limit en tpm_limit in bij het genereren van virtuele sleutels. Het ingebouwde dashboard op /ui toont uitgaven per team en per model.

Is de LiteLLM-proxy veilig te gebruiken in productie?

Ja, met één voorbehoud: vermijd versies 1.82.7 en 1.82.8, die getroffen werden door een supply chain-incident in maart 2026. Gebruik versie 1.83.0 of later. Pin uw Docker-imageversie, stel de LITELLM_SALT_KEY in voor encryptie en volg de officiële productie-best-practices.

Wat is het verschil tussen de LiteLLM SDK en de LiteLLM-proxy?

De SDK is een Python-bibliotheek voor het aanroepen van meerdere LLM-API's vanuit uw code. De proxy is een zelfstandige server waarmee uw hele team verbinding maakt. Gebruik de SDK wanneer u een solo-dev bent die een script schrijft. Gebruik de proxy wanneer u gedeelde toegangscontrole, kostenbeheer en snelheidslimieten over een team nodig heeft.

Kan ik de LiteLLM-proxy gebruiken met Ollama en lokale modellen?

Absoluut. Voeg een vermelding toe aan uw config.yaml met model: ollama/llama3.1 en api_base: http://host.docker.internal:11434 (of uw Ollama-host). Uw team kan dan lokale modellen benaderen via hetzelfde proxy-eindpunt, wat geweldig is voor ontwikkeling en kosteloos testen.

Hoeveel kost de LiteLLM-proxy?

De LiteLLM-proxy is gratis en open-source (MIT-licentie). U host het zelf op uw eigen infrastructuur. De enige kosten zijn uw server (een kleine VPS is voldoende voor de meeste teams) en de LLM-API-kosten die u al betaalt. BerriAI biedt ook een beheerde cloudversie aan als u niet zelf wilt hosten.

Welke providers ondersteunt LiteLLM?

Meer dan 100, waaronder OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Ollama, Hugging Face, Cohere, Replicate en vele anderen. De volledige lijst staat op het LiteLLM GitHub-repository.

Hoe update ik de LiteLLM-proxy veilig?

Pin altijd een specifieke versie in uw Docker-image-tag (bijv. ghcr.io/berriai/litellm:v1.83.2-stable). Controleer voor het upgraden het changelog op breaking changes. Gebruik nooit latest in productie. Controleer altijd of de nieuwe versie niet op de beveiligingsadvieslijst staat -- het incident van maart 2026 bewees dat zelfs vertrouwde pakketten gecompromitteerd kunnen worden.

Eindoordeel en Volgende Stappen

Als uw team geld uitgeeft aan LLM-API's en u heeft nog geen proxy, begin dan vandaag met Docker Compose + Postgres. De setup duurt 15 minuten en u heeft aan het einde kostenzichtbaarheid en toegangscontrole.

Zodra u draait, verken dan het toevoegen van guardrails aan uw LLM-pipeline voor inhoudsfiltering en veiligheidscontroles. De proxy is het fundament -- al het andere bouwt daarop voort.

Bronnen

• LiteLLM Proxy Snelstart -- Officiële documentatie
• LiteLLM Docker Deployment-handleiding
• LiteLLM Documentatie voor virtuele sleutels
• LiteLLM Productie-best-practices
• LiteLLM Beveiligingsupdate -- Maart 2026
• BerriAI/litellm -- GitHub-repository