LiteLLM Proxy : 1 API pour 100+ LLMs (installation Docker en 15 min)

Configuration du Proxy LiteLLM : Clés, Coûts et Limites de Débit

Votre équipe partage des clés API OpenAI dans des DMs Slack. Personne ne sait qui a dépensé 400 € mardi dernier. Il n'y a pas de limite de débit, pas de fallback quand un fournisseur tombe en panne, et passer de GPT-4o à Claude implique de modifier le code à douze endroits. Ça vous semble familier ? Une passerelle LLM auto-hébergée résout tout cela, et le proxy LiteLLM est l'option open source la plus populaire -- un seul point de terminaison compatible OpenAI qui route les requêtes vers plus de 100 fournisseurs LLM.

Ce guide couvre la configuration complète du proxy LiteLLM : Docker Compose avec PostgreSQL, clés d'équipe virtuelles avec budgets, suivi des coûts, limites de débit, et connexion des IDEs IA comme Claude Code et Cursor. Si vous évaluez des outils de passerelle LLM, c'est le tutoriel pratique qui vous emmène de zéro à la production.

Une remarque importante avant de commencer : le SDK LiteLLM (la bibliothèque Python) et le Serveur Proxy sont des choses différentes. Le SDK est pour un développeur solo appelant plusieurs APIs LLM depuis Python. Le proxy est pour les équipes -- il siège comme un serveur entre vos applications et les fournisseurs LLM. Si vous êtes un dev solo écrivant un script, le SDK suffit. Si vous gérez des clés, des budgets et des accès pour une équipe, vous avez besoin du proxy. C'est ce que nous configurons ici.

Le Proxy LiteLLM en un Coup d'Œil

Voici comment les méthodes de déploiement se comparent :

Pour la plupart des équipes, Docker Compose avec PostgreSQL est le juste milieu. C'est ce que nous allons construire -- mais d'abord, faisons tourner un proxy en 60 secondes.

Prérequis et Configuration de l'Environnement

Avant de commencer, assurez-vous d'avoir :

• Docker et Docker Compose installés (Docker Desktop inclut les deux)
• Au moins une clé API LLM (OpenAI, Anthropic, ou une instance Ollama locale)
• Des bases en terminal / CLI

Vérifiez que Docker est prêt et exportez vos clés API :

# Vérifier que Docker est installé
docker --version
docker compose version

# Exporter vos clés API LLM (ajoutez à votre profil shell pour la persistance)
export OPENAI_API_KEY="sk-..."
export ANTHROPIC_API_KEY="sk-ant-..."

# Optionnel : définir une clé maître pour votre proxy (vous en aurez besoin plus tard)
export LITELLM_MASTER_KEY="sk-master-votre-clé-secrète"

C'est tout. Pas de version Python spéciale, pas d'outil spécifique à l'OS. Si Docker tourne sur votre machine, vous êtes prêt.

Démarrage Rapide -- Votre Premier Proxy LiteLLM en 60 Secondes

Une commande pour démarrer un proxy avec 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

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

Ou testez depuis Python :

from openai import OpenAI

# Pointez le SDK OpenAI standard vers votre proxy
client = OpenAI(
    api_key="sk-master-votre-clé-secrète",
    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)

Que vient-il de se passer ? Votre code parle à localhost:4000 en utilisant le format SDK OpenAI standard. Le proxy reçoit la requête, la transmet à l'API d'OpenAI avec la vraie clé, et retourne la réponse. Votre code d'application ne touche jamais la vraie clé API.

C'est l'idée centrale. Maintenant construisons une configuration de production.

Configuration Docker Compose de Production avec PostgreSQL

La commande docker run unique fonctionne pour les tests, mais les équipes en production ont besoin d'un suivi des coûts persistant, de clés virtuelles et d'un stockage de base de données approprié. Cela signifie Docker Compose avec PostgreSQL.

Le Fichier Docker Compose

# docker-compose.yml
version: "3.9"

