Gedistribueerde training met Amazon EKS en Torch Distributed Elastic

Heruitgegeven door Plato

volgers: 0

Gedistribueerde deep learning-modeltraining wordt steeds belangrijker naarmate de gegevensgrootte in veel industrieën groeit. Veel toepassingen in computervisie en natuurlijke taalverwerking vereisen nu training van deep learning-modellen, die exponentieel in complexiteit groeien en vaak worden getraind met honderden terabytes aan gegevens. Het wordt dan belangrijk om een uitgebreide cloudinfrastructuur te gebruiken om de training van dergelijke grote modellen op te schalen.

Ontwikkelaars kunnen open-source frameworks zoals PyTorch gebruiken om eenvoudig intuïtieve modelarchitecturen te ontwerpen. Het schalen van de training van deze modellen over meerdere knooppunten kan echter een uitdaging zijn vanwege de toegenomen orkestratie-complexiteit.

Gedistribueerde modeltraining bestaat voornamelijk uit twee paradigma's:

parallel modelleren – Bij modelparallelle training is het model zelf zo groot dat het niet in het geheugen van een enkele GPU past, en er zijn meerdere GPU's nodig om het model te trainen. Het GPT-3-model van Open AI met 175 miljard trainbare parameters (ongeveer 350 GB groot) is hier een goed voorbeeld van.
Gegevens parallel – Bij dataparallelle training kan het model zich in een enkele GPU bevinden, maar omdat de gegevens zo groot zijn, kan het dagen of weken duren om een model te trainen. Het distribueren van de gegevens over meerdere GPU-knooppunten kan de trainingstijd aanzienlijk verkorten.

In dit bericht bieden we een voorbeeldarchitectuur om PyTorch-modellen te trainen met behulp van de Fakkel gedistribueerd elastiek framework op een parallelle manier gedistribueerde gegevens met behulp van Amazon Elastic Kubernetes-service (Amazone EKS).

Voorwaarden

Om de resultaten die in dit bericht worden gerapporteerd te repliceren, is de enige vereiste een AWS-account. In dit account maken we een EKS-cluster en een Amazon FSx voor Luster bestandssysteem. We pushen ook containerafbeeldingen naar een Amazon Elastic Container-register (Amazon ECR) repository in het account. Instructies voor het instellen van deze componenten worden zo nodig door de hele post heen gegeven.

EKS-clusters

Amazon EKS is een beheerde containerservice om Kubernetes-applicaties op AWS uit te voeren en te schalen. Met Amazon EKS kunt u efficiënt gedistribueerde trainingstaken uitvoeren met behulp van de nieuwste Amazon Elastic Compute-cloud (Amazon EC2) instanties zonder dat u uw eigen besturingsvlak of knooppunten hoeft te installeren, bedienen en onderhouden. Het is een populaire orchestrator voor machine learning (ML) en AI-workflows. Een typisch EKS-cluster in AWS ziet eruit als de volgende afbeelding.

We hebben een open-source project uitgebracht, AWS DevOps voor EKS (aws-do-eks), dat een grote verzameling gebruiksvriendelijke en configureerbare scripts en tools biedt om EKS-clusters in te richten en gedistribueerde trainingstaken uit te voeren. Dit project is gebouwd volgens de principes van de Kader doen: Eenvoud, flexibiliteit en universaliteit. U kunt uw gewenste cluster configureren met behulp van de eks.conf bestand en start het vervolgens door de eks-creëren.sh script. Gedetailleerde instructies vindt u in de GitHub repo.

PyTorch-modellen trainen met Torch Distributed Elastic

Torch Distributed Elastic (TDE) is een native PyTorch-bibliotheek voor het trainen van grootschalige deep learning-modellen waarbij het van cruciaal belang is om rekenbronnen dynamisch te schalen op basis van beschikbaarheid. De TorchElastic Controller voor Kubernetes is een native Kubernetes-implementatie voor TDE die automatisch de levenscyclus beheert van de pods en services die nodig zijn voor TDE-training. Het maakt het mogelijk om rekenbronnen dynamisch te schalen tijdens de training als dat nodig is. Het biedt ook fouttolerante training door taken te herstellen van knooppuntstoringen.

In dit bericht bespreken we de stappen om PyTorch . te trainen EfficiëntNet-B7 en ResNet 50 modellen met behulp van IMAGEnet gegevens op een gedistribueerde manier met TDE. We gebruiken de PyTorch Gedistribueerde gegevens parallel API en de Kubernetes TorchElastic-controller, en voer onze trainingstaken uit op een EKS-cluster met meerdere GPU-knooppunten. Het volgende diagram toont het architectuurdiagram voor deze modeltraining.

