LiteLLM face à OpenRouter : coût, contrôle et bascule automatique

Choisir une passerelle LLM ne revient pas seulement à vérifier si LiteLLM et OpenRouter parlent une API compatible avec OpenAI. La vraie question est de savoir qui exploite la couche de routage. OpenRouter constitue le point de départ le plus simple si votre équipe ne gère pas déjà une infrastructure de passerelle en production. LiteLLM justifie sa complexité supplémentaire lorsque le réseau privé, les règles sur mesure ou un usage soutenu rendent le contrôle suffisamment précieux pour y consacrer des ressources.

Le vrai choix porte sur le mode d’exploitation, pas sur le format d’API

LiteLLM est un logiciel open source qui peut fonctionner comme SDK Python ou comme proxy auto-hébergé. OpenRouter est une API managée et un catalogue de modèles : OpenRouter exploite la passerelle, agrège l’accès aux fournisseurs et vous offre un compte unique pour utiliser les modèles.

Les deux services peuvent exposer une interface compatible avec OpenAI, mais ils répartissent les responsabilités de manière très différente :

Cette différence rend aussi possible une architecture combinée : LiteLLM peut fournir la couche interne de gouvernance et de comptabilité, tandis qu’OpenRouter prend en charge l’accès à certains modèles.

Choisissez selon la contrainte qui vous pénalisera en premier

Le bon choix dépend de la première exigence sur laquelle votre équipe ne peut pas transiger.

Suivez l’argent, du prix des tokens à la facture d’ingénierie

LiteLLM et OpenRouter facturent des couches différentes. OpenRouter répercute le prix des modèles sous-jacents sans marge sur l’inférence, puis applique des frais de 5,5 % lors de l’achat de crédits. Le proxy open source de LiteLLM ne facture pas de frais de passerelle par token, mais vous devez financer l’infrastructure et les équipes nécessaires à son exploitation.

La page tarifaire d’OpenRouter constitue la source actuelle pour les conditions de facturation. Les frais sont liés à l’achat de crédits, et non à une simple majoration de 5 % du prix des tokens de chaque modèle.

Quand les frais d’OpenRouter restent le poste le moins cher

Si une équipe achète suffisamment de crédits OpenRouter pour couvrir sa facture mensuelle d’inférence :

• Avec une consommation mensuelle de $500, les frais d’achat de crédits de 5,5 % s’élèvent à $27.50.
• À $20,000, le même pourcentage représente $1,100.
• À $50,000, il atteint $2,750.

Ces montants indiquent ce que LiteLLM doit compenser après prise en compte de l’hébergement, du déploiement, des correctifs, des alertes, des sauvegardes et du temps d’ingénierie. À $500 par mois, OpenRouter demande souvent moins d’efforts opérationnels à une équipe qui n’exploite pas déjà une passerelle, sauf si le réseau privé est indispensable. À $20,000, une équipe responsable de sa plateforme a intérêt à chiffrer sérieusement LiteLLM.

Quand l’absence de frais de passerelle de LiteLLM devient réellement avantageuse

LiteLLM devient intéressant financièrement lorsque son coût fixe d’exploitation est déjà absorbé par votre équipe plateforme, ou lorsque les frais proportionnels évités dépassent le coût supplémentaire du proxy.

Le guide de démarrage rapide Docker officiel distingue un proxy simple sans base de données du déploiement avec base de données. Dans le flux Compose, PostgreSQL sert à stocker les modèles, les clés et les journaux de dépenses. Sans base de données, LiteLLM indique que les clés virtuelles, le suivi des dépenses et l’application effective des budgets ne sont pas disponibles ; un max_budget configuré ne constitue donc pas un plafond strict fiable.

Redis marque un autre seuil en production. Les prérequis Redis de LiteLLM recommandent un état Redis partagé dès que le proxy fonctionne avec plusieurs workers ou réplicas. Sans cela, les limites de débit, les budgets, les périodes de refroidissement, les entrées de cache et les observations de routage restent répartis entre les workers. Un test à worker unique coûte peu ; une passerelle de production déployée horizontalement forme un système bien plus conséquent.

Utilisez plutôt cette comparaison que le seul prix des tokens :

LiteLLM total cost = provider bills + infrastructure + operations + security ownership
OpenRouter total cost = provider inference + credit-purchase fee

Il n’existe pas de seuil universel de rentabilité. Les paramètres utiles sont les dépenses mensuelles d’inférence, l’hébergement, les heures d’ingénierie, la couverture d’astreinte et l’éventuelle prime liée à la conformité.

Comparez le plan de contrôle que vous devrez exploiter

LiteLLM offre davantage de contrôle à une équipe plateforme, mais ne crée pas l’accès aux fournisseurs à votre place. OpenRouter simplifie la découverte des modèles et la facturation centralisée, mais son catalogue hébergé ne remplace pas une relation directe avec les fournisseurs.

La fiabilité révèle les vraies différences entre les deux solutions

