veilletech.frCe qui se passe
Patrick McCanna publie ses notes après avoir tenté de déplacer ses agents les plus gourmands en contexte depuis une API frontière vers un modèle auto-hébergé. Le résultat brut : des prompts qui tournaient proprement se sont effondrés.
Le diagnostic est la partie intéressante, parce qu'il contredit l'explication réflexe. Ce n'est pas la taille du modèle local qui pose problème, c'est la fenêtre de contexte.
Précisons d'emblée le statut de ce texte : c'est un retour d'expérience individuel, sur un seul matériel, et sa seconde moitié est une charge d'opinion contre les fournisseurs d'inférence. Les mesures, elles, sont utilisables.
Les chiffres du banc d'essai
- machine : AMD Ryzen AI MAX+ 395, 128 Go, dont 32 Go réservés au système hôte, le reste alloué à l'inférence ;
- fenêtre de contexte du système auto-hébergé : 65 000 tokens ;
- un preprompt de 35 ko consomme 14 % de cette fenêtre avant le premier échange ;
- l'agent sature en trois minutes ;
- modèles visés : des poids ouverts 27 B dits « abliterated ».
Ce que « saturer » veut dire concrètement : l'agent rappelle les mêmes outils en boucle, relit des fichiers qu'il a déjà lus, réécrit du travail terminé. Sa formule est la meilleure description du symptôme : avec une fenêtre courte, le preprompt revient à briefer un homme réincarné toutes les quatre-vingt-dix secondes — il exécute la dernière instruction sans conscience des quinze qui précédaient.
Les signaux à journaliser
C'est la contribution la plus réutilisable du billet : une liste de symptômes mesurables, à surveiller dans les journaux plutôt qu'à deviner.
- deux appels d'outils identiques consécutifs ;
- plusieurs lectures du même fichier ;
- un agent qui reformule son objectif ;
- des échecs d'analyse d'appels d'outils — le contenu brut réinjecté dans le contexte finit d'achever la session ;
- un nombre de tours élevé au regard du nombre de fichiers modifiés.
Ce qu'il faut changer dans les prompts
- Découper le preprompt en unités problème/résolution, un objectif chacune.
- Régler explicitement la longueur de contexte dans Ollama : les valeurs par défaut sont très basses, et c'est le premier réglage à corriger.
- Passer à des agents déclaratifs — dans opencode, ils se rangent dans
~/.config/opencode/agents. Les montages artisanaux, à base de scripts shell et de fichiers lus en guise de preprompt, ne survivent pas au changement ; il faut aussi se familiariser avec le système de permissions. - Écrire l'état de session sur disque pour multiplier les passages de relais, et construire des agents qui relisent seulement la tranche dont ils ont besoin.
- Réduire le nombre d'appels d'outils par étape.
- Remplacer les « ne fais pas X » par des directives positives : « fais seulement Y ».
Ce que ça change
La thèse de fond mérite d'être retenue même si l'on ne partage pas le ton du billet : ce qu'on achète à un fournisseur d'inférence n'est pas seulement un modèle, c'est une grande fenêtre de contexte. Elle laisse de la place au raisonnement en chaîne, lequel compense un prompt approximatif. Résultat, on ne sait pas que ses prompts sont mauvais — jusqu'au jour où on les fait tourner dans 65 000 tokens.
À retenir
Avant de conclure qu'un modèle local est trop faible, mesurez votre consommation de contexte. Un preprompt à 14 % de la fenêtre, plus l'historique de session, plus des sorties d'outils verbeuses : la marge disparaît avant que le modèle ait eu l'occasion de démériter.