TorchElastic voor Kubernetes bestaat hoofdzakelijk uit twee componenten: de TorchElastic Kubernetes Controller (TEC) en de parameterserver (etcd). De controller is verantwoordelijk voor het bewaken en beheren van de trainingstaken, en de parameterserver houdt de werkknooppunten bij voor gedistribueerde synchronisatie en peer-detectie.

Om ervoor te zorgen dat de trainingspods toegang hebben tot de gegevens, hebben we een gedeeld gegevensvolume nodig dat door elke pod kan worden gekoppeld. Enkele opties voor gedeelde volumes via Interface voor containeropslag (CSI)-stuurprogramma's inbegrepen in AWS DevOps voor EKS zijn Amazon elastisch bestandssysteem (Amazon EFS) en FSx voor glans.

Clusterconfiguratie

In onze clusterconfiguratie gebruiken we één c5.2xlarge-instantie voor systeempods. We gebruiken drie p4d.24xlarge-instanties als werkpods om een EfficientNet-model te trainen. Voor ResNet50-training gebruiken we p3.8xlarge instances als worker-pods. Bovendien gebruiken we een gedeeld FSx-bestandssysteem om onze trainingsgegevens en modelartefacten op te slaan.

AWS p4d.24xgrote instanties zijn uitgerust met: Elastische stofadapter (EFA) om netwerken tussen knooppunten te bieden. We bespreken EFA later in de post meer. Om communicatie via EFA mogelijk te maken, moeten we de clusterconfiguratie configureren via een .yaml-bestand. Een voorbeeldbestand wordt geleverd in de GitHub-repository.

Nadat dit .yaml-bestand correct is geconfigureerd, kunnen we het cluster starten met behulp van het script in de GitHub-repo:

./eks-create.sh

Verwijs naar de GitHub repo voor gedetailleerde instructies.

Er is praktisch geen verschil tussen het uitvoeren van taken op p4d.24xlarge en p3.8xlarge. De stappen die in dit bericht worden beschreven, werken voor beide. Het enige verschil is de beschikbaarheid van EFA op p4d.24xlarge instances. Voor kleinere modellen zoals ResNet50 heeft standaardnetwerken in vergelijking met EFA-netwerken een minimale impact op de trainingssnelheid.

FSx voor Lustre-bestandssysteem

FSx is ontworpen voor high-performance computerworkloads en biedt submilliseconden latentie bij gebruik van solid-state drive-opslagvolumes. We kozen voor FSx omdat het betere prestaties opleverde omdat we opschaalden naar een groot aantal nodes. Een belangrijk detail om op te merken is dat FSx alleen in een enkele beschikbaarheidszone kan bestaan. Daarom moeten alle knooppunten die toegang hebben tot het FSx-bestandssysteem zich in dezelfde Beschikbaarheidszone bevinden als het FSx-bestandssysteem. Een manier om dit te bereiken is door de relevante Beschikbaarheidszone op te geven in het cluster .yaml-bestand voor de specifieke knooppuntgroepen voordat u het cluster maakt. Als alternatief kunnen we het netwerkgedeelte van de groep voor automatisch schalen voor deze knooppunten wijzigen nadat het cluster is ingesteld, en het beperken tot het gebruik van een enkel subnet. Dit kan eenvoudig op de Amazon EC2-console.

Ervan uitgaande dat het EKS-cluster actief is en de subnet-ID voor de Beschikbaarheidszone bekend is, kunnen we een FSx-bestandssysteem opzetten door de nodige informatie in de fsx.conf bestand zoals beschreven in de readme en het runnen van de implementeren.sh script in de FSX map. Dit stelt het juiste beleid en de juiste beveiligingsgroep in voor toegang tot het bestandssysteem. Het script installeert ook de CSI-stuurprogramma voor FSx als een daemonset. Ten slotte kunnen we de persistente volumeclaim van FSx in Kubernetes maken door een enkel .yaml-bestand toe te passen:

kubectl apply -f fsx-pvc-dynamic.yaml

Dit creëert een FSX-bestandssysteem in de Beschikbaarheidszone gespecificeerd in de fsx.conf bestand, en maakt ook een aanhoudende volumeclaim fsx-pvc, die door een van de pods in het cluster op een read-write-many (RWX)-manier kan worden gemonteerd.

In ons experiment hebben we volledige ImageNet-gegevens gebruikt, die meer dan 12 miljoen trainingsafbeeldingen bevatten, verdeeld over 1,000 klassen. De gegevens kunnen worden gedownload van de ImageNet-website. De originele TAR-bal heeft verschillende mappen, maar voor onze modeltraining zijn we alleen geïnteresseerd in: ILSVRC/Data/CLS-LOC/, waaronder de train en val submappen. Voordat we gaan trainen, moeten we de afbeeldingen in de val subdirectory die overeenkomt met de directorystructuur die vereist is door de PyTorch Afbeeldingsmap klas. Dit kan worden gedaan met behulp van een eenvoudige Python-script nadat de gegevens in de volgende stap naar het persistente volume zijn gekopieerd.

Om de gegevens te kopiëren van een Amazon eenvoudige opslagservice (Amazon S3) bucket naar het FSx-bestandssysteem, maken we een Docker-image met scripts voor deze taak. Een voorbeeld Dockerfile en een shellscript zijn opgenomen in de csi map in de GitHub-repo. We kunnen de afbeelding bouwen met behulp van de build.sh script en push het vervolgens naar Amazon ECR met de push.sh script. Voordat we deze scripts gebruiken, moeten we de juiste URI voor de ECR-repository opgeven in de .env bestand in de hoofdmap van de GitHub-repo. Nadat we de Docker-afbeelding naar Amazon ECR hebben gepusht, kunnen we een pod starten om de gegevens te kopiëren door het relevante .yaml-bestand toe te passen:

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

De pod voert het script automatisch uit data-prep.sh om de gegevens van Amazon S3 naar het gedeelde volume te kopiëren. Omdat de ImageNet-gegevens meer dan 12 miljoen bestanden bevatten, duurt het kopieerproces een paar uur. Het Python-script imagenet_data_prep.py wordt ook uitgevoerd om de . te herschikken val dataset zoals verwacht door PyTorch.

Netwerkversnelling

We kunnen Elastic Fabric Adapter (EFA) gebruiken in combinatie met: ondersteunde EC2-instantietypen om het netwerkverkeer tussen de GPU-knooppunten in uw cluster te versnellen. Dit kan handig zijn bij het uitvoeren van grote gedistribueerde trainingstaken waarbij standaardnetwerkcommunicatie een knelpunt kan zijn. Scripts voor het implementeren en testen van de EFA-apparaatplug-in in het EKS-cluster die we hier gebruiken, zijn opgenomen in de: efa-apparaat-plug-in map in de GitHub-opslagplaats. Om een taak met EFA in uw EKS-cluster mogelijk te maken, moet naast de clusterknooppunten met de benodigde hardware en software, de EFA-apparaatplug-in in het cluster worden geïmplementeerd en moet uw taakcontainer compatibele CUDA en NCCL hebben versies geïnstalleerd.

Om het uitvoeren van NCCL-tests te demonstreren en de prestaties van EFA op p4d.24xlarge-instanties te evalueren, moeten we eerst de Kubeflow MPI-operator implementeren door de bijbehorende implementeren.sh script in de mpi-operator map. Dan runnen we de implementeren.sh script en update de test-efa-nccl.yaml manifest dus limieten en verzoeken om middelen vpc.amazonaws.com zijn ingesteld op 4. De vier beschikbare EFA-adapters in de p4d.24xlarge-knooppunten worden gebundeld om maximale doorvoer te bieden.

lopen kubectl apply -f ./test-efa-nccl.yaml om de test toe te passen en vervolgens de logs van de testpod weer te geven. De volgende regel in de loguitvoer bevestigt dat EFA wordt gebruikt:

NCCL INFO NET/OFI Selected Provider is efa

De testresultaten moeten er ongeveer uitzien als de volgende uitvoer:

