Verbessern Sie die Preisleistung Ihres Modelltrainings mit heterogenen Amazon SageMaker-Clustern

Dieser Beitrag wurde gemeinsam mit Chaim Rand von Mobileye verfasst.

Bestimmte Workloads für maschinelles Lernen (ML), wie z. B. das Trainieren von Computer-Vision-Modellen oder Reinforcement Learning, beinhalten häufig die Kombination der GPU- oder Beschleuniger-intensiven Aufgabe des neuronalen Netzwerkmodelltrainings mit der CPU-intensiven Aufgabe der Datenvorverarbeitung, wie z. B. Bilderweiterung. Wenn beide Arten von Aufgaben auf demselben Instance-Typ ausgeführt werden, kommt es bei der Datenvorverarbeitung zu einem Engpass auf der CPU, was zu einer geringeren GPU-Auslastung führt. Dieses Problem verschlimmert sich mit der Zeit, da der Durchsatz neuerer GPU-Generationen stärker wächst als der von CPUs.

Um dieses Problem anzugehen, haben wir im Juli 2022 ins Leben gerufen heterogene Cluster für Amazon Sage Maker Modelltraining, mit dem Sie Trainingsjobs starten können, die verschiedene Instance-Typen in einem einzigen Job verwenden. Dadurch können Teile der Datenvorverarbeitungspipeline ausgelagert werden rechneroptimiert Instance-Typen, während die Task Deep Neural Network (DNN) weiter ausgeführt wird GPU oder beschleunigtes Rechnen Instanztypen. Unsere Benchmarks zeigen einen Preis-Leistungs-Vorteil von bis zu 46 %, nachdem heterogene Cluster in einem CPU-gebundenen TensorFlow-Computer-Vision-Modelltraining aktiviert wurden.

Für einen ähnlichen Anwendungsfall Mobileye, ein Entwicklungsunternehmen für autonome Fahrzeugtechnologien, hatte Folgendes zu teilen:

„Durch die Verlagerung des CPU-gebundenen Deep-Learning-Computer-Vision-Modelltrainings auf mehrere Instanztypen (CPU- und GPU/ML-Beschleuniger) unter Verwendung von a tf.data.service basierten Lösung, die wir entwickelt haben, ist es uns gelungen, die Schulungszeit um 40 % zu reduzieren und gleichzeitig die Schulungskosten um 30 % zu senken. Wir freuen uns über heterogene Cluster, die es uns ermöglichen, diese Lösung auf Amazon SageMaker auszuführen.“

— KI-Technik, Mobileye

In diesem Beitrag diskutieren wir folgende Themen:

• Wie heterogene Cluster helfen, CPU-Engpässe zu beseitigen
• Wann sollten heterogene Cluster verwendet werden und andere Alternativen
• Referenzimplementierungen in PyTorch und TensorFlow
• Ergebnisse von Performance-Benchmarks
• Heterogene Cluster bei Mobileye

AWS beschleunigte Recheninstanz Familie umfasst Beschleuniger von benutzerdefinierten AWS-Chips (AWS-Inferenz, AWS-Training), NVIDIA (GPUs), Und Gaudi-Beschleuniger von Habana Labs (ein Unternehmen von Intel). Beachten Sie, dass wir in diesem Beitrag die Begriffe GPU und Beschleuniger synonym verwenden.

Wie heterogene Cluster Engpässe bei der Datenverarbeitung beseitigen

