---

Qwen3.6 puis 3.8 : la famille dense qui a conquis le GB10

L’écosystème des LLM open-source a connu une accélération constante depuis 2023, mais rares sont les modèles qui ont suscité autant d’attentes que la lignée Qwen 3.6/3.8. Annoncé le 22 avril 2026 par l’équipe Qwen d’Alibaba, Qwen3.6-27B se distingue d’emblée par son architecture hybride : il combine une attention linéaire (gated DeltaNet sur les trois quarts des couches) avec une attention classique (gated attention sur le quart restant), le tout agrémenté d’un mécanisme sparse-MoE pour certaines transformations. Le résultat ? Une fenêtre de contexte de 256 000 tokens et une licence Apache 2.0, qui ouvre grand la porte aux déploiements commerciaux et personnels.

Le white paper d’Openzeka (juillet 2026) précise l’architecture exacte du modèle : 64 couches, dimension cachée de 5120, organisation en blocs de 16 × (3 × Gated DeltaNet → FFN → 1 × Gated Attention → FFN). Les têtes d’attention DeltaNet utilisent 48 têtes V et 16 têtes QK avec une dimension de tête de 128, tandis que l’attention gated utilise 24 têtes Q et 4 têtes KV avec une dimension de 256. Le contexte natif atteint 262 144 tokens, extensible jusqu’à 1 010 000 avec YaRN. Un encodeur visuel est également présent, ce qui en fait un modèle multimodal (Image-Text-to-Text), bien que les benchmarks se concentrent sur le texte.

Ce qui frappe, c’est la rapidité avec laquelle NVIDIA a embrassé le modèle. Dès le 26 juin 2026, le géant vert publiait sur Hugging Face une quantification NVFP4 officielle de Qwen3.6-27B, spécifiquement optimisée pour le DGX Spark (GB10 Grace Blackwell). Une démarche rare : d’ordinaire, NVIDIA laisse la communauté adapter ses modèles. Ici, l’entreprise a pris les devants, signe que ce modèle est considéré comme un candidat sérieux pour l’inférence locale de haute qualité.

Mais l’histoire ne s’arrête pas là. En août 2026, Alibaba a publié Qwen3.8-27B, une itération qui conserve la même architecture hybride et la même empreinte mémoire, mais corrige plusieurs défauts de la 3.6. Les premiers benchmarks comparatifs (llm-stats.com, septembre 2026) montraient des gains de 3 à 5 points sur les benchmarks de code (HumanEval, MBPP) et de 2 points sur MMLU-Pro. Un variant MoE de 35B (35B-A3B) existe également, mais c’est bien le modèle dense qui concentre l’attention des testeurs — et c’est précisément sur lui que les mesures les plus sérieuses ont depuis été publiées.

Il faut d’ailleurs noter que la famille Qwen3 a continué d’évoluer en parallèle : le dépôt officiel QwenLM/Qwen3 référence les variantes Qwen3-Instruct-2507 et Qwen3-Thinking-2507 (235B-A22B, 30B-A3B, 4B), avec des gains documentés sur le suivi d’instructions, le raisonnement logique, la compréhension de texte, les mathématiques, les sciences, le code et l’usage d’outils. Ces variantes ne sont pas les cibles privilégiées du GB10 — trop lourdes ou trop petites — mais elles confirment la cadence de publication trimestrielle de l’équipe Qwen, qui explique la maturation rapide de la lignée 27B.

---

Sur le DGX Spark : ce que disent vraiment les benchmarks mesurés

C’est ici que l’article initial doit être sérieusement révisé. Les chiffres « 34 à 38 t/s » attribués à des « tests communautaires du 20 août 2026 » ne correspondent à aucune source vérifiable et sont, en réalité, très en dessous de ce que la machine délivre avec les bonnes recettes. Le study le plus complet à ce jour a été publié sur les forums développeurs de NVIDIA : il couvre onze configurations sur une à quatre DGX Spark, avec une méthodologie explicite (128 tokens en entrée, 128 en sortie, 10 rounds par niveau de concurrence, critère de passage TTFT < 1000 ms ET TPS ≥ 15 tok/s).

Le matériel et la pile de test

