Qwen3.6-27B en tant que couche de raisonnement locale : résultats de test multi-agent sur 2 semaines

Un développeur a remplacé Claude par Qwen3.6-27B dans un orchestrateur multi-agent pendant deux semaines, fonctionnant entièrement sur un seul RTX 3090. L'objectif était simple : tester si un modèle local pouvait servir de couche de raisonnement — boucle lead/manager/sous-agent — dans des workflows de codage réels. Les résultats fournissent des chiffres concrets pour ceux qui envisagent de réduire les coûts cloud.

Configuration et référence

• Matériel : RTX 3090, 24 Go de VRAM
• Modèle : Qwen3.6-27B en quantification Q6_K (~22 Go sur GPU), contexte effectif de 32k
• Moteur d'inférence : Ollama
• Orchestrateur : Système multi-agent avec plans JSON structurés, modal d'approbation des plans, passage de révision automatique après exécution du sous-agent
• Charge de travail : 47 workflows de codage multi-étapes sur deux dépôts réels

Ce qui a fonctionné (la couche de raisonnement)

Génération de plans. Qwen3.6 a généré des plans multi-étapes à peu près aussi bien que Claude sur ces tâches. Légèrement plus conservateur — moins de suggestions de refactorisation non sollicitées — mais cohérent et conforme au schéma environ 95% du temps après ajustements des invites. Les 5% restants étaient réparables avec une seule relance.

Extraction de mémoire. L'extraction de faits de style Mem0 toutes les 6 itérations a bien fonctionné. Qwen a extrait les mêmes faits que Claude (par ex., "l'utilisateur préfère pas de commentaires sauf s'ils expliquent un 'pourquoi'") et les a stockés proprement dans Qdrant.

Révision automatique des sorties des sous-agents. Une deuxième instance de Qwen révisant le code de la première a détecté environ 60% des bogues que la révision de Claude détectait sur le même ensemble. Moins agressif, toujours utile et gratuit.

Là où ça a cassé

Fiabilité des appels d'outils. La sortie JSON des appels d'outils de Qwen3.6 présentait un taux d'erreur de format d'environ 12% sur 47 tâches. Claude était à environ 0,5% sur la même charge de travail. Les erreurs n'étaient pas du JSON malformé — c'étaient des noms de champs incorrects, des types erronés, des signatures d'outils hallucinées. L'utilisation d'Outlines ou du mode de sortie stricte a réduit les erreurs mais ne les a pas éliminées.

Dérive du contexte long. Passé environ 14k tokens de contexte de session accumulé, Qwen commençait à mal se souvenir des décisions (par ex., "vous avez dit d'utiliser Postgres" alors que le contraire avait été dit). La limite pratique effective est d'environ 12k tokens, après quoi un résumé agressif et une réinitialisation s'imposent.

Gestion des défaillances en cascade. Lorsqu'un sous-agent échouait, le planificateur de Claude remarquait généralement et replanifiait. Qwen générait parfois des étapes aval en supposant que le sous-agent avait réussi. Trois hallucinations en cascade sur 47 exécutions — pas catastrophiques avec une validation des plans, mais le serait sans.

Implications pratiques

L'avis du développeur : "Qwen3.6-27B est une couche de raisonnement viable pour les systèmes multi-agents locaux aujourd'hui. Ce n'est PAS une couche d'exécution viable." Si vous construisez des agents locaux uniquement, vous avez besoin de :

1. Respect de la sortie structurée à la frontière des appels d'outils (Outlines, lm-format-enforcer ou mode grammaire de votre moteur d'inférence)
2. Validation d'approbation des plans pour que les 12% d'erreurs de format n'atteignent jamais les écritures réelles de fichiers
3. Logique de replanification en cas d'échec — le modèle lui-même ne peut pas être fié pour gérer les défaillances en cascade

L'écart de 12% d'erreurs d'appels d'outils est la métrique à surveiller. Une fois que Qwen3.6 ou le prochain modèle local atteindra environ 2% sur cette métrique, l'argument en faveur du raisonnement cloud dans les boucles d'agents s'affaiblit considérablement.