Optimierungstechniken für die Schulung von CheXNet auf Dell C4140 mit Nvidia V100-GPUs

Der Artikel wurde von Rakshith Vasudev & John Lockman, HPC AI Innovation Lab, im Oktober 2019 verfasst.

Die Daten-Pipeline ist entscheidend, um die maximale Performance der Accelerator zu erzielen:

Was sind TF-Daten und warum sollten diese möglichst verwendet werden?

Während neue Rechengeräte (z. B. GPUs und TPUs) es ermöglichen, neuronale Netzwerke immer schneller zu trainieren, kann es bei der CPU-Verarbeitung zu Engpässen kommen. Die tf.data-API bietet Nutzern Bausteine für den Entwurf von Eingabe-Pipelines, die die CPU effektiv nutzen und jeden Schritt des ETL-Prozesses optimieren.

Um einen Trainingsschritt durchzuführen, müssen zunächst die Trainingsdaten extrahiert und transformiert und dann in ein Modell eingespeist werden, das auf einem Accelerator ausgeführt wird. In einer naiven synchronen Implementierung befindet sich der Accelerator jedoch im Leerlauf, während die CPU die Daten vorbereitet. Genauso umgekehrt, während der Accelerator das Modell trainiert, befindet sich die CPU im Leerlauf. Die Dauer des Trainingsschritts ist daher die Summe der CPU-Vorverarbeitungszeit und der Accelerator-Trainingszeit.

Mit Pipelining überlappen sich die Vorverarbeitung und die Modellausführung eines Trainingsschritts. Während der Accelerator den Trainingsschritt N durchführt, bereitet die CPU die Daten für Schritt N+1 vor. Auf diese Weise wird die Dauer des Trainingsschritts auf das Maximum (im Gegensatz zur Summe) des Trainings und der Zeit für das Extrahieren und Transformieren der Daten reduziert.

Ohne Pipelining bleiben CPU und GPU/TPU einen Großteil der Zeit im Leerlauf:

Abb. 1: Durch die sequenzielle Ausführung bleibt die GPU häufig im Leerlauf.

Mit Pipelining verringert sich die Leerlaufzeit erheblich:

Abb. 2: Mit Pipelining überlappen sich CPU- und GPU-Auslastung, wodurch die GPU-Auslastung erhöht wird.

Die tf.data-API bietet über die tf.data.Dataset.prefetch-Transformation einen Software-Pipelining-Mechanismus, der verwendet werden kann, um die Zeit, zu der Daten erzeugt werden, von der Zeit, zu der sie verbraucht werden, zu entkoppeln. Insbesondere verwendet die Transformation einen Hintergrund-Thread und einen internen Puffer, um Elemente aus dem Eingabe-Datensatz vor dem angeforderten Zeitpunkt vorab abzurufen.

Weitere Informationen finden Sie hier: https://www.tensorflow.org/guide/performance/datasets.

Wenn die von Tensorflow bereitgestellten Richtlinien befolgt werden, kann eine Daten-Pipeline wie die folgende erstellt werden (alter Ansatz):
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/old_approach.py.

Bei diesem Ansatz, der auch als alter Ansatz bezeichnet wird, führt die TF-Datenpipeline Folgendes aus (vorausgesetzt, der Datensatz des Thorax-Röntgenbilds ist eine Sequenz von TFRecords):

1. Ruft die absolute Liste der Dateinamen ab
2. Erstellt einen Datensatz aus der Liste der Dateinamen mithilfe von TFRecordDataset()
3. Erstellt einen neuen Datensatz, der Bilder lädt und formatiert, indem diese vorverarbeitet werden
4. Fragmentiert den Datensatz
5. Mischt den Datensatz beim Training neu
6. Wiederholt den Datensatz
7. Stapelt den Datensatz
8. Ruft den Datensatz für die Batch-Größe vorab ab

Es handelt sich hierbei jedoch nicht um den leistungsstärksten Code. Er führt zu Stillständen und häufigen GPU-Auslastungen von 0 %. Im Grunde genommen werden die Accelerator nicht effektiv genutzt.

Um die TF-Daten-Pipeline korrekt einzurichten, folgen wir dem Ansatz der offiziellen Tensorflow-Modelle, insbesondere dem für ResNet.  Der Unterschied zwischen dem alten und dem neuen Ansatz besteht darin, wie die Daten-Pipeline eingerichtet wird, bevor sie in das Modell eingespeist wird.

So sieht der neue Ansatz aus:
https://github.com/dellemc-hpc-ai/code-examples/blob/master/cheXNet-snippets/new_approach.py.

