Un petit modèle local peut-il acheminer les requêtes vers des modèles plus puissants de manière fiable ?

Oui, un petit modèle local peut acheminer les demandes vers des modèles plus puissants avec une fiabilité suffisante pour être utile, mais pas au point de constituer l’unique mécanisme de sécurité. Le routage de modèles fonctionne mieux lorsque le routeur local gère un problème d’optimisation : quelles demandes sont probablement assez simples pour être traitées par un modèle moins coûteux ou plus petit ? Les tâches à fort enjeu, ambiguës, avec un contexte long ou faisant largement appel aux outils devraient tout de même être soumises à des règles d’escalade déterministes.

Le but n’est pas de prédire parfaitement « l’intelligence ». Il s’agit de réduire les inférences coûteuses inutiles tout en maintenant le coût des erreurs de routage dans des limites mesurées.

Que décide réellement un routeur de modèles locaux ?

Demande entrante
      |
      v
Petit routeur local
      |
      +-- facile / courant ----> petit modèle local
      |
      +-- difficile / incertain --> modèle local plus puissant
      |
      +-- modèle de pointe nécessaire ---> modèle cloud

Le routeur peut être un classificateur, un système de similarité fondé sur les plongements, un petit LLM, un modèle de préférences appris ou une combinaison de règles et de scores appris.

Des projets tels que RouteLLM illustrent cette approche en produisant un score auquel on applique un seuil pour choisir entre un modèle faible et un modèle puissant.

Pourquoi un seuil compte plus que l’étiquette du routeur

Un routeur qui indique « facile » ou « difficile » masque la véritable décision opérationnelle. Un score associé à un seuil vous permet de choisir le compromis entre coût et qualité.

score du routeur : besoin estimé d’un modèle plus puissant

0.0 -------------------------- 1.0
 facile                         difficile

seuil = 0.35
score >= 0.35 -> escalader

La documentation de RouteLLM recommande de calibrer le seuil à partir de requêtes ressemblant au trafic réel, car la proportion acheminée vers le modèle le plus puissant varie selon la distribution des demandes. Cet avertissement est particulièrement important à la maison : votre mélange de commandes Home Assistant, de questions de programmation, de RAG privé, de recherches familiales et de raisonnement approfondi ne ressemble en rien à un benchmark générique.

Définissez des règles d’escalade strictes avant le routage appris

Certaines demandes devraient contourner complètement le petit routeur.

Cela évite que les erreurs de routage ne se transforment en failles de sécurité. Le guide de ZimaSpace sur les limites de confiance liées à l’exécution des outils est pertinent ici : choisir un modèle et autoriser un effet de bord sont deux décisions distinctes.

Featured

NAS cloud personnel et domestique ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Que signifie « fiable » pour un routeur ?

Mesurez le type d’échec qui vous importe réellement. Un routeur peut sembler précis dans l’ensemble tout en envoyant les pires prompts au modèle le moins performant.

Suivez au minimum :

• taux d’erreurs du modèle puissant : les prompts qui nécessitaient une escalade, mais sont restés au petit modèle ;
• taux d’escalades inutiles : les prompts simples envoyés au modèle coûteux ;
• réussite de la tâche finale : le processus complet s’est-il correctement déroulé ?
• latence : le routage a-t-il ajouté davantage de délai qu’il n’en a fait gagner ?
• coût ou énergie : quelle quantité d’inférence coûteuse a été évitée ?

Dans beaucoup de systèmes domestiques, les erreurs du modèle puissant méritent davantage de poids que les escalades inutiles. Un appel d’inférence supplémentaire coûte généralement moins cher que de renvoyer sans le signaler une mauvaise commande de sauvegarde ou un plan d’automatisation erroné.

Prévoir une période d’évaluation en mode fantôme

Avant de laisser le routeur choisir les modèles utilisés en production, exécutez-le en mode fantôme :

1. acheminer chaque demande selon le parcours fiable actuel ;
2. consigner le modèle que le routeur aurait choisi ;
3. comparer hors ligne les réponses du petit et du grand modèle ;
4. classer les échecs par catégorie de demande ;
5. choisir un seuil en fonction du taux d’erreurs acceptable ;
6. n’autoriser le routage automatique qu’ensuite.

Quelques centaines de demandes représentatives d’un foyer sont généralement plus utiles que la recherche d’un score dans un classement public qui mesure un autre domaine.

Les conversations à plusieurs tours sont plus difficiles que les prompts isolés

Router une question isolée comme « convertis cette date » est plus facile que router le cinquième tour d’une conversation dont des éléments importants figurent dans des messages précédents.

