LLM router : choisir ses modèles et vérifier les gains

Votre meilleur modèle doit se concentrer sur les tâches qui exigent ses capacités. Une réponse sur le suivi d’une commande authentifiée et un remboursement contesté, avec des informations contradictoires au dossier, ne devraient pas suivre automatiquement le même parcours. Toute la difficulté consiste à les distinguer avant qu’une réponse bon marché n’entraîne des corrections coûteuses.

Les comportements des produits présentés ici ont été vérifiés dans leur documentation en ligne le 21 octobre 2026. La charge de travail du support et les calculs servent d’illustration : ce ne sont ni des mesures en production ni des économies annoncées par les fournisseurs.

À quoi sert un LLM router ?

Un LLM router, ou routeur de modèles, est une règle ou un classificateur entraîné qui choisit le grand modèle de langage — le LLM — chargé de répondre à chaque requête. Un classificateur affecte une entrée à une catégorie. Pour choisir un modèle, le routeur peut s’appuyer sur le type de tâche de votre application, la conversation, les outils nécessaires, la taille de l’entrée ou une estimation de la difficulté.

Imaginez une personne qui répartit les dossiers au sein d’une équipe de support. Une simple recherche d’information revient à quelqu’un qui la traitera efficacement ; un litige va à un spécialiste. Cette personne doit aussi savoir à qui transmettre un dossier que personne dans l’équipe n’est habilité à résoudre.

Dans une application, cela revient à vérifier l’admissibilité avant d’optimiser : ce modèle peut-il traiter l’entrée, appeler les outils requis et passer par un fournisseur autorisé ? Seuls les candidats admissibles doivent être comparés sur le coût ou la qualité attendue.

Le routage des modèles, le routage des fournisseurs et le repli répondent à des questions différentes. Le premier choisit le modèle qui répondra. Le deuxième détermine où exécuter un modèle donné, par exemple chez quel hébergeur. Le repli, ou fallback, décide quoi tenter après un échec. Une passerelle — la couche d’accès entre votre application et les API des modèles — peut assurer ces trois fonctions. Mais son ajout ne suffit pas à créer un sélecteur de modèles qui tient compte de la qualité.

Dans cet article, le modèle de pointe désigne le candidat généraliste le plus performant que vous envisagez d’utiliser. Il peut malgré tout se tromper. Le routage répartit les capacités ; il ne garantit pas la véracité des réponses.

Les trois approches du routage LLM

Commencez par des règles que vous pouvez expliquer. La sélection automatique devient intéressante lorsqu’elle prend en charge des variations que ces règles ne couvrent pas, tout en respectant vos critères d’acceptation. Ces trois approches peuvent se combiner : une passerelle peut héberger un routeur entraîné.

Des règles définies dans l’application

Votre application associe des types de tâches et des contraintes connus à des modèles. Une requête provenant d’un endpoint de suivi de commande, avec des données de commande authentifiées et un modèle de réponse validé, se prête mieux à un petit modèle qu’un message jugé facile simplement parce qu’il est court.

Ces règles sont utiles lorsque l’application connaît déjà le workflow. Leur limite est l’ambiguïté : le même endpoint peut recevoir une simple demande d’information ou une réclamation fondée sur des données contradictoires. Prévoyez un parcours explicite pour les cas incertains au lieu d’allonger sans fin une liste de mots-clés fragiles.

Le routage automatique d’une passerelle

Vous envoyez une requête à un alias de routage, puis la passerelle choisit le modèle. Selon le produit, cette sélection peut reposer sur un classificateur, des niveaux configurés ou d’autres signaux. Le comportement est centralisé, mais vous adoptez aussi la définition qu’a le routeur d’un bon choix.

Cette approche convient lorsque les tâches entrantes varient et que maintenir votre propre sélecteur représenterait un effort disproportionné. Limitez la sélection à un ensemble de candidats approuvés et consignez le modèle qui a réellement répondu. Un alias ne désigne pas toujours le même modèle.

