Les 5 meilleures alternatives à LiteLLM : commencez par savoir quel rôle vous remplacez

Soyons clairs d'entrée : si votre installation LiteLLM tourne bien, vous n'avez sans doute pas besoin de lire tout ça — sautez à la dernière section. Ce qui pousse vraiment à l'arracher, ce n'est jamais qu'il serait « pas assez puissant ». Ce sont les moments précis et agaçants — un worker du proxy qui grignote la RAM à 2h du matin jusqu'à ce que l'OOM killer l'abatte ; la RSS qui grimpe sur Kubernetes au point que la doc de production officielle vous dit littéralement de recycler les workers tous les N requêtes ; un config.yaml gonflé à plus de 200 lignes que plus personne n'ose toucher ; une montée de version mineure qui a discrètement changé votre comportement de fallback, et vous ne l'apprenez qu'en prod. Voilà ce qui fait taper « on change de passerelle ? » dans Slack.

Cet article ne va donc pas sacrer un vainqueur unique. « Alternatives à LiteLLM » est une formule un peu trompeuse — presque personne ne remplace LiteLLM en bloc. On remplace un ou deux des rôles qu'il joue. Une fois ce déclic passé, toute la décision se simplifie nettement. Si vous ne connaissez pas encore bien LiteLLM, notre guide complet de LiteLLM sert d'amorce ; ici, on part du principe que vous l'avez déjà mis les mains dedans.

1. D'abord : quel rôle de LiteLLM remplacez-vous vraiment ?

LiteLLM assure discrètement quatre tâches à la fois, plus une cinquième qu'il ne touche pas mais à laquelle vous finirez par être confronté :

• Interface unifiée — aplatir les SDK dissemblables d'OpenAI, Anthropic, Gemini et d'une flopée de modèles chinois en un seul appel au format OpenAI. C'est sa valeur centrale, et la plus difficile à remplacer proprement.
• Suivi des coûts — qui a dépensé combien, quelle clé a fait sauter son budget, un relevé détaillé.
• Bascule (failover) — passage automatique sur un secours quand la route principale tombe, rotation de clés pour esquiver les limites de débit.
• Observabilité — logs, latence, erreurs, nombre de tokens par appel.
• Posséder l'inférence — la seule tâche que LiteLLM ne fait pas : à qui appartient le GPU qui fait réellement tourner ces modèles ?

Chacune des cinq « alternatives » ci-dessous ne mord que sur une ou deux de ces tâches. OpenRouter reprend « interface unifiée + bascule », entièrement géré. Portkey attrape « interface unifiée + observabilité + gouvernance/guardrails ». LangSmith ne fait en réalité que le rôle « observabilité/évaluation » — le prendre pour un remplaçant de passerelle, c'est un contresens. Cloudflare AI Gateway vous donne « observabilité + cache + suivi des coûts » en périphérie, mais en pass-through. vLLM/Ollama fait la cinquième tâche, complètement à part : posséder l'inférence. Une fois cette répartition des rôles comprise, vous arrêtez de vous torturer avec « lequel est le meilleur » et vous demandez simplement « lequel me manque ? ».

2. Le tableau comparatif, en un coup d'œil

La colonne à retenir, c'est la deuxième. Remarquez qu'aucune ne soulève les quatre tâches de LiteLLM d'un coup — parce que LiteLLM est lui-même un assemblage de plusieurs choses cousues ensemble. Passons aux analyses. Celle qui mérite plus en aura plus ; les cas marginaux auront deux phrases.

3. OpenRouter : si vous voulez juste que ce soit géré, c'est lui

Ce que c'est : un agrégateur de modèles managé. Une clé API, un base_url, et derrière se trouvent plus de 400 à 500 modèles chez une soixantaine de fournisseurs. Vous ne maintenez rien. Quand la route principale ralentit ou tombe, il bascule vers un autre fournisseur en périphérie, et votre application ne s'en aperçoit quasiment pas.

L'intégration est d'une facilité presque risible — souvent c'est vraiment une seule variable d'environnement :

