Die Hyundai Motor Company mit Sitz in Seoul, Südkorea, ist einer der größten Automobilhersteller der Welt. Sie haben massiv personelle und materielle Ressourcen in das Rennen um die Entwicklung selbstfahrender Autos, auch als autonome Fahrzeuge bekannt, investiert.

Einer der beim autonomen Fahren häufig verwendeten Algorithmen ist die semantische Segmentierung, bei der es um die Annotation jedes Pixels eines Bildes mit einer Objektklasse geht. Diese Klassen können Straße, Person, Auto, Gebäude, Vegetation, Himmel usw. sein. In einem typischen Entwicklungszyklus testet das Team der Hyundai Motor Company regelmäßig die Genauigkeit und sammelt zusätzliche Bilder, um die unzureichende Vorhersageleistung in bestimmten Situationen zu korrigieren. Dies kann jedoch eine Herausforderung darstellen, da oft nicht genug Zeit bleibt, um alle neuen Daten aufzubereiten, während gleichzeitig genügend Zeit bleibt, das Modell zu trainieren und die geplanten Fristen einzuhalten. Zusammen mit dem Amazon ML-Lösungslabor, hat Hyundai Motor Company dieses Problem gelöst, indem das Training mit der skalierbaren AWS Cloud deutlich beschleunigt wurde und Amazon Sage Maker, einschließlich der neuen SageMaker-Bibliothek für Datenparallelität.

Lösungsüberblick

SageMaker ist eine vollständig verwaltete ML-Plattform, die Kundenherausforderungen löst, indem sie den „schweren Aufwand“ bei der Verwaltung einer verteilten Recheninfrastruktur und der Überwachung und Fehlerbehebung des Schulungsjobs reduziert. Für diesen Anwendungsfall verwenden wir die SageMaker-Datenparallelitätsbibliothek und Amazon SageMaker-Debugger um die technischen Herausforderungen der Hyundai Motor Company zu lösen und ihre Geschäftsziele auf kosteneffektive Weise zu erreichen.

SageMaker bietet verteilte Trainingsbibliotheken für Datenparallelität und Modellparallelität. In diesem Fall wird das zu trainierende Modell in den Speicher einer einzelnen GPU eingepasst, aber die Menge an Trainingsdaten ist groß, was bedeutet, dass eine Trainingsepoche mit einer einzelnen GPU zu lange dauert. Dies ist ein typisches Trainingsbeispiel, bei dem datenparalleles verteiltes Training die Gesamtdauer des Trainingsjobs reduzieren kann. Die Datenparallelität von SageMaker erreicht dies, indem Trainingsdaten auf mehrere GPU-Instanzen verteilt und dasselbe Modell auf jeder GPU unter Verwendung des zugewiesenen Datasets trainiert wird. Die SageMaker-Datenparallelitätsbibliothek wurde entwickelt, um die Hochgeschwindigkeits-AWS-Netzwerkinfrastruktur zu nutzen, die eine nahezu lineare Skalierbarkeit mit mehr verwendeten GPUs bietet.

Die Trainingsarchitektur verwendet SageMaker und verwendet optional Amazon FSx für Lustre zur Datenspeicherung. Wir gebrauchen Amazon Simple Storage-Service (Amazon S3) als permanenter Datenspeicher. Wir haben den auf PyTorch Data Parallel basierenden Trainingscode mit nur wenigen Codezeilen in die SageMaker Data Parallelism Library konvertiert und mit 93 GPU-Instanzen oder insgesamt 8 GPUs eine Skalierungseffizienz von bis zu 64 % erreicht. Das folgende Diagramm zeigt die AWS-Architektur, die für verteiltes Training bereitgestellt wird:

Im Gegensatz zum Trainieren eines Modells mit einer einzelnen GPU kann das Training mit mehreren oder verteilten GPUs zugrunde liegende Leistungsprobleme aufdecken, die in einer einzelnen GPU nicht beobachtet wurden. Daher ist es wichtig, die Ressourcenauslastung zusammen mit Trainingsmetriken zu überwachen, um die teuren GPU-Ressourcen vollständig auszulasten und die gewünschte Modellleistung zu erzielen.

