LiteLLM : Passe d'OpenAI à Mistral sans changer une ligne de code

L'uniformité ne concerne pas que la génération de texte. LiteLLM applique la même logique aux embeddings, ces vecteurs qui représentent le sens d'un texte et servent à la recherche sémantique, au clustering ou à la classification. La fonction embedding suit le format OpenAI, quel que soit le fournisseur.

from litellm import embedding

response = embedding(
    model="text-embedding-3-small",   # OpenAI
    input=["Bonjour le monde", "Un autre texte"],
)

# Les vecteurs sont dans response.data[i]["embedding"]
print("Nombre de vecteurs :", len(response.data))
print("Dimension d'un vecteur :", len(response.data[0]["embedding"]))

Pour changer de fournisseur d'embedding, il suffit là encore de changer le nom du modèle, par exemple en text-embedding-004 (Google) ou en un modèle local via Ollama. Tes index vectoriels et tes pipelines de recherche restent inchangés, seul le backend de vectorisation diffère.

Les préfixes de fournisseurs, en un coup d'œil

Le nom du modèle indique à LiteLLM vers quel fournisseur router la requête. Voici les préfixes les plus courants :

• gpt-4o-mini, gpt-4o, o1... : modèles OpenAI, reconnus sans préfixe.
• mistral/mistral-large-latest : les modèles Mistral.
• anthropic/claude-3-5-sonnet-20241022 (ou le nom nu claude-3-5-sonnet-20241022) : les modèles Claude.
• command-r : les modèles Cohere.
• bedrock/... : les modèles exposés par AWS Bedrock.
• azure/... : les déploiements Azure OpenAI.
• ollama/llama3.2 : les modèles locaux servis par Ollama.

Cette convention unique est le cœur de LiteLLM : c'est elle qui te permet de traiter tous les fournisseurs comme un seul et même service, avec une seule clé mentale à retenir.

Gérer les erreurs proprement

LiteLLM lève des exceptions typées, héritées de la classe OpenAIError, qui te permettent de distinguer un modèle introuvable d'une limite de débit atteinte ou d'une clé invalide. C'est bien plus propre que de parser des codes HTTP à la main.

from litellm import completion, exceptions

try:
    response = completion(
        model="modele-qui-nexiste-pas",
        messages=[{"role": "user", "content": "Salut"}],
    )
except exceptions.NotFoundError as e:
    print("Modèle introuvable :", e)
except exceptions.AuthenticationError as e:
    print("Clé API invalide :", e)
except exceptions.RateLimitError as e:
    print("Limite de débit atteinte, réessaie plus tard :", e)
except exceptions.APIError as e:
    print("Erreur générique du fournisseur :", e)

Ces exceptions étant homogènes quel que soit le fournisseur, ton code de gestion d'erreur s'écrit une seule fois. C'est un gain de robustesse considérable quand tu enchaînes plusieurs modèles dans la même application.

Configurer par fichier YAML

Quand la liste des modèles s'allonge, la passer en dur dans le code devient ingérable. LiteLLM accepte un fichier de configuration YAML qui centralise les modèles, les clés et les réglages globaux. Le Router le charge directement.

# config.yaml
model_list:
  - model_name: gpt-4o-mini
    litellm_params:
      model: gpt-4o-mini
      api_key: os.environ/OPENAI_API_KEY
  - model_name: claude-sonnet
    litellm_params:
      model: anthropic/claude-3-5-sonnet-20241022
      api_key: os.environ/ANTHROPIC_API_KEY

litellm_settings:
  num_retries: 3
  request_timeout: 60
  drop_params: true   # ignore les paramètres non supportés par le fournisseur

from litellm import Router

# Le routeur lit la configuration depuis le fichier
router = Router(config_path="config.yaml")

response = router.completion(
    model="claude-sonnet",   # nom logique défini dans le YAML
    messages=[{"role": "user", "content": "Bonjour !"}],
)
print(response.choices[0].message.content)