services:
  litellm:
    image: ghcr.io/berriai/litellm:main-stable
    container_name: litellm-proxy
    ports:
      - "4000:4000"         # Port API proxy
    volumes:
      - ./config.yaml:/app/config.yaml   # Monter votre fichier de config
    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:

Le LITELLM_SALT_KEY chiffre les données des clés virtuelles dans la base de données. La documentation des meilleures pratiques de production LiteLLM recommande de le définir pour tout déploiement d'équipe.

Démarrer la Stack

# Créer un fichier .env avec vos clés (ne commitez pas cela dans git)
echo "LITELLM_MASTER_KEY=sk-master-votre-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

# Démarrer tout
docker compose up -d

# Vérifier les logs
docker compose logs -f litellm

Vérifier que Tout Fonctionne

# Vérification de santé
curl http://localhost:4000/health

# Tester une requête
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"}]}'

Si vous voyez une réponse réussie, votre stack de production tourne. PostgreSQL stocke toutes les données de coûts, les clés virtuelles et les métriques d'utilisation de façon persistante à travers les redémarrages de conteneurs.

Verdict : Docker Compose + PostgreSQL est la configuration de production recommandée. Elle vous donne un stockage persistant, un suivi des coûts et des clés virtuelles en environ 10 minutes de travail. La documentation de déploiement Docker couvre Kubernetes et Helm si vous avez besoin d'auto-scaling plus tard.

Explication de Config.yaml -- Une Vraie Configuration Multi-Fournisseur

La plupart des tutoriels montrent une config.yaml avec un seul modèle. Voici à quoi ressemble une vraie config d'équipe avec trois fournisseurs, des fallbacks et de l'équilibrage de charge.

Le Fichier de Configuration

# config.yaml -- Vraie configuration multi-fournisseur
model_list:
  # Principal : OpenAI GPT-4o
  - model_name: gpt-4o          # Le nom que VOTRE code utilise
    litellm_params:
      model: openai/gpt-4o      # Le fournisseur/modèle réel
      api_key: os.environ/OPENAI_API_KEY

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

  # Local : Ollama pour le développement / tests sans coût
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.1
      api_base: http://host.docker.internal:11434

  # Fallback : router "gpt-4o" vers Claude si OpenAI est 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    # Équilibrer la charge sur les modèles du même nom
  num_retries: 3
  retry_after: 5                  # Secondes entre les tentatives
  fallbacks: [{"gpt-4o": ["claude-sonnet"]}]

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

Alias de Modèles et Routage

Remarquez que gpt-4o apparaît deux fois dans la config -- une fois pointant vers OpenAI, une fois vers Anthropic. Quand votre code demande gpt-4o, LiteLLM essaie d'abord OpenAI. Si ça échoue, le paramètre fallbacks route automatiquement vers Claude. Votre code d'application ne change pas du tout.

Si vous utilisez des backends d'inférence en production comme vLLM ou SGLang, vous pouvez les ajouter de la même façon -- définissez juste api_base à votre serveur d'inférence.

Référence Rapide des Fournisseurs

Le paramètre routing_strategy: least-busy distribue les requêtes sur les modèles avec le même model_name. Si vous avez deux clés OpenAI (peut-être différentes organisations avec différentes limites de débit), listez-les toutes les deux sous gpt-4o et LiteLLM équilibre la charge.

Clés Virtuelles -- Clés API par Équipe avec Budgets et Limites de Débit

C'est là que LiteLLM cesse d'être "juste un proxy" et devient un outil de gestion d'équipe. Les clés virtuelles vous permettent de donner à chaque membre de l'équipe ou service sa propre clé API avec des limites de dépenses et des plafonds de débit -- tout routé à travers votre ensemble unique de clés API fournisseur.

Créer une Clé d'Équipe avec Budget

# Créer une clé virtuelle avec un budget de 50 $/mois
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"}
  }'

