Formation distribuée avec Amazon EKS et Torch Distributed Elastic

La formation sur des modèles d’apprentissage profond distribué devient de plus en plus importante à mesure que la taille des données augmente dans de nombreux secteurs. De nombreuses applications en vision par ordinateur et en traitement du langage naturel nécessitent désormais la formation de modèles d’apprentissage profond, dont la complexité augmente de façon exponentielle et qui sont souvent entraînés avec des centaines de téraoctets de données. Il devient alors important d’utiliser une vaste infrastructure cloud pour étendre la formation de modèles aussi volumineux.

Les développeurs peuvent utiliser des frameworks open source tels que PyTorch pour concevoir facilement des architectures de modèles intuitives. Cependant, la mise à l'échelle de la formation de ces modèles sur plusieurs nœuds peut s'avérer difficile en raison de la complexité accrue de l'orchestration.

La formation sur modèles distribués se compose principalement de deux paradigmes :

• Modèle parallèle – Dans l’entraînement parallèle de modèles, le modèle lui-même est si volumineux qu’il ne peut pas tenir dans la mémoire d’un seul GPU, et plusieurs GPU sont nécessaires pour entraîner le modèle. Le modèle GPT-3 d’Open AI avec 175 milliards de paramètres entraînables (environ 350 Go) en est un bon exemple.
• Données parallèles – Dans la formation parallèle de données, le modèle peut résider dans un seul GPU, mais comme les données sont si volumineuses, la formation d'un modèle peut prendre des jours, voire des semaines. La distribution des données sur plusieurs nœuds GPU peut réduire considérablement le temps de formation.

Dans cet article, nous fournissons un exemple d'architecture pour entraîner des modèles PyTorch à l'aide de Élastique distribué par torche framework de manière parallèle à des données distribuées en utilisant Service Amazon Elastic Kubernetes (Amazon EKS).

Pré-requis

Pour reproduire les résultats rapportés dans cet article, la seule condition préalable est un compte AWS. Dans ce compte, nous créons un cluster EKS et un Amazon FSx pour Lustre système de fichiers. Nous poussons également les images de conteneurs vers un Registre des conteneurs élastiques Amazon (Amazon ECR) dans le compte. Les instructions pour configurer ces composants sont fournies selon les besoins tout au long du message.

Grappes EKS

Amazon EKS est un service de conteneur géré permettant d'exécuter et de faire évoluer les applications Kubernetes sur AWS. Avec Amazon EKS, vous pouvez exécuter efficacement des tâches de formation distribuées en utilisant la dernière version Cloud de calcul élastique Amazon (Amazon EC2) sans avoir besoin d'installer, d'exploiter et de gérer votre propre plan de contrôle ou vos propres nœuds. C'est un populaire orchestrateur pour les workflows d'apprentissage automatique (ML) et d'IA. Un cluster EKS typique dans AWS ressemble à la figure suivante.

Nous avons publié un projet open source, AWS DevOps pour EKS (aws-do-eks), qui fournit une vaste collection de scripts et d'outils faciles à utiliser et configurables pour provisionner des clusters EKS et exécuter des tâches de formation distribuées. Ce projet est construit selon les principes du Faire le cadre: Simplicité, Flexibilité et Universalité. Vous pouvez configurer le cluster souhaité en utilisant le eks.conf fichier puis lancez-le en exécutant le eks-create.sh scénario. Des instructions détaillées sont fournies dans le GitHub repo.

Entraîner des modèles PyTorch à l'aide de Torch Distributed Elastic

Torch Distributed Elastic (TDE) est une bibliothèque PyTorch native pour la formation de modèles d'apprentissage profond à grande échelle où il est essentiel de faire évoluer les ressources de calcul de manière dynamique en fonction de la disponibilité. Le Contrôleur TorchElastic pour Kubernetes est une implémentation native de Kubernetes pour TDE qui gère automatiquement le cycle de vie des pods et des services requis pour la formation TDE. Il permet de faire évoluer dynamiquement les ressources de calcul pendant la formation, selon les besoins. Il fournit également une formation tolérante aux pannes en récupérant les tâches en cas de panne de nœud.

Dans cet article, nous discutons des étapes pour former PyTorch EfficaceNet-B7 ainsi que ResNet50 modèles utilisant ImageNet données de manière distribuée avec TDE. Nous utilisons le PyTorch DistributedDataParallelDistributedDataParallel API et le contrôleur Kubernetes TorchElastic, et exécutez nos tâches de formation sur un cluster EKS contenant plusieurs nœuds GPU. Le diagramme suivant montre le diagramme d'architecture de ce modèle de formation.

TorchElastic pour Kubernetes se compose principalement de deux composants : le contrôleur TorchElastic Kubernetes (TEC) et le serveur de paramètres (etcd). Le contrôleur est responsable de la surveillance et de la gestion des tâches de formation, et le serveur de paramètres assure le suivi des nœuds de travail pour la synchronisation distribuée et la découverte des pairs.

Pour que les modules de formation puissent accéder aux données, nous avons besoin d'un volume de données partagé qui peut être monté par chaque module. Quelques options pour les volumes partagés via Interface de stockage de conteneurs (CSI) pilotes inclus dans AWS DevOps pour EKS Système de fichiers Amazon Elastic (Amazon EFS) et FSx pour Lustre.

Configuration du cluster

Dans notre configuration de cluster, nous utilisons une instance c5.2xlarge pour les pods système. Nous utilisons trois instances p4d.24xlarge comme pods de travail pour former un modèle EfficientNet. Pour la formation ResNet50, nous utilisons des instances p3.8xlarge comme pods de travail. De plus, nous utilisons un système de fichiers partagé FSx pour stocker nos données de formation et nos artefacts de modèle.

Les instances AWS p4d.24xlarge sont équipées de Adaptateur en tissu élastique (EFA) pour assurer la mise en réseau entre les nœuds. Nous discutons davantage de l’EPT plus tard dans l’article. Pour activer la communication via EFA, nous devons configurer la configuration du cluster via un fichier .yaml. Un fichier exemple est fourni dans le référentiel GitHub.

Une fois ce fichier .yaml correctement configuré, nous pouvons lancer le cluster à l'aide du script fourni dans le dépôt GitHub :

./eks-create.sh

Reportez-vous à GitHub repo pour des instructions détaillées.

Il n'y a pratiquement aucune différence entre exécuter des tâches sur p4d.24xlarge et p3.8xlarge. Les étapes décrites dans cet article fonctionnent pour les deux. La seule différence est la disponibilité d'EFA sur les instances p4d.24xlarge. Pour les modèles plus petits comme ResNet50, la mise en réseau standard par rapport à la mise en réseau EFA a un impact minime sur la vitesse de formation.

FSx pour le système de fichiers Lustre

FSx est conçu pour les charges de travail informatiques hautes performances et offre une latence inférieure à la milliseconde en utilisant des volumes de stockage sur disque SSD. Nous avons choisi FSx car il offrait de meilleures performances lorsque nous évoluions vers un grand nombre de nœuds. Un détail important à noter est que FSx ne peut exister que dans une seule zone de disponibilité. Par conséquent, tous les nœuds accédant au système de fichiers FSx doivent exister dans la même zone de disponibilité que le système de fichiers FSx. Une façon d'y parvenir consiste à spécifier la zone de disponibilité appropriée dans le fichier .yaml du cluster pour les groupes de nœuds spécifiques avant de créer le cluster. Alternativement, nous pouvons modifier la partie réseau du groupe de mise à l'échelle automatique pour ces nœuds une fois le cluster configuré et la limiter à l'utilisation d'un seul sous-réseau. Cela peut être facilement fait sur la console Amazon EC2.

En supposant que le cluster EKS est opérationnel et que l'ID de sous-réseau de la zone de disponibilité est connu, nous pouvons configurer un système de fichiers FSx en fournissant les informations nécessaires dans le fichier fsx.conf fichier comme décrit dans le readme et exécuter le déployer.sh script dans le FSX dossier. Cela configure la stratégie et le groupe de sécurité appropriés pour accéder au système de fichiers. Le script installe également le Pilote CSI pour FSx en tant que démon. Enfin, nous pouvons créer la revendication de volume persistant FSx dans Kubernetes en appliquant un seul fichier .yaml :

kubectl apply -f fsx-pvc-dynamic.yaml

Cela crée un système de fichiers FSx dans la zone de disponibilité spécifiée dans le fsx.conf fichier, et crée également une réclamation de volume persistante fsx-pvc, qui peut être monté par n'importe lequel des pods du cluster en mode lecture-écriture-beaucoup (RWX).

