Le guide complet de LiteLLM (2026)

Avez-vous déjà rencontré l'une de ces situations ? Votre projet tourne sur OpenAI, et un jour vous voulez basculer vers Claude — pour découvrir que chaque appel SDK doit être réécrit. Ou vous utilisez trois fournisseurs différents en même temps, avec des clés API éparpillées partout, et votre facture est une boîte noire impossible à répartir par service. Ou votre système en production commence à se heurter constamment aux limites de débit d'un modèle, et vous finissez par écrire à la main tout un tas de code répétitif pour gérer les tentatives.

LiteLLM existe précisément pour résoudre ces problèmes. 53k étoiles sur GitHub, actuellement en v1.91.0 (04/07/2026), prenant en charge plus de 100 fournisseurs LLM, une latence P95 de 8 ms, et un débit pouvant atteindre plus de 1,5k RPS. Il se décline en deux formes : le SDK Python (intégré directement dans votre code) et le serveur Proxy (une passerelle IA auto-hébergée). Vous pouvez utiliser l'un ou l'autre séparément, ou les combiner.

Ceci est le guide LiteLLM le plus complet disponible, couvrant : les bases du SDK, le basculement entre modèles, les stratégies du Router, le déploiement et la configuration d'un Proxy, l'intégration avec Claude Code, le suivi des coûts, la connexion aux relais d'API, et le déploiement en production. C'est un article long — mettez-le en favori et parcourez-le par sections.

1. Ce qu'est LiteLLM, et quel problème il résout

La valeur centrale de LiteLLM tient en une phrase : appeler n'importe quel LLM avec le même code, sans avoir à apprendre le format SDK propre à chaque fournisseur.

Plus de 100 fournisseurs utilisent chacun leur propre format d'API — OpenAI a le sien, Anthropic un autre, Google Vertex encore un autre, et AWS Bedrock est différent également. LiteLLM les enveloppe tous dans une interface unique compatible OpenAI : changez un seul paramètre model, et la requête est routée vers le fournisseur de votre choix.

Au-delà d'une interface unifiée, LiteLLM fournit aussi :

• Routage intelligent : équilibrage de charge automatique, bascule en cas de panne, et distribution des requêtes par latence, coût ou pondération
• Suivi des coûts : calcule automatiquement le coût en tokens à chaque appel et consolide la facturation entre fournisseurs
• Observabilité : intégration en une ligne avec des plateformes de supervision comme Langfuse, MLflow et Helicone
• Mode Proxy : un serveur auto-hébergé compatible OpenAI ; n'importe quel outil utilisant le SDK OpenAI (y compris Claude Code) peut basculer de façon transparente
• Clés virtuelles et budgets : distribuez des clés API virtuelles aux différents membres d'une équipe, avec des plafonds de dépense indépendants

Comparaison des deux modes d'utilisation :

Mode	Cas d'usage	Avantages	Inconvénients
SDK Python	Votre propre projet Python, besoin d'appeler un LLM dans le code	Léger, aucune dépendance supplémentaire, débogage facile	Utilisable uniquement en Python, non partageable avec d'autres langages/outils
Serveur Proxy	Passerelle partagée en équipe, backend pour des outils comme Claude Code / Cursor	Indépendant du langage, gestion centralisée des clés et des coûts, haute disponibilité pour la production	Nécessite de maintenir un processus/conteneur supplémentaire

2. Installation

2.1 Installer le SDK Python

# Recommandé : uv (plus rapide)
uv add litellm

# ou pip
pip install litellm

2.2 Installer le serveur Proxy

# Installer la version complète avec la fonctionnalité Proxy
uv tool install 'litellm[proxy]'

# ou pip
pip install 'litellm[proxy]'

Une fois l'installation terminée, exécutez litellm --version pour vérifier — la dernière version actuelle est v1.91.0.

3. SDK Python : les bases

3.1 L'appel le plus simple

La fonction completion() de LiteLLM est en tout point identique à l'interface chat.completions.create() d'OpenAI, à ceci près qu'un préfixe model supplémentaire indique le fournisseur :

from litellm import completion
import os

# OpenAI
os.environ["OPENAI_API_KEY"] = "sk-..."
response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Bonjour, écris un tri rapide en Python"}]
)
print(response.choices[0].message.content)

Pour basculer vers Anthropic Claude, il suffit de changer model et la clé correspondante :

