MLPerf : des tests pour mesurer objectivement les offres d’IA
Développés par l’organisation à but non lucratif MLCommons, ces benchmarks évaluent les performances des infrastructures vendues pour entraîner ou inférer des IA.
Sur un marché de l’IA en pleine effervescence, où il n’est pas simple de savoir si les performances annoncées par les fabricants, clouds et autres éditeurs sont sincères, MLCommons se positionne comme le fournisseur neutre des benchmarks MLPerf. Fondée par David Kanter, cette organisation à but non lucratif propose des normes ouvertes pour mesurer objectivement les performances et l’efficacité énergétique des systèmes d’IA. Son approche collaborative, qui implique les fournisseurs de solutions d’IA et les chercheurs qui en affinent les algorithmes, contraste avec les déluges d’unités de traitement, de débits ou de tokens mis en avant par les marques.
« Même les hyperscalers développent leurs propres puces d’accélération, désormais. Le marché a besoin de benchmarks pour comparer les technologies. MLPerf met tous les fournisseurs sur le même niveau d’honnêteté », lance David Kanter (en photo en haut de cet article), lors d’un événement IT Press Tour consacré aux acteurs de la Silicon Valley qui innovent en matière d’infrastructure IT.
Selon lui, les benchmarks MLPerf seraient une aide précieuse lors des appels d’offres. C’est en les intégrant dans leur cahier des charges que les responsables du centre européen de supercalcul Lumi auraient ainsi pu rapidement sélectionner l’infrastructure la plus propice à leurs besoins.
« Les benchmarks sont utiles aux acheteurs et aux vendeurs, car ils les aident à prendre des décisions éclairées. Pour un acheteur, quel produit choisir ; pour un vendeur, comment concevoir sa prochaine génération de systèmes. Les benchmarks sont également utiles à la recherche : si vous êtes chercheur, ils vous permettent de savoir si votre technique est efficace », argumente David Kanter.
En général, évaluer les performances d’une solution d’IA est complexe : variations algorithmiques, matérielles et logicielles brouillent les comparaisons. MLCommons intègre tous ces paramètres, ce qui lui évite l’écueil des mesures tronquées.
« Une IA qui donne une mauvaise réponse très rapidement est moins utile qu’une IA qui donne la bonne réponse. »
David KanterFondateur, MLCommons
« Nos benchmarks MLPerf testent différents cas d’usage dans l’entraînement de modèles, l’affinage, l’inférence, que ce soit sur des infrastructures de calcul ou de stockage, en datacenters ou en cloud, mais aussi sur des postes clients, des objets connectés et même, bientôt, des équipements électroniques embarqués dans les automobiles », explique notre interlocuteur.
« Pour chaque cas d’usage, nous définissons un niveau de précision à atteindre. Les benchmarks antérieurs à MLPerf ne faisaient pas cela, ils ne testaient pas la précision d’un modèle. Ils étaient trompés par des solutions qui réduisent la précision pour augmenter les performances. Mais une IA qui donne une mauvaise réponse très rapidement est moins utile qu’une IA qui donne la bonne réponse », ajoute-t-il.
Des benchmarks déclinés pour tous les cas d’usage de l’IA
MLCommons développe une petite dizaine de benchmarks selon l’infrastructure à évaluer (MLPerf Training, MLPerf Inference Datacenter, MLPerf Storage, MLPerf Client, etc.). Chacun d’eux est capable de tester divers cas d’usage avec un jeu de données, un modèle d’IA de référence et un objectif de précision à atteindre lors de l’inférence. Par exemple, MLPerf Training évalue les performances des scénarios suivants de cette manière :
l’entraînement d’un LLM puis inférence (qui est l’étape pendant laquelle un modèle d’IA est exécuté pour accomplir une tâche particulière) sur les données Wikipédia avec les modèles de référence BERT-Large ou GPT3,
la personnalisation d’un LLM puis inférence sur les données GovRep et le modèle de référence Llama 2 70B,
l’entraînement et la génération de recommandations à partir des données de Criteo et le modèle de référence DLRM-dcnv2,
l’entraînement et la détection d’objets dans une image depuis une bibliothèque libre d’images et le modèle de référence RetinaNet,
l’entraînement et la classification d’événements à partir des données IGBH-Full et le modèle de référence R-GAT (ce qui sert notamment à la détection de fraudes, à la découverte de médicaments, etc.)
et, enfin, l’entraînement et la génération d’images à partir des données LAION-400M-filtered et le modèle de référence Stable Diffusion v2.
De la même manière, le test MLPerf Inference teste une dizaine de cas d’usage sur une infrastructure soumise par le candidat, avec autant de jeux de données en RAG et de modèles de référence : la génération de texte, la génération d’image, le résumé de textes, la recommandation, la détection d’objets, la classification d’images, etc.
Le test MLPerf Storage permet de son côté d’identifier les goulets d’étranglement et le niveau d’utilisation du GPU. Il teste l’entraînement de modèles avec des échantillons de données de tailles différentes : 150 Ko, 2 Mo et 146 Mo.
Ce qui compte : le temps d’entraînement pour atteindre un niveau de réponses précises
« Nos métriques sont les temps de calcul et la précision des résultats. D’autres parleront du nombre de tokens par seconde. Mais lorsqu’il s’agit d’entraînement, ce qui compte vraiment, c’est le temps d’entraînement pour atteindre un certain niveau de précision. Si une certaine IA sur une certaine infrastructure n’atteint pas le niveau de précision de notre modèle, son évaluation par MLPerf n’est tout simplement pas valide », précise David Kanter.
« Si une certaine IA sur une certaine infrastructure n’atteint pas le niveau de précision de notre modèle, son évaluation par MLPerf n’est tout simplement pas valide. »
David KanterFondateur, MLCommons
« Beaucoup de candidats utilisent différentes précisions, non pas de résultat, mais de calcul. Elles sont exprimées avec des nombres entiers ou à virgule flottante, qui peuvent être en 16 bits ou 8 bits, au lieu de 32 bits. Ce sont tous des compromis acceptables. Mais ils doivent s’assurer qu’ils peuvent atteindre la précision que nous mettons en objectif, qu’importe la technique qu’ils utilisent, ou les modifications qu’ils font sur leur infrastructure », dit-il.
Deux types de tests sont possibles : une comparaison fermée et une comparaison ouverte. Dans la comparaison fermée, il s’agit de tester les données et le modèle de référence de MLCommons sur une infrastructure. Dans la comparaison ouverte, les candidats peuvent comparer n’importe quel modèle – en général celui qu’ils ont mis au point eux-mêmes – au modèle de référence, également testé sur la même infrastructure. Les candidats doivent cependant expliquer en quoi leur modèle est différent.
Les tests sont répétés cinq à dix fois, car les résultats peuvent varier d’un batch à l’autre. « Nous éliminons le test le plus rapide et le test le plus long. Puis nous faisons la moyenne des tests intermédiaires pour le résultat officiel », dit David Kanter.
Les résultats sont publiés dans l’une des trois catégories que MLCommons a définies : Available (ce qui signifie que la solution est disponible sur le marché), Preview (ce qui signifie que la solution sera bientôt disponible sur le marché) et RDI (ce qui correspond aux prototypes).
Les infrastructures 1,5 x meilleures sur l’inférence et 1,26 x sur l’entraînement
Les dernières versions 4.1 de MLPerf ont été lancées lors du dernier trimestre de l’année dernière.
Depuis la publication de la version 4.1 de MLPerf Training, 156 tests ont mené à des publications officielles de résultats. Parmi les fournisseurs qui ont déjà évalué leur solution d’IA sur MLPerf 4.1, il y a des fournisseurs de solutions en cloud (Azure, Google, Lambda, Nvidia, Oracle), des fournisseurs de solutions à installer sur site (Asus, Cisco, Dell, Fujitsu, Lenovo, Nvidia, Quanta, Supermicro, Tinycorp...) et des concepteurs d’IA en prototype (FlexAI, Google qui a testé sa dernière puce TPU Trillium, Nvidia qui a testé son nouveau GPU B200).
« Nous constatons que les tests les plus nombreux concernent désormais l’IA générative sur GPT3, Stable Diffusion et Llama 2 70B. Ces tests sont en progression de 46 % sur la dernière version par rapport à la version précédente », constate David Kanter.
« Nous constatons que les tests les plus nombreux concernent désormais l’IA générative sur GPT3, Stable Diffusion et Llama 2 70B. »
David KanterFondateur, MLCommons
Il partage d’autres observations. Les tests d’entraînement menés sur Llama 2 70B sont en progression de 16 % et les résultats montrent que les infrastructures actuelles apportent des performances 1,26 fois supérieures aux solutions testées sur la version précédente de MLPerf.
Les tests d’entraînement de classification d’événements sont en augmentation de 55 % et les performances mesurées sont 1,23 fois meilleures que précédemment.
Les tests concernant uniquement l’IA générative, avec MLPerf Inference 4.1, affichent des performances 1,5 fois meilleures que les solutions précédemment testées.
« En fait, les performances des infrastructures pour l’IA évoluent plus vite que la Loi de Moore ! Mais ce n’est pas très surprenant, car il n’y a pas que les infrastructures qui évoluent. Nos benchmarks mesurent aussi l’efficacité des algorithmes, lesquels évoluent encore très rapidement, car ils n’ont pas la maturité des autres logiciels pour serveurs », fait remarquer David Kanter.
Les tests concernant le stockage avec MLPerf Storage démontrent que la problématique concerne plus, à présent, la latence d’accès aux données que la vitesse de chargement de ces données.
Sur les machines personnelles, MLCommons vient tout juste de lancer MLPerf Client v0.5, pour tester l’IA générative sur Windows à partir de Lama 2 7B. La version dédiée aux automobiles doit paraître d’ici à quelques semaines..
