Benchmarks de modèles LLMs

Résultats

• Les tableaux récapitulatifs.
• Détails Gemma-4 Unsloth.

Introduction

L’idée de ces benchmarks est de mesurer l’impact des la quantization des modèles sur leur précision. Pour mon usage, j’ai choisi de prendre les mesure sur les 3 tests suivants:

Le test Arc_Challenge avait des résultats incohérents. Mon setup ne permet pas de récupérer correctement ces résultats, et je les ai refait avec une variante plus fiable pour mon setup, et j’ai mis à jour les changements (22/04/2026). Je me suis basé sur arc_challenge_chat.

À faire: valider et ajouter DROP et Humaneval avec le harness

Objectifs

Ces mesures ne prennent pas en compte la vitesse du modèle, et les valeurs obtenues ne sont pas à comparer avec les benchmarks des éditeurs de modèles. L’objectif premier de ces mesures est de pouvoir trouver le modèle avec les quantisations les plus pertinentes. Dans un premier temps, je me suis basé sur une utilisation agentique (avec Hermes Agent ou Picoclaw) car c’est la mesure que je cherchais à avoir dans mon cas d’usage. Si vous avez un cas d’usage différent, je peux faire d’autres mesures.

Scripts de tests

Les tests ont été réalisé avec l’outil https://github.com/EleutherAI/lm-evaluation-harness

Pour automatiser les tests, une fois que le protocole était établi, je me suis aidé de deux petits scripts

script de bench

Ce scripts run.sh a comme objectif de charger le serveur llama.cpp avec le bon modèle, et de lancer les benchmarks avec les “bons” paramètres. On remarquera que j’ai également stocké les résultats en json avec l’option --output_path.

#!/usr/bin/env bash

source ./lm-evaluation-harness/.venv/bin/activate

MODEL_TESTED="$1"

echo bench de $1

echo $MODEL_TESTED

arc_chat_test() {

lm_eval --model local-completions\
        --model_args "model=google/gemma-4-26B-A4B-it,base_url=http://localhost:8050/v1/completions,api_key=EMPTY,tokenizer=google/gemma-4-26B-A4B-it"\
        --tasks arc_challenge_chat\
        --batch_size 1\
        --apply_chat_template\
        --output_path "./$MODEL_TESTED"-arc-chat
}

arc_test() {

lm_eval --model gguf\
    --model_args "base_url=http://localhost:8050"\
    --tasks "arc_challenge"\
    --num_fewshot 8\
    --batch_size 1\
    --output_path "./$MODEL_TESTED"

}

ifeval_test() {

lm_eval --model local-completions\
      --model_args "base_url=http://localhost:8050/v1/completions,api_key=EMPTY,pretrained=google/gemma-4-26B-A4B-it,tokenizer=google/gemma-4-26B-A4B-it"\
      --tasks "ifeval"\
      --num_fewshot 0\
      --batch_size 1\
      --apply_chat_template \
      --output_path "./$MODEL_TESTED"

}

gsm8k_test() {
lm_eval --model local-completions\
     --model_args "base_url=http://localhost:8050/v1/completions,api_key=EMPTY,pretrained=google/gemma-4-26B-A4B,tokenizer=google/gemma-4-26b-a4b-it"\
     --tasks "gsm8k"\
     --num_fewshot 8\
     --batch_size 1\
     --apply_chat_template\
      --output_path "./$MODEL_TESTED"
}

arc_test >> $MODEL_TESTED-arc
ifeval_test >> $MODEL_TESTED-ifeval
gsm8k_test >> $MODEL_TESTED-gsm8k

script d’ordonnancement

Ce script a pour objectif d’appeler le script de bench avec le modele à évaluer en paramètre. Il est hautement dépendant des dossiers de stockage des modèles. Je mentionne ici les noms des fichiers qui contiennent les poids à tester.