La syntaxe os.environ/OPENAI_API_KEY indique à LiteLLM d'aller lire la clé dans la variable d'environnement correspondante : tes secrets restent hors du fichier, ce qui est essentiel dès que la config est versionnée ou partagée.

Le cache pour réduire les coûts

Beaucoup d'applications répètent les mêmes requêtes (un même prompt de système, une même question fréquente). LiteLLM peut mettre en cache les réponses et ainsi économiser à la fois de l'argent et de la latence. Le cache s'active en une ligne.

import litellm
from litellm import completion

# Active un cache en mémoire, valable pour tous les appels suivants
litellm.enable_cache()

messages = [{"role": "user", "content": "Qui es-tu ?"}]

r1 = completion(model="gpt-4o-mini", messages=messages)
r2 = completion(model="gpt-4o-mini", messages=messages)
# r2 est servi depuis le cache : aucun appel réseau, coût nul

print(r1.choices[0].message.content == r2.choices[0].message.content)  # True

En production, tu remplaces le cache mémoire par un cache Redis partagé entre plusieurs instances, ce qui démultiplie les économies sur une flotte de services. C'est un levier simple et trop souvent négligé.

Budgets et clés virtuelles avec le proxy

Le proxy LiteLLM va plus loin que la simple passerelle : il sait gérer des clés virtuelles avec des budgets, des quotas et des listes de modèles autorisés. C'est l'outil de gouvernance qui manque quand tu ouvres l'accès aux LLM à une équipe.

# Démarre le proxy avec un modèle autorisé
litellm --model gpt-4o-mini --port 4000

# Génère une clé virtuelle limitée à 10 dollars via l'API du proxy
curl http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-litellm" \
  -H "Content-Type: application/json" \
  -d '{"models": ["gpt-4o-mini"], "max_budget": 10}'

Chaque clé virtuelle est traçable individuellement : tu sais qui a consommé quoi, combien, et tu peux révoquer un accès en une commande. Pour une organisation qui adopte plusieurs LLM, c'est la brique de contrôle qui rend l'ensemble gouvernable.

Migrer depuis le SDK OpenAI

Si tu pars d'une application OpenAI existante, la migration est triviale : la signature de completion reproduit celle du SDK, à l'import près. Tu peux donc basculer progressivement, sans réécrire ta logique métier.

# AVANT : SDK OpenAI
from openai import OpenAI
client = OpenAI()
resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Salut"}],
)
print(resp.choices[0].message.content)

# APRÈS : LiteLLM, signature quasi identique
from litellm import completion
resp = completion(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Salut"}],
)
print(resp.choices[0].message.content)

La seule vraie différence, c'est le point d'entrée : la fonction completion à la place du client OpenAI. Une fois ce changement fait, tu peux immédiatement tester d'autres fournisseurs en changeant la valeur de model, sans rien toucher d'autre.

Points d'attention et limites

L'uniformisation a ses limites, et il est sain de les connaître pour ne pas tomber dans les pièges classiques :