os.environ["ANTHROPIC_API_KEY"] = "sk-ant-..."
response = completion(
    model="anthropic/claude-sonnet-5",   # notez le préfixe anthropic/
    messages=[{"role": "user", "content": "Bonjour, écris un tri rapide en Python"}]
)
print(response.choices[0].message.content)

Pour basculer vers Google Gemini :

os.environ["GEMINI_API_KEY"] = "AIza..."
response = completion(
    model="gemini/gemini-3.5-flash",
    messages=[{"role": "user", "content": "Bonjour, écris un tri rapide en Python"}]
)
print(response.choices[0].message.content)

Hormis le paramètre model, le reste du code ne change absolument pas. C'est là la valeur la plus centrale de LiteLLM : changer de modèle ne nécessite aucune modification de la logique métier.

3.2 Format de la chaîne model pour les principaux fournisseurs

Fournisseur	Exemple de format model	Variable d'environnement
OpenAI	openai/gpt-4o	OPENAI_API_KEY
Anthropic	anthropic/claude-sonnet-5	ANTHROPIC_API_KEY
Google Gemini	gemini/gemini-3.5-flash	GEMINI_API_KEY
AWS Bedrock	bedrock/anthropic.claude-3-sonnet	AWS_ACCESS_KEY_ID etc.
Azure OpenAI	azure/<deployment-name>	AZURE_API_KEY etc.
Ollama (local)	ollama/llama3.2	Aucune clé requise
DeepSeek	deepseek/deepseek-chat	DEEPSEEK_API_KEY
Compatible OpenAI (relais)	openai/model-name + api_base	Personnalisée

3.3 Sortie en flux (Streaming)

response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Écris un court texte sur l'IA"}],
    stream=True
)

for chunk in response:
    content = chunk.choices[0].delta.content
    if content:
        print(content, end='', flush=True)
print()  # saut de ligne

3.4 Appel asynchrone

import asyncio
from litellm import acompletion

async def main():
    response = await acompletion(
        model="anthropic/claude-sonnet-5",
        messages=[{"role": "user", "content": "Explique l'intrication quantique"}]
    )
    print(response.choices[0].message.content)

asyncio.run(main())

3.5 Appel de fonctions (Tool Use)

import json
from litellm import completion

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Récupère la météo d'une ville donnée",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "Nom de la ville"},
                    "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
                },
                "required": ["city"]
            }
        }
    }
]

response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Quel temps fait-il à Paris aujourd'hui ?"}],
    tools=tools,
    tool_choice="auto"
)

# Analyser l'appel d'outil
if response.choices[0].message.tool_calls:
    tool_call = response.choices[0].message.tool_calls[0]
    print(f"Outil appelé : {tool_call.function.name}")
    print(f"Paramètres : {json.loads(tool_call.function.arguments)}")

4. SDK Python : techniques avancées

4.1 Gestion unifiée des erreurs

LiteLLM fait correspondre les erreurs de tous les fournisseurs aux types d'exceptions d'OpenAI — vous n'avez donc qu'un seul ensemble d'exceptions à gérer :

from litellm import completion
from litellm.exceptions import (
    AuthenticationError,
    RateLimitError,
    APIError,
    BadRequestError
)

try:
    response = completion(
        model="anthropic/claude-sonnet-5",
        messages=[{"role": "user", "content": "Bonjour"}]
    )
except AuthenticationError as e:
    print(f"Erreur de clé API : {e}")
except RateLimitError as e:
    print(f"Limite de débit atteinte, réessayer plus tard : {e}")
except BadRequestError as e:
    print(f"Paramètre de requête invalide : {e}")
except APIError as e:
    print(f"Erreur côté serveur : {e}")

4.2 Suivi des coûts (par appel)

import litellm

response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Écris un texte de 100 mots"}]
)

# Récupérer le coût de cet appel (en dollars)
cost = litellm.completion_cost(completion_response=response)
print(f"Coût de cet appel : ${cost:.6f}")
print(f"Tokens en entrée : {response.usage.prompt_tokens}")
print(f"Tokens en sortie : {response.usage.completion_tokens}")

4.3 Intégration de l'observabilité (Langfuse)

import litellm

