Quand vous utilisez en même temps OpenAI, Claude, DeepSeek et Gemini, le plus compliqué n'est souvent pas de choisir un modèle, mais de gérer des formats de requête, des clés et des règles de facturation différents pour chaque SDK. LiteLLM est un projet open source né pour résoudre ce problème : il unifie plusieurs fournisseurs derrière une interface compatible OpenAI et fournit une passerelle que vous pouvez héberger vous-même.

Cet article explique ce qu'est LiteLLM, la configuration minimale, le routage et la gestion des clés, les modes de déploiement, puis comment choisir entre auto-hébergement et passerelle gérée.

Remarque : LiteLLM est un projet open source de son détenteur ; OpenAI, Anthropic, DeepSeek et les autres noms cités sont des marques de leurs détenteurs respectifs. Cet article se réfère aux versions courantes d'octobre 2026 ; les paramètres exacts sont ceux de la documentation officielle.

1. Ce qu'est réellement LiteLLM

LiteLLM existe sous deux formes :

  • SDK Python : appeler les modèles de différents fournisseurs depuis le code avec une fonction completion unifiée.
  • Passerelle Proxy : un service autonome qui expose un endpoint /v1/chat/completions compatible OpenAI, auquel tout client acceptant une Base URL personnalisée peut se connecter.

Il résout trois choses : l'adaptation des protocoles, le routage et la comptabilité. Il ne rend pas un modèle meilleur. Autrement dit, c'est un tuyau, pas un modèle.

Ses capacités principales :

Capacité Rôle
Protocole unifié Les modèles de plusieurs fournisseurs passent au format OpenAI
Routage et équilibrage Un même nom de modèle distribué sur plusieurs déploiements
Basculement Passage à un modèle de secours en cas d'échec du principal
Clés virtuelles Clés et budgets distincts par équipe ou projet
Usage et coûts Enregistrement des requêtes, tokens et dépenses
Rappels de journaux Intégration avec Langfuse, OpenTelemetry, etc.

2. Minimum viable : démarrer avec pip

Créez d'abord un environnement virtuel, puis installez le paquet avec le proxy :

python3 -m venv .venv
source .venv/bin/activate
pip install "litellm[proxy]"

Écrivez un config.yaml minimal :

model_list:
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-4-5
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: deepseek-chat
    litellm_params:
      model: deepseek/deepseek-chat
      api_key: os.environ/DEEPSEEK_API_KEY

litellm_settings:
  drop_params: true

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY

Lancement :

export ANTHROPIC_API_KEY="sk-ant-votre-clé"
export DEEPSEEK_API_KEY="sk-votre-clé"
export LITELLM_MASTER_KEY="sk-litellm-clé-admin-locale"
litellm --config config.yaml --port 4000

model_name est le nom exposé vers l'extérieur ; litellm_params.model est le modèle amont réel, généralement au format « fournisseur/nom-du-modèle ». os.environ/XXX indique une lecture depuis les variables d'environnement : n'écrivez pas les clés en clair dans le YAML puis ne commitez pas le fichier dans le dépôt.

Une fois lancé, pointez le SDK OpenAI vers la passerelle locale :

from openai import OpenAI

client = OpenAI(
    api_key="sk-litellm-clé-admin-locale",
    base_url="http://127.0.0.1:4000",
)
resp = client.chat.completions.create(
    model="claude-sonnet",
    messages=[{"role": "user", "content": "Réponds seulement OK"}],
)
print(resp.choices[0].message.content)

3. Routage des modèles et basculement

En production, on n'accroche rarement un seul amont. Configuration courante :

router_settings:
  routing_strategy: simple-shuffle
  num_retries: 2
  timeout: 600
  fallbacks:
    - claude-sonnet: ["deepseek-chat"]

Signification des paramètres :

  • routing_strategy : comment choisir entre plusieurs déploiements d'un même modèle ; simple-shuffle est un point de départ courant.
  • num_retries : nombre de nouvelles tentatives ; chaque retry génère un coût réel.
  • timeout : délai maximal d'une requête, à régler sur le chemin métier le plus lent.
  • fallbacks : modèle de secours lorsque le principal est indisponible.

Le basculement n'est pas gratuit. Le style de sortie, la longueur de contexte et les capacités d'appel d'outils du modèle de secours peuvent différer ; il faut que le métier l'accepte. Pour les cas stricts sur le format, mieux vaut une erreur explicite qu'une dégradation silencieuse.

4. Clés virtuelles et budgets

Partager une seule master key dans une équipe est le début d'un incident d'exploitation. La bonne pratique consiste à émettre une clé virtuelle par projet, avec modèles et budget limités :

curl -X POST "http://127.0.0.1:4000/key/generate" \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "models": ["claude-sonnet"],
    "max_budget": 20,
    "duration": "30d",
    "metadata": {"project": "demo"}
  }'

La clé renvoyée est remise à l'équipe métier ; la master key reste entre les mains de l'exploitation. L'unité et la devise du budget suivent la documentation LiteLLM ; cet exemple ne montre que la structure des champs et n'implique aucun tarif.

5. Déploiement Docker et contrôles avant mise en ligne

Pour un essai sur une seule machine, un conteneur suffit :

docker run -d --name litellm \
  -p 4000:4000 \
  -v "$(pwd)/config.yaml:/app/config.yaml" \
  -e ANTHROPIC_API_KEY \
  -e DEEPSEEK_API_KEY \
  -e LITELLM_MASTER_KEY \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml

Avant la mise en ligne, vérifiez au minimum :

  1. N'exposez pas la passerelle directement sur Internet ; placez Nginx ou Caddy devant pour TLS et contrôle d'accès.
  2. Utilisez une master key aléatoire forte, jamais dans le dépôt de code.
  3. Si vous devez conserver l'usage en base, connectez PostgreSQL ; sinon certaines statistiques sont perdues au redémarrage.
  4. Configurez la rotation des journaux et une alerte disque, car les logs de requêtes grossissent vite.
  5. Prévoyez un health check : curl http://127.0.0.1:4000/health.
  6. Lisez le changelog avant toute mise à jour et fixez un tag de version d'image ; n'utilisez pas latest durablement.

Un point souvent oublié : la passerelle devient un nouveau point unique de défaillance. Si elle tombe, tous les modèles tombent. Prévoyez au moins une supervision de processus, un redémarrage automatique et une chaîne d'alerte indépendante.

6. Journaux et coûts : n'attendez pas la facture

La valeur cachée d'une passerelle est d'enregistrer les appels. LiteLLM peut consigner pour chaque requête le modèle, les tokens, la latence et le coût, puis agréger par clé, équipe ou étiquette. Pour aller au bout, trois étapes :

  1. Configurez une base de données pour persister les coûts, au lieu de les garder en mémoire.
  2. Étiquetez les requêtes, par exemple avec le nom du projet dans les métadonnées, sinon la ventilation mensuelle par projet est impossible.
  3. Branchez un backend d'observabilité pour centraliser traces et journaux.

Exemple de configuration :

litellm_settings:
  success_callback: ["langfuse"]
  failure_callback: ["langfuse"]

general_settings:
  database_url: os.environ/DATABASE_URL

Deux précautions : d'une part, le service de rappel doit lui aussi être hautement disponible, car un rappel bloquant peut ralentir la requête principale ; d'autre part, les journaux peuvent contenir le texte des utilisateurs, donc fixez à l'avance la durée de conservation et les droits d'accès, sans conserver indéfiniment les logs de production.

Côté coûts, la passerelle permet de voir les dépenses, pas de les réduire automatiquement. Les vrais leviers restent le bon choix de modèle, la compression du contexte et la maîtrise du nombre de retries.

7. Auto-hébergement ou passerelle gérée

Dimension LiteLLM auto-hébergé Passerelle IA gérée
Chemin des données Entièrement sous votre contrôle Passe par le prestataire
Coût initial Faible, opérationnel après installation Inscription immédiate
Exploitation long terme Mises à jour, sauvegardes, supervision à votre charge Assurée par le prestataire
Facturation et factures Raccordement amont à votre charge Facturation unifiée en yuans
Flexibilité Élevée, code et routage modifiables Limitée aux capacités de la plateforme
Responsabilité en cas d'incident À votre charge Selon les conditions de service

Un critère pratique :

  • Vous avez une équipe d'exploitation, des exigences de conformité et besoin d'un routage sur mesure : choisissez l'auto-hébergement.
  • L'équipe est petite, vous voulez seulement unifier les clés et la facturation, sans réparer des conteneurs la nuit : choisissez le service géré.
  • Vous pouvez aussi valider le métier sur une passerelle gérée, puis évaluer l'auto-hébergement une fois le volume stabilisé.

Les équipes en Chine doivent en outre tenir compte du réseau. Une passerelle auto-hébergée ne résout pas l'accessibilité des amonts ; si l'accès amont est instable, elle ne fera qu'amplifier les échecs. Dans ce cas, « auto-hébergement avec un amont accessible localement » ou « passerelle gérée » est plus réaliste.

Si vous n'avez pas besoin de modifier le code source et souhaitez seulement un point d'entrée compatible OpenAI, des clés unifiées et une facturation en yuans, une passerelle gérée est généralement opérationnelle le jour de l'inscription ; LiteLLM convient mieux comme infrastructure à maintenir sur la durée. Les deux peuvent coexister : LiteLLM pour le routage interne, une passerelle gérée comme point d'entrée externe.

8. Questions fréquentes

LiteLLM est-il gratuit ?

La partie open source peut être déployée librement, mais les appels aux modèles amont restent facturés ; les tarifs des fonctionnalités entreprise et des services gérés sont ceux de l'éditeur.

Quelle différence avec One API et New API ?

One API et New API sont davantage orientés distribution de quotas multi-utilisateurs ; LiteLLM est davantage orienté routage multi-modèles et unification des SDK. Les deux peuvent exposer un point d'entrée compatible OpenAI ; le choix dépend de votre besoin : distribution facturée ou capacités de routage.

Les appels d'outils natifs de Claude sont-ils pris en charge ?

Cela dépend de la version et de l'adaptation amont. Pour les appels d'outils complexes et le cache, validez avec de vraies requêtes plutôt qu'avec la seule documentation.

L'auto-hébergement permet-il d'économiser ?

Pas nécessairement. Vous économisez les frais de service de plateforme, mais payez serveur, exploitation et temps d'indisponibilité. Pour de petits volumes, le service géré est souvent plus avantageux.

Quelle configuration minimale en production ?

TLS, master key, clés virtuelles, plafonds budgétaires, journaux, sauvegarde de la base et health check : aucun de ces éléments n'est facultatif.

Pour aller plus loin

Si vous voulez d'abord valider les appels multi-modèles sans maintenir de conteneur, inscrivez-vous sur ZSQH AI Gateway et passez la première requête via le point d'entrée compatible OpenAI ; modèles et prix sont ceux de la page Tarifs des modèles. Une fois le volume et les exigences de conformité clarifiés, décidez si LiteLLM auto-hébergé est nécessaire.

Articles liés :