Skip to main content
Dernière vérification : 2026-07-21
Qwen3.6 constitue la famille à poids ouverts la plus largement prise en charge de Qwen : il s’agit d’un modèle multimodal à mélange d’experts qui raisonne par défaut, gère un contexte pouvant atteindre 1M tokens, et intègre nativement la possibilité d’appeler des outils pour le codage assisté par agents. Son successeur, Qwen3.8-27B, est sorti en août 2026 sous la même licence Apache-2.0 ; il bénéficie déjà de versions GGUF créées par la communauté, mais ne possède pas d’étiquette Ollama. Ainsi, Qwen3.6 demeure le choix le plus simple et validé pour un déploiement local. Il se décline en deux tailles : un modèle MoE de 35B-A3B milliards de paramètres (35B milliards au total, 3B actifs) et un modèle dense de 27B milliards de paramètres. Exécutez celui qui convient le mieux à votre matériel, puis associez le connecteur Tokios afin d’y accéder depuis n’importe quel appareil, collaborateur ou agent hébergé via https://api.tokios.com, sans besoin de ports entrants ni de VPN.
Déjà en train d’exécuter Qwen3.6 en local ? Enregistrez-le auprès de Tokios afin de l’utiliser en tant que https://api.tokios.com depuis n’importe quel client.
Vous recherchez Qwen 3.5 ? Qwen3.6 est la génération qui l’a remplacé. Le modèle dense Qwen3.6-27B d’Alibaba surpasse le modèle MoE Qwen3.5-397B-A17B de génération précédente sur plusieurs tâches de codage assisté par agents, bien qu’il soit nettement plus petit. Par conséquent, si vous envisagiez d’utiliser Qwen3.5, ce modèle est à privilégier.

Exécutez-le en local avec Ollama

Qwen3.6 figure dans la bibliothèque d’Ollama. Téléchargez et lancez l’étiquette par défaut (le modèle MoE de 35B-A3B milliards de paramètres) :
Pour le modèle dense de taille plus réduite, exécutez ollama run qwen3.6:27b. Consultez la page de la bibliothèque Ollama pour obtenir la liste complète des étiquettes ; cette page traite de la connexion au modèle, non de tous les détails d’exécution.
La fenêtre de contexte par défaut d’Ollama est limitée (2048 tokens), bien en dessous de la capacité native de Qwen3.6 qui atteint 256K tokens. Augmentez num_ctx dans votre fichier Modelfile ou dans la requête client afin d’exploiter davantage ce contexte. Selon Qwen, il convient de maintenir au moins 128K tokens pour préserver la qualité du raisonnement lors de tâches complexes.

Variantes et étiquettes

Chacune des valeurs ci-dessous provient de la fiche du modèle ainsi que de la bibliothèque Ollama. Les étiquettes et les tailles de téléchargement évoluent à chaque nouvelle version de quantification — vérifiez-les sur ollama.com/library/qwen3.6 avant de choisir définitivement un modèle. Sources : ollama.com/library/qwen3.6, fiche du modèle Qwen/Qwen3.6-35B-A3B, Qwen/Qwen3.6-27B.
Le modèle 35B-A3B est un modèle mixte d’experts qui n’utilise que 3B paramètres actifs par jeton ; il décode donc à une vitesse comparable à celle d’un modèle 3B tout en raisonnant comme un modèle bien plus volumineux. Toutefois, l’ensemble des 35B paramètres doit toujours tenir en mémoire. Il ne faut donc pas se fier uniquement au nombre de paramètres actifs pour dimensionner sa carte graphique. Consultez le fonctionnement de l’inférence pour en comprendre la raison.

Quantification et formats

Ollama’s default tags are GGUF Q4_K_M. The library also publishes -q8_0, -bf16, -nvfp4 (NVIDIA Blackwell), -mxfp8, -mlx (Apple Silicon), and -mtp-* (multi-token-prediction speculative-decoding) variants for both sizes. Which format you can run depends on your hardware — see Quantization formats and the hardware they need for the full matrix, and what quantization is for how to read the Q4_K_M-style names. Contrairement à Gemma, Qwen ne publie pas de points de contrôle officiels issus de quantification-aware-trained (QAT) ; les étiquettes mentionnées ci-dessus correspondent à des quantifications post-entraînement. Si vous souhaitez obtenir une qualité comparable à celle du QAT en utilisant seulement 4 bit, entraînez vous-même le modèle grâce à des outils tels qu’Unsloth ; consultez la quantification-aware training pour savoir quand cette approche se justifie.

Quantification du cache KV

Le cache KV correspond à la mémoire allouée par le modèle pour chaque jeton lors de la lecture de la requête et de la génération de la réponse ; cette mémoire augmente proportionnellement au nombre de jetons du contexte. Pour un modèle à contexte étendu comme Qwen3.6 (262K natif, extensible jusqu’à environ 1M), le cache KV peut atteindre voire dépasser la taille des poids du modèle. La quantification de ce cache constitue une méthode distincte de celle des poids, permettant de réduire la consommation mémoire de moitié.

