Qu'est-ce que LiteLLM ?
LiteLLM est une passerelle qui traduit un format de requête unique compatible OpenAI en appels vers plus de 100 API de fournisseurs LLM différents. La description de son dépôt GitHub le présente comme « la passerelle IA la plus rapide et la plus légère », construite avec un cœur en Rust et un SDK Python par-dessus — une évolution par rapport à l'implémentation purement Python des premières années du projet. Plutôt que d'écrire du code client séparé pour l'API OpenAI, l'API Anthropic et un serveur Ollama local, une application appelle LiteLLM une seule fois, et LiteLLM transmet la requête au fournisseur configuré pour ce nom de modèle.
- Fonction principale : recevoir une requête au format
chat/completionsd'OpenAI (ou au format natif du fournisseur cible), la transmettre au fournisseur configuré, et renvoyer une réponse normalisée - Deux modes d'accès : le SDK Python
litellm, importé directement dans le code d'une application, et le LiteLLM Proxy Server, un service autonome que d'autres applications appellent via HTTP - Développeur : BerriAI, l'organisation derrière le dépôt github.com/BerriAI/litellm
- Pas un moteur d'exécution de modèle : LiteLLM ne charge pas les poids du modèle et n'effectue pas d'inférence lui-même — il route les requêtes vers des fournisseurs qui le font, y compris des API cloud et des serveurs locaux comme Ollama ou vLLM
- Fonctionnalités de niveau production selon la documentation : clés API virtuelles, budgets de dépenses par clé et par utilisateur, limitation de débit, répartition de charge entre plusieurs déploiements du même modèle, et basculement automatique en cas d'erreur d'un fournisseur
Que peut-on faire avec LiteLLM ?
L'ensemble des fonctionnalités de LiteLLM couvre le routage des requêtes, le contrôle des coûts et la fiabilité — les aspects de l'exploitation d'une application basée sur des LLM qui se compliquent à mesure qu'on ajoute des fournisseurs et des utilisateurs, selon la documentation de LiteLLM.
- Surface API unifiée — envoyer une requête au format OpenAI ; LiteLLM la traduit dans le format natif du fournisseur du modèle cible, et normalise la réponse en retour
- Routage et répartition de charge — répartir le trafic entre plusieurs déploiements du même modèle (par exemple plusieurs régions Azure OpenAI) pour éviter un point de défaillance unique ou un plafond de limitation de débit
- Logique de secours et de nouvelle tentative — retenter automatiquement une requête échouée auprès d'un autre fournisseur ou déploiement de modèle plutôt que de renvoyer l'erreur à l'utilisateur final
- Suivi des coûts et budgets — journaliser les dépenses par clé API, par utilisateur ou par équipe, et fixer des limites de budget strictes qui bloquent les requêtes suivantes une fois dépassées
- Limitation de débit — plafonner les requêtes par minute/token par clé ou par utilisateur, appliqué de façon cohérente sur plusieurs instances de proxy via Redis
- Garde-fous et journalisation — points d'ancrage pour la modération de contenu et les intégrations d'observabilité, plus une journalisation structurée des requêtes/réponses pour les audits
- Tableau de bord d'administration — une interface web (servie sur
/uidu proxy) pour gérer les clés virtuelles, consulter les dépenses et configurer les modèles sans modifier directement le fichier de configuration - Fonctionne aussi avec des runtimes locaux — la même couche de routage qui appelle OpenAI ou Anthropic peut tout aussi bien pointer vers un point de terminaison Ollama ou vLLM local, permettant à une passerelle de mélanger modèles cloud et modèles locaux
Exemples d'utilisation : deux façons d'utiliser LiteLLM
Voici des flux de travail concrets construits à partir des parcours d'installation documentés de LiteLLM ci-dessus — pas des cas d'usage hypothétiques.
Appeler plusieurs fournisseurs depuis un script Python
Installer le SDK (pip install litellm), puis remplacer les appels directs aux clients openai, anthropic ou spécifiques à un fournisseur par `litellm.completion(model="gpt-4o", messages=[...]) ou litellm.completion(model="claude-opus-4", messages=[...])`. Les deux appels renvoient la même forme de réponse normalisée, donc changer de fournisseur revient à modifier une ligne de nom de modèle, pas à tout réécrire.
Exploiter une passerelle auto-hébergée pour une équipe
Déployer le LiteLLM Proxy Server (Docker ou Helm), définir une config.yaml avec une model_list qui associe des noms de modèles lisibles à de vrais déploiements de fournisseurs, et émettre une clé API virtuelle par développeur ou par application. Chaque application appelle désormais un point de terminaison interne unique au lieu de détenir ses propres clés OpenAI/Anthropic, et les dépenses sont suivies de façon centralisée dans le tableau de bord.
Mélanger modèles cloud et locaux derrière un seul point de terminaison
Ajouter à la fois un modèle cloud (par exemple openai/gpt-4o) et un modèle local servi par Ollama ou vLLM à la même model_list de la config.yaml. Router le trafic courant ou sensible à la confidentialité vers le modèle local et n'escalader vers le modèle cloud qu'en cas de besoin, sans changer la façon dont l'application appelante parle à la passerelle.
Installer LiteLLM : SDK, proxy et Docker
LiteLLM est un framework et une passerelle auto-hébergée, pas une application téléchargeable pour l'utilisateur final — il n'y a pas d'installateur à récupérer sur une boutique d'applications. Voici les véritables commandes d'installation et de démarrage rapide, selon la documentation officielle de LiteLLM et son guide de démarrage Docker ; vérifiez toujours la documentation directement avant tout déploiement, car les options exactes et les tags d'image peuvent changer entre les versions.
SDK Python
- Commande:
pip install litellm(ouuv add litellm)
Proxy Server (pip)
- Commande:
- `pip install 'litellm[proxy]'
puislitellm --model gpt-4o`
Proxy Server (Docker)
- Commande:
docker run -v $(pwd)/config.yaml:/app/config.yaml -e OPENAI_API_KEY=<clé> -e LITELLM_MASTER_KEY=sk-1234 -p 4000:4000 docker.litellm.ai/berriai/litellm:latest --config /app/config.yaml
Helm (Kubernetes)
- Commande:
helm install litellm oci://ghcr.io/berriai/litellm-helm -f values.yaml
AWS ECS Fargate
- Commande:
- Module Terraform officiel
BerriAI/litellm/aws(fournit VPC, Aurora PostgreSQL, ElastiCache Redis, ALB, ECS)
Google Cloud Run
- Commande:
- Module Terraform officiel
BerriAI/litellm/google(fournit Cloud SQL, Memorystore Redis, GCS, load balancer HTTPS)
Le proxy utilise par défaut le port 4000, avec le tableau de bord d'administration sur http://localhost:4000/ui (identifiants par défaut : nom d'utilisateur admin, mot de passe égal à votre LITELLM_MASTER_KEY). Un config.yaml minimal nécessite un tableau model_list associant un model_name à des litellm_params (la chaîne de modèle réelle du fournisseur plus sa clé API) — voir le démarrage rapide du proxy pour un exemple complet. Render et Railway proposent aussi des boutons de déploiement en un clic pour le proxy, selon la documentation de déploiement de LiteLLM.
Tarifs LiteLLM : est-ce vraiment gratuit ?
Le SDK open source et le Proxy Server sont gratuits — vous ne payez que les appels API aux fournisseurs sous-jacents routés via LiteLLM, plus vos propres coûts d'hébergement. LiteLLM lui-même ne facture ni par requête ni par token pour la voie open source. Une offre payante distincte, LiteLLM Enterprise, existe sur litellm.ai/enterprise, couvrant SSO, demandes de fonctionnalités prioritaires et support dédié, selon le site du projet — cet avis n'a trouvé aucun tarif Enterprise publié et recommande de contacter directement LiteLLM pour un devis.
- SDK open source et Proxy Server : aucun frais de licence, dépôt principal sous licence MIT (voir la remarque sur la licence ci-dessous)
- Vous continuez à payer le fournisseur vers lequel vous routez — LiteLLM ne réduit pas les tarifs des API OpenAI, Anthropic ou Bedrock, il les unifie et les suit seulement
- L'auto-hébergement du proxy a son propre coût d'infrastructure : un serveur ou un hébergeur de conteneurs, plus PostgreSQL et Redis pour un usage en production
- LiteLLM Enterprise ajoute SSO, support prioritaire et d'autres fonctionnalités professionnelles au-dessus du même cœur open source, selon litellm.ai/enterprise — les tarifs ne sont pas publiés et nécessitent de contacter l'entreprise
- Les tarifs Enterprise sont annuels et dimensionnés selon la capacité de requêtes de la passerelle, l'architecture de déploiement et les besoins de support, jamais par token, d'après litellm.ai/pricing ; une clé d'essai Enterprise de 30 jours est disponible et les devis passent par l'équipe commerciale
- Le Single Sign-On (SSO) est gratuit jusqu'à 5 utilisateurs depuis la version v1.76.0 ; au-delà, une licence enterprise est requise, d'après la documentation SSO de LiteLLM
LiteLLM vs. vLLM vs. LocalAI
LiteLLM, vLLM et LocalAI résolvent des problèmes différents que l'on confond facilement car les trois exposent une API compatible OpenAI. LiteLLM route les requêtes vers des modèles exécutés ailleurs ; vLLM et LocalAI exécutent eux-mêmes les poids du modèle.
Aspect | LiteLLM | ||
|---|---|---|---|
| Ce que ça fait | Route les requêtes vers des fournisseurs | Exécute les modèles lui-même | Exécute les modèles lui-même |
| Exécute les poids du modèle | Non | Oui | Oui |
| Licence | MIT (+ exception enterprise) | Apache-2.0 | MIT |
| GPU nécessaire | Non (routeur uniquement) | Oui, pour le service en temps réel | Selon le modèle |
| Idéal pour | Routage multi-fournisseurs & suivi des dépenses | Service auto-hébergé à haut débit | API unique auto-hébergée compatible OpenAI |
Ces outils sont généralement utilisés ensemble plutôt que comme des substituts l'un de l'autre : LiteLLM peut se placer devant un déploiement vLLM ou LocalAI comme couche de routage et de suivi des coûts, pendant que vLLM ou LocalAI réalise l'inférence proprement dite. Voir les articles dédiés vLLM expliqué et LocalAI expliqué pour plus de détails sur ces deux outils.
Pour qui LiteLLM est-il adapté ?
La pertinence de LiteLLM dépend du fait que votre application appelle déjà, ou prévoit d'appeler, plus d'un fournisseur LLM — une application mono-fournisseur tire moins de bénéfice d'une couche de routage.
Utilisez LiteLLM si
- Votre application appelle deux fournisseurs LLM ou plus (ou prévoit de le faire) et vous voulez un seul chemin de code plutôt que du code d'intégration par fournisseur
- Vous avez besoin d'un suivi centralisé des coûts et de budgets par clé ou par utilisateur sur plusieurs applications, équipes ou clients
- Vous voulez un basculement automatique vers un second fournisseur quand le premier tombe en erreur ou vous limite en débit
- Vous voulez mélanger des modèles cloud avec un modèle hébergé localement (via Ollama ou vLLM) derrière le même point de terminaison
- Vous voulez que la couche de routage soit open source (cœur MIT) plutôt qu'un service fermé, uniquement hébergé
Attendez, ou regardez ailleurs, si
- Votre application n'appelle qu'un seul fournisseur et vous ne prévoyez pas d'en ajouter un second — la couche de routage ajoute une surface opérationnelle (un proxy à exploiter, ou une dépendance SDK) sans bénéfice immédiat
- Vous voulez un moteur de service de modèles, pas un routeur — vous avez réellement besoin de quelque chose qui exécute les poids du modèle (voir vLLM ou LocalAI)
- Vous voulez un service de routage entièrement géré, sans exploitation, plutôt qu'un proxy auto-hébergé — un routeur hébergé comme OpenRouter évite la charge opérationnelle de PostgreSQL/Redis, au prix de passer par un tiers
- Une décision de licence dépend spécifiquement de code situé dans le répertoire
enterprise/— lisez directemententerprise/LICENSEplutôt que de supposer que la licence MIT de l'ensemble du dépôt s'y applique
LiteLLM face aux autres passerelles et frameworks
LiteLLM fait partie du segment routeurs et passerelles du Local LLM Software Directory de PromptQuorum, qui compte trois autres revues dédiées, listées en premier ci-dessous. Les autres comparaisons viennent d'outils voisins de la même partie « Run & Serve » du répertoire, ainsi que d'une alternative hébergée très connue, hors du répertoire.
- Plano — un proxy IA auto-hébergé basé sur Envoy et plan de données pour applications agentiques, avec routage LLM, observabilité et garde-fous (Apache-2.0).
- ClawRouter — un routeur LLM auto-hébergé, conçu pour les agents, qui prend ses décisions de routage en local entre modèles de pointe et modèles open-weight gratuits (MIT).
- AIClient2API — un proxy auto-hébergé qui convertit les protocoles clients de Gemini CLI, Codex, Grok, Kiro et Antigravity en une seule API compatible OpenAI (GPL-3.0).
- vLLM — un moteur d'inférence auto-hébergé qui exécute réellement les poids du modèle (GPU requis) ; couramment associé à LiteLLM plutôt qu'en concurrence avec lui, LiteLLM servant de couche de routage devant un ou plusieurs déploiements vLLM.
- LocalAI — un serveur API auto-hébergé compatible OpenAI pour exécuter localement des modèles ouverts ; résout un problème différent de celui de LiteLLM (exécution vs. routage) mais expose une API de format OpenAI similaire, source fréquente de confusion entre les deux.
- LangChain — un framework applicatif pour construire des applications basées sur des LLM (chaînes, agents, mémoire) ; il peut appeler LiteLLM (ou n'importe quel fournisseur directement) comme couche d'accès aux modèles plutôt que de remplacer ce que fait LiteLLM.
- OpenRouter (externe, absent du répertoire de PromptQuorum) — un service de routage hébergé et géré couvrant un cas d'usage multi-fournisseurs similaire au proxy de LiteLLM, mais en tant que service tiers que vous appelez plutôt qu'une infrastructure que vous auto-hébergez ; à comparer directement si vous voulez un routage sans exploitation plutôt que d'exploiter votre propre proxy.
Erreurs fréquentes en évaluant LiteLLM
La plupart des confusions autour de LiteLLM viennent du fait de le confondre avec un moteur de service de modèles, ou de trop simplifier sa licence.
Erreur 1 : supposer que LiteLLM exécute lui-même les modèles
LiteLLM est un routeur — il transmet les requêtes à des API de fournisseurs ou à un runtime local que vous configurez (Ollama, vLLM et autres). Il ne charge pas les poids du modèle et n'effectue pas d'inférence lui-même, contrairement à vLLM ou LocalAI.
Erreur 2 : traiter l'ensemble du dépôt comme simplement MIT
Le code principal est sous licence MIT selon le propre fichier LICENSE du dépôt, mais le contenu du sous-répertoire enterprise/ est sous une licence distincte définie dans enterprise/LICENSE. Vérifiez quels fichiers vous utilisez réellement avant de supposer que des conditions MIT générales s'appliquent.
Erreur 3 : ignorer PostgreSQL et Redis, puis constater des données de dépenses manquantes ou des limites de débit incohérentes
Le SDK litellm seul n'a besoin d'aucune base de données. Le Proxy Server auto-hébergé a besoin de PostgreSQL pour conserver les clés virtuelles et les données de dépenses, et de Redis pour une limitation de débit cohérente sur plus d'une instance de proxy — exécuter le proxy sans l'un ou l'autre fonctionne pour un test rapide, mais perd ces fonctionnalités à grande échelle.
Erreur 4 : s'attendre à ce que LiteLLM fasse baisser les tarifs des API des fournisseurs
LiteLLM suit et unifie les coûts entre fournisseurs ; il ne négocie ni ne remise les tarifs sous-jacents d'OpenAI, Anthropic ou Bedrock que vous payez déjà. Les économies viennent du routage/secours qui évite les nouvelles tentatives gaspillées et les blocages liés aux limites de débit, pas d'un tarif différent par token.
Questions fréquemment posées
Qu'est-ce que LiteLLM ?
LiteLLM (github.com/BerriAI/litellm) est une passerelle open source qui permet aux applications d'appeler plus de 100 API de fournisseurs LLM via une seule interface compatible OpenAI, disponible comme SDK Python ou comme serveur proxy auto-hébergé avec routage, suivi des coûts et limitation de débit.
LiteLLM est-il gratuit ?
Le SDK open source et le Proxy Server sont gratuits — vous ne payez que les appels API aux fournisseurs sous-jacents et votre propre hébergement. L'offre payante LiteLLM Enterprise ajoute le SSO au-delà de cinq utilisateurs, des journaux d'audit et un support 24h/24 et 7j/7 avec SLA ; elle est vendue à l'année sur devis, dimensionnée selon la capacité de requêtes et jamais par token. Une clé d'essai de 30 jours est disponible ; aucun tarif n'est publié.
LiteLLM convient-il à un usage en entreprise ?
Oui. Le cœur sous licence MIT (tout ce qui est hors de enterprise/) peut être utilisé commercialement, et les équipes l'exploitent comme passerelle interne partagée avec clés virtuelles, budgets et suivi des dépenses. Le SSO au-delà de cinq utilisateurs, SCIM, les journaux d'audit et le support sous SLA exigent la licence payante Enterprise ; sa page cite SOC 2 Type 2 et ISO 27001 (déclaration de l'éditeur, non vérifiée ici). La conformité au RGPD dépend des fournisseurs vers lesquels vous routez et de votre configuration ; ceci ne constitue pas un conseil juridique, consultez votre délégué à la protection des données.
Quelle licence utilise LiteLLM ?
Le dépôt principal est sous licence MIT, selon son propre fichier LICENSE. Une licence distincte s'applique uniquement au sous-répertoire enterprise/, définie dans enterprise/LICENSE — vérifié directement dans le fichier LICENSE du dépôt pour cet avis.
LiteLLM nécessite-t-il un GPU ?
Non. LiteLLM est un routeur de requêtes, pas un moteur d'inférence de modèle — il transmet les appels aux fournisseurs (API cloud ou runtimes locaux comme Ollama) au lieu d'exécuter lui-même les poids du modèle, il fonctionne donc très bien sur du matériel CPU uniquement.
Comment installer LiteLLM ?
Pour le SDK Python : pip install litellm. Pour le proxy auto-hébergé : `pip install 'litellm[proxy]' puis litellm --model gpt-4o, ou exécuter l'image Docker docker.litellm.ai/berriai/litellm:latest avec un config.yaml` monté. Voir le tableau d'installation ci-dessus pour les options Helm, AWS ECS Fargate et Google Cloud Run.
Le proxy LiteLLM nécessite-t-il une base de données ?
Pour un usage en production, oui — PostgreSQL conserve les clés virtuelles et les données de dépenses, et Redis maintient une limitation de débit cohérente sur plusieurs instances de proxy, selon la documentation de déploiement de LiteLLM. Un test local rapide peut fonctionner sans les deux, mais perd ces fonctionnalités.
LiteLLM peut-il router vers un modèle hébergé localement ?
Oui. La même model_list du config.yaml qui pointe vers OpenAI ou Anthropic peut tout aussi bien pointer vers un point de terminaison Ollama ou vLLM local, permettant à une passerelle de mélanger modèles cloud et locaux.
Comment LiteLLM se compare-t-il à OpenRouter ?
Les deux unifient plusieurs fournisseurs LLM derrière une interface. LiteLLM est une infrastructure auto-hébergée que vous exploitez vous-même (proxy ou SDK open source) ; OpenRouter est un service de routage hébergé par un tiers que vous appelez au lieu d'exploiter le vôtre. Le choix dépend de si vous voulez du zero-ops (OpenRouter) ou un contrôle total sans marge par requête d'un fournisseur de routage (LiteLLM auto-hébergé).
Qui développe LiteLLM ?
BerriAI, l'organisation derrière le dépôt github.com/BerriAI/litellm, qui affiche plus de 61 000 étoiles au moment de cet avis.