# OpenRouter : changez le base_url et votre SDK OpenAI fonctionne tel quel
export OPENAI_API_KEY="sk-or-..."
export OPENAI_BASE_URL="https://openrouter.ai/api/v1"

Côté performance, c'est meilleur qu'on ne l'imagine. Il tourne en périphérie, donc le routage n'ajoute qu'environ 15 à 25 ms de surcoût ; dans un benchmark de latence public en 2026, le temps jusqu'au premier token d'OpenRouter a même battu l'appel direct à OpenAI d'environ 70 ms, parce qu'il est plus proche de l'utilisateur et choisit l'instance de fournisseur la plus rapide sur le moment. La disponibilité sur 90 jours glissants est de 99,99 %. Pour une équipe qui veut juste alterner entre GPP et Claude de façon fiable, c'est franchement sans douleur.

Maintenant, ce qui agace. D'abord, ces 5,5 % ne sont pas prélevés sur vos tokens — ils le sont sur l'argent que vous chargez. Chaque recharge de crédit perd 5,5 % par carte (5 % en crypto), avec un minimum de 0,80 $ par transaction. C'est de la marge bien réelle, et ça pique au volume. Ensuite, le calcul du BYOK (apporter sa propre clé amont) a changé le 14 juillet 2026 : c'était auparavant une allocation gratuite au nombre de requêtes (1 M/mois en Pay-as-you-go, 5 M en Enterprise), et c'est désormais mesuré en inférence au prix catalogue — gratuit jusqu'à 25 000 $/mois en PAYG (200 000 $ en Enterprise), et au-delà vous payez 5 % de ce que l'appel aurait coûté sur la plateforme d'OpenRouter. Si toute votre raison de faire du BYOK était d'économiser, refaites le calcul. Enfin, et c'est le point qui devrait le plus intéresser un ingénieur : le routage est une boîte noire. Vous ne contrôlez pas complètement quel fournisseur — ni quelle quantification — vous sert. Même nom de modèle, qualité réelle potentiellement différente selon le backend sur lequel vous êtes tombé.

En une ligne : si vous voulez juste basculer entre deux ou trois modèles propriétaires de pointe sans rien exploiter — OpenRouter, ne réfléchissez pas trop. Si vous êtes sensible à la granularité des coûts ou au fait de savoir exactement qui vous sert, cette boîte noire va vous gêner. Pour les options de relais en connexion directe, il y a plus de choix ; voyez notre comparatif des relais d'API IA en parallèle.

4. Portkey : le plus complet — mais il a un nouveau propriétaire

Ce que c'est : passerelle + observabilité + guardrails, en un. C'est depuis longtemps l'option la plus complète pour « je veux une passerelle unifiée et de l'observabilité et des garde-fous de niveau entreprise » — routage, limitation de débit, application de politiques et visibilité complète sur chaque interaction avec un modèle dans un seul produit, traitant selon l'éditeur des milliers de milliards de tokens par mois. Sur la seule capacité, il est plus orienté entreprise qu'OpenRouter et plus orienté passerelle que LangSmith.

En une ligne : en capacité, il reste l'option de type passerelle la plus complète des cinq. Mais à ce stade, mi-2026, je n'ancrerais pas un projet tout neuf et se voulant neutre dessus — attendez de voir où atterrit la feuille de route post-rachat. À l'inverse, si vous êtes déjà dans l'écosystème Palo Alto et que guardrails/conformité sont des exigences dures, le rachat joue en votre faveur.

5. LangChain / LangSmith : le voir comme un remplaçant de passerelle, c'est se tromper d'axe

Dissipons une confusion courante : mettre LangChain/LangSmith dans une liste d'« alternatives à LiteLLM », c'est se tromper d'axe. LangChain est un framework d'orchestration d'applications ; LangSmith est une plateforme de traçage/évaluation/observabilité. Ni l'un ni l'autre n'est une passerelle, et aucun ne fait le travail « aplatir chaque SDK en un seul format » qui est toute la raison d'être de LiteLLM.