# Intégration Langfuse en une ligne, enregistre automatiquement tous les appels LLM
litellm.success_callback = ["langfuse"]
os.environ["LANGFUSE_PUBLIC_KEY"] = "pk-..."
os.environ["LANGFUSE_SECRET_KEY"] = "sk-..."

response = completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Bonjour"}]
)
# L'appel sera automatiquement enregistré dans le tableau de bord Langfuse

Les plateformes de supervision prises en charge incluent aussi : MLflow, Helicone, Lunary, Arize, Weights & Biases, etc., avec une méthode de configuration identique.

4.4 Connecter un relais compatible OpenAI (api_base personnalisé)

Les principaux relais d'API IA (comme SiliconFlow, AiHubMix) proposent généralement une interface compatible OpenAI, que LiteLLM peut connecter directement :

response = completion(
    model="openai/deepseek-v4-flash",   # nom du modèle selon ce que le relais prend en charge
    api_base="https://api.siliconflow.cn/v1",  # point de terminaison du relais
    api_key="sk-...",   # votre clé API sur le relais
    messages=[{"role": "user", "content": "Bonjour"}]
)

5. Router : équilibrage de charge et bascule automatique

Lorsque votre système doit appeler plusieurs déploiements similaires (par exemple trois déploiements Azure GPT-4o répartis dans différentes régions), ou basculer automatiquement vers un modèle de secours en cas d'échec du modèle principal, c'est le moment d'utiliser litellm.Router.

5.1 Configuration de routage de base

from litellm import Router

model_list = [
    {
        "model_name": "gpt-4o",   # nom unifié exposé publiquement
        "litellm_params": {
            "model": "openai/gpt-4o",
            "api_key": "sk-openai-primary",
            "weight": 7   # 70% du trafic
        }
    },
    {
        "model_name": "gpt-4o",
        "litellm_params": {
            "model": "azure/gpt-4o-eastus",
            "api_base": "https://my-eastus.openai.azure.com/",
            "api_key": "azure-key",
            "api_version": "2024-08-01-preview",
            "weight": 3   # 30% du trafic
        }
    }
]

router = Router(model_list=model_list)

# S'appelle exactement comme litellm.completion()
response = router.completion(
    model="gpt-4o",   # utilise le nom unifié
    messages=[{"role": "user", "content": "Bonjour"}]
)

5.2 Les sept stratégies de routage expliquées

Stratégie	Cas d'usage	Caractéristiques
simple-shuffle (par défaut)	Environnements de production généraux	Aléatoire pondéré selon RPM/TPM ou poids, coût minimal, recommandée en premier choix
rate-limit-aware-v2	Protection contre les limites de débit sur plusieurs comptes	Suit le TPM de chaque déploiement en temps réel, filtre ceux qui dépassent la limite, s'exécute de façon asynchrone
latency-based-routing	Systèmes temps réel sensibles à la latence	Met en cache dynamiquement le temps de réponse de chaque déploiement, choisit le plus rapide
least-busy	Contrôler la concurrence, éviter la surcharge d'un déploiement	Choisit le déploiement avec le moins de requêtes en cours
usage-based-routing	Déploiement multi-instances distribué	Route vers le déploiement avec l'usage TPM le plus faible, nécessite Redis
cost-based-routing	Scénarios sensibles aux coûts	Choisit le déploiement disponible le moins cher à chaque requête
custom	Logique métier personnalisée	Hérite de CustomRoutingStrategyBase pour implémenter votre propre logique

5.3 Bascule automatique et politique de nouvelles tentatives

from litellm.router import RetryPolicy, AllowedFailsPolicy

retry_policy = RetryPolicy(
    RateLimitErrorRetries=3,        # 3 tentatives en cas de limite de débit
    TimeoutErrorRetries=2,          # 2 tentatives en cas de timeout
    AuthenticationErrorRetries=0,   # aucune tentative en cas d'erreur d'authentification
    BadRequestErrorRetries=1,
    ContentPolicyViolationErrorRetries=3
)

allowed_fails_policy = AllowedFailsPolicy(
    RateLimitErrorAllowedFails=100,  # 100 échecs de limite de débit tolérés avant refroidissement
    ContentPolicyViolationErrorAllowedFails=1000
)

router = Router(
    model_list=model_list,
    retry_policy=retry_policy,
    allowed_fails_policy=allowed_fails_policy,
    allowed_fails=3,      # un déploiement en échec plus de 3 fois en 1 minute déclenche le refroidissement
    cooldown_time=30      # durée de refroidissement de 30 secondes
)

