Alternatives à LiteLLM (2026) — passerelles hébergées, plans de contrôle avec votre propre clé et quand rester en place

LiteLLM est un proxy open source compatible avec OpenAI que vous exécutez vous-même : il se place devant vos propres comptes fournisseurs et fournit à votre code un point de terminaison et un format de clé uniques (sa documentation). Les équipes cherchent des alternatives pour deux raisons sans rapport. Opérationnelle : un proxy auto-hébergé est un service supplémentaire à corriger, dimensionner et surveiller. Chaîne d’approvisionnement : le 24 mars 2026, un attaquant a publié deux versions compromises de LiteLLM sur PyPI, exposant à de nombreuses équipes le risque lié à « un package dans votre build ». Cette sélection associe chaque motivation à l’outil qui y répond réellement — y compris le cas où il vaut mieux rester, qui est plus solide que ne le suggèrent les sept listes de fournisseurs de cette recherche.

Biais déclaré d’emblée : Kunavo est notre produit et il est présenté en premier. Tous les autres outils ci-dessous font l’objet d’une recommandation sincère ; les détails que nous avons vérifiés figurent sur les pages de comparaison, et les deux solutions que nous n’avons pas évaluées sont décrites uniquement au niveau indiqué par leurs propres sites.

La liste courte

La distinction qui fait l’essentiel du travail

LiteLLM remplit deux fonctions à la fois, tandis que la plupart des remplaçants n’en remplissent qu’une. C’est un proxy (un point de terminaison pour plusieurs fournisseurs) et un outil BYO-key (les comptes fournisseurs restent les vôtres). Une passerelle d’inférence hébergée — Kunavo, OpenRouter — remplace les deux : aucun proxy à exécuter ni compte fournisseur à gérer, car la passerelle détient les identifiants amont et vous facture l’utilisation. Un plan de contrôle hébergé — Portkey, TrueFoundry — ne remplace que le premier : vous cessez d’exploiter le proxy, mais conservez les comptes. Savoir quelle moitié vous remplacez permet de comprendre l’essentiel de cette liste. Le modèle est expliqué dans le guide des passerelles LLM.

Ce qui a réellement poussé les gens à chercher

Le premier résultat de cette recherche n’est pas un article sous forme de liste, mais un fil Reddit consacré à l’attaque de la chaîne d’approvisionnement. Voici ce qui s’est passé, d’après la mise à jour de sécurité de LiteLLM : le 24 mars 2026, un attaquant a publié litellm==1.82.7 et litellm==1.82.8 sur PyPI avec du code malveillant injecté dans les fichiers wheel distribués. Ils sont restés disponibles à partir de 10:39 UTC pendant environ 40 minutes, avant leur mise en quarantaine par PyPI. La compromission a été attribuée à la dépendance Trivy du workflow d’analyse de sécurité CI/CD de LiteLLM ; l’attaquant a contourné le workflow officiel de publication et a téléversé directement sur PyPI. Selon SecurityWeek, plus de 2 500 organisations ont été touchées.

Les mesures correctives de LiteLLM sont documentées et importantes : retrait des packages compromis, renouvellement des identifiants des mainteneurs, intervention de Mandiant pour l’analyse forensique et publication de la v1.83.0 via un pipeline CI/CD reconstruit avec des environnements de build isolés, des contrôles de publication renforcés et des images Docker signées par cosign. Si vous utilisez la 1.83.0 ou une version ultérieure et n’exécutiez pas une version empoisonnée pendant cette fenêtre de 40 minutes, l’incident est clos pour vous.

La raison pour laquelle cet incident pousse encore les gens à effectuer cette recherche est structurelle, et non propre à LiteLLM. Un proxy auto-hébergé est un package dans votre build, ce qui place votre CI/CD et votre cluster dans son rayon d’impact. C’est la phrase à retenir : elle vaut également pour toutes les alternatives auto-hébergées de cette page, y compris MLflow AI Gateway, et c’est la seule chose qu’un point de terminaison hébergé supprime : vous appelez une URL HTTPS, donc aucun package ne peut être empoisonné et rien de la passerelle ne s’exécute dans votre réseau.

L’autre moitié, honnêtement : une passerelle hébergée n’est pas plus sûre, elle est exposée différemment. Votre clé API et vos prompts transitent par l’infrastructure de quelqu’un d’autre, et vous assumez son risque de compromission au lieu de votre propre risque de maintenance. Si les prompts ne peuvent pas quitter votre infrastructure, l’auto-hébergement est la bonne réponse ; le reste de cette page concerne un compromis que vous ne devriez pas accepter.

1. Kunavo — aucun proxy, aucun compte fournisseur

Kunavo est une passerelle d’inférence hébergée : une base URL compatible avec OpenAI, une clé sk-kn-, un solde à l’usage, et nous détenons les identifiants des fournisseurs amont à votre place. Par rapport à LiteLLM, la répartition des responsabilités est différente : vous n’exécutez pas de proxy et ne gérez pas séparément des comptes Anthropic, Google et OpenAI.

Prix : la plupart du catalogue est proposé à des tarifs inférieurs aux tarifs officiels des fournisseurs — Claude Sonnet 4.6 à $2.10 / $10.50 par million de tokens, contre $3.00 / $15.00 chez Anthropic. LiteLLM n’applique aucune marge puisqu’il ne revend rien ; vous payez votre propre contrat fournisseur. La comparaison oppose donc notre tarif à votre tarif direct, et non à zéro. Couverture : modèles de chat, d’image, de vidéo et de musique avec la même clé et le même solde. Ce qu’il ne fait pas : acheminer vos propres clés fournisseurs — c’est la partie BYO-key que LiteLLM conserve et que nous ne remplaçons pas. Détails : Kunavo contre LiteLLM.

2. OpenRouter — la plus longue liste de modèles

L’autre passerelle d’inférence hébergée, à choisir lorsque l’étendue du catalogue compte davantage que le prix unitaire : des centaines de modèles provenant d’un grand nombre de fournisseurs avec un seul portefeuille, ainsi que des niveaux gratuits et un routage avec vos propres clés, que Kunavo ne propose pas. Si vous quittez LiteLLM pour cesser de gérer des comptes, OpenRouter et Kunavo sont les deux formes réalistes. Kunavo contre OpenRouter les compare côte à côte, et la sélection OpenRouter couvre le reste de ce segment.

3. Portkey — gardez vos clés, abandonnez l’exploitation

Un plan de contrôle hébergé au-dessus des comptes fournisseurs que vous possédez déjà : routage, solutions de repli, garde-fous et observabilité, sans proxy à exploiter vous-même. C’est le remplacement le plus proche si vous avez choisi LiteLLM pour ses fonctions de routage et de budget et que vous souhaitez uniquement abandonner son exploitation. Détails : Kunavo contre Portkey.

4. Helicone — si l’observabilité était l’unique raison

De nombreux déploiements LiteLLM existent parce qu’une équipe avait besoin des journaux de requêtes et de l’attribution des coûts par équipe, et que le proxy était le moyen d’y parvenir. Si cela décrit votre cas, une couche d’observabilité au-dessus de vos appels fournisseurs existants est beaucoup plus légère à exploiter qu’une passerelle. Détails : Kunavo contre Helicone.

5. TrueFoundry — lorsque les achats exigent un fournisseur

Occupe la position 2 dans cette recherche avec sa propre comparaison à LiteLLM. Il s’agit d’une passerelle IA d’entreprise vendue sur la base de la latence, de la flexibilité de déploiement, des SLA, de la gouvernance et de contrôles prêts pour l’audit (sa page produit). Nous ne l’avons pas évaluée ; cette entrée est donc un renvoi plutôt qu’une recommandation : si votre obstacle est l’absence de contrat de support pour un proxy open source, c’est la catégorie qui répond à ce besoin, et il vaut la peine de lire la comparaison en sachant qu’ils l’ont rédigée.

6. MLflow AI Gateway — le remplacement open source équivalent

Position 3 et solution la plus proche de LiteLLM sur cette page : une passerelle open source et auto-hébergée qui place vos propres clés fournisseurs derrière un point de terminaison, maintenue dans le cadre du projet MLflow. Il faut le dire clairement : remplacer un proxy auto-hébergé par un autre conserve le modèle de déploiement et donc la surface d’attaque décrite plus haut. C’est un choix légitime — à privilégier si ce qui vous déplaisait était le projet, et non le modèle.

7. Cloudflare AI Gateway — mise en cache et limites en périphérie

Un proxy léger devant les comptes fournisseurs que vous possédez déjà : mise en cache des réponses, limitation du débit, nouvelles tentatives et analyses, sans revente d’inférence. Il se combine avec n’importe quelle source d’inférence au lieu d’en remplacer une, y compris Kunavo ou OpenRouter. Détails : Kunavo contre Cloudflare AI Gateway.

Quand LiteLLM reste le bon choix

• Le texte des prompts ne peut pas quitter votre infrastructure. Données réglementées, environnements isolés du réseau ou politique qu’une passerelle hébergée ne peut tout simplement pas respecter. L’auto-hébergement est la réponse ; la seule question est de savoir quel proxy auto-hébergé choisir.
• Vous avez négocié des contrats avec les fournisseurs. Les dépenses engagées ou les tarifs entreprise chez Anthropic, OpenAI ou Google valent plus que tout ce qu’affiche un revendeur, et les outils permettant d’utiliser votre propre clé sont la manière de continuer à les utiliser.
• Vous utilisez ses budgets par clé et son routage par équipe. Ces fonctionnalités expliquent l’existence de nombreux déploiements LiteLLM ; vérifiez que votre solution de remplacement les couvre avant de supposer qu’un simple changement d’URL de base suffira à la migration.
• Vous voulez du code que vous pouvez lire et modifier. Un proxy open source que vous contrôlez est un véritable atout, et l’incident de mars 2026 ne le remet pas en cause — il s’agissait d’une compromission du pipeline de publication, désormais corrigée, et non d’une faille du proxy lui-même.

Le changement se fait en deux lignes

Toutes les alternatives présentées ici qui revendent de l’inférence parlent le protocole filaire OpenAI ; quitter un proxy LiteLLM est donc un base_url et un changement de clé — les formats des requêtes et des réponses restent inchangés :

# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
    api_key=os.environ["LITELLM_MASTER_KEY"],
    base_url="http://litellm.internal:4000",
)

# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
    api_key=os.environ["KUNAVO_API_KEY"],
    base_url="https://api.kunavo.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-5",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

La partie qui ne tient pas en deux lignes, c’est tout ce que LiteLLM faisait au-delà du routage : budgets par clé, diffusion vers plusieurs équipes, callbacks personnalisés. Faites d’abord l’inventaire. Les détails au niveau du protocole figurent dans le guide de l’API compatible avec OpenAI, et ce qu’une passerelle doit gérer pour vous présente l’ensemble des fonctionnalités à vérifier chez une solution de remplacement.

Questions fréquentes