L’implémentation actuelle du contrôleur de RouteLLM indique explicitement que ses routeurs ont été entraînés sur des données du premier tour et que le routage multi-tour nécessite davantage de recherches. C’est un avertissement général pertinent : un routeur qui évalue uniquement la dernière phrase de l’utilisateur peut voir « oui, fais ça » sans savoir que « ça » désigne une migration complexe de l’infrastructure.

Parmi les options :

• effectuer le routage à partir d’un résumé succinct de la conversation et du dernier tour ;
• conserver le même modèle pendant toute la durée d’une tâche ;
• faire remonter automatiquement les demandes après l’utilisation d’un outil ou dès que le contexte s’allonge ;
• laisser le modèle plus puissant prendre le relais lorsque le petit modèle demande de l’aide.

Le petit modèle peut-il déterminer qu’il n’est pas sûr de lui ?

La confiance que le modèle s’attribue est un indicateur utile, mais elle ne garantit rien. Les modèles peuvent se tromper avec assurance.

Un routeur plus sûr combine plusieurs indicateurs :

score de routage =
  difficulté estimée
+ longueur du contexte
+ besoin d’outil
+ règle de domaine
+ importance pour l’utilisateur
+ catégorie de défaillance antérieure

Par exemple, un modèle de 3 milliards de paramètres pourrait classer « résume cette note de deux paragraphes » comme une demande pouvant être traitée localement, tandis qu’une règle déterministe ferait remonter toute demande contenant un plan de modification de l’infrastructure, une opération sur une clé de chiffrement ou une instruction financière ou juridique.

Utilisez la vérification pour détecter les erreurs de routage vers un modèle trop faible.

Pour certaines tâches confiées à un petit modèle, la validation est peu coûteuse. Le JSON peut être vérifié par rapport à un schéma. Le code peut être testé. Les déplacements de fichiers peuvent être simulés. Les réponses fondées sur des informations récupérées peuvent exiger des citations. Un classificateur peut être vérifié par rapport aux étiquettes autorisées.

Lorsque la validation échoue, envoyez la même tâche au modèle plus puissant, avec le contexte d’origine et l’erreur de validation.

résultat du petit modèle
      |
      v
validateur
  |       |
 réussi    échoué
  |       |
 terminé    v
       modèle puissant

Le routage devient ainsi un système adaptatif plutôt qu’une décision ponctuelle.

Pourquoi le routage convient à un serveur d’IA domestique

Un serveur domestique dispose souvent d’un modèle économique toujours actif, mais sa capacité à exécuter un modèle local plus grand est limitée. Il peut aussi accéder à une API de modèle de pointe pour les tâches difficiles. Le routage permet au système domestique de traiter les tâches courantes de manière privée et économique, tout en ne faisant appel à un modèle plus puissant qu’en cas de besoin.

Cela complète le modèle de coûts plus général de l’IA locale, par API et hybride : un système hybride n’a pas besoin de faire passer chaque prompt par le même niveau de calcul.

Une politique de routage prudente pour un usage domestique

• Par défaut, confiez les tâches répétitives d’extraction, d’étiquetage et de mise en forme au petit modèle.
• Escaladez les requêtes qui dépassent un seuil de complexité testé.
• Escaladez systématiquement, quel que soit le score, les catégories à fort enjeu.
• Escaladez lorsque les validateurs échouent.
• Escaladez les tâches ambiguës comportant plusieurs échanges.
• Consignez les décisions de routage et leurs résultats.
• Recalibrez lorsque les modèles, les prompts ou la répartition des tâches évoluent.
• Gardez une option manuelle « utiliser le modèle le plus puissant ».

FAQ

Le routeur doit-il lui-même être un LLM ?

Non. Un petit classificateur, un modèle de similarité par embeddings, un moteur de règles ou un routeur de préférences entraîné peuvent être plus rapides et plus faciles à calibrer.

Le routage peut-il garantir une qualité identique à celle du plus grand modèle utilisé systématiquement ?

Non. Le routage implique des compromis. Vous pouvez réduire le taux d’erreur grâce à des seuils prudents, des règles d’escalade strictes et des validateurs, mais le décalage de distribution et les erreurs de classification ne disparaissent jamais.

Un routeur doit-il choisir les outils en plus des modèles ?

Il peut aider à classer les intentions, mais l’autorisation d’utiliser des outils doit rester dans une couche de politique distincte. Le choix du modèle est une décision d’optimisation ; l’exécution de privilèges relève de la sécurité.

Verdict final

Un petit modèle local peut servir de routeur efficace à condition de le rendre prudent, mesurable et remplaçable. Calibrez-le à partir de requêtes réelles, définissez les catégories qui doivent toujours être escaladées, validez les résultats à faible coût et surveillez les erreurs du modèle puissant. Le rôle du routeur n’est pas de prouver que le petit modèle est capable. Il doit déterminer quand dépenser davantage en calcul vaut la réduction du risque.