Qwen3.8 27B tient sur 32 Go avec agentic coding local

Un guide technique détaille comment exécuter Qwen3.8 27B en local, via llama.cpp et l’outil pi, sur un Mac Apple Silicon de 32 Go ou une machine Linux équipée d’un GPU de 24 Go. Le montage promet un usage d’agent de code sans clé API, sans cloud et hors ligne, avec une mémoire KV préservée entre les échanges. À ce niveau, la vraie question n’est pas seulement “est-ce que ça marche ?”, mais “combien de contexte on peut garder avant que la machine ne suffoque”.

Un agent de code local qui garde son fil

Le cœur du dispositif repose sur Qwen3.8 27B en format GGUF, servi par llama.cpp, puis piloté par pi. Le modèle est lancé avec un contexte de 64k, un cache KV quantifié en q8_0 et des réglages pensés pour conserver le raisonnement d’un tour à l’autre. Selon la note, l’objectif est clair : garder le “thinking” dans la conversation, plutôt que de repartir de zéro à chaque requête.

Le guide insiste aussi sur un point pratique. Unsloth fournit le GGUF avec son propre chat template, ce qui évite patchs et bricolages. Le serveur devient accessible en local sur 127.0.0.1:8080 après le premier téléchargement, annoncé à 17,56 Go. C’est beaucoup, mais on a déjà vu des outils d’IA demander davantage pour moins de résultats.

Pourquoi le modèle tient sur 32 Go

La tenue en mémoire s’explique par l’architecture de Qwen3.8. D’après la source, seuls 16 des 64 couches utilisent l’attention complète ; le reste repose sur Gated DeltaNet. Résultat, 64k de contexte coûteraient environ 2,3 Gio, contre près de 9 Gio pour un 27B classique [à vérifier]. La différence compte, car elle permet un fonctionnement local plus ambitieux sans basculer vers une station surdimensionnée.

Le paramétrage recommandé dans le guide active aussi le flash attention, un cache KV 8 bits et des checkpoints de contexte espacés. Ces points servent à garder une consommation mémoire stable quand le contexte grossit. Sur un Mac de 32 Go, la note indique que 64k et 128k peuvent tenir, avec une limite plus stricte sur 256k. Côté Linux, un GPU de 24 Go supporterait 64k, tandis que 128k exige davantage de RAM système pour les checkpoints.

La mécanique de pi, niveau par niveau

pi sert ici de couche d’orchestration. L’outil installe ses paquets, détecte le serveur local et traduit le niveau de réflexion demandé en budget de tokens. Le guide distingue plusieurs paliers : low, medium, xhigh, avec des budgets de 2 048, 8 192, 16 384 et 32 768 tokens selon le niveau choisi. Les modes “minimal” et “max” sont explicitement à éviter, car ils provoquent une erreur de type “Unexpected reasoning effort”.

Dans ce cadre, le réglage “medium” devient le compromis par défaut. Il limite le budget par tour tout en laissant au modèle de quoi dérouler un raisonnement utile. La documentation précise aussi que pi-smart-fetch lit les pages web, que pi-smart-web-search effectue des recherches sans clé API, et que pi-plate ajoute date, machine et état Git à la fin du tour pour ne pas casser le préfixe mis en cache.

La partie qui intéresse vraiment les développeurs

Le guide ne se contente pas de l’installation. Il propose aussi un prompt de travail pour générer une todo app locale, sans dépendances ni étape de build, avec ajout, bascule d’état, suppression, filtrage et persistance dans localStorage. La consigne demande un seul gestionnaire de clic délégué, des identifiants traités comme des chaînes et une relecture du fichier app.js pour vérifier la logique. En clair, on ne demande pas à l’agent de “coder un peu”, mais de livrer puis de relire ce qu’il a produit.

Cette approche dit quelque chose du moment actuel de l’IA de développement : le sujet n’est plus seulement la génération de code, mais le contrôle du flux de travail, du contexte et de la mémoire. Un agent local qui pense, cherche, écrit et vérifie sans quitter la machine réduit la dépendance au cloud et aux API, ce qui change la donne pour les équipes soucieuses de confidentialité ou de coûts récurrents.