🌠Qwen3-Coder-Next : Comment exécuter localement
Guide pour exécuter Qwen3-Coder-Next localement sur votre appareil !
Qwen publie Qwen3-Coder-Next, un modèle MoE de 80B (3B paramètres actifs) avec contexte 256K pour un codage agentique rapide et une utilisation locale. Il est comparable aux performances de modèles avec 10–20× plus de paramètres actifs.
Il fonctionne sur 46 Go de RAM/VRAM/mémoire unifiée (85 Go pour 8 bits), est en mode non-réflexion pour des réponses de code ultra-rapides. Le modèle excelle en raisonnement à long terme, en utilisation d'outils complexes et en récupération après des échecs d'exécution.
Mise à jour du 19 fév. : L'appel d'outils devrait maintenant être encore meilleur après que llama.cpp ait corrigé l'analyse.
NOUVEAU ! Voir benchmarks de quantification pour nos GGUF dynamiques !
4 fév. : llama.cpp a corrigé un bug qui ajustait le calcul pour vectorized key_gdiff. Cela corrige les boucles et les problèmes de sortie précédents. Nous avons mis à jour les GGUF - veuillez retélécharger et METTRE À JOUR llama.cpp pour de meilleures sorties.
Vous apprendrez aussi à exécuter le modèle sur Codex & Claude Code. Pour l'affinage, Qwen3-Next-Coder tient sur un seul GPU B200 pour LoRA bf16 dans Unsloth.
Qwen3-Coder-Next Unsloth GGUFs dynamiques pour exécuter : unsloth/Qwen3-Coder-Next-GGUF
Tutoriel Run GGUFCodex & Claude CodeTutoriel FP8 vLLM
⚙️ Guide d'utilisation
Vous n'avez pas 46 Go de RAM ou de mémoire unifiée ? Pas de souci, vous pouvez utiliser nos quantifications plus petites comme 3 bits. Il est préférable que la taille du modèle soit égale à la somme de votre calcul ( espace disque + RAM + VRAM ≥ taille de la quantification). Si votre quantification tient entièrement sur votre appareil, attendez-vous à 20+ tokens/s. Si elle ne tient pas, elle fonctionnera toujours en déchargeant mais ce sera plus lent.
Pour obtenir des performances optimales, Qwen recommande ces réglages :
Température = 1.0Top_P = 0.95Top_K = 40Min_P = 0.01(la valeur par défaut de llama.cpp est 0.05)pénalité de répétition= désactivée ou 1.0
Prend en charge jusqu'à 262,144 contexte nativement mais vous pouvez le régler sur 32,768 tokens pour une utilisation mémoire réduite.
🖥️ Exécuter Qwen3-Coder-Next
Selon votre cas d'utilisation, vous devrez utiliser des réglages différents. Comme ce guide utilise du 4 bits, vous aurez besoin d'environ 46 Go de RAM/mémoire unifiée. Nous recommandons d'utiliser au moins une précision 3 bits pour de meilleures performances.
Mise à jour du 4 fév. : llama.cpp a corrigé un bug qui ajustait le calcul pour vectorized key_gdiff. Cela corrige les boucles et les problèmes de sortie précédents. Nous avons mis à jour les GGUF - veuillez retélécharger et METTRE À JOUR llama.cpp pour de meilleures sorties.
REMARQUE : Ce modèle prend en charge uniquement le mode non-pensée et ne génère pas <think></think> blocs dans sa sortie. Donc spécifier enable_thinking=False n'est plus requis.
Tutoriel Llama.cpp (GGUF) :
Instructions pour exécuter dans llama.cpp (notez que nous utiliserons du 4 bits pour tenir sur la plupart des appareils) :
Obtenez le dernier llama.cpp sur GitHub ici. Vous pouvez aussi suivre les instructions de compilation ci-dessous. Changez -DGGML_CUDA=ON en -DGGML_CUDA=OFF si vous n'avez pas de GPU ou si vous voulez simplement une inférence CPU.
Vous pouvez directement récupérer depuis Hugging Face. Vous pouvez augmenter le contexte à 256K si votre RAM/VRAM le permet. L'utilisation de --fit on déterminera aussi automatiquement la longueur du contexte.
Vous pouvez utiliser les paramètres recommandés : temperature=1.0, top_p=0.95, top_k=40
Téléchargez le modèle via (après avoir installé pip install huggingface_hub). Vous pouvez choisir UD-Q4_K_XL ou d'autres versions quantifiées. Si les téléchargements se bloquent, voyez Hugging Face Hub, débogage XET
Ensuite, exécutez le modèle en mode conversation :
Ajustez aussi fenêtre de contexte selon les besoins, jusqu'à 262,144
REMARQUE : Ce modèle prend en charge uniquement le mode non-pensée et ne génère pas <think></think> blocs dans sa sortie. Donc spécifier enable_thinking=False n'est plus requis.
🦙Service et déploiement llama-server
Pour déployer Qwen3-Coder-Next en production, nous utilisons llama-server Dans un nouveau terminal, par exemple via tmux. Ensuite, déployez le modèle via :
Puis dans un nouveau terminal, après avoir fait pip install openai, nous pouvons exécuter le modèle :
Ce qui produira :
Nous avons extrait le HTML et l'avons exécuté, et l'exemple de jeu Flappy Bird qu'il a généré a bien fonctionné !

👾 OpenAI Codex & Claude Code
Pour exécuter le modèle via des charges de travail agentiques locales de codage, vous pouvez suivre notre guide. Il suffit de changer le nom du modèle 'GLM-4.7-Flash' en 'Qwen3-Coder-Next' et de vous assurer de suivre les paramètres et instructions d'utilisation corrects de Qwen3-Coder-Next. Utilisez le llama-server que nous venons de configurer à l'instant.
Après avoir suivi les instructions pour Claude Code par exemple, vous verrez :

