Erstellen Sie flexible und skalierbare verteilte Trainingsarchitekturen mit Kubeflow auf AWS und Amazon SageMaker

In diesem Beitrag zeigen wir, wie Kubeflow auf AWS (eine AWS-spezifische Verteilung von Kubeflow) verwendet mit AWS Deep Learning Container und Amazon Elastic File System (Amazon EFS) vereinfacht die Zusammenarbeit und bietet Flexibilität beim Training von Deep-Learning-Modellen in großem Umfang auf beiden Amazon Elastic Kubernetes-Service (Amazon EKS) und Amazon Sage Maker Verwenden eines hybriden Architekturansatzes.

Die Entwicklung von maschinellem Lernen (ML) ist auf komplexe und sich ständig weiterentwickelnde Open-Source-Frameworks und -Toolkits sowie auf komplexe und sich ständig weiterentwickelnde Hardware-Ökosysteme angewiesen. Dies stellt eine Herausforderung dar, wenn die ML-Entwicklung auf einen Cluster skaliert wird. Container bieten eine Lösung, da sie nicht nur den Trainingscode, sondern den gesamten Abhängigkeitsstapel bis hin zu den Hardwarebibliotheken vollständig kapseln können. Dadurch wird eine konsistente und portable ML-Umgebung sichergestellt und die Reproduzierbarkeit der Trainingsumgebung auf jedem einzelnen Knoten des Trainingsclusters erleichtert.

Kubernetes ist ein weit verbreitetes System zur Automatisierung der Infrastrukturbereitstellung, Ressourcenskalierung und Verwaltung dieser containerisierten Anwendungen. Kubernetes wurde jedoch nicht mit Blick auf ML entwickelt, sodass es für Datenwissenschaftler aufgrund seiner starken Abhängigkeit von YAML-Spezifikationsdateien kontraintuitiv erscheinen kann. Es gibt keine Jupyter-Erfahrung und es gibt nicht viele ML-spezifische Funktionen wie Workflow-Management und Pipelines sowie andere Funktionen, die ML-Experten erwarten, wie Hyperparameter-Tuning, Modell-Hosting und andere. Solche Fähigkeiten können aufgebaut werden, aber Kubernetes wurde nicht dafür konzipiert, dies als primäres Ziel zu tun.

Die Open-Source-Community wurde darauf aufmerksam und entwickelte eine Schicht auf Kubernetes namens Kubeflow. Kubeflow zielt darauf ab, die Bereitstellung von End-to-End-ML-Workflows auf Kubernetes einfach, portabel und skalierbar zu machen. Sie können Kubeflow verwenden, um erstklassige Open-Source-Systeme für ML in verschiedenen Infrastrukturen bereitzustellen.

Kubeflow und Kubernetes bieten Data Scientist-Teams Flexibilität und Kontrolle. Es ist jedoch immer noch eine Herausforderung, eine hohe Auslastung von Schulungsclustern sicherzustellen, die in großem Maßstab mit reduzierten Betriebskosten ausgeführt werden.

Dieser Beitrag zeigt, wie Kunden mit lokalen Einschränkungen oder bestehenden Kubernetes-Investitionen diese Herausforderung bewältigen können, indem sie Amazon EKS und Kubeflow auf AWS verwenden, um eine ML-Pipeline für verteiltes Training basierend auf einem selbstverwalteten Ansatz zu implementieren und vollständig verwaltetes SageMaker für a kostenoptimierte, vollständig verwaltete und produktionsreife Schulungsinfrastruktur. Dazu gehört die schrittweise Implementierung einer hybriden verteilten Trainingsarchitektur, die es Ihnen ermöglicht, zur Laufzeit zwischen den beiden Ansätzen zu wählen, was maximale Kontrolle und Flexibilität bei strengen Anforderungen für Ihre Bereitstellungen verleiht. Sie werden sehen, wie Sie weiterhin Open-Source-Bibliotheken in Ihrem Deep-Learning-Schulungsskript verwenden und es dennoch plattformunabhängig für die Ausführung auf Kubernetes und SageMaker kompatibel machen können.

Wie helfen Kubeflow auf AWS und SageMaker?

Neuronale Netzwerkmodelle, die mit Deep-Learning-Frameworks wie TensorFlow, PyTorch, MXNet und anderen erstellt wurden, bieten eine viel höhere Genauigkeit durch die Verwendung erheblich größerer Trainingsdatensätze, insbesondere in Anwendungsfällen für Computer Vision und Verarbeitung natürlicher Sprache. Bei großen Trainingsdatensätzen dauert es jedoch länger, die Deep-Learning-Modelle zu trainieren, was letztendlich die Markteinführungszeit verlangsamt. Wenn wir einen Cluster skalieren und die Modelltrainingszeit von Wochen auf Tage oder Stunden verkürzen könnten, könnte dies enorme Auswirkungen auf die Produktivität und die Geschäftsgeschwindigkeit haben.

Amazon EKS hilft bei der Bereitstellung der verwalteten Kubernetes-Steuerungsebene. Sie können Amazon EKS verwenden, um große Schulungscluster mit CPU- und GPU-Instances zu erstellen, und das Kubeflow-Toolkit verwenden, um ML-freundliche Open-Source-Tools bereitzustellen und ML-Workflows zu operationalisieren, die mit Kubeflow-Pipelines portabel und skalierbar sind, um die Produktivität Ihres Teams zu verbessern und die Time-to-Market verkürzen.

Dieser Ansatz kann jedoch einige Herausforderungen mit sich bringen:

• Gewährleistung der maximalen Nutzung eines Clusters durch Data-Science-Teams. Beispielsweise sollten Sie GPU-Instanzen nach Bedarf bereitstellen und ihre hohe Auslastung für anspruchsvolle Aufgaben im Produktionsmaßstab wie Deep-Learning-Training sicherstellen und CPU-Instanzen für weniger anspruchsvolle Aufgaben wie die Datenvorverarbeitung verwenden
• Sicherstellung einer hohen Verfügbarkeit von umfangreichen Kubeflow-Infrastrukturkomponenten, einschließlich Datenbank, Speicher und Authentifizierung, die im Kubernetes-Cluster-Worker-Knoten bereitgestellt werden. Beispielsweise generiert die Kubeflow-Steuerungsebene Artefakte (wie MySQL-Instanzen, Pod-Protokolle oder MinIO-Speicher), die mit der Zeit wachsen und skalierbare Speichervolumes mit kontinuierlichen Überwachungsfunktionen benötigen.
• Die gemeinsame Nutzung des Trainingsdatensatzes, des Codes und der Rechenumgebungen zwischen Entwicklern, Trainingsclustern und Projekten ist eine Herausforderung. Wenn Sie beispielsweise an Ihrem eigenen Satz von Bibliotheken arbeiten und diese Bibliotheken stark voneinander abhängig sind, wird es sehr schwierig, denselben Code zwischen Datenwissenschaftlern im selben Team zu teilen und auszuführen. Außerdem müssen Sie bei jedem Trainingslauf das Trainingsdataset herunterladen und das Trainingsimage mit neuen Codeänderungen erstellen.

Kubeflow on AWS hilft bei der Bewältigung dieser Herausforderungen und bietet ein halbverwaltetes Kubeflow-Produkt der Enterprise-Klasse. Mit Kubeflow auf AWS können Sie einige Dienste der Kubeflow-Steuerungsebene wie Datenbank, Speicherung, Überwachung und Benutzerverwaltung durch von AWS verwaltete Dienste wie ersetzen Relationaler Amazon-Datenbankdienst (Amazon-RDS), Amazon Simple Storage-Service (Amazon S3), Amazon Elastic File System (Amazon-EFS), Amazon FSx, Amazon CloudWatch und Amazon Cognito.

Durch das Ersetzen dieser Kubeflow-Komponenten werden kritische Teile der Kubeflow-Steuerungsebene von Kubernetes entkoppelt, wodurch ein sicheres, skalierbares, robustes und kostenoptimiertes Design bereitgestellt wird. Dieser Ansatz setzt auch Speicher- und Rechenressourcen von der EKS-Datenebene frei, die möglicherweise von Anwendungen wie verteiltem Modelltraining oder Benutzer-Notebook-Servern benötigt werden. Kubeflow auf AWS bietet auch eine native Integration von Jupyter-Notebooks mit Deep Learning Container (DLC)-Images, die mit AWS-optimierten Deep-Learning-Frameworks wie PyTorch und TensorFlow vorkonfiguriert und vorkonfiguriert sind, sodass Sie sofort mit dem Schreiben Ihres Trainingscodes beginnen können, ohne sich darum kümmern zu müssen mit Abhängigkeitsauflösungen und Framework-Optimierungen. Außerdem ermöglicht Ihnen die Amazon EFS-Integration mit Trainingsclustern und der Entwicklungsumgebung, Ihren Code und verarbeiteten Trainingsdatensatz zu teilen, wodurch das Erstellen des Container-Images und das Laden riesiger Datensätze nach jeder Codeänderung vermieden wird. Diese Integrationen mit Kubeflow auf AWS helfen Ihnen, die Modellerstellungs- und Trainingszeit zu verkürzen und ermöglichen eine bessere Zusammenarbeit mit einfacherer Daten- und Codefreigabe.

Kubeflow auf AWS hilft beim Aufbau einer hochverfügbaren und robusten ML-Plattform. Diese Plattform bietet Flexibilität beim Erstellen und Trainieren von Deep-Learning-Modellen und bietet Zugriff auf viele Open-Source-Toolkits, Einblicke in Protokolle und interaktives Debugging für Experimente. Das Erzielen einer maximalen Nutzung der Infrastrukturressourcen beim Trainieren von Deep-Learning-Modellen auf Hunderten von GPUs ist jedoch immer noch mit einem hohen Betriebsaufwand verbunden. Dies könnte durch die Verwendung von SageMaker angegangen werden, einem vollständig verwalteten Dienst, der für die Handhabung leistungsstarker und kostenoptimierter Schulungscluster entwickelt und optimiert wurde, die nur auf Anfrage bereitgestellt, nach Bedarf skaliert und automatisch heruntergefahren werden, wenn die Jobs abgeschlossen sind, wodurch fast 100 bereitgestellt werden % Ressourcennutzung. Sie können SageMaker mithilfe von verwalteten SageMaker-Komponenten in Kubeflow-Pipelines integrieren. Auf diese Weise können Sie ML-Workflows als Teil von Kubeflow-Pipelines operationalisieren, wobei Sie Kubernetes für lokale Schulungen und SageMaker für Schulungen im Produktmaßstab in einer Hybridarchitektur verwenden können.

Lösungsüberblick

Die folgende Architektur beschreibt, wie wir Kubeflow Pipelines verwenden, um portable und skalierbare End-to-End-ML-Workflows zu erstellen und bereitzustellen, um verteiltes Training auf Kubernetes mit Kubeflow-Training oder SageMaker basierend auf dem Laufzeitparameter bedingt auszuführen.

Kubeflow-Training ist eine Gruppe von Kubernetes-Operatoren, die Kubeflow die Unterstützung für verteiltes Training von ML-Modellen mit verschiedenen Frameworks wie TensorFlow, PyTorch und anderen hinzufügen. pytorch-operator ist die Kubeflow-Implementierung von Kubernetes benutzerdefinierte Ressource (PyTorchJob), um verteilte PyTorch-Trainingsjobs auf Kubernetes auszuführen.

Wir verwenden die PyTorchJob Launcher-Komponente als Teil der Kubeflow-Pipeline, um das verteilte PyTorch-Training während der Experimentierphase auszuführen, wenn wir Flexibilität und Zugriff auf alle zugrunde liegenden Ressourcen für interaktives Debuggen und Analysieren benötigen.

Wir verwenden auch SageMaker-Komponenten für Kubeflow-Pipelines, um unser Modelltraining im Produktionsmaßstab durchzuführen. Dadurch können wir leistungsstarke SageMaker-Funktionen wie vollständig verwaltete Dienste, verteilte Trainingsjobs mit maximaler GPU-Auslastung und kostengünstiges Training durch nutzen Amazon Elastic Compute-Cloud (Amazon EC2) Spot-Instanzen.

