LiteLLM

LiteLLM est un SDK Python et un serveur proxy open-source (AI Gateway) qui unifie l’accès à plus de 100 fournisseurs de LLM via le format OpenAI, avec suivi des coûts, load balancing, guardrails et logging intégrés.

Éditeur: BerriAI
Type: SDK Python + Proxy Server (AI Gateway) open-source
Licence: MIT (open-source) + plans Enterprise payants
Providers supportés: 100+ (OpenAI, Anthropic, Azure, Vertex AI, Bedrock, Cohere, HuggingFace, vLLM, NVIDIA NIM, etc.)
GitHub Stars: 39 600+
Financement: $2,1M (Y Combinator, FoundersX, Gravity Fund)
Fondation: 2023, San Francisco (Krrish Dholakia)
URL: litellm.ai | GitHub

Qu’est-ce que LiteLLM ?

LiteLLM est en réalité deux outils sous un même nom, et il est important de bien les distinguer :

LiteLLM SDK : un package Python (pip install litellm) qui sert de couche de traduction. Vous appelez litellm.completion() avec n’importe quel modèle (OpenAI, Anthropic, Google, Azure, Bedrock, etc.), et LiteLLM traduit votre requête au format natif du provider, puis normalise la réponse au format OpenAI. C’est une bibliothèque qui tourne dans votre code Python.

LiteLLM Proxy : un serveur proxy auto-hébergé qui expose une API compatible OpenAI devant vos providers de LLM. Vos applications (en n’importe quel langage) appellent le proxy comme si c’était l’API OpenAI, et le proxy route les requêtes vers le bon provider. Il ajoute des fonctionnalités enterprise : clés virtuelles, budgets par utilisateur/équipe, load balancing, failover, guardrails, et logging vers des outils d’observabilité comme Langfuse, Helicone ou MLflow.

LiteLLM a été créé par Krrish Dholakia, passé par Y Combinator, avec un constat simple : gérer les appels à plusieurs providers LLM avec des formats d’API différents est un cauchemar d’ingénierie. L’objectif est de transformer ce problème en une seule ligne de code. Le projet a atteint plus de 39 600 étoiles sur GitHub et est utilisé par des entreprises comme Lemonade, qui combine LiteLLM avec Langfuse pour gérer ses modèles en production.

Le SDK : la couche de traduction

L’utilisation la plus simple de LiteLLM : appelez n’importe quel modèle avec la même syntaxe.

from litellm import completion
import os

os.environ["OPENAI_API_KEY"] = "sk-..."
os.environ["ANTHROPIC_API_KEY"] = "sk-ant-..."

# Même syntaxe, providers différents
response = completion(
    model="openai/gpt-5.4",
    messages=[{"role": "user", "content": "Bonjour !"}]
)

response = completion(
    model="anthropic/claude-sonnet-4.6",
    messages=[{"role": "user", "content": "Bonjour !"}]
)

response = completion(
    model="azure/mon-deployment",
    messages=[{"role": "user", "content": "Bonjour !"}],
    api_base="https://mon-resource.openai.azure.com/",
    api_key=os.environ["AZURE_API_KEY"]
)

Chaque réponse suit le format OpenAI, quel que soit le provider. Les exceptions sont aussi normalisées : LiteLLM mappe les erreurs de tous les providers vers les types d’exceptions OpenAI. Votre code de gestion d’erreurs fonctionne de manière identique avec tous les fournisseurs.

Le SDK inclut aussi le suivi des coûts intégré. LiteLLM connaît les tarifs de chaque modèle et calcule automatiquement le coût de chaque requête, ce qui permet de tracker les dépenses sans interroger les dashboards de chaque provider.

Le Proxy : l’AI Gateway auto-hébergé

Le Proxy est le produit clé pour les équipes qui veulent un gateway LLM en production. Il se déploie via Docker et expose un endpoint API compatible OpenAI :

# Déployer le proxy avec Docker
docker run 
  -v $(pwd)/config.yaml:/app/config.yaml 
  -e OPENAI_API_KEY=sk-... 
  -e ANTHROPIC_API_KEY=sk-ant-... 
  -p 4000:4000 
  ghcr.io/berriai/litellm:main-latest 
  --config /app/config.yaml

Les fonctionnalités du proxy en production :

