LiteLLM vs gateways managées : quand self-host coûte plus cher en réalité
Le coût fully-loaded de faire tourner ta propre gateway LLM, honnêtement

LiteLLM est une gateway LLM OSS bien construite et largement utilisée. C'est un vrai bon bout de soft. Ce n'est aussi pas le bon choix pour toute équipe, et l'argument "c'est gratuit" planque un ensemble de coûts qui ne se révèlent qu'après trois mois de run.

Ce n'est pas un hit piece. On a utilisé LiteLLM. On le réutiliserait pour la bonne forme d'équipe. La question c'est : quand est-ce que le self-hosting gagne vraiment, et quand est-ce qu'une gateway managée gagne ?

Faisons le calcul honnêtement.

Ce que LiteLLM te donne vraiment

L'offre core : une lib Python OSS et un proxy qui exposent 100+ providers LLM derrière une API compatible OpenAI. Deploie en Docker, Kubernetes, ou VM. Pointe ton app dessus. Fini.

De base tu as :

• Abstraction provider (un SDK, plusieurs backends)
• Routing de fallback (essaye provider A, puis B en échec)
• Caching basique
• Logging de requêtes
• Gestion de clés
• Tracking de budget (en tier enterprise)

C'est une vraie liste. Self-hosted, avec zéro coût par requête qui part chez un vendor.

Les coûts cachés du self-hosting

C'est là que le cadrage "c'est gratuit" commence à fuir.

Coût 1 : Temps ops

Un déploiement LiteLLM réaliste demande, au minimum :

• Docker ou Kubernetes pour le faire tourner.
• Une instance PostgreSQL (pour logs, budgets, état des clés).
• Redis (pour cache et rate limiting).
• Monitoring (Prometheus/Grafana ou équivalent).
• Agrégation de logs.
• Secret management pour les clés provider.
• CI/CD pour déployer les updates.

Si tu fais déjà tourner cette stack pour d'autres raisons, le coût marginal est petit. Sinon, tu provisionnes et maintiens 3-5 bouts d'infra que tu n'aurais pas eus autrement.

Estimé conservateur : 4-8 heures/semaine de platform engineering pour un déploiement non trivial. À un coût chargé de 100 €/heure pour un ingé expérimenté, ça fait 400-800 €/semaine, ou 1 600-3 200 €/mois.

Coût 2 : On-call

Si tes appels LLM sont dans le chemin critique d'une app prod, ta gateway qui tombe veut dire que ton produit tombe. Quelqu'un doit être joignable.

Les rotations on-call ont un coût même quand le pager ne sonne pas — c'est une contrainte sur la vie de l'ingé que le management refuse souvent d'admettre comme réelle. Pour une petite équipe, ajouter une nouvelle surface on-call pour la gateway LLM n'est pas gratuit.

Si ta gateway a un incident à 2h du mat, le coût de l'incident c'est le sommeil de l'ingé, le retard sur le backlog, le temps de debug réel, et potentiellement l'impact client. Une gateway managée sort cet incident de ton assiette — leur rotation on-call sonne, pas la tienne.

Coût 3 : Lag de features

Les providers shipent constamment de nouveaux modèles. Nouveaux champs d'API (structured outputs, extended thinking, paramètres de prompt caching). Nouveaux tiers de pricing. Nouveaux codes d'erreur. Nouvelles sémantiques de rate limit.

LiteLLM OSS suit la plupart de ça, mais il y a toujours un lag. Le cycle c'est : provider ship la feature → issue LiteLLM remontée → PR mergée → nouvelle release → tu upgrades ton déploiement → tu testes → tu déploies.

Pour nous, ce cycle était typiquement 1-4 semaines derrière une gateway managée qui ship en continu. Dans un espace qui bouge vite, quatre semaines comptent.

Coût 4 : Parité de features

LiteLLM OSS a routing et fallback. Il n'a pas (ou n'égale pas la profondeur des gateways managées sur) :

• Routing basé sur l'intelligence qui lit la complexité du prompt en temps réel
• Détection de burn-rate et alertes avant que le budget soit cramé
• Détection de zombie agents (activité agent hors heures)
• Détection de boucles (requêtes identiques qui repartent en boucle)
• Budgets par endpoint granulaires avec auto-downgrade
• UI d'observability soignée pour non-ingés

Tu peux construire chacune. Tu finis par toutes les construire. Chacune c'est une semaine d'ingé que tu ne passes pas sur ton produit réel.

Coût 5 : Charge d'upgrade

Toutes les quelques semaines LiteLLM ship une nouvelle version. Généralement mineure, occasionnellement breaking. Tu dois :

• Lire le changelog.
• Tester la nouvelle version contre ta config.
• Upgrader en staging.
• Smoke-tester.
• Déployer.

Quand ça casse — et ça arrive occasionnellement, c'est la nature d'un projet OSS qui bouge vite — tu debug, parfois contre la communauté OSS, parfois en lisant le code.

C'est du vrai boulot, et c'est du boulot qui scale linéairement avec le nombre de déploiements que tu fais tourner.

La comparaison fully-loaded

Modélisons un scénario concret : une équipe qui fait 1M requêtes LLM/mois avec 3 000 €/mois de dépense provider.

LiteLLM self-hosted

Gateway managée (style HiWay, flat par requête)

