Présentation du modèle Qwen3-Coder-Next
(qwen.ai)- Qwen3-Coder-Next est un modèle de langage à poids ouverts conçu pour les agents de génération de code et les environnements de développement locaux, fondé sur une architecture d’attention hybride et de MoE
- Il a été entraîné via une synthèse de tâches exécutables à grande échelle, l’interaction avec l’environnement et l’apprentissage par renforcement, ce qui lui confère de solides capacités de codage et d’agent même avec un faible coût d’inférence
- Au lieu de simplement augmenter le nombre de paramètres, il met l’accent sur l’extension des signaux d’entraînement des agents, en apprenant directement à partir du feedback grâce à des tâches de codage vérifiables et des environnements d’exécution
- Il dépasse les 70 % sur SWE-Bench Verified et affiche des performances compétitives face à de grands modèles sur SWE-Bench Pro ainsi que dans des environnements multilingues
- Malgré sa petite taille, il atteint un équilibre de Pareto entre efficacité et performance, ce qui en fait un modèle important pour le déploiement rentable d’agents
Vue d’ensemble de Qwen3-Coder-Next
- Qwen3-Coder-Next est un modèle de langage à poids ouverts basé sur Qwen3-Next-80B-A3B-Base
- Il adopte une architecture d’attention hybride et Mixture of Experts (MoE)
- Il a été entraîné via une synthèse de tâches exécutables à grande échelle, l’interaction avec l’environnement et l’apprentissage par renforcement
- L’objectif est une utilisation efficace dans les agents de codage et les environnements de développement locaux
- Il offre de fortes capacités de raisonnement et de codage, même avec un faible coût d’inférence
Méthode d’extension de l’entraînement des agents
- Le modèle se concentre davantage sur l’extension des signaux d’entraînement des agents que sur l’augmentation du nombre de paramètres
- En combinant des tâches de codage vérifiables et des environnements exécutables, il apprend directement à partir du feedback de l’environnement
- Principales étapes de l’entraînement
- Préentraînement continu sur des données centrées sur le code et les agents
- Ajustement fin supervisé à l’aide de données de trajectoires d’agents de haute qualité
- Entraînement spécialisé par domaine en ingénierie logicielle, QA, web/UX et autres
- Distillation de plusieurs modèles experts en un modèle unique déployable
- Cette approche renforce les capacités de raisonnement à long terme, d’utilisation d’outils et de récupération après échec d’exécution
Performances sur les benchmarks d’agents de codage
- Évalué sur divers benchmarks tels que SWE-Bench (Verified, Multilingual, Pro), TerminalBench 2.0 et Aider
- Plus de 70 % atteints sur SWE-Bench Verified
- Des performances compétitives maintenues sur SWE-Bench Pro et dans des environnements multilingues
- Malgré un petit nombre de paramètres actifs, des performances équivalentes ou supérieures à celles de modèles open source plus grands
- Sur les tâches d’agent multi-turn, il a été constaté qu’augmenter le nombre de tours d’agent renforce la capacité de raisonnement à long terme
Équilibre entre efficacité et performance
- Qwen3-Coder-Next (3B active) atteint sur SWE-Bench-Pro des performances comparables à celles de modèles 10 à 20 fois plus grands
- Les modèles propriétaires à attention complète restent devant en performance absolue, mais Qwen3-Coder-Next se situe sur une frontière de Pareto supérieure en matière d’efficacité coût/performance
- Cela montre qu’il s’agit d’un modèle adapté au déploiement rentable d’agents
Démo et exemples d’application
- Ce petit modèle de génération de code, rapide, peut être intégré dans divers environnements applicatifs
- Démonstrations sur OpenClaw, Qwen Code, Claude Code, Web Dev, Browser Use, Cline et autres
- Utilisable sur le web via coder.qwen.ai
Résumé et plan à venir
- Qwen3-Coder-Next a démontré une excellente vitesse et de solides capacités de raisonnement sur les benchmarks d’agents de codage
- Il affiche des performances compétitives même comparé à de grands modèles open source, tout en laissant encore une marge d’amélioration
- À l’avenir, l’objectif est de renforcer les capacités d’utilisation d’outils, la résolution de problèmes complexes et la prise de décision
- avec la prise en charge d’un plus grand nombre de tâches et des mises à jour rapides fondées sur les retours des utilisateurs
1 commentaires
Commentaires Hacker News
Ce modèle GGUF pèse 48,4 Go, donc il peut tourner même sur des laptops haut de gamme
Jusqu’ici, je n’avais encore vu aucun modèle local capable de faire correctement tourner un agent de code du niveau de Codex CLI ou Claude Code sur mon MacBook Pro 64 Go
Je me demande si ce sera différent cette fois. Le guide Unsloth laisse penser qu’il y a du potentiel
Dire qu’un truc branché via llama.cpp sur la même machine est local me paraît insuffisant. Par local, je parle d’un modèle LAN, c’est-à-dire d’un niveau où l’inférence peut tourner « gratuitement » sur du matériel que je contrôle directement
Par exemple, une config 5090 + Threadripper + 256 Go de RAM revient à environ 10 000 dollars, et la voie MLX à environ 6 000 dollars
Comme l’architecture interne du modèle et la méthode de quantification ont un gros impact sur l’usage réel de la mémoire, comparer uniquement au nombre de paramètres devient de moins en moins pertinent
Il faudrait donc, à mon avis, un système pour benchmarker de vraies tâches comme le tool calling, la génération de code et le traitement de documents sur une base matérielle standardisée
Même sur un vieux laptop Razer Blade, ça fonctionne de manière assez stable jusqu’à 64k de contexte
Pour des petits projets, des corrections de bugs ou des améliorations d’UI, c’est largement exploitable
Après, je pense que la notion de “usable” varie selon les gens. L’évaluation dépendra du type de tâches qu’on a essayé
Récupérer de bons logs d’exécution du modèle 120b pour faire un fine-tuning d’une version 20b pourrait être très utile
En augmentant reasoning_effort, on obtient des résultats assez bons, mais avec la limite des 64 Go de mémoire, améliorer le 20b est plus réaliste
C’était tout à fait utilisable pour nettoyer le code d’un vieux projet git, documenter et ajouter des tests
Mes exigences sont peut-être modestes, mais comme assistant de code local, j’en suis plutôt satisfait
Avec l’augmentation de la production de GPU haute performance et de mémoire, ainsi que l’optimisation des modèles, on devrait obtenir des performances tout à fait correctes même sur du matériel intermédiaire
J’ai mis en ligne sur Hugging Face un Dynamic Unsloth GGUF pour un déploiement local,
et j’ai aussi rédigé un guide pour utiliser Claude Code / Codex en local
J’ai lancé le serveur llama.cpp dans un environnement basé sur Radeon RX 7900 XTX, et ça fonctionnait de manière stable avec ctx-size 32768
On m’a demandé pourquoi il fallait utiliser la version Unsloth plutôt que le GGUF par défaut de Qwen3
J’ai installé llama.cpp via Homebrew pour exécuter localement un modèle quantifié Unsloth
J’ai pu lancer en même temps l’interface CLI et un serveur API compatible OpenAI, avec environ 28 Go de RAM utilisés
Si ce modèle est vraiment à la hauteur de ce qui est annoncé, obtenir des performances de code au niveau de Sonnet 4.5 avec 3B de paramètres actifs serait énorme
Il y avait des erreurs même sur des problèmes simples, et parfois il tombait dans une thinking loop
Ça peut venir de bugs d’implémentation initiaux, mais pour l’instant, ça ressemble à des performances survendues
J’ai fait tourner Qwen3 Coder 30B en local sur un Mac M4 Max (36 Go)
C’était lent, mais ça fonctionnait, et les résultats étaient plutôt bons
Je partage une vidéo de démonstration et un billet de blog sur la configuration
Sur un laptop avec 6 Go de VRAM, j’ai obtenu 17 tok/s, avec jusqu’à 100k de contexte
C’est impressionnant, mais comme c’est lent, je vais finalement continuer à utiliser de l’inférence cloud
J’ai partagé un [exemple de configuration docker-compose]
J’ai benchmarké le modèle FP8 dans un environnement DGX Spark + vLLM 0.15.1
Sur une requête unique, on atteint environ 43 tok/s, et jusqu’à 62 tok/s en requêtes parallèles
La version quantifiée 4-bit sous llama.cpp tourne à environ 30 à 35 tok/s, et n’utilise que 50 Go de RAM même avec 200k de contexte
Avec 3B de paramètres actifs, les performances sont un peu en dessous de GLM 4.7, mais l’efficacité est impressionnante
Je pense qu’en utilisant un agent de code simple mais rapide avec un orchestrateur, la vitesse globale peut même être meilleure
Ça automatise les tâches répétitives comme le scan de code, la recherche de bibliothèques ou l’exploration de SourceGraph
Grâce à la fonctionnalité Workspace de Mastra, un développement plus puissant orienté agents est devenu possible
J’ai testé lmstudio-community/Qwen3-Coder-Next-GGUF:Q8_0 sur Strix Halo,
avec 32 tok/s et jusqu’à 128k de contexte. C’est un peu moins bon que MiniMax M2.1 Q6, mais c’est impressionnant
Le FP8 utilisait 110 Go et ne permettait que 16k de contexte
Je l’ai essayé pour générer du code Rust, et il s’en est montré assez capable. Si la vitesse s’améliore, ça pourrait devenir réellement utilisable
Il est probable que des fournisseurs d’API proposeront bientôt ce modèle à bas prix
Je me demande s’il existe une source fiable pour les classements de modèles locaux
Les benchmarks donnent trop l’impression d’être manipulés, donc je trouve que les avis individuels ont plus de valeur
J’aimerais savoir s’il existe un endroit qui recense les meilleurs modèles par domaine : code, voix, image, résumé, musique, etc.