IA en cloud : Volumez automatise les configurations idéales
La startup adapte son moteur de configuration automatique des ressources en IaaS aux besoins des algorithmes d’entraînements de LLM. À la clé, jusqu’à 75 % d’économie sur les coûts et un allègement de charge de travail des data scientists.
Volumez, la startup qui rend plus rapide et moins cher l’accès au stockage pour les machines virtuelles en cloud, adapte sa solution aux traitements de l’IA en ligne. Et plus particulièrement, dans un premier temps, à l’entraînement des modèles sur les infrastructures IaaS d’AWS, d’Azure, de GCP ou encore d’OCI.
« Selon le benchmark MLPerf Storage 1.0, nous obtenons un débit de 1,10 To/s entre le stockage et les VM qui portent les GPU, 9,5 millions d’IOPS et 92 % d’utilisation des GPU. Comparativement, Nutanix et Hammerspace obtiennent, avec des instances de leurs systèmes exécutées en cloud, 273 Go/s (pour 91,6 % d’utilisation des GPU) et 48,4 Go/s (pour 92,12 % d’utilisation des GPU), respectivement », lance John Blumenthal (en photo en haut de cet article), le directeur produits de Volumez, lors d’un événement IT Press Tour consacré aux startups de la Silicon Valley qui innovent en matière de stockage pour l’IA.
« Mais nous battons aussi les meilleures solutions sur site. Une baie de disques Huawei est chronométrée dans des conditions similaires à 695 Go/s (91,7 % d’utilisation GPU), une baie DDN à 99,7 Go/s, une baie HPE Alletra à 40,9 Go/s (90,8 % d’utilisation GPU) et une baie Weka à 34,6 Go/s (91,5 % d’utilisation GPU) », ajoute-t-il.
Rendre l’IaaS moins cher et plus accessible
Précisons que Volumez arrive ces jours-ci dans une version 2.0 spécialement remaniée pour prendre en compte les chargements de données dans le cadre d’un entraînement de modèle d’IA. Par rapport à l’accélération de chargement des données pour VM ou containers applicatifs qu’il proposait initialement, la parallélisation des accès pour alimenter des GPU différerait légèrement, indique la startup.
« Par rapport à une configuration manuelle, dans laquelle vous allez simplement attacher des volumes en mode bloc à des VM de calcul, vous économisez à présent de 31 % à 75 % des coûts d’infrastructure grâce à Volumez. Parce que vous utilisez pour le stockage des VM dédiées moins chères, plutôt que d’ajouter des vCPU à vos VM de calcul très chères pour qu’elles gèrent elles-mêmes le stockage. Parce que nous coupons immédiatement les VMs lorsqu’elles ne servent plus. Et, surtout, parce que nous vous permettons de faire plus avec moins de ressources », argumente John Blumenthal.
« Mais au-delà du prix, nous permettons surtout à des utilisateurs qui sont des data scientists d’utiliser directement la meilleure architecture possible. Sans Volumez, ils devraient faire appel à des informaticiens, c’est-à-dire passer des semaines en réunion pour essayer d’imaginer comment calibrer manuellement l’infrastructure. Avec le risque qu’elle ne soit même pas bien calibrée à la fin. Car l’opération est si complexe à faire qu’elle dépasse la capacité de raisonnement de tout humain normalement constitué », dit-il encore.
Optimiser l’infrastructure existante au-delà des offres sur étagère
Dans le benchmark présenté plus haut, la solution de Volumez gère, sur AWS, 128 machines virtuelles i3en.24xlarge de stockage (60 To chacune en SSD NVMe) reliées, via le réseau en 100 Gbit/s de l’hyperscaler, à 137 VM c5n.18xlarge simulant chacune trois GPU h100.
« Il n’y a aucun contrôleur virtuel entre les VM. Notre solution consiste juste à analyser les performances des ressources en cloud utilisées par notre client et à configurer les Linux présents dans ses VM de la manière la plus optimale. »
John BlumenthalDirecteur Produits, Volumez
« Il n’y a aucun contrôleur virtuel entre les VM. Notre solution consiste juste à analyser les performances des ressources en cloud utilisées par notre client et à configurer les Linux présents dans ses VM de la manière la plus optimale. En l’occurrence, nous montons ici les VM de stockage dans les VM de calcul sous la forme d’un système de fichiers XFS, que nous paramétrons pour qu’il lise une tranche de chaque donnée sur différents SSD », précise John Blumenthal.
XFS est un système de fichiers qui fonctionne au niveau de l’OS comme si les SSD NVMe étaient directement attachés à la machine. C’est le noyau Linux qui permet d’aller les chercher ailleurs, en utilisant des accès en mode bloc sur le réseau Ethernet sans perte de paquet de l’hyperscaler, soit via le protocole NVMe/RoCE (NVMe-over-RDMA-over-Converged Ethernet).
D’ordinaire, les Linux déployés par défaut n'accèdent en mode bloc qu'aux SSD directement accrochés par l'hyperscaler à leur machine virtuelle. Les accès à du stockage distant passent par des protocoles de haut niveau, NFS pour les NAS, ou S3 pour les volumes en mode objet. Ces derniers sont beaucoup plus lents, car leurs paquets sont remplis d’en-têtes fonctionnels qui laissent moins de bande passante aux données utiles.
XFS et NVMe/RoCE sont livrés dans les noyaux de chaque Linux ; Volumez se défend d’installer son propre Linux sur les VMs. Pour autant, les hyperscalers ne proposent pas spécialement de configurations XFS + NVMe/RoCE à leur catalogue, car elles nécessitent des réglages précis que ne sauraient refléter des offres sur étagères.
En cloud, Nutanix et Hammerspace proposent leurs propres pilotes pour accéder au stockage, ce que John Blumenthal appelle des « contrôleurs ». Nutanix utilise un mode bloc qu’il monte dans les machines de calcul, et Hammerspace utilise NFS qu’il enrichit de pNFS (Parallel NFS) pour paralléliser les accès entre plusieurs VM de stockage.
« Le problème est que ces couches ajoutent de la latence et qu’elles sont autant compliquées à configurer manuellement que les stockages nativement proposés par les hyperscalers », prétend John Blumenthal.
Il est à noter que les performances de la nouvelle solution Tier-0 d’Hammerspace, qui consiste à utiliser les SSD internes aux VM de calcul, n’ont pas été évaluées dans le benchmark. Celui-ci ne mesure en effet que les performances d’un cluster d’entraînement avec un stockage externe aux VM de calcul.
« En cloud, les capacités de stockage sur les serveurs de calcul sont limitées et, pire, coûtent plus cher. Tout l’intérêt de Volumez est d’aller chercher du stockage sur des VM moins chères et de les faire fonctionner aussi rapidement que s’il s’agissait de ressources de stockage internes aux VM de calcul », explique notre interlocuteur.
Calculer la configuration optimale et l’automatiser
Volumez se présente comme un service SaaS. Il s’agit essentiellement d’un moteur de configuration connecté à un notebook, c’est-à-dire au code depuis lequel les utilisateurs, idéalement des data scientists, définissent les traitements à exécuter.
En pratique, les data scientists écrivent un code Python simple qui indique les crédits pour se connecter à Volumez, l’emplacement où se trouvent les données source et le travail à faire sur quel cloud dans PyTorch. Il est aussi possible d’utiliser une console d’infrastructure-as-code comme Terraform ou directement au travers de l’API de Volumez. Volumez calcule ensuite les ressources nécessaires sur le cloud indiqué et lance l’ordre de déploiement.
Sur Azure, par exemple, Volumez s’interface avec le moteur de configuration Azure Machine Learning (AML). Via celui-ci, il localise et configure l’accès aux données sources, lui demande de déployer telles VM, avec telles tailles, telles performances, un Linux et un agent de télémétrie. Puis il copie les données sources sur les VM de stockage et charge les jobs d’entraînement sur les VM de calcul.
L’agent, qui est le seul logiciel dans la VM développé par Volumez, se charge à ce stade de renvoyer les détails du travail en cours. C’est notamment lui qui indique à Volumez quand le travail est terminé. Dès que Volumez l’apprend, il migre les données calculées vers le stockage objet d’origine et décommissionne immédiatement toutes les ressources en ligne pour qu’elles ne soient plus facturées.