🌠Qwen3-Coder-Next : comment l'exécuter en local
Guide pour exécuter Qwen3-Coder-Next en local sur votre appareil !
Qwen lance Qwen3-Coder-Next, un modèle MoE de 80B (3B de paramètres actifs) avec un contexte de 256K pour du codage agentique rapide et un usage local. Il est comparable aux performances de modèles ayant 10 à 20 fois plus de paramètres actifs.
Il fonctionne sur 46 Go de RAM/VRAM/mémoire unifiée (85 Go pour 8 bits), n’est pas de type raisonnement pour des réponses de code ultra-rapides. Le modèle excelle dans le raisonnement à long terme, l’utilisation complexe d’outils et la 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 les corrections d’analyse de llama.cpp.
NOUVEAU ! Voir benchmarks de quantification pour nos Dynamic GGUF !
4 fév. : llama.cpp corrigé un bug qui ajustait le calcul de vectorized key_gdiff. Cela corrige les précédents problèmes de boucle et de sortie. Nous avons mis à jour les GGUF - veuillez retélécharger et MISE À JOUR llama.cpp pour de meilleures sorties.
Vous apprendrez également à exécuter le modèle sur Codex et Claude Code. Pour le fine-tuning, Qwen3-Next-Coder tient sur un seul GPU B200 pour du LoRA bf16 dans Unsloth.
Qwen3-Coder-Next Unsloth Dynamic GGUF à exécuter : unsloth/Qwen3-Coder-Next-GGUF
Tutoriel Run GGUFCodex et Claude CodeTutoriel FP8 vLLM
⚙️ Guide d’utilisation
Vous n’avez pas 46 Go de RAM ou de mémoire unifiée ? Pas d’inquiétude, vous pouvez exécuter nos quantifications plus petites comme en 3 bits. Il est préférable que la taille du modèle soit égale à la somme de vos ressources de calcul ( espace disque + RAM + VRAM ≥ taille de la quantification). Si votre quantification tient entièrement sur votre appareil, attendez-vous à 20+ tokens/s. Sinon, elle fonctionnera quand même via déchargement, mais sera plus lente.
Pour obtenir des performances optimales, Qwen recommande ces paramètres :
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 de contexte de manière native, mais vous pouvez le régler à 32,768 tokens pour une moindre utilisation de mémoire.
🖥️ Exécuter Qwen3-Coder-Next
Selon votre cas d’usage, vous devrez utiliser des paramètres 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 corrigé un bug qui ajustait le calcul de vectorized key_gdiff. Cela corrige les précédents problèmes de boucle et de sortie. Nous avons mis à jour les GGUF - veuillez retélécharger et MISE À JOUR llama.cpp pour de meilleures sorties.
REMARQUE : Ce modèle ne prend en charge que le mode sans réflexion et ne génère pas de blocs <think></think> dans sa sortie. Donc spécifier enable_thinking=False n’est plus nécessaire.
Tutoriel Llama.cpp (GGUF) :
Instructions pour exécuter dans llama.cpp (notez que nous utiliserons 4 bits pour s’adapter à 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 simplement une inférence CPU. Pour les appareils Apple Mac / Metal, définissez -DGGML_CUDA=OFF puis continuez comme d’habitude - la prise en charge de Metal est activée par défaut.
Vous pouvez directement récupérer depuis Hugging Face. Vous pouvez augmenter le contexte à 256K si votre RAM/VRAM peut le contenir. Utiliser --fit on déterminera également automatiquement la longueur du contexte.
Vous pouvez utiliser les paramètres recommandés : top_p=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, voir Hugging Face Hub, débogage XET
Puis exécutez le modèle en mode conversation :
Aussi, ajustez la fenêtre de contexte selon les besoins, jusqu’à 262,144
REMARQUE : Ce modèle ne prend en charge que le mode sans réflexion et ne génère pas de blocs <think></think> dans sa sortie. Donc spécifier enable_thinking=False n’est plus nécessaire.
🦙 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 généré a bien fonctionné !

👾 OpenAI Codex et Claude Code
Pour exécuter le modèle via des charges de travail agentiques de codage local, vous pouvez suivre notre guide. Il suffit de changer le nom du modèle 'GLM-4.7-Flash' en 'Qwen3-Coder-Next' et de veiller à suivre les paramètres et les 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 d'échecs en Python :



Si vous voyez Erreur API : 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 quant FP8 Dynamic du modèle pour une inférence premium et rapide. Installez d’abord vLLM à partir de la version nightly. Remplacez --extra-index-url https://wheels.vllm.ai/nightly/cu130 par votre version CUDA trouvée via nvidia-smi - uniquement cu129 et cu130 sont actuellement pris en charge.
Si vous utilisez vLLM / SGLang, essayez nos quantifications 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 également activer FP8 pour réduire l’utilisation de 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 avec 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’ajout 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 (copiez-collez et exécutez) qui analyseront automatiquement les appels de fonction et appelleront le point de terminaison OpenAI pour n'importe quel modèle :
Nous allons maintenant présenter ci-dessous plusieurs méthodes d’exécution de l’appel d’outils pour de nombreux cas d’usage différents :
Exécuter le code Python généré

Exécuter des fonctions arbitraires du terminal
Nous confirmons que le fichier a été créé, et c’est bien 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é réalisés par des contributeurs tiers sur le serveur Aider Polyglot, en comparant les quantifications GGUF d’Unsloth sur le benchmark Aider Polyglot (score vs VRAM). Notamment, le 3 bits UD-IQ3_XXS la quantification se rapproche de BF16 performance, ce qui fait de 3 bits un minimum raisonnable pour la plupart des cas d’usage.
NVFP4 surpasse légèrement la référence BF16, ce qui peut être du bruit d’échantillonnage dû au nombre limité d’exécutions ; toutefois, le schéma global pour : 1 bit → 2 bits → 3 bits → 6 bits en amélioration constante, suggère que le benchmark capture des différences de qualité significatives entre les GGUF d’Unsloth. 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 le pipeline de quantification ou, encore une fois, un échantillonnage insuffisant.
Benjamin Marie (tiers) a évalué Qwen3-Coder-Next en utilisant Unsloth et les GGUF de Qwen sur un suite mixte de 750 prompts (LiveCodeBench v6, MMLU Pro, GPQA, Math500), en rapportant à la fois précision globale et augmentation relative de l'erreur (à quel point le modèle quantifié fait plus souvent des erreurs par rapport à l'original).
Les graphiques montrent clairement que les quants Q4_K_M d’Unsloth sont plus performants que le Q4_K_M standard. Comme prévu, Q3_K_M affiche de moins bonnes performances sur Live Code Bench v6, mais étonnamment de bien meilleures performances sur HumanEval que le Q4_K_M standard. Il semble fonctionner avec la meilleure 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 Verified (avec SWE-Agent)
70.6
70.2
74.2
74.8
SWE-Bench Multilingual (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 json Terminus-2)
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 ?

