Ein Überblick über die Data-Loader-Landschaft: Zusammenfassung und Einführung

Linktabelle

• Zusammenfassung und Einleitung
• Datenlader
• Versuchsaufbau
• Numerische Ergebnisse
• Diskussion
• Ähnliche Projekte
• Schlussfolgerung, Danksagungen und Referenzen
• A. Numerische Ergebnisse, Fortsetzung

ABSTRAKT

Dataloader, die für das Verschieben von Daten vom Speicher in GPUs während des Trainings von Machine-Learning-Modellen zuständig sind, könnten der Schlüssel zu einer drastischen Leistungssteigerung bei Trainingsjobs sein. Jüngste Fortschritte sind vielversprechend, da sie nicht nur die Trainingszeit erheblich verkürzen, sondern auch neue Funktionen wie das Laden von Daten aus Remote-Speichern wie S3 bieten. In diesem Artikel sind wir die Ersten, die den Dataloader als separate Komponente im Deep-Learning-Workflow (DL) hervorheben und seine Struktur und Funktionen skizzieren. Abschließend bieten wir einen umfassenden Vergleich der verschiedenen verfügbaren Dataloading-Bibliotheken, ihre Kompromisse in Bezug auf Funktionalität, Benutzerfreundlichkeit und Leistung sowie die daraus gewonnenen Erkenntnisse.

1. EINLEITUNG

Das Trainieren eines (Deep-)Machine-Learning-Modells erfordert einen Datensatz, ein Modell und die Hardware, die bei realen Problemen eine oder mehrere GPUs umfasst.

Wir sind immer daran interessiert, die Gesamtrechenzeit zu reduzieren, die zum Trainieren eines Modells erforderlich ist. Dies ist aus mehreren Gründen wünschenswert: unter anderem geringere Kosten, einfachere Iteration und bessere Zugänglichkeit für kleinere Teams.

Die Beziehung zwischen den Hauptkomponenten einer ML-Pipeline und der Laufzeit ist oft eindeutig: Ein größerer Datensatz dauert länger, ein größeres Modell dauert länger und eine schnellere GPU reduziert die Gesamtlaufzeit. Ein Schlüsselstück in diesem Puzzle, das oft übersehen wird, ist das Bindeglied zwischen all diesen Teilen: der Datenlader. Der Datenlader ist dafür verantwortlich, die Daten aus seinem permanenten Speicher (RAM, Festplatte oder Netzwerk) zu laden, die erforderlichen Transformationen anzuwenden und die transformierten Daten an das entsprechende Gerät zu senden, damit das Modell sie aufnehmen kann.

Die meisten Entwickler gehen davon aus, dass der Standard-Dataloader in ihrem jeweiligen Machine-Learning-Framework (Pytorch, Tensorflow, Jax) bereits für ihre Anwendung optimiert ist und verlassen sich nicht oft auf Dataloader von Drittanbietern. Interessanterweise hat sich kürzlich gezeigt, dass Dataloader einer der größeren Engpässe von ML-Pipelines sein können (Mohan et al., 2020). Infolgedessen haben wir viele neue Bibliotheken und Forschungsprojekte gesehen, die sich der Optimierung und Verbesserung der Dataloader-Leistung widmen.

Beispielsweise gelang es FFCV (Leclerc et al., 2022), einer neuen Open-Source-Bibliothek, die von einem Forschungsteam am MIT entwickelt wurde, ImageNet in einem Bruchteil der Zeit zu trainieren, die mit dem standardmäßigen PyTorch-Datenlader erforderlich gewesen wäre. Solche Erfolge können die Betriebskosten von Unternehmen und Forschungsteams, die auf Infrastruktur als Service (IaaS) wie Amazon Web Services (AWS) und Google Cloud Platform (GPC) angewiesen sind, drastisch senken.

Ein weiteres vielversprechendes Feature von Dataloadern ist die Möglichkeit, remote gespeicherte Daten zu laden, beispielsweise aus einem S3-Bucket. Dies hat viele praktische Vorteile: Die Zeit zum lokalen Einrichten des Datensatzes wird vermieden, die erforderliche Festplattenkapazität auf dem Computer wird reduziert und das Risiko, dass Teammitglieder unterschiedliche Versionen desselben Datensatzes verwenden, wird verringert. Der natürliche Nachteil des Streamens der Daten während des Trainings besteht darin, dass die Netzwerkübertragungsgeschwindigkeiten normalerweise langsamer sind als die Festplatten-E/A, und daher sollte das Training des Modells länger dauern. Interessanterweise haben wir beobachtet, dass einige Bibliotheken wie Hub (Team, 2022a) und Deep Lake (Hambardzumyan et al., 2022) in einigen Szenarien eine bessere Leistung über das Netzwerk erzielen als der standardmäßige Pytorch-Dataloader, der Daten lokal liest. Dies ist möglich, weil es dem Dataloader gelingt, die erforderlichen Daten vorab abzurufen, bevor die GPU sie benötigt. Wir werden in Abschnitt 5 eine ausführlichere Diskussion anbieten.

Nicht alle Bibliotheken unterstützen das Remote-Laden, und die, die es tun, lassen sich nicht unbedingt in dieselben Remote-Speicherdienste integrieren. Da die Anzahl der verfügbaren Bibliotheken, die Dataloader implementieren, wächst, haben wir uns vorgenommen, einen umfassenden Benchmark zu erstellen, um den aktuellen Stand der Technik aufzuzeigen, welche Probleme bereits gelöst zu sein scheinen, und um die vielversprechendsten Bereiche für Verbesserungen in der zukünftigen Forschung zu entdecken.

An dieser Stelle sei erwähnt, dass ein besonderer Unterschied zu unseren Experimenten aus anderen Arbeiten wie (Kumar & Sivathanu, 2020), (Mohan et al., 2020) darin besteht, dass wir uns auf Jobs konzentrieren, die auf kleinen bis mittleren Workstations mit begrenzter Kapazität (GPU, RAM, SSD) laufen. Diese spiegeln eher die Hardware wider, die den meisten Einzelpersonen und kleinen Teams in der Branche zur Verfügung steht, deren Budget die Nutzung großer Cluster nicht zulässt.

1.1 Beiträge

Unsere Beiträge können wir wie folgt zusammenfassen:

• Open-Source-Code: Wir haben einen Open-Source-Benchmark erstellt, der die beliebtesten Datenladebibliotheken in Pytorch[1] vergleicht. Das Projekt bleibt für die Community verfügbar, sodass neue Bibliotheken und Datensätze hinzugefügt werden können, wenn das Interesse daran steigt. Wir beabsichtigen auch, die in diesen Benchmarks erzielten numerischen Ergebnisse nach größeren Updates für eine der in diesem Dokument verglichenen Bibliotheken zu aktualisieren.

• Durchführbarkeit von Remote-Training: Wir zeigen, dass es unter vernünftigen Umständen möglich ist, ein maschinelles Lernmodell mit einem Datenstrom über eine öffentliche Internetverbindung zu trainieren. Insbesondere weisen wir auf die Auswirkungen der Datenverarbeitung hin. Unser Ergebnis unterscheidet sich von dem von (Mohan et al., 2020), da wir nicht davon ausgehen, dass der Datensatz nach dem Download lokal zwischengespeichert wird.

• Hyperparameter-Optimierung für Geschwindigkeit: Traditionelle Hyperparameter-Ansätze zielen darauf ab, die Gesamtgenauigkeit des trainierten Modells zu erhöhen. In diesem Dokument zeigen wir, wie wir auch die Geschwindigkeit (verarbeitete Samples im Laufe der Zeit) als Proxy für die Gesamtlaufzeit optimieren können. Diese Optimierung ist hardwareabhängig, daher ist es sinnvoll, sie vor lang laufenden Jobs durchzuführen. Dieser Prozess sollte mindestens eine Größenordnung schneller sein als gleichwertige Time-to-Acurracy-Metriken.

[1] Github Repository: https://github.com/smartnets/dataloaderbenchmarks