Data Scientists, die Deep-Learning-Modelle trainieren, zielen darauf ab, die Kosteneffizienz des Trainings zu maximieren und die Trainingszeit zu minimieren. Um dies zu erreichen, ist ein grundlegendes Optimierungsziel eine hohe GPU-Auslastung, die teuerste und knappste Ressource innerhalb der Amazon Elastic Compute-Cloud (Amazon EC2)-Instanz. Dies kann bei ML-Workloads schwieriger sein, die die Vorwärts- und Rückwärtsausbreitung des klassischen GPU-intensiven neuronalen Netzwerkmodells mit CPU-intensiven Aufgaben kombinieren, wie z. B. Datenverarbeitung und Erweiterung in Computer Vision oder Ausführen einer Umgebungssimulation in Reinforcement Learning. Diese Workloads können am Ende CPU-gebunden sein, wobei mehr CPU zu höherem Durchsatz und schnellerem und billigerem Training führen würde, da vorhandene Beschleuniger teilweise im Leerlauf sind. In einigen Fällen können CPU-Engpässe durch den Wechsel zu einem anderen Instance-Typ mit einem höheren CPU:GPU-Verhältnis behoben werden. Es gibt jedoch Situationen, in denen der Wechsel zu einem anderen Instance-Typ aufgrund der Architektur, des Speichers oder der Netzwerkabhängigkeiten der Instance-Familie möglicherweise nicht möglich ist.

In solchen Situationen müssen Sie die CPU-Leistung erhöhen, indem Sie Instance-Typen mischen: Instances mit GPUs zusammen mit CPU. Zusammengenommen führt dies zu einem insgesamt höheren CPU:GPU-Verhältnis. Bis vor kurzem waren SageMaker-Schulungsjobs darauf beschränkt, Instanzen eines einzelnen ausgewählten Instanztyps zu haben. Mit heterogenen Clustern von SageMaker können Data Scientists problemlos einen Trainingsjob mit mehreren Instanztypen ausführen, wodurch einige der vorhandenen CPU-Aufgaben von den GPU-Instanzen auf dedizierte rechenoptimierte CPU-Instanzen ausgelagert werden können, was zu einer höheren GPU-Auslastung und schnelleren und kostengünstigeren Ergebnissen führt. effizientes Training. Darüber hinaus können Sie mit der zusätzlichen CPU-Leistung Vorverarbeitungsaufgaben, die traditionell als vorbereitender Schritt für das Training offline durchgeführt wurden, zu einem Teil Ihrer Trainingsaufgabe machen. Dies beschleunigt das Iterieren und Experimentieren sowohl bei der Datenvorverarbeitung als auch bei DNN-Trainingsannahmen und Hyperparametern.

Betrachten Sie beispielsweise einen leistungsstarken GPU-Instance-Typ, ml.p4d.24xlarge (96 vCPU, 8 x NVIDIA A100 GPUs) mit einem CPU:GPU-Verhältnis von 12:1. Nehmen wir an, Ihr Trainingsjob benötigt 20 vCPUs, um genügend Daten vorzuverarbeiten, damit eine GPU zu 100 % ausgelastet bleibt. Um alle 8 GPUs zu 100 % auszulasten, benötigen Sie daher einen Instance-Typ mit 160 vCPUs. ml.p4d.24xlarge fehlen jedoch 64 vCPUs oder 40 %, wodurch die GPU-Auslastung auf 60 % begrenzt wird, wie links im folgenden Diagramm dargestellt. Würde das Hinzufügen einer weiteren ml.p4d.24xlarge-Instanz helfen? Nein, da das CPU:GPU-Verhältnis des Jobs gleich bleiben würde.

Bei heterogenen Clustern können wir zwei ml.c5.18xlarge (72 vCPU) hinzufügen, wie rechts im Diagramm gezeigt. Die Nettogesamt-vCPU in diesem Cluster beträgt 210 (96+2*72), was zu einem CPU:GPU-Verhältnis von 30:1 führt. Jede dieser rechenoptimierten Instanzen wird mit einer CPU-intensiven Aufgabe zur Datenvorverarbeitung ausgelagert und ermöglicht eine effiziente GPU-Nutzung. Trotz der zusätzlichen Kosten des ml.c5.18xlarge ermöglicht die höhere GPU-Auslastung eine schnellere Verarbeitung und damit höhere Preis-Leistungs-Vorteile.

Wann sollten heterogene Cluster verwendet werden und andere Alternativen