La réponse vous donne une nouvelle clé comme sk-team-abc123.... Donnez-la à l'équipe frontend. Ils peuvent l'utiliser exactement comme une clé OpenAI, mais elle est limitée à 50 $/mois et n'a accès qu'aux modèles que vous avez spécifiés.

Définir des Limites de Débit

# Créer une clé avec des limites de débit : 100 requêtes/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"]
  }'

La documentation des clés virtuelles couvre chaque paramètre. Vous pouvez également définir des budgets et limites de débit par utilisateur pour un contrôle encore plus granulaire.

Surveiller l'Utilisation des Clés

import requests

# Vérifier les dépenses actuelles et les limites d'une clé
response = requests.get(
    "http://localhost:4000/key/info",
    headers={"Authorization": f"Bearer {MASTER_KEY}"},
    params={"key": "sk-team-abc123..."}
)
info = response.json()
print(f"Dépensé : ${info['spend']:.2f} / ${info['max_budget']:.2f}")
print(f"RPM utilisé : {info['rpm_limit_used']} / {info['rpm_limit']}")

Besoin de révoquer une clé compromise ? Un appel API :

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

Verdict : Les clés virtuelles font de LiteLLM un outil d'équipe, pas juste un proxy personnel. Sans elles, vous ne faites qu'ajouter un saut entre votre code et le LLM. Avec elles, vous avez le contrôle d'accès, l'application du budget et l'attribution de l'utilisation -- le genre de choses qui évite à votre DAF de paniquer.

Suivi des Coûts et le Tableau de Bord LiteLLM

Une fois PostgreSQL connecté, LiteLLM suit automatiquement le coût de chaque requête. Vous n'avez rien à configurer -- il connaît le prix par token pour chaque modèle supporté.

Le Tableau de Bord

Accédez à l'interface intégrée à http://localhost:4000/ui (connectez-vous avec votre clé maître). Vous verrez :

• Dépenses totales sur toutes les équipes et clés
• Répartition par modèle -- quels modèles consomment votre budget
• Dépenses par équipe -- qui utilise quoi
• Volume de requêtes dans le temps

Pour les équipes sérieuses à propos de la réduction des coûts API LLM, le tableau de bord seul justifie le proxy. Vous pouvez également connecter LiteLLM à des plateformes d'observabilité IA externes comme Langfuse ou Helicone pour des analyses plus approfondies.

Comparaison des Coûts par Fournisseur

Voici ce que coûtent les principaux modèles par million de tokens (en avril 2026) :

Quand vous voyez ces chiffres dans le tableau de bord décomposés par équipe, les conversations sur "devrions-nous utiliser un modèle moins cher pour ce cas d'usage ?" deviennent très concrètes.

Verdict : Le suivi des coûts seul justifie le proxy pour toute équipe dépensant plus de 100 $/mois en APIs LLM. Vous ne pouvez pas optimiser ce que vous ne mesurez pas.

Connecter les IDEs IA -- Claude Code, Cursor et Continue

Voici quelque chose que la plupart des guides LiteLLM sautent entièrement : vous pouvez également pointer vos outils de codage IA vers le proxy. Un proxy, tous vos outils IDE, facturation unifiée.

Claude Code

# Définir Claude Code pour utiliser votre proxy LiteLLM
export ANTHROPIC_BASE_URL=http://localhost:4000/v1
export ANTHROPIC_API_KEY=sk-team-votre-clé-virtuelle

C'est tout. Claude Code envoie des requêtes à votre proxy, qui les route vers Anthropic (ou là où votre config dit) tout en suivant les coûts sous votre clé virtuelle.

Cursor

Dans les paramètres de Cursor, ajoutez un point de terminaison compatible OpenAI personnalisé :

{
  "openai.apiBaseUrl": "http://localhost:4000/v1",
  "openai.apiKey": "sk-team-votre-clé-virtuelle"
}

Continue (VS Code)

Dans le config.json de Continue :

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

