MLPerf RAG mesure enfin toute la chaîne, pas encore le service

Un RAG n’est pas un appel de modèle

Un benchmark LLM classique reçoit un prompt, exécute un modèle et compte des tokens. Cette unité fonctionne tant que le chemin de calcul reste contenu dans ce modèle. Un système de génération augmentée par recherche, ou RAG, ajoute une chaîne avant la réponse : il transforme la question en vecteur, consulte un index, reclasse des passages, élimine ceux qui ne répondent pas au besoin, décide si les preuves suffisent, puis reformule la recherche si une pièce manque.

Chaque étape sollicite le matériel différemment. L’embedder exécute de nombreux petits passages. L’index traverse une structure en mémoire. Le reranker compare des tokens de requête et de document. Les modèles génératifs alternent prefill prefill Phase initiale d'une inférence LLM : les tokens du prompt sont traités en parallèle pour construire l'état du contexte. Cette réutilisation augmente l'intensité arithmétique et peut rendre la phase limitée par le calcul ; le régime exact dépend du modèle, du batch, du contexte et du backend. Approfondir dans le glossaire , decode decode Phase de génération autorégressive d'un LLM : un token est produit à la fois en relisant les poids et l'état de contexte utile. À faible batch, ce trafic peut limiter le decode par la bande passante mémoire. Sa part dans le coût total dépend toutefois des longueurs d'entrée et de sortie, du batching et de la réutilisation du cache. Approfondir dans le glossaire et appels courts de classification. Chronométrer le seul générateur revient à profiler une fonction en ignorant les appels, les copies et les files qui l’entourent.

MLCommons corrige une partie de ce défaut avec MLPerf End-to-End RAG, intégré à la suite Inference v6.1 et présenté le 26 août 2026. Pour la première fois dans MLPerf Inference, une charge multi-composant suit une question à travers la recherche et le raisonnement, au lieu d’isoler un modèle. La formule est juste, à condition de regarder où le chronomètre commence, où il s’arrête et ce que le protocole fige entre les deux.

Deux benchmarks se partagent le mot « end-to-end »

Le corpus ne traverse pas l’indexation puis les 824 questions dans une même exécution. MLPerf définit deux charges indépendantes.

E2E-RAG-DB part de 2 515 fichiers HTML Wikipédia. Il extrait le corps des pages, conserve les tableaux et listes sous forme de texte, découpe le résultat, calcule les embeddings puis construit un index FAISS HNSW. Son score est un débit en documents par seconde. Le chargement des modèles n’est pas chronométré.

E2E-RAG-QnA recharge cette base déjà construite et traite les 824 questions. Son score est un débit en tâches par seconde, une tâche représentant une question menée jusqu’à sa réponse finale. Cette unité évite un faux agrégat en tokens par seconde : une même tâche appelle deux tailles de GPT-OSS, un embedder et un reranker, avec un nombre de tours variable.

Charge	Entrée	Travail chronométré	Métrique	Hors chronomètre
E2E-RAG-DB	2 515 pages HTML	Parse, découpage, embedding, index HNSW	Documents/s	Chargement des modèles
E2E-RAG-QnA	824 questions + base construite	Recherche, reranking et appels LLM	Tâches/s	Chargement des modèles, juge final

Le terme « end-to-end » décrit donc chaque chemin mesuré, pas tout le cycle de vie d’une base documentaire. Un système peut exceller en ingestion et perdre sur QnA, ou l’inverse. Additionner les deux nombres n’aurait aucun sens : l’un compte des documents, l’autre des questions, et l’index peut servir un nombre arbitraire de requêtes après sa construction.

L’ingestion transforme 2 515 pages en 107 000 unités de recherche

Le corpus est une photographie figée de Wikipédia, jointe au benchmark. Ce gel évite qu’une page modifiée entre deux soumissions déplace les passages et change la recherche. Les 2 515 pages sont découpées en environ 107 000 passages de 768 caractères, avec un chevauchement de 32 caractères. Chaque passage conserve l’URL de sa page d’origine.