Le banc d’essai est le suivant : 4× NVIDIA DGX Spark (GB10 Grace Blackwell, SM 12.1, 128 Go d’UMA, 273 Go/s de bande passante LPDDR5X), interconnectés en CX-7 (100 Gbps), avec sparkrun v0.3.4 et l’outil de benchmark CordatusAI. Trois images logicielles sont comparées : vLLM officiel (vllm/vllm-openai:qwen38), vLLM eugr (ghcr.io/spark-arena/dgx-vllm-eugr-nightly:latest) et SGLang (lmsysorg/sglang, épinglé par SHA). Côté modèles : BF16 (55,6 Go), FP8 (30,9 Go), deux NVFP4 distincts — InferAct et RadixArk, ~18 Go chacun — et un modèle draft DSpark de 1,36B pour le décodage spéculatif.

La progression complète, étape par étape

Étape	Configuration	Ce qui change	TPS @ C1	TTFT @ C1	Concurrence max (les deux critères)
1	BF16, TP=1, vLLM officiel	—	4,5	335 ms	Jamais
2	BF16 + MTP, TP=1, vLLM officiel	+MTP n=3	9,9	611 ms	Jamais
3	FP8, TP=1, vLLM officiel	BF16→FP8	7,9	172 ms	Jamais
4	FP8 + MTP, TP=1, vLLM officiel	+MTP n=3	17,1	392 ms	C4
5	NVFP4 (InferAct), TP=1, vLLM officiel	FP8→NVFP4	9,7	155 ms	Jamais
6	NVFP4 (InferAct) + MTP, TP=1, vLLM officiel	+MTP n=3	18,5	341 ms	C8
7	NVFP4 (RadixArk) + DSpark, TP=1, SGLang	moteur + décodage spéculatif	36,6	246 ms	C4
8	NVFP4 (InferAct) + MTP, TP=2, vLLM officiel	+1 Spark	23,4	254 ms	C8
9	NVFP4 (InferAct) + MTP, TP=2, vLLM eugr	officiel→eugr	33,0	311 ms	C16
10	NVFP4 (RadixArk) + DSpark, TP=2, SGLang	+1 Spark	51,8	219 ms	C16
11	NVFP4 (RadixArk) + DSpark, TP=4, SGLang	+2 Sparks	77,3	227 ms	C16

Trois enseignements majeurs se dégagent de ce tableau, et ils contredisent plusieurs affirmations de l’article initial.

Premier enseignement : le NVFP4 seul ne suffit pas. À l’étape 5, le NVFP4 InferAct en vLLM officiel ne délivre que 9,7 t/s en C1 — à peine mieux que le FP8 (7,9 t/s) et loin devant le BF16 (4,5 t/s), mais très loin des « 34-38 t/s » annoncés. La quantification 4 bits réduit l’empreinte mémoire et accélère le préfill, mais elle ne transforme pas magiquement le débit de décodage d’un modèle dense de 27B sur une bande passante de 273 Go/s. C’est une loi physique : chaque token généré exige de lire l’intégralité des poids actifs, et 18 Go de NVFP4 à 273 Go/s plafonnent théoriquement autour de 15 t/s en pur décodage sans astuce.

Deuxième enseignement : le décodage spéculatif est le vrai levier. Le MTP (Multi-Token Prediction) fait passer le BF16 de 4,5 à 9,9 t/s (×2,2) et le FP8 de 7,9 à 17,1 t/s (×2,2). Le NVFP4 InferAct + MTP atteint 18,5 t/s. Mais c’est DSpark sur SGLang qui change la donne : 36,6 t/s en mono-Spark, soit près de quatre fois le NVFP4 nu. Le choix du moteur d’inférence (SGLang plutôt que vLLM) combiné au bon modèle draft pèse davantage que le choix de la quantification.

Troisième enseignement : le tensor parallelism paie, mais pas linéairement. Passer de 1 à 2 Sparks avec NVFP4 + MTP + vLLM officiel ne fait gagner que de 18,5 à 23,4 t/s (×1,26) — décevant. Mais avec vLLM eugr, on monte à 33,0 t/s, et avec DSpark + SGLang, à 51,8 t/s. À 4 Sparks, DSpark + SGLang atteint 77,3 t/s en C1 et tient la concurrence 16 avec les deux critères de passage. Le message est clair : le scaling multi-nœuds fonctionne, mais il exige la bonne pile logicielle.

