Porazdeljeno usposabljanje z Amazon EKS in Torch Distributed Elastic

Usposabljanje na modelu porazdeljenega globokega učenja postaja vse pomembnejše, saj velikosti podatkov v številnih panogah naraščajo. Številne aplikacije v računalniškem vidu in obdelavi naravnega jezika zdaj zahtevajo usposabljanje modelov globokega učenja, ki eksponentno naraščajo v kompleksnosti in se pogosto usposabljajo s stotinami terabajtov podatkov. Nato postane pomembna uporaba obsežne infrastrukture v oblaku za povečanje obsega usposabljanja tako velikih modelov.

Razvijalci lahko uporabljajo odprtokodna ogrodja, kot je PyTorch, za enostavno oblikovanje intuitivnih arhitektur modelov. Vendar je prilagajanje usposabljanja teh modelov na več vozliščih lahko izziv zaradi povečane kompleksnosti orkestracije.

Usposabljanje po porazdeljenem modelu je v glavnem sestavljeno iz dveh paradigem:

• Vzporedni model – Pri vzporednem usposabljanju modela je sam model tako velik, da se ne more prilegati v pomnilnik ene same GPE, zato je za usposabljanje modela potrebnih več GPE. Model GPT-3 Open AI s 175 milijardami učljivih parametrov (velikosti približno 350 GB) je dober primer tega.
• Vzporedni podatki – Pri vzporednem usposabljanju podatkov se lahko model nahaja v enem samem GPE-ju, a ker so podatki tako veliki, lahko usposabljanje modela traja nekaj dni ali tednov. Porazdelitev podatkov med več vozlišči GPE lahko znatno skrajša čas usposabljanja.

V tej objavi ponujamo primer arhitekture za usposabljanje modelov PyTorch z uporabo Torch Distributed Elastic ogrodje na vzporedni način s porazdeljenimi podatki Amazonski elastični kubernetes storitev (Amazon EKS).

Predpogoji

Za ponovitev rezultatov, navedenih v tej objavi, je edini predpogoj račun AWS. V tem računu ustvarimo gručo EKS in an Amazon FSx za Luster datotečni sistem. Prav tako potiskamo slike vsebnikov v an Registar elastičnih zabojnikov Amazon (Amazon ECR) repozitorij v računu. Navodila za nastavitev teh komponent so po potrebi na voljo v celotni objavi.

EKS grozdi

Amazon EKS je upravljana vsebniška storitev za izvajanje in prilagajanje aplikacij Kubernetes na AWS. Z Amazon EKS lahko učinkovito izvajate porazdeljena usposabljanja z uporabo najnovejših Amazonski elastični računalniški oblak (Amazon EC2), ne da bi morali namestiti, upravljati in vzdrževati lastno nadzorno ravnino ali vozlišča. To je priljubljena orkestrator za strojno učenje (ML) in poteke dela AI. Tipična gruča EKS v AWS izgleda kot naslednja slika.

Izdali smo odprtokodni projekt, AWS DevOps za EKS (aws-do-eks), ki ponuja veliko zbirko enostavnih in nastavljivih skriptov in orodij za zagotavljanje gruče EKS in izvajanje porazdeljenih izobraževalnih opravil. Ta projekt je zgrajen po načelih Naredi okvir: Enostavnost, prilagodljivost in univerzalnost. Želeno gručo lahko konfigurirate z uporabo eks.konf datoteko in jo nato zaženite tako, da zaženete eks-create.sh scenarij. Podrobna navodila so na voljo v GitHub repo.

Usposobite modele PyTorch z uporabo Torch Distributed Elastic

Torch Distributed Elastic (TDE) je izvorna knjižnica PyTorch za usposabljanje obsežnih modelov globokega učenja, kjer je ključnega pomena dinamično prilagajanje računalniških virov glede na razpoložljivost. The Krmilnik TorchElastic za Kubernetes je izvorna implementacija Kubernetes za TDE, ki samodejno upravlja življenjski cikel podov in storitev, potrebnih za usposabljanje TDE. Po potrebi omogoča dinamično prilagajanje računalniških virov med usposabljanjem. Zagotavlja tudi usposabljanje, odporno na napake, z obnovitvijo opravil po okvari vozlišča.