5.4 Ordre de priorité (paramètre order)

model_list = [
    {
        "model_name": "claude-sonnet",
        "litellm_params": {
            "model": "anthropic/claude-sonnet-5",
            "api_key": "primary-key",
            "order": 1   # priorité la plus haute, essayé en premier
        }
    },
    {
        "model_name": "claude-sonnet",
        "litellm_params": {
            "model": "anthropic/claude-sonnet-5",
            "api_base": "https://adresse-du-relais/v1",
            "api_key": "relay-key",
            "order": 2   # secours : utilisé si la ligne principale échoue
        }
    }
]
router = Router(model_list=model_list)

6. Serveur Proxy : une passerelle IA auto-hébergée

LiteLLM Proxy est un serveur HTTP déployable indépendamment, exposant une interface entièrement compatible OpenAI. Tous les membres de l'équipe, tout code dans n'importe quel langage, tous les outils IA (Claude Code, Cursor, Open WebUI, etc.) n'ont qu'à pointer leur base_url vers ce Proxy pour gérer de façon centralisée tous les accès LLM.

6.1 Le démarrage le plus simple

# Démarrage direct, route vers un modèle spécifique
litellm --model openai/gpt-4o

# Le proxy s'exécute sur http://0.0.0.0:4000

6.2 Configuration principale du config.yaml

En production, il est recommandé de gérer toute la configuration via un fichier config.yaml :

model_list:
  # Modèle principal : Claude Sonnet 5
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

  # Secours : DeepSeek via SiliconFlow (connexion directe en Chine continentale)
  - model_name: claude-sonnet
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://api.siliconflow.cn/v1
      api_key: os.environ/SILICONFLOW_API_KEY
      order: 2   # secours

  # Modèle de programmation gratuit : GLM-4.7-Flash (connexion directe en Chine continentale)
  - model_name: glm-flash
    litellm_params:
      model: openai/glm-4.7-flash
      api_base: https://open.bigmodel.cn/api/paas/v4/
      api_key: os.environ/GLM_API_KEY

  # Ollama local
  - model_name: local-llama
    litellm_params:
      model: ollama/llama3.2
      api_base: http://localhost:11434

litellm_settings:
  drop_params: true          # ignore automatiquement les paramètres non pris en charge par le modèle cible
  num_retries: 3             # nombre de tentatives global
  request_timeout: 60        # délai d'expiration (secondes)
  success_callback: ["langfuse"]  # callback de supervision

general_settings:
  master_key: sk-my-secret-key   # clé requise pour accéder au Proxy
  alerting: ["slack"]            # alertes sur requêtes lentes/erreurs

router_settings:
  routing_strategy: simple-shuffle
  allowed_fails: 3
  cooldown_time: 30

# Démarrer avec le fichier config
litellm --config config.yaml

# Vérifier le démarrage
curl http://localhost:4000/health

6.3 Appeler le Proxy via le SDK OpenAI

import openai

# Pointer vers le Proxy local
client = openai.OpenAI(
    api_key="sk-my-secret-key",    # le master_key du config.yaml
    base_url="http://localhost:4000"
)

response = client.chat.completions.create(
    model="claude-sonnet",    # correspond au model_name du config.yaml
    messages=[{"role": "user", "content": "Bonjour"}]
)
print(response.choices[0].message.content)

6.4 Découverte de modèles (lister tous les modèles disponibles)

curl http://localhost:4000/models \
  -H "Authorization: Bearer sk-my-secret-key"

7. Intégration avec Claude Code

C'est l'un des usages les plus populaires de LiteLLM chez les développeurs de Chine continentale : router les requêtes de Claude Code vers d'autres modèles (GPT-5.6, Gemini, DeepSeek, GLM), ou passer par un relais en Chine continentale pour résoudre les problèmes de stabilité d'accès.

7.1 Principe de fonctionnement

Claude Code utilise en interne le format de l'API Anthropic Messages. LiteLLM Proxy va :

1. Recevoir la requête au format Anthropic envoyée par Claude Code
2. La convertir automatiquement au format du fournisseur cible (OpenAI/Gemini/DeepSeek, etc.)
3. La transmettre au fournisseur cible
4. Reconvertir la réponse au format Anthropic avant de la renvoyer à Claude Code

7.2 Étapes de configuration

Étape 1 : créer config.yaml (exemple avec connexion à GPT-4o et à un relais en Chine continentale)

model_list:
  - model_name: gpt-4o
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: deepseek-v4-flash
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://api.siliconflow.cn/v1
      api_key: os.environ/SILICONFLOW_API_KEY

  - model_name: glm-flash
    litellm_params:
      model: openai/glm-4.7-flash
      api_base: https://open.bigmodel.cn/api/paas/v4/
      api_key: os.environ/GLM_API_KEY

general_settings:
  master_key: sk-claude-proxy

Étape 2 : démarrer le Proxy

litellm --config config.yaml
# écoute sur http://0.0.0.0:4000

Étape 3 : configurer les variables d'environnement de Claude Code

export ANTHROPIC_BASE_URL="http://0.0.0.0:4000"
export ANTHROPIC_AUTH_TOKEN="sk-claude-proxy"

Étape 4 : démarrer Claude Code en spécifiant le modèle

# Utiliser GPT-4o
claude --model gpt-4o

# Utiliser DeepSeek en connexion directe en Chine continentale
claude --model deepseek-v4-flash

# Utiliser le gratuit GLM-4.7-Flash
claude --model glm-flash

# Activer la découverte de modèles de la passerelle (basculer via la commande /model dans Claude Code)
export CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1
claude   # une fois démarré, utilisez /model pour lister et basculer entre les modèles

7.3 Comparaison avec claude-code-router

De nombreux lecteurs utilisent peut-être déjà claude-code-router (CCR) — en quoi LiteLLM Proxy diffère-t-il de CCR ?

Critère	LiteLLM Proxy	claude-code-router
Nombre de fournisseurs pris en charge	100+	Quelques acteurs principaux
Stratégies de routage	7, hautement configurables	Routage basé sur le type de requête
Intégration Claude Code	✓	✓ (conçu spécifiquement pour cela)
Tableau de bord d'administration	✓ (interface intégrée)	✗
Multi-utilisateurs en équipe	✓ (clés virtuelles)	✗
Suivi des coûts	✓ (détaillé)	✗
Complexité de déploiement	Moyenne (nécessite de l'exploitation)	Simple (processus unique)

En résumé : CCR est plus léger pour un usage individuel, LiteLLM Proxy est plus complet pour une équipe. Les deux peuvent aussi se combiner : CCR gère le routage intelligent de Claude Code, tandis que LiteLLM gère l'appel unifié multi-fournisseurs des autres services Python.

8. Suivi des coûts et contrôle budgétaire

8.1 Callback de coût personnalisé

import litellm
from litellm.integrations.custom_logger import CustomLogger

class CostTracker(CustomLogger):
    def __init__(self):
        self.total_cost = 0.0
        self.calls = []

    def log_success_event(self, kwargs, response_obj, start_time, end_time):
        cost = kwargs.get("response_cost", 0)
        self.total_cost += cost
        self.calls.append({
            "model": kwargs.get("model"),
            "cost": cost,
            "tokens": response_obj.usage.total_tokens,
            "latency": (end_time - start_time).total_seconds()
        })
        print(f"[Cost] {kwargs.get('model')}: ${cost:.6f}")

tracker = CostTracker()
litellm.callbacks = [tracker]

# Consulter après l'appel
response = litellm.completion(
    model="openai/gpt-4o",
    messages=[{"role": "user", "content": "Hello"}]
)
print(f"Coût cumulé : ${tracker.total_cost:.4f}")

8.2 Clés virtuelles et budgets du Proxy

LiteLLM Proxy permet d'attribuer des clés API virtuelles à différents utilisateurs/projets, avec des plafonds de dépense indépendants :

# Créer une clé virtuelle (via l'API d'administration)
curl -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-my-secret-key" \
  -H "Content-Type: application/json" \
  -d '{
    "team_id": "frontend-team",
    "max_budget": 10.0,       # 10 $ de dépense maximum
    "budget_duration": "30d", # réinitialisation tous les 30 jours
    "models": ["claude-sonnet", "glm-flash"],  # modèles autorisés uniquement
    "metadata": {"user": "alice@example.com"}
  }'

# Réponse : {"key": "sk-virtual-abc123", ...}