Ce que cela implique pour le prix

Rappelons le contexte tarifaire, qui a bougé depuis l’article initial. Le 23 octobre 2026, NVIDIA a mis en boutique un DGX Spark 64 Go à 4 999 dollars, tandis que la version 128 Go dépasse désormais les 6 000 dollars sur le marché (voir Frandroid et Clubic). Autrement dit, la configuration à 4 Sparks du study NVIDIA représente aujourd’hui un investissement de l’ordre de 24 000 dollars — pour 77,3 t/s en mono-session et une concurrence 16 tenable. C’est le prix de la souveraineté locale, mais il faut le savoir avant de comparer avec une API cloud facturée au token.

Le DGX Spark 64 Go, lui, change la donne pour Qwen3.8-27B : avec 18 Go de NVFP4, le modèle tient largement dans 64 Go, ce qui laisse de la marge pour le cache KV et un modèle draft. NVIDIA a d’ailleurs explicitement détaillé les tailles de modèles visées sur un ou deux systèmes, et cité un test Qwen 3.8 27B jusqu’à 1,7× plus rapide dans certaines configurations (voir NeoTeo et le blog NVIDIA). C’est cohérent avec les gains de décodage spéculatif mesurés.

Le préfill et le contexte long

L’article initial citait un préfill de 1078 t/s pour la 3.6 et « ~1100 t/s (estimé) » pour la 3.8. Les mesures du study NVIDIA ne publient pas de préfill isolé, mais les TTFT relevés (155 à 611 ms selon configuration, pour 128 tokens d’entrée) sont cohérents avec des débits de préfill de l’ordre du millier de tokens par seconde sur un seul Spark. Pour les contextes longs, les chiffres de 23-33 t/s jusqu’à 128K tokens restent plausibles avec MTP activé, mais ils n’ont pas été reproduits dans le study à ces longueurs — prudence donc sur les valeurs extrêmes.

Un point que l’article initial passait sous silence : la latence de queue. Le study ne la détaille pas dans l’extrait disponible, mais le critère de passage (TTFT < 1000 ms ET TPS ≥ 15) à concurrence 16 pour les meilleures configurations indique une stabilité raisonnable. Pour les charges agentiques, c’est ce couple TTFT/débit soutenu qui compte, pas le pic mono-session.

---

Qualité des réponses : ce qui est mesuré, ce qui est estimé

Les performances brutes ne font pas tout. La qualité des réponses est cruciale, et là encore, il faut distinguer le solide du spéculatif.

Sur MMLU, le chiffre de 84,46 % en NVFP4 provient de tests communautaires non recoupés, et aucun benchmark officiel Alibaba n’existe à ce jour pour la 3.8. Les estimations de ~86 % sur MMLU-Pro pour la 3.8 relèvent de la projection, pas de la mesure. Il faut le dire clairement : à l’automne 2026, la qualité de Qwen3.8-27B sur les benchmarks académiques n’est pas établie par des sources primaires.

C’est dans le domaine du code que la famille Qwen impressionne vraiment, selon des tests tiers. Un test indépendant mené par Vlad Makarov sur AI-Stat (18 mai 2026) a évalué la 3.6 sur un benchmark de refactoring single-file (300 à 1500 lignes) :

• Q4_K_M : 75 % de pass-rate
• Q5_K_M : 79 %
• FP8 (2 GPU) : 81 %

En comparaison, les modèles cloud atteignent des scores plus élevés : Claude Sonnet 4.6 à 91 %, GPT-5 Thinking à 89 %, Gemini 3.1 Pro à 86 %. Mais Qwen3.6-27B se hisse au niveau de modèles comme GPT-4o et devance largement les modèles locaux de taille inférieure. La 3.8 ajoute 3 à 5 points sur HumanEval et MBPP selon llm-stats.com, ce qui la place dans une zone de confort rare pour un modèle local.

Sur SWE-bench, qui teste la résolution de bugs multi-fichiers dans des repos GitHub, le modèle dense atteint 77,2 % selon PromptQuorum (mai 2026). Là encore, les modèles cloud culminent entre 82 et 87 %, mais la performance locale est remarquable.