Der offizielle TensorFlow-Modellansatz, der auch als neuer Ansatz bezeichnet wird, sieht wie folgt aus:

1. Ruft die absolute Liste der Dateinamen ab
2. Erstellt einen Datensatz aus der Liste der Dateinamen mithilfe von from_tensor_slices()
3. Die Fragmentierung (Sharding) erfolgt im Vorfeld.
4. Der Datensatz wird während des Trainings neu gemischt.
5. Der Datensatz wird dann parallel verschachtelt, d. h. es werden mehrere Dateien (definiert durch Zykluslänge) verschachtelt und verarbeitet, um sie zu transformieren und einen TFRecord-Datensatz zu erstellen.
6. Der Datensatz wird dann vorab abgerufen. Die Puffergröße legt fest, wie viele Datensätze vorab abgerufen werden, was in der Regel die Mindest-Batch-Größe des Jobs ist.
7. Der Datensatz wird erneut gemischt. Die Details des Mischens werden von der Puffergröße gesteuert.
8. Der Datensatz wird wiederholt.  Der Datensatz wird für das Training bis num_epochs wiederholt.
9. Der Datensatz wird einem gleichzeitigen map_and_batch() unterzogen, das die TFRecord-Dateien analysiert, wodurch wiederum die Bilder vorab verarbeitet und gestapelt werden.
10. Das vorverarbeitete Bild steht als Datensatz bereit und wird erneut vorab abgerufen.

Nachfolgend finden Sie einen Vergleich der Performance des alten und neuen Ansatzes anhand der offiziellen TF-Modelle.

Abb. 3: Mit dem neuen Ansatz ist eine nahezu lineare Skalierung zu erwarten.

Wie zu sehen ist, kommt es beim alten Ansatz zu einer erheblichen Performanceeinbuße und es gibt überhaupt keine Skalierungsmöglichkeit. GPUs würden häufig nur wenig bis gar keine Auslastung aufweisen, was zu einer Flatline-Performance führt. Wenn die Berechnung auf einer GPU effizienter gemacht wird, wird auch die Berechnung auf mehreren GPUs auf mehreren Nodes effizienter, wenn die Kommunikation optimal gehandhabt wird.
Die parallele Vorverarbeitung der CPUs, der Vorabruf der verarbeiteten Daten aus dem Arbeitsspeicher und die komplexe Matrix-Multiplikation der GPUs mit schneller Kommunikation sind weitere Aspekte, die diesen neuen Ansatz für die Skalierung von Multinodes attraktiver machen.

Weitere zu beachtende Punkte zur Erzielung einer optimalen Performance:

Die richtige Umgebung ist wichtig:

Die Umgebung, in der Ihre Jobs ausgeführt werden, ist genauso wichtig wie die Jobs selbst, da die richtigen Bibliotheken/Module sich auf die Trainingsperformance auswirken. Auch die neuesten CUDA-bezogenen Bibliotheken können dazu beitragen, die Performance zu verbessern.

Befolgen Sie dieses Tutorial für die Installation, wenn Sie keine passende Umgebung eingerichtet haben.

Verwenden der korrekten Bindungsparameter für MPI:

MPI ist eine Kommunikationsbibliothek, die Horovod bei der Verteilung von Jobs unterstützt. Es wurden verschiedene Bindungs- und Zuordnungsparameteroptionen untersucht und der beste Parameter für den C4140 war die Zuordnung nach Sockel. Die empfohlene Einrichtung ist wie folgt:
mpirun --map-by socket -np x python pyfile.py --pyoptions

Stellen Sie sicher, dass nur ein Prozess auf einer GPU ausgeführt wird:

Wenn mehr als ein Prozess auf einer GPU ausgeführt wird, kann es zu GPU-Ressourcenkonflikten kommen. Es wird GPU-Speicher verbraucht und effektiv werden nicht mehr Bilder pro Stapel eingebunden, was zu einer Beeinträchtigung der GPU-Performance führt. Tensorflow 1.13.1 wurde zwar untersucht, aber zu diesem Zeitpunkt schien ein Fehler vorhanden zu sein. Es wurde mehr als ein Prozess pro GPU gestartet.

Zusammenfassung:

• Eine ordnungsgemäße Einrichtung der Daten-Pipeline ist entscheidend, um Performancesteigerungen zu erzielen.
• Die Einrichtung der passenden Umgebung trägt ebenfalls zu einer besseren Performance bei.
• Die Verwendung der korrekten Bindungsparameter für MPI sorgt für eine bessere Performance.
• Profilieren und beheben Sie Engpässe, wenn GPUs nicht vollständig ausgelastet werden.