Jaotatud koolitus Amazon EKS-i ja Torch Distributed Elasticuga

Jaotatud süvaõppemudeli koolitus muutub üha olulisemaks, kuna andmete maht paljudes tööstusharudes kasvab. Paljud arvutinägemise ja loomuliku keele töötlemise rakendused nõuavad nüüd süvaõppemudelite väljaõpet, mille keerukus kasvab hüppeliselt ja mida koolitatakse sageli sadade terabaitide andmetega. Seejärel muutub selliste suurte mudelite koolituse laiendamiseks oluliseks kasutada ulatuslikku pilveinfrastruktuuri.

Arendajad saavad intuitiivsete mudeliarhitektuuride hõlpsaks kujundamiseks kasutada avatud lähtekoodiga raamistikke, nagu PyTorch. Nende mudelite koolituse skaleerimine mitme sõlme vahel võib aga keerukama orkestreerimise tõttu olla keeruline.

Hajutatud mudelkoolitus koosneb peamiselt kahest paradigmast:

• Mudeli paralleel – Mudeli paralleeltreeningul on mudel ise nii suur, et ei mahu ühegi GPU mällu ning mudeli treenimiseks on vaja mitut GPU-d. Open AI mudel GPT-3 175 miljardi treenitava parameetriga (umbes 350 GB suurune) on selle hea näide.
• Andmed paralleelselt – Andmete paralleeltreeningul võib mudel asuda ühes GPU-s, kuid kuna andmed on nii suured, võib mudeli treenimiseks kuluda päevi või nädalaid. Andmete jaotamine mitme GPU sõlme vahel võib treeninguaega oluliselt vähendada.

Selles postituses pakume näite arhitektuuri PyTorchi mudelite koolitamiseks Jaotatud elastne taskulamp raamistik jaotatud andmete paralleelsel viisil Amazoni elastse Kubernetese teenus (Amazon EKS).

Eeldused

Selles postituses esitatud tulemuste kopeerimiseks on ainus eeltingimus AWS-i konto. Sellel kontol loome EKS-i klastri ja an Amazon FSx Lusteri jaoks failisüsteem. Samuti lükkame konteineri kujutised an Amazoni elastsete konteinerite register (Amazon ECR) hoidla kontol. Juhised nende komponentide seadistamiseks on vastavalt vajadusele kogu postituses.

EKS klastrid

Amazon EKS on hallatav konteinerteenus Kubernetese rakenduste käitamiseks ja skaleerimiseks AWS-is. Amazon EKS-iga saate tõhusalt juhtida hajutatud koolitustöid, kasutades uusimat Amazon Elastic Compute Cloud (Amazon EC2) eksemplarid, ilma et peaksite installima, kasutama ja hooldama oma juhtimistasandit või sõlme. See on populaarne orkestrant masinõppe (ML) ja AI töövoogude jaoks. Tüüpiline AWS-i EKS-klaster näeb välja nagu järgmine joonis.

Oleme välja andnud avatud lähtekoodiga projekti, AWS DevOps EKS-i jaoks (aws-do-eks), mis pakub suurt hulka lihtsalt kasutatavaid ja konfigureeritavaid skripte ja tööriistu EKS-i klastrite loomiseks ja hajutatud koolitustööde käitamiseks. See projekt on üles ehitatud põhimõtete järgi Tehke raamistik: lihtsus, paindlikkus ja universaalsus. Saate konfigureerida soovitud klastri, kasutades eks.conf fail ja seejärel käivitage see, käivitades eks-create.sh stsenaarium. Üksikasjalikud juhised on esitatud dokumendis GitHub repo.

Treenige PyTorchi mudeleid kasutades Torch Distributed Elastic

Torch Distributed Elastic (TDE) on PyTorchi põhiteek suuremahuliste süvaõppemudelite koolitamiseks, kus on ülioluline arvutusressursse dünaamiliselt vastavalt saadavusele skaleerida. The TorchElastic kontroller Kubernetese jaoks on Kubernetese natiivne TDE-rakendus, mis haldab automaatselt TDE koolituseks vajalike kaustade ja teenuste elutsüklit. See võimaldab vastavalt vajadusele treeningu ajal arvutusressursse dünaamiliselt skaleerida. Samuti pakub see tõrketaluvusega koolitust, taastades töökohti sõlme rikke tõttu.

Selles postituses käsitleme PyTorchi treenimise samme EfficientNet-B7 ja ResNet50 kasutavad mudelid IMAGEnet andmeid TDE-ga hajutatud viisil. Me kasutame PyTorchi DistributedDataParallel API ja Kubernetes TorchElastic kontroller ning käivitage meie koolitustööd mitut GPU-sõlme sisaldavas EKS-klastris. Järgmine diagramm näitab selle mudeli koolituse arhitektuuri diagrammi.

TorchElastic for Kubernetes koosneb peamiselt kahest komponendist: TorchElastic Kubernetesi kontrollerist (TEC) ja parameetriserverist (jne). Kontroller vastutab koolitustööde jälgimise ja haldamise eest ning parameetriserver jälgib töötaja sõlmede hajutatud sünkroonimist ja kaaslaste leidmist.

Selleks, et treeningmoodulid saaksid andmetele juurde pääseda, vajame jagatud andmemahtu, mille saab paigaldada igasse poodi. Mõned võimalused jagatud mahtude jaoks Konteinerite salvestusliides (CSI) draiverid on lisatud AWS DevOps EKS-i jaoks See on Amazon elastne failisüsteem (Amazon EFS) ja FSx Lusteri jaoks.

Klastri seadistamine

Oma klastri konfiguratsioonis kasutame süsteemipoodide jaoks ühte c5.2xlarge eksemplari. EfficientNeti mudeli väljaõpetamiseks kasutame kolme p4d.24xlarge eksemplari töötajatena. ResNet50 koolituse jaoks kasutame p3.8xlarge eksemplare töötajatena. Lisaks kasutame treeningandmete ja mudeliartefaktide salvestamiseks jagatud failisüsteemi FSx.

AWS p4d.24xlarge eksemplarid on varustatud Elastsest riidest adapter (EFA), et pakkuda sõlmede vahel võrku. Arutame EFA-st pikemalt hiljem postituses. EFA kaudu suhtlemise lubamiseks peame konfigureerima klastri seadistuse yaml-faili kaudu. An näidisfail on saadaval GitHubi hoidlas.

Kui see .yaml-fail on õigesti konfigureeritud, saame käivitada klastri, kasutades GitHubi repos pakutavat skripti:

./eks-create.sh

Vt GitHub repo üksikasjalike juhiste saamiseks.

P4d.24xlarge ja p3.8xlarge peal töötavate tööde vahel praktiliselt vahet pole. Selles postituses kirjeldatud sammud sobivad mõlema jaoks. Ainus erinevus on EFA kättesaadavus p4d.24xlarge eksemplaridel. Väiksemate mudelite (nt ResNet50) puhul mõjutab standardne võrgustik võrreldes EFA-võrguga treeningu kiirust minimaalselt.

FSx Lusteri failisüsteemi jaoks

FSx on loodud suure jõudlusega andmetöötluse töökoormuste jaoks ja pakub poolmillisekundilist latentsust kasutades pooljuhtdraivi salvestusruume. Valisime FSx-i, kuna see andis parema jõudluse, kuna skaleerisime suurele arvule sõlmedele. Oluline detail, mida tuleb märkida, on see, et FSx saab eksisteerida ainult ühes saadavuse tsoonis. Seetõttu peaksid kõik FSx-failisüsteemile juurde pääsevad sõlmed asuma FSx-failisüsteemiga samas saadavuse tsoonis. Üks viis selle saavutamiseks on määrata klastri .yaml-failis enne klastri loomist konkreetsete sõlmerühmade jaoks asjakohane saadavuse tsoon. Teise võimalusena saame pärast klastri seadistamist muuta nende sõlmede automaatse skaleerimise rühma võrguosa ja piirata selle ühe alamvõrgu kasutamisega. Seda saab hõlpsasti teha Amazon EC2 konsoolil.

Eeldades, et EKS-klaster on valmis ja töötab ning saadavuse tsooni alamvõrgu ID on teada, saame seadistada FSx-failisüsteemi, esitades vajaliku teabe fsx.conf faili, nagu on kirjeldatud jaotises readme ja jookseb juurutada.sh skripti fsx kausta. See seadistab failisüsteemile juurdepääsuks õige poliitika ja turberühma. Skript installib ka CSI draiver FSx-i jaoks deemonikomplektina. Lõpuks saame Kubernetesis luua FSx püsiva mahunõude, rakendades ühte yaml-faili:

kubectl apply -f fsx-pvc-dynamic.yaml

See loob FSx-failisüsteemi käsutuses määratud saadavuse tsoonis fsx.conf faili ja loob ka püsiva mahunõude fsx-pvc, mida saab monteerida klastri mis tahes kausta külge lugemise-kirjutamise-palju (RWX) viisil.

Oma katses kasutasime täielikke ImageNeti andmeid, mis sisaldavad enam kui 12 miljonit treeningpilti, mis on jagatud 1,000 klassi. Andmeid saab alla laadida aadressilt ImageNeti veebisait. Algsel TAR-pallil on mitu kataloogi, kuid meie mudelikoolituse jaoks oleme huvitatud ainult sellest ILSVRC/Data/CLS-LOC/, mis sisaldab train ja val alamkataloogid. Enne treenimist peame pildid ümber korraldama val alamkataloog, et see vastaks PyTorchi nõutavale kataloogistruktuurile Pildikaust klass. Seda saab teha kasutades lihtsat Pythoni skript pärast andmete kopeerimist püsivasse köitesse järgmises etapis.

Andmete kopeerimiseks rakendusest Amazoni lihtne salvestusteenus (Amazon S3) ämbrisse FSx-failisüsteemi loome Dockeri pildi, mis sisaldab selle ülesande jaoks skripte. Dockerfile'i näide ja shelliskript on lisatud csi kaust GitHubi repos. Saame luua pildi kasutades build.sh skript ja seejärel suruge see Amazon ECR-i kasutades push.sh stsenaarium. Enne nende skriptide kasutamist peame esitama ECR-i hoidla jaoks õige URI .env faili GitHubi repo juurkaustas. Kui oleme Dockeri kujutise Amazon ECR-i edastanud, saame käivitada andmete kopeerimiseks sobiva .yaml-faili rakendamisega podi:

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

Pod käivitab skripti automaatselt data-prep.sh andmete kopeerimiseks Amazon S3-st jagatud köitele. Kuna ImageNeti andmetel on rohkem kui 12 miljonit faili, kulub kopeerimisprotsess paar tundi. Pythoni skript imagenet_data_prep.py käivitatakse ka ümberkorraldamiseks val andmestik, nagu PyTorch eeldas.

Võrgu kiirendus

Saame kasutada elastset kangast adapterit (EFA) koos toetatud EC2 eksemplari tüübid võrguliikluse kiirendamiseks klastri GPU sõlmede vahel. See võib olla kasulik suurte hajutatud koolitustööde tegemisel, kus tavaline võrguside võib olla kitsaskohaks. Siin kasutatavad EKS-klastri EFA-seadme pistikprogrammi juurutamiseks ja testimiseks kasutatavad skriptid on lisatud efa-seadme-plugin kaust GitHubi repos. EFA-ga töö lubamiseks oma EKS-klastris peab lisaks vajaliku riist- ja tarkvaraga klastri sõlmedele olema klastrisse juurutatud EFA-seadme pistikprogramm ning teie töökonteiner peab olema ühilduv CUDA ja NCCL-iga. versioonid paigaldatud.

NCCL-i testide käitamise demonstreerimiseks ja EFA toimivuse hindamiseks p4d.24xlarge eksemplaridel peame esmalt juurutama Kubeflow MPI operaatori, käivitades vastava juurutada.sh skripti mpi-operaator kausta. Siis juhime juurutada.sh skript ja värskendage test-efa-nccl.yaml manifest nii piiranguid ja ressursitaotlusi vpc.amazonaws.com on seatud väärtusele 4. Neli saadaolevat EFA-adapterit p4d.24xlarge-sõlmedes koondatakse kokku, et tagada maksimaalne läbilaskevõime.

jooks kubectl apply -f ./test-efa-nccl.yaml testi rakendamiseks ja seejärel testpuldi logide kuvamiseks. Järgmine rida logiväljundis kinnitab EFA kasutamist:

NCCL INFO NET/OFI Selected Provider is efa

Testi tulemused peaksid välja nägema sarnased järgmise väljundiga:

[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

Testitulemustes on näha, et maksimaalne läbilaskevõime on umbes 42 GB/sek ja siini keskmine ribalaius on umbes 8 GB.

Tegime katseid ka ühe lubatud EFA-adapteriga ja ilma EFA-adapteriteta. Kõik tulemused on kokku võetud järgmises tabelis.

Samuti leidsime, et suhteliselt väikeste mudelite (nt ImageNet) puhul vähendab kiirendatud võrguühenduse kasutamine treeninguaega ainult 5–8%, kui partii suurus on 64. Suuremate mudelite ja väiksemate partiide puhul, kui on vaja suuremat võrgusuhtlust. , on kiirendatud võrgu kasutamisel suurem mõju. Täheldasime 15. partii suurusega EfficientNet-B18 treenimise ajastu treeningaja vähenemist 7–1%. EFA tegelik mõju teie treeningule sõltub teie mudeli suurusest.

GPU jälgimine

Enne koolitustöö läbiviimist saame ka seadistada Amazon CloudWatch mõõdikud GPU kasutamise visualiseerimiseks treeningu ajal. Abiks võib olla teadmine, kas ressursse kasutatakse optimaalselt või tuvastada ressursside näljahäda ja koolitusprotsessi kitsaskohad.

Asjakohased skriptid CloudWatchi seadistamiseks asuvad aadressil gpu-meetrika kausta. Esiteks loome Dockeri pildi amazon-cloudwatch-agent ja nvidia-smi. Saame kasutada Dockerfile'i gpu-metrics kausta selle pildi loomiseks. Eeldusel, et ECR-register on failis juba määratud .env faili eelmisest etapist, saame pildi luua ja lükata build.sh ja push.sh. Pärast seda käivitatakse deploy.sh skript viib seadistamise automaatselt lõpule. See käivitab deemonseti koos amazon-cloudwatch-agent ja edastab erinevaid mõõdikuid CloudWatchi. GPU mõõdikud kuvatakse all CWAgent nimeruum CloudWatchi konsoolil. Ülejäänud klastri mõõdikud kuvatakse all ContainerInsights nimeruumi.

Modellikoolitus

Kõik PyTorchi koolituseks vajalikud skriptid asuvad aadressil elastne töö kaust GitHubi repos. Enne koolitustöö käivitamist peame käivitama etcd server, mida TEC kasutab töötajate leidmiseks ja parameetrite vahetamiseks. The juurutada.sh skripti elasticjob kaust teeb täpselt seda.

EFA eeliste kasutamiseks p4d.24xlarge eksemplarides peame kasutama konkreetset Dockeri kujutist, mis on saadaval Amazon ECR avalik galerii mis toetab NCCL-i suhtlust EFA kaudu. Peame lihtsalt oma koolituskoodi sellele Dockeri pildile kopeerima. The dockerfile Vastavalt proovid kaust loob pildi, mida kasutatakse p4d eksemplaridel treeningtöö käitamisel. Nagu alati, saame kasutada ehitada.sh ja push.sh skriptid kaustas pildi koostamiseks ja lükkamiseks.

. imagenet-efa.yaml fail kirjeldab koolitustööd. See yaml-fail seadistab koolitustöö käitamiseks vajalikud ressursid ja ühendab ka püsiva helitugevuse eelmises jaotises seadistatud koolitusandmetega.

Siin tasub välja tuua paar asja. Koopiate arvuks tuleks määrata klastris saadaolevate sõlmede arv. Meie puhul määrasime selle väärtuseks 3, kuna meil oli kolm p4d.24xlarge sõlme. Aastal imagenet-efa.yaml fail, nvidia.com/gpu parameeter ressursside all ja nproc_per_node all args tuleks määrata GPU-de arvule sõlme kohta, mis p4d.24xlarge puhul on 8. Samuti määrab Pythoni skripti töötaja argument protsessorite arvu protsessi kohta. Valisime selle väärtuseks 4, kuna meie katsetes tagab see p4d.24xlarge eksemplaridel töötamisel optimaalse jõudluse. Need sätted on vajalikud kõigi klastris saadaolevate riistvararessursside maksimaalseks kasutamiseks.

Kui töö töötab, saame CloudWatchis jälgida kõigi klastri GPU-de GPU kasutamist. Järgnev on näide ühest meie koolitustööst, kus klastris on kolm p4d.24xlarge sõlme. Siin oleme valinud igast sõlmest ühe GPU. Varem mainitud sätetega on GPU kasutus epohhi treeningfaasis 100% lähedal kõigi klastri sõlmede jaoks.

ResNet50 mudeli koolitamiseks p3.8xlarge eksemplaride abil vajame täpselt samu samme, mida on kirjeldatud p4d.24xlarge kasutava EfficientNeti koolituse puhul. Saame kasutada ka sama Dockeri pilti. Nagu varem mainitud, pole p3.8xlarge eksemplarid EFA-ga varustatud. ResNet50 mudeli puhul pole see aga märkimisväärne puudus. The imagenet-fsx.yaml GitHubi hoidlas pakutav skript seadistab koolitustöö sobivate ressurssidega p3.8xlarge sõlmetüübi jaoks. Töö kasutab sama andmestikku FSx-failisüsteemist.

GPU skaleerimine

Tegime mõned katsed, et jälgida, kuidas EfficientNet-B7 mudeli treeningu ajaskaala graafikaprotsessorite arvu suurendamise kaudu muutub. Selleks muutsime treeningu .yaml failis iga treeningjooksu jaoks koopiate arvu 1-lt 3-le. Täieliku ImageNeti andmestiku kasutamisel jälgisime aega ainult ühe epohhi jaoks. Järgmine joonis näitab meie GPU skaleerimise katse tulemusi. Punane punktiirjoon näitab, kuidas treeninguaeg peaks vähenema 8 GPU-ga töötamise ajal, suurendades GPU-de arvu. Nagu näeme, on skaleerimine oodatule üsna lähedane.

Samamoodi saime GPU skaleerimise graafiku ResNet50 koolituse jaoks p3.8xsuurtel eksemplaridel. Sel juhul muutsime oma .yaml-failis olevaid koopiaid 1-lt 4-le. Selle katse tulemused on näidatud järgmisel joonisel.

Koristage

Pärast mudelikoolitust on oluline ressursse vähendada, et vältida jõudeoleku eksemplaride käitamisega seotud kulusid. Iga skripti, mis loob ressursse, GitHub repo pakub nende kustutamiseks sobiva skripti. Seadistuse puhastamiseks peame enne klastri kustutamist kustutama FSx-failisüsteemi, kuna see on seotud klastri VPC-s oleva alamvõrguga. FSx-failisüsteemi kustutamiseks peame lihtsalt käivitama järgmise käsu (seest fsx kaust):

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

Pange tähele, et see mitte ainult ei kustuta püsivat köidet, vaid kustutab ka FSx-failisüsteemi ja kõik failisüsteemis olevad andmed lähevad kaotsi. Kui see samm on lõpule viidud, saame klastri kustutada, kasutades failis järgmist skripti nt kausta:

./eks-delete.sh

See kustutab kõik olemasolevad kaustad, eemaldab klastri ja kustutab alguses loodud VPC.

Järeldus

Selles postituses kirjeldasime üksikasjalikult PyTorchi hajutatud andmete paralleelmudeli koolituse käitamiseks vajalikke samme EKS-klastrites. See ülesanne võib tunduda hirmutav, kuid AWS DevOps EKS-i jaoks AWS-i ML Frameworksi meeskonna loodud projekt pakub kõiki vajalikke skripte ja tööriistu protsessi lihtsustamiseks ja hajutatud mudelikoolituse hõlpsasti juurdepääsetavaks muutmiseks.

Lisateavet selles postituses kasutatud tehnoloogiate kohta leiate aadressilt Amazon EKS ja Jaotatud elastne taskulamp. Soovitame teil rakendada siin kirjeldatud lähenemisviisi oma hajutatud koolituste kasutusjuhtudel.

Vahendid

Autoritest

Imran Younus on AWS-i ML Frameworksi meeskonna peamine lahenduste arhitekt. Ta keskendub suuremahulisele masinõppele ja sügavale õppetöökoormustele AWS-i teenustes, nagu Amazon EKS ja AWS ParallelCluster. Tal on laialdased kogemused Deep Leaningi rakendustes arvutinägemises ja tööstuslike asjade internetis. Imran omandas doktorikraadi kõrgenergia osakeste füüsikas, kus ta on osalenud eksperimentaalsete andmete analüüsimisel petabaidi skaalal.

Alex Iankoulski on täielik tarkvara- ja infrastruktuuriarhitekt, kellele meeldib teha põhjalikku ja praktilist tööd. Praegu on ta AWS-i isehallatava masinõppe pealahenduste arhitekt. Oma rollis keskendub ta klientide abistamisele konteineritel töötavate AWS-teenuste ML ja AI töökoormuse konteineriseerimisel ja orkestreerimisel. Ta on ka avatud lähtekoodi autor Tehke raamistik ja Dockeri kapten, kes armastab konteinertehnoloogiate rakendamist, et kiirendada innovatsioonitempot, lahendades samal ajal maailma suurimaid väljakutseid. Viimase 10 aasta jooksul on Alex töötanud kliimamuutuste vastu võitlemise, tehisintellekti ja ML demokratiseerimise, reisimise turvalisemaks, tervishoiu paremaks ja energiatarvikuks muutmise nimel.