Alice utilise sk-virtual-abc123 pour appeler le Proxy ; au-delà de 10 $, les requêtes sont automatiquement refusées, sans jamais avoir besoin de partager la clé principale.

9. Connexion aux relais d'API

Les principaux relais d'API IA prennent généralement en charge une interface compatible OpenAI, ce qui rend leur connexion à LiteLLM très simple. Voici la configuration de quelques relais courants :

model_list:
  # SiliconFlow (connexion directe en Chine continentale, gamme complète DeepSeek/Qwen/GLM)
  - model_name: deepseek-v4-flash
    litellm_params:
      model: openai/deepseek-v4-flash
      api_base: https://api.siliconflow.cn/v1
      api_key: os.environ/SILICONFLOW_API_KEY

  # AiHubMix (Claude/GPT en connexion directe en Chine continentale, prend en charge le Prompt Caching)
  - model_name: claude-sonnet-via-relay
    litellm_params:
      model: openai/claude-sonnet-5-20261001
      api_base: https://aihubmix.com/v1
      api_key: os.environ/AIHUBMIX_API_KEY

  # Zhipu AI GLM (connexion directe en Chine continentale, modèle gratuit disponible)
  - model_name: glm-flash-free
    litellm_params:
      model: openai/glm-4.7-flash
      api_base: https://open.bigmodel.cn/api/paas/v4/
      api_key: os.environ/GLM_API_KEY

  # OpenRouter (interface unifiée pour plus de 400 modèles mondiaux)
  - model_name: openrouter-sonnet
    litellm_params:
      model: openai/anthropic/claude-sonnet-5
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

Après avoir configuré les variables d'environnement, démarrez :

export SILICONFLOW_API_KEY="sk-sf-..."
export AIHUBMIX_API_KEY="sk-ahm-..."
export GLM_API_KEY="your-glm-key"

litellm --config config.yaml

Un seul Proxy regroupe ainsi quatre relais différents — votre code n'a besoin de se connecter qu'à http://localhost:4000, et différents model_name permettent d'appeler différents relais, tous gérés de façon parfaitement unifiée.

10. Déploiement en production : Docker + Redis

10.1 Déploiement Docker en conteneur unique

# docker-compose.yml
version: '3.8'
services:
  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml
    environment:
      - ANTHROPIC_API_KEY=${'{ANTHROPIC_API_KEY}'}
      - SILICONFLOW_API_KEY=${'{SILICONFLOW_API_KEY}'}
      - GLM_API_KEY=${'{GLM_API_KEY}'}
      - LITELLM_MASTER_KEY=sk-production-key
    command: --config /app/config.yaml --port 4000 --num_workers 8
    restart: unless-stopped

docker-compose up -d

10.2 Déploiement de niveau production : ajouter Redis pour un état partagé distribué

# docker-compose-production.yml
version: '3.8'
services:
  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data

  litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./config.yaml:/app/config.yaml
    environment:
      - ANTHROPIC_API_KEY=${'{ANTHROPIC_API_KEY}'}
      - REDIS_HOST=redis
      - REDIS_PORT=6379
      - LITELLM_MASTER_KEY=sk-production-key
    depends_on:
      - redis
    command: --config /app/config.yaml --port 4000 --num_workers 8

volumes:
  redis-data:

Activez Redis dans config.yaml :

router_settings:
  routing_strategy: usage-based-routing   # routage conscient de l'état distribué
  redis_host: redis
  redis_port: 6379
  cache_responses: true   # active la mise en cache des réponses pour réduire les coûts

10.3 Repères de performance

Configuration	RPS	Latence P95
1 instance, 8 workers	~400	<10ms (couche proxy)
1 instance, 16 workers	~800	<10ms
3 instances + Redis	~1500+	<8ms (P95)

11. Remarques de sécurité

⚠️ Avertissement de sécurité important : les versions v1.82.7 et v1.82.8 du paquet PyPI de LiteLLM ont été confirmées comme compromises par une attaque de la chaîne d'approvisionnement, intégrant un logiciel malveillant de vol d'identifiants qui envoie vos clés API et variables d'environnement vers un serveur externe. Si vous avez installé l'une de ces deux versions, immédiatement : ① mettez à jour vers la dernière version ; ② faites tourner toutes vos clés API ; ③ vérifiez si des processus anormaux tournent sur votre système.

Autres recommandations de sécurité :