Dans notre expérience, nous avons utilisé les données ImageNet complètes, qui contiennent plus de 12 millions d'images d'entraînement réparties en 1,000 XNUMX classes. Les données peuvent être téléchargées à partir du Site Web ImageNet. La balle TAR originale a plusieurs répertoires, mais pour notre formation de modèle, nous nous intéressons uniquement à ILSVRC/Data/CLS-LOC/, qui comprend le train ainsi que val sous-répertoires. Avant la formation, nous devons réorganiser les images dans le val sous-répertoire pour correspondre à la structure de répertoires requise par PyTorch DossierImage classe. Cela peut être fait en utilisant un simple Script Python une fois les données copiées sur le volume persistant à l’étape suivante.

Pour copier les données d'un Service de stockage simple Amazon (Amazon S3) au système de fichiers FSx, nous créons une image Docker qui inclut des scripts pour cette tâche. Un exemple de Dockerfile et un script shell sont inclus dans le csi dossier dans le dépôt GitHub. Nous pouvons construire l'image en utilisant le build.sh script, puis envoyez-le vers Amazon ECR à l'aide du push.sh scénario. Avant d'utiliser ces scripts, nous devons fournir l'URI correct pour le référentiel ECR dans le fichier .env fichier dans le dossier racine du dépôt GitHub. Après avoir envoyé l'image Docker vers Amazon ECR, nous pouvons lancer un pod pour copier les données en appliquant le fichier .yaml approprié :

kubectl apply -f fsx-data-prep-pod.yaml

Le pod exécute automatiquement le script data-prep.sh pour copier les données d'Amazon S3 vers le volume partagé. Étant donné que les données ImageNet contiennent plus de 12 millions de fichiers, le processus de copie prend quelques heures. Le script Python imagenet_data_prep.py est également exécuté pour réorganiser le val ensemble de données comme prévu par PyTorch.

Accélération du réseau

Nous pouvons utiliser l'adaptateur de tissu élastique (EFA) en combinaison avec types d'instances EC2 pris en charge pour accélérer le trafic réseau entre les nœuds GPU de votre cluster. Cela peut être utile lors de l'exécution de tâches de formation distribuées de grande envergure où la communication réseau standard peut constituer un goulot d'étranglement. Les scripts pour déployer et tester le plug-in de périphérique EFA dans le cluster EKS que nous utilisons ici sont inclus dans le plugin-de-périphérique-efa dossier dans le dépôt GitHub. Pour activer une tâche avec EFA dans votre cluster EKS, en plus des nœuds de cluster disposant du matériel et des logiciels nécessaires, le plug-in de périphérique EFA doit être déployé sur le cluster et votre conteneur de tâches doit avoir des compatibilités CUDA et NCCL. versions installé.

Pour démontrer l'exécution des tests NCCL et évaluer les performances d'EFA sur les instances p4d.24xlarge, nous devons d'abord déployer l'opérateur Kubeflow MPI en exécutant le fichier correspondant. déployer.sh script dans le opérateur mpi dossier. Ensuite, nous exécutons le déployer.sh script et mettre à jour le test-efa-nccl.yaml manifestent ainsi les limites et les demandes de ressources vpc.amazonaws.com sont définis sur 4. Les quatre adaptateurs EFA disponibles dans les nœuds p4d.24xlarge sont regroupés pour fournir un débit maximal.

Courir kubectl apply -f ./test-efa-nccl.yaml pour appliquer le test, puis afficher les journaux du module de test. La ligne suivante dans la sortie du journal confirme qu'EFA est utilisé :

NCCL INFO NET/OFI Selected Provider is efa

Les résultats du test devraient ressembler au résultat suivant :

