OSFRIA Découvrir les outils

OSIALab · Providers / passerelles

LiteLLM — une seule API pour tous vos modèles

LiteLLM unifie l'appel à des dizaines de providers — OpenAI, Anthropic, Mistral, Groq, Cohere, Ollama en local… — derrière un unique endpoint compatible OpenAI. Vos applications cessent de connaître les particularités de chaque API : elles parlent à LiteLLM, qui traduit et route.

Page informative, sans valeur de conseil. Téléchargez depuis la source officielle, vérifiez la licence (cœur MIT, mais un dossier « enterprise » est sous licence distincte — voir plus bas), et gardez en tête que LiteLLM en mode proxy voit passer toutes vos requêtes et centralise vos clés API : c'est un point sensible à sécuriser comme tel.

À quoi ça sert

Chaque provider LLM a sa propre API, ses paramètres et ses formats de réponse. LiteLLM expose un endpoint unique au format OpenAI (/chat/completions) et se charge de traduire vers le provider visé. On change de modèle ou de fournisseur sans toucher au code des applications clientes. Deux usages :

  • Bibliothèque Python — quelques lignes pour appeler n'importe quel provider avec la même interface, idéal dans un script ou un service.
  • Proxy (serveur) — un service que vous hébergez, qui centralise les clés, gère des budgets et des quotas par équipe, journalise les appels et permet de basculer d'un provider à l'autre côté serveur. C'est le mode qui en fait une vraie passerelle d'entreprise.

Cas d'usage : standardiser les appels LLM d'une équipe, ajouter un fallback automatique, plafonner les dépenses par projet, ou donner à n8n, Flowise et Open WebUI un endpoint unique vers tous les modèles.

Ce qui fait sa force

  • Compatibilité OpenAI universelle. Tout outil ou SDK prévu pour l'API d'OpenAI fonctionne en pointant sur LiteLLM, sans réécriture. C'est le standard de fait, réutilisé partout.
  • Clés virtuelles, budgets, quotas. Le proxy émet des virtual keys par projet, chacune avec son budget mensuel, ses limites de débit (RPM/TPM) et ses modèles autorisés. Vous distribuez des clés LiteLLM, jamais vos vraies clés providers.
  • Routage et bascule. Répartition de charge, fallback automatique d'un modèle vers un autre, gestion des erreurs : la couche réseau que l'on bricole sinon à la main.
  • Local et cloud sur le même endpoint. Un modèle Ollama local et un modèle cloud cohabitent dans la même configuration ; les clients ne voient qu'un nom de modèle.
  • Suivi des dépenses centralisé. Les coûts estimés par clé, par modèle et par projet sont consolidés — un tableau de bord là où chaque provider a habituellement le sien.

Pour qui

Pour des développeurs et équipes techniques qui consomment plusieurs providers et veulent réduire la complexité de maintenance. Le mode proxy brille quand plusieurs applications partagent les mêmes clés : LiteLLM centralise au lieu de disséminer. Les profils non techniques n'y touchent pas directement, mais en bénéficient si un administrateur y connecte leurs outils.

Installation

Bibliothèque Python

pip install litellm
from litellm import completion

# Appel vers Ollama en local
response = completion(
    model="ollama/llama3.2",
    messages=[{"role": "user", "content": "Bonjour"}],
    api_base="http://localhost:11434"
)
print(response.choices[0].message.content)

Mode proxy (serveur)

# Installer le proxy
pip install 'litellm[proxy]'

# Démarrer avec un fichier de configuration (port 4000 par défaut)
litellm --config config.yaml --port 4000

Le proxy écoute sur http://localhost:4000 et expose un endpoint /chat/completions compatible OpenAI. Une interface d'administration est disponible sur /ui (connexion avec la clé maître).

Avec Docker

docker run \
  -p 4000:4000 \
  -v $(pwd)/litellm_config.yaml:/app/config.yaml \
  ghcr.io/berriai/litellm:main-latest \
  --config /app/config.yaml --port 4000

Exemple de config.yaml minimal