• Ne codez jamais en dur de clé API dans config.yaml — utilisez systématiquement le format os.environ/VAR_NAME pour référencer une variable d'environnement
• N'exposez jamais le Proxy sur l'internet public sans avoir configuré des clés virtuelles et une liste blanche d'IP ; en développement local, liez-vous à 127.0.0.1:4000 plutôt qu'à 0.0.0.0:4000
• Faites tourner régulièrement le master_key ; les clés virtuelles peuvent avoir une date d'expiration
• Lors de l'activation de la journalisation des requêtes, veillez à anonymiser les données personnelles pour éviter d'enregistrer du contenu sensible saisi par les utilisateurs dans un système de supervision externe

12. FAQ

Q : J'utilise déjà le SDK OpenAI — combien de code dois-je modifier pour intégrer LiteLLM ?

R : En mode Proxy, il suffit de changer deux lignes : api_key devient le master_key du Proxy, et base_url pointe vers l'adresse du Proxy. Le code métier ne bouge absolument pas. En mode SDK Python, remplacez simplement openai.ChatCompletion.create() par litellm.completion() — le format des paramètres est identique.

Q : Quelle latence supplémentaire LiteLLM ajoute-t-il ?

R : Les tests officiels donnent une latence P95 d'environ 8 ms (uniquement la couche proxy, sans compter le temps de réponse du LLM lui-même). Pour la plupart des scénarios d'appel LLM, la réponse du LLM lui-même prend déjà de plusieurs centaines de millisecondes à plusieurs secondes — les 8 ms supplémentaires sont négligeables.

Q : Peut-on utiliser LiteLLM dans un projet Node.js / Go / Java ?

R : Oui, via le mode Proxy. Le Proxy expose une interface REST HTTP standard (compatible OpenAI), que n'importe quel langage peut appeler directement avec un client HTTP, ou en pointant le SDK OpenAI de son propre langage vers le base_url du Proxy.

Q : Quelles fonctionnalités le point de terminaison compatible Anthropic de LiteLLM (`/anthropic`) prend-il en charge ?

R : Il prend en charge les fonctionnalités centrales de l'API Messages, y compris le streaming, tool_use, la vision (entrée d'images), le system prompt, ainsi que le routage via le Proxy d'outils SDK Anthropic comme Claude Code vers d'autres fournisseurs (GPT, Gemini, DeepSeek, etc.).

Q : Comment déboguer si le routage fonctionne comme prévu ?

R : Ajoutez le paramètre --detailed_debug au démarrage, ou set_verbose=True lors de l'initialisation du Router — cela affichera la décision de routage, les journaux de nouvelles tentatives et le déploiement réellement utilisé pour chaque requête.

Q : LiteLLM prend-il en charge les Embeddings et la génération d'images ?

R : Oui. L'interface unifiée de LiteLLM couvre plusieurs points de terminaison, dont /embeddings (vectorisation de texte), /images/generations (génération d'images) et /audio/transcriptions (reconnaissance vocale) — l'appel se fait de façon similaire à completion().

13. Conclusion

LiteLLM résout un problème très réel de l'ingénierie LLM : la fragmentation multi-fournisseurs. Lorsque votre système dépend simultanément d'OpenAI, d'Anthropic, de modèles locaux et de relais, LiteLLM est actuellement la couche unifiée la plus mature disponible.

Recommandations selon le cas d'usage :

• Scripts Python / projets personnels : utilisez le mode SDK, un pip install suivi d'un appel direct à completion(), la solution la plus légère
• Connecter plusieurs modèles à Claude Code / Cursor : utilisez le mode Proxy, déployable en 5 minutes, avec ANTHROPIC_BASE_URL pointant vers le Proxy local
• Accès LLM partagé en équipe : Proxy + clés virtuelles + contrôle budgétaire, une gestion complète de niveau entreprise
• Système de production haute disponibilité : Proxy + Redis + plusieurs instances, plus de 1500 RPS, latence P95 <8ms

Pour les développeurs situés hors des États-Unis : combiner LiteLLM avec des relais d'API (SiliconFlow, AiHubMix, GLM, etc.) reste actuellement la solution d'accès aux LLM la plus flexible — le relais résout le problème de l'accès direct, et LiteLLM résout la gestion unifiée multi-fournisseurs ; les deux se complètent parfaitement.