96 tok/s. Sur du matos grand public. Gemma 4 n’est pas sortie hier — à l’heure du déjeuner, elle corrigeait déjà de vrais bugs dans mon code.
Le dernier modèle open source de Google. Des specs impressionnantes sur le papier. Mais les papiers mentent. Ou du moins, ils en font des tonnes. J’ai lancé mon lab maison — deux cartes NVIDIA RTX 5060 Ti, 32 Go de VRAM au total — et elle tournait à des vitesses qui explosent les benchmarks officiels.
Le hic. llama.cpp en version par défaut ? Plantage total. « Architecture de modèle inconnue : gemma4. » Pas de surprise. Google est en avance, comme d’hab. Ou du moins, il le croit.
Pourquoi bricoler sa propre version de llama.cpp ?
J’ai d’abord essayé l’image CUDA. Raté. J’ai compilé depuis HEAD moi-même. Job Kaniko sur le cluster. Quinze minutes plus tard, image personnalisée dans mon registry. Pas de GitHub Actions, pas de factures cloud.
Dockerfile ? Simple comme bonjour. Clone du master llama.cpp, cmake avec CUDA pour Ampere et Blackwell. SM 86;120. Poussé sur le même Kubernetes qui gère l’inférence. Tout auto-hébergé. On est en 2024 — pourquoi confier son stack ML à des tiers ?
Commande de déploiement : llmkube deploy gemma4-26b –gpu –cuda –gpu-count 2. Modèle depuis Hugging Face, Q4_K_M à 15,6 Go. Flash attention, templates Jinja, contexte 32K. L’opérateur s’occupe du sale boulot Kubernetes. Probes de santé. Endpoint OpenAI. Terminé.
Trois minutes de la commande au premier jeton. Surtout du téléchargement. Puis — bam. 96 tok/s en génération. 128 tok/s en prompts. Débit agrégé ? 170 sous charge. Zéro erreur. Latence P50 à 2 secondes.
Pour info, les benchmarks génériques qui traînent disent que Gemma 4 26B-A4B « dépasse 40 tok/s sur du matos grand public ». On est à 96 tok/s sur une requête unique et 170 tok/s en agrégé sous charge concurrente.
C’est le flex de l’auteur original. Et c’est du solide. Magie MoE — seulement 4 milliards de params actifs par jeton. Les deux GPU se partagent la charge comme des pros. Les chiffres officiels ? Ridicules.
Mais la vitesse sans intelligence, ça vaut rien. J’ai balancé de vrais bugs dessus. Mon propre projet. Des mises à jour rolling Kubernetes qui deadlockent sur les GPU. Le nouveau pod n’attrape pas les ressources ; l’ancien s’accroche comme un ex toxique.
Gemma 4 ? Dans le mille. « Utilise la stratégie Recreate, pas RollingUpdate. Conditionnel sur le nombre de GPU. » Raisonnement en chaîne de pensée. Cas limites couverts. Patch YAML complet. 10,6 secondes pour 1024 jetons.
Ensuite : Endpoints orphelins après suppression d’InferenceServices. Résultat ? Du code Go de prod. Méthode UnregisterEndpoint. Sanitisation DNS. Nettoyage Service/Endpoint. Gestion NotFound. Logs. Pile poil.
11,1 secondes.
Tests ? Parfaitement alignés sur ma suite Gomega. BeforeEach. ContainElements. NotTo(ContainElement). Quatre cas. 12,3 secondes.
Impressionnant. Pas au niveau de Claude. Le raisonnement patine sur les étapes multiples tordues. Coupe parfois en plein milieu. Mais suffisant pour 80 % de la corvée dev.
Gemma 4 tourne-t-elle sur votre config gaming ?
Réponse courte : oui. Si vous avez 32 Go de VRAM. Mon Ryzen 9, Ubuntu 24.04, MicroK8s. Drivers NVIDIA 590. Descendez à une 4090 ? Toujours viable. La quantisation Q4 reste légère.
Le vrai gain ? Le délai entre « Google annonce » et « votre matos ronronne » s’est réduit à quelques heures. Pas des semaines à attendre les ports GGUF quantifiés ou les distros enterprise.
Le bla-bla PR de Google ? « Des modèles open source pour tous ! » Mignon. Mais ils savent bien que la plupart des devs ne compileront pas depuis les sources. Ni ne gèreront des opérateurs K8s. C’est la barrière — subtile incompétence.
Moi, je l’ai fait quand même. LLMKube gère l’ops. Un CRD pour le modèle, un pour le service. Pas de baby-sitting.
Mon grief perso devenu prédiction : c’est le moment Homebrew pour l’inférence IA. Vous vous rappelez les débuts CUDA ? NVIDIA balançait des binaires ; les hackers bricolaient les leurs. Ça a l