V tej objavi razpravljamo o korakih za usposabljanje PyTorcha EfficientNet-B7 in ResNet50 modeli, ki uporabljajo ImageNet podatkov na porazdeljen način s TDE. Uporabljamo PyTorch DistributedDataParallel API in krmilnik Kubernetes TorchElastic ter zaženite naša usposabljanja v gruči EKS, ki vsebuje več vozlišč GPU. Naslednji diagram prikazuje diagram arhitekture za ta model usposabljanja.

TorchElastic za Kubernetes je sestavljen predvsem iz dveh komponent: krmilnika TorchElastic Kubernetes (TEC) in strežnika parametrov (etcd). Krmilnik je odgovoren za spremljanje in upravljanje opravil usposabljanja, strežnik parametrov pa spremlja delovna vozlišča za porazdeljeno sinhronizacijo in odkrivanje vrstnikov.

Da bi vadbeni moduli lahko dostopali do podatkov, potrebujemo skupno podatkovno količino, ki jo lahko namesti vsak modul. Nekatere možnosti za skupne nosilce prek Vmesnik za shranjevanje vsebnikov (CSI) vključeni gonilniki AWS DevOps za EKS so Elastični datotečni sistem Amazon (Amazon EFS) in FSx za Luster.

Nastavitev gruče

V naši konfiguraciji gruče uporabljamo en primerek c5.2xlarge za sistemske bloke. Uporabljamo tri primerke p4d.24xlarge kot delavske enote za usposabljanje modela EfficientNet. Za usposabljanje ResNet50 uporabljamo primerke p3.8xlarge kot delavske enote. Poleg tega uporabljamo skupni datotečni sistem FSx za shranjevanje naših podatkov o usposabljanju in artefaktov modela.

Primerki AWS p4d.24xlarge so opremljeni z Adapter za elastične tkanine (EFA) za zagotavljanje mreženja med vozlišči. Več o EFA bomo razpravljali kasneje v objavi. Da omogočimo komunikacijo prek EFA, moramo konfigurirati nastavitev gruče prek datoteke .yaml. An primer datoteke je na voljo v repozitoriju GitHub.

Ko je ta datoteka .yaml pravilno konfigurirana, lahko zaženemo gručo s skriptom, ki je na voljo v GitHub repo:

./eks-create.sh

Glejte GitHub repo za podrobnejša navodila.

Praktično ni razlike med izvajanjem opravil na p4d.24xlarge in p3.8xlarge. Koraki, opisani v tej objavi, delujejo za oba. Edina razlika je razpoložljivost EFA na primerkih p4d.24xlarge. Pri manjših modelih, kot je ResNet50, standardno mreženje v primerjavi z omrežjem EFA minimalno vpliva na hitrost usposabljanja.

FSx za datotečni sistem Lustre

FSx je zasnovan za visoko zmogljive računalniške delovne obremenitve in zagotavlja zakasnitev pod milisekundo z uporabo prostorov za shranjevanje pogonov SSD. Izbrali smo FSx, ker je zagotavljal boljšo zmogljivost, saj smo razširili na veliko število vozlišč. Pomembna podrobnost, ki jo je treba upoštevati, je, da lahko FSx obstaja samo v enem samem območju razpoložljivosti. Zato bi morala vsa vozlišča, ki dostopajo do datotečnega sistema FSx, obstajati v istem območju razpoložljivosti kot datotečni sistem FSx. Eden od načinov za dosego tega je določitev ustreznega območja razpoložljivosti v datoteki .yaml gruče za določene skupine vozlišč, preden ustvarite gruče. Druga možnost je, da spremenimo omrežni del skupine za samodejno skaliranje za ta vozlišča, potem ko je gruča nastavljena, in jo omejimo na uporabo enega samega podomrežja. To lahko preprosto storite na konzoli Amazon EC2.

Ob predpostavki, da je gruča EKS vzpostavljena in deluje in je ID podomrežja za območje razpoložljivosti znan, lahko nastavimo datotečni sistem FSx tako, da zagotovimo potrebne informacije v fsx.conf datoteko, kot je opisano v readme in vodenje deploy.sh scenarij v fsx mapo. To nastavi pravilno politiko in varnostno skupino za dostop do datotečnega sistema. Skript tudi namesti CSI voznik za FSx kot daemonset. Končno lahko v Kubernetesu ustvarimo zahtevek za trajni nosilec FSx z uporabo ene same datoteke .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

To ustvari datotečni sistem FSx v območju razpoložljivosti, določenem v fsx.conf datoteko in ustvari tudi trajni zahtevek za obseg fsx-pvc, ki ga lahko namesti kateri koli pod v gruči na način branja-pisanja-več (RWX).

V našem poskusu smo uporabili celotne podatke ImageNet, ki vsebujejo več kot 12 milijonov slik usposabljanja, razdeljenih v 1,000 razredov. Podatke lahko prenesete iz Spletno mesto ImageNet. Originalna žoga TAR ima več imenikov, vendar nas za naše modelsko usposabljanje zanima samo ILSVRC/Data/CLS-LOC/, ki vključuje train in val podimeniki. Pred treningom moramo slike preurediti v val podimenik, ki ustreza strukturi imenika, ki jo zahteva PyTorch ImageFolder razred. To je mogoče storiti z uporabo preprostega Python skript potem ko so podatki v naslednjem koraku prekopirani na trajni nosilec.

Za kopiranje podatkov iz Preprosta storitev shranjevanja Amazon (Amazon S3) v datotečni sistem FSx ustvarimo sliko Dockerja, ki vključuje skripte za to nalogo. Primer Dockerfile in lupinski skript sta vključena v CSI mapo v repo GitHub. Sliko lahko zgradimo z uporabo build.sh skript in ga nato potisnite v Amazon ECR z uporabo push.sh scenarij. Pred uporabo teh skriptov moramo zagotoviti pravilen URI za repozitorij ECR v .env datoteko v korenski mapi repoja GitHub. Ko potisnemo sliko Docker v Amazon ECR, lahko zaženemo pod za kopiranje podatkov z uporabo ustrezne datoteke .yaml:

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

Pod samodejno zažene skript data-prep.sh da kopirate podatke iz Amazon S3 na nosilec v skupni rabi. Ker imajo podatki ImageNet več kot 12 milijonov datotek, postopek kopiranja traja nekaj ur. Skript Python imagenet_data_prep.py se izvaja tudi za preureditev val nabor podatkov, kot pričakuje PyTorch.

Omrežni pospešek

V kombinaciji z podprte vrste primerkov EC2 za pospešitev omrežnega prometa med vozlišči GPE v vaši gruči. To je lahko uporabno pri izvajanju velikih porazdeljenih izobraževalnih opravil, kjer je lahko standardna omrežna komunikacija ozko grlo. Skripti za uvajanje in testiranje vtičnika naprave EFA v gruči EKS, ki ga uporabljamo tukaj, so vključeni v efa-device-plugin mapo v repo GitHub. Če želite omogočiti opravilo z EFA v vaši gruči EKS, mora biti poleg tega, da imajo vozlišča gruče potrebno strojno in programsko opremo, v gručo razporejen vtičnik naprave EFA, vaš vsebnik opravil pa mora imeti združljiva CUDA in NCCL različice nameščen.

Za predstavitev izvajanja testov NCCL in vrednotenja zmogljivosti EFA na primerkih p4d.24xlarge moramo najprej razmestiti operaterja Kubeflow MPI z izvajanjem ustreznega deploy.sh scenarij v mpi-operator mapo. Nato zaženemo deploy.sh skript in posodobite test-efa-nccl.yaml manifestira tako omejitve in zahteve po virih vpc.amazonaws.com so nastavljeni na 4. Štirje razpoložljivi adapterji EFA v vozliščih p4d.24xlarge so združeni v paket, da zagotovijo največjo prepustnost.

Run kubectl apply -f ./test-efa-nccl.yaml da uporabite test in nato prikažete dnevnike testne enote. Naslednja vrstica v izpisu dnevnika potrjuje, da se uporablja EFA:

NCCL INFO NET/OFI Selected Provider is efa

Rezultati testa bi morali biti podobni naslednjemu rezultatu:

