Qwen 3.6 27B et 35B MTP par rapport au standard sur GPU 16 Go

J’ai testé les performances de la décodage spéculatif (Multi-Token Prediction, MTP) sur les modèles Qwen 3.6 27B et 35B avec une RTX 4080 dotée de 16 Go de VRAM.

Pour une vue d’ensemble des débits de tokens et des compromis en termes de VRAM sur un plus grand nombre de modèles utilisant le même matériel, consultez Les benchmarks LLM pour 16 Go de VRAM avec llama.cpp.

Qu’est-ce que le MTP (Multi-Token Prediction) ?

La prédiction multi-token (MTP) est une forme de décodage spéculatif intégrée directement dans certains points de contrôle (checkpoints) de modèles. Au lieu de prédire un seul token par passage avant, le modèle possède des « têtes MTP » supplémentaires qui proposent plusieurs futurs tokens en une seule étape, puis les vérifient en parallèle. Si les conjectures sont acceptées, le débit effectif augmente sans altérer la qualité de la sortie.

La famille Qwen 3.6 est livrée avec des fichiers GGUF standards et des variantes activées pour le MTP. Dans llama.cpp, le MTP est activé via :

--spec-type draft-mtp --spec-draft-n-max 3

--spec-draft-n-max est le paramètre clé d’ajustement. Il détermine combien de tokens spéculatifs la tête MTP propose à chaque étape. Des valeurs plus élevées offrent un potentiel d’accélération mais consomment davantage de VRAM pour les tampons de brouillon (draft buffers) — une contrainte réelle sur les cartes de 16 Go.

Ce que j’ai testé et comment

J’ai testé le comportement des deux modèles Qwen 3.6 avec le MTP activé par rapport au décodage standard sur un GPU avec 16 Go de VRAM (RTX 4080).

Pour faire tenir les poids du modèle et le cache KV dans la VRAM, j’ai utilisé des variantes fortement quantifiées :

• Qwen3.6-27B-UD-IQ3_XXS et Qwen3.6-27B-UD-IQ3_XXS-MTP
• Qwen3.6-35B-A3B-UD-IQ3_S et Qwen3.6-35B-A3B-UD-IQ3_S-MTP

Deux budgets de contexte sont suivis par exécution :

• Ctx Moy — la taille du contexte à laquelle llama.cpp occupe ~14,8 Go de VRAM, laissant aux autres applications (Xorg, GNOME Shell, Cursor) une marge confortable d’environ 500 Mo.
• Ctx Max — le plus grand contexte que llama.cpp puisse allouer étant donné que les mêmes applications de bureau occupent déjà ~500 Mo de VRAM.

Une raison importante de maintenir le contexte moyen à un objectif pratique est que l’Agent Hermes — que j’utilise comme assistant AI principal connecté à llama.cpp sur cette machine — nécessite au minimum un contexte de 64 K par défaut et rejettera les modèles avec une fenêtre plus petite au démarrage. Les modèles en dessous de ce seuil ne peuvent pas maintenir une mémoire de travail suffisante pour les flux de travail d’appel d’outils en plusieurs étapes. Pour llama.cpp, cela signifie passer --ctx-size 65536 ou plus. Toute configuration MTP qui compresse le contexte utilisable moyen bien en dessous de 64 K est donc inadaptée aux charges de travail quotidiennes d’Hermes, ce qui explique pourquoi les chiffres du Ctx Moy dans les tableaux ci-dessous sont les plus pertinents pour la prise de décision.

Les deux niveaux de quantification du cache KV ont été testés : q8 (qualité supérieure, plus de VRAM) et q5 (moins de VRAM, contexte plus long). Sachez que passer du cache KV q8 à q5 peut entraîner une baisse notable de la qualité — lors de mes tests, la dégradation était suffisamment significative pour rendre q5 inadapté à mes charges de travail. Les chiffres de vitesse et de contexte pour q5 sont inclus pour exhaustivité, mais vous devriez tester la qualité des réponses sur vos propres tâches avant de vous y engager.