In diesem Abschnitt erklären wir, wie Sie einen CPU-Engpass identifizieren, und erörtern dessen Lösung mithilfe von Instance-Typ-Scale-up im Vergleich zu heterogenen Clustern.

Der schnelle Weg, einen CPU-Engpass zu identifizieren, besteht darin, CPU und GPU zu überwachen Nutzungsmetriken für SageMaker-Schulungsjobs in Amazon CloudWatch. Sie können auf diese Ansichten über zugreifen AWS-Managementkonsole innerhalb des Instanzmetrik-Hyperlinks der Trainingsjobseite. Wählen Sie die relevanten Metriken aus und wechseln Sie von der 5-Minuten- zur 1-Minuten-Auflösung. Beachten Sie, dass die Skalierung 100 % pro vCPU oder GPU beträgt, sodass die Auslastungsrate für eine Instanz mit 4 vCPUs/GPUs bis zu 400 % betragen kann. Die folgende Abbildung ist ein solches Beispiel aus CloudWatch-Metriken, bei denen die CPU zu etwa 100 % ausgelastet ist, was auf einen CPU-Engpass hinweist, während die GPU nicht ausgelastet ist.

Zur detaillierten Diagnose führen Sie die Trainingsjobs mit aus Amazon SageMaker-Debugger um den Ressourcenauslastungsstatus, Statistiken und Framework-Vorgänge zu profilieren, indem Sie eine Profilerkonfiguration hinzufügen, wenn Sie einen SageMaker-Estimator mit dem SageMaker Python SDK erstellen. Nachdem Sie den Schulungsauftrag gesendet haben, überprüfen Sie das Ergebnis Profiler-Bericht für CPU-Engpässe.

Wenn Sie zu dem Schluss kommen, dass Ihr Job von einem höheren CPU:GPU-Rechenverhältnis profitieren könnte, sollten Sie zunächst eine Skalierung auf einen anderen Instance-Typ in derselben Instance-Familie in Erwägung ziehen, falls einer verfügbar ist. Wenn Sie Ihr Modell beispielsweise auf ml.g5.8xlarge (32 vCPUs, 1 GPU) trainieren, sollten Sie eine Skalierung auf ml.g5.16xlarge (64 vCPUs, 1 GPU) in Betracht ziehen. Wenn Sie Ihr Modell mit der Multi-GPU-Instanz ml.g5.12xlarge (48 vCPUs, 4 GPUs) trainieren, sollten Sie eine Skalierung auf ml.g5.24xlarge (96 vCPUs, 4 GPUs) in Betracht ziehen. Beziehen Sie sich auf die G5 Instance-Familienspezifikation für weitere Details.

Manchmal ist Hochskalieren keine Option, da es in derselben Instance-Familie keinen Instance-Typ mit einem höheren vCPU:GPU-Verhältnis gibt. Wenn Sie das Modell beispielsweise auf ml.trn1.32xlarge, ml.p4d.24xlarge oder ml.g5.48xlarge, sollten Sie heterogene Cluster für das SageMaker-Modelltraining in Betracht ziehen.

Neben der Skalierung möchten wir darauf hinweisen, dass es weitere Alternativen zu einem heterogenen Cluster wie NVIDIA gibt DALI, das die Bildvorverarbeitung auf die GPU auslagert. Weitere Informationen finden Sie unter Überwindung von Engpässen bei der Datenvorverarbeitung mit TensorFlow Data Service, NVIDIA DALI und anderen Methoden.

Um die Entscheidungsfindung zu vereinfachen, beachten Sie das folgende Flussdiagramm.

So verwenden Sie heterogene SageMaker-Cluster

Um schnell loszulegen, können Sie direkt zu den in diesem Beitrag bereitgestellten TensorFlow- oder PyTorch-Beispielen springen.

In diesem Abschnitt führen wir Sie anhand eines einfachen Beispiels durch die Verwendung eines heterogenen SageMaker-Clusters. Wir gehen davon aus, dass Sie bereits wissen, wie man ein Modell mit dem SageMaker Python SDK und der Estimator-Klasse trainiert. Wenn nicht, siehe Verwenden des SageMaker-Python-SDK vor dem Fortfahren.