#!/usr/bin/env bash
for i in gemma-4-26B-A4B-it-UD-Q5_K_M.gguf  gemma-4-26B-A4B-it-UD-Q5_K_S.gguf  gemma-4-26B-A4B-it-UD-Q5_K_XL.gguf  gemma-4-26B-A4B-it-UD-Q6_K.gguf
do
        /home/yves/marvin/vllm/llamacpp/llama.cpp/llama-server \
        -m /data/models/unsloth/"$i" \
        -c 65536 \
        -fit off  \
        -fa on \
        --cache-type-k q4_0 \
        --cache-type-v q4_0 \
        -b 1024         -ub 1024 \
        --port 8050 \
        --host 0.0.0.0 \
        --temp 0.6 \
        --top-p 0.95 \
        --top-k 20 \
        --min-p 0.00 \
        --chat-template-kwargs '{"enable_thinking":true}' &
        sleep 10
        ./run.sh "$i"
        pkill llama-server
        sleep 5
done

GSM8K

Le benchmark GSM8K (Grade School Math 8K) est un dataset d’environ 8 500 problèmes de mathématiques de niveau primaire, spécifiquement conçu pour évaluer les capacités de reasoning des modèles de langage. Chaque exemple est un problème en langage naturel nécessitant plusieurs étapes de calcul (multi-step arithmetic), souvent avec des dépendances intermédiaires (variables implicites, proportions, conversions, etc.). L’objectif n’est pas de tester la mémorisation, mais la capacité du modèle à dérouler une chaîne de raisonnement cohérente jusqu’à une réponse finale.

En pratique, GSM8K mesure la capacité d’un modèle à produire une réponse numérique exacte à partir d’un énoncé textuel, ce qui en fait un proxy assez direct du compositional reasoning et de la fiabilité des chaînes de calcul internes. L’évaluation est généralement strict match : seule la réponse finale est comparée à la ground truth, sans tenir compte des étapes intermédiaires ou de la justification produite.

Le score est exprimé en pourcentage d’exactitude (accuracy) : un modèle à 80 % signifie que 80 % des problèmes sont résolus avec la bonne réponse finale. Important : ce score ne capture ni la qualité du raisonnement (un modèle peut “tomber juste” avec un raisonnement incorrect), ni la robustesse aux variations de prompt, ni la sensibilité aux erreurs numériques mineures. Il reste néanmoins un indicateur standard pour comparer la capacité de raisonnement arithmétique entre modèles.

Un point souvent sous-estimé est que GSM8K peut être non trivial à évaluer avec des modèles instruct ou chat. Ces modèles ont tendance à produire des réponses verbeuses, avec du raisonnement en langage naturel, des unités, ou des phrases autour du résultat final. Cela complique l’évaluation en exact match, qui attend généralement une valeur numérique strictement identique à la référence. En pratique, il faut souvent normaliser les sorties (regex, parsing, extraction de la dernière valeur, etc.) ou contraindre le format de réponse via le prompt. Sans cela, on peut sous-estimer artificiellement les performances du modèle, non pas à cause d’un mauvais raisonnement, mais à cause d’un mismatch de format.

Remarques préliminaires

Pour avoir des résultats cohérents, il a été nécessaire de donner le tokeniser et de préciser le “chat_template” pour que les réponses soient correctement intérprétables par lm evaluation harness .

arc_challenge_chat

Pour la mesure du arc_challenge, les benchmarks utilisent les résultats des probabilités donnés par le moteur d’inférence. Malheureusement, le format d’informations donnés par llama.cpp ne permet pas d’avoir des résultats correctement interprétés. Pour corriger ce défaut, j’ai remplacé le arc_challenge par un challenge qui ne regarde pas les probabilités des tokens en réponse et analyse, mais à partir d’une réponse donnée par le modèle. On a résultat moins fin, mais représentatif. Il ne faut cependant pas le comparer à un arc_challenge classique

Le benchmark ARC Challenge est une sous-partie du dataset ARC (AI2 Reasoning Challenge), spécifiquement conçue pour être difficile pour les modèles de langage. Il s’agit d’un ensemble de questions scientifiques de niveau scolaire (principalement collège/lycée), présentées sous forme de QCM, où les questions ont été filtrées pour éliminer celles qui peuvent être résolues par des heuristiques simples ou de la recherche superficielle.

Chaque exemple est une question à choix multiple (généralement 4 options), couvrant des domaines comme la physique, la biologie, la chimie ou les sciences de la Terre. Contrairement à MMLU, qui teste largement la connaissance, ARC-Challenge met davantage l’accent sur la capacité à combiner des faits et à effectuer un raisonnement multi-étapes léger à modéré, souvent avec des connaissances scientifiques implicites.