Virtual Keys : créez des clés API internes pour chaque utilisateur, équipe ou projet. Chaque clé peut avoir un budget, des rate limits, et des modèles autorisés. C’est l’équivalent d’un système de gestion de clés API sans construire le vôtre.

Load balancing et failover : si votre déploiement Azure OpenAI renvoie une erreur 429 (rate limit), LiteLLM reroute automatiquement vers un déploiement de secours (autre région Azure, API OpenAI directe, Anthropic, etc.) sans que l’appelant ne s’en rende compte.

Budget tracking : suivez les dépenses par clé, par utilisateur, par équipe et globalement. Définissez des budgets max et LiteLLM bloque les requêtes quand le budget est atteint.

Guardrails : ajoutez du filtrage de contenu, du masquage PII, et des contrôles de sécurité directement au niveau du proxy.

Logging et observabilité : intégrations natives avec Langfuse, Helicone, MLflow, Prometheus, Supabase, Posthog, et d’autres. Chaque requête est loggée avec le modèle, les tokens, le coût, la latence et la réponse.

Admin UI : tableau de bord web pour gérer les clés, les budgets, les modèles et consulter les logs.

Support MCP et A2A : LiteLLM supporte le Model Context Protocol et le protocole Agent-to-Agent (A2A), permettant de router des requêtes vers des agents IA et des serveurs MCP via le même proxy.

Pricing LiteLLM

Le SDK et le proxy open-source sont gratuits (licence MIT). Les coûts réels viennent de trois sources :

Composante	Coût
LiteLLM SDK (pip install)	Gratuit (MIT)
LiteLLM Proxy (Docker)	Gratuit (MIT)
LLM Providers (OpenAI, Anthropic, etc.)	Tarifs standard des providers (aucune majoration)
Infrastructure (serveur, base de données)	≈ $200-500/mois en production
Enterprise Basic	$250/mois (Prometheus, guardrails LLM)
Enterprise (complet)	Custom (SSO SAML, audit logs, support dédié)

Le coût caché de l’auto-hébergement Le logiciel est gratuit, mais le faire tourner en production ne l’est pas. Le proxy nécessite PostgreSQL ou Redis pour la gestion des clés et des budgets. Ajoutez les coûts de serveur, de monitoring, de load balancing, de backups, et du temps ingénieur pour la maintenance. Pour un déploiement de production gérant un trafic modéré, comptez $200-500/mois d’infrastructure. Au-delà d’un certain volume, un service managé comme OpenRouter ou le Vercel AI Gateway peut être plus rentable en coût total (TCO).

LiteLLM vs OpenRouter vs Portkey

Critère	LiteLLM	OpenRouter	Portkey
Type	Open-source, auto-hébergé	Cloud managé	Cloud managé
Pricing	Gratuit (+ infra)	Pass-through + 5 %	Freemium + plans payants
Contrôle des données	Total (auto-hébergé)	Transit par OpenRouter	Transit par Portkey
Facturation unifiée	Non (vos clés, vos factures)	Oui	Oui (BYOK)
Failover	Oui (configurable)	Oui (automatique)	Oui
Virtual Keys / Budgets	Oui	Oui (enterprise)	Oui
Guardrails	Oui	Non	Oui
MCP / A2A	Oui	Non	Non
Maintenance	Votre responsabilité	Managé	Managé

Verdict Polydesk LiteLLM est le meilleur choix pour les équipes qui veulent un contrôle total sur leur gateway LLM : auto-hébergement (pas de tiers entre vous et vos providers), audit complet du code, et souveraineté des données. C’est la seule option viable pour les environnements air-gapped ou les secteurs réglementés (santé, défense, finance) qui interdisent le transit par un service tiers. Pour les équipes qui préfèrent la commodité d’un service managé, OpenRouter (facturation centralisée, zéro maintenance) est l’alternative naturelle. Portkey se positionne entre les deux avec des fonctionnalités de gouvernance enterprise.

Cas d’usage

Gateway LLM interne pour entreprise. Déployez le proxy LiteLLM en interne, créez des clés virtuelles pour chaque équipe, et définissez des budgets et des modèles autorisés. Vos développeurs appellent un seul endpoint, et LiteLLM route vers le bon provider. C’est le scénario de déploiement le plus courant pour les entreprises qui utilisent plusieurs fournisseurs de LLM.

