Verteiltes Trainieren von Deep Learning-Modellen in Azure

Blob Storage
Container Registry
Machine Learning

Diese Referenzarchitektur zeigt, wie Sie ein verteiltes Training von Deep Learning-Modellen in mehreren Clustern mit GPU-fähigen virtuellen Computern durchführen. Bei dem Szenario handelt es sich zwar um Bildklassifizierung, doch die Lösung kann auch auf andere Deep Learning-Szenarien (etwa für die Segmentierung oder Objekterkennung) verallgemeinert werden.

Eine Referenzimplementierung für diese Architektur ist auf GitHub verfügbar.

Architektur

Architektur für verteiltes Deep Learning

Workflow

Diese Architektur umfasst folgende Dienste:

Azure Machine Learning Compute bildet das Herzstück dieser Architektur und sorgt für eine bedarfsgerechte Skalierung der Ressourcen. Azure Machine Learning Compute ist ein Dienst, der Sie beim Bereitstellen und Verwalten von VM-Clustern, beim Planen von Aufträgen, beim Erfassen der Ergebnisse, beim Skalieren der Ressourcen und beim Behandeln von Fehlern unterstützt. Er unterstützt GPU-fähige virtuelle Computer für Deep Learning-Workloads.

Blob Storage Standard wird zum Speichern der Protokolle und Ergebnisse verwendet. Blob Storage Premium wird zum Speichern der Trainingsdaten verwendet und mithilfe von blobfuse in die Knoten des Trainingsclusters eingebunden. Der Premium-Tarif von Blob Storage bietet eine bessere Leistung als der Standard-Tarif und wird für verteilte Trainingsszenarien empfohlen. Nach der Einbindung mittels „blobfuse“ werden die Trainingsdaten während der ersten Epoche auf die lokalen Datenträger des Trainingsclusters heruntergeladen und zwischengespeichert. Für jede nachfolgende Epoche werden die Daten von den lokalen Datenträgern gelesen, wobei es sich um die leistungsfähigste Option handelt.

Azure Container Registry wird zum Speichern des Docker-Image verwendet, mit dem Azure Machine Learning Compute das Training ausführt.

Komponenten

  • Azure Machine Learning ist eine offene Plattform zum Verwalten der Entwicklung und Bereitstellung von Machine Learning-Modellen im großen Stil. Die Plattform unterstützt häufig verwendete offene Frameworks und ermöglicht die automatisierte Featurisierung und Algorithmusauswahl. Sie können Machine Learning verwenden, um Modelle für verschiedene Ziele bereitzustellen, einschließlich Azure Container Instances.
  • Azure Blob Storage ist ein Dienst, der zu Azure Storage gehört. Blob Storage bietet einen optimierten Cloudobjektspeicher für große Mengen unstrukturierter Daten.
  • Container Registry ist ein cloudbasierter, privater Registrierungsdienst. Mithilfe von Container Registry können Sie Ihre privaten Docker-Containerimages und die zugehörigen Artefakte speichern und verwalten.

Szenariodetails

Szenario: Die Klassifizierung von Bildern ist im Bereich des maschinellen Sehens eine weit verbreitete Technik und wird häufig durch Trainieren eines auf dem Faltungsprinzip basierenden neuronalen Netzes (Convolutional Neural Network, CNN) umgesetzt. Bei besonders umfangreichen Modellen mit großen Datasets kann das Training mit einer einzelnen GPU Wochen oder Monate dauern. Manchmal sind die Modelle sogar so groß, dass gar keine sinnvollen Batchgrößen für die GPU möglich sind. In solchen Fällen lässt sich die Trainingsdauer mithilfe eines verteilten Trainings verkürzen.

In diesem spezifischen Szenario wird ein ResNet50-CNN-Modell unter Verwendung von Horovod mit dem ImageNet-Dataset sowie mit synthetischen Daten trainiert. In der Referenzimplementierung können Sie sehen, wie diese Aufgabe mithilfe von TensorFlow ausgeführt werden kann.

Für das verteilte Training von Deep Learning-Modellen gibt es verschiedene Möglichkeiten. Hierzu zählen unter anderem Ansätze mit parallelen Daten und parallelem Modell, die auf synchronen oder asynchronen Aktualisierungen basieren. Das gängigste Szenario ist derzeit das Training mit parallelen Daten und synchronen Aktualisierungen. Dieser Ansatz lässt sich am einfachsten implementieren und ist in den meisten Fällen ausreichend.

Beim verteilten Trainieren mit parallelen Daten und synchronen Aktualisierungen wird das Modell auf n Hardwaregeräten repliziert. Ein Minibatch mit Trainingsbeispielen wird auf n Mikrobatches aufgeteilt. Jedes Gerät führt Vorwärts- und Rückwärtsvorgänge für einen Mikrobatch aus. Nach Abschluss des Prozesses gibt das jeweilige Gerät die Aktualisierungen an die anderen Geräte weiter. Die Werte werden verwendet, um die aktualisierten Gewichtungen des gesamten Minibatchs zu berechnen, und die Gewichtungen werden modellübergreifend synchronisiert. Dieses Szenario wird in dem zugehörigen GitHub-Repository behandelt.

Verteiltes Training mit parallelen Daten

Diese Architektur kann auch für den Ansatz mit parallelem Modell und asynchronen Aktualisierungen verwendet werden. Beim verteilten Trainieren mit parallelem Modell wird das Modell auf n Hardwaregeräte aufgeteilt, wobei jedes Gerät über einen Teil des Modells verfügt. In der einfachsten Implementierung verfügt jedes Gerät über eine Schicht des Netzwerks, und Informationen werden während der Vorwärts- und Rückwärtsphasen zwischen Geräten ausgetauscht. Größere neuronale Netze können zwar auf diese Weise trainiert werden, dies geht jedoch zulasten der Leistung, da Geräte ständig darauf warten, dass andere Geräte entweder die Vorwärts- oder die Rückwärtsphase abschließen. Bei einigen erweiterten Techniken wird mithilfe synthetischer Gradienten versucht, dieses Problem zumindest teilweise zu entschärfen.

Das Training umfasst folgende Schritte:

  1. Erstellen von Skripts, die im Cluster ausgeführt werden und Ihr Modell trainieren.
  2. Schreiben von Trainingsdaten in Blob Storage.
  3. Erstellen eines Machine Learning-Arbeitsbereichs. In diesem Schritt wird auch eine Instanz von Container Registry erstellt, um Ihre Docker-Images zu hosten.
  4. Erstellen eines GPU-fähigen Machine Learning-Clusters.
  5. Übermitteln von Trainingsaufträgen. Für jeden Auftrag mit eindeutigen Abhängigkeiten wird ein neues Docker-Image erstellt und an Ihre Containerregistrierung gepusht. Während der Ausführung nutzt das entsprechende Docker-Image Ihr Skript und führt es aus.
  6. Alle Ergebnisse und Protokolle werden in Blob Storage geschrieben.

Überlegungen zum Trainingscluster

Azure bietet mehrere GPU-fähige VM-Typen, die zum Trainieren von Deep Learning-Modellen geeignet sind. Im Anschluss finden Sie Informationen zu den verschiedenen Preisen und zur jeweiligen Geschwindigkeit (in aufsteigender Reihenfolge):

Azure-VM-Serie NVIDIA-GPU
NC K80
NDs P40
NCsv2 P100
NCsv3 V100
NDv2 8x V100 (NVLink)
ND A100 v4 8x A100 (NVLink)

Es empfiehlt sich, das Training zunächst zentral zu skalieren, bevor Sie eine horizontale Skalierung durchführen. Versuchen Sie es also beispielsweise erst mit einer einzelnen V100-Instanz, bevor Sie einen Cluster mit K80-Instanzen verwenden. Ebenso sollten Sie die Verwendung eines einzelnen NDv2 anstelle von acht NCsv3-VMs in Erwägung ziehen.

Das folgende Diagramm zeigt die Leistungsunterschiede für verschiedene GPU-Typen auf der Grundlage von Benchmarktests, die mit TensorFlow und Horovod durchgeführt wurden. Das Diagramm zeigt den Durchsatz von 32 GPU-Clustern für verschiedene Modelle mit unterschiedlichen GPU-Typen und MPI-Versionen. Die Modelle wurden in TensorFlow 1.9 implementiert.

Durchsatzergebnisse für TensorFlow-Modelle in GPU-Clustern

Jede VM-Serie aus der obigen Tabelle verfügt über eine Konfiguration mit InfiniBand. Verwenden Sie die InfiniBand-Konfigurationen beim Ausführen von verteilten Trainings, um die Kommunikation zwischen Knoten zu beschleunigen. InfiniBand erhöht außerdem die Skalierungseffizienz des Trainings für die Frameworks, die dafür geeignet sind. Ausführliche Informationen finden Sie im Benchmarkvergleich für InfiniBand.

Überlegungen

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Speicher

Beim Trainieren von Deep Learning-Modellen wird oftmals der Speicherort der Trainingsdaten außer Acht gelassen. Ist der Speicher den Anforderungen der GPUs nicht gewachsen, geht dies unter Umständen zulasten der Trainingsleistung.

Azure Machine Learning Compute unterstützt viele Speicheroptionen. Laden Sie für eine optimale Leistung die Daten lokal auf jeden Knoten herunter. Dieser Prozess kann jedoch mühsam sein, da Sie die Daten aus dem Blob Storage auf jeden Knoten herunterladen müssen. Mit dem ImageNet-Dataset kann dieser Prozess eine beträchtliche Zeit dauern. Standardmäßig bindet Machine Learning Speicher so ein, dass die Daten lokal zwischengespeichert werden. In der Praxis werden die Daten daher nach der ersten Epoche aus dem lokalen Speicher gelesen. In Kombination mit Blob Storage Premium bietet diese Zusammenstellung einen guten Kompromiss zwischen Benutzerfreundlichkeit und hoher Leistung.

Obwohl Azure Machine Learning Compute den Bob Storage Standard mithilfe des blobfuse-Adapters einbinden kann, empfiehlt es sich nicht, den Standard-Tarif für verteiltes Training zu verwenden, da die Leistung in der Regel nicht ausreichend ist, um den erforderlichen Durchsatz zu verarbeiten. Verwenden Sie den Premium-Tarif als Speicher für Trainingsdaten, wie zuvor im Architekturdiagramm gezeigt. Einen Blogbeitrag mit einem Vergleich von Durchsatz und Wartezeit zwischen den beiden Tarifen finden Sie unter Block Blob Storage Premium – ein neuer Leistungsstandard.

Container Registry

Immer wenn ein Machine Learning-Arbeitsbereich bereitgestellt wird, wird ebenfalls ein Satz abhängiger Ressourcen (Blob Storage, Key Vault, Container Registry und Application Insights) bereitgestellt. Alternativ dazu können Sie auch vorhandene Azure-Ressourcen verwenden und diese dem neuen Machine Learning-Arbeitsbereich während seiner Erstellung zuordnen.

Standardmäßig wird Container Registry im Basic-Tarif bereitgestellt. Für umfangreiches Deep Learning wird empfohlen, Ihren Arbeitsbereich für die Verwendung von Container Registry im Premium-Tarifs anzupassen. Es bietet eine deutlich höhere Bandbreite, mit der Sie Docker-Images schnell über die Knoten Ihres Trainingclusters pullen können.

Datenformat

Für große Datasets empfiehlt es sich oft, Datenformate wie TFRecords und Petastorm zu verwenden, die gegenüber mehreren kleinen Imagedateien eine bessere E/A-Leistung bieten.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Verwenden eines HBI-fähigen Arbeitsbereichs (High Business Impact, mit hoher geschäftlicher Auswirkung)

In Szenarien, in denen vertrauliche Daten verwendet werden, sollten Sie erwägen, einen Machine Learning-Arbeitsbereich als Arbeitsbereich mit hohen geschäftlichen Auswirkungen (HBI) zu bestimmen, indem Sie bei dessen Erstellung das hbi_workspace-Flag auf „true“ festlegen. In einem HBI-fähigen Arbeitsbereich werden u. a. lokale Ablagedatenträger (scratch) von Computeclustern verschlüsselt, IP-Filterung wird ermöglicht, und die Menge der von Microsoft gesammelten Diagnosedaten wird reduziert. Weitere Informationen finden Sie unter Datenverschlüsselung mit Azure Machine Learning.

Verschlüsseln von ruhenden und übertragenen Daten

Verschlüsseln Sie vertrauliche ruhende Daten, d. h. im Blob-Speicher. Verwenden Sie bei jedem Verschieben von Daten zwischen Speicherorten SSL, um die Datenübertragung zu schützen. Weitere Informationen finden Sie im Azure Storage-Sicherheitsleitfaden.

Schützen von Daten in einem virtuellen Netzwerk

Bei Produktionsbereitstellungen empfiehlt es sich ggf., den Machine Learning-Cluster in einem Subnetz eines von Ihnen angegebenen virtuellen Netzwerks bereitzustellen. Bei diesem Setup können die Computeknoten im Cluster sicher mit anderen virtuellen Computern oder mit einem lokalen Netzwerk kommunizieren. Sie können auch Dienst- oder private Endpunkte für alle zugeordneten Ressourcen verwenden, um den Zugriff aus einem virtuellen Netzwerk zu gewähren.

Kostenoptimierung

Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Verwenden Sie den Azure-Preisrechner, um die Kosten für die Ausführung ihrer Deep Learning-Workload abzuschätzen. Überlegungen zur Kostenplanung und -verwaltung, die sich speziell auf Machine Learning beziehen, finden Sie unter Planen der Verwaltung von Kosten für Azure Machine Learning. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.

Blob Storage Premium

Bei Blob Storage Premium fallen zwar höhere Datenspeicherkosten an, dafür sind die Transaktionskosten niedriger als die Datenspeicherkosten auf der heißen Speicherebene von Blob Storage Standard. Für Workloads mit hohen Transaktionsraten kann Blob Storage Premium daher günstiger sein. Weitere Informationen finden Sie unter Azure Blob Storage – Preise.

Container Registry

Container Registry ist in den Tarifen „Basic“, „Standard“ und „Premium“ erhältlich. Orientieren Sie sich bei der Wahl des Tarifs an Ihren Speicheranforderungen. Wählen Sie Premium aus, wenn Sie Georeplikation oder einen erhöhten Durchsatz für Docker-Pullvorgänge über parallele Knoten hinweg benötigen. Zusätzlich fallen die üblichen Netzwerkgebühren an. Weitere Informationen finden Sie unter Azure Container Registry – Preise.

Azure Machine Learning Compute

In dieser Architektur ist Azure Machine Learning Compute wahrscheinlich der Hauptkostentreiber. Die Implementierung erfordert ein Cluster von GPU-Computeknoten. Der Preis dieser Knoten wird durch ihre Anzahl und die von Ihnen ausgewählte VM-Größe bestimmt. Weitere Informationen zu den VM-Größen mit GPUs finden Sie unter Für GPU optimierte VM-Größen sowie in den Preisdetails für virtuelle Computer in Azure.

In der Regel verfolgen Deep Learning-Workloads den Fortschritt nach jeder Epoche oder nach einigen Epochen. Diese Methode beschränkt die Auswirkungen unerwarteter Unterbrechungen auf das Training. Sie können diese Methode mit der Verwendung von VMs mit niedriger Priorität für Machine Learning-Computecluster kombinieren. VMs mit niedriger Priorität verwenden die überschüssige Azure-Kapazität zu erheblich reduzierten Preisen. Sie können aber auch vorzeitig entfernt werden, wenn die Kapazitätsanforderungen steigen.

Erstklassige Betriebsprozesse

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

Beim Ausführen Ihres Auftrags ist es wichtig, den Fortschritt zu überwachen und zu überprüfen, ob alles wie erwartet funktioniert. Es kann jedoch eine Herausforderung sein, über einen Cluster von aktiven Knoten hinweg zu überwachen.

Im Rahmen von Machine Learning stehen viele Möglichkeiten zur Verfügung, Ihre Experimente zu instrumentieren. Die beiden Datenströme „stdout“ und „stderr“ aus Ihren Skripts werden automatisch protokolliert. Diese Protokolle werden automatisch mit ihrem Arbeitsbereichsblobspeicher synchronisiert. Sie können sich diese Dateien entweder über das Azure-Portal ansehen, oder sie mithilfe des Python SDK oder der Machine Learning-CLI herunterladen oder streamen. Wenn Sie Ihre Experimente mithilfe von Tensorboard protokollieren, werden diese Protokolle automatisch synchronisiert. Sie können direkt auf sie zugreifen oder das Machine Learning SDK verwenden, um sie in eine Tensorboard-Sitzung zu streamen.

Effiziente Leistung

Leistungseffizienz ist die Fähigkeit Ihrer Workload, auf effiziente Weise eine den Anforderungen der Benutzer entsprechende Skalierung auszuführen. Weitere Informationen finden Sie unter Übersicht über die Säule „Leistungseffizienz“.

Bei der Skalierungseffizienz des verteilten Trainings werden aufgrund der Netzwerkauslastung niemals 100 Prozent erreicht: Die Synchronisierung des gesamten Modells zwischen Geräten wird zu einem Engpass. Daher eignet sich das verteilte Training am besten für:

  • Große Modelle, die nicht mit einer angemessenen Batchgröße auf einer einzelnen GPU trainiert werden können.
  • Probleme, die nicht durch eine einfache, parallele Verteilung des Modells gelöst werden können.

Verteilte Trainings sollten nicht für Hyperparameter-Suchvorgänge verwendet werden. Die Skalierungseffizienz wirkt sich auf die Leistung aus und macht einen verteilten Ansatz weniger effizient als das separate Trainieren mehrerer Modellkonfigurationen.

Eine Möglichkeit zur Steigerung der Skalierungseffizienz ist die Erhöhung der Batchgröße. Nehmen Sie diese Anpassung jedoch vorsichtig vor. Die Erhöhung der Batchgröße ohne Anpassung der anderen Parameter kann die endgültige Leistung des Modells beeinträchtigen.

Bereitstellen dieses Szenarios

Die Referenzimplementierung dieser Architektur ist auf GitHub verfügbar. Führen Sie die dort beschriebenen Schritte aus, um ein verteiltes Training von Deep Learning-Modellen in mehreren Clustern mit GPU-fähigen virtuellen Computern durchzuführen.

Nächste Schritte

Diese Architektur gibt ein trainiertes, in Blob Storage gespeichertes Modell aus. Dieses Modell kann für Echtzeitbewertungen oder für Batchbewertungen operationalisiert werden. Weitere Informationen finden Sie in den folgenden Referenzarchitekturen:

Informationen zu Architekturen, die verteiltes Training oder Deep Learning umfassen, finden Sie in den folgenden Ressourcen: