Dans l’article précédent, j’ai comparé 5 modèles de langage installés sur un mini PC. Et j’ai réglé la « température » (quel drôle de mot) sur 0.2. Ca m’a fait me demander quelle était l’importance de la température d’un modèle de langage sur la qualité de ses résultats. Et je me suis rendue compte qu’il y a aussi une notion de « system prompt » qui peut avoir une incidence sur la qualité des résultats. Alors j’ai décidé de lancer un test, avec un seul modèle, qui fait varier les températures et le system prompt. Le résultat m’a beaucoup appris sur les modèles de langage.
Cet article fait partie de la série Créer une IA locale.
Deux réglages à comprendre avant de commencer
La température contrôle le degré d’imprévisibilité du texte généré. À chaque mot, le modèle calcule une probabilité pour plusieurs mots suivants possibles. Une température basse (proche de 0) pousse le modèle à toujours choisir le mot le plus probable, ce qui donne des réponses stables et répétitives. Une température plus haute laisse le modèle piocher parmi des mots moins probables, ce qui donne des réponses plus variées et plus créatives, mais aussi plus de risque de dérive ou d’invention.
Le system prompt est une instruction envoyée au modèle avant la conversation elle-même, invisible pour l’utilisateur final. Elle sert à cadrer le comportement du modèle, par exemple « réponds de façon concise » ou « tu es un assistant technique rigoureux ».
Un point important à connaître si tu passes d’une interface comme Open WebUI à un appel direct via l’API d’Ollama : Open WebUI injecte souvent un system prompt par défaut, invisible dans l’interface. Un appel direct à l’API d’Ollama, comme dans le script ci-dessous, n’en contient aucun sauf si tu le précises explicitement dans la requête. C’est une des raisons pour lesquelles un même modèle peut sembler se comporter différemment selon l’interface utilisée.
Le protocole
L’idée : tester Gemma 4 E2B sur le même prompt (logique, traduction, poésie) que dans le comparatif précédent, avec 5 répétitions par configuration, pour distinguer une tendance réelle du simple hasard.
Deux variables testées :
- la température : 0,2, 0,5 et 0,8
- la présence ou non d’un system prompt de concision
Soit 2 configurations de system prompt x 3 températures x 5 runs, un total de 30 exécutions.
À chaque run, le script exécute docker exec ollama ollama stop gemma4:e2b et attend 2 secondes pour garantir que le modèle est bien déchargé de la mémoire avant de relancer la génération suivante.
#!/bin/bash
MODEL="gemma4:e2b"
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."
SYSTEM_PROMPT="Tu es un assistant virtuel logique, précis et concis. Analyse les contraintes fournies sans inventer d'éléments extérieurs."
TEMPS=(0.2 0.5 0.8)
RUNS=5
OUTPUT_FILE="resultats_gemma.txt"
echo "=== BENCHMARK GEMMA 4 E2B : STABILITÉ & SYSTEM PROMPT ===" > "$OUTPUT_FILE"
echo "Date : $(date)" >> "$OUTPUT_FILE"
echo "--------------------------------------------------" >> "$OUTPUT_FILE"
# Boucle avec et sans System Prompt
for USE_SYS in "SANS" "AVEC"; do
for TEMP in "${TEMPS[@]}"; do
echo "=================================================="
echo "Configuration : System Prompt [$USE_SYS] | Température [$TEMP]"
echo "=================================================="
echo "==================================================" >> "$OUTPUT_FILE"
echo "CONFIG : System Prompt [$USE_SYS] | Température [$TEMP]" >> "$OUTPUT_FILE"
echo "==================================================" >> "$OUTPUT_FILE"
for ((i=1; i<=RUNS; i++)); do
echo -ne "Exécution $i/$RUNS...\r"
# Vider la mémoire RAM/VRAM avant chaque run
docker exec ollama ollama stop "$MODEL" > /dev/null 2>&1
sleep 2
# Construction du payload selon la présence du system prompt
if [ "$USE_SYS" == "AVEC" ]; then
PAYLOAD=$(jq -n \
--arg model "$MODEL" \
--arg prompt "$PROMPT" \
--arg system "$SYSTEM_PROMPT" \
--argjson temp "$TEMP" \
'{model: $model, prompt: $prompt, system: $system, stream: false, options: {temperature: $temp}}')
else
PAYLOAD=$(jq -n \
--arg model "$MODEL" \
--arg prompt "$PROMPT" \
--argjson temp "$TEMP" \
'{model: $model, prompt: $prompt, stream: false, options: {temperature: $temp}}')
fi
START_TIME=$(date +%s.%N)
RESPONSE=$(curl -s http://localhost:11434/api/generate \
-H "Content-Type: application/json" \
-d "$PAYLOAD")
END_TIME=$(date +%s.%N)
ELAPSED=$(echo "$END_TIME - $START_TIME" | bc)
TEXT=$(echo "$RESPONSE" | jq -r '.response // "Erreur"')
EVAL_COUNT=$(echo "$RESPONSE" | jq -r '.eval_count // 0')
EVAL_DURATION=$(echo "$RESPONSE" | jq -r '.eval_duration // 0')
if [ "$EVAL_DURATION" -gt 0 ] 2>/dev/null; then
TPS=$(echo "scale=2; $EVAL_COUNT / ($EVAL_DURATION / 1000000000)" | bc -l)
else
TPS="N/A"
fi
# Écriture des résultats dans le fichier log
echo "--- Run $i/$RUNS (${ELAPSED}s | ${TPS} tok/s | ${EVAL_COUNT} tokens) ---" >> "$OUTPUT_FILE"
echo "$TEXT" >> "$OUTPUT_FILE"
echo "" >> "$OUTPUT_FILE"
done
echo -e "Configuration terminée ! "
done
done
# Nettoyage final
docker exec ollama ollama stop "$MODEL" > /dev/null 2>&1
echo "=== FIN DU BENCHMARK ==="
echo "Tous les résultats ont été enregistrés dans : $OUTPUT_FILE"
Copie ce script dans un fichier test_gemma.sh, rends-le exécutable (chmod +x test_gemma.sh) et lance-le. Les résultats s’écrivent automatiquement dans resultats_gemma.txt. Compte-toi plusieurs heures d’exécution, 30 runs sur un modèle qui répond en 90 à 110 secondes en moyenne, ça prend du temps.
Résultats
| Configuration | System Prompt | Temp. | Réussite logique | Réussite traduction | Temps moyen / run | Tokens moyens / run | Vitesse moyenne |
|---|---|---|---|---|---|---|---|
| Config 1 | SANS | 0,2 | 5/5 | 5/5 | 107,90 s | 962 tok | 9,83 tok/s |
| Config 2 | SANS | 0,5 | 5/5 | 5/5 | 107,96 s | 964 tok | 9,83 tok/s |
| Config 3 | SANS | 0,8 | 5/5 | 5/5 | 109,22 s | 973 tok | 9,80 tok/s |
| Config 4 | AVEC | 0,2 | 5/5 | 5/5 | 91,23 s | 796 tok | 9,86 tok/s |
| Config 5 | AVEC | 0,5 | 5/5 | 5/5 | 89,92 s | 783 tok | 9,85 tok/s |
| Config 6 | AVEC | 0,8 | 5/5 | 5/5 | 94,63 s | 829 tok | 9,86 tok/s |
tu peux voir tous les résultats dans ce fichier texte : 2026 09 02 resultats_gemma
Une stabilité remarquable sur la logique et la traduction
Sur les 30 exécutions, Gemma 4 E2B obtient un score parfait : 30 sur 30 sur la déduction logique et sur la traduction idiomatique. Même à une température de 0,8, le modèle ne dérive pas et ne se met pas à inventer une couleur ou une traduction fantaisiste.
L’effet du system prompt sur la concision
L’ajout du system prompt de concision change nettement le comportement du modèle :
- le nombre moyen de tokens générés passe d’environ 966 (sans) à environ 802 (avec), soit une baisse d’environ 17%
- le temps moyen d’exécution passe d’environ 108 secondes à environ 92 secondes par run
- sans system prompt, le modèle a tendance à répéter l’énoncé et à ajouter des phrases d’introduction (« Voici la résolution… »), ce que le system prompt supprime
Une vitesse d’inférence constante
Sur l’ensemble des 30 runs, la vitesse brute reste comprise entre 9,80 et 9,87 tokens par seconde, quelle que soit la configuration. Ça confirme que ni la température ni le system prompt ne changent l’effort de calcul par token : ils jouent uniquement sur la longueur et la structure du texte généré.
Et la créativité poétique ?
À température 0,2, les métaphores se répètent beaucoup d’un run à l’autre, la même formulation revient plusieurs fois sur les 5 runs d’une même configuration. À température 0,8, le vocabulaire se diversifie nettement, tout en restant grammaticalement correct.
Ce que je retiens
Gemma 4 E2B se montre robuste sur les tâches factuelles, peu importe la température testée ici. Le vrai levier d’optimisation n’est pas la précision, elle est déjà excellente, mais la vitesse de traitement : ajouter un system prompt de concision réduit le temps de traitement d’environ 17% sans perdre en fiabilité.
Une limite à garder en tête
Ce test ne porte que sur Gemma 4 E2B. Il est possible que d’autres modèles réagissent différemment à un system prompt de concision, ça reste à vérifier avec le même protocole.
Pour aller plus loin
Cet article fait partie de la série Créer une IA locale. Retrouve aussi le comparatif complet dans Gemma 4 E2B face à 4 autres modèles LLM locaux et la série Projets Ubuntu.
Commentaires récents