paint-brush
Deep Lake, un Lakehouse pour le Deep Learning : benchmarks de performancespar@dataology
206 lectures

Deep Lake, un Lakehouse pour le Deep Learning : benchmarks de performances

Trop long; Pour lire

Les chercheurs présentent Deep Lake, un Lakehouse open source pour l'apprentissage profond, optimisant le stockage et le streaming de données complexes pour les cadres d'apprentissage profond.
featured image - Deep Lake, un Lakehouse pour le Deep Learning : benchmarks de performances
Dataology: Study of Data in Computer Science HackerNoon profile picture
0-item

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.

Tableau des liens

6. RÉFÉRENCES DE PERFORMANCE

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.

6.1 Vitesse d'ingestion vers différents formats

Figure 6 : Ingestion de 10 000 images de l'ensemble de données FFHQ [43] dans un format différent (inférieur, mieux)


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]

6.2 Comparaison des chargeurs de données locaux

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


Figure 7 : Vitesse d'itération des images par rapport à d'autres chargeurs de données (plus élevée, meilleure)


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].

6.3 Chargeur de données diffusable à partir de différents emplacements

Figure 8 : Streaming à partir de différents emplacements de stockage de données : Local FileSystem, AWS S3, MinIO (inférieur, meilleur)


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


Figure 9 : Formation sur ImageNet sur un S3 : AWS File Mode copie fichier par fichier à partir de S3 ; Le mode fichier rapide démarre immédiatement avec un entraînement plus lent ; Deep Lake fonctionne comme si les données étaient locales, bien qu'elles soient diffusées en continu (inférieur mieux)


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].

6.4 Formation ImageNet sur le cloud

É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.

6.5 Formation distribuée d'un grand ensemble de données multimodales

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.