Les nouveaux tests de MLPerf suivent AI au-delà de la boîte de discussion

La charge de travail devient plus importante que le modèle

MLCommons a publié les résultats de MLPerf Inference v6.1 le 16 septembre 2026, introduisant des charges de travail de génération augmentée par récupération de bout en bout et d'inférence agent de périphérie. La tâche RAG intègre des étapes telles que la récupération et le reclassement ainsi que la génération ; la tâche agentique traite du comportement multi-tours sous contraintes. MLCommons : MLPerf Résultats de l'inférence v6.1 et nouvelles charges de travail ↗

Il s'agit d'un changement d'orientation utile. De nombreuses applications métier n'envoient pas d'invite isolée à un modèle autrement inactif. Ils récupèrent des informations, maintiennent le contexte et exécutent des séquences d'actions. Une mesure qui inclut une plus grande partie de ce flux de travail peut révéler les limites manquées par un test sur modèle uniquement.

Lire les conditions avant le classement

Les résultats du benchmark restent conditionnels. Le parc matériel, les versions logicielles, la précision, les scénarios et les exigences de qualité affectent la signification d'un résultat. Un chiffre d’une catégorie ne doit pas être présenté comme une évaluation universelle des performances de l’accélérateur concerné.

Avant de comparer deux soumissions, déterminez si elles mesurent la même tâche selon des règles compatibles. Vérifiez si la configuration répertoriée correspond au système que vous envisagez d'acheter. Faites également la distinction entre un résultat publié et une promesse selon laquelle le matériel exact est disponible pour une livraison immédiate.

Pourquoi RAG peut exposer un goulot d'étranglement différent

Considérons un service de recherche de connaissances. La récupération ou le reclassement de documents peut retarder une réponse avant le début de la génération. Si ces étapes dominent, le remplacement de la génération GPU peut produire une amélioration visible par l'utilisateur plus petite que prévu.

Cela ne rend pas les performances de GPU non pertinentes. Cela change de l'unité en cours d'optimisation : la réponse complète avec la qualité et la latence requises. Le même principe s'applique à un agent qui appelle des outils à plusieurs reprises. Un modèle rapide ne peut pas éliminer le temps pris par chaque service externe qu'il utilise.

Pour l'approvisionnement, demandez à la fois des mesures de composants et un test de bout en bout. Le premier aide à diagnostiquer le système ; le second vous indique si l'application atteint son objectif.

Créez un petit benchmark que vous pouvez conserver

Une entreprise n'a pas besoin de reproduire l'intégralité d'une suite de références publiques pour prendre une décision utile. Il nécessite un ensemble d'évaluation stable, un environnement défini et un enregistrement des paramètres utilisés. Incluez les demandes ordinaires, les demandes longues et les demandes simultanées réalistes.

Préserver les contrôles de qualité de sortie lors du réglage de la vitesse. Enregistrez les erreurs et la latence de queue parallèlement au débit moyen. Gardez le test exécutable après une mise à jour d'un pilote, d'un modèle ou d'un framework. La portée étendue de

MLPerf est une bonne raison de revisiter une ancienne feuille de calcul de comparaison. Cela nous rappelle également que la meilleure référence d'achat est celle dont les conditions ressemblent au travail que le système acheté effectuera réellement.