Qwen 3.6 27B MTP vs Standard

Cache KV q8

Avec un cache KV q8, le MTP à --spec-draft-n-max 2 offre une génération ~67 % plus rapide (75 vs 45 t/s) au prix d’une réduction de moitié de la fenêtre de contexte moyenne, passant de 80 K à 40 K. La vitesse d’ingestion du prompt chute de 200 à ~150 t/s car le MTP nécessite des transferts périphérique-hôte pendant la phase de préremplissage (prefill).

Cache KV q5

Le passage au cache KV q5 récupère un contexte significatif : --spec-draft-n-max 1 donne un contexte moyen de 70 K à 57 t/s — une accélération de génération de 39 % par rapport au décodage standard, tout en conservant la fenêtre de contexte à une taille utile. À --spec-draft-n-max 3, le contexte chute à 60 K mais la génération atteint 67 t/s (+63 %).

Bilan Qwen 3.6 27B

Le MTP est véritablement utile pour le modèle dense 27B. Le compromis idéal sur 16 Go de VRAM est :

• Cache KV q8 + --spec-draft-n-max 2 — vitesse brute maximale (75 t/s), contexte réduit à 40–60 K
• Cache KV q5 + --spec-draft-n-max 1 — meilleur équilibre vitesse/contexte (57 t/s, contexte moyen 70 K)

Qwen 3.6 35B MTP vs Standard

Le modèle 35B utilise une architecture Mixture-of-Experts (MoE) (35B-A3B signifie 35B de paramètres totaux, ~3B actifs par token). Les modèles MoE bénéficient généralement plus du MTP car le routage.sparse garde la tête MTP computationnellement peu coûteuse par rapport à un passage avant complet.

Cache KV q8

L’architecture MoE offre une vitesse de génération brute impressionnante avec le MTP (+27 % à max 1, +29 % à max 2 vs le standard 146 t/s). Mais le problème pratique est le contexte moyen. Avec un cache KV q8, même --spec-draft-n-max 1 ne donne que 15 K de contexte moyen — à peine suffisant pour des tâches modérées. Les profondeurs de brouillon plus élevées n’ont tout simplement aucun contexte moyen viable sur une carte 16 Go.

C’est la question centrale du coût en VRAM du MTP sur le matériel grand public : les tampons de brouillon supplémentaires réduisent directement le budget VRAM restant, et le modèle 35B-A3B avec un cache KV q8 laisse très peu de marge.

Cache KV q5

Le cache KV q5 n’améliore que marginalement la situation du contexte moyen. --spec-draft-n-max 1 donne un contexte moyen de 10 K à 151 t/s. Le décodage standard à q5 offre 122 t/s avec un contexte moyen de 120 K.

Bilan Qwen 3.6 35B

Sur un GPU 16 Go, le modèle MoE 35B avec MTP fait face à un mur : le contexte utilisable moyen s’effondre à 10–15 K tokens, ce qui le rend impraticable pour les charges de travail réelles. Le décodage standard à 122–146 t/s avec un contexte de 80–120 K est nettement plus utile.

Si vous disposez de 24 Go de VRAM ou plus, la combinaison 35B + MTP devient beaucoup plus attractive — le problème de la fenêtre de contexte disparaît et vous conservez l’avantage en vitesse.

Choisir la bonne valeur pour --spec-draft-n-max

La question de savoir combien de tokens spéculatifs proposer par étape (--spec-draft-n-max) n’a pas de réponse unique — elle dépend à la fois de l’architecture du modèle et de la VRAM disponible :

