Instruire distribuită cu Amazon EKS și Torch Distributed Elastic

Instruirea modelului de deep learning distribuit devine din ce în ce mai importantă, deoarece dimensiunile datelor cresc în multe industrii. Multe aplicații în viziunea computerizată și procesarea limbajului natural necesită acum formarea modelelor de învățare profundă, care cresc exponențial în complexitate și sunt adesea antrenate cu sute de terabytes de date. Atunci devine important să folosiți o infrastructură vastă de cloud pentru a scala formarea unor astfel de modele mari.

Dezvoltatorii pot folosi cadre open-source, cum ar fi PyTorch, pentru a proiecta cu ușurință arhitecturi de model intuitive. Cu toate acestea, scalarea antrenamentului acestor modele pe mai multe noduri poate fi o provocare din cauza complexității crescute a orchestrației.

Formarea modelului distribuit constă în principal din două paradigme:

• Model paralel – În antrenamentul în paralel cu modelul, modelul în sine este atât de mare încât nu poate încăpea în memoria unui singur GPU și sunt necesare mai multe GPU-uri pentru a antrena modelul. Modelul GPT-3 al Open AI cu 175 de miliarde de parametri antrenabili (aproximativ 350 GB în dimensiune) este un bun exemplu în acest sens.
• Date paralele – În antrenamentul în paralel cu datele, modelul poate locui într-un singur GPU, dar deoarece datele sunt atât de mari, poate dura zile sau săptămâni pentru a antrena un model. Distribuirea datelor pe mai multe noduri GPU poate reduce semnificativ timpul de antrenament.

În această postare, oferim un exemplu de arhitectură pentru a antrena modele PyTorch folosind Torță distribuită elastică cadru într-un mod paralel de date distribuite folosind Serviciul Amazon Elastic Kubernetes (Amazon EKS).

Cerințe preliminare

Pentru a reproduce rezultatele raportate în această postare, singura condiție prealabilă este un cont AWS. În acest cont, creăm un cluster EKS și un Amazon FSx pentru Luster Sistemul de fișiere. De asemenea, împingem imaginile containerului la un Registrul Amazon de containere elastice (Amazon ECR) din cont. Instrucțiunile pentru configurarea acestor componente sunt furnizate după cum este necesar pe parcursul postării.

clustere EKS

Amazon EKS este un serviciu de container gestionat pentru rularea și scalarea aplicațiilor Kubernetes pe AWS. Cu Amazon EKS, puteți rula eficient joburi de instruire distribuite folosind cele mai recente Cloud Elastic de calcul Amazon (Amazon EC2) fără a fi nevoie să instalați, să operați și să vă întrețineți propriul plan de control sau noduri. Este un popular orchestrator pentru învățare automată (ML) și fluxuri de lucru AI. Un cluster EKS tipic în AWS arată ca în figura următoare.

Am lansat un proiect open-source, AWS DevOps pentru EKS (aws-do-eks), care oferă o colecție mare de scripturi și instrumente ușor de utilizat și configurabile pentru furnizarea clusterelor EKS și pentru a rula joburi de instruire distribuite. Acest proiect este construit urmând principiile Faceți Cadrul: Simplitate, flexibilitate și universalitate. Puteți configura clusterul dorit utilizând eks.conf fișier și apoi lansați-l rulând fișierul eks-create.sh scenariu. Instrucțiuni detaliate sunt furnizate în GitHub repo.

Antrenați modele PyTorch folosind Torch Distributed Elastic

Torch Distributed Elastic (TDE) este o bibliotecă nativă PyTorch pentru formarea modelelor de învățare profundă la scară largă, unde este esențial să scalați resursele de calcul în mod dinamic, în funcție de disponibilitate. The Controler TorchElastic pentru Kubernetes este o implementare nativă Kubernetes pentru TDE care gestionează automat ciclul de viață al pod-urilor și serviciilor necesare pentru instruirea TDE. Permite scalarea dinamică a resurselor de calcul în timpul antrenamentului, după cum este necesar. Oferă, de asemenea, instruire tolerantă la erori prin recuperarea joburilor din defecțiunea nodului.

