Auteurs:
(1) Sasun Hambardzumyan, Activeloop, Mountain View, Californie, États-Unis ;
(2) Abhinav Tuli, Activeloop, Mountain View, Californie, États-Unis ;
(3) Levon Ghukasyan, Activeloop, Mountain View, Californie, États-Unis ;
(4) Fariz Rahman, Activeloop, Mountain View, Californie, États-Unis ;.
(5) Hrant Topchyan, Activeloop, Mountain View, Californie, États-Unis ;
(6) David Isayan, Activeloop, Mountain View, Californie, États-Unis ;
(7) Mark McQuade, Activeloop, Mountain View, Californie, États-Unis ;
(8) Mikayel Harutyunyan, Activeloop, Mountain View, Californie, États-Unis ;
(9) Tatevik Hakobyan, Activeloop, Mountain View, Californie, États-Unis ;
(10) Ivo Stranic, Activeloop, Mountain View, Californie, États-Unis ;
(11) Davit Buniatyan, Activeloop, Mountain View, Californie, États-Unis.
Dans cette section, nous démontrons expérimentalement les performances de Deep Lake à grande échelle, depuis le point d'ingestion dans le format jusqu'à la formation à grande échelle par rapport à d'autres chargeurs de données et formats. Nous comparons les ensembles de données de streaming provenant de différents backends de stockage et présentons les gains de performances et l'évolutivité lors de la formation sur le cloud.
10 000 images de l'ensemble de données FFHQ [43] ont été décompressées et stockées au format NumPy. Chaque image brute de 1 024 x 1 024 x 3 correspond à un tableau de 3 Mo. Ensuite, comme le montre la figure 6, les images ont été écrites en série dans chaque format. Pour augmenter les performances, nous avons utilisé TensorStore [23] pour écrire aux formats Zarr [52] et N5 [24]. Les expériences ont été réalisées sur la machine AWS c5.9xlarge. Deep Lake atteint des performances d'écriture nettement plus rapides par rapport aux formats de tableau et comparables aux formats binaires tels que WebDataset [19] et FFCV Beton [39]
Comme le montre la figure 7, Deep Lake permet un chargement de données plus rapide dans une boucle d'entraînement PyTorch sans modèle. L'expérience a été réalisée sur une instance AWS P3.2xlarge avec un GPU Nvidia V100
carte. L'ensemble de données a généré de manière aléatoire 50 000 images 250x250x3 stockées sous forme de fichiers JPEG. La liste des bibliothèques dans lesquelles les benchmarks ont été effectués était Deep Lake, FFCV [39], Squirrel [75], Webdataset [19] et le chargeur de données natif PyTorch [58].
Dans cette expérience, comme le montre la figure 8, nous explorons différents backends de stockage pour le streaming à distance en utilisant le même ensemble de données que dans la section 6.2. MinIO [17] s'exécute sur une autre machine d'un réseau local. Notamment, Deep Lake atteint des performances similaires comme si les données étaient locales sur la machine par rapport à AWS S3. WebDataset et Deep Lake sont nettement plus lents lors de la diffusion en continu des données depuis
MinIO par rapport à AWS S3. Pour des références plus détaillées sur les chargeurs de données, nous recommandons une étude globale exhaustive des chargeurs de données réalisée par Ofeidis et al. [54].
Étant donné que Deep Lake a été conçu pour être axé sur le cloud, dans cette section et dans la suivante, nous démontrons les avantages qu'il offre pour la formation de modèles sur le cloud. Nous prenons l'ensemble de données ImageNet [35] et le stockons sur AWS S3 [1] en tant qu'original et format de stockage Tensor. L'ensemble de données contient 1,2 million d'images et d'étiquettes pour un total de 150 Go. Deep Lake atteint des performances de formation pratiquement similaires à celles si les données étaient locales sur la machine. Cela permet d'économiser jusqu'à 4 fois le temps et les coûts de calcul du GPU, comme le montre la figure 9.
Comme deuxième expérience, nous prenons l'ensemble de données LAION [67] contenant 400 millions de paires image-texte et entraînons CLIP [60], un modèle d'intégration image-texte avec 1 milliard de paramètres. L'ensemble de données d'origine est un tableau de fichiers Parquet avec une colonne d'URL d'images. Le téléchargement de l'ensemble de données à partir de la source a pris 100 heures, tandis que l'ingestion au format Tensor Storage n'a pris que 6 heures, pour une taille totale de 1,9 To. L'ensemble de données a été stocké sur AWS dans la région de l'est des États-Unis lors de la formation de la machine GPU dans la région centrale des États-Unis. Comme le montre la figure 10, Deep Lake atteint une utilisation élevée du GPU en diffusant 5 100 images/s sur 16 GPU Nvidia A100, sans modèle, jusqu'à 80 000 images/s par machine dans la même région.
Cet article est disponible sur arxiv sous licence CC 4.0.