Benchmark	Qwen3.6-27B (NVFP4/FP8)	Qwen3.8-27B (estimé)	Modèles cloud (meilleurs)
MMLU	84,46 %	~86 %	~90 %+
Refactoring single-file (FP8)	81 %	84–86 %	91 % (Claude Sonnet 4.6)
SWE-bench	77,2 %	~79 %	82–87 %

Mais le test le plus frappant vient du benchmark agentic. Le variant MoE de 35B (Qwen3.6-35B-A3B) a obtenu un score moyen de 91,0 ± 1,5 sur 84 scénarios de tool-calling, surpassant même Claude Opus 4.5 sur certains sous-tests. Le modèle dense 27B, lui, se situe juste en dessous, mais reste compétitif. Selon Wisely Chen, Qwen3.6-27B atteint un niveau « Sonnet 4.6-class » sur SWE-bench et Terminal-Bench, ce qui signifie qu’un agent de codage local peut désormais rivaliser avec les API cloud les plus chères.

Il faut toutefois tempérer : ces résultats proviennent de sources uniques (AI-Stat, PromptQuorum, Wisely Chen) et n’ont pas été reproduits de manière indépendante. La tendance est claire — la famille Qwen 3.6/3.8 est un excellent modèle de code local — mais les chiffres exacts doivent être maniés avec précaution.

Le contexte concurrentiel : MiMo-V2.6, Gemma 4, DeepSeek V4 Flash et les autres

La famille Qwen n’est plus seule sur le créneau du 27B dense. En avril 2026, Google a dévoilé Gemma 4 (27B), également dense mais avec une architecture d’attention classique. Puis, le 22 septembre 2026, Xiaomi a créé la surprise avec MiMo-V2.6. Et DeepSeek V4 Flash, dans sa version FP8, atteint des débits agrégés de ~350 tok/s à concurrence 32 sur 2 Sparks en TP=2 (vLLM), avec un single-stream de ~41 t/s et un préfill de ~1785 t/s — des chiffres qui, sur les charges concurrentes, dépassent largement Qwen3.8-27B. La comparaison n’est pas à l’avantage de Qwen sur le débit pur : DeepSeek V4 Flash est un MoE, donc structurellement plus rapide par token actif. Qwen3.8-27B reste compétitif sur la qualité de code et la simplicité de déploiement (un seul fichier de 18 Go).

Un autre acteur est apparu : AMD Ryzen AI Halo 192GB, lancé à 7 299,99 dollars chez Micro Center, capable de charger des modèles open-weight de 300 milliards de paramètres. Les benchmarks indépendants cités par TechTimes (14 octobre 2026) montrent toutefois que le DGX Spark reste devant en vitesse — la mémoire plus abondante de l’AMD ne compense pas la bande passante et l’écosystème logiciel de NVIDIA. Pour Qwen3.8-27B, qui tient dans 18 Go, l’avantage mémoire de l’AMD est sans objet.

---

Fine-tuning sur DGX Spark : ce que la stack permet vraiment

L’article initial n’abordait pas le fine-tuning, et c’est une lacune à combler tant le sujet est central pour un magazine tech. Que peut-on réellement entraîner sur un GB10 ?

La réponse courte : jusqu’à 70 milliards de paramètres en fine-tuning local selon les spécifications officielles du DGX Spark, et jusqu’à 200 milliards en inférence. Pour Qwen3.8-27B, cela signifie qu’un LoRA ou un QLoRA complet est parfaitement envisageable sur un seul Spark 128 Go, et a fortiori sur un 64 Go en QLoRA 4 bits. Les frameworks documentés par l’équipe Qwen — Axolotl, LLaMA-Factory — sont supportés, et le dépôt QwenLM/Qwen3 fournit les instructions de post-training (SFT, RLHF en TODO).

En pratique, plusieurs contraintes pèsent sur le fine-tuning d’un 27B sur GB10 :