Mais si ce que vous vouliez vraiment de LiteLLM sans jamais l'obtenir, c'est justement le rôle observabilité — voir la chaîne d'appels complète de chaque requête, disposer d'un vrai harnais d'évaluation (eval) — alors LangSmith est une réponse légitime. Ses arbres de traces et son outillage d'évaluation vont bien plus loin que la journalisation intégrée de LiteLLM.

Le prix se paie sur deux plans. Un : ce n'est pas un proxy transparent — vous devez instrumenter votre code, donc pas le changement indolore de base_url des autres. Deux : la tarification mord. Le palier gratuit Developer, c'est 5 000 traces/mois, 14 jours de rétention, un siège. Plus, c'est 39 $/siège/mois avec 10 000 traces de base incluses, dépassement à 2,50 $ les 1 000, et si vous voulez la rétention étendue à 400 jours, c'est 5,00 $ les 1 000. Les sièges s'additionnent linéairement — dix personnes, c'est 390 $/mois avant tout dépassement. Le vrai piège, c'est le dépassement de traces : une équipe de cinq produisant 2 millions de traces par mois peut dépasser 5 000 $/mois. Estimez votre volume d'appels avant d'instrumenter, pas quand la facture tombe.

En une ligne : choisissez LangSmith quand ce qui vous manque, c'est « voir ce qui s'est réellement passé à chaque appel » plus une boucle d'évaluation. Si vous vouliez une passerelle, il répond à une autre question.

6. Cloudflare AI Gateway : le presque-gratuit sous-estimé

Ce que c'est : un plan de contrôle en périphérie qui vous donne observabilité, cache, limitation de débit et suivi des coûts. C'est le plus facile à oublier de la liste et, dans la bonne situation, le meilleur rapport qualité-prix du lot.

L'économie est jolie. Les fonctions cœur de la passerelle sont gratuites, sans frais par appel ; le palier gratuit inclut 100 000 logs/mois, et au-delà Workers Paid (5 $/mois) vous en donne 1 million. Le tout nouveau Unified Billing de 2026 vous permet même de rapatrier l'usage des modèles tiers (OpenAI et consorts) directement sur votre facture Cloudflare, au prix de 5 % de frais sur les crédits. Le cache fait vraiment économiser — un hit revient directement de la périphérie et ne touche jamais l'amont.

En une ligne : si vous êtes déjà sur Cloudflare et que ce que vous voulez, c'est précisément observabilité, cache et un point d'étranglement pour le débit — cette couche est quasi gratuite et proche du zéro-ops. N'attendez juste pas d'elle l'« un seul format pour tous les fournisseurs » de LiteLLM.

7. Auto-hébergement vLLM / Ollama : un tout autre axe

À proprement parler, ces deux-là ne sont pas des « alternatives à LiteLLM » du tout — ils remplacent cette cinquième tâche, posséder l'inférence, c'est-à-dire faire tourner le modèle vous-même. Dans la vraie vie de l'ingénierie, vous ne mettez généralement pas vLLM à la place de LiteLLM ; vous faites tourner le modèle sur vLLM et vous placez un LiteLLM (ou une autre passerelle) devant. Ils s'empilent ; ce n'est pas l'un ou l'autre.

Ollama est le roi du local et du prototype : cinq minutes pour un modèle qui tourne sur votre propre machine, parfait avec Open WebUI ou un RAG qui n'a pas besoin de concurrence. Mais son plafond est dur. Par défaut, il gère environ 4 requêtes simultanées (OLLAMA_NUM_PARALLEL vaut 1 par défaut, parfois 4 sur les machines à forte VRAM), et sous charge il se stabilise autour de 41 tokens/seconde. À 128 utilisateurs simultanés, sa latence P99 grimpe à 673 ms tandis que vLLM, dans le même test, reste sous 100 ms. Il a aussi un travers désagréable : quand plusieurs utilisateurs sollicitent le même modèle, il concentre la charge sur un seul GPU et laisse les autres cartes inactives. La conclusion est brutale : Ollama a sa place sur votre propre machine, pas pour encaisser la concurrence de production.

