Chronologie
Archives.
Tous les posts groupés par année et par mois.
-
Gemma 4 audio E4B à 288 t/s — la deuxième merge upstream ferme la famille
Hier j'ai shippé Gemma 4 12B à 170 t/s via le merge upstream PR #23398. Aujourd'hui PR #24282 (le pendant E2B/E4B) a mergé. Custom rebuild, swap chart, bench : Gemma 4 audio E4B passe de 47 t/s à 288 t/s. 6.1× speedup sur le même hardware en 5 minutes de config. Avec un piège FA en route — la combo Gemma 4 E4B + audio mmproj + MTP draft crashe le CUDA flash attention kernel, fallback no-FA débloque tout.
Lire → -
Gemma 4 12B passe à 170 t/s — le merge upstream donne +67% speed gratuit
Avant-hier j'ai shippé Gemma 4 12B QAT à 102 t/s sur Olares One. Aujourd'hui je ship 170 t/s. Même hardware. Même fichier modèle. Même drafter. Même context. Le delta : am17an's PR #23398 (Gemma 4 MTP support) qui a mergé dans llama.cpp upstream à 12h50 UTC. Mon image custom — qui était un snapshot de sa branche WIP au commit dd97604 — manquait 10+ commits de polish que ggerganov a forcés en review. +67% de speed sur le même setup, juste en rebasant. Bonus : insight critique sur le driver NVIDIA d'Olares One qui cap CUDA à 13.1 et coince tout l'écosystème upstream.
Lire → -
Gemma 4 12B QAT débarque — +17% speed, −39% VRAM, 65K context sur 24 Go consumer Blackwell
Google a publié aujourd'hui à 13 h UTC les variants QAT (Quantization-Aware Training) de Gemma 4. Trois heures plus tard, Olares One tourne dessus. Sur le 12B : 102.78 t/s vs 87.5 baseline = +17.4% speed. 8.6 GB VRAM vs ~14 GB = −39%. Context 32K → 65K avec encore de la marge. Tool calling intact, vision intacte (modulo un piège mmproj que j'explique plus bas).
Lire →
-
Vision débloquée sur Qwen3.6 35B-A3B MTP — 243 t/s + 262K context + image input via le --mmproj-gpu-swap de spiritbuun
Il y a trois jours j'ai shippé Qwen3.6 35B-A3B MTP à 249 t/s text-only sur Olares One — le nouveau champion. Hier j'ai shippé Gemma 4 26B à 250 t/s avec vision. Aujourd'hui le champion Qwen reçoit aussi la vision. Même GPU 24 Go. Même fichier modèle. Le déclencheur : spiritbuun a mergé le 22 mai une feature appelée --mmproj-gpu-swap qui hot-swap MTP et l'encodeur vision en VRAM à la demande. Trade-off : -2.8% de throughput text, +full vision support, +4× de context vs ma tentative v1.0.5.
Lire → -
Gemma 4 26B Vision à 250 t/s — vLLM v0.21 a rattrapé mon champion text-only
Il y a deux jours j'ai shippé Qwen 3.6 35B-A3B MTP à 249 t/s sur Olares One. Text-only, mais nouveau champion. Aujourd'hui le même hardware tourne Gemma 4 26B à 250 t/s — avec vision et tool calling. Le déclencheur : vLLM v0.21 a discrètement mergé le drafter MTP officiel de Google pour Gemma 4. Plus de cycle bug 5-fast/4-slow du DFlash. Plus de fallback no-spec à 135 t/s. Juste la vitesse maximum, plus les images.
Lire → -
249 t/s sur Qwen3.6 35B-A3B MTP — le modèle plus gros qui tourne plus vite que tout ce qui est plus petit
Hier je postais que Nemotron-Labs Elastic 30B-A3B NVFP4 atteignait 166 t/s sur Olares One — puis 182 quand vLLM #40082 a atterri. Nouveau record. Titre du post : 'LLM le plus rapide sur Olares One'. Moins de 12 heures plus tard, ce record est maintenant en deuxième place. Qwen3.6 35B-A3B MTP tourne à 249 t/s sur le même hardware. Modèle plus gros, +37% plus rapide. Voici ce qui se passe.
Lire → -
166 t/s sur Nemotron-Labs 30B-A3B NVFP4 — le nouveau LLM le plus rapide sur Olares One, caché derrière un flag CUDA-graph
NVIDIA a sorti Nemotron-Labs Elastic 30B-A3B avec quantization NVFP4 native il y a deux semaines. Sur Olares One (RTX 5090M consumer mobile sm_120, 24 GB), la config par défaut de vLLM OOM au load. Avec un seul flag CUDA-graph bien réglé — mode PIECEWISE et capture_sizes explicites [1,2,4] — le modèle boot et tourne à 165,91 t/s. +22% vs Gemma 4, +55% vs BeeLlama sur Qwen3.6 27B, +124% vs mon build MTP-master. Nouveau champion.
Lire → -
MTP a fusionné dans llama.cpp master — et la valeur par défaut de n_max que tout le monde a ratée (86,7 % d'acceptation sur Qwen3.6 27B Blackwell mobile)
Le support MTP a fusionné dans llama.cpp master le 16 mai. Cinq jours plus tard, trois PRs de suivi ont silencieusement changé le comportement de MTP — notamment la valeur par défaut de spec-draft-n-max qui passe de 16 à 3. Sur Olares One (RTX 5090M sm_120), ce changement combiné à la réécriture backend-sampling de NVIDIA (#23287) a fait passer l'acceptance des drafts MTP de 64 % à 86,7 % sur Qwen3.6 27B. +22 points. Personne n'en parle.
Lire → -
Gemma 4 26B-A4B vision via vLLM — 135 t/s à 128K pour un office workhorse sur 24 GB
Un peer user d'Olares One a partagé un patch Discord pour restaurer la vision sur la chart gemma426ba4bone. 24 heures plus tard, j'avais shippé un variant vLLM à 135 t/s à 128K de contexte — et le même user l'a validé en production. L'histoire d'une boucle community-driven, quatre configs llama.cpp benchées en parallèle, et le moment où turbo3 KV a cessé d'être la réponse.
Lire → -
BeeLlama Qwen3.6 27B avec vision — 106 t/s à 200K sur Blackwell consumer mobile
Suite du post BeeLlama text-only 262K d'hier soir — ajout du projecteur vision mmproj sur Qwen3.6 27B, je m'attendais à perdre en perf, j'ai eu une surprise contre-intuitive. BeeLlama supporte vision + DFlash spec decoding ensemble (qui crash sur Gemma 4). Et 200K de contexte bat 128K de 4,4 %. Premier bench public BeeLlama vision sur sm_120.
Lire → -
BeeLlama testé sur Olares One — 107 t/s à 262K full, +48 % sur mon meilleur path
La semaine dernière sur r/LocalLLaMA, un post annonce 135 t/s sur Qwen3.6 27B Q5 + 200K de contexte sur une simple RTX 3090, via un fork appelé BeeLlama.cpp. Ridicule si c'est vrai — mon meilleur path sur Olares One plafonnait à 88. J'ai voulu vérifier. Spoiler : 107 t/s à 262K full, zéro OOM, zéro dégradation. +48 % sur mon path le plus rapide. L'histoire d'un build qemu et de trois apps de mon catalogue rendues obsolètes en une nuit.
Lire → -
NVIDIA a shipé FlashInfer 0.6.11 sans aucun cubin SM120/121 — FP4 MoE sur Blackwell grand public dead-on-arrival sur vLLM tant que ce gap n'est pas comblé
Le bringup d'un cluster 8-node DGX Spark sur la vLLM PR
Lire → -
Qwen3.6-27B + MTP CUDA OOM à 262K sur 24Go — réglé en descendant un cran de quant UD
Un utilisateur a tapé un CUDA OOM reproductible en MTP draft sur ma v1.0.5 de Qwen3.6-27B à 262K de contexte. Boot OK, draft scale au-delà de l'estimation statique, exit 139 dans common_speculative_state_mtp draft. Réglé en descendant havenoammo UD-Q3_K_XL (14.9 Go) vers UD-Q2_K_XL (12.3 Go). Bench direct valide v1.0.7 à 72.14 t/s stable, 262K full, zéro OOM. Bonus : test pour drop les patches Genesis via NVFP4. Spoiler : ça marche pas.
Lire → -
Gemma 4 26B-A4B + DFlash sur RTX 5090 Laptop 24 Go — n_spec=8 optimal, +5% vs default, et un cycle de dégradation chelou
Sweep complet de num_speculative_tokens pour Gemma 4 26B-A4B + drafter DFlash z-lab sur RTX 5090M (24 Go sm_120). Optimal = n_spec=8 (pas n=15 comme en desktop). J'ai aussi trouvé un cycle de dégradation 100% reproductible que j'ai pas réussi à fixer côté config.
Lire → -
L'histoire de la journée où j'ai cassé mon plafond Qwen3.6 — pas avec du code, avec un nom de quelqu'un que je ne connaissais pas
J'ai passé toute une journée à essayer de pousser mon Qwen3.6 27B sur Olares au-dessus de 65 t/s. Builds custom, forks expérimentaux, merges qui crashent. Et puis le soir, dans une recherche désespérée sur HuggingFace, je tombe sur un nom : havenoammo. Cinq minutes plus tard, 77 t/s sur 262K de contexte. L'histoire d'une journée à courir après une réponse qui m'attendait à portée de clic.
Lire → -
Une semaine de benches sur Olares One : Gemma 4 MTP, Lucebox qui régresse, vLLM no-Genesis qui se cogne au workspace lock
Du 5 au 8 mai 2026, j'ai bench tout ce qui pouvait tenir sur un RTX 5090M 24 Go. Trois trouvailles : Gemma 4 MTP via vLLM passe à 178 t/s 24 h après merge, Lucebox v1.9.0 régresse mystérieusement de 88 à 69 t/s, vLLM no-Genesis valide PR #39931 mais reste bloqué sur P65/P22/P38. Plus le ménage : 8 apps Qwen3.6 27B → 2.
Lire → -
Gemma 4 E4B MTP sur RTX 5090M : 178 t/s, 24 h après le merge vLLM upstream
Le 6 mai à 14:39 UTC, lucianommartins merge la PR #41745 dans vLLM main : support natif des drafters Multi-Token Prediction de Gemma 4. Le 7 mai à 06:13 UTC, le nightly Docker est publié. À 06:35 UTC, mon Olares One sort 178,6 t/s avec 77,3 % d'acceptance — premier bench public Gemma 4 MTP sur Blackwell consumer mobile.
Lire → -
Quitter les 28 patches Genesis sur vLLM ? Bench vanilla : 88 → 72,5 t/s, voilà pourquoi
PR #39931 (TurboQuant hybrid) mergée dans vLLM main hier matin. J'ai testé sur Olares One avec ZÉRO Genesis patch, image vanilla vllm/vllm-openai:gemma4-0505-cu130. Verdict : 72.55 t/s avec --enforce-eager (vs 88 baseline Genesis = -17.5%). Bonus : on a recroisé deux bugs HAMi/CUDA-graph + l'issue #40807 déjà dans le pipe upstream.
Lire → -
Qwen3.6-27B sur llama.cpp upstream : +123 % gratuits avec MTP, zéro fork à maintenir
MTP arrive enfin dans llama.cpp upstream (PR #22673 par am17an, 4 mai). Bench sur Olares One RTX 5090M sm_120 : 78 t/s avec un GGUF MTP-enabled, +123% vs baseline. Pas de Lucebox, pas de Genesis, pas de fork custom permanent.
Lire → -
Lucebox sur Olares One — Épisode 9 : la PR qui annonçait +57 % et qui livre +0,2 %
Hier soir, Lucebox passait à 88,5 t/s sur Olares One et devenait le nouveau champion. Ce matin la PR #94 annonce +57 % sur RTX 4090. Si ça scale, on tape 120 t/s. Spoiler : 88,7 t/s. Sweep DDTree complet, trois hypothèses, la leçon honnête sur les benchs upstream qui ne se reproduisent pas.
Lire → -
Lucebox sur Olares One — Épisode 8 : sept jours d'attente, une lib swappée à la main, 88,5 t/s
Sept jours après ma PR #188 chez HAMi-core, toujours pas de review. La saga avait son cliffhanger — j'attendais quelqu'un d'autre. Et puis une idée stupide : compiler ma lib patchée et la swap moi-même. Trois bugs nouveaux, une nuit, et au bout du chemin Lucebox tape 88,5 t/s. Premier path llama.cpp à passer devant vLLM Turbo sur ce hardware.
Lire → -
Ma market Olares perso — 28 apps tunées pour l'Olares One, à un clic
Une market Olares custom hand-tunée pour le RTX 5090M de l'Olares One. 28 apps prêtes-à-l'emploi : llama.cpp, vLLM, DFlash, Voxtral ASR/TTS, vision, music. Comment l'ajouter à votre device en 30 secondes.
Lire → -
DFlash débloqué sur 24 Go consumer Blackwell — 80 t/s, 4 jours après le post « impossible »
Il y a quatre jours j'écrivais que DFlash sur 24 Go consumer Blackwell ne tenait pas. Le 28 avril, un dev publie un drafter quantizé. Le 30 avril, je build, je teste, je tape 0,97 t/s. Le 1er mai, après mon issue, le dev fixe en 24h. Ce soir : 80 t/s. L'histoire d'une thèse qui a tenu 72 heures.
Lire →
-
Lucebox sur Olares One — Épisode 7 : six hooks HAMi corrigés upstream d'un coup
Le bug est identifié : 6 hooks dans HAMi-core ignorent le return de cuCtxGetDevice. Le fix tient en 50 lignes. Mais pour qu'il bénéficie à toute la communauté HAMi, il faut le pousser upstream. Voilà comment ça s'est passé.
Lire → -
Lucebox sur Olares One — Épisode 6 : On lit le code source de HAMi-core et on trouve 6 bugs
NO_VMM ne fix rien. Le bug `Illegal device id` revient à chaque run. Il faut lire le code de HAMi-core. Et ce qu'on trouve, c'est pas un bug — c'est un pattern systémique présent dans 6 hooks différents.
Lire → -
Lucebox sur Olares One — Épisode 5 : Le runtime nous claque la porte avec un device id négatif
Image push, pod déployé, modèles téléchargés. Tout est prêt. Et puis HAMi vGPU me balance `Illegal device id: -644371744` à chaque boot, avec un nombre random qui change à chaque run. Ça pue l'uninitialized stack à plein nez.
Lire → -
Lucebox sur Olares One — Épisode 4 : Le sous-module llama-server vous remet ça 1h plus tard
test_dflash compile, super. Mais pour servir en HTTP il me faut llama-server, qui se compile depuis le sous-module. Et le sous-module a sa propre invocation cmake — où j'ai oublié de remettre le -rpath-link. Et boom, rebelote 1h plus tard.
Lire → -
Lucebox sur Olares One — Épisode 3 : LIBRARY_PATH n'est pas ce que vous croyez
On a ajouté LIBRARY_PATH et un symlink libcuda.so.1, on relance 2h de compile, et ld nous balance la même erreur. Pourquoi ? Parce que LIBRARY_PATH ne résout pas les indirect dependencies. Vous avez besoin de -Wl,-rpath-link.
Lire → -
Lucebox sur Olares One — Épisode 2 : 2h de compile CUDA pour 11 undefined references
Premier build Docker. 2h13 de compile CUDA pour sm_120, et au moment du link, ld vous balance 11 undefined references vers cuMemCreate, cuMemMap, cuMemAddressReserve. Pourquoi ? Parce que libcuda.so.1 n'est pas là où il devrait être.
Lire → -
Lucebox sur Olares One — Épisode 1 : 134 t/s sur RTX 3090, et chez moi ?
Vous traînez sur r/LocalLLaMA et vous tombez sur un post qui annonce 134 t/s sur Qwen3.6-27B en RTX 3090 grâce à Lucebox. Évidemment, vous voulez tester sur votre Olares One. Spoiler : ça va prendre 12h de compile et 6 builds Docker. Premier épisode.
Lire → -
Pourquoi j'ai pris un Olares One pour faire tourner mes LLMs
Le choix de la machine, en vrai. Pourquoi pas un Mac Studio, pourquoi pas un PC GPU custom, et pourquoi un Olares One a fini par gagner — vu d'un papa qui a aussi un boulot.
Lire → -
Pourquoi DFlash sur Qwen3.6-27B ne tient pas sur 24 Go single GPU
Trois paths testés (z-lab BF16, AEON-7 NVFP4, Lucebox). Tous demandent ≥26 Go. Math VRAM, négatifs honnêtes, ce qu'attendre pour le 24 Go.
Lire → -
Genesis sur Blackwell consumer — TurboQuant débloqué pour Qwen3.6-27B sur 24 Go
Patches Sandermage Genesis validés sur RTX 5090M (sm_120). TurboQuant 4-bit + MTP n=3 sur Qwen3.6-27B → 60 t/s, 100K contexte, 177K tokens KV.
Lire → -
Qwen3.6-27B à 85-100 t/s sur un RTX 5090 Laptop 24 Go
J'ai adapté les recettes desktop 32 Go et Ampere 24 Go à un GPU Blackwell mobile 24 Go (sm_120). Image vLLM custom, AutoRound INT4, MTP n=3 — 85-100 t/s soutenus avec 75K de contexte.
Lire →