Pourquoi DFlash sur Qwen3.6-27B ne tient pas sur 24 Go single GPU

Salut les amis !

Aujourd’hui un post un peu différent : je vais vous expliquer pourquoi un truc ne marche pas. Plus précisément : pourquoi DFlash (Block Diffusion for Flash Speculative Decoding, ICLR 2026) — qui annonce un délicieux 207 t/s sur Qwen3.5-27B en RTX 3090 24 Go — ne tient pas sur l’Olares One. C’est presque 3× notre meilleur Turbo (60 t/s sur le même hardware en consumer Blackwell). Évidemment j’ai voulu reproduire. Spoiler : ça ne tient pas, et ce n’est pas un problème de tuning, c’est juste de la math VRAM. Allez, on regarde ensemble.

La math, déjà

Sur Olares One (RTX 5090M 24 Go GDDR7), HAMI vGPU expose 23.42 GiB utilisables au pod après les réservations système.

Pour faire tourner DFlash sur Qwen3.6-27B, il faut héberger en VRAM le target + le drafter + les buffers/activations + le KV cache. Voilà le budget :

Composant	Taille
Target Qwen3.6-27B BF16	51 GiB
Target Qwen3.6-27B FP8	27 GiB
Target Lorbus AutoRound INT4	17 GiB
Drafter z-lab/Qwen3.6-27B-DFlash (5-layer Qwen3 BF16)	~6 GiB
Activations + cudagraph buffers	2-3 GiB
KV cache (au minimum 8K context)	1-2 GiB
Total minimum	~26-28 GiB

L’élément qu’on sous-estime, c’est le drafter. “5-layer Qwen3” ça sonne tout petit, mais chaque couche d’un Qwen3-27B fait ~1.2 GiB en BF16 à cause de la dim cachée et des projections QKVO + FFN. Cinq couches × 1.2 GiB = 6 GiB. Et le drafter doit rester en BF16 parce que c’est l’entraînement officiel z-lab — pas de quant pour l’instant. Bref, on est cuits avant d’avoir commencé.

Les tests menés

J’ai quand même essayé plusieurs paths, par acquis de conscience. Voilà le récap.

Path 1 : vLLM stock + drafter z-lab (le path “officiel”)

vllm serve Qwen/Qwen3.6-27B \
  --speculative-config '{"method":"dflash","model":"z-lab/Qwen3.6-27B-DFlash","num_speculative_tokens":15}' \
  --attention-backend flash_attn \
  --max-num-batched-tokens 32768

Avec Qwen/Qwen3.6-27B BF16 (51 GiB) en target, c’est immédiatement OOM dès le model loading. Évidemment.

J’ai swap target → Lorbus/Qwen3.6-27B-int4-AutoRound (17 GiB). Le model load passe. Et puis :

torch.OutOfMemoryError: CUDA out of memory.
Tried to allocate 2.37 GiB. GPU 0 has a total capacity of 23.42 GiB
of which 266.38 MiB is free. Including non-PyTorch memory,
this process has 23.28 GiB memory in use.

Le drafter prend 6 GiB qu’on n’a plus. Réduire max-model-len à 16K ne change rien — l’OOM est sur les poids (target + drafter), pas sur le KV cache. Pas le bon levier.

J’ai tenté gpu_memory_utilization 0.85 et --enforce-eager (skip cudagraph alloc). Toujours 22.86 GiB allocated dès le model loading. La memory profiler de vLLM se réserve l’espace en amont, donc bidouiller le target context ne libère pas grand-chose. Suivant !

Path 2 : AEON-7 NVFP4 (taillé pour Blackwell)

AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored-DFlash annonce une variante NVFP4 (26 Go) avec docker-compose pour DGX Spark / RTX PRO 6000 Blackwell. Targeted at Blackwell hardware, donc je me suis dit “tiens, ça pourrait passer”. Premier réflexe naïf : 26 Go c’est plus petit que 51 Go BF16, peut-être que ça rentre ?

Vérification dans leur README. Ils sont honnêtes :

