Pourquoi le routage de modèles est un problème de systèmes, pas de classification

Le routage de modèles est une de ces idées qui semblent propres sur un tableau blanc. Aiguiller les requêtes simples vers des modèles moins chers et plus rapides. Réserver les modèles lourds pour les tâches complexes. Mais le sol du centre de données n'est pas un tableau blanc. En production, le routage devient un numéro d'équilibriste permanent, et les variables qui dominent le coût et la latence ne sont presque jamais celles que les ingénieurs listent dans un tableau comparatif.

Cet article parcourt trois dimensions qui ont rendu le routage étonnamment difficile pour nous, en s'appuyant sur 417 tâches du AppWorld Test Challenge avec un agent CodeAct. Chaque chiffre provient d'un déploiement réel, pas d'une simulation.

Le coût ne se limite pas à la tarification du modèle

L'hypothèse de départ était simple : GPT-4.1 devrait être moins cher que Claude Sonnet 4.6. La tarification par token de GPT-4.1 est inférieure à la fois pour l'entrée et la sortie, et Sonnet prend environ trois fois plus d'étapes de raisonnement pour accomplir les mêmes tâches agentiques. Rien qu'au prix catalogue, GPT-4.1 gagne.

Les chiffres réels ont raconté une histoire différente. Sur 417 tâches avec le même agent, Sonnet a coûté 79 $ au total (0,19 $ par tâche) tandis que GPT-4.1 a coûté 155 $ au total (0,37 $ par tâche), soit presque le double.

L'explication est la mise en cache, un facteur que la plupart des architectures de routage ignorent complètement. Les charges de travail des agents réutilisent de larges blocs de contexte entre étapes consécutives. Lorsque les taux de succès du cache sont élevés, les coûts d'entrée effectifs chutent considérablement. La tarification de lecture du cache plus basse de Sonnet a fait que ce modèle a bénéficié de manière disproportionnée de ce schéma, suffisamment pour surmonter à la fois sa tarification de base plus élevée et ses trajectoires plus longues. Un routeur qui ne regarde que la fiche tarifaire optimise par rapport aux mauvais chiffres.

La complexité ne se limite pas à la difficulté de la tâche

Une stratégie de routage courante consiste à mesurer la difficulté de la tâche et à envoyer le travail plus difficile à des modèles plus puissants. Intuitif, mais cela échoue de deux manières en production.

Premièrement, la difficulté est souvent invisible au moment du routage. Une requête comme "résume ce contrat" semble simple, mais elle peut déclencher une récupération, des vérifications de conformité, une utilisation d'outils et plusieurs rounds d'affinage avant d'être terminée. Pendant ce temps, une invite très technique peut être traitée efficacement par un modèle spécialisé plus petit. On ne sait souvent pas à quel point une tâche est difficile jusqu'à ce que l'exécution révèle sa structure interne.

Deuxièmement, même si l'on pouvait estimer parfaitement la difficulté, ce n'est qu'un signal parmi de nombreux autres. Les routeurs d'entreprise doivent équilibrer simultanément le coût, la latence, la spécialisation du modèle et la fiabilité. Les contraintes réglementaires s'ajoutent : règles de résidence des données, listes de modèles approuvés, exigences de conformité. Une tâche qui irait idéalement à un modèle pourrait devoir aller ailleurs en raison de la gouvernance, et le routeur doit gérer cela avec élégance plutôt que d'échouer.

Les routeurs ne résolvent pas un seul problème. Ils jonglent constamment avec le coût, la qualité, la latence, la conformité et la fiabilité, le tout en même temps.

La latence ne se limite pas à la vitesse du modèle

Il est de notoriété publique de penser à la latence uniquement en termes de taille du modèle : les grands modèles sont plus lents, les plus petits plus rapides. Mais ce que l'utilisateur expérimente dépend de bien plus que cela.

Le routage lui-même ajoute une surcharge. Les facteurs d'infrastructure, sur quel matériel un modèle fonctionne-t-il, si le cache est chaud, à quel point le point de terminaison est occupé, dominent souvent les temps de réponse de bout en bout. Un modèle théoriquement plus rapide peut encore produire une expérience utilisateur plus lente si les conditions de service ne sont pas alignées.

Ensuite, il y a la granularité du routage. Router une fois par tâche ajoute une surcharge minimale. Mais router à chaque étape, ce qui offre plus de flexibilité pour s'adapter en cours d'exécution, signifie que chaque point de décision supplémentaire introduit une latence et une complexité opérationnelle. Un routeur qui ignore le système de service combat le mauvais combat.

Une approche basée sur l'optimisation

Ces leçons ont conduit à un changement fondamental : nous avons cessé de traiter le routage comme un problème de classification et avons commencé à le traiter comme un problème d'optimisation. Au lieu de se demander "quel modèle est le meilleur pour cette tâche ?", l'algorithme optimise simultanément le coût, la qualité et la latence, tout en restant suffisamment léger pour ne pas devenir lui-même un goulot d'étranglement.

Sur le AppWorld Test Challenge, un routeur basé sur l'optimisation a tracé une frontière nette entre coût et précision. La configuration 1 (optimisée pour la latence) a atteint une précision de 84 % pour 93 $ et 83 secondes. Cela représente une réduction de coût de 21 % et une réduction de latence de 9 % par rapport à l'exécution d'Opus seul, avec seulement une baisse de précision de 4 %. Un routeur standard basé sur la difficulté s'est situé dans une plage de précision similaire mais à un coût plus élevé ; il n'a pas exploré tout l'espace des compromis. L'optimisation elle-même s'exécute en environ 6 millisecondes et 2 kilo-octets de mémoire par tâche.

Le point clé à retenir : le routage ne consiste pas à choisir des modèles. Il s'agit d'optimiser des systèmes. Les modèles sont une variable, importante, mais une seule parmi le comportement de mise en cache, l'état de l'infrastructure, les contraintes de conformité et les schémas de charge de travail.

Si vous construisez le routage dans vos propres systèmes agentiques, l'auteur se réjouit d'entendre parler des compromis que vous rencontrez.