--- title: "Benchmarks LLM : lire les scores sans se faire piéger" description: Panorama des benchmarks LLM, comment lire les scores — et quatre pièges de mesure côté serveur qui produisent des chiffres crédibles et faux. date: 2026-06-01T00:00:00.000Z dateModified: 2026-08-26T00: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 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](/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. ## 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](/decouvertes/quantification-avancee/) - [Choix du matériel](/decouvertes/choix-du-materiel/) - [Dense ou MoE sur Strix Halo](/decouvertes/dense-vs-moe-strix-halo/)