Enable FP8 KV cache

Sur vLLM, ajoutez --kv-cache-dtype fp8 à votre commande de lancement :
Sur SGLang, le paramètre équivalent est --kv-cache-dtype fp8 :
Ollama et LM Studio gèrent le cache KV en interne et ne proposent pas de paramètre --kv-cache-dtype. Si vous avez besoin du cache KV en précision flottante FP8, privilégiez vLLM ou SGLang comme moteur de service.

Ce que vous obtenez

Le bénéfice concret est un contexte plus long sur le même matériel. Un déploiement de Qwen3.6 pouvant accueillir 32K tokens avec le cache KV en FP16 peut généralement en gérer 64K ou davantage avec le cache KV en FP8 dans le même budget mémoire, car le cache occupe deux fois moins d’espace par token. Sur du matériel à mémoire limitée tel qu’un DGX Spark, cette différence peut faire la distinction entre un déploiement à contexte long utilisable et un échec dû à un dépassement de mémoire. Pour l’optimisation matérielle, consultez Compatibilité des modèles DGX Spark.
Le cache KV en FP8 représente un compromis entre qualité et consommation mémoire, et n’apporte pas de gain gratuit. Pour la plupart des tâches — dialogue, résumé, génération de code — la perte de qualité de 2% reste minime. Si votre charge de travail exige une grande précision (raisonnement long, démonstrations mathématiques), effectuez des tests avec et sans cache KV en FP8 sur vos prompts réels avant de procéder au déploiement.

Adaptabilité matérielle

Une utilisation confortable pour un contexte de taille modérée, soit environ Q4. Chaque valeur indiquée est une estimation ; la taille réelle correspond à la taille de l’GGUF plus la mémoire du cache KV nécessaire à votre contexte. Consultez Quelle taille de modèle convient à votre GPU ? pour les calculs de dimensionnement.

Le DGX Spark peut-il exécuter Qwen3.6 ?

Oui, et c’est l’un des meilleurs choix pour cette gamme de processeurs. Le modèle dense 27B occupe environ 14 Go en format NVFP4, tandis que le modèle MoE 35B-A3B nécessite près de 18 Go, pour une mémoire unifiée totale de 128 Go. Comme les poids consomment peu d’espace, le reste est disponible pour le cache KV, ce qui rend le contexte natif de 262K jetons réalisable ici, et non théorique. Privilégiez le modèle MoE pour le débit : seuls 3B paramètres s’activent par jeton, ce qui permet un décodage bien plus rapide que ce que suggère sa taille totale. Consultez Compatibilité des modèles avec DGX Spark pour les réglages et les performances mesurées.

Le Strix Halo peut-il exécuter Qwen3.6 ?

Oui. Le processeur AMD Strix Halo peut allouer jusqu’à 96 Go à la puce graphique, permettant ainsi le chargement des deux variantes avec suffisamment de marge pour des contextes longs. La capacité mémoire n’est pas la contrainte principale sur cette machine ; c’est plutôt la bande passante mémoire. Le décodage reste inférieur à celui d’une carte graphique dédiée utilisant les mêmes poids, et le traitement des invites encore plus lent. Il convient donc de privilégier le modèle MoE 35B-A3B, dont le faible nombre de paramètres actifs apporte un gain significatif. Les articles Exécution de vLLM sur Strix Halo et Compatibilité des modèles avec Strix Halo détaillent les solutions ROCm et Vulkan.

Une carte graphique de 24 Go peut-elle exécuter Qwen3.6 ?

Oui, pour le modèle dense 27B à Q4_K_M, qui requiert environ 17 gigaoctets et laisse près de 7 gigaoctets pour le cache KV — ce qui convient parfaitement aux longueurs de contexte courantes. Le modèle MoE 35B-A3B nécessite quant à lui environ 24 gigaoctets ; sur une carte de 24 gigaoctets, l’espace est donc limité : il faut réduire la longueur du contexte ou opter pour une carte de 32 gigaoctets. Avec 16 Go de mémoire, le modèle dense 27B ne peut traiter que des contextes très courts, tandis que le modèle MoE ne tient pas du tout en mémoire Q4. Le transfert vers la RAM système est possible mais ralentit le décodage ; se référer à Mémoire et transfert pour plus de détails.

La méthode la plus rapide pour exécuter Qwen3.6 en local.

For the most tokens per second on modest hardware, reach for the 35B-A3B MoE: only 3B of its 35B parameters are active per token, so it decodes about as fast as a 3B model while reasoning like a much larger one — provided all 35B fit in memory (~24 GB at Q4_K_M). If you specifically want the dense 27B, pull Q4_K_M on Ollama or LM Studio (~17 GB); on Apple Silicon the -mlx tag runs fastest. Raise num_ctx only as far as you actually need — a shorter context leaves more memory for weights and speeds up decode.

Exécutez-le — pour débutants comme pour experts

Laissez Ollama en écoute sur le port http://127.0.0.1:11434 par défaut. Augmentez la valeur de num_ctx pour utiliser davantage de contexte.

Fonctionnalités

  • Raisonnement : Par défaut, Qwen3.6 fonctionne en mode réflexion, affichant un bloc <think>…</think> avant de fournir sa réponse. Pour obtenir une réponse directe, désactivez ce mode via le paramètre "chat_template_kwargs": {"enable_thinking": false} dans votre requête (ou via "enable_thinking": false sur Alibaba Cloud Model Studio). Il existe également une option « préservation de la réflexion » permettant de conserver le contexte de raisonnement d’un tour à l’autre.
  • Appel de fonctions natif : Oui. Sur vLLM/SGLang, définissez --tool-call-parser qwen3_coder (avec --reasoning-parser qwen3) ; Ollama applique le modèle de formatage automatiquement. Conçu pour la programmation assistée par agents : raisonnement au niveau du dépôt et gestion des flux de travail frontend.
  • Vision : Multimodal — accepte du texte, des images et des vidéos.
  • Long context: 262,144 tokens natively, extensible to ~1M. Keep at least 128K for complex reasoning tasks.

Connectez-le à Tokios.

Une fois Qwen3.6 lancé localement, associez le connecteur Tokios afin de pouvoir y accéder via https://api.tokios.com depuis Claude Code, Cline ou tout autre client compatible — et non uniquement depuis localhost:11434.
1

Associez le connecteur Tokios.

Connectez-vous sur tokios.com/console, ouvrez l’onglet Setup puis cliquez sur Start pairing pour obtenir un code d’activation unique (TKS-XXXX-XXXX). Installez et exécutez ensuite le connecteur sur la machine hébergeant Ollama.
Windows
macOS
Linux
Ensuite, sélectionnez approve le périphérique dans l’onglet Setup ou Connectors.
2

Indiquez au connecteur d’utiliser l’API /v1 d’Ollama.

Ollama propose une interface compatible OpenAI à l’adresse /v1. Dans un environnement à un seul modèle, l’assistant de configuration du tableau de bord renseigne automatiquement ce champ avec http://127.0.0.1:11434/v1. Pour plusieurs modèles, il faut le définir manuellement dans tokios-connector.json — consultez Configuration du connecteur.
3

Enregistrez un déploiement.

Dans l’onglet Models, enregistrez le modèle et choisissez un nom public de déploiement, tel que qwen3.6-tunnel. Ce nom — et non l’ID de modèle amont d’Ollama — sera transmis par les clients dans le champ model.
4

Créez une clé API

Dans l’onglet Keys, cliquez sur Create key. Copiez immédiatement la clé sk-tok-… — elle ne s’affiche qu’une seule fois.

Appelez-la depuis n’importe quel endroit

Le champ model doit toujours contenir le nom de votre déploiement enregistré (qwen3.6-tunnel ci-dessus), et non l’ID de modèle amont local d’Ollama. Consultez Utiliser Claude Code et Utiliser Cline pour la configuration complète des clients.

Points à prendre en compte

  • Par défaut, Qwen3.6 génère un raisonnement de type <think>…</think>. Si un client ultérieur affiche ce raisonnement brut ou si vous souhaitez réduire la latence, désactivez cette fonctionnalité comme indiqué ci-dessus.
  • Le comportement des appels d’outils dépend du moteur d’exécution utilisant le parseur qwen3_coder. Ollama s’en charge automatiquement ; si vous hébergez vous-même le modèle via vLLM/SGLang, appliquez les paramètres indiqués, sinon les appels d’outils ne seront pas interprétés.
  • Le système MoE de 35B-A3B requiert que tous les paramètres 35B soient présents en mémoire, même si seuls 3B sont actifs par jeton. Calculez donc la capacité matérielle nécessaire en fonction du volume total, et non du nombre de paramètres actifs.
Nouvelle alternative de même catégorie. Si vous envisagez d’utiliser la version dense de 27B pour des tâches d’agents, le modèle Muse Glimmer 30B de Meta constitue désormais une troisième option dans cette catégorie. Il s’agit également d’une version dense, sous licence Apache 2.0, conçue spécifiquement pour les appels d’outils et la réalisation de tâches en plusieurs étapes. Meta le compare directement à Qwen3.6 27B, et les résultats penchent en faveur de Muse Glimmer, bien que ces tests soient effectués par le fournisseur sans validation indépendante. Qwen3.6 bénéficie d’une expérience plus longue et d’une plus grande variété de modèles ; testez donc les deux solutions avant de choisir celle qui conviendra à votre workflow d’agents.

Démarrage rapide

Associez un connecteur et enregistrez votre premier modèle en suivant toutes les étapes.

Quelle taille de modèle convient à votre carte graphique ?

Assurez-vous que la quantité de VRAM disponible correspond aux exigences de Qwen3.6 avant de procéder au téléchargement.

Quantification et matériel

Parmi les formats de Qwen3.6 — GGUF, NVFP4, MLX — lequel convient le mieux à votre matériel ?

Quel modèle local choisir pour quelle tâche ?

Découvrez comment Qwen3.6 se compare aux autres modèles locaux en fonction des tâches à accomplir.