Der SageMaker Debugger und seine Profiling-Funktionen ermöglichen Deep-Learning-Wissenschaftlern und -Ingenieuren, systembezogene oder modellbezogene Leistungsprobleme zu überwachen, zu verfolgen und zu analysieren, während ein Trainingsjob ausgeführt wird. Das Aktivieren der Debugging-Ausgabe erfordert keine Codeänderungen in den Trainingsskripten. Echtzeit-Überwachung und Visualisierung werden bereitgestellt von Amazon SageMaker-Studio, und Sie können über API-Aufrufe zur benutzerdefinierten Visualisierung oder Analyse auf die gesammelten Debug- und Profiling-Daten zugreifen. Sie können den Profiler während eines laufenden Trainingsjobs ein- oder ausschalten und sogar die Profilerstellungskonfiguration ändern, um den durch die Profilerstellungsfunktion auf Framework-Ebene des Debuggers verursachten Overhead zu minimieren.

Verteiltes Training mit der SageMaker-Bibliothek für Datenparallelität

Um die SageMaker-Datenparallelitätsbibliothek zu verwenden, ist nur eine kleine Codeänderung erforderlich, die das Modell mit dem SageMaker umschließt DistributedDataParallel Klasse und führt die Initialisierung durch. Das folgende Codebeispiel zeigt, wie dies mit einem PyTorch-Trainingsskript geschieht. Die Benutzererfahrung auf der API ähnelt der von PyTorch DistributedDataParallel.

# Importing SageMaker distributed training library
from smdistributed.dataparallel.torch.parallel.distributed import DistributedDataParallel as DDP
import smdistributed.dataparallel.torch.distributed as dist # Initializing distributed training process group
dist.init_process_group() # Setting the local rank as the local GPU ID
local_rank = dist.get_local_rank() # Wrapping the model for distributed training
model = DDP(Net())
torch.cuda.set_device(local_rank)
model.cuda(local_rank)

Wenn Sie ein erfahrener Benutzer von verteiltem PyTorch- oder TensorFlow-Training sind, stellen Sie möglicherweise eine Frage wie „Wie richte ich einen Cluster für verteiltes Training ein und wie starte ich Trainingsprozesse für jede Instanz im Cluster?“ In SageMaker müssen Sie lediglich die Anzahl der Instanzen und den Instanztyp angeben und SageMaker mitteilen, welche verteilte Trainingsstrategie verwendet werden soll. SageMaker übernimmt das schwere Heben, und diese Konfiguration wird sowohl auf PyTorch als auch auf TensorFlow angewendet. Siehe folgenden Beispielcode:

estimator = PyTorch(instance_count=4, instance_type='ml.p4d.24xlarge', distribution={ 'smdistributed':{ 'dataparallel':{ 'enabled': True } } })

Nachdem wir das Trainingsskript aktualisiert haben, sollten wir entscheiden, wie wir auf das Dataset im S3-Bucket zugreifen. Die gebräuchlichste Methode besteht darin, dass SageMaker Datasets von Ihrem S3-Bucket in den angeschlossenen Speicher oder den internen NVMe-SSD-Speicher kopieren lässt, wenn der Trainingsjob initiiert wird. Diese Speicherung ist für alle Ausbildungsjobs nicht dauerhaft. Diese Methode wird als SageMaker-Dateimodus bezeichnet.

In unserem Fall ist der Datensatz mit einer großen Anzahl von Dateien insgesamt etwa 300 GB groß, was etwa 1 Stunde dauert, um die Datenkopie in die Trainingsinstanzen abzuschließen, bevor das Modelltraining beginnen kann. Das eigentliche Trainingsskript wird erst ausgeführt, nachdem dieser Schritt abgeschlossen ist. Die Datenladezeit ist vernachlässigbar, wenn wir ein umfangreiches Training durchführen, das Tage, Wochen oder sogar länger dauert. Aber während der Entwicklungs- und Testphase ist dieser Zeitaufwand wichtig.

