Envoyer chaque requête au même LLM, c'est payer le prix d'une Ferrari pour aller chercher le pain. L'architecture hybride SLM/LLM résout ce problème en routant automatiquement chaque requête vers le modèle adapté à sa complexité, un petit modèle spécialisé (SLM) pour le volume des tâches courantes, le gros LLM uniquement quand c'est nécessaire. Résultat sur des workloads mixtes : 60 à 85 % d'économies sur les coûts d'inférence.
Cet article détaille comment fonctionne ce pattern, quels outils l'implémentent (RouteLLM, semantic-router, LiteLLM), comment calibrer les seuils de routing, et surtout les pièges classiques : mauvaise classification, latence du routeur, gestion du fallback. Pas de magie, des ordres de grandeur réels.
Pourquoi le routing de modèles change la donne sur les coûts
Un chatbot interne qui répond à 10 000 questions par jour mélange toujours des requêtes de niveaux très différents. "Quelle est la date de ma prochaine réunion ?" et "Explique-moi les implications juridiques de cette clause de non-concurrence" n'ont pas besoin du même modèle.
Le problème : la plupart des projets LLM en production utilisent un seul modèle pour tout. C'est simple à déployer, mais coûteux. Sur un workload typique, 60 à 75 % des requêtes sont des tâches de complexité faible ou moyenne (extraction, reformulation, résumé court, classification, réponse factuelle simple). Toutes ces requêtes paient le prix d'un GPT-4o ou d'un Claude Sonnet, alors qu'un SLM à 10 fois moins cher les traiterait avec la même qualité.
C'est exactement ce que résout le model routing : analyser chaque requête en amont et décider dynamiquement quel modèle l'exécute. Le routeur lui-même doit être léger, rapide et peu coûteux, son surcoût doit rester négligeable face aux économies générées.
| Modèle | Coût input ($/M tokens) | Coût output ($/M tokens) | Latence typique | Usage idéal en routing |
|---|---|---|---|---|
| GPT-4o (OpenAI) | 2,50 $ | 10,00 $ | 2 à 5 s | Raisonnement complexe, multi-étapes |
| Claude Sonnet 4 (Anthropic) | 3,00 $ | 15,00 $ | 2 à 4 s | Analyse nuancée, longs documents |
| GPT-4o mini (OpenAI) | 0,15 $ | 0,60 $ | 0,5 à 2 s | Tâches simples, extraction, classification |
| Mistral 7B (hébergé) | 0,10 à 0,20 $ | 0,10 à 0,20 $ | 0,3 à 1 s | Volume, tâches répétitives en français |
| Phi-4 Mini (Microsoft) | ~0,05 $ | ~0,10 $ | 0,2 à 0,8 s | Classification, extraction structurée |
Sur un mix réel avec 70 % de requêtes simples routées vers un SLM à 0,15 $/M tokens et 30 % vers un LLM à 3 $/M tokens, le coût moyen par token passe de 3 $ à environ 0,60 $. Soit une réduction de 80 %, avant même d'optimiser les prompts ou de cacher les résultats fréquents.
Dans un secteur réglementé comme l'aéronautique, ce calcul se double d'une contrainte supplémentaire : la branche "LLM fort" du routeur ne peut souvent pas être une API cloud américaine dès que la requête touche des données confidentielles ou ITAR. Notre article IA souveraine vs ChatGPT chez les sous-traitants aéronautiques détaille pourquoi ce choix d'architecture se pose différemment après l'accord Airbus-Mistral.
Anatomie d'une architecture hybride SLM/LLM
Le flux d'une requête dans ce pattern suit toujours le même schéma en quatre étapes. La robustesse de l'ensemble dépend surtout de la qualité du classifieur et de la logique de fallback.
| Étape | Composant | Ce qui se passe |
|---|---|---|
| 1. Réception | API Gateway / proxy | La requête arrive. Contexte utilisateur et historique attachés si nécessaire. |
| 2. Classification | Routeur (classifieur ou règles) | La requête est analysée : longueur, complexité lexicale, type de tâche détecté, score de confiance calculé. |
| 3. Routage | Dispatcher | Si score ≥ seuil "simple" → SLM. Si score ≤ seuil "complexe" → LLM. Zone grise → LLM par défaut. |
| 4. Fallback | Fallback manager | Si le SLM répond avec un score de confiance bas ou une réponse vide → re-route automatiquement vers le LLM. |
Le fallback est la pièce la plus critique. Un SLM qui rate une requête complexe sans mécanisme de récupération génère une mauvaise expérience utilisateur et des erreurs silencieuses difficiles à détecter. On y revient dans la section sur les pièges.
Les trois approches pour implémenter le routeur
Approche 1 : règles heuristiques
La plus simple, la plus rapide à déployer, et souvent sous-estimée. On route selon des critères mesurables sans ML : longueur de la requête en tokens, présence de mots-clés indicateurs de complexité ("compare", "analyse", "explique pourquoi", "raisonne"), type de document joint, rôle de l'utilisateur.
Sur un projet d'assistant interne que nous avons mis en place pour un groupe industriel, des règles simples (longueur < 80 tokens et pas de document joint → SLM) ont suffi à router correctement 65 % des requêtes sans aucun ML. Le temps d'implémentation : une journée. Les économies : immédiates. C'est un bon point de départ avant d'investir dans un classifieur entraîné. Dans un environnement aéronautique où la branche SLM doit tourner en air-gapped, ces règles s'appliquent directement sur l'infrastructure locale : voir notre guide déployer un SLM on-premise et sécurisé dans l'aéronautique.
Approche 2 : routing sémantique avec embeddings
semantic-router (bibliothèque Python open source) est la solution la plus élégante pour ce cas. On définit des "routes" en langage naturel avec quelques exemples par catégorie, et la bibliothèque calcule la similarité sémantique entre la requête et chaque route via des embeddings locaux (Sentence Transformers). Pas d'appel API externe, latence < 20 ms sur CPU, déploiement trivial.
Exemple concret : définir une route "simple" avec des exemples comme "Résume ce texte en 3 points", "Qu'est-ce que la TVA ?", "Reformule cette phrase", et une route "complexe" avec "Compare les implications contractuelles de...", "Rédige une analyse comparative de...". La bibliothèque apprend à classer automatiquement les nouvelles requêtes par similarité avec ces exemples.
Approche 3 : classifieur ML entraîné (RouteLLM)
RouteLLM, publié par l'équipe LMSYS (les créateurs du LLM Arena), est à ce jour le framework de routing le plus robuste pour les architectures hybrides. Il entraîne un classifieur léger sur des données de préférence (paires requête / modèle optimal) pour prédire avec précision si une requête nécessite un LLM fort ou si un modèle léger suffit. Les modèles pré-entraînés publiés par LMSYS permettent de démarrer sans données d'entraînement propriétaires [RouteLLM, arXiv 2406.18665].
L'inconvénient : RouteLLM est plus complexe à opérer, nécessite un pipeline d'entraînement si vous souhaitez l'adapter à votre domaine, et introduit une dépendance supplémentaire. À réserver aux projets avec des volumes importants (> 50 000 requêtes/jour) qui justifient cet investissement de maintenance.
AVANT / APRÈS routing : tableau de coûts réels
Voici un exemple de calcul sur un assistant interne à 20 000 requêtes par jour, mix typique d'un usage bureau (FAQ interne, reformulation, extraction, quelques analyses complexes) :
| Scénario | Distribution | Coût/requête moyen | Coût mensuel estimé |
|---|---|---|---|
| Sans routing (tout GPT-4o) | 100 % LLM | ~0,012 $ | ~7 200 $ |
| Avec routing (70 % SLM / 30 % LLM) | 70 % Mistral 7B, 30 % GPT-4o | ~0,0025 $ | ~1 500 $ |
| Avec routing optimisé + cache | 70 % SLM, 30 % LLM, cache 20 % | ~0,002 $ | ~1 200 $ |
Soit une économie de l'ordre de 6 000 $/mois (environ 5 400 €) sur ce seul poste. Ces chiffres dépendent fortement de la longueur moyenne des requêtes et du ratio de complexité réel, mais l'ordre de grandeur est représentatif de ce qu'on observe en production.
Pour dimensionner votre budget LLM global et replacer le routing dans votre enveloppe, notre guide budget IA pour PME donne les repères nécessaires.
Trois outils nommés, leurs forces et leurs limites
RouteLLM
Le plus rigoureux académiquement. L'équipe LMSYS a démontré dans leur papier qu'un bon routeur peut atteindre 40 % d'économies sur les coûts sans dégradation mesurable de la qualité. Les classifieurs pré-entraînés couvrent les paires GPT-4 / GPT-3.5 et peuvent être adaptés à d'autres paires. Limite : nécessite Python 3.10+, dépendance à PyTorch pour l'inférence du classifieur, latence de 50-150 ms selon le hardware.
semantic-router
Le plus simple à démarrer. Installation en une ligne (pip install semantic-router), configuration déclarative des routes en JSON ou Python, embeddings locaux ou via API (OpenAI, Cohere). Très adapté pour commencer avec 5 à 10 routes bien définies. Limite : la qualité du routing dépend de la qualité des exemples fournis par route, avec des exemples pauvres, le classifieur se trompe sur les cas limites.
LiteLLM
LiteLLM est avant tout un proxy LLM universel (il normalise les API de 100+ fournisseurs), mais il embarque des fonctionnalités de routing : fallback automatique entre fournisseurs, règles de coût maximum par requête, retry sur erreur. Pour une PME qui veut une solution clé-en-main sans écrire de code de routing, c'est le point d'entrée le plus accessible. Déployable en Docker, interface de monitoring intégrée.
Les pièges à éviter dans une architecture hybride
Soyons honnêtes : la majorité des implémentations de routing qu'on voit en production ont au moins un de ces problèmes.
Piège 1 : l'absence de fallback explicite
Le SLM répond quelque chose d'incorrect. Sans score de confiance ni mécanisme de détection, cette réponse part à l'utilisateur. C'est le cas le plus dangereux. Toujours implémenter : (1) un score de confiance sur la sortie du SLM, (2) un seuil en dessous duquel le fallback vers le LLM est automatique, (3) une journalisation de tous les fallbacks pour monitorer la qualité du routeur.
Piège 2 : zone grise sous-dimensionnée
Les classifieurs ont une zone d'incertitude entre "clairement simple" et "clairement complexe". Envoyer cette zone vers le SLM pour économiser quelques centimes est une fausse bonne idée. Règle de base : en cas de doute, le LLM. Le coût d'une mauvaise réponse (perte de confiance, re-travail humain, erreur métier) est presque toujours supérieur au coût d'un appel LLM supplémentaire.
Piège 3 : latence du routeur mal anticipée
Un routeur qui appelle lui-même une API pour classifier la requête (anti-pattern) peut ajouter 500 ms à 2 secondes de latence, parfois plus que le SLM lui-même. Règle : le routeur doit être local et synchrone. Un classifieur Sentence Transformers sur CPU classifie en < 15 ms. Un appel réseau supplémentaire annule souvent le gain de vitesse du SLM.
Piège 4 : maintenance du classifieur oubliée
Les requêtes évoluent au fil du temps. Un classifieur entraîné sur les données de janvier peut se dégrader en juin si les patterns d'usage changent. Prévoir dès le départ : un pipeline de ré-entraînement périodique (trimestriel au minimum), une boucle de feedback utilisateur, et des métriques de monitoring sur le taux de fallback (un taux qui monte anormalement signale une dérive du classifieur).
Quand le routing vaut vraiment l'investissement (et quand non)
Le routing ajoute de la complexité. Ce n'est pas gratuit en termes de maintenance, de monitoring et de debugging. Voici quand ça vaut le coup :
- Volume > 5 000 requêtes/jour. En dessous, les économies ne justifient pas la complexité opérationnelle. Une règle simple sur la longueur de la requête peut suffire.
- Mix de complexité hétérogène. Si 80 % de vos requêtes sont du même type de complexité, le routing n'apporte rien. Il est utile quand le workload mêle vraiment des tâches simples et des tâches complexes.
- SLM validé sur vos données. Ne router vers un SLM que si vous avez validé ses performances sur un jeu de test représentatif de votre domaine. Un SLM "bon en général" peut être médiocre sur votre vocabulaire métier spécifique.
Si vous partez de zéro sur un projet LLM, lisez d'abord notre guide sur le déploiement LLM en production : le routing est une optimisation à faire une fois que l'architecture de base tourne.
Pour comprendre les modèles disponibles des deux côtés du routeur, notre comparatif SLM vs LLM : quel modèle choisir pour une PME donne les repères pratiques.
Pour aller plus loin
- SLM (Small Language Models) en entreprise : les modèles légers disponibles et leurs cas d'usage.
- SLM vs LLM : quel modèle choisir pour une PME : grille de décision complète.
- Déployer un LLM en production : infrastructure, monitoring, coûts, le guide complet avant d'ajouter un routeur.
- Top serveurs d'inférence LLM open source : vLLM, Ollama, TGI, pour héberger le SLM côté routeur.
- Mistral vs OpenAI vs Anthropic pour l'entreprise en France : choisir les bons modèles pour chaque branche du routeur.
- Choisir le bon modèle d'IA pour automatiser : la logique de task-model fit qui détermine quelle branche de votre routeur appelle quel modèle.
- Guide budget IA pour PME : replacer le routing dans votre enveloppe globale.
- Notre expertise LLM en production : audit d'architecture, optimisation des coûts d'inférence, implémentation routing.
- RouteLLM : papier original LMSYS, les données de performance du routing sur GPT-4/GPT-3.5.
- semantic-router (GitHub), la bibliothèque Python pour routing sémantique léger.
- Calibrer les seuils de routage par l'expérimentation : un protocole de test pour déterminer la complexité réelle des requêtes et ajuster vos règles de dispatching.
- Réduire la latence de la branche LLM avec vLLM : speculative decoding et prefix caching pour effacer l'écart de vitesse avec le SLM.
Vous hésitez encore ?
Discutons de votre architecture LLM. 30 minutes pour savoir si le routing est la bonne optimisation pour votre cas.
En résumé : un routeur bien calibré, c'est souvent le meilleur ROI en LLMOps
L'architecture hybride SLM/LLM n'est pas complexe sur le papier. En pratique, le diable est dans les détails : calibrage des seuils, gestion des cas limites, fallback fiable, monitoring du taux de dérive. Les projets qui s'y cassent les dents ont en général sous-estimé la zone grise et oublié le fallback.
La bonne séquence : valider d'abord que votre SLM candidat tient la route sur vos données métier, commencer avec des règles simples avant un classifieur ML, et instrumenter dès le départ (taux de fallback, latence du routeur, qualité des sorties SLM). Une fois ces bases posées, c'est souvent l'optimisation de coûts à plus fort ROI qu'on puisse appliquer sur un LLM déjà en production.
Pour un audit de votre architecture LLM actuelle et une recommandation chiffrée sur le potentiel d'économies, notre service d'expert LLM et optimisation d'inférence couvre exactement ce type de mission.
