Vous traînez sur r/LocalLLaMA un dimanche soir, vous regardez les benchs Qwen3.6-27B, et vous tombez là-dessus :
“Lucebox: 134.78 t/s @ 128K context on a single RTX 3090, with DFlash speculative decoding.”
134 t/s. Sur RTX 3090. Avec un contexte de 128K tokens. Et chez moi, sur Olares One avec mon RTX 5090M, le meilleur que j’arrive à sortir avec Genesis + TurboQuant K8V4 c’est 38 t/s. Bandwidth ratio 5090M vs 3090 : +30 % en faveur du 5090M. Donc si Lucebox tient ses promesses, je devrais voler à 170-200 t/s sur Blackwell consumer.
Évidemment je veux tester. Bienvenue dans la saga.
Lucebox, c’est quoi ?
Il s’agit de Lucebox, un fork de llama.cpp ultra-tuned pour hardware consumer. C’est research-grade et c’est sous MIT. Trois ingrédients clés :
- DFlash — speculative decoding par block diffusion model. Papier ICLR 2026, code chez z-lab. Le drafter génère 15 tokens en un seul forward pass au lieu de drafter token par token comme les méthodes EAGLE/MTP.
- DDTree — Diffusion Draft Tree. Une extension qui transforme les distributions du drafter en arbre de candidats. Améliore l’acceptance rate de DFlash.
- TQ3_0 KV cache — TurboQuant 3-bit avec rotation Hadamard. 3.5 bits par valeur. Compression 5×+ par rapport à fp16, qualité quasi-neutre.
Le tout integré dans un fork custom Luce-Org/llama.cpp@luce-dflash avec des kernels CUDA spécialisés pour les opérations en arbre.
C’est 100 % open source. Ça compile from source. Y a un README. Et là, le hic.
Le hic
Pas de Docker public. Pas de binary release. Pas de nightly.
Leur cible documentée c’est Ampere (RTX 3090, A100) et Ada Lovelace (RTX 4090). Personne n’a jamais testé sur Blackwell consumer (sm_120). Ni sur Kubernetes en général.
Et moi je veux le faire tourner sur Olares One, qui est :
- RTX 5090 Laptop GPU (24 Go GDDR7, sm_120 Blackwell consumer)
- Sous Kubernetes
- Avec HAMi vGPU comme couche d’isolation GPU
Trois inconnues empilées :
- Est-ce que les kernels CUDA de Lucebox compilent pour sm_120 ?
- Est-ce que le binaire tourne sous HAMi vGPU ?
- Est-ce que les perfs scale comme la bande passante le suggère ?
Aucune de ces trois questions n’a de réponse publique. Le seul moyen de savoir, c’est de sortir le Dockerfile et compiler.
Le plan
Je pars sur un Dockerfile multi-stage, classique :
- Stage 1 (
builder) :nvidia/cuda:13.0.0-devel-ubuntu22.04, clone du repo Lucebox avec submodules, cmake config + compile. - Stage 2 (
runtime) :nvidia/cuda:13.0.0-runtime-ubuntu22.04, copy des binaires depuis le builder, entrypoint qui download les modèles depuis HuggingFace + startllama-server.
Cible : aamsellem/lucebox-qwen36-blackwell:1.0.0 sur Docker Hub. Build amd64, sm_120. Et un chart Helm pour deployer sur Olares en quelques commandes.
Sur le papier, c’est 30-40 minutes de compile et un push. En pratique, vous allez voir.
Pourquoi je raconte ça
Parce que personne ne l’a fait sur cette plateforme. Et que les 3 fix que je vais découvrir épisode par épisode ne sont écrits nulle part. Et qu’à la fin, je vais tomber sur un bug dans HAMi vGPU qui crashe non seulement Lucebox mais aussi tout llama.cpp récent et vLLM en async scheduling. Ce bug, je vais le corriger upstream avec un PR. Mais on n’en est pas là.
Pour l’instant, je lance mon premier docker buildx build.
À l’épisode 2 : 2h13 de compile CUDA, et un message d’erreur qui ne dit rien de gentil. Bonne lecture, et à 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.