[1,0]<stdout>:#                                                       out-of-place                       in-place
[1,0]<stdout>:#       size         count      type   redop     time   algbw   busbw  error     time   algbw   busbw  error
[1,0]<stdout>:#        (B)    (elements)                       (us)  (GB/s)  (GB/s)            (us)  (GB/s)  (GB/s)
[1,0]<stdout>:           8             2     float     sum    629.7    0.00    0.00  2e-07    631.4    0.00    0.00  1e-07
[1,0]<stdout>:          16             4     float     sum    630.5    0.00    0.00  1e-07    628.1    0.00    0.00  1e-07
[1,0]<stdout>:          32             8     float     sum    627.6    0.00    0.00  1e-07    628.2    0.00    0.00  1e-07
[1,0]<stdout>:          64            16     float     sum    633.6    0.00    0.00  1e-07    628.4    0.00    0.00  6e-08
[1,0]<stdout>:         128            32     float     sum    627.5    0.00    0.00  6e-08    632.0    0.00    0.00  6e-08
[1,0]<stdout>:         256            64     float     sum    634.5    0.00    0.00  6e-08    636.5    0.00    0.00  6e-08
[1,0]<stdout>:         512           128     float     sum    634.8    0.00    0.00  6e-08    635.2    0.00    0.00  6e-08
[1,0]<stdout>:        1024           256     float     sum    646.6    0.00    0.00  2e-07    643.6    0.00    0.00  2e-07
[1,0]<stdout>:        2048           512     float     sum    745.0    0.00    0.01  5e-07    746.0    0.00    0.01  5e-07
[1,0]<stdout>:        4096          1024     float     sum    958.2    0.00    0.01  5e-07    955.8    0.00    0.01  5e-07
[1,0]<stdout>:        8192          2048     float     sum    963.0    0.01    0.02  5e-07    954.5    0.01    0.02  5e-07
[1,0]<stdout>:       16384          4096     float     sum    955.0    0.02    0.03  5e-07    955.5    0.02    0.03  5e-07
[1,0]<stdout>:       32768          8192     float     sum    975.5    0.03    0.06  5e-07   1009.0    0.03    0.06  5e-07
[1,0]<stdout>:       65536         16384     float     sum   1353.4    0.05    0.09  5e-07   1343.5    0.05    0.09  5e-07
[1,0]<stdout>:      131072         32768     float     sum   1395.9    0.09    0.18  5e-07   1392.6    0.09    0.18  5e-07
[1,0]<stdout>:      262144         65536     float     sum   1476.7    0.18    0.33  5e-07   1536.3    0.17    0.32  5e-07
[1,0]<stdout>:      524288        131072     float     sum   1560.3    0.34    0.63  5e-07   1568.3    0.33    0.63  5e-07
[1,0]<stdout>:     1048576        262144     float     sum   1599.2    0.66    1.23  5e-07   1595.3    0.66    1.23  5e-07
[1,0]<stdout>:     2097152        524288     float     sum   1671.1    1.25    2.35  5e-07   1672.5    1.25    2.35  5e-07
[1,0]<stdout>:     4194304       1048576     float     sum   1785.1    2.35    4.41  5e-07   1780.3    2.36    4.42  5e-07
[1,0]<stdout>:     8388608       2097152     float     sum   2133.6    3.93    7.37  5e-07   2135.0    3.93    7.37  5e-07
[1,0]<stdout>:    16777216       4194304     float     sum   2650.9    6.33   11.87  5e-07   2649.9    6.33   11.87  5e-07
[1,0]<stdout>:    33554432       8388608     float     sum   3422.0    9.81   18.39  5e-07   3478.7    9.65   18.09  5e-07
[1,0]<stdout>:    67108864      16777216     float     sum   4783.2   14.03   26.31  5e-07   4782.6   14.03   26.31  5e-07
[1,0]<stdout>:   134217728      33554432     float     sum   7216.9   18.60   34.87  5e-07   7240.9   18.54   34.75  5e-07
[1,0]<stdout>:   268435456      67108864     float     sum    12738   21.07   39.51  5e-07    12802   20.97   39.31  5e-07
[1,0]<stdout>:   536870912     134217728     float     sum    24375   22.03   41.30  5e-07    24403   22.00   41.25  5e-07
[1,0]<stdout>:  1073741824     268435456     float     sum    47904   22.41   42.03  5e-07    47893   22.42   42.04  5e-07
[1,4]<stdout>:test-efa-nccl-worker-0:33:33 [4] NCCL INFO comm 0x7fd4a0000f60 rank 4 nranks 16 cudaDev 4 busId 901c0 - Destroy COMPLETE
[1,0]<stdout>:# Out of bounds values : 0 OK
[1,0]<stdout>:# Avg bus bandwidth    : 8.23785

Nous pouvons observer dans les résultats des tests que le débit maximum est d'environ 42 Go/s et la bande passante moyenne du bus est d'environ 8 Go.

Nous avons également mené des expériences avec un seul adaptateur EFA activé ainsi qu'avec aucun adaptateur EFA. Tous les résultats sont résumés dans le tableau suivant.

