--- title: "Benchmarks LLM : lire les scores sans se faire piéger" description: "Code, raisonnement, contamination, saturation : panorama des benchmarks LLM et pourquoi nous gardons BenchLocal, notre évaluation qualité interne." date: 2026-06-01T00:00:00.000Z dateModified: 2026-06-14T00:00:00.000Z author: name: Antoine Michéa url: https://sobercloud.fr/ sameAs: - https://altilink.eu/ tags: - benchmarks - llm - performance - reference section: Benchmarks canonical: https://sobercloud.fr/decouvertes/benchmarks-llm/ --- # 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 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](/decouvertes/harness-agents-code/)) et vers l'efficacité matérielle (voir [Pénurie de mémoire 2026](/decouvertes/penurie-memoire-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. ## Pour aller plus loin - [Quantification GGUF et front de Pareto](/decouvertes/quantification-avancee/) - [Choix du matériel](/decouvertes/choix-du-materiel/) - [Dense ou MoE sur Strix Halo](/decouvertes/dense-vs-moe-strix-halo/)