Le chevauchement protège une petite zone aux frontières : une date ou un nom coupé à la fin d’un segment réapparaît au début du suivant. Il ne résout pas la structure. Une cellule de tableau aplatie devient une suite de texte ; une relation portée par la mise en page peut disparaître alors que les caractères restent présents. Le score d’ingestion récompense la vitesse de ce chemin défini, pas la meilleure façon possible d’indexer un PDF, une base SQL ou un corpus multilingue.

e5-base-v2 transforme chaque passage en vecteur de 768 dimensions. FAISS les organise ensuite dans un graphe HNSW. Pour la première version, les règles fixent M = 32, efConstruction = 200 et efSearch = 100. Cette rigidité a une raison : MLCommons ne dispose pas encore d’un seuil officiel de qualité de recherche qui permettrait à deux index différents de prouver leur équivalence. Fixer l’algorithme réduit la liberté, mais empêche qu’un score de débit soit gagné en dégradant silencieusement le rappel.

Une question peut déclencher cinq tours et plus de douze appels LLM

FRAMES contient 824 questions dont la réponse exige de relier plusieurs pages. Une question ne fournit pas directement les bons mots-clés. Le pipeline doit découvrir une première entité, utiliser cette information pour chercher la suivante, puis vérifier que la chaîne suffit.

Réécriture jusqu'à 3 sous-requêtes GPT-OSS-120B

Recherche embedding + HNSW e5-base-v2

Reranking top candidats par sous-requête ColBERTv2

Filtrage passages pertinents GPT-OSS-20B

Suffisance preuve complète ? GPT-OSS-120B

Réponse faits conservés GPT-OSS-120B

Le réécrivain produit jusqu’à trois sous-requêtes. Chacune est encodée par e5-base-v2 et interroge l’index. ColBERTv2 reclasse les candidats de chaque sous-requête par interaction tardive : il conserve des représentations au niveau du token au lieu d’écraser tout le passage dans un seul vecteur. Le contrôleur élimine ensuite les URL déjà vues. GPT-OSS-20B attribue une pertinence binaire aux nouveaux documents récupérés.

GPT-OSS-120B examine l’ensemble conservé. S’il manque une relation, il reformule et relance le cycle. Le protocole autorise jusqu’à cinq tours et exige ce plafond pour toutes les soumissions. Quand les preuves sont jugées suffisantes, ou quand le cinquième tour est atteint, le même GPT-OSS-120B génère la réponse finale. Le code de référence peut donc effectuer une douzaine d’appels génératifs ou davantage pour une seule tâche.

Le dimensionnement ne suit plus le nombre de paramètres affiché sur une seule fiche. GPT-OSS-120B est un MoE MoE Mixture-of-Experts. Architecture où le réseau est découpé en de nombreux « experts » dont un routeur n'active qu'un petit sous-ensemble par token. Le calcul par token suit le nombre de paramètres actifs ; la mémoire, elle, suit le nombre total, car tous les experts doivent rester résidents en VRAM, prêts à être sollicités. Approfondir dans le glossaire de 117 milliards de paramètres, dont 5,1 milliards sont actifs par token ; GPT-OSS-20B en compte 21 milliards, dont 3,6 milliards actifs. Le grand modèle sert trois rôles peuplés d’appels variables, tandis que le 20B absorbe un filtrage documentaire à plus fort volume. e5-base-v2 et ColBERTv2 ne comptent chacun que 110 millions de paramètres, mais la charge se répète : e5 encode tous les passages lors de DB puis chaque sous-requête lors de QnA, et ColBERT reclasse les candidats retenus par la recherche.

Composant	Modèle	Taille publiée	Précision de référence	Place dans la mesure
Embedding	e5-base-v2	110 M	FP32	DB + QnA
Reranking	ColBERTv2	110 M	FP32	QnA
Grader documentaire	GPT-OSS-20B	21 Md / 3,6 Md actifs	MXFP4	QnA
Réécriture, suffisance, réponse	GPT-OSS-120B	117 Md / 5,1 Md actifs	MXFP4	QnA
Juge de précision	Llama 3.1 8B	8 Md	BF16	Après le run

Le vrai benchmark porte sur l’ordonnancement

Dans une charge à modèle unique, augmenter le batch remplit mieux le GPU jusqu’à rencontrer la mémoire ou la contrainte de latence. Ici, le lot traverse une chaîne dont chaque étage possède son propre débit. Dix tâches peuvent produire trente sous-requêtes, cent passages à reranker, plusieurs dizaines de décisions documentaires et des générations de longueurs différentes. Accélérer un étage déplace la file sur le suivant.

L’équipe qui soumet peut placer l’embedder sur CPU et les modèles génératifs sur GPU, isoler les deux GPT-OSS sur des accélérateurs distincts, partager une carte par partitionnement mémoire ou choisir des précisions différentes tant que la qualité reste au-dessus du seuil. Elle peut aussi chevaucher les tâches : pendant que GPT-OSS-120B génère une requête pour le lot A, ColBERT traite le lot B et le 20B classe les documents du lot C. La pile ressemble alors à un pipeline processeur. Le débit dépend moins de la vitesse d’un étage que de la capacité à empêcher les bulles entre eux.

Le scénario Offline accentue cette dimension. LoadGen remet les 824 tâches dans un seul lot au système, qui peut les grouper et les ordonnancer pour maximiser le débit. Le préfixe croissant au fil des tours ouvre aussi le KV cache KV cache Mémoire des vecteurs clé et valeur déjà calculés pour chaque token traité par un LLM. Évite de recalculer l'attention sur tout l'historique, au prix d'une consommation mémoire qui croît avec le contexte. Approfondir dans le glossaire et le prefix caching à l’intérieur d’une tâche. Les règles interdisent en revanche de réutiliser entre deux questions des résultats dérivés de leur contenu.

La métrique en tâches par seconde devient cohérente : elle absorbe tous les étages et leurs déséquilibres. Elle ne dit rien de la durée vécue par une requête isolée. Un système peut afficher un excellent débit en maintenant chaque accélérateur plein, tout en laissant une question attendre derrière un grand lot.

Le test de performance rejoue les décisions, pas le comportement

Une boucle multi-hop pose un problème de reproductibilité. GPT-OSS-120B utilise un échantillonnage à température 1, avec top_p = 1. Une différence dans la première réécriture peut changer les passages récupérés, le nombre de tours et tous les appels suivants. Deux machines ne recevraient plus la même quantité de travail.

MLPerf sépare donc précision et performance. Le run de précision utilise les sorties vivantes des modèles. Le run de performance appelle encore chaque LLM et mesure son temps d’inférence, mais remplace sa sortie par une réponse enregistrée avant de poursuivre le pipeline. Les mêmes sous-requêtes, passages et décisions de suffisance alimentent ainsi l’étape suivante sur chaque système.

Ce dispositif est l’équivalent d’une trace de branchement rejouée dans un profileur : l’instruction est exécutée, mais le chemin de contrôle vient d’une référence commune. Il compare le coût du calcul et de l’orchestration sans laisser l’aléa modifier le volume de travail.

Cette distinction interdit deux lectures. Un score QnA élevé ne prouve pas que les requêtes produites par le système sont meilleures, puisque leurs effets sur le chemin suivant sont remplacés. Il ne prouve pas non plus qu’un changement de modèle conserve sa dynamique propre. La qualité est contrôlée dans un run séparé.

Le seuil de précision protège une référence encore faible

MLCommons publie 35 % de précision de réponse finale sur les 824 questions, avec une variation observée de ±3 points liée au non-déterminisme de GPT-OSS. Les règles indiquent une précision oracle de 68 % quand les bons documents sont fournis, puis attribuent l’écart à la recherche approximative, au reranking, aux fenêtres de contexte et au raisonnement multi-hop. La boucle itérative a fait passer la référence de 20 % à environ 35 %.

Une soumission est valide si elle conserve au moins 97 % de la précision de référence. Appliqué au chiffre arrondi de 35 %, cela place le seuil autour de 34 %. Ce seuil évite qu’une quantification ou une optimisation sacrifie trop de réponses pour gagner du débit. Il ne transforme pas 35 % en objectif produit : sur cette charge, près de deux réponses finales sur trois ne correspondent pas encore à la vérité de référence selon le juge.

La décomposition par raisonnement confirme le point. MLCommons rapporte 38 % sur les questions à contraintes multiples, 34 % en post-traitement, 32 % sur le temporel, puis 31 % sur les questions tabulaires et numériques. Ces chiffres décrivent la pile de référence, pas une propriété universelle du RAG. Un découpage en caractères conserve mal les tableaux et aucun interpréteur de code ne prend en charge le calcul.

La qualité de recherche, malgré des valeurs de référence de 75 % en précision, 70 % en rappel et 69 % en F1, n’est pas une métrique officielle. Ces trois valeurs restent diagnostiques. Un contrôle d’intégrité distinct vérifie les paramètres de l’index et exige, sur des requêtes sondes, au moins 95 % de recouvrement moyen entre les URL du top-k local et celles du manifeste de référence. Ce seuil mesure la parité avec la base de référence, pas la pertinence face aux bonnes pages. Le test de conformité QnA ne contrôle automatiquement que la longueur moyenne de la sortie du générateur final, 273,81 tokens avec une bande de ±10 %. Il ne couvre pas automatiquement la recherche, le reranking ni les appels intermédiaires ; les examinateurs doivent s’appuyer sur le journal détaillé.

Ce que le premier classement ne permettra pas de conclure

Le scénario Server reste réservé aux cycles suivants. La version initiale n’impose donc aucune arrivée progressive de requêtes, aucun objectif de latence de queue, aucun TTFT et aucun percentile de délai. Elle ne teste ni contrôle d’admission, ni annulation, ni priorité entre locataires. Son score répond à « combien de tâches cette pile termine-t-elle quand tout le travail est visible ? », pas à « combien de temps mon utilisateur attend-il ? ».

Le corpus borne aussi l’extrapolation. Il s’agit de 2 515 pages Wikipédia anglaises déjà sélectionnées pour répondre aux questions FRAMES. Aucun PDF scanné, contrôle d’accès, document dupliqué, mise à jour incrémentale ou requête sans réponse ne vient solliciter la chaîne. L’ingestion mesure une reconstruction complète ; elle ne mesure pas la fraîcheur d’un index alimenté en continu.

Enfin, aucun résultat matériel officiel E2E-RAG n’était public à la date de gel de cet article, le 30 août 2026. L’annonce définit une épreuve et ses références, pas un vainqueur. Tout titre proclamant déjà qu’un GPU ou un fournisseur « gagne MLPerf RAG » confondrait le protocole avec des soumissions qui ne sont pas encore publiées.

Comment lire les futurs résultats

Le score DB doit rester associé à son temps d’ingestion et à la configuration de l’embedder. Il intéresse une équipe qui reconstruit régulièrement de grands index ; il pèse peu si la base est créée une fois puis interrogée pendant des mois.

Le score QnA doit être lu avec la division MLPerf, la précision obtenue, le nombre et le type d’accélérateurs, leur consommation et le placement des composants chronométrés. Deux systèmes au même débit peuvent suivre des architectures opposées : l’un réplique GPT-OSS-20B pour vider la file de documents, l’autre réserve davantage de GPU au 120B pour absorber les tours de raisonnement. Le résultat système cache volontairement ces choix ; la description de soumission doit les remettre en lumière.

Pour un achat, il manque encore le test qui envoie des requêtes selon une arrivée réaliste, impose un percentile de latence et rapporte un coût par tâche valide. MLPerf E2E-RAG fournit désormais la charge commune sur laquelle construire ce test. Il ne fournit pas encore le verdict économique.

Conclusion

Le progrès n’est pas que MLPerf ait ajouté un nouveau modèle à sa liste. Il a changé l’objet mesuré : la performance n’appartient plus à un réseau de neurones isolé, mais au système qui place, alimente et synchronise plusieurs modèles autour d’un index.

