Routage de modèles IA : promesse simple, pièges réels
Un client demande : « comment réduire ma facture d'API sans changer de fournisseur ? » La réponse qui revient systématiquement est le routage de modèles. L'idée séduit tout le monde en dix minutes de réunion. Sa mise en œuvre prend ensuite plusieurs semaines, et les résultats ne ressemblent pas toujours à la promesse initiale.
Le routage de modèles, en une phrase
Le routage de modèles (model routing) consiste à envoyer chaque requête vers le modèle le plus adapté à sa complexité, plutôt que d'utiliser systématiquement le modèle le plus puissant et le plus cher disponible.
Ce que promet un routeur : bon modèle, bonne requête, moindre coût
Une question de type « résume ce texte en trois lignes » ne justifie pas d'appeler un modèle premium à 15 dollars le million de tokens en sortie. Un modèle plus léger, moins cher, fait le travail correctement. Le routeur a pour rôle de trier ces requêtes et de diriger chacune vers le modèle qui coûte le moins cher tout en répondant au niveau de qualité attendu.
Les deux grandes familles : routage par règles et routage appris
Le routage par règles s'appuie sur des heuristiques explicites : longueur du prompt, présence de mots-clés, type de tâche déclaré par l'application appelante. Simple à auditer, mais rigide face à des cas nouveaux.
Le routage appris utilise un modèle de classification, parfois un petit LLM lui-même, entraîné à prédire la complexité d'une requête et à choisir le modèle cible. Amazon Bedrock Intelligent Prompt Routing fonctionne sur ce principe : il route dynamiquement entre modèles d'une même famille selon la complexité prédite, au 1er juillet 2025 selon la documentation AWS.
Pourquoi ça paraît simple au départ
Le cas d'école : petit modèle par défaut, gros modèle en secours
L'architecture la plus citée en démonstration : un modèle petit et rapide traite 80 % du trafic, un modèle plus grand prend le relais pour les 20 % restants jugés complexes. Sur le papier, le calcul est imparable. En pratique, la difficulté ne réside jamais dans l'architecture cible, mais dans la définition fiable de ce seuil des 20 %.
Les gains annoncés sur la facture de tokens
OpenRouter met en avant son routage automatique comme un moyen de sélectionner le modèle le plus pertinent parmi son catalogue en fonction du prompt, avec des règles de repli configurables en cas d'indisponibilité d'un fournisseur, selon sa documentation mise à jour le 1er août 2025. Le raisonnement économique tient : moins de tokens facturés au tarif premium, facture globale en baisse. Ce raisonnement suppose toutefois que la classification elle-même ne coûte rien et ne se trompe jamais. Aucune des deux hypothèses ne tient dans un système en production.
Là où ça se complique
Le coût caché de la classification avant routage
Classifier une requête avant de la router demande soit un appel supplémentaire à un modèle, soit un système de règles à maintenir. Un appel de classification ajoute de la latence et, si le classifieur est lui-même un LLM, un coût. IBM Research pointe explicitement ce problème dans son billet du 15 juillet 2025 : la classification en amont introduit sa propre marge d'erreur, et cette marge se répercute directement sur la qualité perçue en sortie.
La dérive de qualité difficile à mesurer
Le vrai piège n'est pas technique, il est organisationnel : personne ne mesure la qualité des réponses routées vers le modèle léger, faute d'avoir défini au préalable ce qu'est une réponse acceptable. Sans grille d'évaluation, une équipe découvre la dérive de qualité via des retours clients trois mois plus tard, jamais via un tableau de bord.
Latence ajoutée et points de défaillance supplémentaires
Chaque étape de routage est un point de défaillance de plus : classifieur indisponible, timeout sur le modèle cible, incohérence entre le format attendu par l'application et celui renvoyé par un modèle de secours différent du modèle principal. Un système à un seul modèle a une seule surface de panne. Un système routé en a au minimum trois : le classifieur, le routeur, et chacun des modèles cibles.
Maintenance : chaque nouveau modèle casse la logique
Un nouveau modèle sort, moins cher ou plus performant sur une tâche donnée. L'intégrer dans un routeur par règles suppose de réévaluer tous les seuils existants, pas seulement d'ajouter une ligne. Un routeur appris nécessite un réentraînement ou un recalibrage. Cette dette de maintenance est rarement budgétée au moment de la décision initiale.
Bonnes pratiques observées
Mesurer avant de router : établir une baseline coût/qualité
Avant d'introduire un routeur, il faut connaître le coût et la qualité actuels avec un seul modèle sur un échantillon représentatif de requêtes réelles. Sans cette baseline, impossible de savoir si le routage améliore vraiment quelque chose ou déplace simplement le problème.
Router sur des tâches segmentées, pas sur une intuition
Le routage fonctionne mieux quand il s'appuie sur des catégories de tâches identifiées à l'avance — résumé court, extraction de données structurées, génération de code, réponse conversationnelle longue — plutôt que sur une estimation continue de « complexité » difficile à calibrer. La documentation Bedrock recommande d'ailleurs de définir les profils de modèles cibles par type de tâche avant d'activer le routage automatique.
Prévoir un fallback et l'observabilité dès le départ
Un mécanisme de repli (fallback) vers le modèle par défaut, en cas d'échec du classifieur ou d'indisponibilité d'un fournisseur, doit exister avant la mise en production, pas être ajouté après un incident. OpenRouter documente ce mécanisme comme une règle configurable, pas comme une option accessoire.
Journaliser systématiquement quel modèle a traité chaque requête et pourquoi
Suivre un échantillon de réponses routées vers le modèle léger avec une revue humaine périodique
Fixer un budget de tokens de classification distinct du budget d'inférence principal
Ce que le routage ne fait pas
Le routage ne corrige pas un mauvais prompt. Un prompt mal conçu produira une réponse médiocre quel que soit le modèle appelé. Il ne remplace pas non plus une politique de cache : deux requêtes identiques ou proches gagnent davantage à être mises en cache qu'à être reroutées à chaque fois.
Il ne réduit pas la charge d'ingénierie à long terme : un système routé demande plus de supervision qu'un système à modèle unique, pas moins. Enfin, il ne garantit aucune économie mécanique. Sans mesure continue, une équipe peut très bien payer pour un classifieur coûteux qui route mal, et voir sa facture globale augmenter plutôt que baisser.
Par où commencer
Mesurer d'abord : constituer un échantillon de 200 à 500 requêtes réelles, faire tourner un seul modèle dessus, noter coût et qualité perçue avant tout projet de routage
Tester le routage sur un seul cas d'usage segmenté et à faible risque, avec un modèle de repli connu, avant de l'étendre à l'ensemble du trafic
Instrumenter dès le premier déploiement : journalisation du modèle utilisé par requête, taux de fallback déclenché, et revue manuelle hebdomadaire d'un échantillon des réponses issues du modèle le moins cher
Sources
Model routing is simple, until it isn't — IBM Research, Hugging Face Blog, 15/07/2025
Model Routing — OpenRouter, OpenRouter, 01/08/2025
Increase application resilience with Amazon Bedrock Intelligent Prompt Routing — Amazon Web Services, AWS Documentation, 01/07/2025
Cet article a été rédigé et illustré par un système d'intelligence artificielle à partir des sources citées ci-dessus, puis publié automatiquement, sans relecture humaine préalable. Si vous relevez une erreur factuelle, merci de nous la signaler.
Commentaires