Le test de codage Pacman passé par Qwen 3.6 27B F16, mais échec des quantifications 8 bits — Leçons clés sur les modèles et le décodage spéculatif MTP

Un développeur sur r/LocalLLaMA a partagé un benchmark pratique de codage : générer en une seule tentative un clone de Pacman sur une page à partir d'une bonne invite, trois essais, garder le meilleur. Qwen 3.6 27B F16 a produit deux jeux quasi parfaits — le premier modèle local à réussir. Cependant, passer à une quantification 8 bits a rendu les bons résultats impossibles à reproduire même après cinq tentatives, renforçant l'affirmation selon laquelle la quantification 8 bits n'est pas sans perte pour les tâches génératives complexes.
Principales conclusions techniques du post :
- Le template de chat est crucial : Le template officiel de Qwen est optimisé pour vLLM et contient des erreurs dans llama.cpp et autres exécuteurs. L'auteur a corrigé les bugs de manière itérative, et après le réglage, le modèle a semblé « d'un nouveau niveau d'intelligence ».
- Le décodage spéculatif MTP varie selon la tâche : Pour les tâches déterministes comme le codage, la génération tok/s variait de 8 à 18 tok/s (base sans MTP : 6,6 tok/s). Les tâches créatives bénéficient de moins d'accélération.
- Le choix du framework affecte davantage la vitesse que la qualité du code : Qwen CLI a fonctionné étonnamment bien — comparable à Claude Code en qualité de sortie, mais beaucoup plus rapide car les invites supplémentaires de Claude Code ralentissent les modèles locaux. Avec un modèle lent comme Qwen 3.6 27B à environ 6 tok/s, chaque invite supplémentaire ajoute une latence pénible.
- Ne pas interférer avec la gestion du contexte : La mise en cache et la compaction natives du contexte du modèle fonctionnent bien. Les plugins ou outils qui manipulent le cache ou le contexte perturbent le modèle et dégradent les performances.
- Les appels d'outils et les sous-agents fonctionnent parfaitement après les corrections appropriées du template de chat. La compaction du contexte, l'utilisation du shell et les sous-agents parallèles fonctionnent tous comme prévu.
L'auteur prévient que les résultats dépendent fortement de la configuration de l'exécuteur : utilisez des poids F16, un template de chat corrigé, et évitez les frameworks lourds sauf si vous avez une inférence rapide. Le résultat complet du Pacman jouable est disponible sur guigand.com/pacman.
📖 Lisez la source complète : r/LocalLLaMA
👀 See Also

Compteur de Jetons Claude Mis à Jour avec Fonction de Comparaison de Modèles
L'outil Claude Token Counter de Simon Willison prend désormais en charge la comparaison des nombres de tokens entre différents modèles Claude. La mise à jour révèle qu'Opus 4.7 utilise 1,0 à 1,35 fois plus de tokens qu'Opus 4.6 en raison d'un tokeniseur mis à jour, ce qui pourrait augmenter les coûts d'environ 40 % malgré un tarif identique.

La bibliothèque de workflows Claude suit et évalue désormais automatiquement les workflows issus de Reddit
Un index consultable et mis à jour automatiquement des workflows Claude et Claude Code provenant des principaux subreddits, avec étapes, artefacts et évaluations par la communauté.

cc-session-utils : Tableau de bord TUI pour gérer les sessions et les coûts de Claude Code
Un développeur a créé cc-session-utils, un outil d'interface utilisateur en terminal pour gérer les fichiers de session Claude Code, suivre les coûts par modèle, nettoyer les sessions orphelines et migrer les données entre projets. Il nécessite Python 3.11+ et est construit avec Textual.

EsoLang-Bench : Un benchmark de codage utilisant des langages ésotériques pour tester le raisonnement des LLM
Des chercheurs ont créé EsoLang-Bench, un benchmark de codage utilisant des langages de programmation ésotériques comme Brainfuck et Whitespace pour tester si les LLM peuvent raisonner ou simplement faire du pattern-matching. Le meilleur résultat parmi GPT-5.2, O4-mini, Gemini, Qwen et Kimi était de 11,2 %.