Als Teil des Workflow-Erstellungsprozesses führen Sie die folgenden Schritte aus (wie im vorherigen Diagramm gezeigt), um diese Pipeline zu erstellen:

1. Verwenden Sie die Kubeflow-Manifestdatei, um ein Kubeflow-Dashboard zu erstellen und über das zentrale Kubeflow-Dashboard auf Jupyter-Notebooks zuzugreifen.
2. Verwenden Sie das Kubeflow-Pipeline-SDK, um Kubeflow-Pipelines mit Python-Code zu erstellen und zu kompilieren. Die Pipeline-Kompilierung konvertiert die Python-Funktion in eine Workflow-Ressource, die ein Argo-kompatibles YAML-Format ist.
3. Verwenden Sie den Kubeflow Pipelines SDK-Client, um den Endpunkt des Pipeline-Dienstes zum Ausführen der Pipeline aufzurufen.
4. Die Pipeline wertet die bedingten Laufzeitvariablen aus und entscheidet zwischen SageMaker oder Kubernetes als Zielausführungsumgebung.
5. Verwenden Sie die Kubeflow PyTorch Launcher-Komponente, um verteilte Schulungen in der nativen Kubernetes-Umgebung auszuführen, oder verwenden Sie die SageMaker-Komponente, um die Schulung auf der von SageMaker verwalteten Plattform zu übermitteln.

Die folgende Abbildung zeigt die an der Architektur beteiligten Kubeflow Pipelines-Komponenten, die uns die Flexibilität geben, zwischen verteilten Kubernetes- oder SageMaker-Umgebungen zu wählen.

Anwendungsfall-Workflow

Wir verwenden den folgenden Schritt-für-Schritt-Ansatz, um den Anwendungsfall für verteiltes Training mit Amazon EKS und SageMaker mit Kubeflow auf AWS zu installieren und auszuführen.

Voraussetzungen:

Für diese exemplarische Vorgehensweise sollten Sie die folgenden Voraussetzungen erfüllen:

• An AWS-Konto.
• Eine Maschine mit Docker und der AWS-Befehlszeilenschnittstelle (AWS CLI) installiert.
• Optional können Sie AWS Cloud9, eine Cloud-basierte integrierte Entwicklungsumgebung (IDE), die es ermöglicht, die gesamte Arbeit von Ihrem Webbrowser aus zu erledigen. Anweisungen zur Einrichtung finden Sie unter Richten Sie die Cloud9-IDE ein. Wählen Sie in Ihrer Cloud9-Umgebung das Pluszeichen und öffnen Sie ein neues Terminal.
• Erstellen Sie eine Rolle mit der Bezeichnung sagemakerrole. Verwaltete Richtlinien hinzufügen AmazonSageMakerFullAccess und AmazonS3FullAccess um SageMaker Zugriff auf S3-Buckets zu gewähren. Diese Rolle wird vom SageMaker-Job verwendet, der als Teil des Kubeflow-Pipelines-Schritts übermittelt wird.
• Stellen Sie sicher, dass Ihr Konto über eine Ressourcentypbeschränkung für SageMaker-Schulungen verfügt ml.p3.2xlarge mit 2 erhöht Servicekontingent-Konsole

1. Installieren Sie Amazon EKS und Kubeflow auf AWS

Sie können verschiedene Ansätze verwenden, um einen Kubernetes-Cluster zu erstellen und Kubeflow bereitzustellen. In diesem Beitrag konzentrieren wir uns auf einen Ansatz, von dem wir glauben, dass er den Prozess vereinfacht. Zuerst erstellen wir einen EKS-Cluster und stellen dann Kubeflow auf AWS v1.5 darauf bereit. Für jede dieser Aufgaben verwenden wir ein entsprechendes Open-Source-Projekt, das den Prinzipien der Rahmen tun. Anstatt für jede Aufgabe eine Reihe von Voraussetzungen zu installieren, erstellen wir Docker-Container, die über alle erforderlichen Tools verfügen und die Aufgaben innerhalb der Container ausführen.

Wir verwenden in diesem Beitrag das Do Framework, das die Kubeflow-Bereitstellung mit Amazon EFS als Add-On automatisiert. Die offiziellen Kubeflow on AWS-Bereitstellungsoptionen für Produktionsbereitstellungen finden Sie unter Einsatz.

Konfigurieren Sie das aktuelle Arbeitsverzeichnis und die AWS CLI

Wir konfigurieren ein Arbeitsverzeichnis, damit wir es als Ausgangspunkt für die folgenden Schritte verwenden können:

export working_dir=$PWD

Wir konfigurieren auch ein AWS CLI-Profil. Dazu benötigen Sie eine Zugangsschlüssel-ID und einen geheimen Zugangsschlüssel von an AWS Identity and Access Management and (ICH BIN) Benutzer Konto mit Administratorrechten (hängen Sie die vorhandene verwaltete Richtlinie an) und programmgesteuertem Zugriff. Siehe folgenden Code:

aws configure --profile=kubeflow
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: us-west-2
Default output format [None]: json

# (In Cloud9, select “Cancel” and “Permanently disable” when the AWS managed temporary credentials dialog pops up)

export AWS_PROFILE=kubeflow

1.1 Erstellen Sie einen EKS-Cluster

Wenn Sie bereits einen EKS-Cluster zur Verfügung haben, können Sie mit dem nächsten Abschnitt fortfahren. Für diesen Beitrag verwenden wir die aws-do-eks-Projekt um unseren Cluster zu erstellen.

1. Klonen Sie zunächst das Projekt in Ihr Arbeitsverzeichnis

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-eks
   cd aws-do-eks/

2. Erstellen Sie dann die und führen Sie sie aus aws-do-eks Container:

   ./build.sh
   ./run.sh

   Das build.sh script erstellt ein Docker-Container-Image, das alle notwendigen Tools und Skripte für die Bereitstellung und den Betrieb von EKS-Clustern enthält. Das run.sh script startet einen Container mit dem erstellten Docker-Image und hält es aufrecht, sodass wir es als unsere EKS-Verwaltungsumgebung verwenden können. Um den Status Ihrer zu sehen aws-do-eks Container, können Sie ausführen ./status.sh. Wenn sich der Container im Status Beendet befindet, können Sie die verwenden ./start.sh Skript, um den Container hochzufahren oder den Container neu zu starten, können Sie ausführen ./stop.sh gefolgt von ./run.sh.

3. Öffnen Sie eine Shell im laufenden Betrieb aws-do-eks Container:
4. Führen Sie den folgenden Befehl aus, um die EKS-Clusterkonfiguration für unsere KubeFlow-Bereitstellung zu überprüfen:

   vi ./eks-kubeflow.yaml

   Standardmäßig erstellt diese Konfiguration einen Cluster mit dem Namen eks-kubeflow der us-west-2 Region mit sechs m5.xlarge-Knoten. Außerdem ist die EBS-Volume-Verschlüsselung standardmäßig nicht aktiviert. Sie können es aktivieren, indem Sie hinzufügen "volumeEncrypted: true" an die Knotengruppe und es wird mit dem Standardschlüssel verschlüsselt. Ändern Sie bei Bedarf andere Konfigurationseinstellungen.

5. Führen Sie zum Erstellen des Clusters den folgenden Befehl aus:

   export AWS_PROFILE=kubeflow
   eksctl create cluster -f ./eks-kubeflow.yaml

   Der Cluster-Bereitstellungsprozess kann bis zu 30 Minuten dauern.

6. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Cluster erfolgreich erstellt wurde:

   kubectl get nodes

   Die Ausgabe des vorherigen Befehls für einen erfolgreich erstellten Cluster sieht wie folgt aus:

   root@cdf4ecbebf62:/eks# kubectl get nodes
   NAME                                           STATUS   ROLES    AGE   VERSION
   ip-192-168-0-166.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-13-28.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-45-240.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-63-84.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-75-56.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-85-226.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326

Erstellen Sie ein EFS-Volume für den SageMaker-Trainingsauftrag

In diesem Anwendungsfall beschleunigen Sie den SageMaker-Trainingsjob, indem Sie Deep-Learning-Modelle anhand von Daten trainieren, die bereits in Amazon EFS gespeichert sind. Diese Wahl hat den Vorteil, dass Ihre Trainingsjobs direkt aus den Daten in Amazon EFS gestartet werden, ohne dass eine Datenverschiebung erforderlich ist, was zu schnelleren Trainingsstartzeiten führt.

Wir erstellen ein EFS-Volume und stellen den EFS Container Storage Interface (CSI)-Treiber bereit. Dies wird durch ein Bereitstellungsskript erreicht, das sich in befindet /eks/deployment/csi/efs innerhalb der aws-do-eks Container.

Dieses Skript geht davon aus, dass Sie einen EKS-Cluster in Ihrem Konto haben. Satz CLUSTER_NAME= falls Sie mehr als einen EKS-Cluster haben.

cd /eks/deployment/csi/efs
./deploy.sh

Dieses Skript stellt ein EFS-Volume bereit und erstellt Bereitstellungsziele für die Subnetze der Cluster-VPC. Anschließend stellt es den EFS-CSI-Treiber bereit und erstellt die efs-sc Speicherklasse u efs-pv Persistentes Volume im EKS-Cluster.

Nach erfolgreichem Abschluss des Skripts sollten Sie eine Ausgabe wie die folgende sehen:

Generating efs-sc.yaml ...

Applying efs-sc.yaml ...
storageclass.storage.k8s.io/efs-sc created
NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
efs-sc          efs.csi.aws.com         Delete          Immediate              false                  1s
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  36m

Generating efs-pv.yaml ...
Applying efs-pv.yaml ...
persistentvolume/efs-pv created
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWX            Retain           Available           efs-sc                  10s

Done ...

Erstellen Sie einen Amazon S3-VPC-Endpunkt

Sie verwenden eine private VPC, auf die Ihr SageMaker-Trainingsjob und das EFS-Dateisystem Zugriff haben. Um dem SageMaker-Trainingscluster von Ihrer privaten VPC aus Zugriff auf die S3-Buckets zu gewähren, erstellen Sie einen VPC-Endpunkt:

cd /eks/vpc 
export CLUSTER_NAME= 
export REGION= 
./vpc-endpoint-create.sh

Sie können jetzt das verlassen aws-do-eks Containerhülle und fahren Sie mit dem nächsten Abschnitt fort:

exit

root@cdf4ecbebf62:/eks/deployment/csi/efs# exit
exit
TeamRole:~/environment/aws-do-eks (main) $

1.2 Stellen Sie Kubeflow auf AWS auf Amazon EKS bereit

Um Kubeflow auf Amazon EKS bereitzustellen, verwenden wir die aws-do-kubeflow-Projekt.

1. Klonen Sie das Repository mit den folgenden Befehlen:

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-kubeflow
   cd aws-do-kubeflow

2. Konfigurieren Sie dann das Projekt:

   ./config.sh

   Dieses Skript öffnet die Projektkonfigurationsdatei in einem Texteditor. Es ist wichtig für AWS_REGION auf die Region eingestellt werden, in der sich Ihr Cluster befindet, sowie AWS_CLUSTER_NAME um mit dem Namen des zuvor erstellten Clusters übereinzustimmen. Standardmäßig ist Ihre Konfiguration bereits richtig eingestellt. Wenn Sie also keine Änderungen vornehmen müssen, schließen Sie einfach den Editor.

   ./build.sh
   ./run.sh
   ./exec.sh

   Das build.sh -Skript erstellt ein Docker-Container-Image, das über alle Tools verfügt, die zum Bereitstellen und Verwalten von Kubeflow in einem vorhandenen Kubernetes-Cluster erforderlich sind. Das run.sh Das Skript startet einen Container unter Verwendung des Docker-Images, und das exec.sh-Skript öffnet eine Befehlsshell im Container, den wir als unsere Kubeflow-Verwaltungsumgebung verwenden können. Du kannst den ... benutzen ./status.sh Skript, um zu sehen, ob die aws-do-kubeflow Container läuft und die ./stop.sh und ./run.sh Skripte, um es bei Bedarf neu zu starten.

3. Nachdem Sie eine Shell in der geöffnet haben aws-do-eks container können Sie überprüfen, ob der konfigurierte Clusterkontext wie erwartet ist:

   root@ip-172-31-43-155:/kubeflow# kubectx
   kubeflow@eks-kubeflow.us-west-2.eksctl.io

4. Um Kubeflow auf dem EKS-Cluster bereitzustellen, führen Sie die deploy.sh Skript:

   ./kubeflow-deploy.sh

   Die Bereitstellung ist erfolgreich, wenn alle Pods im kubeflow-Namespace in den Status Running wechseln. Eine typische Ausgabe sieht wie der folgende Code aus:

   Waiting for all Kubeflow pods to start Running ...
   
   Waiting for all Kubeflow pods to start Running ...
   
   Restarting central dashboard ...
   pod "centraldashboard-79f489b55-vr6lp" deleted
   /kubeflow/deploy/distro/aws/kubeflow-manifests /kubeflow/deploy/distro/aws
   /kubeflow/deploy/distro/aws
   
   Kubeflow deployment succeeded
   Granting cluster access to kubeflow profile user ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   clusterrolebinding.rbac.authorization.k8s.io/kubeflow-user-example-com-cluster-admin-binding created
   Setting up access to Kubeflow Pipelines ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   
   Creating pod-default for namespace kubeflow-user-example-com ...
   poddefault.kubeflow.org/access-ml-pipeline created

5. Um den Status der KubeFlow-Pods in einem separaten Fenster zu überwachen, können Sie den folgenden Befehl verwenden:

   watch kubectl -n kubeflow get pods

6. Öffentlichkeitsarbeit/Presse Strg + C Wenn alle Pods ausgeführt werden, stellen Sie das Kubeflow-Dashboard außerhalb des Clusters bereit, indem Sie den folgenden Befehl ausführen:

   ./kubeflow-expose.sh

Sie sollten eine Ausgabe sehen, die wie der folgende Code aussieht:

root@ip-172-31-43-155:/kubeflow# ./kubeflow-expose.sh
root@ip-172-31-43-155:/kubeflow# Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

Dieser Befehl leitet den Istio-Ingress-Gateway-Dienst von Ihrem Cluster an Ihren lokalen Port 8080 weiter. Um auf das Kubeflow-Dashboard zuzugreifen, besuchen Sie http://localhost:8080 und melden Sie sich mit den Standardbenutzeranmeldeinformationen an (user@example.com/12341234). Wenn Sie die ausführen aws-do-kubeflow Container in AWS Cloud9, dann können Sie wählen Vorspann, Dann wählen Vorschau der laufenden Anwendung. Wenn Sie Docker Desktop verwenden, müssen Sie möglicherweise die ./kubeflow-expose.sh Skript außerhalb der aws-do-kubeflow Container.

2. Richten Sie die Kubeflow-on-AWS-Umgebung ein

Um Ihre Kubeflow-on-AWS-Umgebung einzurichten, erstellen wir ein EFS-Volume und ein Jupyter-Notebook.

2.1 Erstellen Sie ein EFS-Volume

Führen Sie die folgenden Schritte aus, um ein EFS-Volume zu erstellen:

• Wählen Sie im Kubeflow-Dashboard aus Volumes im Navigationsbereich.
• Wählen Neuer Band.
• Aussichten für Name und Vorname, eingeben efs-sc-claim.
• Aussichten für Volumengröße, eingeben 10.
• Aussichten für Lagerklasse, wählen efs-sc.
• Aussichten für Zugriffsmodus, wählen ReadWriteOnce.
• Auswählen Erstellen.

2.2 Erstellen Sie ein Jupyter-Notebook

Führen Sie die folgenden Schritte aus, um ein neues Notizbuch zu erstellen:

• Wählen Sie im Kubeflow-Dashboard aus Notizbücher im Navigationsbereich.
• Auswählen Neues Notizbuch.
• Aussichten für Name und Vorname, eingeben aws-hybrid-nb.
• Aussichten für Jupyter-Docket-Image, wählen Sie das Bild aus c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (das neueste verfügbare jupyter-pytorch DLC-Image).
• Aussichten für CPU, eingeben 1.
• Aussichten für Memory, eingeben 5.
• Aussichten für GPUs, verlassen als Andere.
• Nehmen Sie keine Änderungen an der vor Arbeitsbereichsvolumen .
• Im Datenvolumen Wählen Sie im Abschnitt Vorhandenes Volume anhängen und erweitern Sie den Abschnitt Vorhandenes Volumen
• Aussichten für Name und Vorname, wählen efs-sc-claim.
• Aussichten für Mount-Pfad, eingeben /home/jovyan/efs-sc-claim.
  Dadurch wird das EFS-Volume in Ihrem Jupyter-Notebook-Pod bereitgestellt, und Sie können den Ordner sehen efs-sc-claim in Ihrer Jupyter Lab-Oberfläche. Sie speichern das Trainingsdataset und den Trainingscode in diesem Ordner, damit die Trainingscluster darauf zugreifen können, ohne die Containerimages zum Testen neu erstellen zu müssen.
• Auswählen Zugriff auf Kubeflow-Pipelines zulassen im Abschnitt Konfiguration.
• Auswählen Einführung.
  Vergewissern Sie sich, dass Ihr Notizbuch erfolgreich erstellt wurde (dies kann einige Minuten dauern).
• Auf dem Notizbücher Seite wählen Vernetz Dich um sich bei der JupyterLab-Umgebung anzumelden.
• Auf dem Git Menü, wählen Sie Klonen Sie ein Repository.
• Aussichten für Klonen Sie ein Repo, eingeben https://github.com/aws-samples/aws-do-kubeflow.
  

3. Führen Sie verteiltes Training durch

Nachdem Sie das Jupyter-Notebook eingerichtet haben, können Sie die gesamte Demo mithilfe der folgenden allgemeinen Schritte aus dem Ordner ausführen aws-do-kubeflow/workshop im geklonten Repository:

• PyTorch Distributed Data Parallel (DDP) Trainingsskript: Siehe PyTorch DDP-Trainingsskript cifar10-distributed-gpu-final.py, das ein Beispiel für ein neurales Faltungsnetz und Logik enthält, um das Training auf einem CPU- und GPU-Cluster mit mehreren Knoten zu verteilen. (Einzelheiten siehe 3.1)
• Bibliotheken installieren: Führen Sie das Notizbuch aus 0_initialize_dependencies.ipynb um alle Abhängigkeiten zu initialisieren. (Einzelheiten siehe 3.2)
• Führen Sie das verteilte PyTorch-Job-Training auf Kubernetes aus: Führen Sie das Notizbuch aus 1_submit_pytorchdist_k8s.ipynb um verteilte Schulungen für einen primären und zwei Worker-Container mit der benutzerdefinierten Kubernetes-Ressource PyTorchJob YAML-Datei mit Python-Code zu erstellen und zu übermitteln. (Einzelheiten siehe 3.3)
• Erstellen Sie eine hybride Kubeflow-Pipeline: Führen Sie das Notizbuch aus 2_create_pipeline_k8s_sagemaker.ipynb um die hybride Kubeflow-Pipeline zu erstellen, die das verteilte Training auf SageMaker oder Amazon EKS unter Verwendung der Laufzeitvariablen ausführt training_runtime. (Einzelheiten siehe 3.4)

Stellen Sie sicher, dass das Notebook ausgeführt wurde 1_submit_pytorchdist_k8s.ipynb bevor Sie das Notebook starten 2_create_pipeline_k8s_sagemaker.ipynb.

In den folgenden Abschnitten besprechen wir jeden dieser Schritte im Detail.

3.1 PyTorch Distributed Data Parallel (DDP)-Trainingsskript

Als Teil des verteilten Trainings trainieren wir ein Klassifizierungsmodell, das von einem einfachen Convolutional Neural Network erstellt wurde, das auf dem CIFAR10-Datensatz arbeitet. Das Trainingsskript cifar10-distributed-gpu-final.py enthält nur die Open-Source-Bibliotheken und ist kompatibel, um sowohl auf Kubernetes- als auch auf SageMaker-Trainingsclustern auf GPU-Geräten oder CPU-Instanzen ausgeführt zu werden. Sehen wir uns einige wichtige Aspekte des Trainingsskripts an, bevor wir unsere Notebook-Beispiele ausführen.

Wir nutzen die torch.distributed -Modul, das PyTorch-Unterstützung und Kommunikationsprimitive für Multiprozess-Parallelität über Knoten im Cluster enthält:

...
import torch
import torch.distributed as dist
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
import torch.utils.data
import torch.utils.data.distributed
import torchvision
from torchvision import datasets, transforms
...

Wir erstellen ein einfaches Bildklassifizierungsmodell mit einer Kombination aus Faltungs-, Max-Pooling- und linearen Schichten, auf die im Vorwärtsdurchgang des Modelltrainings eine Relu-Aktivierungsfunktion angewendet wird:

# Define models
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(3, 6, 5)
self.pool = nn.MaxPool2d(2, 2)
self.conv2 = nn.Conv2d(6, 16, 5)
self.fc1 = nn.Linear(16 * 5 * 5, 120)
self.fc2 = nn.Linear(120, 84)
self.fc3 = nn.Linear(84, 10)

def forward(self, x):
x = self.pool(F.relu(self.conv1(x)))
x = self.pool(F.relu(self.conv2(x)))
x = x.view(-1, 16 * 5 * 5)
x = F.relu(self.fc1(x))
x = F.relu(self.fc2(x))
x = self.fc3(x)
return x

Wir verwenden den Torch DataLoader, der den Datensatz und kombiniert DistributedSampler (lädt eine Teilmenge von Daten auf verteilte Weise mit torch.nn.parallel.DistributedDataParallel) und bietet einen Einzelprozess- oder Multiprozess-Iterator für die Daten:

# Define data loader for training dataset
def _get_train_data_loader(batch_size, training_dir, is_distributed):
logger.info("Get train data loader")

train_set = torchvision.datasets.CIFAR10(root=training_dir,
train=True,
download=False,
transform=_get_transforms())

train_sampler = (
torch.utils.data.distributed.DistributedSampler(train_set) if is_distributed else None
)

return torch.utils.data.DataLoader(
train_set,
batch_size=batch_size,
shuffle=train_sampler is None,
sampler=train_sampler)
...

Wenn der Trainingscluster über GPUs verfügt, führt das Skript das Training auf CUDA-Geräten aus und die Gerätevariable enthält das standardmäßige CUDA-Gerät:

device = "cuda" if torch.cuda.is_available() else "cpu"
...

Bevor Sie verteiltes Training mit PyTorch ausführen DistributedDataParallel Um die verteilte Verarbeitung auf mehreren Knoten auszuführen, müssen Sie die verteilte Umgebung durch einen Aufruf initialisieren init_process_group. Dieser wird auf jeder Maschine des Trainingsclusters initialisiert.

dist.init_process_group(backend=args.backend, rank=host_rank, world_size=world_size)
...

Wir instanziieren das Klassifikatormodell und kopieren das Modell auf das Zielgerät. Wenn das verteilte Training aktiviert ist, um auf mehreren Knoten ausgeführt zu werden, wird die DistributedDataParallel -Klasse wird als Wrapper-Objekt um das Modellobjekt herum verwendet, was ein synchron verteiltes Training über mehrere Computer ermöglicht. Die Eingabedaten werden nach Chargendimension aufgeteilt und auf jeder Maschine und jedem Gerät wird ein Replikat des Modells platziert.

model = Net().to(device)

if is_distributed:
model = torch.nn.parallel.DistributedDataParallel(model)

...

3.2 Bibliotheken installieren

Sie installieren alle erforderlichen Bibliotheken, um das verteilte PyTorch-Trainingsbeispiel auszuführen. Dazu gehören Kubeflow Pipelines SDK, Training Operator Python SDK, Python-Client für Kubernetes und Amazon SageMaker Python SDK.

#Please run the below commands to install necessary libraries

!pip install kfp==1.8.4

!pip install kubeflow-training

!pip install kubernetes

!pip install sagemaker

3.3 Ausführen von verteiltem PyTorch-Job-Training auf Kubernetes

Das Notebook 1_submit_pytorchdist_k8s.ipynb erstellt die PyTorchJob-YAML-Datei der benutzerdefinierten Kubernetes-Ressource mithilfe des Kubeflow-Trainings und des Kubernetes-Client-Python-SDK. Im Folgenden finden Sie einige wichtige Ausschnitte aus diesem Notizbuch.

Wir erstellen die PyTorchJob-YAML mit den Primär- und Worker-Containern, wie im folgenden Code gezeigt:

# Define PyTorchJob custom resource manifest
pytorchjob = V1PyTorchJob(
api_version="kubeflow.org/v1",
kind="PyTorchJob",
metadata=V1ObjectMeta(name=pytorch_distributed_jobname,namespace=user_namespace),
spec=V1PyTorchJobSpec(
run_policy=V1RunPolicy(clean_pod_policy="None"),
pytorch_replica_specs={"Master": master,
"Worker": worker}
)
)

Dies wird mithilfe von an die Kubernetes-Steuerungsebene übermittelt PyTorchJobClient:

# Creates and Submits PyTorchJob custom resource file to Kubernetes
pytorchjob_client = PyTorchJobClient()

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Zeigen Sie die Kubernetes-Trainingsprotokolle an

Sie können die Trainingsprotokolle entweder über dasselbe Jupyter-Notebook mit Python-Code oder über die Kubernetes-Client-Shell anzeigen.

3.4 Erstellen Sie eine hybride Kubeflow-Pipeline

Das Notebook 2_create_pipeline_k8s_sagemaker.ipynb erstellt eine hybride Kubeflow-Pipeline basierend auf einer bedingten Laufzeitvariablen training_runtime, wie im folgenden Code gezeigt. Das Notebook verwendet die Kubeflow Pipelines-SDK und es wird eine Reihe von Python-Paketen bereitgestellt, um die ML-Workflow-Pipelines anzugeben und auszuführen. Als Teil dieses SDK verwenden wir die folgenden Pakete:

• Der Paket-Decorator für domänenspezifische Sprachen (DSL). dsl.pipeline, das die Python-Funktionen dekoriert, um eine Pipeline zurückzugeben
• Das dsl.Condition Paket, das eine Gruppe von Vorgängen darstellt, die nur ausgeführt werden, wenn eine bestimmte Bedingung erfüllt ist, z training_runtime Wert als sagemaker or kubernetes

Siehe folgenden Code:

# Define your training runtime value with either 'sagemaker' or 'kubernetes'
training_runtime='sagemaker'

# Create Hybrid Pipeline using Kubeflow PyTorch Training Operators and Amazon SageMaker Service
@dsl.pipeline(name="PyTorch Training pipeline", description="Sample training job test")
def pytorch_cnn_pipeline():

# Pipeline Step 1: to evaluate the condition. You can enter any logic here. For demonstration we are checking if GPU is needed for training
condition_result = check_condition_op(training_runtime)

# Pipeline Step 2: to run training on Kuberentes using PyTorch Training Operators. This will be executed if gpus are not needed
with dsl.Condition(condition_result.output == 'kubernetes', name="PyTorch_Comp"):
train_task = pytorch_job_op(
name=training_job_name,
namespace=user_namespace,
master_spec=json.dumps(master_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_master_spec.yml
worker_spec=json.dumps(worker_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_worker_spec.yml
delete_after_done=False
).after(condition_result)

# Pipeline Step 3: to run training on SageMaker using SageMaker Components for Pipeline. This will be executed if gpus are needed
with dsl.Condition(condition_result.output == 'sagemaker', name="SageMaker_Comp"):
training = sagemaker_train_op(
region=region,
image=train_image,
job_name=training_job_name,
training_input_mode=training_input_mode,
hyperparameters='{ 
"backend": "'+str(pytorch_backend)+'", 
"batch-size": "64", 
"epochs": "3", 
"lr": "'+str(learning_rate)+'", 
"model-type": "custom", 
"sagemaker_container_log_level": "20", 
"sagemaker_program": "cifar10-distributed-gpu-final.py", 
"sagemaker_region": "us-west-2", 
"sagemaker_submit_directory": "'+source_s3+'" 
}',
channels=channels,
instance_type=instance_type,
instance_count=instance_count,
volume_size=volume_size,
max_run_time=max_run_time,
model_artifact_path=f's3://{bucket_name}/jobs',
network_isolation=network_isolation,
traffic_encryption=traffic_encryption,
role=role,
vpc_subnets=subnet_id,
vpc_security_group_ids=security_group_id
).after(condition_result)

Wir konfigurieren das verteilte SageMaker-Training mit zwei ml.p3.2xlarge-Instanzen.

Nachdem die Pipeline definiert wurde, können Sie die Pipeline mithilfe der Kubeflow Pipelines SDKs in eine Argo YAML-Spezifikation kompilieren kfp.compiler Paket. Sie können diese Pipeline mit dem Kubeflow Pipeline SDK-Client ausführen, der den Pipelines-Dienstendpunkt aufruft und die entsprechenden Authentifizierungsheader direkt vom Notebook übergibt. Siehe folgenden Code:

# DSL Compiler that compiles pipeline functions into workflow yaml.
kfp.compiler.Compiler().compile(pytorch_cnn_pipeline, "pytorch_cnn_pipeline.yaml")

# Connect to Kubeflow Pipelines using the Kubeflow Pipelines SDK client
client = kfp.Client()

experiment = client.create_experiment(name="kubeflow")

# Run a specified pipeline
my_run = client.run_pipeline(experiment.id, "pytorch_cnn_pipeline", "pytorch_cnn_pipeline.yaml")

# Please click “Run details” link generated below this cell to view your pipeline. You can click every pipeline step to see logs.

Wenn du eine bekommst sagemaker import Fehler, führen Sie !pip install sagemaker aus und starten Sie den Kernel neu (auf der Kernel Menü, wählen Sie Kernel neu starten).

Wähle die Ausführungsdetails Link unter der letzten Zelle, um die Kubeflow-Pipeline anzuzeigen.

Wiederholen Sie den Schritt zum Erstellen der Pipeline mit training_runtime='kubernetes' um die Pipelineausführung in einer Kubernetes-Umgebung zu testen. Das training_runtime Variable kann auch in Ihrer CI/CD-Pipeline in einem Produktionsszenario übergeben werden.

Zeigen Sie die Ausführungsprotokolle der Kubeflow-Pipeline für die SageMaker-Komponente an

Der folgende Screenshot zeigt unsere Pipeline-Details für die SageMaker-Komponente.

Wählen Sie den Trainingsjob-Schritt und auf der Logs Wählen Sie auf der Registerkarte CloudWatch logs den Link CloudWatch logs aus, um auf die SageMaker-Protokolle zuzugreifen.

Der folgende Screenshot zeigt die CloudWatch-Protokolle für jede der beiden ml.p3.2xlarge-Instanzen.

Wählen Sie eine der Gruppen aus, um die Protokolle anzuzeigen.

Zeigen Sie die Ausführungsprotokolle der Kubeflow-Pipeline für die Kubeflow PyTorchJob Launcher-Komponente an

Der folgende Screenshot zeigt die Pipeline-Details für unsere Kubeflow-Komponente.

Führen Sie die folgenden Befehle mit aus Kubectl auf Ihrer Kubernetes-Client-Shell, die mit dem Kubernetes-Cluster verbunden ist, um die Protokolle anzuzeigen (ersetzen Sie Ihre Namespace- und Pod-Namen):

kubectl get pods -n kubeflow-user-example-com
kubectl logs  -n kubeflow-user-example-com -f

4.1 Aufräumen

Um alle Ressourcen zu bereinigen, die wir im Konto erstellt haben, müssen wir sie in umgekehrter Reihenfolge entfernen.

1. Löschen Sie die Kubeflow-Installation, indem Sie sie ausführen ./kubeflow-remove.sh der aws-do-kubeflow Container. Der erste Befehlssatz ist optional und kann verwendet werden, falls Sie noch keine Befehlsshell in Ihrem haben aws-do-kubeflow Behälter geöffnet.

   cd aws-do-kubeflow
   ./status.sh
   ./start.sh
   ./exec.sh
   
   ./kubeflow-remove.sh

2. Von dem aws-do-eks Container-Ordner, entfernen Sie das EFS-Volume. Der erste Befehlssatz ist optional und kann verwendet werden, falls Sie noch keine Befehlsshell in Ihrem haben aws-do-eks Behälter geöffnet.

   cd aws-do-eks
   ./status.sh
   ./start.sh
   ./exec.sh
   
   cd /eks/deployment/csi/efs
   ./delete.sh
   ./efs-delete.sh

   Das Löschen von Amazon EFS ist erforderlich, um die Netzwerkschnittstelle freizugeben, die mit der VPC verknüpft ist, die wir für unseren Cluster erstellt haben. Beachten Sie, dass durch das Löschen des EFS-Volumes alle darauf gespeicherten Daten zerstört werden.

3. Von dem aws-do-eks Container, führen Sie die eks-delete.sh Skript zum Löschen des Clusters und aller anderen damit verbundenen Ressourcen, einschließlich der VPC:

   cd /eks
   ./eks-delete.sh

Zusammenfassung

In diesem Beitrag haben wir einige der typischen Herausforderungen des verteilten Modelltrainings und der ML-Workflows besprochen. Wir haben einen Überblick über die Verteilung von Kubeflow auf AWS gegeben und zwei Open-Source-Projekte (aws-do-eks und aws-do-kubeflow), die die Bereitstellung der Infrastruktur und die Bereitstellung von Kubeflow darauf vereinfachen. Schließlich haben wir eine hybride Architektur beschrieben und demonstriert, die einen nahtlosen Übergang von Workloads zwischen der Ausführung auf einer selbstverwalteten Kubernetes- und einer vollständig verwalteten SageMaker-Infrastruktur ermöglicht. Wir empfehlen Ihnen, diese hybride Architektur für Ihre eigenen Anwendungsfälle zu verwenden.

Sie können dem folgen AWS Labs-Repository um alle AWS-Beiträge zu Kubeflow zu verfolgen. Sie finden uns auch auf der Kubeflow #AWS Slack-Channel; Ihr Feedback dort wird uns helfen, die nächsten Funktionen zu priorisieren, die zum Kubeflow-Projekt beitragen.

Besonderer Dank geht an Sree Arasanagatta (Software Development Manager AWS ML) und Suraj Kota (Software Dev Engineer) für ihre Unterstützung beim Start dieses Beitrags.

Über die Autoren

Kanwaljit Khurmi ist AI/ML Specialist Solutions Architect bei Amazon Web Services. Er arbeitet mit dem AWS-Produkt, der Technik und den Kunden zusammen, um Anleitungen und technische Unterstützung bereitzustellen, die ihnen helfen, den Wert ihrer hybriden ML-Lösungen bei der Verwendung von AWS zu verbessern. Kanwaljit ist darauf spezialisiert, Kunden mit containerisierten und maschinellen Lernanwendungen zu unterstützen.

Gautam Kumar ist ein Software Engineer mit AWS AI Deep Learning. Er hat AWS Deep Learning Containers und AWS Deep Learning AMI entwickelt. Seine Leidenschaft gilt der Entwicklung von Tools und Systemen für KI. In seiner Freizeit fährt er gerne Fahrrad und liest Bücher.

Alex Iankoulski ist ein Full-Stack-Software- und Infrastrukturarchitekt, der gerne tiefgreifende, praktische Arbeit leistet. Derzeit ist er Principal Solutions Architect für selbstverwaltetes maschinelles Lernen bei AWS. In seiner Rolle konzentriert er sich darauf, Kunden bei der Containerisierung und Orchestrierung von ML- und KI-Workloads auf containergestützten AWS-Services zu unterstützen. Er ist auch der Autor der Open Source Rahmen tun und ein Docker-Kapitän, der es liebt, Containertechnologien einzusetzen, um das Innovationstempo zu beschleunigen und gleichzeitig die größten Herausforderungen der Welt zu lösen. In den letzten 10 Jahren hat Alex daran gearbeitet, den Klimawandel zu bekämpfen, KI und ML zu demokratisieren, Reisen sicherer, die Gesundheitsversorgung zu verbessern und Energie intelligenter zu machen.