Gemma 4 12B passe à 170 t/s — le merge upstream donne +67% speed gratuit

Avant-hier j’ai shippé llamacppgemma412bone v1.0.3 sur Olares One avec Gemma 4 12B QAT : 102.78 t/s.

Hier v1.0.4 avec le drafter QAT-matched de Janvitos : 101.7 t/s, accept rate +18 pts mais speed identique.

Aujourd’hui v1.0.5 : 169.76 t/s.

Même GPU 24 Go, même Qwen-class hardware, même fichier modèle, même drafter, même context, même KV cache. Le seul changement : l’image llama.cpp.

Le contexte

am17an avait ouvert PR #23398 il y a quelques semaines pour ajouter le support Gemma 4 MTP à llama.cpp. Pendant que la PR avançait, j’ai pris un snapshot de sa branche au commit dd97604 pour pouvoir shipper la fonctionnalité sans attendre la merge upstream. C’est l’image aamsellem/llama-cpp-gemma4mtp:am17an-dd97604 qu’on tournait depuis quelques jours.

Aujourd’hui à 12h50 UTC, ggerganov a mergé la PR. La fin du cycle review était dense — 10+ commits de polish en 12h :

• MTP graph reuse fixes pour la Gemma 4 path
• llama_context clean-up
• Quantized-cache path corrections
• Toutes les renames d’arch que les drafters communautaires (Janvitos, cortexist) ciblaient post-rebase

Le snapshot dd97604 avait raté tout ça.

Le bench

3 runs Space Invaders HTML, single user, vision-loaded, MTP n=2 actif, prompt identique à v1.0.4.

Run 1: 170.03 t/s | 2000 tokens
Run 2: 169.46 t/s | 2000 tokens
Run 3: 169.78 t/s | 1849 tokens

AVG : 169.76 t/s. vs v1.0.4 baseline 101.7 t/s = +66.9% speed.

MTP draft acceptance : 90.4–90.9% (vs v1.0.4 91.4% = within noise). GPU usage inchangé à 8.6 GB.

Le +67% vient pur des MTP graph optimizations upstream — pas de changement de précision, pas de changement de quant, pas de changement de drafter. Le compute path Gemma 4 + MTP a été réécrit dans le review.

Le piège CUDA 13.3

Quand la PR a mergé, j’ai pensé pouvoir juste pull la prochaine image officielle ghcr.io/ggml-org/llama.cpp:server-cuda13-bXXXX post-merge. Sauf que le même jour, en parallèle, un autre commit 3f7c79d (PR #24228) a bumpé le Dockerfile officiel de CUDA 13.1 → CUDA 13.3. Olares One tourne sur nvidia driver 590.44.01 qui cap à CUDA 13.1.x. Toute image officielle ggml-org post-merge fail au démarrage :

nvidia-container-cli: requirement error: unsatisfied condition: cuda>=13.3,
please update your driver to a newer version, or use an earlier cuda container

C’est un cap silencieux qui coince TOUT le scénario “j’attends que ggml-org publie l’image officielle”. Marc (autre user Olares One sur le même hardware) hit la même chose pour son setup vLLM.

Workaround : build mon image perso depuis le source ggml-org/llama.cpp main HEAD, mais sur base nvidia/cuda:13.1.1-devel-ubuntu24.04. Le code source llama.cpp lui-même n’est PAS gated CUDA 13.3 — seul le Dockerfile officiel l’est. Donc on récupère le merge sans payer le bump.

Dockerfile complet :

FROM nvidia/cuda:13.1.1-devel-ubuntu24.04 AS build
ARG CUDA_DOCKER_ARCH=120
RUN apt-get update && apt-get install -y --no-install-recommends \
    build-essential cmake git libcurl4-openssl-dev ca-certificates ccache && \
    rm -rf /var/lib/apt/lists/*
WORKDIR /src
RUN git clone --depth 1 https://github.com/ggml-org/llama.cpp.git .
# Workaround llama.cpp issue #23357 — CUDA::cuda_driver PRIVATE-scope propagation bug:
# explicitly link against the cuda driver stub.
RUN cmake -B build \
    -DGGML_CUDA=ON \
    -DCMAKE_CUDA_ARCHITECTURES=${CUDA_DOCKER_ARCH} \
    -DLLAMA_CURL=ON \
    -DCMAKE_BUILD_TYPE=Release \
    -DCMAKE_EXE_LINKER_FLAGS="-L/usr/local/cuda/lib64/stubs -lcuda" \
    -DCMAKE_SHARED_LINKER_FLAGS="-L/usr/local/cuda/lib64/stubs -lcuda"
RUN cmake --build build --config Release --target llama-server -j$(nproc)

FROM nvidia/cuda:13.1.1-runtime-ubuntu24.04
RUN apt-get update && apt-get install -y --no-install-recommends \
    libcurl4 ca-certificates libgomp1 && \
    rm -rf /var/lib/apt/lists/*
WORKDIR /app
COPY --from=build /src/build/bin/llama-server /app/llama-server
COPY --from=build /src/build/bin/*.so* /app/
ENV LD_LIBRARY_PATH=/app
EXPOSE 8080
ENTRYPOINT ["/app/llama-server"]

Build amd64 + push docker.io en ~30 min. Tag final : aamsellem/llamacpp-gemma4mtp:main-postmerge-cuda131.

Le nouveau leaderboard 12B sur Olares One

Depuis le baseline pre-MTP de v1.0.0 (47 t/s, 32K) : +261% speed et +103% context en 4 versions sur 4 jours.

Pourquoi ça compte au-delà d’Olares One

Le +67% est un gain pure-upstream que tout user llama.cpp + Gemma 4 + MTP va capturer en pullant la prochaine image. Sur RTX 5090 desktop, RTX 4090, RTX 3090 — toute hardware qui supportait am17an’s branch va voir le même delta dès que le Docker tag upstream propagera.

Le piège CUDA 13.3 par contre est spécifique aux setups avec nvidia driver < 595.x. Probable que ça touche pas mal de gens — Olares One ship un driver récent mais pas le plus récent. Sur des cartes plus anciennes ou des distros conservatrices, le cap est encore plus bas.

Coda

Avant-hier j’écrivais que “le scoring board des modèles ≤24 Go change”. Aujourd’hui le board change ENCORE — Gemma 4 12B passe de 102 t/s à 170 t/s sur le même hardware sans changer une ligne de config. C’est le genre de saut qu’on voit habituellement entre deux générations de hardware. Là c’est entre deux commits.

Le hardware reste fixe. Le software continue à bouffer le problème — encore plus vite qu’avant.

Sur Olares One : pull https://orales-one-market.aamsellem.workers.dev, upgrade Gemma 4 12B One en v1.0.5 depuis le market UI. ~3 GB image pull, 30s de cold start.