🌠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 de 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 46GB de RAM/VRAM/mémoire unifiée (85GB pour 8 bits), est en mode non-réflexif pour des réponses de code ultra-rapides. Le modèle excelle en raisonnement à long terme, usage complexe d'outils et récupération après des échecs d'exécution.
Mise à jour du 19 février: 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évrier : llama.cpp corrigé un bug corrigeant le calcul pour vectorized key_gdiff. Cela corrige des problèmes de bouclage et de sortie antérieurs. Nous avons mis à jour les GGUF - veuillez télécharger à nouveau 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 GGUF dynamiques pour exécuter : unsloth/Qwen3-Coder-Next-GGUF
Lancer le tutoriel GGUFCodex & Claude CodeTutoriel FP8 vLLM
⚙️ Guide d'utilisation
Vous n'avez pas 46GB 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 capacité de 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 quand même en déchargeant mais sera plus lente.
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 à 32,768 tokens pour une moindre utilisation mémoire.
🖥️ Exécuter Qwen3-Coder-Next
Selon votre cas d'utilisation, vous devrez employer des réglages différents. Comme ce guide utilise du 4 bits, vous aurez besoin d'environ 46GB de RAM/mémoire unifiée. Nous recommandons d'utiliser au moins la précision 3 bits pour de meilleures performances.
Mise à jour du 4 février : llama.cpp corrigé un bug corrigeant le calcul pour vectorized key_gdiff. Cela corrige des problèmes de bouclage et de sortie antérieurs. Nous avons mis à jour les GGUF - veuillez télécharger à nouveau et METTRE À JOUR llama.cpp pour de meilleures sorties.
REMARQUE : Ce modèle supporte uniquement le mode non-pensant 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 (note : nous utiliserons du 4 bits pour tenir sur la plupart des appareils) :
Obtenez la dernière llama.cpp sur GitHub ici. Vous pouvez également 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 seulement une inférence CPU. Pour appareils Apple Mac / Metal, définissez -DGGML_CUDA=OFF puis continuez comme d'habitude - le support Metal est activé par défaut.
Vous pouvez tirer directement depuis Hugging Face. Vous pouvez augmenter le contexte à 256K si votre RAM/VRAM peut le contenir. 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 restent bloqués, voir 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 supporte uniquement le mode non-pensant et ne génère pas <think></think> blocs dans sa sortie. Donc spécifier enable_thinking=False n'est plus requis.
🦙 Service & 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 affichera :
Nous avons extrait le HTML et l'avons exécuté, et l'exemple de jeu Flappy Bird généré a bien fonctionné !

👾 OpenAI Codex & Claude Code
Pour exécuter le modèle via des charges de travail agentiques de codage locales, 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 bons paramètres et instructions d'utilisation 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 pour les é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 maintenant utiliser notre nouveau Quantification FP8 dynamique du modèle pour une inférence premium et rapide. Installez d'abord vLLM depuis la version nightly. Changez --extra-index-url https://wheels.vllm.ai/nightly/cu130 pour votre version CUDA trouvée via nvidia-smi - seuls 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
Puis servez La version FP8 dynamique d'Unsloth du modèle. Vous pouvez aussi activer FP8 pour réduire l'utilisation mémoire du cache KV de 50% en ajoutant --kv-cache-dtype fp8 Nous l'avons servi sur 4 GPU, mais si vous avez 1 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 en utilisant l'API OpenAI et l'appel d'outils - cela fonctionne pour vLLM et llama-server.

🔧Appel 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 encore :
Nous utilisons ensuite les fonctions ci-dessous (copier-coller et exécuter) qui analyseront automatiquement les appels de fonction et appelleront le point de terminaison OpenAI pour n'importe quel modèle :
Maintenant, nous allons 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 terminal arbitraires
Nous confirmons que le fichier a été créé et c'est le cas !

Voir Tool Calling Guide pour plus d'exemples d'appel 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 quant approche BF16 la performance, rendant 3 bits un minimum raisonnable pour la plupart des cas d'utilisation.
NVFP4 surpasse légèrement la référence BF16, ce qui peut être un bruit d'échantillonnage dû au nombre limité d'exécutions ; cependant, le schéma global pour : 1-bit → 2-bit → 3-bit → 6-bit s'améliorant régulièrement, suggère que le benchmark capture des différences de qualité significatives entre les Unsloth GGUFs. Le non-Unsloth FP8 semble moins performant 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 GGUFs Unsloth et Qwen sur un ensemble mixte de 750 prompts (LiveCodeBench v6, MMLU Pro, GPQA, Math500), rapportant à la fois la précision globale et l'augmentation relative de l'erreur (à quelle fréquence le modèle quantifié fait des erreurs de plus que l'original).
Les graphiques montrent clairement que les quants Q4_K_M d'Unsloth performent mieux que le Q4_K_M standard. Q3_K_M, comme prévu, fonctionne 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 efficience, il est conseillé d'utiliser au minimum Q4_K_M.
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 ayant 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 ?