La boucle d’apprentissage d’un routeur de modèles

Un routeur entraîné apprend, à partir d’exemples et de résultats annotés, quel candidat a le plus de chances de mieux répondre. La question utile pour l’entraînement est de savoir si le modèle le plus performant apporte une valeur supplémentaire à cette requête, pas simplement si le texte paraît complexe.

RouteLLM, un framework open source pour déployer et évaluer des routeurs, décrit une sélection entre modèles plus ou moins puissants entraînée sur des préférences, ainsi que le calibrage d’un seuil. Ce seuil contrôle la fréquence de sélection du modèle le plus performant. Les résultats publiés ne prouvent pas son efficacité sur vos tickets. Documentation de RouteLLM.

La difficulté de maintenance tient à l’évolution des requêtes : de nouveaux types de tâches ou le remplacement de modèles peuvent rendre caduc un seuil jusque-là pertinent. Entraînez ou calibrez le routeur sur des exemples de développement, puis évaluez-le sur des cas distincts qui n’ont jamais servi à le régler.

Un exemple de politique de routage pour une application de support

Confiez au petit modèle les réponses bien délimitées et étayées par les données ; réservez au modèle de pointe les raisonnements encore à résoudre. Les décisions d’autorisation doivent rester dans les règles de l’application. Aucun modèle n’obtient le droit d’effectuer un remboursement au seul motif qu’il sait en expliquer les conditions.

Prenons un commerçant proposant des abonnements, dont l’application récupère la commande du client, la politique applicable et l’historique de conversation avant de rédiger une réponse. Le tableau suivant propose une politique de routage. Il ne prétend pas qu’un petit modèle donné satisfait déjà ces exigences.

Le parcours confié au petit modèle doit s’abstenir de répondre lorsque les éléments requis manquent. Votre application peut détecter des champs de commande absents, une structure de sortie invalide ou une action demandée qui sort du workflow autorisé. Une contradiction factuelle peut nécessiter un vérificateur distinct ou une intervention humaine. Une réponse dont la syntaxe est valide peut tout de même être fausse.

Utilisez le modèle de pointe pour les cas difficiles, et ne lui transmettez une tentative ratée du petit modèle que si l’échec est détectable. Des données manquantes exigent une récupération d’informations ou une clarification ; soumettre le même dossier incomplet à un plus gros modèle ne comble pas les lacunes.

Comptez aussi les appels après escalade

Supposons qu’un lot illustratif contienne 1,000 requêtes. Votre politique en envoie 700 au petit modèle et 300 directement au modèle de pointe. Parmi les appels initiaux au petit modèle, 70 échouent à un contrôle et sont relancés sur le modèle de pointe.

Vous payez donc 700 appels au petit modèle et 370 appels au modèle de pointe, auxquels s’ajoutent le routage et la validation. Cela représente 1,070 appels aux modèles chargés de répondre, et non 1,000. Une nouvelle tentative reste du travail supplémentaire, même si l’utilisateur ne voit que la réponse finale.

Notons r le coût moyen du routage par requête initiale, s le coût moyen d’un appel au petit modèle, f le coût moyen d’un appel au modèle de pointe et g les frais supplémentaires de passerelle ou de validation pour le lot. Dans cet exemple simplifié, nous supposons que le coût moyen du modèle de pointe est identique pour le scénario de référence, les appels directs et les escalades :

Coût avec routage = 1,000r + 700s + 370f + g

Coût de référence, tout sur le modèle de pointe = 1,000f

Le routage ne coûte moins cher que si 700(f − s) > 70f + 1,000r + g. À gauche figurent les coûts de réponse initiaux évités grâce au petit modèle ; à droite, les nouvelles tentatives sur le modèle de pointe et les frais supplémentaires.

Calculez le coût des appels avec les modèles et les tarifs que vous retenez : coût d’un appel = (tokens d’entrée hors cache × tarif d’entrée + tokens d’entrée en cache × tarif du cache + tokens de sortie facturés × tarif de sortie) / 1,000,000, lorsque les tarifs sont exprimés par million de tokens ; ajoutez les outils et les frais de requête facturés séparément.

En production, remplacez ces moyennes simplifiées par la consommation réelle, ventilée par tâche et par parcours. Les tickets difficiles peuvent produire des réponses plus longues, les nouvelles tentatives embarquer davantage de contexte, et un changement de modèle modifier la réutilisation du cache. Incluez les tokens du classificateur de routage et les tokens de raisonnement facturés, le cas échéant, sans compter deux fois les mêmes frais. Comparez les deux systèmes avec la même politique de nouvelle tentative.

Le résultat recherché est un coût par résolution acceptée plus faible, sans abaisser le niveau minimal de qualité. Une facture réduite accompagnée de davantage de promesses de remboursement sans fondement ne remplit pas cet objectif.

Ce que font les solutions de routage documentées

Examinez le mécanisme de sélection avant d’adopter un endpoint de routage. Ces produits prennent des décisions différentes ; le mot « router » ne rend pas leurs comportements par défaut équivalents.

OpenRouter : un Auto Router qui tient compte de la tâche

OpenRouter, une passerelle gérée donnant accès à plusieurs fournisseurs de modèles, expose Auto Router via openrouter/auto. Sa documentation actuelle décrit une classification de la tâche, puis un classement des modèles selon les dépenses de la communauté pour cette tâche sur une fenêtre glissante de 7 jours, suivi d’un filtrage par tranche de coût et par admissibilité. Il s’agit d’un signal d’usage agrégé, pas de votre grille de qualité du support. Documentation d’Auto Router.

Les options de cost_tier sont low, medium, high, xhigh et max ; le comportement par défaut correspond à peu près à low. Un niveau définit une tranche de coût, pas un plafond strict de dépenses. Restreignez les candidats avec allowed_models et excluded_models, puis consignez le champ model de la réponse. Le mécanisme de persistance au sein d’une conversation peut conserver le modèle sélectionné, sans garantir qu’il restera le même.

Avec une clé API définie dans votre environnement, cette commande envoie une requête minimale de routage :

curl --fail-with-body https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/auto",
    "messages": [{"role": "user", "content": "Rewrite this status politely: Your parcel is in transit."}],
    "plugins": [{"id": "auto-router", "cost_tier": "low"}]
  }'

Limitez l’ensemble des candidats pour votre évaluation. Sinon, l’évolution du groupe de modèles rend les résultats de qualité de la veille plus difficiles à interpréter.

LiteLLM : distinguer le routage des déploiements d’Auto Router

LiteLLM, une passerelle LLM configurable, décrit plusieurs stratégies de routage des déploiements : sélection pondérée, choix du déploiement le moins occupé, routage selon la latence ou selon le coût. Sa stratégie par défaut, simple-shuffle, ne classe pas les tickets de support par difficulté. Documentation du routeur.

Son Auto Router, distinct, propose des classificateurs fondés sur des heuristiques, un LLM, des règles de mots-clés ou des plugins personnalisés. Les niveaux SIMPLE, MEDIUM, COMPLEX et REASONING correspondent à des modèles ou à des groupes configurés. Dans le tableau de bord, le parcours documenté est Models + Endpoints → Add Model → Auto Router, puis la configuration et Test Routing. Documentation d’Auto Router.

Cette solution convient aux équipes qui veulent contrôler les modèles candidats et le comportement de classification. La contrepartie est la responsabilité de l’exploitation : associer des modèles à des niveaux ne prouve pas qu’ils respectent vos critères d’acceptation. Le comparatif LiteLLM et OpenRouter détaille ce choix d’infrastructure.

Vercel AI Gateway : choix du fournisseur et contrôles explicites du routage