“Anything older than A100” / “Not supported” / “51 GB BF16 or 26 GB NVFP4 will not fit.”

Le 26 Go NVFP4 ne fit déjà pas sur du 24 Go consumer. Leur path explicit est DGX Spark (sm_121a) ou RTX PRO 6000 Blackwell 96 Go. Pas pour nous, malheureusement. Bref, KO.

Path 3 : Lucebox custom engine

Luce-Org/lucebox-hub (MIT) a un port DFlash GGUF qui fait 78 t/s sur Qwen3.6-27B sur RTX 3090 24 Go. Là je tilte : comment ils tiennent dans 24 Go alors que vLLM ne tient pas ?

Réponse : ils utilisent Q4_K_M target (17 GiB) + TQ3_0 KV cache (TurboQuant 3-bit, GGUF) et leur fork Luce-Org/llama.cpp@luce-dflash avec custom tree-mode operations. Le drafter est intégré différemment (pas un model BF16 de 6 Go full). Bref, ils ont fait du sale, mais du sale qui marche.

Mais — et c’est un gros mais — pas de Docker public, pas de binary release. C’est research-grade : il faut compiler le fork llama.cpp + dflash + megakernel à la main, par GPU cible. Ça vaut un post séparé (et une session dédiée) pour packager ça en image Docker exploitable sur Olares K8s. Et sm_120 n’a pas été testé par l’équipe Luce, ils visent du Ampere / Ada. À suivre !

Ce qu’il faudrait pour débloquer le 24 Go consumer

Je vois trois pistes pour qu’un jour DFlash tourne en 24 Go single-GPU :

Un drafter quantizé — un z-lab/Qwen3.6-27B-DFlash-FP8 (3 GiB) ou -INT4 (1.5 GiB) à la place du BF16 actuel. Ça libère 3-5 GiB et le path vLLM stock devient viable. À ma connaissance personne ne l’a publié. Si vous voyez passer ce quant quelque part, faites-moi signe !
Ou Lucebox packagé — image Docker reproductible, support sm_120 confirmé. Project en cours côté blog.
Ou un target FP8 plus serré — le target Qwen/Qwen3.6-27B-FP8 fait 27 Go, juste hors budget. Une variante “fp8-mixed” qui descend à 22-23 Go laisserait 1-2 Go pour drafter mini-quantizé. Pas vu dans la wild non plus.

TL;DR

DFlash sur 24 Go consumer GPU = impossible avec les paths publics actuels (Q1 2026). Le drafter z-lab BF16 fait 6 GiB qui ne fittent pas après le target Lorbus INT4 17 GiB + buffers. Les solutions du futur : drafter quantizé (pas dispo) ou Lucebox packagé en Docker (work-in-progress de mon côté).

En attendant, ne vous mettez pas en boule : Turbo (TurboQuant 4bit_nc + MTP n=3 + Genesis Sandermage) fait 60 t/s avg / 73 peak sur la même carte, c’est notre meilleur DFlash-équivalent open-stack sur 24 Go. Tout est détaillé dans le post précédent — allez voir si ce n’est pas déjà fait.

Crédits

z-lab/dflash pour la méthode (block diffusion drafter, parallel drafting, 207 t/s claim)
AEON-7 pour l’image vLLM Blackwell + le README honnête sur les hardware floor
Luce-Org pour le port GGUF 24 Go single-GPU. À suivre côté Docker packaging.

Voilà ! Si vous tournez sur 5090M, 4080M ou 3090 24 Go et que vous arrivez à faire fitter DFlash dans le budget, je veux absolument savoir comment vous avez fait. À très vite !

Disclosure — Tous les benchmarks de ce post tournent sur mon propre Olares One. Si le contenu vous a été utile et que vous envisagez d’en acheter un, commander via ce lien de parrainage vous donne 400 $ de réduction (3 599 $ au lieu de 3 999 $) et me rapporte 200 $. Je le mentionne par transparence — et oui, accessoirement, ça aide à faire vivre le blog (hébergement, domaine, et le temps que je passe à écrire ici). Lien valable jusqu’à fin juin 2026 environ.