La prochaine étape est déjà dessinée par les limites de cette première version. Quand Server ajoutera les arrivées et la latence, quand la recherche possédera son propre seuil de qualité et quand le chemin ne dépendra plus d’une trace rejouée, le benchmark se rapprochera d’un service RAG. Puis viendront les outils, les index structurés et les décisions autonomes. À ce moment-là, le problème ne sera plus seulement de chronométrer une chaîne. Il faudra prouver que l’agent choisit la bonne chaîne.

Sources et méthode

Date de gel rédactionnel : 30 août 2026. Étiquettes : fait vérifié (source primaire), estimation (calcul explicite à partir d’une source), hypothèse (lecture assumée sans mesure). Aucun résultat de performance E2E-RAG n’était public à cette date ; l’article analyse le protocole et sa référence, pas un classement matériel.

Définition du benchmark

• Fait vérifié. MLCommons, Introducing the MLPerf End-to-End RAG Inference Benchmark, 26 août 2026 : deux charges DB et QnA ; 824 questions, 2 515 pages, environ 107 000 passages ; modèles, métriques, précision de référence, scénario Offline, TEST09 et pistes d’optimisation.
• Fait vérifié. Documentation MLPerf Inference v6.1 : E2E-RAG QnA et DB figurent dans la catégorie datacenter avec FRAMES comme jeu de données.

Code et règles figés

• Fait vérifié. Dépôt de référence MLCommons, commit cfb0df14, consulté le 30 août 2026 : scripts DB/QnA, paramètres MAX_ITERATIONS=5, MAX_SUB_QUERIES=3, TOP_K_RETRIEVER=10, séparation des modèles, cache du chemin de performance, appels LLM réels et contrôle d’intégrité de la base avec 95 % de recouvrement top-k.
• Fait vérifié. MLCommons, règles Inference E2E-RAG, commit d3eba2f2 : tâches chronométrées, chargement des modèles exclu, non-déterminisme à 35 % ±3, oracle à 68 %, HNSW M=32, efConstruction=200, efSearch=100, cache interdit entre requêtes et journal détaillé requis pour la revue.
• Fait vérifié. Le document du dépôt Accuracy Tests vs Performance Tests confirme que le mode performance exécute les appels LLM pour leur temps, puis retourne les réponses enregistrées au pipeline ; le mode accuracy utilise les sorties vivantes.
• Contradiction documentaire résolue. Au même commit, le README de TEST09 conserve une ancienne moyenne de 235,47 tokens. Le fichier de conformité appliqué, audit.config, fixe 273,81 tokens et la plage 246,43 à 301,19, chiffres également publiés dans l’annonce MLCommons. L’article retient ces valeurs concordantes.

Jeu de données et modèles

• Fait vérifié. Krishna et al., Fact, Fetch, and Reason: A Unified Evaluation of Retrieval-Augmented Generation, NAACL 2025 : construction de FRAMES, 824 questions multi-hop, catégories de raisonnement et mesures originales. Les scores du papier utilisent une autre pile que la référence MLPerf ; ils ne sont pas transposés au benchmark 2026.
• Fait vérifié. OpenAI, Introducing gpt-oss, 5 août 2025 : GPT-OSS-120B contient 117 milliards de paramètres dont 5,1 milliards actifs par token ; GPT-OSS-20B contient 21 milliards de paramètres dont 3,6 milliards actifs ; poids MoE fournis en MXFP4.

Calculs et limites éditoriales

• Estimation arithmétique. Le seuil « autour de 34 % » vient de 35 % × 97 % = 33,95 %. La référence de 35 % est arrondie et varie de ±3 points ; nous n’en faisons pas un seuil exact au centième.
• Constat daté. Au 30 août 2026, MLCommons publiait encore Inference v6.0 comme dernière annonce de résultats et aucun dépôt public inference_results_v6.1 n’existait dans son organisation GitHub. L’absence de résultat matériel E2E-RAG est donc un constat à cette date, pas une propriété durable du benchmark.
• Lecture éditoriale. Qualifier cette version de benchmark de débit système, et non de service interactif, découle de son unique scénario Offline, de l’absence de métrique de latence et du rejeu des décisions en mode performance. Ce verdict ne remet pas en cause le caractère end-to-end du chemin chronométré ; il en fixe le périmètre.