Vercel AI Gateway, une couche d’accès gérée aux API de modèles, choisit les fournisseurs par défaut en fonction de leur disponibilité et de leur latence récentes. Ses options permettent d’ordonner et de filtrer les fournisseurs ; les modèles de repli indiqués sous forme de chaînes de caractères sont essayés lorsque le modèle principal échoue ou n’est pas disponible. Ce sont des mécanismes utiles pour la fiabilité. À eux seuls, ils ne déterminent pas si un ticket de support nécessite un modèle de pointe. Documentation du routage des fournisseurs et du repli.

Les règles de routage de Gateway permettent aussi de remplacer le modèle demandé par un autre ou d’en refuser l’utilisation. Cette substitution peut centraliser une migration de trafic, mais remplacer un modèle pour toutes les requêtes qui le visent n’équivaut pas à classer la difficulté de chaque requête. Documentation des règles de routage.

Utilisez ces contrôles sous une politique de sélection définie dans l’application lorsque vous avez besoin d’un comportement explicite. Le piège serait de supposer que le choix automatique du fournisseur inclut une sélection automatique selon la qualité requise par la tâche. Pour comparer plus largement les couches d’accès, consultez le guide des passerelles IA pour les applications multimodèles.

Microsoft Foundry : un routeur entraîné et géré par le fournisseur

Le model router de Microsoft Foundry est un sélecteur de modèles entraîné, accessible sous forme de déploiement. Microsoft décrit une sélection fondée sur la complexité, le raisonnement, le type de tâche et d’autres attributs. Il propose les modes Balanced, Quality et Cost, ainsi que des sous-ensembles de modèles. Présentation du model router.

Cette option convient à une application qui utilise déjà Foundry et souhaite une sélection gérée parmi les modèles admissibles. La principale limite est l’ensemble des candidats : la région et les droits d’accès influent sur leur disponibilité. La documentation de Microsoft avertit aussi que la plus petite fenêtre de contexte des modèles sous-jacents limite ce que le routeur peut accepter de manière fiable. Restreignez le sous-ensemble aux modèles qui répondent à vos besoins d’entrée.

Un mode nommé Quality ne remplace pas une évaluation des tâches. Testez le sous-ensemble choisi avec vos longueurs de conversation réelles, vos outils et vos critères d’acceptation.

Comment choisir son routeur de modèles IA ?

Conservez les règles applicatives lorsque vous savez identifier les tâches simples de manière fiable. Envisagez le routage automatique géré lorsque la diversité des tâches fragilise ces règles. Entraîner un sélecteur devient pertinent lorsque vous disposez d’assez de résultats représentatifs et annotés pour justifier sa maintenance.

Pour explorer les solutions d’infrastructure au-delà de ces mécanismes, poursuivez avec le guide des alternatives à OpenRouter. La première décision reste votre politique de routage et les éléments qui la justifient, avant l’allongement de la liste des fournisseurs.

Comment évaluer un routeur sur un jeu de test ?

Mesurez les réponses produites par le routage, pas la concordance avec des étiquettes comme « facile » et « difficile ». Un sélecteur peut classer correctement vos catégories de tâches tout en envoyant les mauvais cas au petit modèle.

Un jeu d’évaluation réunit des requêtes, leur contexte et des critères d’acceptation pour permettre des tests reproductibles. Pour l’application de support, chaque cas doit inclure la conversation, un instantané des données de commande, la politique applicable, les faits attendus, les affirmations ou actions interdites et le comportement d’escalade requis.

Le tableau de suivi doit rendre visibles les erreurs coûteuses :

Si aucun cas ne correspond au dénominateur d’une mesure, indiquez qu’elle est indéfinie, et non nulle. Estimez le taux de routage préjudiciable vers le petit modèle à partir des sorties des modèles évaluées indépendamment, et signalez aussi les erreurs finales après une éventuelle escalade. Identifiez séparément les cas où les deux modèles échouent : un sélecteur ne peut pas produire une réponse acceptable à partir de ces candidats.

