Publié le 18 septembre 2026 à 11:00 · Publication originale
Certaines exigent seulement de reconnaître une langue.
D'autres doivent résumer un message.
Quelques centaines nécessitent d'analyser un contrat, rechercher dans plusieurs documents ou construire une réponse complexe.
Envoyer les 30.000 demandes au modèle le plus puissant fonctionne.
Mais cela revient à utiliser un chirurgien pour prendre la température.
Les architectures commencent donc à introduire un composant supplémentaire: le routeur de modèles.
Avant qu'une requête soit traitée, ce système estime sa difficulté, son domaine, son niveau de risque ou le temps disponible. Il choisit ensuite le modèle adapté.
Un petit modèle rapide peut classifier une demande. Un modèle spécialisé peut traiter du code. Un modèle plus puissant reçoit les raisonnements complexes. Un modèle local peut être réservé aux données qui ne doivent pas quitter l'entreprise.
Deux modèles capables de répondre à la même question peuvent avoir des coûts et des temps de calcul très différents.
Le choix peut même évoluer pendant une tâche.
Une première étape classe le document. Une seconde extrait les informations. Une troisième n'appelle un modèle coûteux que lorsqu'une ambiguïté apparaît.
L'entreprise ne choisit alors plus "son IA".
Elle construit un portefeuille de capacités.
Cette architecture réduit également une dépendance souvent invisible. Si toutes les applications reposent sur les particularités d'un fournisseur, le remplacer peut imposer de modifier une grande partie du système.
Une couche d'orchestration permet au contraire de déplacer certaines tâches vers un autre modèle.
Le modèle devient interchangeable pour certaines fonctions, spécialisé pour d'autres.
La première décision n'est donc pas d'en connecter cinq.
Elle consiste à constituer un corpus de requêtes réelles permettant de découvrir lequel réussit quoi, à quel coût et dans quel délai.
ULTRA®
Un routeur multi-modèles peut être traité comme un problème de "bandit contextuel".
À chaque requête, domaine, longueur, langue, sensibilité et latence constituent le contexte. Les modèles sont les actions possibles. La récompense combine qualité, coût et temps de réponse.
Mais après avoir choisi A, le système ignore généralement ce qu'auraient répondu B, C ou D: c'est le problème du retour partiel. Une exploration contrôlée reste nécessaire pour éviter qu'un modèle historiquement performant capture progressivement tout le trafic.
RouteLLM, projet open source issu de LMSYS, permet d'expérimenter cette logique avec plusieurs stratégies de routage. LiteLLM peut fournir une interface commune aux modèles et vLLM servir localement des modèles ouverts.
Conseil: commencer avec deux modèles et 500 à 1.000 requêtes réelles évaluées sur les deux.
Après quelques milliers de comparaisons, l'entreprise possède quelque chose qu'aucun benchmark public ne peut lui fournir: la géographie de ses propres problèmes.