Pourquoi s'embêter ? Parce que maintenant toute l'utilisation IDE de chaque développeur passe par le proxy. Vous obtenez un suivi des coûts par personne pour les assistants de codage IA, des limites de débit pour que personne ne brûle accidentellement 500 € en une session de codage, et un seul endroit pour changer de modèle si vous en trouvez un meilleur.

Résolution des Problèmes Courants

"Fichier de configuration introuvable"

Cela signifie généralement que le chemin de montage du volume est incorrect dans Docker. Assurez-vous que votre config.yaml est dans le répertoire depuis lequel vous montez :

# Vérifier que le fichier existe là où vous pensez
ls -la ./config.yaml

# Le montage du volume dans docker-compose.yml devrait correspondre
# volumes:
#   - ./config.yaml:/app/config.yaml

"Connexion refusée" vers PostgreSQL

Le réseau Docker prend tout le monde au moins une fois. Si LiteLLM ne peut pas atteindre Postgres, vérifiez que :

• Le nom du service dans DATABASE_URL correspond au nom du service Docker Compose (postgres, pas localhost)
• Le depends_on avec condition: service_healthy est défini (pour que LiteLLM attende que Postgres soit prêt)
• Les deux services sont sur le même réseau Docker (ils le sont par défaut dans Compose)

"Format de clé API invalide"

La confusion la plus courante : votre LITELLM_MASTER_KEY est pour les opérations admin (créer des clés virtuelles, accéder au tableau de bord). Les clés virtuelles (sk-team-...) sont ce que vos applications utilisent. Ne les mélangez pas.

"Modèle introuvable"

Le champ model dans votre requête doit correspondre à un model_name dans config.yaml. Si votre config définit gpt-4o mais que votre code demande openai/gpt-4o, ça ne correspondra pas. Vérifiez l'orthographe exacte.

Le proxy démarre mais les requêtes restent bloquées

Généralement un problème de pare-feu ou de liaison de port. Vérifiez que le port 4000 est exposé et non bloqué :

# Vérifier si le port est en écoute
docker port litellm-proxy
# Devrait afficher : 4000/tcp -> 0.0.0.0:4000

Sécurité : Évitez les Versions 1.82.7 et 1.82.8

En mars 2026, un incident de chaîne d'approvisionnement a affecté les versions LiteLLM 1.82.7 et 1.82.8. Les versions compromises ont été retirées, et une version propre a été publiée à la version 1.83.0. Épinglez toujours votre image Docker à une version spécifique et vérifiez la mise à jour de sécurité officielle avant de mettre à jour. Si vous êtes sur 1.82.7 ou 1.82.8, mettez à jour immédiatement.

Quelle Méthode de Configuration LiteLLM Choisir ?

Si vous lisez ce guide pour la première fois, commencez avec Docker Compose + PostgreSQL. Vous pouvez toujours migrer vers Kubernetes plus tard -- la config.yaml reste la même.

FAQ

Qu'est-ce que le proxy LiteLLM et comment fonctionne-t-il ?

Le proxy LiteLLM est un serveur passerelle IA open source qui siège entre vos applications et les fournisseurs LLM comme OpenAI et Anthropic. Il expose un seul point de terminaison compatible OpenAI, donc votre code parle à une URL pendant que le proxy gère le routage, la gestion des clés, le suivi des coûts et les fallbacks en coulisses.

Comment configurer le proxy LiteLLM avec Docker Compose ?

Créez un docker-compose.yml avec l'image du proxy LiteLLM et une base de données PostgreSQL, montez votre config.yaml, définissez vos clés API comme variables d'environnement, et exécutez docker compose up -d. La section "Configuration Docker Compose de Production" ci-dessus contient un fichier complet prêt à copier-coller.

Comment gérer les clés API d'équipe avec LiteLLM ?

Utilisez des clés virtuelles. Appelez le point de terminaison /key/generate avec votre clé maître pour créer des clés par équipe ou par utilisateur. Chaque clé virtuelle peut avoir son propre budget mensuel, ses limites de débit (RPM et TPM) et ses restrictions d'accès aux modèles. La section "Clés Virtuelles" couvre le workflow complet.