Les deux produits peuvent réessayer une requête ou basculer vers une autre cible, mais la responsabilité n’est pas la même. OpenRouter gère le pool de fournisseurs ; LiteLLM vous laisse définir ce pool et doit être exploité comme un composant à part entière de votre stack de fiabilité.

La documentation du routage des fournisseurs d’OpenRouter indique que le comportement par défaut répartit la charge entre les fournisseurs disponibles en tenant compte du prix et des pannes récentes. Vous pouvez demander un ordre de fournisseurs, autoriser ou désactiver les replis, exiger certains paramètres, filtrer selon la politique de traitement des données ou trier selon le prix, le débit ou la latence. Le guide des replis de modèles décrit une liste models ordonnée ; la facturation s’effectue selon le modèle qui traite finalement la requête.

La documentation du routage de LiteLLM décrit la sélection pondérée ou mélangée, le routage tenant compte de l’usage, le routage fondé sur la latence, le routage vers le serveur le moins chargé, le routage selon le coût et les stratégies personnalisées. LiteLLM prend également en charge les priorités de déploiement, les périodes de refroidissement, les nouvelles tentatives et les groupes de repli. Ces réglages sont plus programmables, mais leur fiabilité dépend de votre configuration, de vos contrôles de santé, de l’état partagé et de votre réponse aux incidents.

Latence des agents, cache et dérive des fournisseurs

Un saut réseau supplémentaire peut être négligeable pour une longue réponse en streaming. Il pèse davantage lorsqu’un agent enchaîne des dizaines d’appels courts au modèle, car les délais de passerelle, de réseau et de nouvelle tentative s’additionnent d’un tour à l’autre. Un proxy LiteLLM auto-hébergé peut être installé à proximité de l’application ; OpenRouter ajoute un passage par son service managé avant d’atteindre le fournisseur sélectionné. La documentation générique d’aucun des deux acteurs ne remplace un test dans votre région, avec votre modèle, votre mode de streaming et votre niveau de concurrence.

Le routage peut aussi modifier l’économie du cache. OpenRouter peut sélectionner plusieurs endpoints fournisseurs pour un même modèle, tandis que LiteLLM peut répartir les requêtes entre les déploiements configurés. Si un workflow dépend du cache de prompts côté fournisseur, un changement de route peut modifier la localité du cache et le coût en tokens. Intégrez donc le comportement du cache à vos tests de charge.

Un même identifiant de modèle ne garantit pas non plus un comportement identique. Les implémentations des fournisseurs peuvent différer par les limites de contexte, la prise en charge des appels d’outils, la latence, la quantification, la mise en cache et les paramètres propres au fournisseur. OpenRouter expose des filtres fournisseurs comme require_parameters, tandis que LiteLLM normalise les appels fournisseurs dans une interface commune. Testez les schémas d’outils et les paramètres de modèle exacts utilisés par votre agent.

Les pannes à anticiper

OpenRouter transforme les incidents d’infrastructure en dépendance vis-à-vis d’un fournisseur. LiteLLM les transforme en incidents que votre équipe plateforme peut inspecter et corriger.

Observabilité et confidentialité ne s’arrêtent pas au même endroit

« Auto-hébergé » et « privé » ne sont pas synonymes, pas plus que « managé » ne signifie « enregistre chaque prompt ». La bonne question consiste à déterminer quelle couche stocke le contenu, laquelle conserve les métadonnées et quels fournisseurs reçoivent la requête.

La documentation Zero Data Retention d’OpenRouter indique que le ZDR peut être imposé à l’échelle du compte, par groupe de modèles, garde-fou ou requête. Elle distingue les endpoints sans conservation des fournisseurs qui n’entraînent pas leurs modèles mais peuvent conserver temporairement les données. Le ZDR s’applique au routage d’inférence ; les outils et plugins activés doivent faire l’objet d’un examen séparé.

LiteLLM vous donne davantage de contrôle sur le réseau, la base de données, l’authentification et les journaux de la passerelle, mais cette responsabilité vous revient entièrement. Sécurisez le proxy, appliquez les correctifs, limitez les routes d’administration, protégez les clés fournisseurs et vérifiez les conditions de conservation et d’entraînement de chaque fournisseur amont.

L’architecture hybride est souvent la réponse la plus pragmatique

Placez LiteLLM devant OpenRouter lorsque vous avez besoin d’un endpoint interne stable et de règles de gouvernance, sans vouloir ouvrir un compte direct pour chaque modèle ou fournisseur. Acheminez directement les données sensibles ou prévisibles vers des fournisseurs approuvés, et envoyez les requêtes exploratoires ou dépendantes du catalogue via OpenRouter.

Voici un exemple de configuration simplifié :

model_list:
  - model_name: direct-claude
    litellm_params:
      model: anthropic/claude-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: catalogue-model
    litellm_params:
      model: openrouter/<provider>/<model>
      api_base: https://openrouter.ai/api/v1
      api_key: os.environ/OPENROUTER_API_KEY

