Application de l'Architecture de Claude Code aux Modèles Locaux 9B : Principales Découvertes et Optimisations

Configuration expérimentale et découverte clé

Le développeur a utilisé une RTX 5070 Ti (16 Go de VRAM) avec qwen3.5:9b via Ollama (6,6 Go) et le framework d'agent local OpenClaw. Après 18 tests et 10 optimisations, la découverte principale a été que qwen3.5:9b dispose d'appels d'outils structurés natifs, tandis que qwen2.5-coder:14b et qwen2.5:14b placent le JSON dans le champ de contenu au lieu d'utiliser de véritables appels d'outils, nécessitant un parsing supplémentaire.

Comparaison des performances

Comparaison des performances des modèles :

• qwen3.5:9b : Structure d'appels d'outils native, chaîne de réflexion activée, 39 tok/s
• qwen2.5-coder:14b : Appels d'outils défectueux (dans le champ de contenu), pas de chaîne de réflexion, ~30 tok/s
• qwen2.5:14b : Appels d'outils défectueux (dans le champ de contenu), pas de chaîne de réflexion, ~35 tok/s

10 optimisations issues de l'architecture de Claude Code

• Invite système structurée → +600 % de qualité de sortie (test A/B : 4 problèmes trouvés contre 25+)
• MicroCompact (compression des résultats d'outils) → 80-93 % de compression, 11 Ko réduits à 367 caractères
• Coupure forcée (transition exploration→production imposée) → Résout les boucles d'exploration où les modèles 9B restent bloqués à lire des fichiers sans produire de résultat
• think=false → Efficacité des tokens multipliée par 8-10, élimine la contamination linguistique
• Chargement différé de ToolSearch → -60 % d'espace d'invite (229 contre 568 tokens)
• Système de mémoire à quatre types (utilisateur/retour/projet/référence) → Réponses personnalisées
• Bifurcation du cache KV → Effet minimal sur un seul GPU (1,1x), nécessite vLLM
• Discipline d'écriture stricte → Vérifier avant de mettre à jour la mémoire, empêche la corruption de la mémoire
• Amorçage parallèle → Démarrage à froid 9 % plus rapide
• Suivi de rupture du cache → Ollama met en cache les invites identiques (182 ms→75 ms)

Découverte fondamentale : l'autodiscipline comme véritable plafond

La plus grande découverte a été que le véritable plafond pour les modèles 9B n'est pas la capacité de raisonnement ou la précision de l'utilisation des outils, mais l'autodiscipline — savoir quand arrêter d'explorer et commencer à produire un résultat. Sans coupure forcée, le modèle utilisait les 12 étapes pour lire des fichiers et produisait 0 octet de rapport. Avec la coupure forcée : 5 étapes de lecture + 1 étape d'écriture = rapport structuré de 6080 octets.

Ce que qwen3.5:9b peut réellement faire

• Lire des scripts bash de 800 lignes et trouver de vrais bugs (conditions de concurrence, opérations non atomiques) — 2 min
• Concevoir une architecture de système de retour de vente — document de 8,7 Ko en 2,5 min
• Construire un projet complet (calculatrice + tests + exécution des tests) — 28 secondes
• Exécution autonome en 10 étapes : écrire un scraper web → échec de pip install → trouver une solution de contournement → réessayer → tests réussis — zéro intervention humaine
• Pipeline complet de mini-usine : recherche → rédaction d'article → relecture → publication en HTML — 2,5 min

Performances du moteur complet

Les 10 optimisations ont été regroupées dans un seul moteur Python (~280 lignes). Résultats de la première exécution :

• Amorçage : 527 ms (mémoire parallèle + préchauffage du modèle)
• Exploration : 5 étapes d'outils avec MicroCompact (88 % de compression)
• Production : rapport structuré de 1947 caractères
• Total : 39,4 s / coût API nul

Ce qui n'a pas fonctionné

• Bifurcation du cache KV sur un seul GPU (nécessite multi-GPU ou vLLM)
• Budget d'étapes dans l'invite système (le modèle ignore les méta-instructions concernant son propre comportement)
• Série qwen2.5 pour les appels d'outils (problèmes de format)

Le développeur a exécuté cela sur WSL2 + Ubuntu 24.04 et est prêt à partager plus de détails ou le code du moteur.