Environnements réglementés. Si vous êtes dans la santé, la finance ou la défense, vous ne pouvez probablement pas envoyer vos requêtes LLM via un service cloud tiers. LiteLLM auto-hébergé est la seule option qui vous donne un contrôle total sur le chemin des données. Vous pouvez auditer chaque ligne de code, car le projet est open-source.

Migration multi-provider. Vous utilisez actuellement l’API OpenAI et voulez tester Anthropic ou Gemini ? Mettez LiteLLM devant votre code existant, et testez les nouveaux providers sans réécrire une ligne. Le failover automatique vous protège pendant la transition.

Suivi des coûts multi-provider. Si votre équipe utilise GPT-5.4 via Azure, Claude via l’API Anthropic, et Gemini via Vertex AI, consolider les coûts est un cauchemar. LiteLLM calcule automatiquement le coût de chaque requête et agrège les dépenses par clé, utilisateur et équipe dans un seul dashboard.

Intégration avec des frameworks d’agents. LiteLLM est compatible avec LangChain, LlamaIndex, Pydantic AI, CrewAI, AutoGen, et d’autres frameworks d’agents IA. Le support MCP et A2A permet de l’utiliser comme gateway pour des architectures multi-agents.

Démarrer avec LiteLLM

Option 1 : SDK Python (le plus simple). pip install litellm, configurez vos clés API en variables d’environnement, et appelez litellm.completion(). C’est suffisant pour du prototypage et des projets personnels.

Option 2 : Proxy Docker (production). Créez un fichier config.yaml avec vos modèles, lancez le container Docker, et pointez vos applications vers le proxy. Ajoutez PostgreSQL pour la persistance des clés et des budgets.

Option 3 : Enterprise. Contactez BerriAI pour le plan Enterprise avec Prometheus, SSO SAML, audit logs et support dédié.

Bonnes pratiques de déploiement. Utilisez les images Docker avec le tag -stable pour la production (elles ont subi des tests de charge de 12 heures). Configurez PostgreSQL managé (AWS RDS, Cloud SQL) plutôt qu’une instance locale pour la fiabilité. Activez les callbacks de logging vers Langfuse ou Helicone dès le premier jour pour avoir une visibilité sur vos coûts et vos performances. Définissez des budgets par clé virtuelle pour éviter les dérapages de coûts. Et testez le failover en simulant des erreurs 429 sur votre provider principal pour vérifier que le routage de secours fonctionne correctement.

LiteLLM fournit aussi un calculateur de coûts intégré dans l’admin UI : vous spécifiez un modèle, un volume de tokens attendu, et le nombre de requêtes par jour/mois, et il estime vos coûts mensuels. C’est un outil précieux pour budgétiser avant de passer en production. L’export en PDF ou CSV permet de partager les estimations avec les stakeholders non techniques.

Images Docker stables Pour la production, utilisez les images Docker avec le tag -stable. Ces images ont subi des tests de charge de 12 heures avant publication. Les images -latest sont plus récentes mais potentiellement moins stables.

Limites

Complexité opérationnelle en production. Faire tourner un proxy haute disponibilité avec Redis, PostgreSQL, monitoring et backups est un travail d’infra à part entière. Pour les petites équipes sans ingénieur DevOps dédié, la charge de maintenance peut dépasser les bénéfices.

Performance sous forte charge. Le proxy LiteLLM ajoute de la latence et du overhead de sérialisation. Selon les benchmarks, les performances se dégradent au-delà d’un certain volume de requêtes par seconde. Pour des charges très élevées, des solutions managées ou des gateways compilés (pas Python) peuvent être plus performants.

Python uniquement (SDK). Le SDK est Python-only. Le proxy expose une API REST compatible avec tout langage, mais la configuration et l’extension du proxy se font en Python.

Pas de facturation centralisée. Contrairement à OpenRouter, LiteLLM ne gère pas la facturation des providers. Vous payez chaque provider séparément avec vos propres clés. LiteLLM track les coûts, mais ne les consolide pas sur une seule facture.

Quand utiliser LiteLLM vs quand l’éviter

Utilisez LiteLLM si : vous êtes une équipe avec des compétences DevOps, vous opérez dans un secteur réglementé qui exige l’auto-hébergement, vous avez besoin de contrôler intégralement le chemin des données (air-gapped, on-premise), vous gérez des dizaines de développeurs internes qui appellent différents LLM et que vous devez tracker les coûts et budgets par équipe, ou vous voulez un hackathon interne où chaque participant reçoit une clé avec un budget plafonné.

Évitez LiteLLM si : vous êtes une petite équipe sans ingénieur DevOps dédié et que la maintenance d’un proxy en production représente un coût disproportionné, vous préférez une facturation unifiée sans gérer les relations avec chaque provider séparément (OpenRouter est plus adapté), ou vous avez besoin d’un SLA de 99,99 % sans vouloir construire et maintenir la haute disponibilité vous-même.

La règle empirique : si vous traitez moins de quelques milliers de requêtes par jour et que vous n’avez pas de contraintes réglementaires sur la localisation des données, un service managé est probablement plus rationnel. Au-delà, ou avec des exigences de souveraineté, LiteLLM devient l’option la plus pertinente.

Intégrations d’observabilité

L’un des points forts du proxy LiteLLM est son écosystème d’intégrations pour le logging et l’observabilité. Chaque requête peut être automatiquement envoyée vers :

Langfuse : observabilité LLM complète avec traces, coûts, et évaluation. C’est la combinaison la plus populaire avec LiteLLM.

Helicone : analytics et monitoring de requêtes LLM avec dashboard intuitif.

Prometheus : métriques pour l’alerting et le monitoring d’infrastructure (disponible sur le plan Enterprise).

MLflow : tracking d’expériences ML.

Supabase, Posthog, Mixpanel, Sentry : intégrations variées pour le logging et l’analytics produit.

La configuration se fait en une ligne dans le fichier config.yaml ou via les callbacks du SDK. Cette flexibilité dans le choix des outils d’observabilité est un avantage par rapport aux services managés qui imposent souvent leur propre dashboard.

Questions fréquentes sur LiteLLM

LiteLLM est-il vraiment gratuit ?

Le logiciel est gratuit et open-source (MIT). Vous pouvez le forker, le modifier et l’utiliser commercialement sans frais de licence. Les coûts réels viennent de l’infrastructure (serveur, base de données) et des providers LLM eux-mêmes. LiteLLM ne prélève aucune commission sur vos appels LLM. Pour les fonctionnalités enterprise (Prometheus, guardrails, SSO), BerriAI propose des plans payants à partir de $250/mois.

Quelle est la différence entre LiteLLM et OpenRouter ?

OpenRouter est un service cloud managé : vous achetez des crédits et OpenRouter gère tout (routage, failover, facturation, observabilité). Vos requêtes transitent par les serveurs d’OpenRouter. LiteLLM est un logiciel que vous déployez sur votre propre infrastructure. Vos requêtes vont directement de votre serveur au provider, sans tiers. LiteLLM offre plus de contrôle et de confidentialité ; OpenRouter offre plus de commodité et moins de maintenance.

Puis-je utiliser LiteLLM avec des modèles locaux ?

Oui. LiteLLM supporte les endpoints d’inférence locaux comme Ollama, vLLM, TGI, LM Studio, et tout serveur exposant une API compatible OpenAI. Vous configurez l’URL locale comme un provider supplémentaire dans le proxy, et vos modèles locaux sont accessibles via la même interface unifiée que vos providers cloud.

LiteLLM ajoute-t-il de la latence ?

Le SDK ajoute un overhead minimal (quelques millisecondes pour la traduction de format). Le proxy ajoute plus de latence car il s’agit d’un serveur intermédiaire. L’ajout dépend de votre infrastructure, mais comptez 5-20 ms pour le proxy. C’est négligeable par rapport au temps d’inférence du modèle (souvent 500 ms à plusieurs secondes).

Comment LiteLLM se compare-t-il au Vercel AI SDK ?

Le Vercel AI SDK est un toolkit TypeScript pour les applications web IA, avec des hooks UI natifs (React, Vue, Svelte). LiteLLM est un proxy Python pour le routage et la gouvernance des appels LLM. Les deux outils sont complémentaires : vous pouvez utiliser le Vercel AI SDK en frontend et LiteLLM en backend pour le routage, le budget tracking et le failover. Ils ciblent des couches différentes de votre stack.