Elosztott képzés az Amazon EKS és a Torch Distributed Elastic segítségével

Az elosztott mély tanulási modell képzés egyre fontosabbá válik, mivel az adatok mérete számos iparágban növekszik. A számítógépes látás és a természetes nyelvi feldolgozás számos alkalmazása megköveteli a mély tanulási modellek képzését, amelyek összetettsége exponenciálisan növekszik, és gyakran több száz terabájtnyi adattal tanítják őket. Ezután fontossá válik egy hatalmas felhő-infrastruktúra használata az ilyen nagy modellek képzésének skálázásához.

A fejlesztők használhatják a nyílt forráskódú keretrendszereket, például a PyTorch-ot, hogy könnyen tervezzenek intuitív modellarchitektúrákat. Ezeknek a modelleknek a betanításának több csomóponton való skálázása azonban kihívást jelenthet a megnövekedett hangszerelési összetettség miatt.

Az elosztott modellképzés alapvetően két paradigmából áll:

• Modell párhuzamos – A modell párhuzamos betanításánál maga a modell akkora méretű, hogy egyetlen GPU memóriájába sem fér bele, a modell betanításához pedig több GPU szükséges. Jó példa erre az Open AI GPT-3 modellje 175 milliárd betanítható paraméterrel (kb. 350 GB méretű).
• Az adatok párhuzamosak – Az adatok párhuzamos betanítása során a modell elhelyezkedhet egyetlen GPU-ban, de mivel az adatok olyan nagyok, napokba vagy hetekbe telhet egy modell betanítása. Az adatok több GPU-csomópont közötti elosztása jelentősen csökkentheti a betanítási időt.

Ebben a bejegyzésben egy példaarchitektúrát mutatunk be a PyTorch modellek betanítására a Elosztott elasztikus zseblámpa keretrendszer elosztott adatok párhuzamos használatával Amazon Elastic Kubernetes szolgáltatás (Amazon EKS).

Előfeltételek

Az ebben a bejegyzésben közölt eredmények megismétléséhez az egyetlen előfeltétel egy AWS-fiók. Ebben a fiókban létrehozunk egy EKS-fürtöt és egy Amazon FSx Lusterhez fájlrendszer. A konténerképeket is továbbítjuk egy Amazon Elastic Container Registry (Amazon ECR) adattárat a fiókban. Ezen összetevők beállítására vonatkozó utasítások szükség szerint megtalálhatók a bejegyzésben.

EKS klaszterek

Az Amazon EKS egy felügyelt konténerszolgáltatás, amely Kubernetes-alkalmazásokat futtat és méretez az AWS-en. Az Amazon EKS segítségével hatékonyan futtathat elosztott képzési feladatokat a legújabb eszközökkel Amazon rugalmas számítási felhő (Amazon EC2) példányok saját vezérlősík vagy csomópontok telepítése, működtetése és karbantartása nélkül. Ez egy népszerű hangszerelő gépi tanuláshoz (ML) és AI munkafolyamatokhoz. Egy tipikus EKS-fürt az AWS-ben a következő ábra szerint néz ki.

Kiadtunk egy nyílt forráskódú projektet, AWS DevOps for EKS (aws-do-eks), amely könnyen használható és konfigurálható szkriptek és eszközök nagy gyűjteményét kínálja az EKS-fürtök létrehozásához és az elosztott képzési feladatok futtatásához. Ez a projekt az alapelvek szerint épül fel Végezze el a keretrendszert: Egyszerűség, rugalmasság és egyetemesség. A kívánt fürtöt a gombbal konfigurálhatja eks.conf fájlt, majd indítsa el a eks-create.sh forgatókönyv. A részletes utasításokat a GitHub repo.

Tanítsa a PyTorch modelleket a Torch Distributed Elastic használatával

A Torch Distributed Elastic (TDE) egy natív PyTorch-könyvtár nagyméretű mély tanulási modellek betanításához, ahol kritikus a számítási erőforrások dinamikus méretezése a rendelkezésre állás alapján. A TorchElastic vezérlő Kuberneteshez egy natív Kubernetes-implementáció a TDE számára, amely automatikusan kezeli a TDE képzéshez szükséges podok és szolgáltatások életciklusát. Lehetővé teszi a számítási erőforrások dinamikus skálázását edzés közben, szükség szerint. Hibatűrő képzést is biztosít azáltal, hogy helyreállítja a feladatokat a csomópont meghibásodásából.

Ebben a bejegyzésben a PyTorch betanításának lépéseit tárgyaljuk EfficientNet-B7 és a ResNet50 használó modellek ImageNet az adatokat elosztott módon TDE-vel. PyTorch-ot használunk DistributedDataParallel API-t és a Kubernetes TorchElastic vezérlőt, és futtassa tanítási feladatainkat egy több GPU-csomópontot tartalmazó EKS-fürtön. A következő diagram ennek a modelltanításnak az architektúráját mutatja be.

A TorchElastic for Kubernetes főként két összetevőből áll: a TorchElastic Kubernetes-vezérlőből (TEC) és a paraméterkiszolgálóból (stb.). A vezérlő felelős a betanítási feladatok figyeléséért és kezeléséért, a paraméterkiszolgáló pedig nyomon követi a dolgozó csomópontjait az elosztott szinkronizálás és a peer felderítés érdekében.

Ahhoz, hogy a tréning podok hozzáférjenek az adatokhoz, szükségünk van egy megosztott adatkötetre, amelyet minden podhoz fel lehet szerelni. Néhány lehetőség a megosztott kötetekhez Konténer tárolási felület (CSI) illesztőprogramokat tartalmaz AWS DevOps az EKS-hez faliórái Amazon elasztikus fájlrendszer (Amazon EFS) és FSx a Lusterhez.

Klaszter beállítása

Fürtkonfigurációnkban egy c5.2xlarge példányt használunk a rendszerdobozokhoz. Három p4d.24xlarge példányt használunk worker pod-ként az EfficientNet modell betanításához. A ResNet50 képzéshez p3.8xlarge példányokat használunk worker pod-ként. Ezenkívül egy FSx megosztott fájlrendszert használunk a képzési adatok és a modelltermékek tárolására.

Az AWS p4d.24xlarge példányok fel vannak szerelve Elasztikus szövetadapter (EFA) hálózatot biztosít a csomópontok között. Az EFA-ról bővebben a bejegyzés későbbi részében fogunk beszélni. Az EFA-n keresztüli kommunikáció engedélyezéséhez konfigurálnunk kell a fürtbeállítást egy .yaml fájlon keresztül. An példa fájl a GitHub adattárában található.

Miután ez a .yaml fájl megfelelően be van állítva, elindíthatjuk a fürtöt a GitHub-tárban található szkript segítségével:

./eks-create.sh

Utal GitHub repo részletes útmutatásért.

Gyakorlatilag nincs különbség a p4d.24xlarge és a p3.8xlarge felületen futó jobok között. Az ebben a bejegyzésben leírt lépések mindkét esetben működnek. Az egyetlen különbség az EFA elérhetősége a p4d.24xlarge példányokon. Kisebb modelleknél, mint például a ResNet50, az EFA-hálózattal összehasonlítva a szabványos hálózat minimális hatással van az edzés sebességére.

FSx Luster fájlrendszerhez

Az FSx-et nagy teljesítményű számítási munkaterhelésekhez tervezték, és ezredmásodperc alatti késleltetést biztosít a szilárdtestalapú meghajtók tárolási köteteinek használatával. Azért választottuk az FSx-et, mert jobb teljesítményt nyújtott, mivel nagyszámú csomópontra méreteztük. Fontos megjegyezni, hogy az FSx csak egyetlen elérhetőségi zónában létezhet. Ezért az FSx fájlrendszerhez hozzáférő összes csomópontnak ugyanabban az elérhetőségi zónában kell lennie, mint az FSx fájlrendszernek. Ennek egyik módja az, hogy a fürt létrehozása előtt megadja a megfelelő Elérhetőségi zónát a fürt .yaml fájljában az adott csomópontcsoportokhoz. Alternatív megoldásként módosíthatjuk ezen csomópontok automatikus skálázási csoportjának hálózati részét a fürt beállítása után, és egyetlen alhálózat használatára korlátozhatjuk. Ez egyszerűen megtehető az Amazon EC2 konzolon.

Feltételezve, hogy az EKS-fürt működik és működik, és az elérhetőségi zóna alhálózati azonosítója ismert, beállíthatunk egy FSx fájlrendszert a szükséges információk megadásával a fsx.conf fájlban leírtak szerint readme és fut a telepíteni.sh forgatókönyv a FSX mappát. Ezzel beállítja a megfelelő házirendet és biztonsági csoportot a fájlrendszer eléréséhez. A szkript telepíti a CSI driver FSx-hez démonsetként. Végül létrehozhatjuk az FSx állandó kötetigénylést a Kubernetesben egyetlen .yaml fájl alkalmazásával:

kubectl apply -f fsx-pvc-dynamic.yaml

Ez egy FSx fájlrendszert hoz létre a következőben megadott elérhetőségi zónában fsx.conf fájlt, és állandó kötetkövetelést is létrehoz fsx-pvc, amelyet a fürt bármelyik podjára fel lehet szerelni sok olvasható-írható (RWX) módban.

Kísérletünkben teljes ImageNet adatot használtunk, amely több mint 12 millió edzésképet tartalmaz 1,000 osztályra osztva. Az adatok letölthetők a ImageNet weboldal. Az eredeti TAR labdának több könyvtára is van, de a modellképzésünkre csak az érdekel minket ILSVRC/Data/CLS-LOC/, amely magában foglalja a train és a val alkönyvtárak. Edzés előtt át kell rendeznünk a képeket a val alkönyvtárat, hogy megfeleljen a PyTorch által megkövetelt könyvtárszerkezetnek ImageFolder osztály. Ez megtehető egy egyszerű Python szkript miután a következő lépésben az adatokat a tartós kötetre másolta.

Az adatok másolásához egy Amazon egyszerű tárolási szolgáltatás (Amazon S3) vödröt az FSx fájlrendszerhez, létrehozunk egy Docker-képet, amely tartalmazza a feladathoz szükséges szkripteket. Egy példa Dockerfile és egy shell script szerepel a csi mappát a GitHub tárhelyen belül. A képet a build.sh szkriptet, majd tolja be az Amazon ECR-be a segítségével push.sh forgatókönyv. Mielőtt ezeket a szkripteket használnánk, meg kell adnunk a megfelelő URI-t az ECR-tárhoz a .env fájlt a GitHub-tárház gyökérmappájában. Miután továbbítottuk a Docker-képet az Amazon ECR-be, elindíthatunk egy pod-ot az adatok másolásához a megfelelő .yaml fájl alkalmazásával:

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

A pod automatikusan futtatja a szkriptet data-prep.sh hogy az adatokat az Amazon S3-ról a megosztott kötetre másolja. Mivel az ImageNet adatok több mint 12 millió fájlt tartalmaznak, a másolási folyamat néhány órát vesz igénybe. A Python szkript imagenet_data_prep.py is fut, hogy átrendezze a val adatkészlet, ahogy azt a PyTorch elvárta.

Hálózati gyorsítás

Az Elastic Fabric Adaptert (EFA) együtt használhatjuk támogatott EC2 példánytípusok a fürt GPU-csomópontjai közötti hálózati forgalom felgyorsítására. Ez hasznos lehet nagy elosztott képzési feladatok futtatásakor, ahol a szabványos hálózati kommunikáció szűk keresztmetszetet jelenthet. Az EKS-fürtben az EFA-eszköz-bővítmény telepítéséhez és teszteléséhez használt szkriptek, amelyeket itt használunk, a efa-device-plugin mappát a GitHub-tárban. Az EFA-val való munka engedélyezéséhez az EKS-fürtben a szükséges hardverrel és szoftverrel rendelkező fürtcsomópontokon kívül az EFA eszközbővítményt is telepíteni kell a fürtre, és a feladattárolónak kompatibilis CUDA-val és NCCL-lel kell rendelkeznie. verzió telepítve.

Az NCCL-tesztek futtatásának demonstrálásához és az EFA teljesítményének kiértékeléséhez p4d.24xlarge példányokon először telepítenünk kell a Kubeflow MPI operátort a megfelelő telepíteni.sh forgatókönyv a mpi-operátor mappát. Ezután futtatjuk a telepíteni.sh szkriptet és frissítse a test-efa-nccl.yaml megnyilvánulnak, így korlátok és erőforrás-kérések vpc.amazonaws.com A négy elérhető EFA-adapter a p4d.4xlarge csomópontokban össze van kötve a maximális átvitel érdekében.

futás kubectl apply -f ./test-efa-nccl.yaml a teszt alkalmazásához, majd megjeleníti a tesztdoboz naplóit. A következő sor a naplókimenetben megerősíti, hogy EFA használatban van:

NCCL INFO NET/OFI Selected Provider is efa

A teszteredményeknek a következő kimenethez hasonlóan kell kinézniük:

[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

A teszteredményekben megfigyelhető, hogy a maximális átviteli sebesség körülbelül 42 GB/sec, az átlagos busz sávszélesség pedig körülbelül 8 GB.

Kísérleteket végeztünk egyetlen engedélyezett EFA adapterrel, valamint EFA adapterek nélkül. Az összes eredményt a következő táblázat foglalja össze.

Azt is megállapítottuk, hogy az olyan viszonylag kis modelleknél, mint az ImageNet, a gyorsított hálózat használata csak 5–8%-kal csökkenti a korszakonkénti betanítási időt 64-es kötegméret esetén. , a gyorsított hálózat használatának nagyobb hatása van. Az 15. kötegmérettel rendelkező EfficientNet-B18 betanításánál a korszakos képzési idő 7–1%-os csökkenését figyeltük meg. Az EFA edzésre gyakorolt ​​tényleges hatása a modell méretétől függ.

GPU figyelés

A betanítási munka lebonyolítása előtt beállíthatjuk is amazonfelhőóra mérőszámok a GPU kihasználtságának megjelenítéséhez a képzés során. Hasznos lehet tudni, hogy az erőforrásokat optimálisan használják-e fel, vagy potenciálisan azonosítja az erőforrások hiányát és a szűk keresztmetszeteket a képzési folyamatban.

A CloudWatch beállításához szükséges szkriptek itt találhatók gpu-metrics mappát. Először is létrehozunk egy Docker képet amazon-cloudwatch-agent és a nvidia-smi. Használhatjuk a Dockerfile-t a gpu-metrics mappát a kép létrehozásához. Feltéve, hogy az ECR nyilvántartás már be van állítva a .env fájlt az előző lépésből, a kép segítségével felépíthetjük és tolhatjuk build.sh és a push.sh. Ezt követően fut a deploy.sh script automatikusan befejezi a beállítást. Ezzel elindít egy démont amazon-cloudwatch-agent és különféle mutatókat küld a CloudWatch-nek. A GPU-metrikák a alatt jelennek meg CWAgent névtér a CloudWatch konzolon. A fürt többi mutatója a alatt látható ContainerInsights névtér.

Modellképzés

A PyTorch képzéshez szükséges összes szkript megtalálható a rugalmas munka mappát a GitHub-tárban. A képzési munka elindítása előtt le kell futtatnunk a etcd szervert, amelyet a TEC a dolgozók felderítésére és paramétercserére használ. A telepíteni.sh forgatókönyv a elasticjob mappa pontosan ezt teszi.

Az EFA előnyeinek kihasználásához p4d.24xlarge példányokban egy adott Docker-képet kell használnunk, amely elérhető a Amazon ECR Public Gallery amely támogatja az NCCL kommunikációt az EFA-n keresztül. Csak át kell másolnunk a képzési kódunkat erre a Docker-képre. A dockerfile alatt a minták mappa létrehoz egy képet, amelyet a képzési feladat futtatásakor használ a p4d példányokon. Mint mindig, most is használhatjuk a build.sh és a nyomja.sh szkriptek a mappában a kép létrehozásához és leküldéséhez.

A imagenet-efa.yaml fájl leírja a képzési munkát. Ez a .yaml fájl beállítja a betanítási feladat futtatásához szükséges erőforrásokat, és csatlakoztatja az állandó kötetet az előző szakaszban beállított betanítási adatokkal.

Itt érdemes kiemelni néhány dolgot. A replikák számát a fürtben elérhető csomópontok számára kell beállítani. Esetünkben ezt 3-ra állítottuk, mert három p4d.24xlarge csomópontunk volt. Ban,-ben imagenet-efa.yaml fájl, a nvidia.com/gpu paraméter a források és nproc_per_node alatt args A csomópontonkénti GPU-k számát kell beállítani, ami p4d.24xlarge esetén 8. A Python-szkriptre vonatkozó worker argumentum is beállítja a processzorok számát folyamatonként. Azért választottuk ezt a 4-et, mert kísérleteinkben ez optimális teljesítményt biztosít p4d.24xlarge példányokon. Ezek a beállítások szükségesek a fürtben elérhető összes hardvererőforrás maximalizálásához.

Amikor a feladat fut, megfigyelhetjük a GPU-használatot a CloudWatch-ban a fürt összes GPU-jára vonatkozóan. A következő egy példa az egyik képzési munkánkból három p4d.24xlarge csomóponttal a fürtben. Itt minden csomópontból kiválasztottunk egy GPU-t. A korábban említett beállításokkal a GPU-használat közel 100%-os az epocha betanítási szakaszában a fürt összes csomópontja esetében.

A p50xlarge példányokat használó ResNet3.8 modell betanításához pontosan ugyanazokra a lépésekre van szükségünk, mint a p4d.24xlarge használatával végzett EfficientNet képzésnél. Ugyanezt a Docker-képet is használhatjuk. Mint korábban említettük, a p3.8xlarge példányok nincsenek felszerelve EFA-val. A ResNet50 modell esetében azonban ez nem jelent jelentős hátrányt. A imagenet-fsx.yaml a GitHub-lerakatban biztosított szkript beállítja a betanítási feladatot a megfelelő erőforrásokkal a p3.8xlarge csomóponttípushoz. A feladat ugyanazt az adatkészletet használja az FSx fájlrendszerből.

GPU méretezés

Futtattunk néhány kísérletet annak megfigyelésére, hogy az EfficientNet-B7 modell betanítási időskálája a GPU-k számának növelésével hogyan lép fel. Ennek érdekében a replikák számát 1-ről 3-ra változtattuk a képzési .yaml fájlunkban minden edzési futáshoz. A teljes ImageNet adatkészlet használata közben csak egyetlen korszakban figyeltük meg az időt. A következő ábra a GPU skálázási kísérletünk eredményeit mutatja. A piros szaggatott vonal azt jelzi, hogy a GPU-k számának növelésével hogyan kell lecsökkennie a betanítási időnek egy 8 GPU-t használó futáshoz képest. Amint látjuk, a méretezés egészen közel áll az elvárthoz.

Hasonlóképpen megkaptuk a GPU skálázási diagramját a ResNet50 oktatásához p3.8xlarge példányokon. Ebben az esetben a .yaml fájl replikáit 1-ről 4-re változtattuk. A kísérlet eredményeit a következő ábra mutatja.

Tisztítsuk meg

A modell betanítása után fontos az erőforrások lebontása, hogy elkerülje a tétlen példányok futtatásával járó költségeket. Minden erőforrást létrehozó szkriptnél a GitHub repo megfelelő szkriptet biztosít ezek törléséhez. A beállítások megtisztításához törölnünk kell az FSx fájlrendszert a fürt törlése előtt, mivel az a fürt VPC-jében lévő alhálózathoz van társítva. Az FSx fájlrendszer törléséhez csak a következő parancsot kell futtatnunk (belülről FSX mappa):

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

Ne feledje, hogy ezzel nem csak az állandó kötetet törli, hanem az FSx fájlrendszert is, és a fájlrendszeren lévő összes adat elveszik. Ha ez a lépés befejeződött, törölhetjük a fürtöt a következő szkript használatával a volt mappa:

./eks-delete.sh

Ezzel törli az összes meglévő podot, eltávolítja a klasztert, és törli az elején létrehozott VPC-t.

Következtetés

Ebben a bejegyzésben részleteztük a PyTorch elosztott adatok párhuzamos modelljének EKS-fürtökön történő futtatásához szükséges lépéseket. Ez a feladat ijesztőnek tűnhet, de a AWS DevOps az EKS-hez Az AWS ML Frameworks csapata által létrehozott projekt minden szükséges szkriptet és eszközt biztosít a folyamat egyszerűsítéséhez és az elosztott modellképzés könnyen elérhetővé tételéhez.

Az ebben a bejegyzésben használt technológiákkal kapcsolatos további információkért látogasson el ide Amazon EX és a Elosztott elasztikus zseblámpa. Javasoljuk, hogy az itt leírt megközelítést alkalmazza saját elosztott képzési felhasználási eseteire.

Tudástár

A szerzőkről

Imran Younus az AWS ML Frameworks csapatának vezető megoldások építésze. A nagyszabású gépi tanulásra és a mély tanulási munkaterhelésre összpontosít az AWS-szolgáltatásokban, mint például az Amazon EKS és az AWS ParallelCluster. Nagy tapasztalattal rendelkezik a Deep Leaning in Computer Vision és Industrial IoT alkalmazásai terén. Imran nagyenergiájú részecskefizikából szerzett PhD fokozatot, ahol a kísérleti adatok petabájtos skálán történő elemzésében vett részt.

Alex Iankoulski egy full-stack szoftver és infrastruktúra építész, aki szeret mélyreható, gyakorlatias munkát végezni. Jelenleg az AWS-nél az önállóan menedzselt gépi tanulás fő megoldási építésze. Munkájában arra összpontosít, hogy segítse az ügyfeleket az ML és AI munkaterhelések konténerezésében és összehangolásában a konténeralapú AWS szolgáltatásokon. Ő a nyílt forráskód szerzője is Készíts keretet és egy Docker kapitány, aki szereti a konténertechnológiák alkalmazását az innováció ütemének felgyorsítására, miközben megoldja a világ legnagyobb kihívásait. Az elmúlt 10 évben Alex az éghajlatváltozás leküzdésén, a mesterséges intelligencia és az ML demokratizálásán, az utazás biztonságosabbá tételén, az egészségügy jobbá tételén és az energiaügyek okosabbá tételén dolgozott.