model_list:
  - model_name: llama3-local
    litellm_params:
      model: ollama/llama3.2
      api_base: http://host.docker.internal:11434

  - model_name: mistral-cloud
    litellm_params:
      model: mistral/mistral-small
      api_key: os.environ/MISTRAL_API_KEY

Aller plus loin : clé maître et clés virtuelles

Deux niveaux de clés cohabitent, à ne pas confondre :

  • LITELLM_MASTER_KEY — la clé racine du proxy. Elle authentifie les administrateurs et l'accès à l'interface /ui. Ce n'est pas une clé provider.
  • Clés providers (OpenAI, Anthropic, Mistral…) — ajoutées par modèle, dans la configuration ou via l'UI. Avec une base PostgreSQL, elles sont stockées chiffrées et persistent entre les redémarrages.
  • Virtual keys — émises par le proxy pour chaque application cliente, avec budget, quotas et modèles autorisés. Ce sont elles que vous distribuez. Leur gestion nécessite une base PostgreSQL (incluse dans la configuration Docker Compose officielle).

Points de vigilance

En mode proxy, LiteLLM devient un point central qui détient les clés et voit toutes les requêtes. Les points ci-dessous découlent directement de ce rôle.

Point d'attention Niveau Ce qu'il faut savoir
Proxy exposé sans clé maître 🔴 si accessible en réseau Sans LITELLM_MASTER_KEY et clés virtuelles, le proxy peut être interrogé librement par quiconque l'atteint — et consommer vos clés providers. Définissez la clé maître, émettez des clés virtuelles par client, et placez le proxy derrière un reverse proxy HTTPS.
Centralisation des clés API providers 🔴 réel par conception Toutes vos clés providers sont réunies au même endroit (chiffrées en base). Si l'instance est compromise, l'impact est global. Isolez le service, restreignez l'accès, prévoyez une rotation des clés.
Requêtes et réponses dans les journaux 🟡 selon configuration LiteLLM peut journaliser le contenu des échanges à des fins d'observabilité. Avant de traiter des données personnelles ou confidentielles, vérifiez le niveau de log et désactivez la journalisation du contenu en production si nécessaire.
Emballement des coûts cloud 🟡 réel Le proxy facilite l'appel de providers payants par de nombreuses applications. Posez des budgets par clé virtuelle et des alertes côté provider pour éviter les dérives.
Licence : MIT, sauf le dossier « enterprise » 🟡 avant usage commercial Le cœur de LiteLLM est sous licence MIT. Le contenu du dossier enterprise/ relève d'une licence distincte définie dans ce même dossier. Si vous utilisez ces fonctions, lisez leurs conditions avant un déploiement commercial.
Compromission de la chaîne de publication PyPI (mars 2026) 🔴 si ces versions précises ont été installées En mars 2026, deux versions piégées (1.82.7 et 1.82.8) ont brièvement circulé sur PyPI à la suite d'une compromission de la chaîne de publication, vite détectée et corrigée. Si vous avez installé l'une de ces deux versions précises, tournez immédiatement toutes vos clés API et mettez à jour vers une version stable récente. Dans tous les cas, épinglez vos versions (litellm==x.y.z) pour maîtriser ce que vous déployez. Source : Datadog Security Labs.

Sécurité

  • Définissez la clé maître. LITELLM_MASTER_KEY pour protéger l'accès au proxy et à l'interface /ui.
  • Une clé virtuelle par application. Avec budget et modèles autorisés ; ne distribuez jamais vos vraies clés providers.
  • HTTPS obligatoire. Reverse proxy (Nginx, Caddy) avec TLS — les clés transitent dans les en-têtes HTTP.
  • Isolez et surveillez. Accès réseau restreint à l'instance, audit régulier des journaux (modèles appelés, fréquence, coûts).
  • Tenez le proxy à jour. LiteLLM évolue très vite ; suivez les releases.

Aller plus loin

  • Ollama — le provider local à brancher en priorité pour les données sensibles.
  • Open WebUI — une interface unique pour tous les modèles servis par LiteLLM.
  • n8n — pointer un endpoint LiteLLM unique dans vos workflows.
  • OSIALab — comparer les providers et passerelles.

Sources

Continuer la lecture