[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

We kunnen in de testresultaten zien dat de maximale doorvoer ongeveer 42 GB/sec is en de gemiddelde busbandbreedte ongeveer 8 GB.

We hebben ook experimenten uitgevoerd met een enkele EFA-adapter ingeschakeld en zonder EFA-adapters. Alle resultaten zijn samengevat in de volgende tabel.

Aantal EFA-adapters	Net/OFI geselecteerde provider	Gem. Bandbreedte (GB/s)	Maximaal Bandbreedte (GB/s)
4	efa	8.24	42.04
1	efa	3.02	5.89
0	stopcontact	0.97	2.38

We ontdekten ook dat voor relatief kleine modellen zoals ImageNet, het gebruik van versnelde netwerken de trainingstijd per epoch slechts met 5-8% vermindert bij een batchgrootte van 64. Voor grotere modellen en kleinere batchgroottes, wanneer meer netwerkcommunicatie van gewichten nodig is , heeft het gebruik van versneld netwerken een grotere impact. We zagen een afname van de epoch-trainingstijd met 15-18% voor training van EfficientNet-B7 met batchgrootte 1. De daadwerkelijke impact van EFA op uw training hangt af van de grootte van uw model.

GPU-bewaking

Voordat we de trainingstaak uitvoeren, kunnen we ook instellen: Amazon Cloud Watch metrische gegevens om het GPU-gebruik tijdens de training te visualiseren. Het kan nuttig zijn om te weten of de middelen optimaal worden gebruikt of om mogelijk gebrek aan middelen en knelpunten in het opleidingsproces te identificeren.

De relevante scripts om CloudWatch in te stellen bevinden zich in de gpu-statistieken map. Eerst maken we een Docker-image met amazon-cloudwatch-agent en nvidia-smi. We kunnen de Dockerfile gebruiken in de gpu-metrics map om deze afbeelding te maken. Ervan uitgaande dat het ECR-register al is ingesteld in de .env bestand uit de vorige stap, kunnen we de afbeelding bouwen en pushen met build.sh en push.sh. Hierna draait de deploy.sh script voltooit automatisch de installatie. Het lanceert een daemonset met amazon-cloudwatch-agent en pusht verschillende statistieken naar CloudWatch. De GPU-statistieken verschijnen onder de CWAgent naamruimte op de CloudWatch-console. De rest van de clusterstatistieken wordt weergegeven onder de ContainerInsights naamruimte.

Modeltraining

Alle scripts die nodig zijn voor PyTorch-training bevinden zich in de elastische baan map in de GitHub-opslagplaats. Voordat we de trainingstaak starten, moeten we de etcd server, die door de TEC wordt gebruikt voor het opsporen van werknemers en het uitwisselen van parameters. De implementeren.sh script in de elasticjob map doet precies dat.

Om te profiteren van EFA in p4d.24xlarge-instanties, moeten we een specifieke Docker-afbeelding gebruiken die beschikbaar is in de Amazon ECR openbare galerij die NCCL-communicatie via EFA ondersteunt. We hoeven alleen onze trainingscode naar deze Docker-afbeelding te kopiëren. De Dockerfile onder de monsters map maakt een afbeelding die moet worden gebruikt bij het uitvoeren van een trainingstaak op p4d-instanties. Zoals altijd kunnen we de bouwen.sh en push.sh scripts in de map om de afbeelding te bouwen en te pushen.

De imagenet-efa.yaml bestand beschrijft de trainingstaak. Dit .yaml-bestand stelt de bronnen in die nodig zijn voor het uitvoeren van de trainingstaak en koppelt ook het persistente volume aan de trainingsgegevens die in de vorige sectie zijn ingesteld.

Een paar dingen zijn hier het vermelden waard. Het aantal replica's moet worden ingesteld op het aantal knoop punten dat beschikbaar is in het cluster. In ons geval hebben we dit ingesteld op 3 omdat we drie p4d.24xlarge-knooppunten hadden. In de imagenet-efa.yaml bestand, het nvidia.com/gpu parameter onder middelen en nproc_per_node voor args moet worden ingesteld op het aantal GPU's per knooppunt, wat in het geval van p4d.24xlarge 8 is. Ook stelt het worker-argument voor het Python-script het aantal CPU's per proces in. We hebben ervoor gekozen om 4 te zijn omdat dit in onze experimenten optimale prestaties levert bij gebruik op p4d.24xlarge instances. Deze instellingen zijn nodig om het gebruik van alle beschikbare hardwarebronnen in het cluster te maximaliseren.

Wanneer de taak wordt uitgevoerd, kunnen we het GPU-gebruik in CloudWatch observeren voor alle GPU's in het cluster. Het volgende is een voorbeeld van een van onze trainingstaken met drie p4d.24xlarge-knooppunten in het cluster. Hier hebben we één GPU van elk knooppunt geselecteerd. Met de eerder genoemde instellingen is het GPU-gebruik bijna 100% tijdens de trainingsfase van het tijdperk voor alle knooppunten in het cluster.

Voor het trainen van een ResNet50-model met p3.8xlarge-instanties hebben we precies dezelfde stappen nodig als beschreven voor de EfficientNet-training met p4d.24xlarge. We kunnen ook dezelfde Docker-afbeelding gebruiken. Zoals eerder vermeld, zijn p3.8xlarge-instanties niet uitgerust met EFA. Voor het ResNet50-model is dit echter geen significant nadeel. De imagenet-fsx.yaml script dat in de GitHub-repository wordt geleverd, stelt de trainingstaak in met de juiste bronnen voor het p3.8xlarge-knooppunttype. De taak gebruikt dezelfde dataset van het FSx-bestandssysteem.

GPU-schaalverdeling

We hebben enkele experimenten uitgevoerd om te zien hoe de trainingstijd voor het EfficientNet-B7-model wordt geschaald door het aantal GPU's te vergroten. Om dit te doen, hebben we het aantal replica's gewijzigd van 1 in 3 in ons .yaml-trainingsbestand voor elke trainingsrun. We observeerden slechts de tijd voor een enkel tijdperk terwijl we de volledige ImageNet-dataset gebruikten. De volgende afbeelding toont de resultaten voor ons GPU-schaalexperiment. De rode stippellijn geeft aan hoe de trainingstijd moet afnemen van een run met 8 GPU's door het aantal GPU's te vergroten. Zoals we kunnen zien, ligt de schaal vrij dicht bij wat wordt verwacht.

Op dezelfde manier hebben we de GPU-schaalgrafiek verkregen voor ResNet50-training op p3.8xlarge-instanties. Voor dit geval hebben we de replica's in ons .yaml-bestand gewijzigd van 1 in 4. De resultaten van dit experiment worden weergegeven in de volgende afbeelding.

Opruimen

Het is belangrijk om resources na de training van het model af te bouwen om kosten te vermijden die gepaard gaan met het uitvoeren van inactieve instanties. Met elk script dat bronnen creëert, GitHub repo biedt een overeenkomend script om ze te verwijderen. Om onze setup op te schonen, moeten we het FSx-bestandssysteem verwijderen voordat we het cluster verwijderen, omdat het is gekoppeld aan een subnet in de VPC van het cluster. Om het FSx-bestandssysteem te verwijderen, hoeven we alleen de volgende opdracht uit te voeren (van binnenuit de FSX map):

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

Merk op dat hierdoor niet alleen het persistente volume wordt verwijderd, maar ook het FSx-bestandssysteem en alle gegevens op het bestandssysteem gaan verloren. Wanneer deze stap is voltooid, kunnen we het cluster verwijderen met behulp van het volgende script in de ex map:

./eks-delete.sh

Hiermee worden alle bestaande pods verwijderd, het cluster verwijderd en de in het begin gemaakte VPC verwijderd.

Conclusie

In dit bericht hebben we de stappen beschreven die nodig zijn voor het uitvoeren van PyTorch-training voor parallelle gedistribueerde gegevensmodellen op EKS-clusters. Deze taak lijkt misschien ontmoedigend, maar de AWS DevOps voor EKS project gemaakt door het ML Frameworks-team van AWS biedt alle benodigde scripts en hulpmiddelen om het proces te vereenvoudigen en gedistribueerde modeltraining gemakkelijk toegankelijk te maken.

Ga voor meer informatie over de technologieën die in dit bericht worden gebruikt naar Amazon EX en Fakkel gedistribueerd elastiek. We raden u aan om de hier beschreven aanpak toe te passen op uw eigen gedistribueerde gebruiksscenario's voor trainingen.

Resources

Over de auteurs

Imran Younus is een Principal Solutions Architect voor het ML Frameworks-team bij AWS. Hij richt zich op grootschalige machine learning en deep learning-workloads voor AWS-services zoals Amazon EKS en AWS ParallelCluster. Hij heeft uitgebreide ervaring in toepassingen van Deep Leaning in Computer Vision en Industrial IoT. Imran promoveerde in High Energy Particle Physics waar hij betrokken was bij het analyseren van experimentele data op peta-byte schalen.

Alex Iankouski is een full-stack software- en infrastructuurarchitect die graag diepgaand, hands-on werk doet. Momenteel is hij Principal Solutions Architect for Self-managed Machine Learning bij AWS. In zijn rol richt hij zich op het helpen van klanten met containerisatie en orkestratie van ML- en AI-workloads op container-aangedreven AWS-services. Hij is ook de auteur van de open source Doe kader en een Docker-kapitein die dol is op het toepassen van containertechnologieën om het innovatietempo te versnellen en 's werelds grootste uitdagingen op te lossen. De afgelopen 10 jaar heeft Alex gewerkt aan het bestrijden van klimaatverandering, het democratiseren van AI en ML, het veiliger maken van reizen, het verbeteren van de gezondheidszorg en het slimmer maken van energie.