Utiliser un seul modèle pour chaque appel peut être inutilement coûteux, mais le routage n’est pas automatiquement une amélioration.
Une équipe peut constater que la classification, l’extraction, la rédaction et les raisonnements complexes n’ont pas les mêmes exigences de qualité et de latence. Le routage permet de tirer parti de ces différences. Il ajoute aussi parfois un appel de classification, de nouveaux modes de défaillance liés aux fournisseurs, des comportements de sécurité incohérents et davantage d’évaluations. La seule économie que vous pouvez défendre est celle calculée à partir de votre consommation mesurée de jetons, des tarifs actuels et de vos critères de qualité.
L’orchestration multi-modèles consiste à sélectionner un modèle ou un service spécialisé pour un type d’appel défini, selon des contraintes explicites de qualité, de latence, de confidentialité et de coût.
Cet article présente les schémas d’orchestration, la logique de routage, les compromis et une méthode de mise en œuvre pas à pas.
Pourquoi un seul modèle n’est pas optimal
Les catalogues des fournisseurs évoluent fréquemment, mais une charge de travail peut toujours définir des niveaux fonctionnels :
Catégorie de raisonnement avancé : modèles candidats pour les tâches difficiles de planification ou d’analyse. Évaluez sur vos propres cas la précision, l’utilisation des outils, la latence de queue et le nombre total de jetons de raisonnement générés.
Catégorie généraliste : modèles candidats pour la rédaction destinée aux utilisateurs et les tâches variées où la qualité importe, sans nécessairement exiger un raisonnement prolongé.
Catégorie à faible latence : modèles candidats pour des tâches limitées de classification, d’extraction et de réécriture. Un modèle plus petit ne garantit ni une précision suffisante ni une latence globale plus faible.
Catégorie locale ou petits modèles : candidats lorsque la localisation des données, le fonctionnement hors ligne ou le coût marginal de l’inférence comptent. Intégrez à la comparaison le matériel, l’exploitation, l’énergie, les accès concurrents et les effets de la quantification.
Services spécialisés (plongement vectoriel, reclassement, vision, parole) : comparez-les aux modèles généralistes sur l’opération exacte ; la spécialisation n’est pas une preuve de meilleure qualité ou de coût total inférieur.
Au moment de décider, consultez les pages à jour sur les modèles et leurs tarifs : modèles OpenAI et tarifs, modèles Anthropic et tarifs, ainsi que modèles Google et tarifs. Ne figez ni la disponibilité ni les prix dans une décision d’architecture destinée à durer.
Une application d’IA typique effectue différents types d’appels LLM. Chaque appel a ses propres exigences :
- Classification de l’intention utilisateur : évaluez un candidat à faible latence sur un ensemble étiqueté, y compris les cas ambigus et hors périmètre.
- Extraction de données structurées : mesurez la précision au niveau des champs et la validité du schéma, pas la taille du modèle.
- Génération d’une réponse destinée à l’utilisateur : mesurez l’exactitude factuelle, le respect des règles et la latence de queue.
- Résumé de la conversation précédente : testez l’omission des décisions, noms, contraintes et négations.
- Traitement par lots en arrière-plan : mesurez le débit, le coût des réessais et le respect des délais.
Ne supposez ni que le modèle le moins cher suffit, ni que le plus coûteux est le meilleur. Établissez-le avec le même jeu d’évaluation pour chaque voie.
Calculez les économies à partir de la télémétrie
Pour chaque type d’appel, collectez :
- le nombre mensuel d’appels ;
- la distribution des jetons d’entrée, d’entrée en cache et de sortie ;
- le taux de réessai et de cascade ;
- les frais d’outils, de recherche, par lots ou d’hébergement ;
- les centiles de latence ; et
- le taux de réussite lors de l’évaluation de mise en production de la voie.
Calculez le coût de chaque voie candidate à partir des tarifs actuels :
coût mensuel de la voie = appels × (
jetons_entrée × prix_entrée
+ jetons_cache × prix_cache
+ jetons_sortie × prix_sortie
) + frais_outils + hébergement + coût_réessai_attendu
Comparez le résultat au modèle de référence uniquement pour les candidats qui satisfont aux mêmes critères de qualité et de sécurité. Présentez les hypothèses avec le résultat. Une voie qui réduit le coût des jetons mais augmente les corrections manuelles, les incidents ou la latence peut revenir plus cher au total.
Si vous ne disposez pas de télémétrie, commencez par une évaluation parallèle qui n’influe pas sur les réponses réelles. Ne publiez pas un pourcentage d’économie fondé sur une répartition générique du trafic.
Les schémas d’orchestration de base
Plusieurs schémas se retrouvent dans les systèmes multi-modèles en production :
Schéma 1 : routage par tâche
Différents types de tâches sont acheminés vers différents modèles. C’est le schéma le plus simple.
# Resolve these aliases from reviewed configuration; provider IDs change.
def route_request(task_type):
if task_type == "classification":
return SMALL_TIER
elif task_type == "extraction":
return EXTRACTION_TIER
elif task_type == "summarization":
return SUMMARY_TIER
elif task_type == "user-facing-response":
return RESPONSE_TIER
elif task_type == "complex-reasoning":
return REASONING_TIER
Le code appelant classe lui-même les tâches, puisqu’il sait ce qu’il demande. Le routage reste déterministe et facile à déboguer.
Schéma 2 : routage selon la complexité
Le système estime la complexité de chaque requête et l’achemine en conséquence.
def route_by_complexity(request):
complexity = estimate_complexity(request)
if complexity < 3:
return "small"
elif complexity < 7:
return "mid"
else:
return "flagship"
L’estimation de la complexité peut reposer sur une heuristique (longueur de la requête, détection de mots-clés) ou sur un modèle (un classificateur peu coûteux évalue la requête). Ce schéma convient lorsque des tâches du même type présentent des niveaux de difficulté différents.
Schéma 3 : routage en cascade
Essayez d’abord un modèle peu coûteux. Si sa sortie est bonne, utilisez-la. Sinon, transmettez la requête à un modèle plus coûteux.
def cascade(request):
cheap_response = call_model("small", request)
if is_acceptable(cheap_response):
return cheap_response
return call_model("flagship", request)
Cette méthode fonctionne lorsqu’il est possible de déterminer si le résultat est « acceptable », au moyen de scores de confiance, de validateurs ou d’un LLM distinct chargé du contrôle qualité. La méthode est puissante : la plupart des requêtes simples sont alors traitées par le modèle peu coûteux ; seules les plus difficiles atteignent le modèle coûteux.
Schéma 4 : routage spécialisé
Utilisez des modèles spécialisés pour des tâches spécialisées :
- Plongements vectoriels : utilisez un modèle dédié pour générer les vecteurs (bien moins cher qu’un modèle de dialogue employé à cette fin).
- Reclassement : utilisez un modèle de reclassement dédié.
- Vision : utilisez un modèle spécialisé en vision pour l’analyse d’images.
- Voix : utilisez un modèle vocal pour la transcription/synthèse.
- Code : utilisez un modèle spécialisé en code pour les tâches de codage.
Les modèles spécialisés ou plus petits peuvent être plus rapides, moins chers ou meilleurs sur une tâche précise, mais leur catégorie ne garantit aucun de ces avantages. Évaluez la combinaison exacte du modèle, du fournisseur, du prompt et de la langue, ainsi que le centile de latence, la grille tarifaire et le jeu d’évaluation.
Schéma 5 : routage par fournisseur
Utilisez des modèles de plusieurs fournisseurs pour la redondance et un levier sur les prix.
providers = ["openai", "anthropic", "google"]
preferred = "anthropic" # primary
fallback = "openai" # fallback
def call_with_failover(request):
try:
return call(preferred, request)
except (RateLimit, ProviderError):
return call(fallback, request)
Cette approche améliore la résilience face à la panne d’un fournisseur ou à ses limites de débit. Elle permet aussi de tirer parti des évolutions tarifaires : si un fournisseur baisse ses prix, vous pouvez lui confier davantage de trafic.
Un exemple réaliste : IA de support client
Pour rendre cela concret, voici comment une IA de support client pourrait utiliser l’orchestration multi-modèles.
Le système comporte ces étapes par ticket :
Étape 1 : classifier l’intention. Que demande le client ?
Candidat de routage : un modèle à faible latence qui réussit l’ensemble étiqueté d’intentions.
Étape 2 : déterminer l’urgence et le sentiment. Le client est-il frustré ? S’agit-il d’une urgence ?
Candidat de routage : le même modèle, uniquement si les faux négatifs concernant l’urgence restent sous le seuil de sécurité défini séparément. Le sentiment n’est pas un indicateur fiable de l’urgence.
Étape 3 : récupérer la connaissance pertinente.
Candidat de routage : récupération par plongement vectoriel plus un modèle de reclassement, évalué sur un ensemble de récupération spécifique au ticket.
Étape 4 : déterminer si l’IA peut répondre ou si le cas doit être transmis à une personne.
Candidat de routage : un modèle évalué spécialement sur sa capacité à repérer les cas à transmettre. Des règles doivent imposer le recours à une personne pour l’accès au compte, la sécurité, les questions juridiques ou financières et les autres cas définis par la politique interne.
Étape 5 (si l’IA peut répondre) : générer la réponse destinée au client.
Candidat de routage : un modèle généraliste de meilleure qualité. Conservez la réponse à l’état de brouillon jusqu’à ce que l’exactitude factuelle, le respect des politiques, la confidentialité et le ton satisfassent aux critères de mise en production.
Étape 6 (si l’IA ne peut pas répondre) : générer un résumé pour l’agent humain.
Candidat de routage : un modèle moins coûteux dont les résumés préservent le problème, les preuves, les étapes tentées, les contraintes du client et l’incertitude.
Étape 7 : vérification de la qualité. La réponse a-t-elle atteint nos standards ?
Candidat de routage : des contrôles déterministes complétés par un évaluateur calibré. Un modèle évaluateur ne fournit pas de garantie indépendante ; faites vérifier un échantillon de ses décisions par des personnes.
Instrumentez chaque étape, puis renseignez la formule de coût ci-dessus à partir de la distribution mesurée des jetons, des prix actuels, de la part des demandes transmises, du taux de nouvelle tentative et du coût de la validation humaine. Cet exemple ne donne volontairement aucune estimation générique des économies : la composition des demandes et les seuils d’acceptation déterminent le résultat.
La logique de routage
Quelques approches pour implémenter le routage :
Approche 1 : codée en dur par type de tâche
La plus simple. Vous savez quelle tâche vous appelez, vous choisissez le modèle.
def classify(text):
return openai_client.chat.completions.create(
model=SMALL_TIER, # your provider's current small model
messages=[{"role": "user", "content": f"Classify: {text}"}],
)
def respond(context, query):
return claude_client.messages.create(
model=RESPONSE_TIER, # reviewed config alias, not a frozen provider ID
max_tokens=1024,
messages=[{"role": "user", "content": f"Context: {context}\n\nQuery: {query}"}]
)
Avantages : transparent, facile à déboguer et à modifier. Inconvénients : ne s’adapte pas aux variations de complexité au sein d’un même type de tâche.
Approche 2 : modèle routeur
Un petit modèle classe chaque requête et l’achemine.
ROUTER_PROMPT = """
Classify this request as: trivial, moderate, or complex.
Output one word.
Request: {request}
"""
def route(request):
classification = small_model_call(ROUTER_PROMPT.format(request=request))
return MODEL_BY_COMPLEXITY[classification]
Avantages : s’adapte à la complexité au sein d’une catégorie. Inconvénients : ajoute la latence d’un appel au routeur, crée un point de défaillance supplémentaire et exige un réglage.
Approche 3 : routeur fondé sur les plongements vectoriels
Pour les requêtes correspondant à des schémas connus, utilisez la similarité entre plongements vectoriels et des exemples antérieurs.
def route(request):
embedding = embed(request)
closest = find_nearest_example(embedding)
return closest.suggested_model
Avantages : rapide, puisqu’une recherche vectorielle suffit, et s’améliore avec davantage de données. Inconvénients : exige de constituer un jeu d’exemples étiquetés.
Approche 4 : cascade
Essayez d’abord le modèle le moins cher ; passez à un modèle plus performant si nécessaire.
def cascade(request):
cheap = small_model_call(request)
if validates(cheap):
return cheap
return flagship_call(request)
Avantages : adaptatif, avec un coût moyen faible. Inconvénients : lent pour les cas transmis au second modèle, puisqu’ils nécessitent deux appels, et dépend d’une validation fiable.
En pratique, de nombreux systèmes de production utilisent un hybride : routage codé en dur pour les types de tâches principaux, avec des cascades pour des sous-types spécifiques à haute variance.
Les pièges
Quelques erreurs à éviter :
Piège 1 : optimiser le coût au détriment de la qualité
Il est facile d’acheminer tout vers des petits modèles et de voir les coûts baisser. Il est plus difficile de remarquer que la qualité a également baissé. Associez toujours les changements de routage à une surveillance de la qualité.
Une bonne pratique consiste à tester en parallèle, ou par test A/B, une voie moins coûteuse jusqu’à ce que l’échantillon couvre les principales catégories d’entrées et les modes de défaillance. Une durée fixe d’une semaine ne constitue pas une preuve. Ne déployez la modification que si les critères de qualité et de sécurité définis à l’avance restent satisfaits.
Piège 2 : trop complexifier le routeur
Un routeur avec de nombreux types de tâches et une logique opaque peut être plus difficile à maintenir que le routage qu’il remplace. Commencez par le nombre minimal de voies que justifient vos mesures.
N’ajoutez une voie que si elle modifie une décision opérationnelle et améliore suffisamment une contrainte mesurée pour justifier un responsable, des tests et une solution de repli propres.
Piège 3 : ignorer la latence
Les modèles moins chers ne sont pas nécessairement plus rapides. Mesurez séparément la latence et la qualité. Une cascade, qui essaie un modèle avant de passer à un autre, ajoute au moins une tentative dans les cas de basculement et peut augmenter de façon notable la latence de queue dans les parcours destinés aux utilisateurs.
Pour une réponse destinée à l’utilisateur et sensible à la latence, comparez une voie directe et une cascade à la fois sur le taux de réussite et sur la latence de queue. Les cascades sont souvent plus acceptables pour les traitements par lots ou asynchrones, mais le bon choix dépend de la charge de travail.
Piège 4 : ne pas gérer les défaillances des fournisseurs
Lorsque vous dépendez de plusieurs modèles, les défaillances possibles se multiplient. Un modèle phare peut tomber en panne, une limite de débit peut se déclencher ou une clé API expirer. Votre logique de routage doit prévoir des solutions de repli.
Définissez un comportement explicite pour les limites de débit, les expirations et les erreurs des fournisseurs. Le passage à un autre fournisseur n’est acceptable que si ses conditions de traitement des données, son acheminement régional, ses contrats d’outils et de schémas ainsi que ses résultats d’évaluation conviennent. Sinon, bloquez la réponse, mettez la demande en file d’attente ou transmettez-la à une personne. Renvoyer une réponse nettement moins bonne ne constitue pas de la disponibilité.
Piège 5 : ne pas mesurer la qualité de chaque voie
Vous devez savoir quelles voies fonctionnent bien et lesquelles échouent. Cela suppose une évaluation, idéalement automatisée.
Une configuration utile consiste à journaliser, pour chaque appel en production, le modèle utilisé, la requête, la réponse et, si possible, un indicateur de qualité comme le retour de l’utilisateur, une mesure en aval ou une évaluation automatique. Regroupez ensuite les mesures par voie afin de détecter une dérive de qualité avant les plaintes des utilisateurs.
Revalidez les dépendances actuelles
Les identifiants de modèles, les dates de retrait, les limites des fenêtres de contexte, les prix, les limites de débit, le traitement régional et le fonctionnement des sorties structurées ou des outils peuvent évoluer indépendamment. Consultez la documentation actuelle des fournisseurs et rejouez les évaluations de chaque voie avant de modifier un alias. Une couche de transport compatible avec OpenAI ne garantit ni des schémas équivalents, ni le même comportement des outils, le même calcul des jetons, les mêmes règles de sécurité ou le même traitement des données.
Une liste de vérification pour débuter
Si vous construisez un système multi-modèles à partir de zéro, ou migrez depuis un modèle unique :
-
Cartographiez vos tâches. Quels types d’appels LLM votre application effectue-t-elle ? À quelle fréquence approximative ? Quel coût approximatif ?
-
Catégorisez par complexité. Pour chaque type de tâche, décidez : trivial, modéré ou complexe. Associez au niveau de modèle.
-
Construisez un routeur. Commencez par un routage explicite fondé sur les tâches. Ne le complexifiez pas sans nécessité.
-
Définissez le comportement en cas de défaillance. Selon les conséquences et la politique relative aux données, utilisez une solution de repli testée, une file d’attente, un blocage ou le recours à une personne.
-
Mesurez la qualité de chaque voie. Mettez en place la journalisation et une évaluation de base. Vous devez savoir si la qualité est maintenue.
-
Itérez. Déplacez les tâches vers des modèles moins chers où la qualité est maintenue. Remettez les tâches sur des modèles plus coûteux où la qualité échoue. Ajustez au fil du temps.
-
Continuez d’ajuster. Les modèles et les prix évoluent, et de nouveaux modèles paraissent. Une configuration de routage optimale en mai 2026 peut ne plus l’être en novembre 2026.
Routez uniquement là où les preuves le justifient
L’orchestration multi-modèles peut réduire le coût ou la latence lorsque les types d’appels diffèrent réellement et que chaque voie est évaluée. Elle peut aussi accroître le coût d’exploitation et nuire à la cohérence. Publiez les résultats de référence et du routage, les critères de qualité et la période d’échantillonnage au lieu d’avancer un taux d’économie universel.
La condition de routage peut être courte ; le véritable travail de production porte sur la maîtrise de la configuration, l’évaluation, l’observabilité, l’examen des enjeux de confidentialité, la logique de nouvelle tentative et les solutions de repli.
Cartographiez vos tâches, évaluez les candidats viables, n’ajoutez du routage que lorsque les preuves le justifient et poursuivez les mesures après la mise en production.