Nous avons également constaté que pour des modèles relativement petits comme ImageNet, l'utilisation d'une mise en réseau accélérée réduit le temps de formation par époque de seulement 5 à 8 % pour une taille de lot de 64. Pour les modèles plus grands et les lots plus petits, lorsqu'une communication réseau accrue des poids est nécessaire. , l’utilisation d’une mise en réseau accélérée a un plus grand impact. Nous avons observé une diminution du temps de formation par époque de 15 à 18 % pour la formation d'EfficientNet-B7 avec une taille de lot de 1. L'impact réel de l'EFA sur votre formation dépendra de la taille de votre modèle.

Surveillance du GPU

Avant d'exécuter la tâche de formation, nous pouvons également configurer Amazon Cloud Watch des métriques pour visualiser l’utilisation du GPU pendant l’entraînement. Il peut être utile de savoir si les ressources sont utilisées de manière optimale ou d'identifier potentiellement le manque de ressources et les goulots d'étranglement dans le processus de formation.

Les scripts pertinents pour configurer CloudWatch se trouvent dans le métriques GPU dossier. Tout d’abord, nous créons une image Docker avec amazon-cloudwatch-agent ainsi que nvidia-smi. Nous pouvons utiliser le Dockerfile dans le gpu-metrics dossier pour créer cette image. En supposant que le registre ECR soit déjà défini dans le .env fichier de l’étape précédente, nous pouvons construire et pousser l’image en utilisant build.sh ainsi que push.sh. Après cela, exécutez le deploy.sh Le script termine automatiquement la configuration. Il lance un démonset avec amazon-cloudwatch-agent et transmet diverses métriques à CloudWatch. Les métriques GPU apparaissent sous le CWAgent espace de noms sur la console CloudWatch. Le reste des métriques du cluster s'affiche sous le ContainerInsights espace de noms.

Formation de modèle

Tous les scripts nécessaires à la formation PyTorch se trouvent dans le travail élastique dossier dans le dépôt GitHub. Avant de lancer la tâche de formation, nous devons exécuter le etcd serveur, qui est utilisé par le TEC pour la découverte des travailleurs et l'échange de paramètres. Le déployer.sh script dans le elasticjob le dossier fait exactement cela.

Pour profiter de l'EFA dans les instances p4d.24xlarge, nous devons utiliser une image Docker spécifique disponible dans le Galerie publique Amazon ECR qui prend en charge la communication NCCL via EFA. Il nous suffit de copier notre code de formation sur cette image Docker. Le Dockerfile sous le échantillons Le dossier crée une image à utiliser lors de l'exécution d'une tâche de formation sur des instances p4d. Comme toujours, nous pouvons utiliser le build.sh ainsi que push.sh scripts dans le dossier pour créer et pousser l’image.

Les imagenet-efa.yaml Le fichier décrit le travail de formation. Ce fichier .yaml configure les ressources nécessaires à l'exécution de la tâche de formation et monte également le volume persistant avec les données de formation configurées dans la section précédente.

Deux ou trois choses méritent d’être soulignées ici. Le nombre de réplicas doit être défini sur le nombre de nœuds disponibles dans le cluster. Dans notre cas, nous avons défini cette valeur sur 3 car nous avions trois nœuds p4d.24xlarge. Dans le imagenet-efa.yaml fichier, le nvidia.com/gpu paramètre sous ressources et nproc_per_node sous args doit être défini sur le nombre de GPU par nœud, qui dans le cas de p4d.24xlarge est de 8. De plus, l'argument travailleur du script Python définit le nombre de processeurs par processus. Nous avons choisi la valeur 4 car, dans nos expériences, cela offre des performances optimales lors de l'exécution sur des instances p4d.24xlarge. Ces paramètres sont nécessaires afin de maximiser l'utilisation de toutes les ressources matérielles disponibles dans le cluster.

Lorsque le travail est en cours d'exécution, nous pouvons observer l'utilisation du GPU dans CloudWatch pour tous les GPU du cluster. Ce qui suit est un exemple tiré de l'une de nos tâches de formation avec trois nœuds p4d.24xlarge dans le cluster. Ici, nous avons sélectionné un GPU pour chaque nœud. Avec les paramètres mentionnés précédemment, l'utilisation du GPU est proche de 100 % pendant la phase de formation de l'époque pour tous les nœuds du cluster.

Pour former un modèle ResNet50 à l'aide d'instances p3.8xlarge, nous avons besoin exactement des mêmes étapes que celles décrites pour la formation EfficientNet à l'aide de p4d.24xlarge. Nous pouvons également utiliser la même image Docker. Comme mentionné précédemment, les instances p3.8xlarge ne sont pas équipées d’EFA. Cependant, pour le modèle ResNet50, ce n'est pas un inconvénient majeur. Le imagenet-fsx.yaml Le script fourni dans le référentiel GitHub configure la tâche de formation avec les ressources appropriées pour le type de nœud p3.8xlarge. La tâche utilise le même ensemble de données du système de fichiers FSx.

Mise à l'échelle du processeur graphique

Nous avons mené quelques expériences pour observer comment le temps de formation évolue pour le modèle EfficientNet-B7 en augmentant le nombre de GPU. Pour ce faire, nous avons modifié le nombre de réplicas de 1 à 3 dans notre fichier .yaml de formation pour chaque exécution de formation. Nous n'avons observé l'heure que pour une seule époque en utilisant l'ensemble de données ImageNet complet. La figure suivante montre les résultats de notre expérience de mise à l'échelle du GPU. La ligne pointillée rouge représente la façon dont le temps de formation devrait diminuer à partir d'une exécution utilisant 8 GPU en augmentant le nombre de GPU. Comme nous pouvons le constater, la mise à l’échelle est assez proche de celle attendue.

De même, nous avons obtenu le tracé de mise à l'échelle GPU pour la formation ResNet50 sur les instances p3.8xlarge. Pour ce cas, nous avons modifié les réplicas dans notre fichier .yaml de 1 à 4. Les résultats de cette expérience sont présentés dans la figure suivante.

Nettoyer

Il est important de ralentir les ressources après la formation du modèle afin d'éviter les coûts associés à l'exécution d'instances inactives. Avec chaque script qui crée des ressources, le GitHub repo fournit un script correspondant pour les supprimer. Pour nettoyer notre configuration, nous devons supprimer le système de fichiers FSx avant de supprimer le cluster car il est associé à un sous-réseau dans le VPC du cluster. Pour supprimer le système de fichiers FSx, il suffit d'exécuter la commande suivante (depuis l'intérieur du FSX dossier):

kubectl delete -f fsx-pvc-dynamic.yaml
./delete.sh

Notez que cela supprimera non seulement le volume persistant, mais également le système de fichiers FSx et toutes les données du système de fichiers seront perdues. Une fois cette étape terminée, nous pouvons supprimer le cluster en utilisant le script suivant dans le ex dossier:

./eks-delete.sh

Cela supprimera tous les pods existants, supprimera le cluster et supprimera le VPC créé au début.

Conclusion

Dans cet article, nous avons détaillé les étapes nécessaires pour exécuter la formation de modèles parallèles de données distribuées PyTorch sur les clusters EKS. Cette tâche peut paraître ardue, mais le AWS DevOps pour EKS Le projet créé par l'équipe ML Frameworks d'AWS fournit tous les scripts et outils nécessaires pour simplifier le processus et rendre la formation de modèles distribués facilement accessible.

Pour plus d'informations sur les technologies utilisées dans cet article, visitez Amazon EKS ainsi que Élastique distribué par torche. Nous vous encourageons à appliquer l’approche décrite ici à vos propres cas d’utilisation de formation distribuée.

Ressources

À propos des auteurs

Imran Younus est architecte de solutions principal pour l'équipe ML Frameworks chez AWS. Il se concentre sur les charges de travail d'apprentissage automatique et d'apprentissage profond à grande échelle sur les services AWS tels qu'Amazon EKS et AWS ParallelCluster. Il possède une vaste expérience dans les applications du Deep Leaning en vision par ordinateur et en IoT industriel. Imran a obtenu son doctorat en physique des particules de haute énergie où il a participé à l'analyse de données expérimentales à l'échelle du péta-octet.

Alex Yankoulski est un architecte logiciel et infrastructure full-stack qui aime faire un travail approfondi et pratique. Il est actuellement architecte principal de solutions pour l'apprentissage automatique autogéré chez AWS. Dans son rôle, il se concentre sur l'aide aux clients pour la conteneurisation et l'orchestration des charges de travail ML et AI sur les services AWS alimentés par conteneurs. Il est également l'auteur de l'open source Faire le cadre et un capitaine Docker qui aime appliquer les technologies de conteneurs pour accélérer le rythme de l'innovation tout en résolvant les plus grands défis du monde. Au cours des 10 dernières années, Alex a travaillé sur la lutte contre le changement climatique, la démocratisation de l'IA et du ML, rendant les voyages plus sûrs, les soins de santé meilleurs et l'énergie plus intelligente.