LiteLLM devient ainsi l’endroit où appliquer les clés internes, les budgets, les tags et les journaux. Cela ne supprime pas les frais d’OpenRouter, le transit hébergé ni la frontière liée aux politiques des fournisseurs pour les requêtes qui passent par cette route. Vous ajoutez également un saut réseau et un domaine de panne supplémentaire : ne faites donc pas transiter automatiquement toutes les requêtes par les deux couches.

Une répartition cohérente consiste à utiliser :

1. Des routes directes vers les fournisseurs pour les données sensibles, les modèles de production stables ou les contrats fournisseurs négociés.
2. Des routes OpenRouter pour découvrir des modèles, accéder à des fournisseurs moins courants et profiter d’une bascule managée entre fournisseurs.
3. Les contrôles LiteLLM pour les clés applicatives, les équipes, les budgets et l’imputation interne des coûts.
4. Des tableaux de bord et des alertes distincts pour le trafic direct et le trafic OpenRouter.

Migration : ce qui change, et ce qui ne change pas

Faire passer un client compatible avec OpenAI d’une passerelle à l’autre peut être rapide. En revanche, migrer une charge de production ne se résume pas à modifier l’URL de base.

from openai import OpenAI
import os

client = OpenAI(
    base_url=os.environ["LLM_BASE_URL"],
    api_key=os.environ["LLM_API_KEY"],
)

OpenRouter utilise généralement https://openrouter.ai/api/v1 (référence de l’API) ; un proxy LiteLLM expose souvent un endpoint privé comme http://localhost:4000 (guide de démarrage rapide du proxy). Les identifiants de modèles, les préfixes fournisseurs, l’authentification et les paramètres facultatifs peuvent néanmoins différer.

Avant de basculer le trafic de production, testez :

1. Le streaming et le comportement des timeouts.
2. Les appels d’outils avec vos schémas JSON exacts.
3. Les sorties structurées et la gestion stricte du JSON.
4. Le raisonnement, la mise en cache et les paramètres propres aux fournisseurs.
5. Le comportement de repli lorsque le modèle principal renvoie une erreur 429, 5xx ou de validation.
6. L’imputation des coûts, car l’événement de facturation peut se produire à une couche différente de celle de la requête applicative.

La compatibilité d’API vous permet de réussir la première intégration. Elle ne garantit pas des sorties, une latence, une sélection de fournisseur ou une sémantique de facturation identiques.

Les questions que les équipes se posent avant de trancher

Peut-on utiliser LiteLLM et OpenRouter ensemble ?

Oui. LiteLLM peut utiliser OpenRouter comme route amont : LiteLLM gère alors les clés internes, les budgets, les journaux ou les règles, tandis qu’OpenRouter fournit l’accès à certains modèles et le routage entre fournisseurs. Le chemin combiné ajoute un saut et conserve les frais d’OpenRouter ainsi que sa frontière de données hébergée pour ce trafic.

Quelle solution coûte le moins cher pour une API en production ?

OpenRouter demande souvent moins d’efforts opérationnels à une petite équipe qui n’exploite pas déjà une infrastructure de passerelle. LiteLLM peut devenir moins cher à un niveau d’usage élevé si votre équipe gère déjà l’infrastructure nécessaire et souhaite éviter les frais proportionnels ; comparez le coût total, pas uniquement celui des tokens.

LiteLLM donne-t-il accès à l’intégralité du catalogue OpenRouter ?

Pas à lui seul. LiteLLM documente la prise en charge de plus de 100 LLM et d’un large éventail de fournisseurs dans son guide de démarrage rapide du proxy, mais il n’accède qu’aux fournisseurs et aux identifiants que vous configurez. Ajouter OpenRouter comme source amont peut élargir le catalogue accessible, mais les requêtes suivent alors la disponibilité des modèles et des fournisseurs d’OpenRouter.

Quelle solution convient le mieux à la confidentialité et à la conformité ?

LiteLLM auto-hébergé vous donne davantage de contrôle sur le déploiement de la passerelle, les journaux, les identifiants et la frontière réseau. OpenRouter propose des contrôles d’enregistrement du contenu, des filtres de politique fournisseur, un routage ZDR et des options régionales UE/États-Unis dans son offre Enterprise, mais reste présent dans le chemin de la requête ; vérifiez le fournisseur exact et l’exigence contractuelle concernée avant de choisir.

Choisissez la frontière que vous pouvez réellement exploiter : comparez les frais proportionnels à vos coûts réels de fonctionnement d’une passerelle, classez les requêtes autorisées à transiter par un intermédiaire hébergé et testez les pannes ainsi que le comportement de routage et d’appels d’outils nécessaires à votre application. Si vous ne pouvez pas prendre en charge la base de données, Redis, les mises à jour et les astreintes de LiteLLM, OpenRouter constitue le choix par défaut le plus réaliste. Si votre plateforme possède déjà ces capacités, LiteLLM ou une architecture hybride peuvent vous rendre le contrôle et réduire les frais récurrents de passerelle.

Pour découvrir davantage d’alternatives à OpenRouter, consultez OpenRouter alternatives ; ce comparatif reste volontairement plus ciblé et se concentre sur le choix du mode d’exploitation de LiteLLM.