• Pour le dense 27B sur 16 Go : --spec-draft-n-max 2 avec un cache KV q8 est le plus rapide, --spec-draft-n-max 1 avec un cache KV q5 est le plus favorable au contexte.
• Pour le MoE 35B sur 16 Go : --spec-draft-n-max 1 est la seule option qui conserve un contexte utilisable, et encore de manière marginale.
• Les valeurs plus élevées (3, 4) augmentent la pression sur la VRAM sans gains de vitesse proportionnels — à max 4, vous consommez à peu près la même quantité supplémentaire de VRAM qu’à max 2, mais la vitesse de génération ne suit pas.

Comment activer le MTP dans llama.cpp

Assurez-vous d’utiliser un GGUF activé pour le MTP (le nom du fichier contient MTP). Si vous découvrez les drapeaux (flags) de llama.cpp, le Guide de démarrage rapide de llama.cpp avec CLI et Serveur couvre tous les fondamentaux. Ensuite, lancez llama-server ou llama-cli avec :

llama-server \
  --model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \
  --ctx-size 40000 \
  -ngl 99 --flash-attn on \
  --cache-type-k q8_0 --cache-type-v q8_0 \
  --spec-type draft-mtp \
  --spec-draft-n-max 2

Pour un cache KV q5, remplacez q8_0 par q5_1 ou q5_0 et augmentez --ctx-size :

llama-server \
  --model Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf \
  --ctx-size 80000 \
  -ngl 99 --flash-attn on \
  --cache-type-k q5_1 --cache-type-v q5_1 \
  --spec-type draft-mtp \
  --spec-draft-n-max 1

Le MTP est activé automatiquement une fois que llama.cpp détecte les têtes MTP dans le fichier GGUF et que --spec-type draft-mtp est défini. Ainsi, le fichier standard Qwen3.6-27B-UD-IQ3_XXS.gguf ne fonctionnera pas en mode MTP ; vous aurez besoin de Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf. Mais le fichier Qwen3.6-27B-UD-IQ3_XXS-MTP.gguf peut fonctionner en mode décodage spéculatif comme en mode autorégressif.

Conclusion

Sur un GPU 16 Go (RTX 4080), avec ces quantifications, le MTP de llama.cpp est un avantage clair pour Qwen 3.6 27B et un bilan négatif pour Qwen 3.6 35B dans un usage pratique :

Qwen 3.6 27B (IQ3_XXS) — Le MTP vaut le coup :

• Cache KV q8 + MTP max 2 → ~67 % de génération plus rapide, contexte 40–60 K (vs 80–100 K sans MTP)
• Cache KV q5 + MTP max 1 → ~39 % de génération plus rapide, contexte 70–100 K (vs 130–160 K sans MTP)
• Bon équilibre entre vitesse et efficacité VRAM à --spec-draft-n-max 2

Qwen 3.6 35B (IQ3_S) — Le MTP n’est pas pratique à 16 Go :

• La vitesse de génération est 27–29 % plus élevée, mais le contexte moyen s’effondre à 10–15 K en q8, 10 K en q5
• Le décodage standard à 122–146 t/s avec un contexte de 80–120 K est plus utile pour des tâches réelles
• La situation s’améliore considérablement sur 24 Go de VRAM ou plus

Sur le papier, le cache KV q5 est la réponse évidente pour maximiser la fenêtre de contexte tout en conservant les gains de vitesse du MTP — mais en pratique, la baisse de qualité en passant de q8 à q5 peut être significative. Testez le q5 sur vos propres tâches avant de l’adopter ; pour mes charges de travail, la dégradation était inacceptable, et le q8 avec un budget de contexte plus serré reste le meilleur compromis.

Pour une vue d’ensemble des options d’hébergement LLM et des compromis infrastructurels, consultez les rubriques Hébergement LLM en 2026 et Performance LLM en 2026. Si vous ajustez les paramètres de l’échantillonneur (sampler) de Qwen 3.6 en parallèle du MTP, la Référence des paramètres d’inférence pour systèmes agencés Qwen 3.6 et Gemma 4 est un complément utile.