Les petits modèles devraient décider de ce que voient les grands

Il devient courant de laisser un modèle d’IA puissant orchestrer des modèles plus petits. Le modèle large planifie le travail, puis délègue la classification, l’extraction ou les modifications prévisibles à des modèles plus rapides et moins coûteux.

C’est une approche logique. Mais elle n’optimise que qui effectue chaque tâche.

Je pense qu’un gain d’efficacité encore plus important est possible : utiliser des petits modèles non seulement sous le modèle large, mais autour de lui.

Ils pourraient préparer son contexte avant qu’il ne raisonne, filtrer la sortie de ses outils et préserver les informations utiles à mesure que la session s’allonge.

Le modèle large prendrait toujours les décisions difficiles. Mais comme il est intelligent, lent et coûteux, chaque token qu’il traite doit justifier sa présence.

Préparer le contexte plutôt que de l’accumuler

Les agents de codage génèrent un long historique de travail : messages, plans, sorties de commandes, fichiers, erreurs et versions obsolètes d’une même information. Chaque élément a pu être utile un jour. Peu le restent pour chaque décision ultérieure.

Les systèmes actuels accumulent souvent ce matériel jusqu’à ce qu’ils effacent les résultats d’outils, sauvegardent des souvenirs ou compactent la conversation. La documentation d’Anthropic considère le contexte non pertinent comme une menace pour la concentration du modèle, et pas seulement pour la capacité de la fenêtre de contexte.

Un petit modèle pourrait sélectionner le contexte avant chaque étape de raisonnement importante. Sa sortie pourrait ressembler à ceci :

{
  "include_messages": [2, 7, 11],
  "include_files": [
    { "path": "src/auth.ts", "lines": "48-126" },
    { "path": "tests/auth.test.ts", "match": "refresh token" }
  ],
  "include_tool_results": ["call_184"],
  "durable_notes": ["L’utilisateur a rejeté les sessions basées sur les cookies."],
  "omit_reason": "Logs de build non pertinents et fichiers obsolètes"
}

Le modèle large recevrait les passages sources sélectionnés, et non un résumé vague de tout l’historique. Il s’agit d’une récupération d’informations sur l’espace de travail évolutif de l’agent lui-même.

À gauche, un espace de travail encombré de fichiers, de tests échoués, d’anciens plans et de notes éparses. Un sélecteur de contexte en choisit quatre, affichés à droite comme le contexte de travail transmis au modèle principal. — L’espace de travail conserve tout. Seul ce dont la prochaine décision a besoin parvient au modèle.

Filtrer les sorties d’outils avant la lecture par le modèle principal

Une API ou un serveur MCP peut renvoyer des dizaines de champs alors que l’agent n’en a besoin que de trois. Les identifiants, les horodatages, les métadonnées de pagination et les descriptions répétitives restent alors dans la transcription et peuvent être traités à nouveau lors des tours suivants.

Un petit modèle pourrait se placer entre la réponse de l’outil et le modèle principal. Il filtrerait la sortie brute en fonction de l’objectif actuel, renverrait un sous-ensemble typé et conserverait une référence au résultat intact. C’est particulièrement précieux lorsque le développeur de l’agent ne peut pas modifier l’outil externe.

Cette même couche pourrait classer les fichiers, localiser les sections pertinentes et exclure le contenu généré avant que le modèle large ne les lise.

Une longue réponse brute d’outil passe par un filtre de payload, qui transmet une courte liste de champs utiles au modèle principal, tandis que la réponse brute est archivée comme preuve récupérable. — Le filtre réduit ce qui parvient au modèle, et la réponse brute reste récupérable.

Compresser l’information pendant qu’elle est fraîche

La compaction est généralement réactive : une fois que le contexte atteint un seuil, un historique volumineux devient un petit résumé. D’ici là, le modèle principal a peut-être déjà relu plusieurs fois un contenu verbeux. Un résumé tardif doit également préserver des détails de plusieurs étapes dont la pertinence future est difficile à prédire.

L’historique d’un agent a deux lecteurs aux besoins différents. Les humains ont besoin des messages complets et du langage naturel pour comprendre et auditer ce qui s’est passé. Les modèles d’IA ont besoin des mêmes faits avec le moins de tokens fiables possible.

Un petit modèle pourrait maintenir les deux versions au fur et à mesure que l’information arrive : la transcription complète lisible par l’humain et une représentation compacte lisible par la machine chargée dans le contexte actif. Chaque élément compressé serait lié à l’original.

La version machine n’aurait pas besoin d’une prose soignée. Elle pourrait s’inspirer de la tendance récente “Caveman” dans les agents de codage : des déclarations télégraphiques qui suppriment les articles, les formules de politesse, les nuances et les mots de liaison tout en préservant les détails techniques. Le but n’est pas de faire parler les humains ainsi, mais d’arrêter de payer des modèles larges pour relire un langage écrit pour les humains.

Un log de test de 2 000 tokens pourrait devenir :

14 tests réussis. refreshes expired token a échoué car expiresAt était undefined à auth.test.ts:88. Sortie complète : artefact test-run-184.

Le résultat, l’échec, la valeur pertinente, la localisation et le chemin vers la preuve survivent tous. Le bruit, lui, disparaît.

C’est un entretien continu plutôt qu’une compaction d’urgence.

