LLM Gateway vs Router vs Inference Provider : la frontière architecturale

Une passerelle (gateway) LLM, un routeur et un fournisseur d'inférence sont trois couches distinctes dans la pile de service des modèles, et les confondre est l'erreur la plus courante que commettent les équipes lors de l'architecture de produits IA. La passerelle se situe au plus près de votre application et gère l'authentification, la normalisation et l'observabilité ; le routeur décide quel modèle ou fournisseur gère une requête donnée ; le fournisseur d'inférence est l'entité qui exécute réellement les poids et renvoie les tokens.

Se tromper sur cette frontière conduit à des intégrations fragiles : les équipes codent en dur le SDK d'un seul fournisseur, puis découvrent des mois plus tard que l'ajout d'un modèle de secours ou la comparaison des coûts entre Claude Sonnet 5, GPT-5.5 et DeepSeek V4 Flash implique de réécrire une grande partie de leur gestion des requêtes. Cet article sépare les trois couches, montre où résident réellement les responsabilités et fournit un cadre décisionnel pour évaluer les fournisseurs dans chaque catégorie.

Points clés à retenir

• Un fournisseur d'inférence exécute les poids du modèle et expose une API (OpenAI, Anthropic, Google, DeepSeek, ou un moteur auto-hébergé tel que vLLM) ; un routeur sélectionne parmi les fournisseurs ou les modèles par requête ; une passerelle est la couche orientée application qui unifie l'authentification, le formatage, la journalisation et le basculement (failover) entre les deux.
• La logique de routage (sélection basée sur le coût, la latence ou les capacités) peut exister en tant que service autonome ou en tant que fonctionnalité au sein d'une passerelle ; ce n'est pas la même chose que la passerelle elle-même.
• L'auto-hébergement d'un fournisseur d'inférence, l'utilisation d'un fournisseur basé sur une API et l'utilisation d'une passerelle multi-fournisseurs ne sont pas mutuellement exclusifs ; les systèmes de production combinent souvent les trois en fonction du modèle et de la charge de travail.
• Évaluez les fournisseurs en demandant sur quelle couche ils opèrent réellement, car un produit commercialisé comme un « routeur » peut ne router qu'entre des points de terminaison compatibles OpenAI qu'il n'héberge pas, tandis qu'une « passerelle » peut regrouper le routage et des fonctionnalités de gouvernance dont vous n'avez pas encore besoin.

Ce qu'un fournisseur d'inférence fait réellement

Le fournisseur d'inférence est la couche qui possède les poids du modèle, les GPU (ou accélérateurs équivalents) et le moteur de service de bas niveau. Cela inclut les fournisseurs d'API commerciaux tels qu'Anthropic (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5), OpenAI (GPT-5.5), Google (Gemini 3.5 Flash), Zhipu (GLM-5.2) et DeepSeek (DeepSeek V4 Pro, DeepSeek V4 Flash), ainsi que les déploiements auto-hébergés de modèles à poids ouverts comme Qwen3.7 Plus, MiniMax M3 ou Kimi K2.7 Code.

Si vous auto-hébergez, la couche fournisseur d'inférence est un logiciel que vous exécutez vous-même. La documentation de service de vLLM décrit un moteur d'inférence construit autour du traitement par lots continu (continuous batching) et de la gestion de l'attention efficace en mémoire pour servir les charges de travail LLM à grande échelle, ce qui est le type de composant qui se situe directement sous un déploiement de modèle auto-hébergé. Exécuter vLLM (ou un moteur comparable) fait de vous le fournisseur d'inférence pour ce modèle, responsable de la planification de la capacité GPU, de la mise à l'échelle et de la disponibilité, en échange d'un contrôle sur les coûts et la localité des données.

Si vous utilisez une API commerciale, l'infrastructure et les limites de débit (rate limits) du fournisseur deviennent votre contrainte. Chaque fournisseur a son propre schéma d'authentification, son schéma de requête et de réponse, ses codes d'erreur et son comportement en matière de limites de débit. C'est la couche où la qualité du modèle, la fenêtre de contexte et la latence brute sont réellement déterminées. Aucun routeur ou passerelle ne peut changer ce dont un fournisseur d'inférence est capable ; ils changent seulement la façon dont vous l'atteignez.

Ce qu'un routeur fait

Un routeur est une logique de décision qui sélectionne une destination, un modèle ou un fournisseur pour une requête entrante. Le routage peut se produire sur plusieurs axes : le coût (envoyer des requêtes simples vers un modèle bon marché comme DeepSeek V4 Flash ou Gemini 3.5 Flash, réserver Claude Opus 4.8 pour les plus complexes), la latence (préférer le fournisseur qui répond le plus rapidement pour un modèle donné) ou la disponibilité (basculer vers un second fournisseur si le premier est dégradé).

L'explication publique d'OpenRouter sur le routage des modèles décrit ce modèle au niveau du modèle : les requêtes pour un modèle à poids ouverts peuvent être routées à travers plusieurs fournisseurs qui hébergent les mêmes poids, de sorte qu'un seul appel de modèle logique peut être satisfait par l'un des nombreux backends. La documentation de sélection de fournisseur d'OpenRouter décrit en outre des paramètres pour exprimer des préférences d'ordre et pour exclure des fournisseurs spécifiques, ce qui est le mécanisme par lequel un appelant exprime explicitement son intention de routage plutôt que de la laisser entièrement à la plateforme.

Le point architectural important est que le routage est une politique, pas une catégorie de produit en soi. Vous pouvez implémenter vous-même un routage de base dans le code de l'application (un simple if/else sur le type de tâche ou une boucle de réessai en cas d'erreur), l'acheter en tant que couche de routage dédiée, ou l'obtenir intégré dans une passerelle plus large. Évaluez la capacité de routage en demandant quels signaux elle utilise (prix, latence, taux d'erreur, capacité du modèle) et si ces signaux sont configurables ou fixes.

Ce qu'une passerelle fait

Une passerelle est la couche avec laquelle votre code d'application communique réellement. Son rôle est de présenter une interface cohérente, quel que soit le fournisseur d'inférence qui sert finalement la requête. Une passerelle comprend généralement :

• Un schéma de requête et de réponse unifié entre les fournisseurs, afin que le passage de GPT-5.5 à Claude Sonnet 5 ne nécessite pas de réécrire votre logique d'analyse.
• La gestion de l'authentification et des clés, afin que les identifiants des fournisseurs ne soient pas dispersés dans le code de l'application.
• La journalisation, le suivi de l'utilisation et l'attribution des coûts pour chaque modèle et fournisseur utilisé.
• Le comportement de basculement et de réessai lorsqu'un fournisseur est lent, limité en débit ou renvoie une erreur.
• Optionnellement, une logique de routage en tant que fonctionnalité parmi d'autres, plutôt que le produit entier.

La page de recherche sur les modèles de TokenLab catalogue les modèles actuels parmi les fournisseurs, y compris les modèles de pointe (Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5, GPT-5.5, GLM-5.2, Gemini 3.5 Flash), les modèles orientés code (Claude Sonnet 5, Kimi K2.7 Code, DeepSeek V4 Pro, DeepSeek V4 Flash) et les candidats au routage à faible coût (DeepSeek V4 Flash, GLM-5.2, Laguna XS 2.1, Hy3, Qwen3.7 Plus, MiniMax M3), ce qui est le type de référence dont un utilisateur de passerelle a besoin pour décider vers quoi router. Consultez l'article de TokenLab sur pourquoi une passerelle d'API IA unifiée est importante en 2026 pour un traitement plus complet du problème de l'unification lui-même.

La frontière architecturale, concrètement

La frontière est plus facile à voir en traçant une seule requête à travers les trois couches.

1. Votre application envoie une requête de complétion de chat au point de terminaison de la passerelle, en spécifiant un type de tâche ou une préférence de modèle.
2. La passerelle authentifie la requête, la normalise selon le schéma attendu de chaque fournisseur candidat, et la transmet à la logique de routage.
3. Le routeur évalue sa politique configurée (plafond de coût, cible de latence ou ordre explicite des fournisseurs) et choisit une destination, par exemple Claude Sonnet 5 via l'API d'Anthropic, ou une instance DeepSeek V4 Pro auto-hébergée servie via vLLM.
4. Le fournisseur d'inférence exécute le modèle et renvoie les tokens.
5. La passerelle normalise la réponse dans une forme cohérente et enregistre le résultat (latence, coût, fournisseur utilisé, succès ou échec) pour votre couche d'observabilité.

Chaque couche peut échouer indépendamment. Une panne de fournisseur est un problème de couche d'inférence ; une mauvaise décision de routage (envoyer des requêtes à long contexte vers un modèle avec une petite fenêtre de contexte) est un problème de couche routeur ; un schéma de réponse incohérent brisant votre analyseur est un problème de couche passerelle. Comprendre quelle couche a produit un échec donné est ce qui rend le débogage gérable. L'article de TokenLab sur l'infrastructure de fiabilité pour les API IA couvre l'isolation des pannes à travers ces couches plus en profondeur.

Liste de contrôle décisionnelle

Utilisez cette liste de contrôle pour évaluer si vous avez besoin d'une passerelle, d'un routeur, d'une intégration directe avec un fournisseur, ou d'une combinaison.

Question	Si oui	Si non
Appelez-vous plus d'un modèle ou fournisseur aujourd'hui, ou prévoyez-vous de le faire dans les 12 prochains mois ?	Vous avez besoin d'une couche passerelle ou routeur, pas d'appels SDK directs par fournisseur.	Une intégration SDK directe avec un fournisseur peut suffire à court terme.
Avez-vous besoin d'un basculement automatique lorsqu'un fournisseur est dégradé ou limité en débit ?	Vous avez besoin d'une logique au niveau du routeur avec des vérifications de santé et un ordre de secours.	Les réessais manuels dans le code de l'application peuvent être acceptables initialement.
Avez-vous besoin d'une visibilité sur les coûts et l'utilisation par modèle à travers les fournisseurs en un seul endroit ?	Vous avez besoin d'une journalisation et d'une attribution au niveau de la passerelle.	Les tableaux de bord natifs des fournisseurs peuvent couvrir vos besoins pour le moment.
Auto-hébergez-vous des modèles à poids ouverts (GLM-5.2, DeepSeek V4 Pro, Qwen3.7 Plus, Kimi K2.7 Code) ?	Vous exploitez également une couche fournisseur d'inférence et avez besoin d'une infrastructure de service telle que vLLM.	Vous pouvez compter entièrement sur les fournisseurs d'API commerciaux.
Avez-vous besoin de router par type de tâche (modèle bon marché pour la classification, modèle de pointe pour le raisonnement) ?	Vous avez besoin d'une politique de routage explicite, pas seulement d'un basculement.	Un seul modèle par défaut peut suffire.

Exemple de forme de requête

L'exemple ci-dessous illustre la forme générale d'une requête de type passerelle qui exprime à la fois une préférence de modèle principale et une liste de secours, un modèle cohérent avec la façon dont la documentation de sélection de fournisseur d'OpenRouter décrit l'expression des préférences de routage. Considérez les noms de champs comme illustratifs ; vérifiez les paramètres exacts par rapport à la référence API actuelle de votre passerelle avant de déployer.

POST /v1/chat/completions
Content-Type: application/json
Authorization: Bearer <api_key>

{
  "model": "claude-sonnet-5",
  "fallback_models": ["gpt-5.5", "deepseek-v4-flash"],
  "routing_policy": {
    "strategy": "cost_then_latency",
    "max_cost_per_1k_tokens": 0.01
  },
  "messages": [
    {"role": "user", "content": "Summarize the attached incident report."}
  ]
}

Dans cette forme, la passerelle possède la normalisation de la requête et le contrat de réponse, le routeur possède l'interprétation de routing_policy et fallback_models, et quel que soit le fournisseur finalement sélectionné, il possède la génération réelle de la complétion. Confirmez le schéma exact de requête et de réponse par rapport à la documentation actuelle avant de vous fier à un nom de champ spécifique en production.

Limites

La documentation publique d'OpenRouter et de vLLM décrit des mécanismes généraux de routage et de service, pas des garanties universelles. La latence exacte, la tarification et le comportement de basculement varient selon le fournisseur et changent avec le temps, vérifiez donc les chiffres actuels directement par rapport à la documentation du fournisseur plutôt que cet article. L'auto-hébergement avec vLLM déplace la responsabilité opérationnelle (planification de la capacité, mise à l'échelle, correctifs) sur votre équipe ; cela n'élimine pas le travail d'infrastructure, il le déplace. Aucune politique de routage ne peut compenser un choix de modèle fondamentalement inadapté, comme l'envoi d'une tâche nécessitant un raisonnement à long contexte vers un modèle non adapté à cela ; la configuration du routeur ne remplace pas l'évaluation de la capacité du modèle par rapport à votre charge de travail, c'est pourquoi il est important de maintenir une référence de modèle à jour telle que la recherche sur les modèles de TokenLab.

FAQ

Une passerelle est-elle la même chose qu'un routeur ? Non. Un routeur est une logique de décision pour sélectionner un modèle ou un fournisseur ; une passerelle est la couche plus large orientée application qui inclut le routage comme une fonctionnalité possible aux côtés de l'authentification, de la normalisation et de la journalisation.

Puis-je être mon propre fournisseur d'inférence et utiliser quand même une passerelle ? Oui. Les modèles auto-hébergés servis via un moteur comme vLLM peuvent se situer derrière la même passerelle que les fournisseurs d'API commerciaux, tant que la passerelle prend en charge des points de terminaison personnalisés ou compatibles OpenAI.

Ai-je besoin des trois couches dès le premier jour ? Pas nécessairement. Une intégration directe avec un seul fournisseur est raisonnable pour un premier prototype. Dès que vous avez besoin de basculement, de contrôle des coûts multi-modèles ou de comparaison de fournisseurs, l'introduction d'une passerelle avec routage devient rentable par rapport au coût d'ingénierie.

Si vous évaluez quelle couche adopter en premier, passez en revue les options de modèles actuelles sur la page de recherche sur les modèles de TokenLab et commencez avec une configuration de passerelle qui vous permet d'ajouter progressivement du routage et des fournisseurs plutôt que de vous engager dans une seule intégration dès le départ.