• Mémoire : un fine-tuning full-parameter en BF16 du 27B exige ~108 Go rien que pour les poids, plus les gradients et les états de l’optimiseur — hors de portée d’un seul Spark. Le QLoRA 4 bits (poids quantifiés + adaptateurs BF16) tient en revanche dans 64 Go avec une marge confortable.
• Bande passante : les 273 Go/s de LPDDR5X limitent le débit d’entraînement. Un fine-tuning LoRA sur un dataset de quelques milliers d’exemples reste faisable en quelques heures, mais il ne faut pas espérer la vitesse d’un H100.
• Stack logicielle : le fine-tuning sur GB10 passe plutôt par PyTorch + PEFT/TRL que par vLLM (qui est un moteur d’inférence). La pile CUDA et DGX OS fournit les pilotes, mais les recettes d’entraînement spécifiques au GB10 restent moins documentées que celles d’inférence.

Pour les équipes qui veulent aller plus loin, le cluster de Sparks ouvre la voie au fine-tuning distribué (FSDP, DeepSpeed), mais les benchmarks publics sur ce cas d’usage sont rares à l’automne 2026. C’est un angle mort qu’il faudra combler.

---

Clusters DGX Spark : ce que deux, quatre ou huit nœuds changent vraiment

Le study NVIDIA est, à ce jour, la meilleure démonstration publique du scaling multi-Spark sur un modèle dense de 27B. Reprenons les faits mesurés.

Avec 2 Sparks (TP=2) : NVFP4 InferAct + MTP en vLLM officiel donne 23,4 t/s (C1) et tient C8. En vLLM eugr, on passe à 33,0 t/s et C16. En DSpark + SGLang, 51,8 t/s et C16. Le gain par rapport à un seul Spark varie donc de ×1,26 (vLLM officiel) à ×1,4 (DSpark) — loin du ×2 théorique, ce qui s’explique par les coûts de communication sur CX-7 (100 Gbps) et la nature dense du modèle, où chaque requête multiplie la même matrice de poids.

Avec 4 Sparks (TP=4) : DSpark + SGLang atteint 77,3 t/s en C1 et tient C16. C’est le meilleur résultat publié pour Qwen3.8-27B sur DGX Spark à ce jour. Le gain vs 2 Sparks est de ×1,49, cohérent avec un scaling sous-linéaire mais réel.

Ce que cela signifie pour les charges agentiques : à C16 avec TTFT < 1000 ms et TPS ≥ 15, un cluster de 4 Sparks peut servir seize agents simultanés avec une latence de première réponse sous la seconde. C’est le cas d’usage qui justifie vraiment le cluster — pas le mono-session, où un seul Spark suffit largement.

Les limites : le study ne teste pas 8 nœuds, et les benchmarks publics sur cette configuration restent à produire. La taille maximale de modèle supportée par 2 Sparks est documentée à 405 milliards de paramètres, ce qui laisse de la marge pour des MoE plus gros que Qwen3.8-27B. Mais pour un dense de 27B, 4 Sparks est déjà un plafond de rentabilité : au-delà, le gain par nœud s’effondre.

Un détail d’implémentation important : le study utilise sparkrun v0.3.4, un outil dédié à l’orchestration des Sparks. C’est un indice que l’écosystème logiciel se structure — on n’est plus à l’époque où il fallait tout câbler à la main. La pile DGX OS, CUDA, TensorRT-LLM, vLLM, Ollama et NIM forme désormais un socle cohérent, et les images eugr (spark-arena) apportent des optimisations que le vLLM officiel n’intègre pas encore.

---

Le MTP et DSpark : les vrais accélérateurs

L’article initial mentionnait le MTP comme un « accélérateur sous-exploité » avec un gain de 15 à 25 %. Les mesures du study NVIDIA réévaluent nettement ce chiffre à la hausse : sur Qwen3.8-27B, le MTP double le débit (×2,2 en BF16 comme en FP8), et le DSpark va jusqu’à ×3,8 par rapport au NVFP4 nu (36,6 vs 9,7 t/s). Ce n’est plus un gadget, c’est le levier principal.

Le mécanisme est simple : le décodage spéculatif fait prédire plusieurs tokens d’avance par un petit modèle draft (ici DSpark, 1,36B) ou par des têtes MTP intégrées, puis vérifie ces prédictions en batch avec le modèle principal. Sur un modèle dense où chaque token coûte une lecture complète des poids, cette vérification groupée amortit le coût et multiplie le débit effectif.

Les précautions restent celles de l’article initial : le décodage spéculatif consomme de la mémoire pour le cache des prédictions auxiliaires, et le taux d’acceptation des tokens draft varie selon la tâche. Sur du code très prévisible, le gain est maximal ; sur de la génération créative, il diminue. Le study ne publie pas les taux d’acceptation par tâche, ce qui serait la prochaine mesure à produire.

---

Quelle recette choisir en octobre 2026 ?

Au terme de cette revue, voici ce que les sources permettent d’affirmer, sans extrapolation.

Pour un développeur solo sur un DGX Spark 128 Go : NVFP4 (RadixArk) + DSpark en SGLang, TP=1. C’est la configuration qui offre le meilleur débit mono-session (36,6 t/s) avec un TTFT de 246 ms. Alternative plus simple : NVFP4 InferAct + MTP en vLLM officiel (18,5 t/s, C8), qui demande moins de réglages.

Pour un petit collectif sur 2 Sparks : NVFP4 (RadixArk) + DSpark en SGLang, TP=2 (51,8 t/s, C16). C’est le meilleur rapport performance/complexité pour des charges agentiques.

Pour une équipe sur 4 Sparks : NVFP4 (RadixArk) + DSpark en SGLang, TP=4 (77,3 t/s, C16). Le plafond actuel, à réserver aux charges réellement concurrentes.

Ce qu’il faut éviter : le BF16 nu (4,5 t/s) et le NVFP4 sans décodage spéculatif (9,7 t/s), qui sous-exploitent massivement le matériel. Ce sont pourtant les configurations par défaut de nombreux tutoriels — d’où l’importance de lire les benchmarks avant de déployer.

Le DGX Spark 64 Go à 4 999 dollars change la donne pour Qwen3.8-27B : avec 18 Go de NVFP4, le modèle laisse 46 Go pour le cache KV et le draft, ce qui suffit pour les configurations ci-dessus en mono-nœud. Pour le cluster, il faudra arbitrer entre quatre Sparks 64 Go (économie) et deux Sparks 128 Go (moins de nœuds à orchestrer).

---

Sources

• Comprehensive Qwen3.8-27B Study on DGX Sparks: Quantization, Speculative Decoding, and TP/DP Scaling — forums développeurs NVIDIA (study 11 configurations, 1 à 4 Sparks)
• QwenLM/Qwen3 — dépôt officiel Qwen, documentation post-training et variantes 2507
• Qwen3.8-27B on a Single DGX Spark — Measured Benchmarks — benchmarks mono-Spark
• Putting Qwen3.8-27B to Work on a DGX Spark — Todd Espy, retour d’expérience
• Qwen3.8 27B on DGX Spark: benchmarks — AxForge
• NVIDIA DGX Spark 64GB Gives Developers More Ways to Build and Scale Local AI — blog NVIDIA, 2 octobre 2026
• DGX Spark 64 Go : NVIDIA annonce une configuration — NeoTeo, 3 octobre 2026 (test Qwen 3.8 27B jusqu’à 1,7×)
• Nvidia lance le DGX Spark en 64 Go : faut-il acheter deux petits plutôt qu’un gros ? — Frandroid, 2 octobre 2026
• NVIDIA lance un DGX Spark 64 Go : moins de mémoire, mais une drôle d’astuce pour dépasser le modèle 128 Go — Clubic, 2 octobre 2026
• Le DGX Spark Perd La Moitié De Sa Mémoire Mais Conserve Son Tarif De 4 999 Dollars — Pause Hardware, 2 octobre 2026
• AMD Ryzen AI Halo 192GB Loads Models No Rival Can: DGX Spark Still Wins on Speed — TechTimes, 14 octobre 2026
• The Best DGX Spark for Local AI in 2026: LLM Speed, Model Sizes, and Clusters, With Sources — Pyshine, 1er octobre 2026
• NVIDIA DGX Spark specifications et usages — SysKB (fine-tuning jusqu’à 70B, inférence jusqu’à 200B)
• sparkrun — outil d’orchestration multi-Spark v0.3.4
• CordatusAI LLM Benchmark Tool — outil de mesure utilisé dans le study NVIDIA