Deux chronologies. Dans la première, les messages bruts s’accumulent jusqu’à un signal d’alerte, puis s’effondrent en un seul résumé compact. Dans la seconde, un gardien de mémoire compresse chaque message à son arrivée, produisant un enregistrement compact tout au long du processus. — Avec une compaction tardive, vous payez pour les mêmes tokens à chaque tour jusqu’au franchissement du seuil. Compresser au fil de l’eau signifie ne payer qu’une seule fois.

L’économie est plausible

L’inférence supplémentaire n’est rentable que si elle économise plus qu’elle ne coûte en argent, en latence et en erreurs. Un modèle simple montre que le seuil financier peut être bas.

Considérons une session de codage illustrative de 20 étapes. Le modèle large reçoit au total 1,45 million de tokens d’entrée. Un modèle de contexte lit le même historique, émet 10 000 tokens d’instructions de sélection et réduit l’entrée du modèle large à 560 000 tokens. Les deux versions produisent 40 000 tokens de sortie du modèle large.

Deux colonnes. À gauche, une pile élevée de documents va directement dans le modèle principal, qui produit une large étiquette de coût rouge. À droite, un petit filtre affine d’abord la pile pour une fraction du prix, et l’étiquette de coût du modèle principal est beaucoup plus petite. — Le petit modèle est rentabilisé deux fois si ce qu’il supprime coûte plus cher à lire qu’à exécuter.

En utilisant les prix d’API standard publiés le 4 juillet 2026, l’association de Gemini 3.1 Flash-Lite (0,25 $ en entrée et 1,50 $ en sortie par million de tokens) avec Claude Fable 5 (10 $ en entrée et 50 $ en sortie) donne :

	Sans filtrage	Avec filtrage
Entrée modèle large	1,45M tokens	0,56M tokens
Coût modèle large	16,50 $	7,60 $
Coût modèle contexte	aucun	0,38 $
Total	16,50 $	7,98 $

Coût total d’une session de 20 étapes

Sans filtrage16,50 $

Avec filtrage7,98 $

La dernière ligne du tableau, à l’échelle. L’économie est de 8,52 $, soit 51,7 %.

Le filtrage est rentabilisé après la suppression de 37 750 tokens d’entrée Fable, soit 2,6 % de l’entrée brute.

Le filtre peut échouer

Supprimer du contexte peut supprimer l’indice qui permet de résoudre la tâche. Un petit modèle peut écarter une ligne de log inhabituelle, déformer une contrainte utilisateur ou perdre un identifiant nécessaire à l’appel d’outil suivant.

L’architecture nécessite donc quelques règles strictes :

garder les entrées brutes récupérables ;
rendre les décisions de filtrage structurées et auditables ;
ne jamais compresser les instructions utilisateur ou les contraintes de sécurité ;
inclure les informations incertaines ;
permettre au modèle principal de demander la preuve originale ;
mesurer le succès de la tâche, et pas seulement l’économie de tokens.

Les petits modèles doivent gérer l’accès aux preuves, et non devenir une source de vérité invisible.

L’expérience importe plus que l’estimation

L’idée doit être testée face à trois alternatives : le contexte brut accumulé, la compaction basée sur un seuil et le filtrage sémantique continu.

Chaque système doit exécuter les mêmes tâches de codage. L’évaluation doit mesurer le coût total des tokens, la latence, l’utilisation du cache et le succès des tâches. Elle doit également enregistrer chaque cas où le filtrage supprime une preuve dont le modèle principal aura besoin plus tard.

1Un jeu de tâchesLe même travail de codage pour chacun
2Trois systèmesBrut, compaction par seuil, filtrage continu
3Quatre mesuresCoût, latence, cache hits, succès
4Un verdictLe moindre coût ne compte que si ça fonctionne toujours

L’économie de tokens seule désignerait le filtre le plus agressif comme vainqueur, c’est pourquoi la qualité de l’exécution est la mesure décisive et non une simple note de bas de page.

L’architecture gagne seulement si elle réduit le coût sans réduire la qualité d’exécution. Tant qu’un tel test n’existe pas, l’économie est une raison d’expérimenter, et non la preuve que le système fonctionne.

Un nouveau rôle pour les petits modèles

Le routage de modèles demande : quel modèle doit effectuer cette tâche ?

Cette architecture demande : qu’est-ce qui mérite l’attention du meilleur modèle ?

Routage de modèlesQui fait le travail

Lit la tâche, choisit un modèle
Le modèle bon marché fait les tâches faciles
Le contexte est tout ce qui a été accumulé

Petits modèles autour du grandSur quoi le travail est fait

Le meilleur modèle garde les décisions difficiles
Les petits modèles choisissent ce qu’il lit
Le contexte est sélectionné avant chaque étape

Les deux ne sont pas des alternatives. Le routage décide qui répond, ceci décide sur quoi la réponse se base.

Les petits modèles pourraient devenir des bibliothécaires de contexte, des éditeurs de payload et des gestionnaires de mémoire. Ils prépareraient l’espace de travail avant que le modèle principal ne raisonne, puis préserveraient les résultats utiles après son action.

L’idée est surtout pertinente pour les agents de codage car ils génèrent énormément de matériel intermédiaire. Elle s’applique également à la recherche, au support et aux autres flux de travail de longue durée combinant conversation, outils et données externes.

Le modèle le plus performant ne devrait pas lire chaque ligne simplement parce que le système peut lui envoyer.

Chaque token doit être là pour une raison.