• Paramètres spécifiques : certains réglages (top_k d'Anthropic, par exemple) n'existent pas partout. Active drop_params pour que LiteLLM les ignore silencieusement sur les fournisseurs qui ne les connaissent pas.
• Limites de contexte : chaque modèle a sa propre fenêtre. Un prompt qui passe sur GPT peut dépasser la limite d'un autre modèle. Vérifie max_tokens au cas par cas.
• Capacités inégales : la vision, l'audio ou l'appel d'outils ne sont pas disponibles sur tous les modèles. Un appel qui marche sur GPT peut échouer sur un modèle plus limité.
• Coûts et latence variables : deux modèles ne se valent pas en prix ni en vitesse. Mesure avant de basculer un service en production.

Ces limites ne remettent pas en cause l'intérêt de LiteLLM : elles rappellent simplement qu'unifier l'interface ne signifie pas unifier les capacités. Le bon réflexe est de tester chaque modèle sur tes cas réels avant de généraliser.

Tester et évaluer plusieurs modèles

LiteLLM rend l'évaluation comparative triviale : une boucle sur une liste de modèles suffit pour mesurer la latence et comparer la qualité des réponses. C'est la première chose à faire avant de choisir un modèle pour un cas d'usage précis.

import time
from litellm import completion

modeles = [
    "gpt-4o-mini",
    "mistral/mistral-large-latest",
    "claude-3-5-sonnet-20241022",
]
question = "Explique le concept d'inflation en deux phrases."

for modele in modeles:
    debut = time.time()
    try:
        r = completion(model=modele, messages=[{"role": "user", "content": question}])
        duree = time.time() - debut
        print(f"{modele:35s} | {duree:.2f}s | {r.choices[0].message.content}")
    except Exception as e:
        print(f"{modele:35s} | ERREUR : {e}")

Cette boucle te donne, en quelques secondes, un premier aperçu de la latence et du style de chaque fournisseur. Pour une évaluation plus rigoureuse, fixe un jeu de questions de référence et compare les réponses sur des critères objectifs (pertinence, format, coût). C'est le préalable à toute décision de migration.

En combinant ce type de benchmark avec le Router, tu peux même automatiser le choix du modèle : acheminer les requêtes simples vers le modèle le moins cher et réserver le plus puissant aux cas complexes. LiteLLM te donne les briques, l'orchestration fine reste ton affaire.

LiteLLM dans l'écosystème Python

LiteLLM ne vit pas en vase clos : il s'intègre aux principaux frameworks du moment. LangChain peut router ses appels via LiteLLM, et le proxy expose une API compatible OpenAI que consomment nativement des dizaines de bibliothèques, des SDK officiels aux outils d'agents.

Concrètement, adopter LiteLLM ne t'enferme dans aucun écosystème : c'est au contraire un moyen de rendre tes modèles accessibles au plus grand nombre d'outils, sans verrouillage. Le proxy joue le rôle de plaque tournante : tes applications, quels que soient leur langage ou leur framework, parlent toutes à la même porte.

• LangChain : utilise LiteLLM comme backend d'appel aux modèles.
• LlamaIndex : peut s'appuyer sur LiteLLM pour la génération et les embeddings.
• Tout SDK compatible OpenAI : pointe vers le proxy et profite du multi-fournisseur sans rien réécrire.

Bonnes pratiques pour la production

Passer en production avec plusieurs fournisseurs demande un peu de discipline. Quelques réflexes qui évitent les mauvaises surprises :

• Stocke les clés en variables d'environnement, jamais en dur dans le code ni dans les fichiers versionnés.
• Configure num_retries et request_timeout dès le départ : les API de LLM échouent régulièrement, anticipe-le.
• Active le cache pour les requêtes répétées, c'est de l'argent économisé sans effort.
• Mesure les coûts par modèle avant de généraliser : un modèle plus cher peut se justifier, mais encore faut-il le savoir.
• Prévois toujours un fallback : aucun fournisseur n'est infaillible, un modèle de secours évite une panne complète.

Conclusion

LiteLLM fait disparaître la friction du multi-fournisseur. Une seule signature d'appel, un simple changement de nom de modèle pour changer de fournisseur, et des outils de production (router, proxy, retries, suivi des coûts) qui évitent de réinventer la roue. C'est la bibliothèque à connaître dès que ton application touche à plus d'un LLM, ou que tu veux garder la liberté d'en changer.

Pour aller plus loin, explore la configuration complète du proxy (clés virtuelles, budgets par équipe, cache, load balancing avancé) et les callbacks d'observabilité. La documentation de LiteLLM est exhaustive et constamment à jour, ce qui est précieux dans un écosystème qui bouge aussi vite.

Sources

• Documentation officielle de LiteLLM
• Dépôt GitHub BerriAI/litellm
• Liste des fournisseurs supportés
• Documentation du Proxy Server
• Guide du Router (load balancing et fallbacks)