Managée est 2 781 €/mois moins cher à cette échelle, presque entièrement sur le labor d'ingénierie. Et c'est avant de compter le smart routing, qui coupe typiquement 40-85% sur les 3 000 € de dépense provider en plus — un levier que LiteLLM self-hosted ne te donne pas de base.

Ce sont des nombres illustratifs. Ton taux horaire ingé peut être 80 € ou 150 €. Ton overhead ops peut être 3h/semaine ou 12h/semaine. Mais la forme du calcul est robuste : une fois que tu price le temps d'ingénierie honnêtement, le self-hosted cesse d'être "gratuit".

Quand le self-hosting gagne vraiment

LiteLLM self-hosted gagne quand au moins une de ces conditions est vraie :

Tu as déjà la plateforme

Si ton équipe fait tourner un cluster Kubernetes, a PostgreSQL, Redis, Grafana, et des rotations on-call en place pour d'autres raisons, ajouter LiteLLM est proche du gratuit. L'infra est déjà là ; la charge opérationnelle marginale est petite.

Tu as un platform engineer dédié

Une équipe avec quelqu'un dont le job c'est le boulot plateforme — pas une rotation ops à temps partiel — peut absorber LiteLLM proprement. Les 4-8 heures/semaine dont on parlait plus haut sont dans sa charge existante, pas incrémentales.

Tu as des exigences dures de résidence des données

Si tu as besoin que ta gateway tourne dans une région précise, sur du hardware précis, avec des sous-processeurs précis — et qu'aucun service managé ne peut rentrer dans ces contraintes — le self-hosted est la seule option. C'est rare mais réel. Défense, santé dans certaines juridictions, gouvernemental.

Tu es sensible au coût et à l'échelle

À des volumes de requêtes très élevés (10M+ requêtes/mois) où les coûts d'abonnement gateway deviennent un vrai line item, le self-hosted peut être plus efficace si tes coûts plateforme sont amortis sur plusieurs workloads. Mais "très élevé" veut dire assez élevé pour que le calcul platform-engineering change aussi — tu as probablement l'équipe pour le supporter.

Tu veux la sortie de secours OSS par principe

Certaines équipes ne dépendront pas d'un vendor closed-source pour un composant de chemin critique, point. C'est un choix légitime. LiteLLM te donne une option OSS qu'un service managé closed-source ne te donne pas.

Quand une gateway managée gagne

Tu es une petite équipe qui ship du produit

Si ton équipe ingé fait moins de 10 personnes et ton job c'est de shipper des features, passer 4-8 heures/semaine sur l'ops gateway c'est 4-8 heures pas passées sur le produit. Le ROI de sous-traiter ça est immédiat.

Tu veux des features que tu ne construirais jamais toi-même

Détection burn-rate. Blocage zombie-agents. Routing basé sur l'intelligence. Auto-downgrade par endpoint. C'est 2-4 semaines d'ingé chacune. Pour la plupart des équipes, elles n'arriveraient jamais — la roadmap produit les écrase. Une gateway managée les shipe en défauts.

Tu veux de l'observability sans la construire

Une UI d'observability soignée — breakdowns de coût, percentiles de latence, dashboards par endpoint — est un vrai produit en soi. L'UI de LiteLLM est fonctionnelle. Les gateways managées sont typiquement en avance ici parce que c'est leur produit.

Tu veux la réponse d'incident sur le pager de quelqu'un d'autre

Le moment où un incident gateway n'est pas le problème de ton équipe, tu as sorti toute une catégorie d'inquiétude de tes épaules. Pour les équipes qui n'ont pas d'infra on-call, c'est substantiel.

Tu veux de l'hosting UE sans faire tourner un datacenter UE

Pour les équipes européennes qui ont besoin de résidence des données UE, utiliser une gateway managée déjà UE-hosted (sur OVH, sur Scaleway, sur un cloud européen) est infiniment plus rapide que monter ton propre déploiement régionalement compliant.

Le face-à-face

Le chemin hybride (qui est réel)

Certaines équipes font tourner LiteLLM en dev et test, et une gateway managée en prod. D'autres font l'inverse. Les deux marchent.

Si tu es à l'aise à faire tourner LiteLLM en local pour que les ingés testent contre — pas de charge ops, pas de scale — et utiliser une gateway managée pour la prod où fiabilité et profondeur de features comptent, tu as l'essentiel du meilleur des deux. Le coût principal c'est la dérive de config entre environnements.

Le bottom line honnête

LiteLLM est un super bout de soft. Il n'est aussi pas gratuit. Quand tu comptabilises honnêtement le temps d'ingé, la charge on-call, le lag de features, et la surface opérationnelle d'une gateway prod, LiteLLM self-hosted est moins cher qu'un service managé seulement à des combinaisons précises de forme d'équipe et d'échelle.

Pour la plupart des équipes — petits groupes ingé, orientés produit, pas de platform engineer dédié — une gateway managée est le choix plus pas cher, plus rapide, moins distrayant. Pour les équipes qui font déjà tourner l'infra plateforme, ont les effectifs, ou ont besoin d'OSS par principe, LiteLLM est la bonne réponse.

Il n'y a pas de gagnant universel. Il y a juste le calcul honnête pour ton équipe précise.

---

Prochain : les modèles de pricing des gateways LLM expliqués — au token, à la requête, BYOK, flat.