Benchmarks LLM : lire les scores sans se faire piéger

Les benchmarks offrent une mesure objective des capacités d’un modèle, mais un bon score ne garantit jamais une bonne performance sur votre cas d’usage. Voici comment les lire correctement, et pourquoi nous complétons systématiquement les classements publics par une évaluation interne.

Pourquoi les benchmarks comptent (et leurs limites)

Un benchmark permet de comparer des modèles entre eux et de suivre les progrès dans le temps. Mais trois pièges guettent :

• Contamination de données : le modèle a pu voir les questions de test pendant son entraînement, ce qui gonfle artificiellement les scores. Problème majeur des benchmarks anciens.
• Saturation : quand les meilleurs modèles dépassent 90 %, le benchmark ne différencie plus rien. MMLU et HumanEval sont considérés comme saturés.
• Écart avec le réel : un modèle excellent sur des problèmes isolés peut échouer sur un projet complexe nécessitant contexte, debugging et intégration.

Benchmarks de code

Les benchmarks de code ont évolué d’exercices algorithmiques isolés vers des simulations de travail d’ingénieur logiciel : on est passé de « le modèle sait-il coder ? » à « sait-il faire de l’ingénierie logicielle ? ».

SWE-bench — le standard industriel

SWE-bench présente des issues GitHub réelles : le modèle reçoit un dépôt complet et doit produire un patch validé par les tests unitaires.

Caractéristique	SWE-bench	SWE-bench Verified	SWE-bench Pro
Tâches	2 294	500	~1 000
Source	12 repos Python	Subset vérifié humain	Issues post-cutoff
Validation	Tests auto	Tests + humain	Tests + anti-contamination
Risque contamination	Élevé	Modéré	Faible

Les meilleurs systèmes agentiques atteignent 70 %+ sur Verified, mais chutent à 15-25 % sur Pro (conçu contre la contamination) — un écart révélateur entre mémorisation et raisonnement réel.

Les autres benchmarks de code

• HumanEval : 164 complétions de fonctions Python, métrique Pass@1. Historique mais saturé (>95 %).
• MBPP : ~1 000 problèmes Python basiques. Largement saturé.
• LiveCodeBench : problèmes de compétition collectés en continu (post-cutoff), donc résistant à la contamination. Meilleur indicateur récent.
• BigCodeBench : tâches réalistes utilisant des bibliothèques (pandas, numpy, requests).
• Aider Polyglot : édition de code sur 6 langages (Python, JavaScript, Java, C++, Go, Rust), métrique Pass@2 avec une seconde tentative après retour des tests.
• MultiPL-E : HumanEval/MBPP traduits vers 18 langages.

Attention au biais Python : la majorité des benchmarks de code sont fortement orientés Python. Pour un autre langage, privilégiez MultiPL-E ou Aider Polyglot.

Benchmarks généraux

• MMLU : connaissances sur 57 sujets en QCM. Saturé (>90 %) ; MMLU-Pro durcit avec 10 choix.
• GSM8K : maths niveau primaire en 2 à 8 étapes de raisonnement. Saturé (95 %+).
• MATH : problèmes de compétitions (AMC, AIME), bien plus difficile.
• ARC : raisonnement scientifique niveau collège.
• HellaSwag : bon sens via complétion de phrases avec pièges adversariaux.
• TruthfulQA : véracité face aux idées reçues plausibles mais fausses.

Comment interpréter les scores

Ce que les scores indiquent : SWE-bench → résolution de bugs réels ; LiveCodeBench → programmation robuste non mémorisée ; Aider Polyglot → édition multi-langage ; MMLU → connaissances factuelles ; GSM8K/MATH → raisonnement mathématique.

Ce que les scores n’indiquent pas : la compréhension d’un codebase de millions de lignes, la qualité du code produit (lisibilité, maintenabilité), le respect des conventions d’un projet, le comportement face à des spécifications ambiguës.

L’écart fermé / ouvert en 2026

Une question revient à chaque comparatif : de combien les modèles fermés devancent-ils encore les modèles ouverts ? Les indices agrégés indépendants de la mi-2026 donnent une réponse précieuse, à manier toutefois avec les précautions ci-dessus.

• Sur un index d’intelligence agrégé publié mi-2026, les meilleurs MoE ouverts se hissent au niveau des modèles fermés de référence : Kimi K3 se situe au niveau d’un GPT-5.5, et DeepSeek V4 Pro au coude-à-coude avec un Sonnet 4.6.
• Sur le code et le travail agentique, l’écart se compte désormais en quelques points, pas en générations — un modèle ouvert reste un choix viable pour l’écriture, la recherche et les agents spécialisés.
• Une estimation de l’institut Epoch chiffrait cet écart temporel à environ quatre mois ; un repère déjà optimiste, que l’arrivée de modèles fermés comme Claude Fable 5 a sans doute resserré côté frontière.

La conséquence pratique pour une infra locale : la qualité brute n’est plus le facteur bloquant. Ce qui se joue se déplace vers le harness (voir Harness IA et agents de code) et vers l’efficacité matérielle (voir Pénurie de mémoire 2026).

Les métriques de performance, pas seulement de qualité

Au-delà de la qualité, un déploiement local se juge aussi sur trois métriques de débit :

