Gemma 4 e2b et e4b : ce que j'ai appris après des heures de benchmark sur des modèles locaux

C'est la première fois que je passe autant d'heures à tester les limites d'un modèle local. Pas juste lancer quelques prompts et voir si ça répond — vraiment benchmarker : scripts automatisés, métriques précises, tests de rupture. Et j'ai appris des choses que je n'aurais pas devinées en lisant les annonces de lancement.

Les modèles en question : gemma4:e2b et gemma4:e4b, les deux variants « E-series » de Google. Le constat principal après cette session : ces modèles ne sont pas faits pour du traitement instantané. Ils sont faits pour du traitement intelligent, de qualité, en mode batch.

Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.

Pourquoi les modèles E-series de Gemma 4 sont différents

Avant de parler des résultats, un point d'architecture qui change tout.

Le « E » dans E2B et E4B ne signifie pas « Edge ». Il signifie « Effective parameters » — paramètres effectifs. Google a utilisé une technique appelée Per-Layer Embeddings (PLE) : des signaux d'embedding secondaires injectés à chaque couche du décodeur. Résultat : un modèle de 2,3 milliards de paramètres actifs qui embarque la densité représentationnelle d'un modèle 5,1B.

Concrètement, l'e2b pèse environ 1,5 GB en quantification 4 bits. L'e4b autour de 2-3 GB. Mais ils disposent d'une fenêtre de contexte de 128 000 tokens et d'une attention hybride qui alterne fenêtres locales (vitesse) et attention globale (cohérence). Ce n'est pas la même classe que les modèles 2-4B habituels.

L'autre différence notable : un mode thinking natif. Ces modèles peuvent raisonner avant de répondre — et comme on va le voir, ce mode se comporte très différemment selon le variant.

Mon infrastructure de test

• GPU : 6 GB VRAM (WSL2, Ollama 0.20.3, port 11700)
• e2b : ~7,2 GB VRAM estimés — tient en GPU
• e4b : ~9,6 GB — dépasse la limite, CPU offload obligatoire
• Scripts : Python async, sept tests batch + six tests de limite

Pour comparaison, mes modèles de production habituels :
- qwen2.5-coder:0.5b : 271 TPS, 720 MB VRAM — modèle format ultra-rapide
- qwen3:4b (q4_K_S) : 59 TPS, 3,3 GB VRAM — modèle sémantique, 94 % sur les tâches générales

Note infrastructure : mon infrastructure locale tourne sur une GPU 6 GB dédiée, avec trois modèles Ollama chargés en simultané (voir J'ai abandonné l'idée de « conscience » dans mon RAG). Le benchmark gemma4 s'est donc fait dans des conditions réelles de production, pas sur un serveur dédié.

Phase 1 — Les cas d'usage batch : là où e2b brille

Premier constat après sept tests batch sur e2b : 7/7 PASS, 100 %. Durée totale 184 secondes, 32,1 TPS en moyenne.

Le résultat le plus important : le triage binaire. E2b utilisé en filtre de première passe : 91 % de précision, 100 % de recall. Aucun élément important n'est écarté. C'est exactement ce qu'on veut pour un pipeline batch — filtrer vite et fiable, et passer les 15-20 % flaggés à un modèle plus profond.

Cette logique de pipeline batch en deux niveaux rejoint ce que j'ai documenté sur la réduction de tokens par accumulation et batching : le vrai gain n'est pas dans un modèle plus rapide, c'est dans une architecture qui évite les appels inutiles.

L'autre observation clé : think=OFF est systématiquement meilleur sur e2b. Mode thinking activé = 2,5× plus lent, sans gain de qualité. Sur les tâches de raisonnement, le mode thinking perd même 8 points de précision. C'est contre-intuitif mais répétable.

Phase 2 — Les tests de limite : les vraies surprises

Six tests de rupture pour trouver où le modèle craque. Et ça craque à des endroits inattendus.

Ce qui marche bien

Cohérence des outputs : dix exécutions du même prompt → 100 % d'accord inter-runs. E2b est entièrement déterministe sur des tâches de classification claires. Pour du tagging à grande échelle, c'est une propriété critique.

Résistance à la pression de contexte : pas de « falaise de latence » jusqu'à 24k tokens. Le modèle répond aussi vite à 24k qu'à 4k. Pas de dégradation de performance brute.

Raisonnement multi-étapes (think=OFF) : 89 % d'accuracy sur des questions à 1-5 sauts logiques. Meilleur que le mode thinking.

Ce qui casse

Schémas JSON contraints : c'est le point de rupture critique. Sur un schéma JSON à 6 niveaux imbriqués avec contraintes d'arrays (min/max), e2b est conforme dans 30 % des cas seulement. Le problème dominant : la contrainte 1-3 dépendances est systématiquement violée (70 % des erreurs). Le modèle génère du JSON syntaxiquement valide, mais ignore les contraintes quantitatives.

En production, cela signifie : validation + retry côté applicatif obligatoire pour tout schéma avec contraintes numériques sur des tableaux.

La calibration de confiance — la vraie rupture : sur 20 questions techniques binaires, e2b déclare 100 % de confiance sur toutes les réponses. Toujours. Même quand il se trompe. Le Brier score résultant est 0,250 — exactement celui d'un modèle aléatoire. Impossible d'utiliser le score de confiance pour router automatiquement les cas difficiles vers un modèle plus puissant.

E4b — Plus lent, mais fondamentalement différent sur deux points

E4b souffre du CPU offload (9,6 GB > 6 GB VRAM disponibles) : 11-14 TPS au lieu de 32. Presque trois fois plus lent. Sur certains appels, jusqu'à 60 secondes.

Mais sur deux dimensions, e4b est dans une autre catégorie :

La calibration : Brier 0,046 vs 0,250

Sur les mêmes 20 questions techniques, e4b obtient 95 % d'accuracy et un Brier score de 0,046 (0 = parfait, 0,25 = aléatoire). Il varie ses scores de confiance entre 90 %, 95 %, 100 % selon sa certitude réelle. Une seule erreur à haute confiance sur 20 questions.

Ce résultat débloque le routing automatique par confiance : si e4b annonce < 70 % de confiance, escalader vers Claude Haiku ou Sonnet. Avec e2b, ce routing est impossible — le signal est du bruit. J'avais cherché à construire ce type de routing dans mon système de métriques (voir 920 appels LLM par jour à votre insu) — e4b fournit enfin le signal fiable qui manquait.

Le thinking mode qui fonctionne vraiment

Sur e4b, think=ON gagne sur le raisonnement multi-étapes : +4,1 points de précision, 86,6 % vs 82,5 %. Le mode thinking est bénéfique sur e4b, et contre-productif sur e2b.

La règle qui en découle : think=ON uniquement sur e4b, pour les questions critiques multi-hop.

Ce qui reste un problème sur e4b

Surprise : e4b est pire qu'e2b sur les schémas JSON contraints — 5 % de conformance vs 30 %. Plus de paramètres n'aide pas sur cette dimension. Les deux modèles nécessitent validation côté applicatif.

L'architecture qui émerge de ces tests

Après ces sessions, l'architecture batch optimale devient évidente :

Volume 100 %
    ↓
[e2b — think=OFF — Classification/Triage]   ~9-23s/batch | Précision 91 %, Recall 100 %
    ↓ ~15-20 % flaggés pour analyse approfondie
[e4b — think=ON — Analyse profonde]         ~33s/item | Accuracy 87 %, Brier 0,046
    ↓ routing par confiance e4b
[Claude Haiku si confiance < 70 %]           Escalade sur les cas vraiment difficiles

Ce n'est pas une architecture « un modèle fait tout ». C'est une chaîne où chaque niveau fait ce qu'il fait bien.

Comparaison avec mon stack qwen

Mes modèles qwen de production ont un profil fondamentalement différent :

Qwen3:4b est mon modèle sémantique de production : 94 % sur les tâches générales, 100 % sur les audits complets, 59 TPS. C'est le backbone de mon infrastructure de traitement intelligent.

Qwen2.5-coder:0.5b est le sprinter : 271 TPS, 720 MB, pour tout ce qui est formatage, génération de messages de commit, naming. Des tâches où la vitesse prime sur la réflexion.

Les gemma4 E-series occupent une case différente : traitement batch à haute valeur sémantique. Ce sont les modèles qu'on lance la nuit sur 10 000 items, pas ceux qu'on sollicite en temps réel pour une réponse instantanée.

La leçon principale : deux classes de modèles locaux

Ce benchmark m'a confirmé quelque chose que j'avais intuité mais pas formalisé : il y a deux classes de modèles locaux, avec des usages très différents.

Classe 1 — Traitement instantané : qwen2.5-coder:0.5b à 271 TPS, qwen3:4b à 59 TPS. Ces modèles répondent en secondes. Ils sont dans la boucle conversationnelle, dans les hooks, dans les pipelines temps-réel. La latence compte plus que la profondeur.

Classe 2 — Traitement intelligent batch : gemma4:e2b à 32 TPS, gemma4:e4b à 11 TPS. Ces modèles prennent leur temps. On ne les appelle pas pour qu'ils répondent vite — on les appelle parce qu'ils font quelque chose que les modèles plus rapides ne font pas aussi bien : évaluer de la qualité, calibrer une confiance, raisonner sur plusieurs étapes, classifier avec fiabilité à grande échelle.

La promesse de l'E-series de Google est réelle : une densité d'intelligence-par-paramètre supérieure, grâce aux PLE et à l'attention hybride. Mais cette intelligence a un coût : la latence. Ce sont des modèles pour des architectures asynchrones, pas pour des endpoints synchrones.

Points de vigilance avant de déployer

Quelques garde-fous tirés de ces sessions :

1. Schémas JSON : les deux variants échouent sur les contraintes min/max dans les arrays imbriqués. Implémenter validation + retry (max 2 tentatives) côté applicatif.
2. Ne pas utiliser le score de confiance d'e2b : toujours 100 %, aucune valeur informationnelle. Pour le routing par confiance, utiliser e4b.
3. Think=ON sur e2b : désactiver systématiquement. Gain de latence 2,5×, gain d'accuracy 8 pp.
4. Context window : e2b perd la conformance schéma dès 8k tokens de contexte. Garder les prompts contraints en dessous de 4k.
5. E4b sans GPU suffisant : le CPU offload ajoute une latence variable et imprévisible. Prévoir 10+ GB VRAM pour e4b en production GPU.

Conclusion

Des heures de benchmark pour arriver à une conclusion simple : gemma4 e2b et e4b ne sont pas des modèles rapides — ce sont des modèles intelligents.

Dans une infrastructure batch bien conçue, e2b remplace avantageusement des appels API cloud pour le triage et l'évaluation RAG. E4b apporte quelque chose de rare dans les petits modèles locaux : une calibration de confiance utilisable. Le tout à coût marginal zéro.

La prochaine étape sur mon agenda : tester e4b avec une GPU ≥ 12 GB et comparer le Pareto coût/qualité/latence contre claude-haiku sur les mêmes sept tâches batch. Je publierai les résultats.

Est-ce que vous avez déjà benchmarké sérieusement un modèle local ? Quelle est la limite qui vous a le plus surpris ? Dites-moi en commentaire.

Pour aller plus loin

Sources et références externes :
- Google — annonce officielle Gemma 4
- Hugging Face — Gemma 4 blog
- Google AI — fiche technique Gemma 4
- Ollama — modèles gemma4 disponibles

Articles liés sur ce blog :
- J'ai abandonné l'idée de « conscience » dans mon RAG — même infrastructure Ollama, GPU 6 GB, qwen en production
- 920 appels LLM par jour à votre insu — le système de métriques qui mesure chaque appel vers ces modèles
- 6 semaines de données RAG, ce que les chiffres révèlent vraiment — le contexte de réduction de coûts qui motive l'usage de modèles locaux

Qui suis je ?

Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.

J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.

Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.

L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.

La technologie, les méthodes, le management sont le cœur de mes compétences.

Vous pouvez me faire confiance sur ces points là.

Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr

Je documente en public ce que je construis en privé. Abonnez-vous pour ne pas manquer les prochains articles sur l'IA locale, les agents autonomes et l'architecture de systèmes LLM.

Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.