În această postare, discutăm pașii pentru a antrena PyTorch EfficientNet-B7 și ResNet50 modele folosind IMAGEnet date într-un mod distribuit cu TDE. Folosim PyTorch DistributedDataParallel API și controlerul Kubernetes TorchElastic și rulați lucrările noastre de instruire pe un cluster EKS care conține mai multe noduri GPU. Următoarea diagramă prezintă diagrama arhitecturii pentru acest model de antrenament.

TorchElastic pentru Kubernetes constă în principal din două componente: TorchElastic Kubernetes Controller (TEC) și serverul de parametri (etcd). Controlerul este responsabil pentru monitorizarea și gestionarea joburilor de instruire, iar serverul de parametri ține evidența nodurilor de lucru pentru sincronizarea distribuită și descoperirea de la egal la egal.

Pentru ca podurile de antrenament să acceseze datele, avem nevoie de un volum de date partajat care poate fi montat de fiecare pod. Câteva opțiuni pentru volume partajate prin Interfață de stocare container drivere (CSI) incluse în AWS DevOps pentru EKS sunt Sistem de fișiere elastice Amazon (Amazon EFS) și FSx pentru Luster.

Configurarea clusterului

În configurația noastră de cluster, folosim o instanță c5.2xlarge pentru podurile de sistem. Folosim trei instanțe p4d.24xlarge ca pod-uri de lucru pentru a antrena un model EfficientNet. Pentru instruirea ResNet50, folosim instanțe p3.8xlarge ca pod-uri de lucru. În plus, folosim un sistem de fișiere partajat FSx pentru a stoca datele noastre de antrenament și artefactele modelului.

Instanțele AWS p4d.24xlarge sunt echipate cu Adaptor pentru țesături elastice (EFA) pentru a oferi rețele între noduri. Vom discuta mai multe despre EFA mai târziu în postare. Pentru a activa comunicarea prin EFA, trebuie să configuram configurarea clusterului printr-un fișier .yaml. Un fișier exemplu este furnizat în depozitul GitHub.

După ce acest fișier .yaml este configurat corect, putem lansa clusterul folosind scriptul furnizat în depozitul GitHub:

./eks-create.sh

Consultați GitHub repo pentru instrucțiuni detaliate.

Practic, nu există nicio diferență între rularea joburilor pe p4d.24xlarge și p3.8xlarge. Pașii descriși în această postare funcționează pentru ambele. Singura diferență este disponibilitatea EFA pe instanțe p4d.24xlarge. Pentru modelele mai mici, cum ar fi ResNet50, rețeaua standard în comparație cu rețeaua EFA are un impact minim asupra vitezei de antrenament.

FSx pentru sistemul de fișiere Luster

FSx este proiectat pentru încărcături de lucru de calcul de înaltă performanță și oferă o latență de sub milisecunde folosind volume de stocare a unităților SSD. Am ales FSx pentru că a oferit performanțe mai bune, deoarece am scalat la un număr mare de noduri. Un detaliu important de remarcat este că FSx poate exista doar într-o singură zonă de disponibilitate. Prin urmare, toate nodurile care accesează sistemul de fișiere FSx ar trebui să existe în aceeași zonă de disponibilitate ca și sistemul de fișiere FSx. O modalitate de a realiza acest lucru este să specificați zona de disponibilitate relevantă în fișierul cluster .yaml pentru grupurile de noduri specifice înainte de a crea clusterul. Alternativ, putem modifica partea de rețea a grupului de scalare automată pentru aceste noduri după ce clusterul este configurat și o putem limita la utilizarea unei singure subrețea. Acest lucru se poate face cu ușurință pe consola Amazon EC2.

Presupunând că clusterul EKS este activ și rulează și că ID-ul de subrețea pentru Zona de Disponibilitate este cunoscut, putem configura un sistem de fișiere FSx furnizând informațiile necesare în fsx.conf fișier așa cum este descris în Readme și rulează deploy.sh scenariul în fsx pliant. Aceasta setează politica corectă și grupul de securitate pentru accesarea sistemului de fișiere. Scriptul instalează de asemenea driver CSI pentru FSx ca un set de demoni. În cele din urmă, putem crea revendicarea volumului persistent FSx în Kubernetes aplicând un singur fișier .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

Aceasta creează un sistem de fișiere FSx în zona de disponibilitate specificată în fsx.conf fișier și, de asemenea, creează o revendicare de volum persistentă fsx-pvc, care poate fi montat de oricare dintre podurile din cluster într-un mod de citire-scriere-multe (RWX).

