MLPerf Inference 6.1 : quels changements dans les benchmarks de workflow pour les acheteurs privés d'IA

Le 16 septembre 2026, MLCommons a publié les résultats de MLPerf Inference v6.1 avec de nouveaux tests de génération augmentée par récupération (RAG) de bout en bout et d'inférence agentique en périphérie.[1] Pour un acheteur privé d'IA, l'évolution utile est l'unité de mesure élargie : des preuves sur un workflow peuvent répondre à des questions qu'un simple test de réponse de modèle laisse ouvertes. Notre recommandation est d'utiliser ces résultats pour orienter un pilote, puis de mesurer le déploiement réel séparément.

Cet article reflète le matériel disponible au 26 septembre. Il ne rapporte pas une soumission de benchmark Software Tailor ni ne prétend qu'un déploiement AI Server reproduira un résultat publié.

Lire la charge de travail avant de comparer le score

La publication décrit un travail RAG couvrant la récupération et la génération, ainsi qu'une charge de travail agentique en périphérie avec des tours répétés et un historique croissant.[1] Ce sont des distinctions utiles pour les acheteurs. Un assistant documentaire et un workflow de codage peuvent tous deux appeler un modèle de langage, mais leur travail environnant mérite une investigation séparée.

Commencez une comparaison avec l'opération métier considérée. Nommez l'entrée, la sortie attendue et le point où l'opération est terminée. Une réponse documentaire peut être achevée seulement lorsque ses passages cités peuvent être ouverts. Une tâche d'agent peut nécessiter un résultat d'outil vérifié avant que sa réponse soit utilisable. Ce sont des limites d'acceptation proposées, non des exigences supplémentaires imposées par MLPerf.

Placez la limite du benchmark à côté de cette description. Marquez chaque étape couverte par le résultat et chaque étape appartenant à l'application proposée. Un écart visible est utile : il identifie le travail que le pilote doit mesurer. Cacher cet écart dans un score global unique supprime la raison de faire la comparaison.

Séparez la préparation du corpus de la réponse à une question

L'introduction d'août de MLCommons au benchmark RAG distingue un pipeline d'ingestion qui crée une base de données vectorielle d'un pipeline de question-réponse qui travaille dessus. Ce dernier peut répéter la récupération et le raisonnement sur plusieurs sauts.[2] Cela rend le travail de préparation visible aux côtés du travail de réponse.

Pour une organisation évaluant sa propre collection documentaire, notre pilote suggéré comporte deux enregistrements. L'un décrit la préparation d'une collection définie pour l'usage. L'autre décrit la réponse à un ensemble fixe de questions sur cette collection. Conservez les versions des documents et les paramètres de préparation avec les deux enregistrements afin que les réponses puissent être retracées au même point de départ.

Ajoutez ensuite une mise à jour contrôlée des documents. Observez quand le changement devient disponible pour le chemin de question-réponse et ce que l'utilisateur voit pendant la transition. Traitez cela comme un test d'application avec son propre résultat. Un résultat d'ingestion pour un benchmark externe n'établit pas une promesse de mise à jour pour un magasin de documents différent.

Cette distinction est particulièrement utile lorsque les achats demandent un engagement unique sur le temps de réponse. L'équipe peut spécifier si l'engagement commence avec une collection déjà préparée ou inclut la mise en recherche de nouveaux documents. l'article sur la planification de capacité développe cette distinction en une décision commerciale.

Considérez une séquence d'agents comme une séquence

Une première réponse rapide est un critère d'acceptation incomplet pour une application qui inspectera à plusieurs reprises les preuves et appellera des outils. Notre évaluation suggérée maintient la tâche complète visible. Enregistrez les requêtes successives, les opérations autorisées et le résultat final, puis examinez où l'application a attendu ou a eu besoin d'intervention.

Utilisez une tâche avec un résultat connu avant d'ajouter un travail ouvert. Un petit inventaire fabriqué suffit pour établir si un agent demande l'article prévu, reçoit le résultat correct et l'intègre dans sa réponse suivante. Le procédure d'intégration AI Server utilise cet exemple pour séparer les vérifications de connexion de l'exécution des outils.

Ajoutez délibérément des entrées plus longues et des tours de suivi. Gardez ces cas nommés dans le rapport au lieu de les fondre dans une moyenne inexpliquée. Si un test se termine prématurément, enregistrez pourquoi il s'est arrêté et ce qui est resté inachevé. Un résultat est plus facile à interpréter lorsque l'évaluateur peut distinguer une tâche complétée d'une réponse partielle qui est arrivée rapidement.

Conservez les conditions de comparaison attachées

MLCommons distingue les divisions Fermée et Ouverte, ainsi que les catégories de disponibilité du système. Ses pages de résultats renvoient également à un journal des modifications car les résultats publiés peuvent être modifiés ou invalidés par la suite.[3] Un dossier d'achat doit donc conserver le résultat exact consulté et la date à laquelle il a été vérifié.

Notre fiche de présélection proposée inclut la version du benchmark, la charge de travail, le scénario, la configuration système et la métrique rapportée. Ajoutez la division et la catégorie de disponibilité. Si deux résultats candidats diffèrent dans ces champs, décrivez la différence avant de les classer. Il s'agit d'une discipline pour interpréter les preuves, non d'une affirmation selon laquelle des systèmes différents ne peuvent jamais être comparés.

Conservez une colonne séparée pour l'installation prévue. Elle doit décrire le modèle, la topologie de déploiement et la charge de travail applicative que l'organisation prévoit d'utiliser. Lorsqu'une configuration publiée ne peut pas être reproduite dans le budget ou l'environnement d'exploitation proposé, indiquez-le clairement. Le résultat peut toujours éclairer une enquête, mais ne doit pas devenir silencieusement un objectif d'acceptation.

Transformez le benchmark en un cahier des charges pilote

Le résultat pratique est une expérience limitée. Choisissez une tâche dont la justesse peut être inspectée, définissez les étapes de la charge de travail et indiquez la limite temporelle. Demandez au fournisseur candidat quelles parties du chemin proposé les preuves publiées couvrent. Attribuez les questions restantes à un pilote local avec des critères d'acceptation nommés.

Pour Software Tailor, une discussion de déploiement utile commence par ce cahier des charges et la limite de données prévue. Apportez des entrées représentatives pouvant être partagées selon les règles de l'organisation, ou des équivalents fabriqués qui exercent le même flux de travail. Gardez l'acceptation commerciale, les contrôles de sécurité et la performance mesurée comme des constats séparés.

Un benchmark doit laisser l'acheteur avec de meilleures questions sur l'installation proposée. La décision finale d'achat nécessite des réponses pour cette installation.

Références

[1] MLCommons. Annonce des résultats MLPerf Inference v6.1. Publié le 16-09-2026. Consulté le 26-09-2026.

[2] MLCommons. Présentation du benchmark MLPerf End-to-End RAG Inference. Publié le 26-08-2026. Consulté le 26-09-2026.

[3] MLCommons. MLPerf Inference : Datacenter. Résultats actuels et aperçu méthodologique. Consulté le 26-09-2026.