Um dadurch nicht gebremst zu werden, können wir eine der folgenden Maßnahmen ergreifen:

• Verringern Sie die Größe des Datensatzes
• Verwenden Sie den SageMaker Pipe-Modus, der Daten streamt, anstatt sie zu kopieren
• Verwenden Sie FSx for Lustre, anstatt Daten von Amazon S3 zu kopieren

Wir wählten FSx für Lustre für das wiederholte Experiment. Wir haben das FSx for Lustre-Dateisystem mit den Daten in einem S3-Bucket erstellt und es für jeden Trainingsjob an Trainingsinstanzen angehängt. Da das FSx for Lustre-Dateisystem über SageMaker-Trainingsjobs hinweg bestehen bleibt (im Gegensatz zu dem an Trainingsinstanzen angehängten Speicher), können wir mehrere Experimente ohne Initialisierungsverzögerung ausführen.

Nachdem wir die Codekonvertierung abgeschlossen und sichergestellt haben, dass der Trainingscode ohne Probleme ausgeführt wird, wechseln wir in den Dateimodus, damit wir den internen NVMe-SSD-Speicher für eine optimale E/A-Leistung verwenden können. Dies ist auch einfach durch Ändern der SageMaker-Schätzerkonfiguration möglich. Auch hier ist keine Codeänderung am Trainingsskript erforderlich. Siehe folgenden Code:

# Using Amazon FSx for Lustre
train_fs = FileSystemInput(file_system_id='file system id', file_system_type='FSxLustre', directory_path='/fsx/', file_system_access_mode='ro') estimator.fit(inputs={'train': train_fs}) # Using S3
estimator.fit(inputs={'train': 's3://your-bucket-name/prefix/'})

Trainingsleistungsanalyse und -tuning

Für die Verwendung des Debuggers sind keine Änderungen am Trainingscode erforderlich. Debugger wird entweder konfiguriert, wenn Sie den Schätzer definieren, oder über Studio oder die Debugger-API aktiviert oder deaktiviert, während ein Trainingsjob ausgeführt wird. Wir haben das Debugger-Systemprofiling für CPU-Auslastung, GPU-Auslastung, GPU-Speicherauslastung und I/O-Wartezeit mit 500-Millisekunden-Intervallen über einen SageMaker-Schätzer aktiviert, um ein vollständiges Bild der Trainingsjobleistung zu erhalten. Dies geschieht durch die Definition ProfilerConfig und setze es auf den Schätzer:

profiler_config = ProfilerConfig( system_monitor_interval_millis=500) estimator = PyTorch( ... profiler_config=profiler_config)

Wir haben die Auslastung der Systemressourcen mithilfe der Visualisierungsfunktion von Studio im Debugger überwacht, um ein anormales Muster zu finden. Die Zeit für jeden Schritt wurde beim Multi-GPU-Training länger als beim Single-GPU-Training. Die CPUs erreichten während des Multi-GPU-Trainings die ganze Zeit 100 %, während die GPUs nicht ausgelastet waren. Dieses Muster wurde während des Trainings über die Heatmap der CPU- und GPU-Auslastung in Studio schnell identifiziert. Wir könnten eine Ursachenanalyse mit Hilfe der Framework-Profiling-Funktion von Debugger durchführen, die eine Profiling-Ausgabe auf Python- und Deep-Learning-Framework-Ebene liefert.

Amazon ML Solutions Lab und Hyundai Motor Company tauchten tief in die Debugger-Daten und den Trainingscode ein und fanden die Ursache im benutzerdefinierten Datenlader. Dieses Problem verursachte keinen Performance-Overhead in einem Trainingskontext mit einer GPU. Nachdem das Problem mit dem CPU-Aushunger behoben war, wurde die Auslastung der Systemressourcen wieder normal und die Trainingsleistung wurde verbessert. Dieser Aufwand führte dazu, dass die Multi-GPU-Trainingsgeschwindigkeit bei gleicher Menge an GPU-Ressourcen auf das Doppelte erhöht wurde.