Comment ajouter le suivi des coûts et les limites de débit à mon API LLM ?

Connectez PostgreSQL au proxy (via DATABASE_URL), et le suivi des coûts se fait automatiquement. Pour les limites de débit, définissez rpm_limit et tpm_limit lors de la génération des clés virtuelles. Le tableau de bord intégré à /ui montre les dépenses par équipe et par modèle.

Le proxy LiteLLM est-il sûr à utiliser en production ?

Oui, avec une mise en garde : évitez les versions 1.82.7 et 1.82.8, qui ont été affectées par un incident de chaîne d'approvisionnement en mars 2026. Utilisez la version 1.83.0 ou ultérieure. Épinglez la version de votre image Docker, définissez le LITELLM_SALT_KEY pour le chiffrement, et suivez les meilleures pratiques de production officielles.

Quelle est la différence entre le SDK LiteLLM et le proxy LiteLLM ?

Le SDK est une bibliothèque Python pour appeler plusieurs APIs LLM depuis votre code. Le proxy est un serveur autonome auquel toute votre équipe se connecte. Utilisez le SDK quand vous êtes un dev solo écrivant un script. Utilisez le proxy quand vous avez besoin d'un contrôle d'accès partagé, d'un suivi des coûts et de limites de débit sur une équipe.

Puis-je utiliser le proxy LiteLLM avec Ollama et des modèles locaux ?

Absolument. Ajoutez une entrée à votre config.yaml avec model: ollama/llama3.1 et api_base: http://host.docker.internal:11434 (ou votre hôte Ollama). Votre équipe peut alors accéder aux modèles locaux via le même point de terminaison proxy, ce qui est excellent pour le développement et les tests sans coût.

Combien coûte le proxy LiteLLM ?

Le proxy LiteLLM est gratuit et open source (licence MIT). Vous l'hébergez vous-même sur votre propre infrastructure. Les seuls coûts sont votre serveur (un petit VPS suffit pour la plupart des équipes) et les coûts API LLM que vous payez déjà. BerriAI propose également une version cloud gérée si vous ne voulez pas l'auto-héberger.

Quels fournisseurs LiteLLM supporte-t-il ?

Plus de 100, dont OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex AI, Ollama, Hugging Face, Cohere, Replicate, et bien d'autres. La liste complète est sur le dépôt GitHub LiteLLM.

Comment mettre à jour le proxy LiteLLM en toute sécurité ?

Épinglez toujours une version spécifique dans votre tag d'image Docker (ex: ghcr.io/berriai/litellm:v1.83.2-stable). Avant de mettre à jour, vérifiez le changelog pour les changements cassants. N'utilisez jamais latest en production. Et vérifiez toujours que la nouvelle version n'est pas sur la liste des avis de sécurité -- l'incident de mars 2026 a prouvé que même des paquets de confiance peuvent être compromis.

Verdict Final et Prochaines Étapes

Si votre équipe dépense de l'argent en APIs LLM et que vous n'avez pas encore de proxy, commencez avec Docker Compose + Postgres aujourd'hui. La configuration prend 15 minutes, et vous aurez la visibilité des coûts et le contrôle d'accès à la fin.

Une fois que vous êtes opérationnel, explorez l'ajout de garde-fous à votre pipeline LLM pour le filtrage de contenu et les vérifications de sécurité. Le proxy est la fondation -- tout le reste se construit par-dessus.

Sources

• Proxy LiteLLM Démarrage Rapide -- Documentation officielle
• Guide de Déploiement Docker LiteLLM
• Documentation des Clés Virtuelles LiteLLM
• Meilleures Pratiques de Production LiteLLM
• Mise à Jour de Sécurité LiteLLM -- Mars 2026
• BerriAI/litellm -- Dépôt GitHub