Sélectionner une page
Accueil » Tous les articles » Gemma 4 E2B face à 4 autres modèles LLM locaux : le crash test

Gemma 4 E2B face à 4 autres modèles LLM locaux : le crash test

par | Sep 4, 2026 | IA & Automatisation | 0 commentaires

| Mis à jour le 4 septembre 2026

J’ai comparé quatre modèles LLM en local dans un premier article, en juin. J’avais réalisé les essais à la main, en ligne de commande. Ici j’ai voulu comparer ces modèles à Gemma 4 E2B, un modèle récent. et j’ai choisi de le faire en automatique, via un script bash. Ma seule contribution pendant le comparatif, c’était de regarder la charge du système avec chaque modèle. J’étais chargée de faire des captures d’écran, le script faisait tout le reste !

Cet article fait partie de la série Créer une IA locale.

Pourquoi une température basse pour ce comparatif

La température est un réglage qui contrôle le degré d’imprévisibilité d’un modèle. Une température basse pousse le modèle vers la réponse la plus probable, donc plus stable et plus factuelle. Une température haute laisse plus de place à la variation, ce qui est utile pour la créativité mais augmente le risque d’inventer des éléments qui n’ont pas de sens.

Pour comparer des modèles sur leur capacité à raisonner et traduire correctement, j’ai réglé tous les modèles à une température de 0,2. Par défaut, Open WebUI utilise une température plus élevée (autour de 0,8), pensée pour des usages conversationnels plus créatifs. C’est un choix qui a un impact réel sur les résultats, je détaille cet aspect dans un article, ici, dédié à la température et au system prompt.

Avant de démarrer

Avant tout test, j’ai mis à jour tous mes containers Docker via Portainer (voir l’article dédié), pour être certaine que chaque modèle tourne sur la dernière version d’Ollama.

J’ai aussi arrêté temporairement les containers non essentiels pendant le test (Home Assistant, Tika, Stirling-PDF, Mosquitto, Zigbee2MQTT), pour éviter qu’ils ne consomment de la RAM ou du CPU en arrière-plan et faussent les mesures.

Un second terminal SSH avec htop ouvert en parallèle permet de suivre la consommation de RAM et de CPU pendant chaque test.

Le protocole

Les cinq modèles comparés, tous réglés à température 0,2 :

  • Gemma 4 E2B
  • Qwen 2.5 3B
  • Qwen 2.5 7B
  • Mistral 7B
  • Llama 3.1 8B

Chaque modèle reçoit le même prompt, qui combine trois tâches différentes : un problème de logique, une traduction d’expression idiomatique, et une phrase poétique. Ce format permet de juger plusieurs capacités en un seul appel, mais il faut garder en tête qu’un échec sur une tâche ne dit rien des deux autres.

Installe d’abord jq et bc, deux outils utilisés par le script :

bash

sudo apt install jq bc

jq est un processeur JSON en ligne de commande. Comme l’API d’Ollama renvoie ses réponses en JSON, jq sert à en extraire la réponse du modèle, le nombre de tokens générés ou le temps de calcul. bc est une calculatrice en ligne de commande qui gère les nombres à virgule, ce que Bash ne sait pas faire nativement, utile ici pour calculer la vitesse en tokens par seconde.

Crée ensuite le script :

sudo nano /home/USER/benchmark.sh

Colle-y ce contenu :

#!/bin/bash

MODELS=(
  "gemma4:e2b"
  "qwen2.5:3b"
  "qwen2.5:7b"
  "mistral:latest"
  "llama3.1:latest"
)

PROMPT="Résous ce problème de logique étape par étape : Trois personnes (Alice, Bob et Charlie) ont chacune une couleur de pull différente (Bleu, Rouge, Vert). Alice dit qu'elle ne porte pas de bleu. Charlie porte un pull vert. Quelle est la couleur du pull de Bob ? Ensuite, traduis cette expression anglaise de manière naturelle en français : 'It is raining cats and dogs'. Enfin, écris une seule phrase poétique sur la pluie."
JSON_PROMPT=$(jq -rn --arg x "$PROMPT" '$x')

TOTAL=${#MODELS[@]}
INDEX=1

echo "=== DÉBUT DU BENCHMARK ==="
echo "Température : 0.2"
echo "--------------------------------------------------"

for MODEL in "${MODELS[@]}"; do
  # Mise à jour du titre de l'onglet du terminal
  echo -ne "\033]0;[$INDEX/$TOTAL] Pulling $MODEL...\007"
  echo ""
  echo "[$INDEX/$TOTAL] >>> Mise à jour et récupération des infos de : $MODEL"

  # 1. Mise à jour du modèle
  docker exec ollama ollama pull "$MODEL" > /dev/null 2>&1

  # 2. Récupération des informations de version (Digest / Quantization)
  SHOW_INFO=$(curl -s http://localhost:11434/api/show -d "{\"model\": \"$MODEL\"}")
  FAMILY=$(echo "$SHOW_INFO" | jq -r '.details.family // "inconnu"')
  QUANT=$(echo "$SHOW_INFO" | jq -r '.details.quantization_level // "inconnu"')

  # Récupération de l'ID/Digest du modèle via Ollama CLI
  MODEL_ID=$(docker exec ollama ollama list | grep -E "^$(echo $MODEL | cut -d: -f1)" | awk '{print $2}' | head -n 1)

  # 3. Nettoyage VRAM/RAM
  docker exec ollama ollama stop "$MODEL" > /dev/null 2>&1
  sleep 3

  # Mise à jour du titre de l'onglet pendant le test
  echo -ne "\033]0;[$INDEX/$TOTAL] Testing $MODEL...\007"
  echo ">>> Exécution du test..."

  # 4. Envoi de la requête API et mesure
  START_TIME=$(date +%s.%N)

  RESPONSE=$(curl -s http://localhost:11434/api/generate -d "{
    \"model\": \"$MODEL\",
    \"prompt\": $JSON_PROMPT,
    \"options\": {
      \"temperature\": 0.2
    },
    \"stream\": false
  }")

  END_TIME=$(date +%s.%N)
  ELAPSED=$(echo "$END_TIME - $START_TIME" | bc)

  # Extraction des métriques
  TEXT=$(echo "$RESPONSE" | jq -r '.response')
  EVAL_COUNT=$(echo "$RESPONSE" | jq -r '.eval_count')
  EVAL_DURATION=$(echo "$RESPONSE" | jq -r '.eval_duration')

  TPS=$(echo "scale=2; $EVAL_COUNT / ($EVAL_DURATION / 1000000000)" | bc -l 2>/dev/null || echo "N/A")

  # 5. Affichage des résultats
  echo "--------------------------------------------------"
  echo "MODÈLE         : $MODEL"
  echo "ID (Digest)    : ${MODEL_ID:-N/A}"
  echo "Format / Quant : $FAMILY ($QUANT)"
  echo "Temps total    : ${ELAPSED}s"
  echo "Tokens générés : $EVAL_COUNT"
  echo "Vitesse        : ${TPS} tok/s"
  echo "--------------------------------------------------"
  echo "Réponse :"
  echo "$TEXT"
  echo "--------------------------------------------------"

  # Nettoyage
  docker exec ollama ollama stop "$MODEL" > /dev/null 2>&1
  ((INDEX++))
  sleep 2
done

# Remet le titre par défaut du terminal
echo -ne "\033]0;Terminal\007"
echo "=== BENCHMARK TERMINÉ ==="

Rends-le exécutable et lance-le :

sudo chmod +x benchmark.sh
./benchmark.sh

Le script se charge de :

  • mettre à jour chaque modèle avant de le tester
  • vider complètement la RAM entre deux modèles, pour ne pas fausser les mesures
  • envoyer le prompt via l’API d’Ollama avec la température fixée à 0,2
  • mesurer le temps de réponse total
  • calculer la vitesse de génération en tokens par seconde

Il n’enregistre en revanche pas les pics de RAM et de CPU du système, c’est pour cela qu’il faut suivre htop en parallèle dans un autre terminal. Voici par exemple une capture d’écran réalisée pendant le test de Gemma 4 E2B. Les 4 autres captures sont tout en bas de l’article :

htop pendant l'essai de Gemma 4 E2B

Résultats

ModèleLogiqueTraductionPoésieVitesse (tok/s)Temps totalRAM max (htop)
Gemma 4 E2B (5,1B)Juste (Bleu)Juste (Cordes)Juste9,84106,78 s9,16 Go
Qwen 2.5 (3B)Faux (Rouge)Faux (hors-sujet)Juste8,3739,63 s3,92 Go
Qwen 2.5 (7B)Faux (Rouge)Juste (Cordes)Juste3,7869,21 s6,54 Go
Mistral (7B)Faux (Rouge)Juste (Cordes)Juste3,8648,92 s6,48 Go
Llama 3.1 (8B)Juste (Bleu)Inexact (« gros traits »)Juste3,5590,98 s7,07 Go

Gemma 4 E2B est le seul modèle à réussir les trois épreuves sans erreur. Il génère aussi le texte le plus rapidement en tokens par seconde, même si son temps total reste élevé à cause d’une phase de réflexion plus longue avant de produire la réponse. Sa consommation RAM est la plus élevée du lot, ce qui s’explique par le contexte de raisonnement chargé en mémoire.

Les deux modèles Qwen 2.5 7B et Mistral 7B échouent tous les deux sur le problème de logique, en concluant à tort que Bob porte du rouge. Llama 3.1 8B résout correctement la logique mais traduit l’expression de façon moins idiomatique.

Les réponses des 5 modèles sont disponibles dans ce fichier texte : 2026 09 02 resultats_benchmark

Ce que j’en pense

Au vu de ces résultats, Gemma 4 E2B devient mon modèle local par défaut. Il n’est pas seulement le plus fiable des cinq sur ce test, c’est aussi le seul de la sélection à traiter nativement le texte, l’image et l’audio. Il peut aussi analyser des vidéos, en les découpant en une séquence d’images.

Cette capacité multimodale ouvre des usages que je n’avais pas avec les autres modèles testés ici, comme la transcription ou la description d’images directement en local. C’est une piste que je compte explorer dans un prochain article. Et je vais aussi l’utiliser comme une sorte d’agent.

Pour aller plus loin

Cet article fait partie de la série Créer une IA locale. Retrouve aussi la série Projets Ubuntu pour tout ce qui touche à l’infrastructure Linux qui héberge ces modèles.

Les copies d’ecran htop pendant les 4 autres essais

Pendant le test de qwen2.5:3b :

Pendant le test de qwen2.5:3b

Pendant le test de qwen2.5:7b :

Pendant le test de qwen2.5:7b

Pendant le test de mistral:latest

Pendant le test de Mistral

Pendant le test de llama3.1:latest

Pendant le test de llama3.1
0 0 votes
Évaluation de l'article
0
Nous aimerions avoir votre avis, veuillez laisser un commentaire.x