Gemma 4 audio E4B à 288 t/s — la deuxième merge upstream ferme la famille

Hier post : Gemma 4 12B passe de 102 à 170 t/s grâce à PR #23398 (Gemma 4 MTP support 12B/26B/31B) qui a mergé dans llama.cpp upstream.

Aujourd’hui : PR #24282 (le pendant E2B/E4B) a mergé à 20:48 UTC hier soir par max-krasnyansky (l’auteur original de Gemma 4 MTP chez Qualcomm).

Gemma 4 audio E4B sur Olares One :

• v1.0.1 baseline (pre-MTP) : 47 t/s
• v1.1.1 (PR #24282 + MTP drafter Q8_0) : 288.4 t/s
• +513% speedup. 6.1×.

Même fichier modèle. Même drafter. Même hardware. Juste un rebuild d’image avec le source post-merge + un drafter Q8_0 community qui s’aligne sur la convention arch officielle.

Le tour de la famille en deux PRs

Gemma 4 a été release fin mai dans 5 tailles : E2B / E4B (les small actifs, MoE), 12B (dense), 26B-A4B (MoE), 31B (dense). Quand Google ship leur recipe MTP officielle (assistant drafters), llama.cpp a accepté ça en deux PRs distinctes parce que E2B/E4B utilisent une archi différente du reste de la famille.

PR #23398 (am17an, mergée 2026-06-07) : support MTP pour 12B + 26B-A4B + 31B. Les variants dense + MoE-A4B partagent un format de KV cache homogène.

PR #24282 (max-krasnyansky, mergée 2026-06-08 20:48 UTC) : support MTP pour E2B + E4B. Les variants E* ont une optimisation KV layer-sharing (layers 0-2 partagent leur KV avec layer 40, layer 3 avec 41) qui demandait du code séparé.

Les deux PRs ensemble = toute la famille Gemma 4 a le support MTP officiel upstream. C’est rare qu’on capture une release feature à ce niveau, en moins d’une semaine, sur 5 tailles différentes.

Le drafter du jour

Pour le 12B hier j’utilisais Janvitos/gemma-4-12B-it-qat-assistant-MTP-Q8_0-GGUF — GGUF conversion du checkpoint QAT assistant officiel Google.

Pour le E4B aujourd’hui : NicklausCairns/gemma-4-E4B-it-qat-assistant-MTP-Q8_0 — même pattern, 94 MB Q8_0, arch GGUF gemma4-assistant (tiret, pas underscore) qui matche la convention upstream.

Une fois la convention gemma4-assistant (hyphen) établie post-merge, l’écosystème community a immédiatement publié les conversions GGUF pour chaque taille. C’est la première fois que je vois une release model + drafter + GGUF community + chart shipping arriver en moins d’une semaine.

Le piège flash attention

Premier essai sur Olares One : pod crashe au boot avec :

/src/ggml/src/ggml-cuda/fattn.cu:110: fatal error

Le kernel ggml_cuda_flash_attn_ext lance une assertion sur un cas non-géré. Cause probable : Gemma 4 E4B utilise du KV layer sharing (visible dans les logs : layer 3: sharing with layer 41. k = 0x71a414000000, v = 0x71a418000000 ; layers 0-2: sharing with layer 40) qui interagit mal avec le pipeline FA + MTP draft + audio mmproj.

C’est probablement un bug de couverture — la combo des 4 features (E4B KV-layer-share + FA + spec-decode + multimodal mmproj) ne tombe sous aucun test upstream. Un test minimal report sur llama.cpp et ça se fixera dans une révision suivante.

Workaround immédiat : --flash-attn off. Boot propre, decode @ 288 t/s. La perte de FA sur un model 4B + KV layer sharing est minime parce que les heads sont peu nombreuses → le speedup FA est marginal. On ne perd quasi rien.

Le bench

Olares One (RTX 5090 Mobile sm_120 Blackwell, 24 GB), 3 runs Space Invaders HTML, single user, vision désactivée (audio uniquement pour ce chart), MTP n=2 actif :

Run 1: 289.32 t/s | 2000 tokens
Run 2: 295.22 t/s | 2000 tokens
Run 3: 280.51 t/s | 1849 tokens

AVG : 288.4 t/s. MTP draft acceptance 72-79% (AVG 76%). VRAM ~7 GB total (target Q4_K_M + audio mmproj BF16 + drafter Q8_0 + KV).

vs v1.0.1 baseline (47 t/s, no MTP) = +513% / 6.1× speedup.

Le drafter Q8_0 à 76% accept rate est dans la même ligue que ce qu’on observe sur 12B (91% Janvitos) et 35B-A3B (86% colefuoco). La taille E4B avec ses 4B params actifs et le drafter QAT-matched permet une draft acceptance suffisamment haute pour que MTP n=2 paye.

Le nouveau leaderboard sur Olares One

Gemma 4 audio E4B prend la première place en throughput pur, devant même le champion Qwen 35B-A3B en text. La raison : E4B c’est 4B params actifs sur un model qui en a 8B au total, contre 3B actifs sur Qwen 35B-A3B qui pèse 17 GB. Le ratio params-actifs/VRAM-totale est meilleur sur E4B → plus de tokens par seconde extractibles du même GPU.

Cas d’usage différents par contre :

• Audio E4B : voice agent input layer, ASR léger, summary speech
• Qwen 35B-A3B : agent général haute qualité, reasoning, code, vision
• Gemma 4 12B : chat avec vision, multilingual, mid-tier reasoning

Pas concurrents : complémentaires. Sur le même Olares One, un user qui mix les 3 a un stack très différent d’un user qui n’a que le 35B-A3B.

CUDA 13.3 trap rappel

Comme pour le post d’hier : j’ai dû builder mon image perso sur base nvidia/cuda:13.1.1-devel-ubuntu24.04. ggml-org a bumpé leur Dockerfile officiel à CUDA 13.3 le 2026-06-07, et Olares One driver 590.44.01 cap à 13.1.x. Toute image officielle post-bump fail au démarrage :

nvidia-container-cli: requirement error: unsatisfied condition: cuda>=13.3

Mon image custom build directement depuis le source main HEAD bypass le Dockerfile officiel → CUDA 13.1.1 + dernier code source post-PR #24282 = ce qui marche sur Olares.

Tag final : aamsellem/llamacpp-gemma4mtp:main-postmerge-cuda131-r3 (r3 = troisième révision après le fix curl-CLI binary qui était manquant en r1/r2).

Coda

Trois posts en trois jours. Trois fois la même histoire :

• Lundi : Gemma 4 QAT release → 87 → 102 t/s sur 12B (+17%, weight quantization upgrade)
• Vendredi : PR #23398 merge → 102 → 170 t/s sur 12B (+67%, upstream MTP compute path optimization)
• Aujourd’hui : PR #24282 merge → 47 → 288 t/s sur E4B audio (+513%, MTP feature unlock sur la 2e moitié de la famille)

Chaque saut est entre deux commits, pas entre deux générations de hardware. Le hardware reste fixe — RTX 5090 Mobile depuis qu’on a unboxed l’Olares One. Le software continue à bouffer le problème, et plus vite que je peux écrire.

Sur Olares One : pull https://orales-one-market.aamsellem.workers.dev, upgrade Gemma 4 Audio One en v1.1.1 depuis le market UI. ~5 GB image pull + 4 GB models (E4B target + audio mmproj + drafter Q8_0), boot ~40s post-download.

Côté upstream, le prochain à watcher : KVarN Issue #10 (head_dim=256 support) qui débloquerait le chemin Marc agent-powerhouse (vLLM + Qwen 3.6 27B + KVarN + MTP @ 131K context). philippebich a shippé l’adaptation MLA hier — Qwen/Gemma head_dim=256 next dans la queue.

Trois posts en trois jours. Voyons combien il y en aura cette semaine.