vLLM est la vraie réponse pour l'auto-hébergement en production. PagedAttention plus le continuous batching poussent le débit jusqu'à 24 fois au-dessus des implémentations naïves, et en 2026 c'est le socle de base de toute pile d'inférence sérieuse — né au Sky Computing Lab de l'UC Berkeley, aujourd'hui projet cœur de l'écosystème PyTorch, en production chez LinkedIn et Uber. Stripe a réduit son coût d'inférence de 73 % après y avoir migré, servant 50 millions d'appels par jour sur un tiers de sa flotte de GPU. Le prix, c'est l'ops : vous possédez les GPU, l'ordonnancement, l'autoscaling, la supervision. Ce n'est pas un travail de changement de base_url.

En une ligne : passez à l'auto-hébergement sur vLLM quand les données ne peuvent pas sortir des murs, quand l'échelle rend l'exploitation maison moins chère, ou quand vous avez besoin de votre propre modèle affiné — et gardez Ollama pour votre portable et les démos. Et souvenez-vous : une fois qu'il tourne, vous voudrez probablement encore une passerelle devant, ce qui vous ramène aux options ci-dessus.

8. Lequel choisir, en clair

• Vous voulez juste basculer entre OpenAI et Claude sans ops → OpenRouter, ne réfléchissez pas trop. Acceptez juste les 5,5 % de frais de recharge.
• Vous êtes déjà sur Cloudflare et voulez observabilité + cache + limitation de débit → Cloudflare AI Gateway, presque gratuit, branché en une journée.
• Contexte entreprise, besoin de guardrails / conformité / audit, surtout si vous êtes déjà client Palo Alto → Portkey. À l'inverse, si vous êtes un projet neuf qui tient à la neutralité, attendez et observez.
• Ce qui vous manque vraiment, c'est « voir chaque appel + faire des évals » → LangSmith, mais dimensionnez d'abord votre volume de traces et gardez un œil sur cette facture qui gonfle.
• Les données ne peuvent pas sortir / l'échelle rend l'auto-hébergement moins cher / vous faites tourner des modèles affinés → auto-hébergement vLLM avec une passerelle devant ; gardez Ollama pour le dev local.

9. La conclusion honnête : bien souvent, ne changez pas

Après tout ça, la ligne la plus à contre-courant — et la plus utile à dire — est celle-ci : bien souvent, la meilleure « alternative », c'est de ne pas changer du tout.

Le problème de mémoire qui donne envie de fuir a un remède connu. La propre doc de production de LiteLLM le détaille : configurez le recyclage des workers — redémarrez chaque worker après N requêtes servies pour contenir la lente dérive mémoire — figez votre version pour qu'une montée mineure ne vous surprenne pas, et posez une limite de mémoire sur le processus. En gros, ceci :

# Faites tourner le proxy LiteLLM sous gunicorn et recyclez les workers après
# un nombre fixe de requêtes pour contenir la lente croissance mémoire (à ajuster)
litellm --config config.yaml \
  --num_workers 4 \
  --run_gunicorn --max_requests 1200 --max_requests_jitter 200

Et à noter : LiteLLM migre lui-même vers un cœur Rust (son slogan actuel est « Rust core with Python SDK »), donc le surcoût en forte concurrence qui restait coincé derrière le GIL de Python se résout peu à peu — dès la v1.78.5, le surcoût médian à 1 000 requêtes simultanées est retombé à 8 ms. Autrement dit, le problème que vous rencontrez aujourd'hui pourrait avoir disparu à la prochaine version.

Voici la version un peu cavalière : la plupart des gens changent de passerelle à cause d'un après-midi pourri, pas parce qu'ils ont vraiment heurté un plafond architectural. Déterminez si vous avez heurté le plafond ou juste un accident de config avant de vous engager dans une migration. Les migrations ne sont pas gratuites non plus — ne troquez pas un piège que vous savez déjà contourner contre un tout nouveau.