Routage de modèles IA : 74 % moins cher, 6 points en moins

Le routage de modèles répond à la question que tout le monde se pose en ouvrant la facture de ses agents en production : est-ce que chaque appel avait vraiment besoin du gros modèle ? LangChain vient de publier une réponse chiffrée, et elle est nette. Sur une suite de 145 tâches agentiques, 93 % des appels n'avaient pas besoin d'un modèle frontier, et la dépense totale tombe de 74 %.

Le reste de l'article traite l'autre moitié du sujet, celle qu'on oublie systématiquement quand on lit "74 % d'économie" : ce que ça coûte en précision, en latence, et en complexité opérationnelle. Parce que le routage n'est pas gratuit, et le benchmark le montre aussi.

Le contexte

Le routage de modèles consiste à placer un arbitre devant vos appels LLM. Pour chaque requête, cet arbitre, qu'on appelle le juge ou le routeur, décide si elle part vers un petit modèle rapide et bon marché, ou vers un modèle frontier lent et cher. L'idée est ancienne dans l'infrastructure : c'est du load balancing avec un critère de difficulté au lieu d'un critère de charge.

Ce qui a changé, c'est l'économie des agents. Un chatbot fait un appel par message d'utilisateur. Un agent, lui, enchaîne : il lit, il planifie, il appelle un outil, il relit le résultat, il corrige. Dans le benchmark que nous détaillons plus bas, la moyenne est de 6,3 appels de modèle par tâche. Votre facture ne suit plus le nombre d'utilisateurs, elle suit le nombre d'étapes de raisonnement. C'est exactement le régime où le routage devient intéressant, parce que sur ces 6,3 appels, la plupart sont triviaux : reformuler, extraire un champ, décider quel outil appeler ensuite.

Le pari du routage, c'est que la difficulté est très inégalement répartie dans une trajectoire d'agent. Le benchmark permet enfin de mettre un chiffre sur cette intuition.

Ce que mesure le benchmark de routage Switchyard

L'étude, publiée le 11 août 2026 par Srimanth Tangedipalli et Karan Singh, évalue NVIDIA NeMo Switchyard, une bibliothèque open source de routage de modèles. Le protocole s'appuie sur la suite d'évaluation Deep Agents : 145 tâches agentiques multi-étapes, avec ces 6,3 appels de modèle en moyenne, réparties sur trois domaines réalistes, le support client, l'investigation d'incidents et l'automatisation multi-étapes.

Trois configurations sont comparées. Le modèle frontier seul, Claude Opus 4.8. Le petit modèle seul, NVIDIA Nemotron 3.5 Lightning. Et la configuration routée, où un juge, Gemini 3.1 Flash Lite, arbitre chaque appel entre les deux.

Trois configurations, trois factures

La ligne du milieu est celle qui compte. Elle est décrite ainsi dans l'article : le routage est "74 % moins cher et 6 points moins précis". Ce sont les deux nombres à retenir, et ils vont ensemble. Toute présentation du routage qui cite le premier sans le second vous vend quelque chose.

Notez aussi la troisième ligne. Le petit modèle seul n'est pas ridicule : 77,7 % contre 86,0 % pour le frontier. L'écart entre "tout petit" et "tout gros" n'est que de 8,3 points. Le routage récupère un peu plus des deux tiers de cet écart pour environ quatre fois le prix du petit modèle. C'est ce compromis que vous achetez, pas un repas gratuit.

93 % des appels pour 10 % de la dépense

Le chiffre le plus utile de l'étude n'est pas le coût total, c'est la répartition. Nemotron a traité 93 % des appels de modèle pour 10,4 % de la dépense, pendant qu'Opus traitait 7 % des appels pour 68,4 % de cette même dépense.

Lisez cette phrase deux fois si vous exploitez des agents. Elle dit que dans une trajectoire d'agent typique, l'écrasante majorité des appels sont mécaniques, et qu'une poignée d'appels décisifs consomment les deux tiers du budget. Elle dit aussi que si vous facturez aujourd'hui la totalité de vos appels au tarif frontier, vous payez le prix fort pour du travail que n'importe quel modèle de 2024 aurait fait correctement.

Le juge n'est pas gratuit

Reste 21,2 % de la dépense routée. C'est la part du juge, et c'est le poste que la plupart des équipes oublient de modéliser. Un routeur, c'est un troisième modèle en production. Il consomme des tokens sur chaque appel, y compris ceux qu'il finit par envoyer au petit modèle.

L'article donne la formule de rentabilité, et elle est assez simple pour tenir dans un tableur : coût du juge / (coût du modèle cher - coût du modèle pas cher). Pour l'appariement testé, il fallait délester 5,9 % des tours pour que le juge se rembourse. Le système en a délesté 93 %, soit seize fois la barre. La marge est confortable ici, mais elle ne l'est pas par construction : rapprochez le petit modèle du gros en prix, et le dénominateur s'effondre. Le routage entre deux modèles de coûts voisins ne rembourse jamais son juge.

Le juge coûte aussi du temps. L'article chiffre son surcoût de latence à environ 700 ms par appel. Sur une tâche à 6,3 appels, cela fait plus de quatre secondes ajoutées à la trajectoire complète, dans le meilleur des cas et hors parallélisation. Pour une automatisation en arrière-plan, c'est invisible. Pour un agent qui répond à un humain qui attend, c'est un changement de catégorie d'expérience.

La variance, angle mort du routage

Un détail du benchmark mérite plus d'attention qu'il n'en reçoit d'habitude. Sur cinq exécutions, la part du trafic envoyée au modèle frontier a varié de 4,1 % à 9,1 %, pour une moyenne de 6,9 %. Le coût a suivi : la pire exécution routée est ressortie à 3,61 $, soit environ un tiers du coût d'Opus seul.

Cette dispersion est la conséquence directe du design. Le juge est lui-même un modèle probabiliste, et la difficulté d'une trajectoire dépend de ce que les outils renvoient en cours de route. Vous n'achetez donc pas un coût, vous achetez une distribution de coûts.

En pratique, cela veut dire que le budget d'un système routé se prévoit comme une fourchette, pas comme un nombre. Si votre modèle financier repose sur la moyenne observée en pilote, une semaine de trafic difficile vous fera dépasser sans qu'aucune alerte technique ne se déclenche. Le bon réflexe est d'instrumenter la part de trafic frontier comme une métrique de production à part entière, avec un seuil, au même titre qu'un taux d'erreur.

Quand le routage ne vaut pas le coup

L'article est explicite sur son domaine de validité, et c'est appréciable. Le routage vise les équipes qui ont besoin de la capacité frontier sur les requêtes difficiles et qui ne peuvent pas savoir à l'avance lesquelles le sont. C'est la condition centrale. Si vous pouvez classer vos requêtes en amont avec une règle métier fiable, écrivez la règle : elle sera plus rapide, gratuite et déterministe.

Deux cas sont à écarter. Les charges sensibles à la latence, à cause des 700 ms du juge. Et les charges courtes, où le nombre d'appels est trop faible pour amortir la complexité ajoutée : sur une tâche à un ou deux appels, vous ajoutez une dépendance et un mode de panne pour économiser quelques centimes.

Ce que ça change pour les équipes IA

Les 74 % font le titre. Voici ce qui compte réellement quand on doit exploiter le système.

Les 6 points de précision sont une décision produit, pas une décision technique. Passer de 86 % à 80 % de réussite sur des tâches agentiques, cela signifie qu'une tâche sur cinq échoue au lieu d'une sur sept. Selon ce que fait l'agent, c'est indolore ou inacceptable. Ce seuil se fixe avec les personnes qui répondent aux clients, avant de toucher à l'infrastructure. Un arbitrage coût / qualité décidé en solo par l'équipe plateforme finit toujours par remonter en escalade.

Il faut instrumenter avant de router. La formule de rentabilité exige de connaître le coût par appel de vos trois modèles et la proportion d'appels délestés. Si votre observabilité s'arrête à un total mensuel par clé d'API, vous ne pouvez même pas calculer si le routage vous rapporte quelque chose. La télémétrie par appel, avec le modèle utilisé, le coût, la latence et l'issue, est un prérequis, pas une amélioration.

Le juge est une dépendance de production à part entière. Il se versionne, il se surveille, il se restaure. Et il crée une nouvelle surface d'incident : une dégradation de qualité peut venir du juge qui route mal, sans qu'aucun des deux modèles de travail n'ait changé. Le jour où votre précision baisse, la première question devient "qu'est-ce qui a bougé dans la répartition du routage", et vous devez pouvoir y répondre en lisant un graphique, pas en relisant des logs.

Le pattern rejoint un mouvement plus large. LangChain pousse en parallèle l'idée d'agents managés, où le runtime, l'état, les sandboxes et l'observabilité sont fournis ensemble plutôt qu'assemblés à la main. Le routage relève de la même logique : ce sont des problèmes d'exploitation, pas des problèmes de modèle. La même équipe documente d'ailleurs un agent SRE autonome pour des déploiements Kubernetes, autre signe que le sujet agentique bascule du prototype vers la salle des machines.

Commencez par mesurer votre propre distribution. Avant d'installer quoi que ce soit, échantillonnez une centaine de trajectoires réelles et demandez-vous, appel par appel, si un petit modèle aurait suffi. Si votre réponse est "oui" sur 90 % des appels, le routage vous concerne. Si elle est "oui" sur 40 %, votre problème n'est pas le routage, c'est la conception de vos prompts et de vos outils.

En bref

• Sur 145 tâches agentiques, le routage entre Nemotron 3.5 Lightning et Claude Opus 4.8 coûte 74 % moins cher et perd 6 points de précision, à 80,0 % contre 86,0 %.
• Le petit modèle absorbe 93 % des appels pour 10,4 % de la dépense ; le frontier prend 7 % des appels pour 68,4 %.
• Le juge consomme 21,2 % de la dépense routée et ajoute environ 700 ms par appel : il faut délester au moins 5,9 % des tours pour qu'il se rembourse.
• La part de trafic frontier a varié de 4,1 % à 9,1 % sur cinq exécutions : budgétez une fourchette, et surveillez ce ratio comme une métrique de production.
• À écarter si votre charge est sensible à la latence, si elle est courte, ou si une règle métier simple sait déjà trier vos requêtes.

Vous industrialisez vos agents IA ? SeedVision propose des audits IA en 3-5 jours et des forfaits de mise en production de 15 à 30 jours. Voir les packages ou réserver un appel de 30 min.

Photo de couverture : Photo by Johannes Plenio on Unsplash.