Hajautettu koulutus Amazon EKS:n ja Torch Distributed Elasticin kanssa

Hajautettu syväoppimismallikoulutus on tulossa yhä tärkeämmäksi tietokokojen kasvaessa monilla toimialoilla. Monet tietokonenäön ja luonnollisen kielen käsittelyn sovellukset vaativat nyt syväoppimismallien koulutusta, joiden monimutkaisuus kasvaa eksponentiaalisesti ja joita koulutetaan usein satojen teratavujen datalla. Sitten on tärkeää käyttää laajaa pilviinfrastruktuuria tällaisten suurten mallien koulutuksen skaalaamiseen.

Kehittäjät voivat käyttää avoimen lähdekoodin kehyksiä, kuten PyTorchia, intuitiivisten malliarkkitehtuurien suunnitteluun. Näiden mallien koulutuksen skaalaaminen useiden solmujen välillä voi kuitenkin olla haastavaa, koska orkestrointi on monimutkaista.

Hajautettu mallikoulutus koostuu pääasiassa kahdesta paradigmasta:

• Malli yhdensuuntainen – Mallin rinnakkaiskoulutuksessa malli itsessään on niin suuri, että se ei mahdu yhden GPU:n muistiin ja mallin kouluttamiseen tarvitaan useita GPU:ita. Open AI:n GPT-3-malli 175 miljardilla koulutettavalla parametrilla (kooltaan noin 350 Gt) on tästä hyvä esimerkki.
• Data rinnakkain – Datan rinnakkaiskoulutuksessa malli voi sijaita yhdessä GPU:ssa, mutta koska data on niin suurta, mallin kouluttaminen voi kestää päiviä tai viikkoja. Tietojen jakaminen useiden GPU-solmujen kesken voi lyhentää harjoitusaikaa merkittävästi.

Tässä viestissä tarjoamme esimerkin arkkitehtuurista PyTorch-mallien kouluttamiseen käyttämällä Taskulamppu jaettu elastinen kehyksessä hajautetun datan rinnakkain käyttämällä Amazonin elastisten kuberneettien palvelu (Amazon EKS).

Edellytykset

Tässä viestissä raportoitujen tulosten toistamiseksi ainoa edellytys on AWS-tili. Tällä tilillä luomme EKS-klusterin ja Amazon FSx Lusterille tiedostojärjestelmä. Välitämme myös konttikuvat an Amazonin elastisten säiliörekisteri (Amazon ECR) arkisto tilillä. Ohjeet näiden komponenttien asettamiseen annetaan tarvittaessa koko postauksen aikana.

EKS-klusterit

Amazon EKS on hallittu konttipalvelu Kubernetes-sovellusten ajamiseen ja skaalaamiseen AWS:ssä. Amazon EKS:n avulla voit suorittaa hajautettuja koulutustöitä tehokkaasti käyttämällä viimeisintä Amazonin elastinen laskentapilvi (Amazon EC2) -esiintymiä ilman, että sinun tarvitsee asentaa, käyttää ja huoltaa omaa ohjaustasoa tai solmuja. Se on suosittu Orchestrator koneoppimiseen (ML) ja tekoälyn työnkulkuihin. Tyypillinen EKS-klusteri AWS:ssä näyttää seuraavalta kuvalta.

Olemme julkaisseet avoimen lähdekoodin projektin, AWS DevOps EKS:lle (aws-do-eks), joka tarjoaa laajan kokoelman helppokäyttöisiä ja konfiguroitavia komentosarjoja ja työkaluja EKS-klustereiden luomiseen ja hajautettujen koulutustöiden suorittamiseen. Tämä projekti on rakennettu noudattaen periaatteita Tee Framework: Yksinkertaisuus, joustavuus ja yleismaailmallisuus. Voit määrittää haluamasi klusterin käyttämällä eks.conf tiedosto ja käynnistä se sitten suorittamalla eks-create.sh käsikirjoitus. Yksityiskohtaiset ohjeet löytyvät GitHub repo.

Harjoittele PyTorch-malleja käyttämällä Torch Distributed Elasticia

Torch Distributed Elastic (TDE) on natiivi PyTorch-kirjasto, jolla opetetaan laajamittaisia ​​syväoppimismalleja, joissa on tärkeää skaalata laskentaresurssit dynaamisesti saatavuuden mukaan. The TorchElastic-ohjain Kubernetesille on natiivi Kubernetes-toteutus TDE:lle, joka hallitsee automaattisesti TDE-koulutukseen tarvittavien podien ja palveluiden elinkaarta. Se mahdollistaa laskentaresurssien dynaamisen skaalauksen harjoittelun aikana tarpeen mukaan. Se tarjoaa myös vikasietoista koulutusta palauttamalla työt solmuvioista.

Tässä viestissä keskustelemme PyTorchin kouluttamisesta EfficientNet-B7 ja ResNet50 käyttäviä malleja IMAGEnet tietoja hajautetusti TDE:n avulla. Käytämme PyTorchia DistributedDataParallel API ja Kubernetes TorchElastic -ohjain ja suorita koulutustyömme EKS-klusterissa, joka sisältää useita GPU-solmuja. Seuraava kaavio esittää tämän mallikoulutuksen arkkitehtuurikaavion.

TorchElastic for Kubernetes koostuu pääasiassa kahdesta osasta: TorchElastic Kubernetes -ohjaimesta (TEC) ja parametripalvelimesta (etcd). Ohjain on vastuussa koulutustöiden seurannasta ja hallinnasta, ja parametripalvelin pitää kirjaa työntekijäsolmuista hajautettua synkronointia ja vertaishakua varten.

Jotta harjoituspodit voivat käyttää tietoja, tarvitsemme jaetun tietomäärän, joka voidaan asentaa jokaiseen podiin. Joitakin vaihtoehtoja jaetuille levyille Säiliön tallennusliitäntä (CSI) ajurit sisältyvät AWS DevOps EKS:lle olemme Amazonin elastinen tiedostojärjestelmä (Amazon EFS) ja FSx Lusterille.

Klusterin asetukset

Klusterikokoonpanossamme käytämme yhtä c5.2xlarge-instanssia järjestelmäkoteloille. Käytämme kolmea p4d.24xlarge-instanssia työntekijäpodeina EfficientNet-mallin kouluttamiseen. ResNet50-koulutuksessa käytämme p3.8xlarge-esiintymiä worker podeina. Lisäksi käytämme jaettua FSx-tiedostojärjestelmää harjoitustietojemme ja malliesineiden tallentamiseen.

AWS p4d.24xlarge -esiintymät on varustettu Joustava kangasadapteri (EFA) tarjoamaan verkottumista solmujen välille. Keskustelemme EFA:sta lisää myöhemmin postauksessa. Jotta kommunikointi EFA:n kautta voidaan ottaa käyttöön, meidän on määritettävä klusterin asetukset .yaml-tiedoston kautta. An esimerkkitiedosto tarjotaan GitHub-arkistossa.

Kun tämä .yaml-tiedosto on määritetty oikein, voimme käynnistää klusterin käyttämällä GitHub-varastossa olevaa komentosarjaa:

./eks-create.sh

Viittaavat GitHub repo yksityiskohtaisia ​​ohjeita.

Ei käytännössä ole eroa käynnissä olevien töiden välillä p4d.24xlarge ja p3.8xlarge. Tässä viestissä kuvatut vaiheet toimivat molemmille. Ainoa ero on EFA:n saatavuus p4d.24xlarge-esiintymissä. Pienemmissä malleissa, kuten ResNet50, tavallisella verkkoyhteydellä EFA-verkkoon verrattuna on minimaalinen vaikutus harjoituksen nopeuteen.

FSx Luster-tiedostojärjestelmälle

FSx on suunniteltu korkean suorituskyvyn laskennan työkuormille ja tarjoaa alle millisekunnin viiveen käyttämällä SSD-tallennustilaa. Valitsimme FSx:n, koska se tarjosi paremman suorituskyvyn, kun skaalauduimme suureen määrään solmuja. Tärkeä huomioitava yksityiskohta on, että FSx voi olla olemassa vain yhdellä Saatavuusvyöhykkeellä. Siksi kaikkien FSx-tiedostojärjestelmää käyttävien solmujen tulisi olla samassa Saatavuusvyöhykkeellä kuin FSx-tiedostojärjestelmä. Yksi tapa saavuttaa tämä on määrittää asianmukainen Saatavuusvyöhyke klusterin .yaml-tiedostossa tietyille solmuryhmille ennen klusterin luomista. Vaihtoehtoisesti voimme muokata näiden solmujen automaattisen skaalausryhmän verkko-osaa klusterin perustamisen jälkeen ja rajoittaa sen käyttämään yhtä aliverkkoa. Tämä voidaan tehdä helposti Amazon EC2 -konsolilla.

Olettaen, että EKS-klusteri on toiminnassa ja saatavuusvyöhykkeen aliverkon tunnus on tiedossa, voimme määrittää FSx-tiedostojärjestelmän antamalla tarvittavat tiedot fsx.conf tiedosto kuten readme ja ajaa deploy.sh käsikirjoitus FSX kansio. Tämä määrittää oikean käytännön ja suojausryhmän tiedostojärjestelmän käyttöä varten. Skripti asentaa myös CSI kuljettaja FSx:lle demonsetiksi. Lopuksi voimme luoda pysyvän FSx-taltion vaatimuksen Kubernetesissa käyttämällä yhtä .yaml-tiedostoa:

kubectl apply -f fsx-pvc-dynamic.yaml

Tämä luo FSx-tiedostojärjestelmän käytettävyyden vyöhykkeelle, joka on määritetty kohdassa fsx.conf tiedostoa ja luo myös jatkuvan volyymivaatimuksen fsx-pvc, joka voidaan asentaa mihin tahansa klusterin podista luku-kirjoitus-monen (RWX) -tavalla.

Kokeessamme käytimme täydellisiä ImageNet-tietoja, jotka sisältävät yli 12 miljoonaa harjoituskuvaa jaettuna 1,000 luokkaan. Tiedot voi ladata osoitteesta ImageNetin verkkosivusto. Alkuperäisessä TAR-pallossa on useita hakemistoja, mutta mallikoulutuksemme vuoksi olemme vain kiinnostuneita ILSVRC/Data/CLS-LOC/, joka sisältää train ja val alihakemistoja. Ennen harjoittelua meidän on järjestettävä kuvat uudelleen val alihakemisto vastaamaan PyTorchin vaatimaa hakemistorakennetta ImageFolder luokkaa. Tämä voidaan tehdä käyttämällä yksinkertaista Python-skripti sen jälkeen, kun tiedot on kopioitu pysyvään taltioon seuraavassa vaiheessa.

Voit kopioida tiedot kohteesta Amazonin yksinkertainen tallennuspalvelu (Amazon S3) ämpäri FSx-tiedostojärjestelmään, luomme Docker-kuvan, joka sisältää komentosarjat tätä tehtävää varten. Esimerkki Docker-tiedostosta ja komentotulkkikomentosarja ovat mukana csi kansio GitHub-repon sisällä. Voimme rakentaa kuvan käyttämällä build.sh komentosarja ja työnnä se sitten Amazon ECR:ään käyttämällä push.sh käsikirjoitus. Ennen kuin käytät näitä komentosarjoja, meidän on annettava oikea URI ECR-tietovarastoon tiedostossa .env tiedosto GitHub-repon juurikansiossa. Kun olemme siirtäneet Docker-kuvan Amazon ECR:ään, voimme käynnistää podin tietojen kopioimiseksi käyttämällä asianmukaista .yaml-tiedostoa:

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

Pod suorittaa skriptin automaattisesti data-prep.sh kopioidaksesi tiedot Amazon S3:sta jaetulle taltiolle. Koska ImageNet-tiedoissa on yli 12 miljoonaa tiedostoa, kopiointiprosessi kestää muutaman tunnin. Python-skripti imagenet_data_prep.py ajetaan myös järjestää uudelleen val tietojoukko PyTorchin odotetulla tavalla.

Verkon kiihdytys

Voimme käyttää Elastic Fabric Adapteria (EFA) yhdessä tuetut EC2-instanssityypit nopeuttaaksesi verkkoliikennettä klusterin GPU-solmujen välillä. Tämä voi olla hyödyllistä suoritettaessa suuria hajautettuja koulutustöitä, joissa tavallinen verkkoviestintä voi olla pullonkaula. Skriptit EFA-laitelaajennuksen käyttöönottamiseksi ja testaamiseksi tässä käyttämässämme EKS-klusterissa sisältyvät efa-device-plugin kansio GitHub-varastossa. EFA-työn mahdollistamiseksi EKS-klusterissasi sen lisäksi, että klusterin solmuilla on tarvittavat laitteistot ja ohjelmistot, klusteriin on otettava käyttöön EFA-laitelaajennus ja työsäilön tulee olla yhteensopivat CUDA- ja NCCL-tiedostot. versiot asennettu.

Havainnollistaaksemme NCCL-testien suorittamista ja EFA:n suorituskyvyn arvioimista p4d.24xlarge-esiintymissä meidän on ensin otettava käyttöön Kubeflow MPI -operaattori suorittamalla vastaava deploy.sh käsikirjoitus mpi-operaattori kansio. Sitten ajamme deploy.sh skripti ja päivitä test-efa-nccl.yaml ilmentää niin rajoituksia ja resurssipyyntöjä vpc.amazonaws.com on asetettu arvoon 4. Neljä saatavilla olevaa EFA-sovitinta p4d.24xlarge-solmuissa niputetaan yhteen maksimaalisen suorituskyvyn saavuttamiseksi.

ajaa kubectl apply -f ./test-efa-nccl.yaml suorittaaksesi testin ja näyttää sitten testikotelon lokit. Lokitulosteen seuraava rivi vahvistaa, että EFA on käytössä:

NCCL INFO NET/OFI Selected Provider is efa

Testitulosten pitäisi näyttää samanlaisilta kuin seuraava tulos:

[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

Testituloksissa voidaan havaita, että suurin suoritusnopeus on noin 42 Gt/s ja keskimääräinen väylän kaistanleveys on noin 8 Gt.

Teimme myös kokeita yhdellä EFA-sovittimella ja ilman EFA-sovittimia. Kaikki tulokset on koottu seuraavassa taulukossa.

Havaitsimme myös, että suhteellisen pienissä malleissa, kuten ImageNet, nopeutetun verkkoyhteyden käyttö lyhentää harjoitusaikaa jaksoa kohti vain 5–8 %, kun eräkoko on 64. Suuremmille malleille ja pienemmille eräkokoille, kun tarvitaan lisää painojen tiedonsiirtoa verkossa. , nopeutetun verkottumisen käytöllä on suurempi vaikutus. Havaitsimme aikakauden harjoitusajan lyhenemisen 15–18 % EfficientNet-B7:n harjoitteluun eräkoon 1 kanssa. EFA:n todellinen vaikutus harjoitteluun riippuu mallisi koosta.

GPU-valvonta

Ennen koulutustyön suorittamista voimme myös perustaa amazonin pilvikello mittareita grafiikkasuorittimen käytön visualisoimiseksi harjoituksen aikana. Voi olla hyödyllistä tietää, käytetäänkö resursseja optimaalisesti, tai mahdollisesti tunnistaa resurssien nälkä ja pullonkaulat koulutusprosessissa.

Asiaankuuluvat skriptit CloudWatchin määrittämiseksi sijaitsevat osoitteessa gpu-metriikka kansio. Ensin luomme Docker-kuvan amazon-cloudwatch-agent ja nvidia-smi. Voimme käyttää Docker-tiedostoa gpu-metrics kansio luodaksesi tämän kuvan. Olettaen, että ECR-rekisteri on jo asetettu .env tiedosto edellisestä vaiheesta, voimme rakentaa ja työntää kuvan käyttämällä build.sh ja push.sh. Tämän jälkeen käynnissä deploy.sh skripti suorittaa asennuksen automaattisesti loppuun. Se käynnistää demonsetin kanssa amazon-cloudwatch-agent ja siirtää erilaisia ​​mittareita CloudWatchiin. GPU-tiedot näkyvät alla CWAgent nimiavaruus CloudWatch-konsolissa. Muut klusterin tiedot näkyvät alla ContainerInsights nimitila.

Malliharjoittelu

Kaikki PyTorch-koulutukseen tarvittavat skriptit sijaitsevat osoitteessa elastinen työ kansio GitHub-varastossa. Ennen kuin aloitamme koulutustyön, meidän on suoritettava etcd palvelin, jota TEC käyttää työntekijöiden etsintään ja parametrien vaihtoon. The deploy.sh käsikirjoitus elasticjob kansio tekee juuri niin.

Jotta voimme hyödyntää EFA:ta p4d.24xlarge-esiintymissä, meidän on käytettävä tiettyä Docker-kuvaa, joka on saatavilla Amazon ECR Public Gallery joka tukee NCCL-viestintää EFA:n kautta. Meidän täytyy vain kopioida koulutuskoodimme tähän Docker-kuvaan. The Dockerfile alla näytteet kansio luo kuvan, jota käytetään suoritettaessa harjoitustyötä p4d-esiintymissä. Kuten aina, voimme käyttää build.sh ja push.sh skriptejä kansiossa kuvan rakentamiseksi ja työntämiseksi.

- imagenet-efa.yaml tiedosto kuvaa koulutustyötä. Tämä .yaml-tiedosto määrittää koulutustyön suorittamiseen tarvittavat resurssit ja liittää myös jatkuvan volyymin edellisessä osiossa määritetyillä harjoitustiedoilla.

Tässä kannattaa mainita pari asiaa. Replikoiden määrä tulee asettaa klusterissa käytettävissä olevien solmujen lukumäärään. Meidän tapauksessamme asetimme tämän arvoon 3, koska meillä oli kolme p4d.24xlarge-solmua. Vuonna imagenet-efa.yaml tiedosto, nvidia.com/gpu resurssit ja nproc_per_node varten args tulee asettaa GPU:iden lukumäärään solmua kohti, mikä p4d.24xlarge:n tapauksessa on 8. Python-komentosarjan työntekijä-argumentti määrittää myös suorittimien määrän prosessia kohti. Valitsimme tämän arvoksi 4, koska kokeiluissamme tämä tarjoaa optimaalisen suorituskyvyn käytettäessä p4d.24xlarge-esiintymiä. Nämä asetukset ovat välttämättömiä, jotta voidaan maksimoida kaikkien klusterin käytettävissä olevien laitteistoresurssien käyttö.

Kun työ on käynnissä, voimme tarkkailla GPU:n käyttöä CloudWatchissa kaikille klusterin GPU:ille. Seuraavassa on esimerkki yhdestä koulutustyöstämme, jossa on kolme p4d.24xlarge-solmua klusterissa. Tässä olemme valinneet yhden GPU:n kustakin solmusta. Aiemmin mainituilla asetuksilla GPU:n käyttö on lähes 100 % aikakauden harjoitusvaiheessa kaikille klusterin solmuille.

ResNet50-mallin kouluttamiseen p3.8xlarge-instanssien avulla tarvitsemme täsmälleen samat vaiheet kuin on kuvattu EfficientNet-koulutuksessa käyttämällä p4d.24xlargea. Voimme myös käyttää samaa Docker-kuvaa. Kuten aiemmin mainittiin, p3.8xlarge-esiintymissä ei ole EFA:ta. ResNet50-mallille tämä ei kuitenkaan ole merkittävä haittapuoli. The imagenet-fsx.yaml GitHub-arkistossa oleva komentosarja määrittää koulutustyön sopivilla resursseilla p3.8xlarge-solmutyypille. Työ käyttää samaa tietojoukkoa FSx-tiedostojärjestelmästä.

GPU-skaalaus

Suoritimme joitain kokeita tarkkaillaksemme kuinka EfficientNet-B7-mallin harjoitusaika skaalautuu lisäämällä grafiikkasuorittimien määrää. Tätä varten muutimme replikoiden lukumäärän yhdestä kolmeen harjoitus-.yaml-tiedostossamme jokaisessa harjoitusajossa. Tarkastimme aikaa vain yhden aikakauden aikana, kun käytimme koko ImageNet-tietojoukkoa. Seuraava kuva näyttää GPU-skaalauskokeilumme tulokset. Punainen katkoviiva ilmaisee, kuinka harjoitusajan tulisi lyhentyä 1 GPU:n käytön jälkeen lisäämällä GPU:iden määrää. Kuten näemme, skaalaus on melko lähellä odotettua.

Samoin saimme GPU-skaalauskaavion ResNet50-koulutukselle p3.8xlarge-esiintymissä. Tässä tapauksessa muutimme .yaml-tiedostomme replikoita arvosta 1 arvoon 4. Tämän kokeilun tulokset näkyvät seuraavassa kuvassa.

Puhdistaa

On tärkeää vähentää resursseja mallikoulutuksen jälkeen, jotta vältytään käyttämättömien ilmentymien käyttämiseen liittyviltä kustannuksilta. Jokaisen resursseja luovan skriptin kanssa GitHub repo tarjoaa vastaavan komentosarjan niiden poistamiseksi. Asetuksen puhdistamiseksi meidän on poistettava FSx-tiedostojärjestelmä ennen klusterin poistamista, koska se liittyy aliverkkoon klusterin VPC:ssä. FSx-tiedostojärjestelmän poistamiseksi meidän tarvitsee vain suorittaa seuraava komento (sisältä FSX kansio):

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

Huomaa, että tämä ei ainoastaan ​​poista pysyvää taltiota, se poistaa myös FSx-tiedostojärjestelmän ja kaikki tiedostojärjestelmän tiedot menetetään. Kun tämä vaihe on valmis, voimme poistaa klusterin käyttämällä seuraavaa komentosarjaa EKS kansio:

./eks-delete.sh

Tämä poistaa kaikki olemassa olevat podit, poistaa klusterin ja poistaa alussa luodun VPC:n.

Yhteenveto

Tässä viestissä kerroimme yksityiskohtaisesti vaiheet, joita tarvitaan PyTorchin hajautetun datan rinnakkaismallikoulutuksen suorittamiseen EKS-klustereissa. Tämä tehtävä saattaa tuntua pelottavalta, mutta AWS DevOps EKS:lle AWS:n ML Frameworks -tiimin luoma projekti tarjoaa kaikki tarvittavat komentosarjat ja työkalut prosessin yksinkertaistamiseksi ja hajautetun mallikoulutuksen helpottamiseksi.

Lisätietoja tässä viestissä käytetyistä teknologioista on osoitteessa Amazon EX ja Taskulamppu jaettu elastinen. Kehotamme sinua soveltamaan tässä kuvattua lähestymistapaa omiin hajautettuihin koulutuskäyttötapauksiin.

Esittelymateriaalit

Tietoja kirjoittajista

Imran Younus on AWS:n ML Frameworks -tiimin pääratkaisuarkkitehti. Hän keskittyy laajamittaiseen koneoppimiseen ja syvään oppimiseen liittyviin työkuormiin AWS-palveluissa, kuten Amazon EKS ja AWS ParallelCluster. Hänellä on laaja kokemus Deep Leaningin sovelluksista Computer Visionissa ja teollisessa IoT:ssä. Imran valmistui tohtoriksi korkean energian hiukkasfysiikasta, jossa hän on ollut mukana analysoimassa kokeellista dataa petatavuissa.

Alex Iankoulski on täyspinon ohjelmisto- ja infrastruktuuriarkkitehti, joka haluaa tehdä syvällistä, käytännönläheistä työtä. Hän on tällä hetkellä AWS:n itsehallitun koneoppimisen pääratkaisuarkkitehti. Roolissaan hän keskittyy auttamaan asiakkaita ML- ja AI-työkuormien konteinnissa ja organisoinnissa konttikäyttöisissä AWS-palveluissa. Hän on myös avoimen lähdekoodin kirjoittaja Tee puitteet ja Docker-kapteeni, joka rakastaa konttitekniikoiden soveltamista innovaation vauhdittamiseksi ja samalla maailman suurimpien haasteiden ratkaisemiseksi. Viimeisten 10 vuoden aikana Alex on työskennellyt ilmastonmuutoksen torjumiseksi, tekoälyn ja ML:n demokratisoimiseksi, matkustamisen turvallisuuden parantamiseksi, terveydenhuollon parantamiseksi ja energian fiksummaksi.