Fixez avant le test l’écart de qualité acceptable pour les erreurs non critiques, puis examinez chaque nouvelle régression critique. Utilisez des intervalles de confiance adaptés à l’échantillon apparié ; si l’incertitude couvre encore une dégradation inacceptable, recueillez davantage d’éléments avant de conclure à l’équivalence.

Enfin, faites fonctionner le routeur en parallèle sur un échantillon limité du trafic réel, tandis que le modèle actuel continue de répondre aux clients. Ces appels en parallèle génèrent des dépenses supplémentaires. Après examen des résultats, procédez à un déploiement limité, avec la possibilité de revenir immédiatement à la politique de modèles existante. Poursuivez le suivi par type de requête et relancez l’évaluation lorsque les prompts, les outils, les modèles ou le comportement de routage changent.

Quelles promesses du routage de modèles faut-il relativiser ?

« La même qualité pour moins cher » est un constat propre à une charge de travail, pas une propriété du routeur. Tout dépend des requêtes reçues, des candidats disponibles et de ce que vous jugez acceptable. Aucun pourcentage d’économies obtenu sur la charge de travail d’un autre ne remplace vos propres mesures.

Une réponse API réussie renseigne elle aussi très peu sur la qualité du contenu. Le repli sur erreur peut pallier l’indisponibilité d’un endpoint ; il ne détecte pas une politique inventée dans une réponse fluide. L’escalade pour des raisons de qualité nécessite un contrôle distinct, avec son propre taux d’erreur et son propre coût.

Les scores de difficulté méritent le même examen. La confiance d’un classificateur ne représente pas automatiquement la probabilité que le modèle choisi réponde correctement. Calibrez chaque seuil sur les résultats observés des tâches. Ne laissez pas un texte utilisateur tel que « c’est facile » passer outre les autorisations de l’application ou les restrictions sur les candidats.

Enfin, la sélection automatique peut évoluer même si le code de votre application ne change pas. Les candidats d’OpenRouter, déterminés à partir des dépenses, évoluent ; la version actuelle du model router de Microsoft peut recevoir de nouveaux modèles sous-jacents. Ces comportements documentés font de la journalisation des candidats et de l’actualisation des évaluations une partie intégrante de l’exploitation du routeur.

Qui devrait se lancer, qui devrait attendre et par où commencer ?

Les équipes de développement peuvent se lancer lorsqu’elles savent isoler des tâches récurrentes avec un critère de réussite clair. Ajoutez un parcours vers le petit modèle pour les réponses de statut étayées par les données, gardez un parcours prudent pour les cas incertains et versionnez la politique pour pouvoir reproduire les échecs.

Les responsables de l’exploitation doivent exiger des preuves à l’échelle du workflow. Une facture d’inférence plus faible ne suffit pas si les réouvertures de tickets, les vérifications humaines ou les délais de résolution augmentent. Suivez ces résultats en parallèle de l’évaluation hors ligne.

Les acheteurs doivent demander un test sur leurs propres cas. Exigez de la visibilité sur les modèles sélectionnés et le comportement de repli. Un benchmark général ne permet pas d’établir qu’un routeur comprend votre politique de remboursement.

Attendez si vous ne pouvez pas définir ce qu’est un résultat correct, restreindre l’ensemble des candidats ou réunir assez de trafic pour rentabiliser le travail d’exploitation. Une application qui utilise déjà un petit modèle validé pour une tâche fixe et bien délimitée peut tirer peu de bénéfices d’un sélecteur supplémentaire.

Dès lundi : exportez un ensemble représentatif de dossiers de support, figez leurs éléments et évaluez votre modèle actuel face à un candidat plus petit. Écrivez une règle de routage ciblée pour le sous-ensemble sur lequel ce dernier réussit. Ne confiez du trafic à un routeur automatique qu’après avoir vérifié qu’il fait mieux que cette règle sur le coût, tout en respectant les mêmes exigences de qualité.

Questions fréquentes sur le routage de modèles

Abonnez-vous à la newsletter pour recevoir des guides pratiques sur la création et l’évaluation d’applications d’IA.