En pratique, ARC-Challenge mesure la capacité d’un modèle à appliquer des connaissances scientifiques dans un contexte de raisonnement, plutôt qu’à simplement rappeler des faits. Les questions sont conçues pour nécessiter une compréhension plus profonde (par exemple : relations causales, propriétés physiques, interprétation de phénomènes), ce qui en fait un benchmark intermédiaire entre pure connaissance et reasoning structuré.

Le score est exprimé en accuracy : un modèle à 60 % signifie qu’il répond correctement à 60 % des questions. Étant donné le caractère “challenge” du dataset, les scores sont généralement plus bas que sur des benchmarks plus faciles, et les écarts entre modèles peuvent être plus significatifs. Comme pour tout QCM, le score peut être influencé par des effets de calibration ou des biais dans la distribution des réponses.

Comme pour MMLU ou HellaSwag, l’évaluation avec des modèles instruct ou chat nécessite de contrôler le format de sortie. Les modèles ont tendance à répondre avec des explications (“Je pense que la réponse est B car…”), ce qui nécessite soit un prompt contraint (ex : “Réponds uniquement par A, B, C ou D”), soit un parsing robuste. Sans cela, on peut introduire du bruit dans l’évaluation.

Enfin, ARC-Challenge met en lumière une limite fréquente des LLMs : même avec de bonnes connaissances, les modèles peuvent échouer lorsqu’il faut combiner plusieurs concepts scientifiques de manière cohérente. Cela en fait un bon complément à des benchmarks comme MMLU (plus orienté connaissance) ou GSM8K (raisonnement arithmétique), pour évaluer une forme de reasoning appliqué au monde réel.

ifeval

Le benchmark IFEval (Instruction Following Evaluation) est un dataset d’environ 500 prompts spécifiquement conçu pour évaluer la capacité des modèles de langage à respecter des consignes de formatage et des contraintes structurelles strictes. Chaque exemple est une requête en langage naturel accompagnée d’une ou plusieurs contraintes vérifiables (par exemple : “écris exactement 3 paragraphes”, “ne contiens aucune virgule”, “commence par le mot ‘Cependant’”, ou “réponds au format JSON strict”). L’objectif n’est pas de tester les connaissances ou la pertinence sémantique, mais la capacité du modèle à obéir aveuglément et avec précision à des règles formelles.

En pratique, IFEval mesure la fiabilité d’un modèle en tant qu’exécutant discipliné, ce qui en fait un proxy direct pour les cas d’usage “Agentiques” (où l’IA doit interagir avec du code ou des bases de données). L’évaluation est purement algorithmique et déterministe par le biais de scripts Python : elle vérifie la longueur du texte, le comptage des mots, la ponctuation, ou la présence de mots-clés, sans jamais évaluer la qualité du fond. L’évaluation est binaire : si la consigne demande exactement 250 mots et que le modèle en génère 251, le test échoue.

Le score est exprimé en pourcentage de réussite (accuracy) et se divise généralement en deux métriques : instruction-level (pourcentage de sous-contraintes individuelles respectées) et prompt-level (pourcentage de prompts où toutes les contraintes sont respectées simultanément). Un modèle à 85 % en prompt-level strict signifie que dans 85 % des cas, la réponse a passé tous les filtres heuristiques sans la moindre erreur. Important : ce score ne capture absolument pas l’intelligence ou le style du texte généré (un modèle pourrait écrire du charabia complet et obtenir 100 % s’il respecte le compte de mots et les lettres interdites). Il reste néanmoins l’indicateur de référence pour mesurer l’obéissance brute d’un modèle.

Un point souvent sous-estimé est qu’IFEval est extrêmement sensible à l’alignement conversationnel (Chat Template) et aux nouvelles architectures de modèles. Les modèles bavards ou “polis” qui rajoutent des préambules (“Bien sûr, voici le texte demandé :”) échouent systématiquement aux règles de type “Commence exactement par le mot X”. De plus, avec l’émergence des modèles de raisonnement, les balises de brouillon (comme <think>) faussent totalement les compteurs de mots du correcteur automatique. Sans un nettoyage de la réponse avant correction ou un prompt interdisant ces balises, on peut sous-estimer artificiellement un excellent modèle, non pas parce qu’il désobéit, mais parce que son processus de réflexion ou de courtoisie perturbe le script d’évaluation.