În experimentul nostru, am folosit date complete ImageNet, care conține mai mult de 12 milioane de imagini de antrenament împărțite în 1,000 de clase. Datele pot fi descărcate din Site-ul ImageNet. Mingea TAR originală are mai multe directoare, dar pentru antrenamentul nostru de model, ne interesează doar ILSVRC/Data/CLS-LOC/, care include train și val subdirectoare. Înainte de antrenament, trebuie să rearanjam imaginile din val subdirectorul pentru a se potrivi cu structura de directoare cerută de PyTorch ImageFolder clasă. Acest lucru se poate face folosind un simplu Script Python după ce datele sunt copiate pe volumul persistent în pasul următor.

Pentru a copia datele dintr-un Serviciul Amazon de stocare simplă (Amazon S3) la sistemul de fișiere FSx, creăm o imagine Docker care include scripturi pentru această sarcină. Un exemplu Dockerfile și un script shell sunt incluse în fișierul csi folderul din depozitul GitHub. Putem construi imaginea folosind build.sh script și apoi împingeți-l către Amazon ECR folosind push.sh scenariu. Înainte de a folosi aceste scripturi, trebuie să furnizăm URI-ul corect pentru depozitul ECR din .env fișier în folderul rădăcină al depozitului GitHub. După ce împingem imaginea Docker către Amazon ECR, putem lansa un pod pentru a copia datele aplicând fișierul .yaml relevant:

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

Podul rulează automat scriptul data-prep.sh pentru a copia datele de pe Amazon S3 pe volumul partajat. Deoarece datele ImageNet au peste 12 milioane de fișiere, procesul de copiere durează câteva ore. Scriptul Python imagenet_data_prep.py este, de asemenea, rulat pentru a rearanja val set de date așa cum era de așteptat de PyTorch.

Accelerarea rețelei

Putem folosi Elastic Fabric Adapter (EFA) în combinație cu tipuri de instanțe EC2 acceptate pentru a accelera traficul de rețea între nodurile GPU din clusterul dvs. Acest lucru poate fi util atunci când rulați joburi mari de instruire distribuite în care comunicarea standard în rețea poate fi un blocaj. Scripturile pentru implementarea și testarea pluginului de dispozitiv EFA în clusterul EKS pe care îl folosim aici sunt incluse în efa-device-plugin folderul din depozitul GitHub. Pentru a activa un job cu EFA în clusterul dvs. EKS, pe lângă nodurile clusterului care au hardware-ul și software-ul necesar, pluginul pentru dispozitiv EFA trebuie să fie implementat în cluster, iar containerul dvs. de joburi trebuie să aibă CUDA și NCCL compatibile Versiunile instalat.

Pentru a demonstra rularea testelor NCCL și evaluarea performanței EFA pe instanțe p4d.24xlarge, trebuie mai întâi să implementăm operatorul Kubeflow MPI prin rularea corespunzătoare deploy.sh scenariul în mpi-operator pliant. Apoi rulăm deploy.sh script și actualizați test-efa-nccl.yaml manifestă astfel limite și solicitări de resurse vpc.amazonaws.com sunt setate la 4. Cele patru adaptoare EFA disponibile din nodurile p4d.24xlarge sunt combinate pentru a oferi un debit maxim.

Alerga kubectl apply -f ./test-efa-nccl.yaml pentru a aplica testul și apoi afișați jurnalele testului. Următoarea linie din rezultatul jurnalului confirmă faptul că EFA este utilizat:

NCCL INFO NET/OFI Selected Provider is efa

Rezultatele testului ar trebui să arate similar cu următoarea ieșire:

[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

Putem observa în rezultatele testelor că debitul maxim este de aproximativ 42 GB/sec, iar lățimea medie de bandă a magistralei este de aproximativ 8 GB.

De asemenea, am efectuat experimente cu un singur adaptor EFA activat, precum și fără adaptoare EFA. Toate rezultatele sunt rezumate în tabelul următor.

De asemenea, am constatat că, pentru modele relativ mici, cum ar fi ImageNet, utilizarea rețelei accelerate reduce timpul de antrenament pe epocă doar cu 5–8% la dimensiunea lotului de 64. Pentru modele mai mari și dimensiuni mai mici a loturilor, atunci când este necesară o comunicare sporită a greutăților în rețea. , utilizarea rețelelor accelerate are un impact mai mare. Am observat o scădere a timpului de antrenament de epocă cu 15–18% pentru antrenamentul EfficientNet-B7 cu dimensiunea lotului 1. Impactul real al EFA asupra antrenamentului dumneavoastră va depinde de dimensiunea modelului dumneavoastră.

Monitorizare GPU

Înainte de a rula jobul de antrenament, putem și configura Amazon CloudWatch metrici pentru a vizualiza utilizarea GPU-ului în timpul antrenamentului. Poate fi util să știm dacă resursele sunt utilizate în mod optim sau dacă pot identifica lipsa de resurse și blocajele în procesul de formare.

Scripturile relevante pentru configurarea CloudWatch se află în GPU-metrics pliant. Mai întâi, creăm o imagine Docker cu amazon-cloudwatch-agent și nvidia-smi. Putem folosi Dockerfile în fișierul gpu-metrics folder pentru a crea această imagine. Presupunând că registrul ECR este deja setat în .env fișier de la pasul anterior, putem construi și împinge imaginea folosind build.sh și push.sh. După aceasta, rulați deploy.sh scriptul finalizează automat configurarea. Lansează un daemonset cu amazon-cloudwatch-agent și împinge diverse valori către CloudWatch. Valorile GPU apar sub CWAgent spațiu de nume pe consola CloudWatch. Restul valorilor clusterului sunt afișate sub ContainerInsights spațiu de nume.

Antrenamentul modelului

Toate scripturile necesare pentru instruirea PyTorch sunt situate în elasticjob folderul din depozitul GitHub. Înainte de a lansa jobul de formare, trebuie să rulăm etcd server, care este folosit de TEC pentru descoperirea lucrătorilor și schimbul de parametri. The deploy.sh scenariul în elasticjob folderul face exact asta.

Pentru a profita de EFA în cazurile p4d.24xlarge, trebuie să folosim o anumită imagine Docker disponibilă în Galeria publică Amazon ECR care sprijină comunicarea NCCL prin EFA. Trebuie doar să copiem codul nostru de antrenament în această imagine Docker. The Dockerfile în temeiul probe folderul creează o imagine pentru a fi utilizată atunci când rulează jobul de antrenament pe instanțe p4d. Ca întotdeauna, putem folosi construi.sh și împinge.sh scripturi din folder pentru a construi și a împinge imaginea.

imagenet-efa.yaml dosarul descrie munca de formare. Acest fișier .yaml setează resursele necesare pentru rularea jobului de antrenament și, de asemenea, montează volumul persistent cu datele de antrenament configurate în secțiunea anterioară.

Câteva lucruri merită subliniate aici. Numărul de replici trebuie setat la numărul de noduri disponibile în cluster. În cazul nostru, am setat acest lucru la 3 pentru că aveam trei noduri p4d.24xlarge. În imagenet-efa.yaml fișier, nvidia.com/gpu parametru sub resurse și nproc_per_node în args ar trebui setat la numărul de GPU-uri per nod, care în cazul p4d.24xlarge este 8. De asemenea, argumentul de lucru pentru script-ul Python stabilește numărul de procesoare per proces. Am ales ca acesta să fie 4 deoarece, în experimentele noastre, acesta oferă performanță optimă atunci când rulează pe instanțe p4d.24xlarge. Aceste setări sunt necesare pentru a maximiza utilizarea tuturor resurselor hardware disponibile în cluster.

Când lucrarea rulează, putem observa utilizarea GPU-urilor în CloudWatch pentru toate GPU-urile din cluster. Următorul este un exemplu dintr-unul dintre joburile noastre de instruire cu trei noduri p4d.24xlarge în cluster. Aici am selectat câte un GPU de la fiecare nod. Cu setările menționate mai devreme, utilizarea GPU-ului este aproape de 100% în timpul fazei de antrenament a epocii pentru toate nodurile din cluster.

Pentru antrenamentul unui model ResNet50 folosind instanțe p3.8xlarge, avem nevoie de exact aceiași pași ca cei descriși pentru antrenamentul EfficientNet folosind p4d.24xlarge. De asemenea, putem folosi aceeași imagine Docker. După cum am menționat mai devreme, instanțele p3.8xlarge nu sunt echipate cu EFA. Cu toate acestea, pentru modelul ResNet50, acesta nu este un dezavantaj semnificativ. The imagenet-fsx.yaml scriptul furnizat în depozitul GitHub setează jobul de instruire cu resurse adecvate pentru tipul de nod p3.8xlarge. Lucrarea folosește același set de date din sistemul de fișiere FSx.

Scalare GPU

Am efectuat câteva experimente pentru a observa modul în care timpul de antrenament se scalează pentru modelul EfficientNet-B7 prin creșterea numărului de GPU. Pentru a face acest lucru, am modificat numărul de replici de la 1 la 3 în fișierul nostru de antrenament .yaml pentru fiecare rulare de antrenament. Am observat doar timpul pentru o singură epocă în timp ce am folosit setul complet de date ImageNet. Următoarea figură arată rezultatele experimentului nostru de scalare a GPU. Linia punctată roșie reprezintă modul în care timpul de antrenament ar trebui să scadă de la o rulare folosind 8 GPU-uri prin creșterea numărului de GPU-uri. După cum putem vedea, scalarea este destul de apropiată de ceea ce se așteaptă.

În mod similar, am obținut diagrama de scalare a GPU pentru antrenamentul ResNet50 pe instanțe p3.8xlarge. Pentru acest caz, am schimbat replicile din fișierul nostru .yaml de la 1 la 4. Rezultatele acestui experiment sunt prezentate în figura următoare.

A curăța

Este important să reduceți resursele după formarea modelului pentru a evita costurile asociate cu rularea instanțelor inactive. Cu fiecare script care creează resurse, GitHub repo oferă un script de potrivire pentru a le șterge. Pentru a ne curăța configurația, trebuie să ștergem sistemul de fișiere FSx înainte de a șterge clusterul, deoarece este asociat cu o subrețea din VPC-ul clusterului. Pentru a șterge sistemul de fișiere FSx, trebuie doar să rulăm următoarea comandă (din interiorul fsx pliant):

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

Rețineți că acest lucru nu va șterge doar volumul persistent, ci va șterge și sistemul de fișiere FSx și toate datele de pe sistemul de fișiere se vor pierde. Când acest pas este finalizat, putem șterge cluster-ul utilizând următorul script în ex pliant:

./eks-delete.sh

Aceasta va șterge toate podurile existente, va elimina clusterul și va șterge VPC-ul creat la început.

Concluzie

În această postare, am detaliat pașii necesari pentru rularea instruirii modelului paralel de date distribuite PyTorch pe clustere EKS. Această sarcină poate părea descurajantă, dar AWS DevOps pentru EKS proiectul creat de echipa ML Frameworks de la AWS oferă toate scripturile și instrumentele necesare pentru a simplifica procesul și a face formarea modelului distribuit ușor accesibilă.

Pentru mai multe informații despre tehnologiile utilizate în această postare, vizitați Amazon EKS și Torță distribuită elastică. Vă încurajăm să aplicați abordarea descrisă aici pentru propriile dvs. cazuri de utilizare a instruirii distribuite.

Resurse

Despre autori

Imran Younus este un arhitect principal de soluții pentru echipa ML Frameworks la AWS. El se concentrează pe învățarea automată la scară largă și pe sarcinile de lucru de deep learning în serviciile AWS precum Amazon EKS și AWS ParallelCluster. Are o vastă experiență în aplicațiile Deep Leaning în Computer Vision și Industrial IoT. Imran și-a obținut doctoratul în fizica particulelor de înaltă energie, unde a fost implicat în analiza datelor experimentale la scară peta-octeți.

Alex Iankoulski este un arhitect de software și infrastructură complet căruia îi place să facă o muncă profundă și practică. În prezent, este arhitect principal de soluții pentru învățarea automată autogestionată la AWS. În rolul său, el se concentrează pe a ajuta clienții cu containerizarea și orchestrarea sarcinilor de lucru ML și AI pe servicii AWS alimentate de containere. El este, de asemenea, autorul open source Faceți cadru și un căpitan Docker căruia îi place să aplice tehnologii de containere pentru a accelera ritmul inovației, rezolvând în același timp cele mai mari provocări ale lumii. În ultimii 10 ani, Alex a lucrat la combaterea schimbărilor climatice, la democratizarea inteligenței artificiale și a ML, făcând călătoriile mai sigure, îngrijirea sănătății mai bună și energia mai inteligentă.