Passerelle LLM vs OpenRouter : laquelle choisir ?

La réponse courte

Quand les gens demandent la différence entre une passerelle LLM et OpenRouter, ils comparent généralement deux choses différentes. OpenRouter est un routeur hébergé : une seule API et un seul compte qui vous permettent de choisir parmi de nombreux modèles provenant de plusieurs fournisseurs. Une passerelle LLM est une couche que vous placez devant un ou plusieurs points de terminaison de modèles pour gérer l'authentification, les réessais, les journaux, les budgets et le routage. Certaines passerelles sont hébergées, d'autres sont gérées par vous-même.

Le choix dépend de votre problème. Si vous voulez basculer librement entre les modèles de nombreux fournisseurs, un routeur est fait pour cela. Si vous voulez contrôler le trafic vers des endpoints que vous utilisez déjà, vous avez besoin d'une passerelle. Si vous n'avez besoin que d'un seul modèle sans censure derrière une API standard, vous n'en avez peut-être besoin ni l'un ni l'autre, car un endpoint unique compatible OpenAI est déjà la couche la plus simple. Cet article expose les différences pour vous aider à choisir, et montre où s'insère notre endpoint. L'explication sur les passerelles LLM couvre les bases si le terme est nouveau.

Trois choses appelées passerelle

1. Un routeur ou agrégateur de modèles

Un endpoint, plusieurs modèles, généralement une seule facture. Vous choisissez le modèle par son nom dans la requête et le service le redirige vers le fournisseur qui l'héberge. OpenRouter est un exemple connu. La valeur est la diversité : vous pouvez tester de nombreux modèles sans ouvrir plusieurs comptes. L'inconvénient est que votre trafic, votre disponibilité et vos politiques dépendent du routeur et de chaque fournisseur en amont, et chaque modèle conserve ses propres règles de contenu.

2. Une passerelle que vous gérez

Il s'agit d'un proxy situé au sein de votre infrastructure. Des projets open-source tels que LiteLLM remplissent ce rôle. Vous pointez vos applications vers le proxy, et le proxy communique avec un ou plusieurs fournisseurs. Vous obtenez un point central pour les clés, les limites de débit, le suivi des dépenses et les solutions de repli, et vous contrôlez où vont les journaux. Le coût est que vous devez désormais gérer un service.

3. Un endpoint direct

Un fournisseur, un modèle, une URL qui parle le protocole OpenAI. Aucune décision de routage à prendre. C'est la catégorie dans laquelle se situe notre API : https://api.openllmgateway.com/v1 sert un seul modèle à poids ouverts sous l'ID uncensored. Ce n'est pas un routeur entre plusieurs fournisseurs et ce n'est pas l'API officielle d'aucun fournisseur de modèle.

Comparaison côte à côte

Pour tout ce qui concerne les prix, les frais ou la liste des modèles d'un routeur spécifique, consultez leur tarification et leur documentation actuelles. Elles changent souvent et nous ne les indiquons pas ici.

Quand un routeur est le meilleur choix

Choisissez un routeur quand la question est « quel modèle est le meilleur pour cette tâche ? » et que vous vous attendez à ce que la réponse change. Un routeur vous permet de comparer de nombreux fournisseurs en changeant une chaîne. Il convient aussi aux prototypes où vous ne savez pas encore ce dont vous avez besoin, et aux applications qui veulent permettre aux utilisateurs de choisir dans un catalogue.

Soyez conscient de ce qu'un routeur ne vous donne pas. Le comportement du modèle reste celui du modèle en amont. Si un modèle refuse une requête légale, le routeur transmet le refus. Le routage entre plusieurs modèles peut aussi rendre les sorties moins cohérentes pour un produit qui nécessite le même ton à chaque fois.

Quand vous voulez une couche de passerelle

Une passerelle justifie son utilité lorsque vous avez plusieurs backends ou plusieurs équipes. Raisons typiques : budgets par équipe, stockage centralisé des clés pour que les applications ne voient jamais les clés du fournisseur, journalisation des requêtes dans votre propre stockage, gestion centralisée des tentatives et des délais d'attente, et basculement d'un endpoint à un autre.

Notre endpoint fonctionne comme l'un de ces backends. Toute passerelle capable de rediriger vers une URL compatible OpenAI peut l'utiliser avec l'URL de base et une clé Bearer. Une vérification minimale côté client que le backend est accessible :

Copycurl https://api.openllmgateway.com/v1/models \
  -H "Authorization: Bearer $API_KEY"

curl https://api.openllmgateway.com/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "uncensored", "messages": [{"role": "user", "content": "ping"}], "max_tokens": 5}'

Si vous prévoyez d'exécuter une passerelle en production, la liste de contrôle pour les passerelles IA en production indique ce qu'il faut couvrir : délais d'attente, tentatives, limites, secrets et surveillance.

Quand vous n'avez besoin ni de l'un ni de l'autre

De nombreuses applications ont une exigence d'un seul modèle : un produit de chat, un outil d'écriture, un compagnon de jeu de rôle pour adultes, un classifieur par lots. Pour ces cas, ajouter un routeur ou une passerelle ajoute un saut et un point de défaillance sans apporter de valeur. Le SDK OpenAI gère déjà les réessais et les délais d'attente, et le point de terminaison retourne déjà les en-têtes nécessaires à la surveillance : X-Request-Id, X-Balance-USD, X-RateLimit-Limit-Requests et X-RateLimit-Limit-Concurrency.

Les limites sont simples. Une clé complète obtient 8 requêtes simultanées et 300 par minute ; une clé d'essai en obtient 2 et 60. Au-delà d'une limite, vous recevez un HTTP 429 avec le code rate_limited ou concurrency. Une surcharge temporaire retourne également un 429 avec Retry-After: 5. Une requête en streaming occupe sa place de concurrence jusqu'à la fin du flux.

Les fonctionnalités que vous ajouteriez autrement dans une passerelle sont déjà présentes : streaming via SSE, appel d'outils, mode JSON et une fenêtre de contexte de 100 000 tokens. Ce qui n'est pas présent : génération d'images, d'audio ou de vidéo, embeddings et fine-tuning. Si vous en avez besoin, associez ce point de terminaison à un autre service, ce qui est le seul cas où une passerelle commence à avoir du sens même pour les petits projets.

Coût et démarrage

L'endpoint est en paiement à l'usage à partir d'un crédit prépayé : 0,15 $ par 1M de tokens d'entrée et 0,50 $ par 1M de tokens de sortie, sans abonnement, un crédit qui n'expire jamais, et aucun frais pour les requêtes échouées ou refusées. À titre d'exemple, une requête avec 2 000 tokens d'entrée et 500 tokens de sortie coûte 2 000 x 0,15 $ / 1M plus 500 x 0,50 $ / 1M, soit 0,0003 $ plus 0,00025 $, ou 0,00055 $. Voir la page de tarification pour les montants de rechargement et les bonus. Les paiements par carte et en crypto sont acceptés.

Pour l'essayer, réclamez le crédit d'essai de 0,50 $ en un clic sur la page de clé API après vous être inscrit avec Google ou par e-mail. Puis suivez la documentation pour pointer votre client ou votre passerelle vers l'URL de base. Les prompts ne sont pas utilisés pour l'entraînement.

Plus de guides

• Passerelle LLM en Python : appeler un endpoint backend
• Checklist AI Gateway : API LLM sans censure