Nous pouvons alors demander par exemple Créer un jeu Python d'échecs :



Si vous voyez API Error: 400 {"error":{"code":400,"message":"request (16582 tokens) exceeds the available context size (16384 tokens), try increasing it","type":"exceed_context_size_error","n_prompt_tokens":16582,"n_ctx":16384}} cela signifie que vous devez augmenter la longueur du contexte ou voir Qwen3-Coder-Next

🎱 FP8 Qwen3-Coder-Next dans vLLM
Vous pouvez désormais utiliser notre nouveau quant FP8 dynamique du modèle pour une inférence premium et rapide. Installez d'abord vLLM depuis les nightly. Changez --extra-index-url https://wheels.vllm.ai/nightly/cu130 en fonction de votre version CUDA trouvée via nvidia-smi - seulement cu129 et cu130 sont actuellement pris en charge.
Si vous utilisez vLLM / SGLang, essayez d'utiliser nos quants FP8-Dynamic qui peuvent augmenter le débit de 25 % ou plus ! Voir Qwen3-Coder-Next
Ensuite servez Version FP8 dynamique d'Unsloth du modèle. Vous pouvez également activer FP8 pour réduire l'utilisation de la mémoire du cache KV de 50 % en ajoutant --kv-cache-dtype fp8 Nous l'avons servi sur 4 GPU, mais si vous n'avez qu'un GPU, utilisez CUDA_VISIBLE_DEVICES='0' et définissez --tensor-parallel-size 1 ou supprimez cet argument. Utilisez tmux pour lancer ce qui suit dans un nouveau terminal puis CTRL+B+D - utilisez tmux attach-session -t0 pour y revenir.
Vous devriez voir quelque chose comme ci-dessous. Voir Qwen3-Coder-Next pour savoir comment utiliser réellement Qwen3-Coder-Next avec l'API OpenAI et les appels d'outils - cela fonctionne pour vLLM et llama-server.

🔧Appels d'outils avec Qwen3-Coder-Next
Dans un nouveau terminal, nous créons quelques outils comme l'addition de 2 nombres, l'exécution de code Python, l'exécution de fonctions Linux et bien plus :
Nous utilisons ensuite les fonctions ci-dessous (copiez-collez et exécutez) qui analyseront automatiquement les appels de fonctions et appelleront le point de terminaison OpenAI pour n'importe quel modèle :
Nous allons maintenant présenter plusieurs méthodes d'exécution d'appels d'outils pour de nombreux cas d'utilisation ci-dessous :
Exécuter du code Python généré

Exécuter des fonctions arbitraires du terminal
Nous confirmons que le fichier a été créé, et c'est le cas !

Voir Tool Calling Guide pour plus d'exemples d'appels d'outils.
📐Benchmarks
Benchmarks de quantification GGUF
Voici quelques benchmarks de quantification réalisés par des évaluateurs tiers.


Les benchmarks ont été exécutés par des contributeurs tiers sur le serveur Aider Polyglot, comparant les quantifications Unsloth GGUF sur le benchmark Aider Polyglot (score vs. VRAM). Notamment, la quantification 3 bits UD-IQ3_XXS se rapproche de BF16 en termes de performance, faisant des 3 bits un minimum judicieux pour la plupart des cas d'utilisation.
NVFP4 surpasse légèrement la référence BF16, ce qui peut être du bruit d'échantillonnage dû à un nombre limité d'exécutions ; cependant, le schéma global pour : 1-bit → 2-bit → 3-bit → 6-bit s'améliorant progressivement, suggère que le benchmark capture des différences de qualité significatives entre les GGUF d'Unsloth. Le non-Unsloth FP8 semble performer moins bien que les deux UD-IQ3_XXS et UD-Q6_K_XL, ce qui pourrait refléter des différences dans la chaîne de quantification ou, encore une fois, un échantillonnage insuffisant.
Benjamin Marie (tiers) a évalué Qwen3-Coder-Next en utilisant les GGUF Unsloth et Qwen sur une suite mixte de 750 invites (LiveCodeBench v6, MMLU Pro, GPQA, Math500), rapportant à la fois la précision globale et l'augmentation relative d'erreur (à quelle fréquence le modèle quantifié fait des erreurs par rapport à l'original).
Les graphiques montrent clairement que les quantifications Q4_K_M d'Unsloth offrent de meilleures performances que le Q4_K_M standard. Q3_K_M fonctionne comme prévu moins bien sur Live Code Bench v6, mais étonnamment bien mieux sur HumanEval que le Q4_K_M standard. Il semble fonctionner avec la plus grande efficacité, l'utilisation d'au moins Q4_K_M est conseillée.
Benchmarks de Qwen3-Coder-Next
Qwen3-Coder-Next est le modèle le plus performant pour sa taille, et ses performances sont comparables à celles de modèles avec 10–20× plus de paramètres actifs.
SWE-Bench Vérifié (avec SWE-Agent)
70.6
70.2
74.2
74.8
SWE-Bench Multilingue (avec SWE-Agent)
62.8
62.3
63.7
66.2
SWE-Bench Pro (avec SWE-Agent)
44.3
40.9
40.6
34.6
Terminal-Bench 2.0 (avec Terminus-2 json)
36.2
39.3
37.1
32.6
Aider
66.2
69.9
52.1
61.0



Mis à jour
Ce contenu vous a-t-il été utile ?

