Qwen3.8-27B en local : 262 144 tokens de contexte sur une seule machine
Publié le 13 août 2026 sous licence Apache 2.0, Qwen3.8-27B offre un contexte natif de 262 144 tokens, si bien que le contexte long n'est plus réservé aux baies GPU. Voici le dimensionnement réel, carte par carte.
Ce qui change avec Qwen3.8-27B
Qwen3.8-27B est un modèle dense de 27 milliards de paramètres (tous actifs, sans mixture d'experts), publié par Alibaba le 13 août 2026 sous licence Apache 2.0, avec un encodeur visuel natif (images et vidéos jusqu'à l'échelle de l'heure). Sur les benchmarks, il s'installe devant des modèles plus gros sur le code agentique : 61,7 sur SWE-bench Pro (contre 53,4 à Opus 4.6 Max dans la même évaluation), 90,3 sur LiveCodeBench v6, et 84,3 sur OSWorld-Verified pour l'usage ordinateur. Le mode de raisonnement est réglable par requête (reasoning_effort), activé par défaut.
Mais pour un déploiement sur site, la donnée la plus structurante est ailleurs : le contexte natif passe à 262 144 tokens, extensible à 1 million via YaRN, et surtout le coût mémoire de ce contexte a fondu. C'est ce second point qui décide de la facture hardware.
Pourquoi le cache KV devient (presque) abordable
Dans un modèle d'attention classique, chaque token du contexte occupe en permanence de la mémoire : le cache KV, dont nous détaillions le mécanisme dans notre article sur prefill, decode et cache KV. Pour un dense 27B full-attention, ce cache devient rapidement le poste dominant dès que le contexte dépasse quelques dizaines de milliers de tokens.
Qwen3.8-27B évite une partie de ce piège par son architecture, puisque ses 64 couches suivent un motif hybride : 16 blocs composés chacun de trois couches Gated DeltaNet (attention linéaire) puis d'une couche d'attention complète. Résultat : seules 16 couches sur 64, soit un quart, alimentent un cache KV croissant, tandis que les 48 couches linéaires maintiennent un état récurrent constant, d'environ 75 Mo au total, quelle que soit la longueur du contexte.
Le calcul donne 64 Kio par token en FP16 (2 × 4 têtes KV × 256 dimensions × 16 couches × 2 octets), soit 32 Kio en FP8, ce qui représente environ quatre fois moins qu'un modèle dense équivalent entièrement en attention.
| Contexte | Cache KV FP16 | Cache KV FP8 |
|---|---|---|
| 32 768 tokens | 2 Go | 1 Go |
| 131 072 tokens | 8 Go | 4 Go |
| 262 144 tokens (natif) | 16 Go | 8 Go |
| 524 288 tokens (YaRN ×2) | 32 Go | 16 Go |
| 1 048 576 tokens (YaRN ×4) | 64 Go | 32 Go |
À noter : le cache KV se paie par requête concurrente, puisque servir quatre utilisateurs simultanés à 262 144 tokens en FP8 demande 32 Go de cache en plus des poids. Le dimensionnement d'une plateforme de service doit donc raisonner en (poids + N × cache), pas seulement en poids.
Poids + cache : le dimensionnement réel
Les poids occupent environ 62,1 Go en FP16 (vision comprise), 29 Go en FP8 et 15,5 Go en NVFP4. En croisant avec le catalogue matériel, quatre profils ressortent :
- Carte 24 Go (RTX 3090/4090) : NVFP4 ou Q4, contexte court à moyen. Des retours communautaires sur RTX 3090 font état d'environ 43 tokens/s en Q4_K_XL avec décodage spéculatif MTP, pour 19 Go de VRAM. La carte convient alors à un poste de travail mono-utilisateur.
- DGX Spark, 128 Go unifiés : FP8 complet + 262 144 tokens de contexte natif, avec de la marge pour quelques requêtes concurrentes. Le premier palier où le contexte natif s'exploite réellement. Détail : Qwen 3.8 27B sur DGX Spark.
- Mac Studio Ultra, 512 Go : FP16 intégral à contexte maximal, ou FP8 avec forte concurrence. Détail : Qwen 3.8 27B sur Mac Studio Ultra.
- RTX PRO 6000 (768 Go) ou serveur SXM : FP8 + YaRN ×4 pour approcher le million de tokens, en conservant des batches confortables. Détails : RTX PRO 6000 et H200 SXM.
Le servir : moteurs et réglages
Les moteurs officiellement recommandés sont vLLM, SGLang et TokenSpeed, chacun avec une recette dédiée, et au-delà de 262 144 tokens l'extension passe par YaRN : un facteur 2 suffit pour 524 288 tokens et préserve mieux les performances que le facteur 4 du million. Attention, le YaRN des moteurs open source est statique : activé en permanence, il peut dégrader légèrement les contextes courts, ce qui invite à ne le configurer que si vos charges l'exigent.
Deux réglages méritent d'être connus dès le départ : preserve_thinking, activé par défaut, conserve le raisonnement des tours précédents et améliore la réutilisation du cache entre les tours d'une session agentique ; et le budget de sortie recommandé est généreux (jusqu'à 262 144 tokens de raisonnement, 131 072 de réponse). Prévoyez cette marge dans la fenêtre de contexte.
Le point llama.cpp / GGUF
Des conversions GGUF existent dès maintenant (unsloth propose notamment Q4_K_XL et Q6_K, avec des drafts MTP pour le décodage spéculatif), mais méfiez-vous des builds anciens : un bug dans les kernels CUDA des couches DeltaNet produisait des sorties totalement corrompues, sans erreur ni ralentissement visible. Si vous passez par llama.cpp, utilisez un build récent et vérifiez que les bibliothèques libggml-cuda chargées sont à jour. Pour une plateforme de production, restez sur vLLM ou SGLang : les performances sur cette architecture hybride y sont nettement supérieures.
Ce qu'il faut retenir
Qwen3.8-27B rend le contexte long compatible avec du matériel de bureau : 262 144 tokens coûtent 16 Go de cache KV en FP16, et une machine unifiée de 128 Go couvre modèle FP8 + contexte natif. Pour les charges agentiques longues (revues de code base entière, analyse documentaire, sessions d'automatisation), c'est le premier modèle ouvert de cette taille où la fenêtre de contexte n'impose plus l'architecture du serveur. Le dimensionnement précis, machine par machine, est détaillé dans nos fiches dimensionnement.
Sources : la fiche de modèle Qwen3.8-27B sur Hugging Face, dont sont tirés le nombre de paramètres, la longueur de contexte native et la configuration d'attention, et la documentation de llama.cpp pour les formats GGUF.
Questions fréquentes
Quel matériel pour faire tourner Qwen3.8-27B en local ?
En quantification 4 bits (Q4_K_XL ou NVFP4), le modèle tient dans environ 15,5 à 19 Go : une carte 24 Go comme une RTX 3090 ou 4090 suffit pour un contexte court. Pour exploiter les 262 144 tokens natifs, comptez la mémoire des poids plus 16 Go de cache KV en FP16 (8 Go en FP8) : une machine 128 Go comme un DGX Spark couvre l'ensemble en FP8.
Quel est le cache KV de Qwen3.8-27B ?
64 Kio par token en FP16 et 32 Kio en FP8, soit 16 Go pour 262 144 tokens en FP16. Cette valeur basse vient de l'architecture hybride : seules 16 des 64 couches utilisent l'attention complète, les 48 autres (Gated DeltaNet) maintiennent un état constant d'environ 75 Mo, indépendant de la longueur du contexte.
Qwen3.8-27B fonctionne-t-il avec llama.cpp ou Ollama ?
Des conversions GGUF existent (unsloth) et llama.cpp le prend en charge, mais exigez un build récent : les anciens kernels CUDA des couches DeltaNet produisaient des sorties corrompues sans erreur visible. Pour un usage sérieux, les moteurs recommandés par Qwen sont vLLM, SGLang et TokenSpeed, nettement plus rapides sur cette architecture.