Die folgende Abbildung zeigt die CPU- und GPU-Auslastungsdiagramme und Heatmaps. Das linke ist aus dem problematischen Training und das rechte aus dem Training mit dem angewendeten Fix.

Zusammenfassung

In diesem Beitrag haben wir die Herausforderungen bei diesem komplexen Anwendungsfall detailliert beschrieben und wie wir die SageMaker-Datenparallelitätsbibliothek verwendet haben, um das Training zu beschleunigen. Wir haben auch reale Techniken geteilt, um Engpässe zu identifizieren und die Trainingsleistung zu optimieren. Als Ergebnis erreichten wir mit nur fünfmal so vielen Instanzen eine 10-mal höhere Trainingsgeschwindigkeit.

„Wir verwenden Computer-Vision-Modelle für die Szenensegmentierung, die für das Szenenverständnis wichtig ist“, sagte Jinwook Choi, Senior Research Engineer bei Hyundai Motor Company. „Früher dauerte es 57 Minuten, um das Modell für eine Epoche zu trainieren, was uns verlangsamte. Mit der Datenparallelitätsbibliothek von Amazon SageMaker und mit Hilfe von Amazon ML Solutions Lab konnten wir in 6 Minuten mit optimiertem Trainingscode auf fünf ml.p3.16xlarge-Instances trainieren. Durch die 10-fache Verkürzung der Schulungszeit können wir während des Entwicklungszyklus mehr Zeit für die Datenvorbereitung aufwenden.“

Weitere Informationen zu verwandten Funktionen von SageMaker finden Sie unter:

Über Amazon ML Solutions Lab

Amazon ML-Lösungslabor bringt Ihr Team mit ML-Experten zusammen, um Ihnen bei der Identifizierung und Implementierung der wertvollsten ML-Chancen Ihres Unternehmens zu helfen. Wenn Sie Hilfe bei der beschleunigten Nutzung von ML in Ihren Produkten und Prozessen benötigen, wenden Sie sich bitte an die Amazon ML-Lösungslabor.

Über die Autoren

Muhyun Kim ist Datenwissenschaftler bei Amazon Machine Learning Solutions Lab. Er löst die verschiedenen geschäftlichen Probleme der Kunden durch Anwendung von maschinellem Lernen und Deep Learning und hilft ihnen, sich weiterzubilden.

Jiyang Kang ist ein Deep-Learning-Architekt bei Amazon Machine Learning Solutions Lab. Mit seiner Erfahrung beim Entwerfen globaler Unternehmens-Workloads in AWS ist er für das Entwerfen und Implementieren von ML-Lösungen für die neuen Geschäftsprobleme der Kunden verantwortlich.

Youngjoon Choi ist ein Lösungsarchitekt für AWS und hilft Kunden, ihre Anwendungsfälle mit AWS-Services zu entwerfen und zu erstellen. Youngjoon deckt durch die Erfahrung eines früheren Data Scientists insbesondere ein breites Spektrum von KI/ML-Anwendungsfällen für Unternehmenskunden ab, einschließlich Fertigung, Gesundheitswesen und Finanzdienstleistungen.

Aditya Bindal ist Senior Product Manager für AWS Deep Learning. Er arbeitet an Produkten, die es Kunden erleichtern, Deep-Learning-Modelle in AWS zu trainieren. In seiner Freizeit verbringt er gerne Zeit mit seiner Tochter, spielt Tennis, liest historische Romane und reist gern.

Nathalie Rauschmayr ist Applied Scientist bei AWS, wo sie Kunden bei der Entwicklung von Deep-Learning-Anwendungen unterstützt.

Jongmo Kim ist ein Deep-Learning-Forschungsingenieur bei der Hyundai Motor Company und arbeitet an der Entwicklung von Produkten für autonomes Fahren/Parken.

PlatonAi. Web3 neu erfunden. Datenintelligenz verstärkt.

Klicken Sie hier, um darauf zuzugreifen.

Quelle: https://aws.amazon.com/blogs/machine-learning/hyundai-reduces-training-time-for-autonomous-driving-models-using-amazon-sagemaker/