DFlash 2 — 3× plus de tokens sur Qwen3.8-27B, même sortie

J’ai écrit Qwen 3.8 27B parce que le modèle est enfin assez bon pour rester en local. Le plafond suivant n’est plus la qualité — c’est le débit. Un agent qui lit, planifie et appelle des outils pendant des heures consomme des tokens à un rythme que le chat n’a jamais atteint. Chaque token, en décodage classique, coûte un forward pass complet. DFlash 2 (Inco AI, 18 août 2026) attaque exactement ça : draft parallèle + vérif en un pass, sortie prouvée identique au modèle cible.

L’article Inco AI →

Pourquoi ça m’intéresse

Sur un 27B, le bottleneck n’est plus « est-ce que le modèle est assez fort » — c’est « est-ce que je peux le servir assez vite pour un agent ». DFlash 1 (janvier 2026) est déjà dans SGLang, vLLM, TensorRT-LLM et llama.cpp : NVIDIA a mesuré jusqu’à 15× de throughput sur Blackwell, Google 3× de tok/s sur TPU, et le endpoint CoreWeave Kimi K2.7 Code — le plus rapide du modèle sur Artificial Analysis — tourne DFlash par défaut. 3,5 M de downloads Hugging Face. DFlash 2 n’invente pas un nouveau stack : il récupère le slack encore dans le draft parallèle.

• Le draft n’est plus autoregressif : tout le bloc, toutes les positions, en un pass.
• DFlash 2 : +16–25 % d’acceptance length vs DFlash, ~1 % de latence de cycle en plus.
• Sur Qwen3.8-27B : 2,7–3,4× le throughput autoregressif (batch 1), même texte.
• Deux drafters le jour J : incoai/Qwen3.8-27B-DFlash2 et Muse Glimmer.

L’idée, sans le papier

Le speculative decoding classique : un petit modèle devine un bloc, le gros vérifie le bloc en un forward. Bonnes guesses → plusieurs tokens pour un pass. Mauvaises → on jette. Pendant des années le draft lui-même restait un token à la fois. DFlash a rendu le draft one-pass. DFlash 2 corrige les deux fuites qui restaient : mauvais choix parmi de bons candidats, et suffix decay (la fin du bloc pourrit).

Chiffre qui m’a convaincu : sur un DFlash 5 couches (Qwen3-4B, GSM8K), le top-1 est juste 85,4 % du temps en position 0 — mais le bon token est dans le top 16 à 99,5 %. Le problème n’est pas « le drafter ne sait pas ». C’est sélectionner un chemin cohérent dans des listes déjà bonnes. Un oracle top-16 ferait passer l’acceptance de 4,27 → 6,79. DFlash 2 pose un sélecteur de paires (+2 M params, +0,6 % latence) plutôt qu’une tête autoregressive type DSpark (+77,8 M, +9,6 %). *Choosing is cheaper than predicting.*

Le suffix decay, eux le traitent comme un problème local : une conv deux taps (style Canon / short conv) avant/après chaque attention et MLP. +3 % de params, +0,7 % de latence, et un 5 couches rattrape presque un 15 couches. Ensemble, sélecteur + conv = +1,3 % de cycle pour +1 token accepté par pass en moyenne.

Les chiffres qui comptent sur Qwen3.8-27B

C’est le drafter que je viserais. Comparé au MTP natif du modèle et à un DSpark communautaire, sur les benches Inco (block 8, sampling officiel Qwen) :

• Acceptance mean : MTP 4,28 · DSpark 3,62 · DFlash 2 4,80.
• GSM8K : 5,46 vs MTP 5,02. MATH-500 : 5,28 vs 4,72. MBPP : 4,79 vs 3,99.
• Throughput batch 1 (H200, SGLang, model card) : 2,67–3,43× vs autoregressif — 184 à 236 tok/s là où l’AR plafonne ~69.
• Concurrency 8 : encore 2,3–2,8×. À 32, le gain se tasse (1,0–1,45×) — normal : le batch remplit déjà le GPU.
• Muse Glimmer : 3,1–4,6×, mean 5,70 vs DFlash officiel 4,44.

Lossless : greedy = exactement le target ; sampling via rejection sampling = même distribution. Tu n’échanges pas de la qualité contre du débit. Tu paies ~1 % de cycle pour un token de plus par vérif.

Le lancer

Déjà branché dans SGLang, vLLM (PR), llama.cpp (PR), Ollama (PR) et oMLX. Le chemin le plus court aujourd’hui, c’est SGLang + le drafter Hub :

pip install "sglang[all] @ git+https://github.com/sgl-project/sglang.git#subdirectory=python"

python -m sglang.launch_server \
  --model-path Qwen/Qwen3.8-27B \
  --speculative-algorithm DFLASH \
  --speculative-draft-model-path incoai/Qwen3.8-27B-DFlash2 \
  --speculative-num-draft-tokens 8

• vLLM : method: dflash, num_speculative_tokens: 7 — encore sur une PR (vllm#52816).
• llama.cpp : --spec-type draft-dflash + GGUF incoai/Qwen3.8-27B-DFlash2-GGUF.
• Mac : oMLX (prebuilt) ou Ollama expérimental, draft incoai/Qwen3.8-27B-DFlash2 sur un target MLX 4-bit.
• Le drafter n’est pas un LLM autonome (~2B). Il ne sert que dans un serveur speculatif.

Où ça se branche chez moi

Sur le serveur Qwen 3.6 et le 3.8 en Studio / MLX, le coût réel d’un agent c’est le tok/s × durée de boucle. 3× en batch 1, c’est une session Hermes / MCP qui tient dans la même fenêtre au lieu de timeout. À haute concurrence le gain fond — si tu sers déjà un batch plein, DFlash 2 n’est pas magique. Si tu sers un agent à la fois (le cas local / une carte), c’est le levier.

Takeaway

DFlash 2 n’est pas un nouveau modèle. C’est un drafter qui rend le 27B que tu as déjà utilisable en agent sans changer une ligne de prompt ni la distribution de sortie. Inco le dit clairement : l’inférence n’a pas encore touché le plancher. Pour moi le test concret, c’est brancher incoai/Qwen3.8-27B-DFlash2 sur le même Qwen3.8 que je sers déjà — et mesurer le tok/s, pas le blog.

• Source : inco.ai/blog/dflash2/
• Drafter : huggingface.co/incoai/Qwen3.8-27B-DFlash2
• Qwen 3.8 : /blog/qwen-3-8-27b
• Local Studio : /blog/unsloth-studio