Vor dieser Funktion haben Sie die Estimator-Klasse des Trainingsjobs mit initialisiert InstanceCount und InstanceType-Parameter, was implizit davon ausgeht, dass Sie nur einen einzigen Instance-Typ (einen homogenen Cluster) haben. Mit der Veröffentlichung von heterogenen Clustern haben wir das Neue eingeführt sagemaker.instance_group.InstanceGroup Klasse. Dies stellt eine Gruppe aus einer oder mehreren Instanzen eines bestimmten Instanztyps dar, die für eine logische Rolle ausgelegt sind (z. B. Datenverarbeitung oder neuronale Netzwerkoptimierung). Sie können zwei oder mehr Gruppen haben und einen benutzerdefinierten Namen für jede Instanzgruppe angeben, die Instanz Typ und die Anzahl der Instanzen für jede Instanzgruppe Weitere Informationen finden Sie unter Verwenden des SageMaker-Python-SDK und Verwenden der Low-Level-SageMaker-APIs.

Nachdem Sie die Instanzgruppen definiert haben, müssen Sie Ihr Trainingsskript ändern, um die SageMaker Informationen zur Trainingsumgebung dazu gehört auch eine heterogene Clusterkonfiguration. Die Konfiguration enthält Informationen wie die aktuellen Instanzgruppen, die aktuellen Hosts in jeder Gruppe und in welcher Gruppe sich der aktuelle Host mit seiner Rangfolge befindet. Sie können Logik in Ihr Trainingsskript einbauen, um die Instanzgruppen bestimmten Trainings- und Datenverarbeitungsaufgaben zuzuweisen. Darüber hinaus muss Ihr Trainingsskript für die Kommunikation zwischen Instanzgruppen oder verteilte Datenlademechanismen sorgen (z. B. tf.data.service in TensorFlow oder generisch gRPC-Client-Server) oder ein anderes Framework (z. B. Apache Funken).

Lassen Sie uns ein einfaches Beispiel für das Starten eines heterogenen Trainingsjobs und das Lesen der Umgebungskonfiguration zur Laufzeit durchgehen.

1. Beim Definieren und Starten des Trainingsjobs konfigurieren wir zwei Instanzgruppen, die als Argumente für den SageMaker-Estimator verwendet werden:

   from sagemaker.instance_group import InstanceGroup
   data_group = InstanceGroup("data_group", "ml.c5.18xlarge", 2)
   dnn_group = InstanceGroup("dnn_group", "ml.p4d.24xlarge", 1)
   
   from sagemaker.pytorch import PyTorch
   estimator = PyTorch(...,
       entry_point='launcher.py',
       instance_groups=[data_group, dnn_group]
   )

2. Auf dem Einstiegspunkt-Trainingsskript (named launcher.py) lesen wir die heterogene Clusterkonfiguration, um festzustellen, ob die Instanz den Vorverarbeitungs- oder den DNN-Code ausführt:

   from sagemaker_training import environment
   env = environment.Environment()
   if env.current_instance_group == 'data_group': ...;

Lassen Sie uns damit die Aufgaben zusammenfassen, die SageMaker für Sie erledigt, und die Aufgaben, für die Sie verantwortlich sind.

SageMaker führt die folgenden Aufgaben aus:

1. Stellen Sie verschiedene Instanztypen gemäß der Instanzgruppendefinition bereit.
2. Stellen Sie Eingabekanäle für alle oder bestimmte Instanzgruppen bereit.
3. Verteilen Sie Trainingsskripts und Abhängigkeiten an Instanzen.
4. Richten Sie einen MPI-Cluster für eine bestimmte Instanzgruppe ein, falls definiert.

Sie sind für folgende Aufgaben verantwortlich:

1. Ändern Sie Ihr Skript zum Starten des Trainingsjobs, um Instanzgruppen anzugeben.
2. Implementieren Sie eine verteilte Datenpipeline (z. B. tf.data.service).
3. Ändern Sie Ihr Einstiegspunktskript (siehe launcher.py im Beispiel-Notebook) zu einem einzelnen Einstiegspunkt, der auf allen Instanzen ausgeführt wird, erkennt, in welcher Instanzgruppe er ausgeführt wird, und das relevante Verhalten auslöst (z. B. Datenverarbeitung oder DNN-Optimierung).
4. Wenn die Trainingsschleife beendet ist, müssen Sie sicherstellen, dass Ihr Einstiegspunktprozess auf allen Instances in allen Instance-Gruppen beendet wird. Dies ist wichtig, da SageMaker wartet, bis alle Instanzen die Verarbeitung abgeschlossen haben, bevor es den Auftrag als abgeschlossen markiert und die Abrechnung stoppt. Das launcher.py Das Skript in den Beispiel-Notebooks TensorFlow und PyTorch stellt eine Referenzimplementierung der Signalisierung von Datengruppeninstanzen bereit, die beendet werden sollen, wenn DNN-Gruppeninstanzen ihre Arbeit beenden.

Beispiel-Notebooks für heterogene SageMaker-Cluster

In diesem Abschnitt geben wir Ihnen eine Zusammenfassung Beispiel Notizbücher sowohl für TensorFlow- als auch für PyTorch ML-Frameworks. In den Notizbüchern finden Sie die Implementierungsdetails, exemplarische Vorgehensweisen zur Funktionsweise des Codes, Codeausschnitte, die Sie in Ihren Schulungsskripts wiederverwenden könnten, Flussdiagramme und Kostenvergleichsanalysen.

Beachten Sie, dass Sie in beiden Beispielen nicht erwarten sollten, dass das Modell auf sinnvolle Weise konvergiert. Unsere Absicht ist nur, den Durchsatz der Datenpipeline und der neuronalen Netzwerkoptimierung, ausgedrückt in Epochen-/Schrittzeit, zu messen. Sie müssen Benchmarks mit Ihrem eigenen Modell und Datensatz durchführen, um Preis-Leistungs-Vorteile zu erzielen, die Ihrer Workload entsprechen.

Heterogener Cluster mit einem tf.data.service-basierten verteilten Datenlader (TensorFlow)

Dieser Notizbuch zeigt, wie ein heterogener Cluster für das SageMaker-Training mit TensorFlow implementiert wird tf.data.service basierte verteilte Datenpipeline. Wir trainieren ein Deep-Learning-Computer-Vision-Modell resnet50 das erfordert eine CPU-intensive Datenerweiterung. Es verwendet Horwod für verteilte Datenparallelität mit mehreren GPUs.

Wir führen die Workload in zwei Konfigurationen aus: zuerst als homogener Cluster, einzelne ml.p4d.24xlarge-Instanz, unter Verwendung eines Standards tf.data Pipeline, die CPU-Engpässe aufzeigt, die zu einer geringeren GPU-Auslastung führen. Im zweiten Durchlauf wechseln wir mithilfe eines heterogenen SageMaker-Clusters von einem einzelnen Instanztyp zu zwei Instanzgruppen. Diese Ausführung verlagert einen Teil der Datenverarbeitung auf zusätzliche CPU-Instanzen (unter Verwendung von tf.data.service).

Anschließend vergleichen wir die homogenen und heterogenen Konfigurationen und ermitteln die wichtigsten Preis-Leistungs-Vorteile. Wie in der folgenden Tabelle gezeigt, ist der heterogene Job (86 ms/Schritt) 2.2-mal schneller zu trainieren als der homogene Job (192 ms/Schritt), wodurch das Training eines Modells um 46 % günstiger wird.

Beispiel 1 (TF)	ml.p4d.24xl	ml.c5.18xl	Preis pro Stunde*	Durchschnittliche Schrittzeit	Kosten pro Schritt	Verbesserung der Preisleistung
Homogene	1	0	$37.688	192 ms	$0.201	.
Heterogen	1	2	$45.032	86 ms	$0.108	46%

* Preis pro Stunde basiert auf us-east-1 SageMaker On-Demand-Preise

Diese Beschleunigung wird durch die Nutzung der zusätzlichen vCPU, die von der Datengruppe bereitgestellt wird, und einer schnelleren Vorverarbeitung ermöglicht. Siehe die Notizbuch für weitere Details und Grafiken.

Heterogener Cluster mit einem gRPC-Client-Server-basierten verteilten Datenladeprogramm (PyTorch)

Dieser Notizbuch zeigt eine Beispielworkload mit einem heterogenen Cluster für das SageMaker-Training unter Verwendung eines gRPC-Client-Server-basierten verteilten Datenladeprogramms. Dieses Beispiel verwendet eine einzelne GPU. Wir verwenden das PyTorch-Modell auf der Grundlage des Folgenden offizielles MNIST-Beispiel. Der Trainingscode wurde geändert, um die Datenvorverarbeitung stark zu belasten. Wir trainieren dieses Modell sowohl im homogenen als auch im heterogenen Clustermodus und vergleichen die Preisleistung.

In diesem Beispiel sind wir davon ausgegangen, dass die Workload nicht von mehreren GPUs profitieren kann und von einer bestimmten GPU-Architektur (NVIDIA V100). Wir führten sowohl homogene als auch heterogene Trainingsjobs durch und stellten wichtige Preis-Leistungs-Vorteile fest, wie in der folgenden Tabelle dargestellt. Der heterogene Job (1.19 s/Schritt) lässt sich 6.5-mal schneller trainieren als der homogene Job (0.18 s/Schritt), wodurch das Trainieren eines Modells um 77 % günstiger wird.

Beispiel 2 (PT)	ml.p3.2xl	ml.c5.9xl	Preis pro Stunde*	Durchschnittliche Schrittzeit	Kosten pro Schritt	Verbesserung der Preisleistung
Homogene	1	0	$3.825	1193 ms	$0.127	.
Heterogen	1	1	$5.661	184 ms	$0.029	77%

* Preis pro Stunde basiert auf us-east-1 SageMaker On-Demand-Preise

Dies ist möglich, weil wir bei einer höheren CPU-Anzahl 32 Data Loader Worker (im Vergleich zu 8 bei ml.p3.2xlarge) verwenden könnten, um die Daten vorzuverarbeiten, und die GPU in regelmäßigen Abständen nahe 100 % ausgelastet zu halten. Siehe die Notizbuch für weitere Details und Grafiken.

Heterogene Cluster bei Mobileye

Mobileye, ein Unternehmen von Intel, entwickelt fortschrittliche Fahrerassistenzsysteme (ADAS) und autonome Fahrzeugtechnologien mit dem Ziel, die Transportbranche zu revolutionieren, Straßen sicherer zu machen und Leben zu retten. Diese Technologien werden durch ausgeklügelte Computer Vision (CV)-Modelle ermöglicht, die mit SageMaker auf große Datenmengen trainiert werden, die darin gespeichert sind Amazon Simple Storage-Service (Amazon S3). Diese Modelle verwenden modernste Deep-Learning-Techniken für neuronale Netze.

Wir haben festgestellt, dass bei einem unserer CV-Modelle der CPU-Engpass hauptsächlich durch eine starke Datenvorverarbeitung verursacht wurde, die zu nicht ausgelasteten GPUs führte. Für diese spezifische Workload begannen wir mit der Suche nach alternativen Lösungen, bewerteten verteilte Datenpipeline-Technologien mit heterogenen Clustern auf Basis von EC2-Instanzen und entwickelten Referenzimplementierungen für beide TensorFlow und PyTorch. Die Veröffentlichung des heterogenen SageMaker-Clusters ermöglicht es uns, diese und ähnliche Workloads auf SageMaker auszuführen, um verbesserte Preis-Leistungs-Vorteile zu erzielen.

Überlegungen

Mit der Einführung der heterogenen Cluster-Funktion bietet SageMaker viel mehr Flexibilität beim Mischen und Abgleichen von Instance-Typen innerhalb Ihres Trainingsjobs. Beachten Sie jedoch Folgendes, wenn Sie diese Funktion verwenden:

• Die Funktion für heterogene Cluster ist über SageMaker verfügbar PyTorch und TensorFlow Framework-Schätzerklassen. Unterstützte Frameworks sind PyTorch v1.10 oder höher und TensorFlow v2.6 oder höher.
• Alle Instanzgruppen verwenden dasselbe Docker-Image.
• Alle Instanzgruppen verwenden dasselbe Trainingsskript. Daher sollte Ihr Trainingsskript geändert werden, um zu erkennen, zu welcher Instanzgruppe es gehört, und Fork entsprechend ausführen.
• Die Hostnamen der Trainingsinstanzen (z. B. alog-1, algo-2 usw.) werden zufällig zugewiesen und geben nicht an, zu welcher Instanzgruppe sie gehören. Um die Rolle der Instanz abzurufen, empfehlen wir, während der Laufzeit ihre Instanzgruppenmitgliedschaft abzurufen. Dies ist auch bei der Überprüfung von Anmeldungen relevant Cloudwatch, da der Name des Protokollstreams [training-job-name]/algo-[instance-number-in-cluster]-[epoch_timestamp] hat den Hostnamen.
• Eine verteilte Trainingsstrategie (normalerweise ein MPI-Cluster) kann nur auf eine Instanzgruppe angewendet werden.
• SageMaker Verwaltete warme Pools und SageMaker Lokalbetrieb kann derzeit nicht mit heterogenem Cluster-Training verwendet werden.

Zusammenfassung

In diesem Beitrag haben wir erörtert, wann und wie die heterogene Cluster-Funktion des SageMaker-Trainings verwendet wird. Wir haben eine Preis-Leistungs-Verbesserung von 46 % an einem realen Anwendungsfall demonstriert und Ihnen geholfen, schnell mit dem verteilten Datenladeprogramm (tf.data.service und gRPC-Client-Server)-Implementierungen. Sie können diese Implementierungen mit minimalen Codeänderungen in Ihren vorhandenen Trainingsskripts verwenden.

Probieren Sie zunächst unsere aus Beispiel Notizbücher. Weitere Informationen zu dieser Funktion finden Sie unter Trainieren Sie mit einem heterogenen Cluster.

---

Über die Autoren

Gili Nachum ist ein Senior AI/ML Specialist Solutions Architect, der als Teil des EMEA Amazon Machine Learning-Teams arbeitet. Gili interessiert sich leidenschaftlich für die Herausforderungen beim Training von Deep-Learning-Modellen und dafür, wie maschinelles Lernen die Welt, wie wir sie kennen, verändert. In seiner Freizeit spielt Gili gerne Tischtennis.

Hrushikesh Gangur ist ein leitender Lösungsarchitekt für KI/ML-Startups mit Erfahrung in ML-Schulungen und AWS-Netzwerken. Er hilft Start-ups in den Bereichen autonome Fahrzeuge, Robotik, CV, NLP, MLOps, ML-Plattform und Robotik-Prozessautomatisierungstechnologien, um ihr Geschäft effizient und effektiv auf AWS zu führen. Bevor er zu AWS kam, sammelte Hrushikesh mehr als 20 Jahre Branchenerfahrung, hauptsächlich in Bezug auf Cloud- und Datenplattformen.

Gal Oschri ist Senior Product Manager im Amazon SageMaker-Team. Er verfügt über 7 Jahre Erfahrung in der Arbeit an Werkzeugen, Frameworks und Diensten für maschinelles Lernen.

Chaim Rand ist ein Entwickler von Algorithmen für maschinelles Lernen, der bei Mobileye, einem Unternehmen von Intel, an Deep-Learning- und Computer-Vision-Technologien für autonome Fahrzeuglösungen arbeitet. Schau dir seine an Blogs.