Autoren:  (1) Sasun Hambardzumyan, Activeloop, Mountain View, CA, USA;  (2) Abhinav Tuli, Activeloop, Mountain View, CA, USA;  (3) Levon Ghukasyan, Activeloop, Mountain View, CA, USA;  (4) Fariz Rahman, Activeloop, Mountain View, CA, USA;.  (5) Hrant Topchyan, Activeloop, Mountain View, CA, USA;  (6) David Isayan, Activeloop, Mountain View, CA, USA;  (7) Mark McQuade, Activeloop, Mountain View, CA, USA;  (8) Mikayel Harutyunyan, Activeloop, Mountain View, CA, USA;  (9) Tatevik Hakobyan, Activeloop, Mountain View, CA, USA;  (10) Ivo Stranic, Activeloop, Mountain View, CA, USA;  (11) Davit Buniatyan, Activeloop, Mountain View, CA, USA.  Linktabelle   Zusammenfassung und Einleitung   Derzeitige Herausforderungen   Tensor-Speicherformat   Übersicht zum Deep Lake System   Anwendungsfälle für maschinelles Lernen   Leistungsbenchmarks   Diskussion und Einschränkungen   Ähnliche Projekte   Schlussfolgerungen, Danksagungen und Referenzen  6. LEISTUNGSBENCHMARKS  In diesem Abschnitt demonstrieren wir experimentell die Leistung von Deep Lake im großen Maßstab vom Zeitpunkt der Aufnahme in das Format bis zum Training im großen Maßstab im Vergleich zu anderen Datenladern und Formaten. Wir vergleichen Streaming-Datensätze aus verschiedenen Speicher-Backends und demonstrieren Leistungssteigerungen und Skalierbarkeit beim Training in der Cloud.  6.1 Aufnahmegeschwindigkeit in verschiedene Formate   10.000 Bilder aus dem FFHQ-Datensatz [43] wurden dekomprimiert und im NumPy-Format gespeichert. Jedes 1024x1024x3-Rohbild ist ein 3 MB großes Array. Dann wurden, wie in Abb. 6 gezeigt, die Bilder seriell in jedes Format geschrieben. Um die Leistung zu erhöhen, verwendeten wir TensorStore [23], um in die Formate Zarr [52] und N5 [24] zu schreiben. Die Experimente wurden auf der AWS c5.9xlarge-Maschine durchgeführt. Deep Lake erreicht eine deutlich schnellere Schreibleistung im Vergleich zu Array-Formaten und ist vergleichbar mit Binärformaten wie WebDataset [19] und FFCV Beton [39].  6.2 Vergleich lokaler Datenlader  Wie in Abb. 7 gezeigt, erreicht Deep Lake ein schnelleres Laden von Daten in einer PyTorch-Trainingsschleife ohne Modell. Das Experiment wurde auf einer AWS P3.2xlarge-Instanz mit einer Nvidia V100 GPU durchgeführt.   Karte. Der Datensatz enthält 50.000 zufällig generierte 250x250x3-Bilder, die als JPEG-Dateien gespeichert sind. Die Liste der Bibliotheken, in denen die Benchmarks durchgeführt wurden, umfasste Deep Lake, FFCV [39], Squirrel [75], Webdataset [19] und den nativen PyTorch-Dataloader [58].  6.3 Streambarer Datenlader von verschiedenen Standorten   In diesem Experiment, wie in Abb. 8 dargestellt, untersuchen wir verschiedene Speicher-Backends für Remote-Streaming mit demselben Datensatz wie in Abschnitt 6.2. MinIO [17] läuft auf einer anderen Maschine in einem lokalen Netzwerk. Bemerkenswert ist, dass Deep Lake im Vergleich zu AWS S3 eine ähnliche Leistung erzielt, als ob die Daten lokal auf der Maschine wären. Sowohl WebDataset als auch Deep Lake sind beim Streaming der Daten von   MinIO im Vergleich zu AWS S3. Für detailliertere Dataloader-Benchmarks empfehlen wir eine umfassende Dataloader-Übersichtsstudie von Ofeidis et al. [54].  6.4 ImageNet-Training in der Cloud  Da Deep Lake als Cloud-First-Lösung entwickelt wurde, zeigen wir in diesem und im nächsten Abschnitt die Vorteile, die es für das Trainieren von Modellen in der Cloud bietet. Wir nehmen den ImageNet-Datensatz [35] und speichern ihn auf AWS S3 [1] im Original- und Tensor-Speicherformat. Der Datensatz enthält 1,2 Millionen Bilder und Beschriftungen, insgesamt 150 GB. Deep Lake erreicht praktisch die gleiche Trainingsleistung, als ob die Daten lokal auf der Maschine wären. Dies spart bis zu 4x GPU-Rechenzeit und -Kosten, wie in Abb. 9 dargestellt.  6.5 Verteiltes Training eines großen multimodalen Datensatzes  Als zweites Experiment verwenden wir den LAION-Datensatz [67] mit 400 Millionen Bild-Text-Paaren und trainieren CLIP [60], ein Bild-Text-Einbettungsmodell mit 1 Milliarde Parametern. Der ursprüngliche Datensatz ist eine Tabelle mit Parquet-Dateien mit einer Spalte mit Bild-URLs. Der Download des Datensatzes von der Quelle dauerte 100 Stunden, während die Aufnahme in das Tensor-Storage-Format nur 6 Stunden dauerte, was einer Gesamtgröße von 1,9 TB entspricht. Der Datensatz wurde auf AWS in der Region US-Ost gespeichert, während die GPU-Maschine in der Region US-Zentral trainiert wurde. Wie in Abb. 10 gezeigt, erreicht Deep Lake eine hohe GPU-Auslastung durch das Streamen von 5.100 Bildern/s in 16 Nvidia A100 GPUs, während ohne Modell bis zu 80.000 Bilder/s pro Maschine in derselben Region möglich sind.  Dieses Dokument ist   . auf Arxiv unter der CC 4.0-Lizenz verfügbar

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Dataology.TECH

Dataology is the study of data. We publish the highest quality university papers & blog posts about the essence of data.

Dataology

Dieses Audio ist in der Originalsprache der Geschichte produziert!

Zu lang; Lesen

Boost your HackerNoon story @ $159.99! 🚀

Deep Lake, ein Lakehouse für Deep Learning: Leistungsbenchmarks

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Programming Community!

HackerNoon Decoded 2024: Celebrating Our Writing Community!

Welcome to HackerNoon Decoded: The Best of 2024 Tech Blogging

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps