Benchmarks
Benchmarks LLM : lire les scores sans se faire piéger
Code, raisonnement, contamination, saturation : panorama des benchmarks LLM et pourquoi nous gardons BenchLocal, notre évaluation qualité interne.
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 K2.6 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.
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.