[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

V rezultatih testa lahko opazimo, da je največja prepustnost približno 42 GB/s, povprečna pasovna širina vodila pa približno 8 GB.

Izvedli smo tudi poskuse z enim omogočenim adapterjem EFA in brez adapterjev EFA. Vsi rezultati so povzeti v naslednji tabeli.

Ugotovili smo tudi, da pri sorazmerno majhnih modelih, kot je ImageNet, uporaba pospešenega omrežnega povezovanja skrajša čas usposabljanja na epoho samo za 5–8 % pri velikosti serije 64. Pri večjih modelih in manjših velikostih serije, ko je potrebna večja omrežna komunikacija uteži , ima uporaba pospešenega mreženja večji učinek. Opazili smo zmanjšanje časa epoškega usposabljanja za 15–18 % za usposabljanje EfficientNet-B7 z velikostjo serije 1. Dejanski vpliv EFA na vaše usposabljanje bo odvisen od velikosti vašega modela.

Nadzor GPU

Pred izvedbo usposabljanja lahko tudi nastavimo amazoncloudwatch metrike za vizualizacijo izkoriščenosti GPE med usposabljanjem. Lahko je koristno vedeti, ali se viri uporabljajo optimalno, ali potencialno prepoznati pomanjkanje virov in ozka grla v procesu usposabljanja.

Ustrezni skripti za nastavitev CloudWatch se nahajajo v gpu-metrics mapo. Najprej ustvarimo Dockerjevo sliko z amazon-cloudwatch-agent in nvidia-smi. Dockerfile lahko uporabimo v gpu-metrics mapo za ustvarjanje te slike. Ob predpostavki, da je register ECR že nastavljen v .env datoteko iz prejšnjega koraka, lahko zgradimo in potisnemo sliko z uporabo build.sh in push.sh. Po tem zagonu deploy.sh skript samodejno dokonča nastavitev. Zažene demonset z amazon-cloudwatch-agent in potiska različne meritve v CloudWatch. Meritve GPU so prikazane pod CWAgent imenski prostor na konzoli CloudWatch. Ostale meritve grozda so prikazane pod ContainerInsights imenski prostor.

Usposabljanje za modele

Vsi skripti, potrebni za usposabljanje PyTorch, se nahajajo v elasticjob mapo v repo GitHub. Pred začetkom usposabljanja moramo zagnati etcd strežnik, ki ga TEC uporablja za odkrivanje delavcev in izmenjavo parametrov. The deploy.sh scenarij v elasticjob mapa naredi točno to.

Če želimo izkoristiti EFA v primerkih p4d.24xlarge, moramo uporabiti posebno sliko Dockerja, ki je na voljo v Javna galerija Amazon ECR ki podpira komunikacijo NCCL prek EFA. Samo našo kodo za usposabljanje moramo kopirati na to sliko Docker. The Dockerfile pod vzorce mapa ustvari sliko za uporabo pri izvajanju učnega opravila na primerkih p4d. Kot vedno lahko uporabimo build.sh in potisni.sh skripte v mapi za izdelavo in potiskanje slike.

O imagenet-efa.yaml datoteka opisuje delo usposabljanja. Ta datoteka .yaml nastavi vire, potrebne za izvajanje izobraževalnega opravila, in tudi pripne trajni nosilec s podatki o usposabljanju, nastavljenimi v prejšnjem razdelku.

Tukaj je vredno poudariti nekaj stvari. Število replik mora biti nastavljeno na število vozlišč, ki so na voljo v gruči. V našem primeru smo to nastavili na 3, ker smo imeli tri vozlišča p4d.24xlarge. V imagenet-efa.yaml datoteko, nvidia.com/gpu parameter pod viri in nproc_per_node pod args mora biti nastavljen na število grafičnih procesorjev na vozlišče, kar je v primeru p4d.24xlarge 8. Poleg tega argument worker za skript Python nastavi število procesorjev na proces. Izbrali smo to vrednost 4, ker v naših poskusih to zagotavlja optimalno zmogljivost pri izvajanju na primerkih p4d.24xlarge. Te nastavitve so potrebne za čim večjo uporabo vseh virov strojne opreme, ki so na voljo v gruči.

Ko se opravilo izvaja, lahko opazujemo uporabo GPE-ja v CloudWatchu za vse GPU-je v gruči. Sledi primer enega od naših izobraževalnih del s tremi vozlišči p4d.24xlarge v gruči. Tukaj smo iz vsakega vozlišča izbrali en GPE. Z nastavitvami, omenjenimi prej, je uporaba GPE blizu 100 % med fazo usposabljanja epohe za vsa vozlišča v gruči.

Za usposabljanje modela ResNet50 z uporabo primerkov p3.8xlarge potrebujemo popolnoma enake korake, kot so opisani za usposabljanje EfficientNet z uporabo p4d.24xlarge. Uporabimo lahko tudi isto sliko Dockerja. Kot smo že omenili, primerki p3.8xlarge niso opremljeni z EFA. Vendar za model ResNet50 to ni pomembna pomanjkljivost. The imagenet-fsx.yaml skript, ki je na voljo v repozitoriju GitHub, nastavi opravilo usposabljanja z ustreznimi viri za vrsto vozlišča p3.8xlarge. Opravilo uporablja isti nabor podatkov iz datotečnega sistema FSx.

GPU skaliranje

Izvedli smo nekaj poskusov, da bi opazovali, kako se čas usposabljanja spreminja za model EfficientNet-B7 s povečanjem števila grafičnih procesorjev. Da bi to naredili, smo spremenili število replik z 1 na 3 v naši datoteki .yaml za usposabljanje za vsako izvedbo usposabljanja. Med uporabo celotnega nabora podatkov ImageNet smo opazovali samo čas za eno obdobje. Naslednja slika prikazuje rezultate našega poskusa skaliranja GPU. Rdeča pikčasta črta predstavlja, kako naj bi se čas vadbe zmanjšal od teka z uporabo 8 GPE s povečanjem števila GPE. Kot lahko vidimo, je skaliranje precej blizu pričakovanemu.

Podobno smo pridobili graf skaliranja GPE za usposabljanje ResNet50 na primerkih p3.8xlarge. V tem primeru smo replike v naši datoteki .yaml spremenili iz 1 v 4. Rezultati tega poskusa so prikazani na naslednji sliki.

Čiščenje

Pomembno je, da po usposabljanju modela zavrtite vire, da se izognete stroškom, povezanim z izvajanjem nedejavnih primerkov. Z vsakim skriptom, ki ustvarja vire, se GitHub repo nudi ustrezen skript za njihovo brisanje. Za čiščenje naše nastavitve moramo izbrisati datotečni sistem FSx, preden izbrišemo gručo, ker je povezan s podomrežjem v VPC gruče. Če želite izbrisati datotečni sistem FSx, moramo samo zagnati naslednji ukaz (iz datoteke fsx mapa):

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

Upoštevajte, da s tem ne boste izbrisali le obstojnega nosilca, ampak boste izbrisali tudi datotečni sistem FSx in vsi podatki v datotečnem sistemu bodo izgubljeni. Ko je ta korak končan, lahko izbrišemo gručo z uporabo naslednjega skripta v npr mapa:

./eks-delete.sh

S tem boste izbrisali vse obstoječe sklope, odstranili gručo in izbrisali VPC, ustvarjen na začetku.

zaključek

V tej objavi smo podrobno opisali korake, potrebne za zagon usposabljanja porazdeljenih podatkovnih vzporednih modelov PyTorch na gručah EKS. Ta naloga se morda zdi zastrašujoča, vendar AWS DevOps za EKS projekt, ki ga je ustvarila ekipa ML Frameworks pri AWS, zagotavlja vse potrebne skripte in orodja za poenostavitev postopka in omogoča enostavno dostopnost usposabljanja porazdeljenega modela.

Za več informacij o tehnologijah, uporabljenih v tej objavi, obiščite Amazon EKS in Torch Distributed Elastic. Priporočamo vam, da tukaj opisani pristop uporabite za lastne primere uporabe porazdeljenega usposabljanja.

viri

O avtorjih

Imran Younus je glavni arhitekt rešitev za ekipo ML Frameworks pri AWS. Osredotoča se na obsežno strojno učenje in delovne obremenitve globokega učenja v storitvah AWS, kot sta Amazon EKS in AWS ParallelCluster. Ima bogate izkušnje z aplikacijami Deep Leaning v računalniškem vidu in industrijskem IoT. Imran je pridobil doktorat iz fizike delcev z visoko energijo, kjer je sodeloval pri analizi eksperimentalnih podatkov na petabajtnih lestvicah.

Alex Iankoulski je arhitekt programske opreme in infrastrukture s polnim skladom, ki rad opravlja poglobljeno in praktično delo. Trenutno je glavni arhitekt rešitev za samoupravljano strojno učenje pri AWS. V svoji vlogi se osredotoča na pomoč strankam pri kontejnerizaciji in orkestraciji delovnih obremenitev ML in AI v storitvah AWS, ki jih poganja vsebnik. Je tudi avtor odprte kode Naredi okvir in kapitan Dockerja, ki obožuje uporabo tehnologij vsebnikov za pospešitev hitrosti inovacij ob reševanju največjih izzivov na svetu. V zadnjih 10 letih se je Alex ukvarjal z bojem proti podnebnim spremembam, demokratiziral AI in ML, naredil potovanja varnejša, zdravstveno varstvo boljše in energijo pametnejšo.