Ein Überblick über die Dataloader-Landschaft: Dataloader

Linktabelle

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

2. DATENLADER

Beim Trainieren eines Deep-Learning-Modells muss der Datensatz aus dem Speicher gelesen und vorverarbeitet werden, bevor er als Eingabe an das Modell übergeben werden kann. Dieser Vorgang erfordert das Laden der gesamten Daten auf einmal in den Speicher. In den meisten Fällen und insbesondere bei großen Datensätzen entsteht aufgrund der begrenzten Speichermenge im System ein Speichermangel, was auch die Reaktionszeit des Systems verschlechtert. Dieser Engpass wird in Deep-Learning-Bibliotheken häufig durch den Einsatz eines sogenannten Dataloaders behoben. Diese Struktur bietet eine Möglichkeit, über den Datensatz zu iterieren, indem parallele Verarbeitung, Vorabruf, Batchverarbeitung und andere Techniken genutzt werden, um die Datenladezeit und den Speicheraufwand so weit wie möglich zu reduzieren (Paszke et al., 2019).

Das Hauptziel eines Dataloaders besteht darin, die Aktionen auszuführen, die für die Übertragung von Datenproben von einem Speicherort in den Speicher verantwortlich sind, der sich für das Training mit den Verarbeitungseinheiten am selben Ort befindet, um einen Stapel von Proben zu bilden, die in das Modell eingespeist werden. Diese Aktionen werden durch die Bandbreite des Speichersystems und insbesondere durch seine E/A-Leistung eingeschränkt. Abhängig von den Hardwarespezifikationen des Systems, dem Dateisystem, das es bedient, und dem Durchsatz der Verbindung mit den Recheneinheiten kann dies einen enormen Einfluss auf die Gesamtzeit haben, die zum Abschließen des Trainings benötigt wird.

Die folgende Spezifikation der Dataloader-Komponente konzentriert sich hauptsächlich auf PyTorch (torch.DataLoader() (PyTorch Core Team)), während das TensorFlow-Gegenstück (tf.Dataset() (Abadi et al., 2015)) zwar nicht dasselbe ist, aber große Ähnlichkeiten aufweist.

Beim Einsatz eines Dataloaders hat der Benutzer neben der Bereitstellung des Datensatzes als Eingabe auch die Möglichkeit, eine Reihe von Hyperparametern zu konfigurieren, die auf seine Bedürfnisse und Ressourcen zugeschnitten sind. Ein gemeinsamer Parameter, der in allen Dataloadern verfügbar ist, ist die Batchgröße, die, wie bereits erwähnt, die Anzahl der Samples definiert, die verwendet werden, bevor die internen Modellparameter aktualisiert werden. Dieser Parameter ist untrennbar mit dem Konzept des „Mini-Batch“ im stochastischen Gradientenabstieg (Hinton et al., 2012) verknüpft und daher einer der ersten Parameter, der normalerweise einer Feinabstimmung unterzogen wird, wenn bessere Trainingsergebnisse erzielt werden sollen.

Zweitens kann der Benutzer den Sampling-Ansatz definieren, der die Strategie zum Ziehen von Samples aus dem Datensatz und zum Einfügen in einen Batch bestimmt. Dies könnte die Auswahl von Samples anhand bestimmter Kriterien sowie einer Wahrscheinlichkeitsverteilung umfassen. In diesem Schritt besteht die Möglichkeit des Mischens, wobei die Samples vor jeder Datensatziteration neu angeordnet werden können, wobei das Ziel normalerweise darin besteht, die Generalisierung des Trainingsmodells zu verbessern. Ein weiterer Parameter ist die Collate/Padding-Funktion, die im Wesentlichen den Prozess des Verknüpfens aller einzelnen Samples in einem Batch angibt (denken Sie an das Stapeln von Vektoren zu einem Tensor), um ein einzelnes Element zu bilden, das als Eingabe für das Trainingsmodell verwendet wird. Darüber hinaus kann der Datenlader so konfiguriert werden, dass abgerufene Datensamples automatisch im fixierten (seitengesperrten) Speicher gespeichert werden, wodurch eine schnellere Datenübertragung auf CUDA-fähige Geräte ermöglicht wird.

Dataloader verfügen über eine Komponente namens „Worker“, deren Zweck es ist, diesen Datenübertragungsprozess zu optimieren. Worker sind Unterprozesse, die für das asynchrone Laden der Daten verantwortlich sind. Beim Erstellen einer Instanz eines Dataloaders hat der Benutzer die Möglichkeit, die Anzahl der Worker anzugeben, die erstellt werden und diesen Vorgang steuern. Wenn die Anzahl der Worker gleich Null ist, werden keine Unterprozesse erstellt, was wiederum bedeutet, dass das Abrufen der Daten synchron im selben Prozess erfolgt und die Recheneinheiten (GPU) daher warten müssen, bis das Laden der Daten abgeschlossen ist (PyTorch Core Team). Umgekehrt werden Unterprozesse in der gleichen Anzahl von Workern generiert, wodurch verhindert wird, dass der Berechnungscode durch das Laden der Daten blockiert wird. Dies wird erreicht, indem zukünftige Batches im Voraus abgerufen werden, damit sie bei Bedarf bereit sind.