La facture arrive en fin de mois et personne ne sait l'expliquer. Trois mille euros chez un fournisseur de modèles, contre huit cents le mois précédent. La question tombe en réunion : qui a dépensé quoi ? La réponse honnête, dans la plupart des entreprises qui ont commencé à coder avec des modèles de langage, c'est qu'on l'ignore. Les clés ont été distribuées au fil de l'eau, chaque service a la sienne, chaque prototype tape en direct sur l'API, et le tableau de bord du fournisseur donne un total mensuel sans rien dire de sa composition.
Le second problème arrive six mois plus tard, quand la direction demande si on ne pourrait pas héberger tout ça en interne, vu le prix. Là, on découvre que quatorze applications appellent l'API en dur, avec quatorze clés, et que basculer vers un serveur d'inférence local suppose de rouvrir quatorze dépôts.
LiteLLM règle ces deux problèmes avec la même pièce : une passerelle posée entre vos applications et les modèles.
Une seule adresse, cent fournisseurs derrière
Le principe tient en une phrase : vos applications parlent à LiteLLM au format OpenAI, et LiteLLM parle à qui vous voulez. Anthropic, Azure, Bedrock, Vertex AI, Mistral, un serveur vLLM sur votre propre carte graphique, un modèle Nvidia NIM. Le catalogue annoncé par le projet dépasse la centaine d'API.
Concrètement, une application qui pointait sur api.openai.com pointe désormais sur votre passerelle, avec une clé que vous avez émise vous-même. Le nom du modèle demandé devient un alias que vous contrôlez.
model_list:
- model_name: assistant-interne
litellm_params:
model: anthropic/claude-sonnet-5
api_key: os.environ/ANTHROPIC_API_KEY
- model_name: assistant-interne
litellm_params:
model: hosted_vllm/mistral-small
api_base: http://gpu01.interne:8000/v1
Deux entrées, un seul nom exposé. L'application demande assistant-interne et ignore complètement ce qu'il y a derrière. Le jour où le GPU local est prêt, vous modifiez cette configuration, pas le code applicatif. Le jour où le GPU tombe en panne, le trafic repart chez le fournisseur externe. C'est exactement ce qui rend un investissement matériel défendable devant une direction financière : il devient réversible.
Les clés virtuelles, là où la facture redevient lisible
La passerelle émet ses propres clés. Une par équipe, une par application, une par prestataire si vous en avez. Chacune porte un budget, une liste de modèles autorisés et une limite de débit.
curl -X POST 'https://llm.interne/key/generate' \
-H 'Authorization: Bearer sk-maitre' \
-H 'Content-Type: application/json' \
-d '{
"key_alias": "equipe-support",
"models": ["assistant-interne"],
"max_budget": 200,
"budget_duration": "30d",
"rpm_limit": 60
}'
Deux cents euros par mois pour le support, au-delà la clé refuse. Le mois suivant, le compteur repart. Vous n'avez plus un total mensuel opaque mais une ligne par équipe, avec le détail par modèle et par requête, stocké dans votre propre base.
C'est la fonction qui justifie à elle seule le déploiement. Une dépense qu'on ne sait pas ventiler est une dépense qu'on finit par couper en bloc, souvent au pire moment. Une dépense ventilée se discute service par service.
Ce que le routage sait faire, et ce qu'il ne fera pas à votre place
Plusieurs entrées portant le même model_name forment un groupe. La passerelle répartit entre elles, bascule sur la suivante quand l'une répond en erreur, et sort de la rotation celle qui échoue en boucle. Vous pouvez pondérer, fixer un ordre de priorité, imposer un délai maximal au-delà duquel on passe à la suivante.
Le repli entre un modèle local et un modèle distant marche, mais il demande une décision que l'outil ne prendra pas pour vous : accepter que la qualité des réponses change en cours de route. Un petit modèle ouvert servi sur votre carte et un modèle commercial de dernière génération ne produisent pas le même texte. Pour un classement de tickets ou une extraction de champs, la différence est souvent invisible. Pour de la rédaction destinée à un client, elle se voit. Le repli automatique est une bonne idée sur les tâches de traitement, une mauvaise sur les tâches de production écrite, et personne ne peut trancher ça à votre place.
Le déploiement réel
La documentation du projet est explicite sur ce qu'attend un déploiement de production, et l'écart avec le docker run de démonstration mérite d'être connu avant de s'engager.
PostgreSQL porte les clés, les budgets et le journal des dépenses. C'est la base supportée, les autres ne le sont pas. Elle devient un composant critique : si elle tombe, plus personne n'obtient de réponse. Un couple répliqué s'impose dès que la passerelle sert des applications qui comptent, avec la bascule automatique que décrit notre article sur la haute disponibilité PostgreSQL avec Patroni.
Redis devient obligatoire dès la deuxième instance. Il porte le cache, les compteurs de limite de débit et l'état partagé du routeur. Sans lui, deux instances comptent chacune de leur côté et vos plafonds valent le double de ce que vous croyez. Là encore, un Redis en haute disponibilité plutôt qu'un conteneur isolé.
Le dimensionnement recommandé est d'un vCPU et quatre gigaoctets de mémoire par instance, avec un seul worker par conteneur et une mise à l'échelle horizontale. L'autoscaling se règle sur le processeur avec une cible à soixante pour cent ; la mémoire n'est pas un signal exploitable ici.
Deux réglages évitent des surprises de facturation interne. L'écriture groupée des dépenses toutes les soixante secondes, au lieu d'une écriture par requête, épargne la base. Au-delà du millier de requêtes par seconde, un tampon transactionnel dans Redis évite les blocages sur ces mêmes écritures.
general_settings:
proxy_batch_write_at: 60
use_redis_transaction_buffer: true
trusted_proxy_ranges: ['10.0.0.0/8']
litellm_settings:
set_verbose: false
json_logs: true
Le champ des plages de confiance mérite un mot : sans lui, derrière un répartiteur de charge, toutes les tentatives d'authentification semblent venir de la même adresse et le comptage des échecs devient inutilisable.
Les pièges qui coûtent cher
Un réglage ne se change jamais après coup : la clé de salage qui chiffre les identifiants des fournisseurs stockés en base. La modifier après avoir enregistré des modèles rend ces enregistrements illisibles, sans message d'erreur explicite. Elle se met dans votre coffre à secrets, au même titre que le reste, et elle n'en bouge plus. Si vous n'avez pas encore de coffre, OpenBao fait le travail.
Le mode production doit être déclaré explicitement par variable d'environnement, faute de quoi la passerelle continue de charger un fichier d'environnement local, comportement acceptable sur un poste de développement et douteux sur un serveur.
Enfin, le rythme du projet impose une discipline. Entre deux versions publiées en septembre 2026, le journal des modifications compte plus de quatre cent soixante-dix commits. C'est le signe d'un projet vivant, avec cinquante-neuf mille trois cents étoiles et plus de cinq mille tickets ouverts, mais c'est aussi la garantie qu'un déploiement suivant l'étiquette latest changera de comportement sans prévenir. On épingle une version, on lit les notes avant de monter, on teste ailleurs qu'en production.
Le code est sous licence MIT, à une exception près : le répertoire enterprise/ relève d'une licence propriétaire distincte. Les fonctions qu'il contient ne sont pas libres d'usage. Pour une passerelle d'entreprise classique, clés, budgets, routage et journalisation, la partie MIT suffit. Vérifiez ce point avant de bâtir une offre dessus.
Où ça se place dans une infrastructure
La passerelle est un point de passage obligé, donc un point de panne. Elle se traite comme tel : plusieurs instances, un répartiteur devant, une supervision qui remonte les erreurs par fournisseur et pas seulement le taux global. Un fournisseur qui dégrade sans tomber se voit sur la latence par groupe de modèles, pas sur la disponibilité de la passerelle, qui reste verte pendant que les utilisateurs attendent. Les métriques exposées s'intègrent à une chaîne Prometheus et Grafana classique.
Quand nous posons cette brique chez un client, la première question n'est jamais technique. Elle porte sur ce qui a le droit de sortir du réseau. Une passerelle bien configurée est aussi le seul endroit où l'on peut appliquer une règle du type « les données de ce service ne partent que vers un modèle hébergé en France », et le seul endroit où cette règle se vérifie dans un journal. Pour un dossier soumis au RGPD ou pour une organisation qui s'est engagée sur un hébergement souverain, c'est la pièce qui rend l'engagement démontrable plutôt que déclaratif.
Le reste suit : le serveur d'inférence sur GPU derrière la passerelle, le partage de cartes entre plusieurs charges si le parc le justifie.
Ce qu'il faut en retenir
LiteLLM ne rend pas l'IA moins chère. Il rend sa dépense visible, attribuable et plafonnée, ce qui est la condition pour en discuter sereinement, et il découple les applications du fournisseur, ce qui est la condition pour changer d'avis plus tard sans tout réécrire. Ces deux propriétés valent largement la base PostgreSQL et le Redis qu'il faut tenir derrière.
Une passerelle mal exploitée redevient vite le point de panne qu'elle prétendait supprimer : base non répliquée, version qui suit latest, aucune alerte par fournisseur. Quand la facture des modèles commence à peser dans un budget, la brique se pose et se tient comme n'importe quel composant critique, et c'est ce travail-là que nous faisons sur les infrastructures que nous opérons. Si vous en êtes au point où personne ne sait ventiler la dépense par équipe, nous pouvons poser la passerelle et l'exploiter, avec ou sans GPU derrière.
Sources
- Dépôt GitHub BerriAI/litellm, version v1.101.0 du 15 septembre 2026, 59 313 étoiles, licence MIT hors répertoire enterprise
- Documentation de production du proxy, dimensionnement, base de données, réglages obligatoires
- Site officiel litellm.ai, positionnement et catalogue de fournisseurs
- Notes de version v1.101.0, contenu du cycle de septembre 2026