• Tokens/s (decode) : vitesse de génération perçue, limitée par la bande passante mémoire.
• TTFT (Time To First Token) : latence avant le premier token, dépend du prefill et de la longueur du prompt.
• Throughput agrégé : tokens/s cumulés en multi-requêtes, clé en production avec batching.

Mesurer une infrastructure d’inférence : quatre pièges qu’on ne voit pas venir

Les sections précédentes portent sur la qualité des modèles. Mesurer la performance d’un serveur a ses propres traquenards, et nous sommes tombés dans les quatre suivants — chacun a produit un chiffre parfaitement crédible et parfaitement faux.

1. Saturer le contexte sans laisser de place à la réponse

Notre test de récupération sur contexte long échouait systématiquement. Le modèle n’était pas en cause : nous avions rempli le contexte à 262 138 tokens sur 262 144, laissant six tokens pour répondre. Le serveur tronquait proprement la génération, et le test rapportait un échec de compréhension là où il n’y avait qu’un problème d’arithmétique.

Le réflexe : toujours vérifier le champ indiquant la raison d’arrêt de la génération. Un arrêt « longueur maximale atteinte » avec zéro token produit ne dit rien du modèle, seulement de votre prompt.

2. Compter les tokens à la louche

Le piège suivant venait du même test : notre estimateur maison comptait 16 tokens par bloc de texte là où le tokenizer réel en produisait 31,5. Nos prompts « de 130 000 tokens » en faisaient plus du double, dépassaient le contexte, et étaient rognés en silence.

Le réflexe : calibrer sur le vrai tokenizer, en envoyant un échantillon et en lisant le nombre de tokens rapporté. Deux lignes de code, et tous les points de mesure suivants deviennent fiables.

3. Tester le serveur au lieu de tester le service

Nos mesures en appel direct sur le moteur d’inférence donnaient des résultats bien meilleurs que via notre passerelle. Normal : la passerelle applique des réglages par défaut — dans notre cas, elle désactive le mode raisonnement. En l’interrogeant directement, nous mesurions un modèle qui « réfléchissait » longuement avant de répondre, ce que nos utilisateurs ne voient jamais.

Le réflexe : mesurer là où l’utilisateur se branche. Un chiffre obtenu en contournant votre propre chaîne ne décrit pas votre service. Et méfiez-vous des premières requêtes après un redémarrage : elles incluent la mise en chauffe et peuvent afficher la moitié du débit réel.

4. Valider sur une fenêtre trop courte

Le plus coûteux. Nous avons validé une configuration sur vingt minutes de tests intensifs : contexte record, débit record, aucune erreur. Elle a fonctionné six heures, puis s’est mise à s’effondrer toutes les quelques minutes.

La cause était une réserve de mémoire trop mince, invisible tant que le serveur n’avait pas rencontré la bonne combinaison de requêtes. Une seconde configuration a reproduit exactement le même schéma : plusieurs heures de fonctionnement parfait, puis l’effondrement.

Le réflexe : sur une plateforme qui alloue de la mémoire en cours de service, une validation courte ne prouve rien. Nous exigeons désormais plusieurs heures sous trafic réel avant de considérer un profil comme validé — et nous laissons délibérément de la mémoire inutilisée plutôt que d’afficher un meilleur chiffre.

Et surveillez ce que votre supervision ne peut pas voir

Corollaire du point précédent, et le plus embarrassant : pendant que ce serveur redémarrait neuf fois en trois heures, aucune alerte ne s’est déclenchée. La panne a été signalée par des utilisateurs qui trouvaient le service « lent ».

Deux mécanismes se combinaient. D’abord, notre passerelle basculait automatiquement sur un serveur de secours à chaque redémarrage : le service répondait toujours, simplement six fois plus lentement, et sans la moindre erreur côté client. Ensuite, la panne mémoire était interceptée par le moteur lui-même, qui s’arrêtait proprement — code de sortie zéro. Pour l’orchestrateur, le conteneur s’était terminé normalement : aucune des alertes standard sur les redémarrages en boucle ou les dépassements mémoire ne pouvait s’en apercevoir.

Le réflexe : surveiller le nombre brut de redémarrages sur une fenêtre glissante, sans présumer de leur cause. Une alerte qui exige un état d’erreur explicite manquera tous les arrêts « propres » — et un basculement automatique, aussi utile soit-il, transforme une panne visible en dégradation silencieuse.

BenchLocal : notre évaluation qualité interne

Les classements publics ne disent rien de la tenue d’un modèle quantifié sur notre matériel et nos tâches. Nous maintenons donc BenchLocal, une référence qualité interne articulée autour de trois axes proches de nos usages réels :

• Tool-Calling : fiabilité des appels d’outils structurés (JSON valide, bons arguments).
• Instruction-Following : respect des consignes et du format demandé.
• Data-Extraction : extraction fidèle d’informations depuis des documents.

Verdict observé sur Strix Halo : à fichier équivalent, un MoE bat un dense, et la quantification Q5_K_XL se situe sur le front de Pareto qualité/taille. Autrement dit, descendre plus bas en bits dégrade la qualité plus vite qu’il ne libère de mémoire utile. C’est cette mesure terrain, plus que les leaderboards, qui décide quel modèle part en production.

Pour aller plus loin

• Quantification GGUF et front de Pareto
• Choix du matériel
• Dense ou MoE sur Strix Halo