Formazione distribuita con Amazon EKS e Torch Distributed Elastic

La formazione del modello di apprendimento profondo distribuito sta diventando sempre più importante poiché le dimensioni dei dati stanno crescendo in molti settori. Molte applicazioni nella visione artificiale e nell'elaborazione del linguaggio naturale ora richiedono l'addestramento di modelli di deep learning, che stanno crescendo in modo esponenziale in termini di complessità e sono spesso addestrati con centinaia di terabyte di dati. Diventa quindi importante utilizzare una vasta infrastruttura cloud per scalare la formazione di modelli così grandi.

Gli sviluppatori possono utilizzare framework open source come PyTorch per progettare facilmente architetture di modelli intuitive. Tuttavia, il ridimensionamento dell'addestramento di questi modelli su più nodi può essere difficile a causa della maggiore complessità dell'orchestrazione.

Il training del modello distribuito consiste principalmente in due paradigmi:

• Modello parallelo – Nell'addestramento parallelo del modello, il modello stesso è così grande da non poter essere contenuto nella memoria di una singola GPU e per addestrare il modello sono necessarie più GPU. Il modello GPT-3 di Open AI con 175 miliardi di parametri addestrabili (circa 350 GB di dimensione) ne è un buon esempio.
• Dati paralleli – Nell'addestramento in parallelo dei dati, il modello può risiedere in una singola GPU, ma poiché i dati sono così grandi, possono essere necessari giorni o settimane per addestrare un modello. La distribuzione dei dati su più nodi GPU può ridurre significativamente i tempi di addestramento.

In questo post, forniamo un'architettura di esempio per addestrare i modelli PyTorch utilizzando il Elastico distribuito a torcia framework in un modo parallelo di dati distribuiti utilizzando Servizio Amazon Elastic Kubernetes (Amazon EKS).

Prerequisiti

Per replicare i risultati riportati in questo post, l'unico prerequisito è un account AWS. In questo account, creiamo un cluster EKS e un Amazon FSx per Lustre file system. Inviamo anche le immagini del contenitore a un Registro dei contenitori Amazon Elastic (Amazon ECR) nell'account. Le istruzioni per impostare questi componenti sono fornite secondo necessità durante tutto il post.

Cluster EKS

Amazon EKS è un servizio container gestito per eseguire e ridimensionare le applicazioni Kubernetes su AWS. Con Amazon EKS, puoi eseguire in modo efficiente lavori di formazione distribuiti utilizzando le più recenti Cloud di calcolo elastico di Amazon (Amazon EC2) senza la necessità di installare, utilizzare e mantenere il proprio piano di controllo o nodi. È un popolare orchestratore per flussi di lavoro di machine learning (ML) e AI. Un tipico cluster EKS in AWS è simile alla figura seguente.

Abbiamo rilasciato un progetto open source, AWS DevOps per EKS (aws-do-eks), che fornisce un'ampia raccolta di script e strumenti configurabili e facili da usare per eseguire il provisioning di cluster EKS ed eseguire processi di formazione distribuiti. Questo progetto è costruito seguendo i principi del Fai quadro: Semplicità, Flessibilità e Universalità. È possibile configurare il cluster desiderato utilizzando il eks.conf file e quindi avviarlo eseguendo il file eks-create.sh sceneggiatura. Istruzioni dettagliate sono fornite nel Repository GitHub.

Addestra i modelli PyTorch utilizzando Torch Distributed Elastic

Torch Distributed Elastic (TDE) è una libreria PyTorch nativa per l'addestramento di modelli di deep learning su larga scala in cui è fondamentale ridimensionare le risorse di calcolo in modo dinamico in base alla disponibilità. Il Controller TorchElastic per Kubernetes è un'implementazione Kubernetes nativa per TDE che gestisce automaticamente il ciclo di vita dei pod e dei servizi richiesti per la formazione TDE. Consente il ridimensionamento dinamico delle risorse di calcolo durante l'addestramento, se necessario. Fornisce inoltre una formazione a tolleranza d'errore ripristinando i lavori da un errore del nodo.

In questo post, discutiamo i passaggi per addestrare PyTorch EfficientNet-B7 ed ResNet50 modelli che utilizzano IMAGEnet dati in modo distribuito con TDE. Usiamo il PyTorch DistributedDataParallel API e il controller Kubernetes TorchElastic ed esegui i nostri processi di addestramento su un cluster EKS contenente più nodi GPU. Il diagramma seguente mostra il diagramma dell'architettura per questo training del modello.

TorchElastic per Kubernetes è costituito principalmente da due componenti: TorchElastic Kubernetes Controller (TEC) e il server dei parametri (etcd). Il controller è responsabile del monitoraggio e della gestione dei lavori di addestramento e il server dei parametri tiene traccia dei nodi di lavoro per la sincronizzazione distribuita e il rilevamento peer.

Affinché i pod di addestramento possano accedere ai dati, è necessario un volume di dati condiviso che possa essere montato da ciascun pod. Alcune opzioni per i volumi condivisi tramite Interfaccia di archiviazione del contenitore (CSI) driver inclusi in AWS DevOps per EKS sono File system elastico Amazon (Amazon EFS) e FSx per Lustro.

Configurazione del cluster

Nella nostra configurazione del cluster, utilizziamo un'istanza c5.2xlarge per i pod di sistema. Usiamo tre istanze p4d.24xlarge come pod di lavoro per addestrare un modello EfficientNet. Per la formazione ResNet50, utilizziamo istanze p3.8xlarge come pod di lavoro. Inoltre, utilizziamo un file system condiviso FSx per archiviare i nostri dati di addestramento e gli artefatti del modello.

Le istanze AWS p4d.24xlarge sono dotate di Adattatore in tessuto elastico (EFA) per fornire reti tra i nodi. Discutiamo di EFA più avanti nel post. Per abilitare la comunicazione tramite EFA, è necessario configurare l'installazione del cluster tramite un file .yaml. Un file di esempio è fornito nel repository GitHub.

Dopo aver configurato correttamente questo file .yaml, possiamo avviare il cluster utilizzando lo script fornito nel repository GitHub:

./eks-create.sh

Fare riferimento a Repository GitHub per le istruzioni dettagliate.

Non c'è praticamente alcuna differenza tra l'esecuzione di lavori su p4d.24xlarge e p3.8xlarge. I passaggi descritti in questo post funzionano per entrambi. L'unica differenza è la disponibilità di EFA su istanze p4d.24xlarge. Per i modelli più piccoli come ResNet50, la rete standard rispetto alla rete EFA ha un impatto minimo sulla velocità di formazione.

FSx per il file system Lustre

FSx è progettato per carichi di lavoro di elaborazione ad alte prestazioni e fornisce una latenza inferiore al millisecondo utilizzando volumi di archiviazione di unità a stato solido. Abbiamo scelto FSx perché ha fornito prestazioni migliori poiché abbiamo ridimensionato un numero elevato di nodi. Un dettaglio importante da notare è che FSx può esistere solo in una singola zona di disponibilità. Pertanto, tutti i nodi che accedono al file system FSx dovrebbero esistere nella stessa zona di disponibilità del file system FSx. Un modo per ottenere ciò è specificare la zona di disponibilità pertinente nel file .yaml del cluster per i gruppi di nodi specifici prima di creare il cluster. In alternativa, possiamo modificare la parte di rete del gruppo di ridimensionamento automatico per questi nodi dopo aver configurato il cluster e limitarlo all'utilizzo di una singola sottorete. Questo può essere fatto facilmente sulla console Amazon EC2.

Supponendo che il cluster EKS sia attivo e funzionante e che l'ID di sottorete per la zona di disponibilità sia noto, possiamo configurare un file system FSx fornendo le informazioni necessarie nel fsx.conf file come descritto in readme e correndo il distribuire.sh script in fsx cartella. Questo imposta la politica e il gruppo di sicurezza corretti per l'accesso al file system. Lo script installa anche il autista CSI per FSx come set di demoni. Infine, possiamo creare l'attestazione del volume persistente FSx in Kubernetes applicando un singolo file .yaml:

kubectl apply -f fsx-pvc-dynamic.yaml

Questo crea un file system FSx nella zona di disponibilità specificata in fsx.conf file e crea anche un'attestazione di volume persistente fsx-pvc, che può essere montato da qualsiasi pod nel cluster in modalità read-write-many (RWX).

Nel nostro esperimento, abbiamo utilizzato dati ImageNet completi, che contengono più di 12 milioni di immagini di addestramento suddivise in 1,000 classi. I dati possono essere scaricati dal Sito Web ImageNet. La palla TAR originale ha diverse directory, ma per il nostro addestramento del modello, siamo interessati solo a ILSVRC/Data/CLS-LOC/, che include il train ed val sottodirectory. Prima dell'allenamento, dobbiamo riorganizzare le immagini nel file val sottodirectory in modo che corrisponda alla struttura di directory richiesta da PyTorch Cartella immagine classe. Questo può essere fatto usando un semplice Script Python dopo che i dati sono stati copiati nel volume persistente nel passaggio successivo.

Per copiare i dati da un Servizio di archiviazione semplice Amazon (Amazon S3) nel file system FSx, creiamo un'immagine Docker che include script per questa attività. Un esempio di Dockerfile e uno script di shell sono inclusi in csi cartella all'interno del repository GitHub. Possiamo costruire l'immagine usando il build.sh script e quindi invialo ad Amazon ECR utilizzando il file push.sh sceneggiatura. Prima di utilizzare questi script, è necessario fornire l'URI corretto per il repository ECR nel file .env file nella cartella principale del repository GitHub. Dopo aver inviato l'immagine Docker ad Amazon ECR, possiamo avviare un pod per copiare i dati applicando il file .yaml pertinente:

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

Il pod esegue automaticamente lo script data-prep.sh per copiare i dati da Amazon S3 al volume condiviso. Poiché i dati di ImageNet contengono più di 12 milioni di file, il processo di copia richiede un paio d'ore. Lo script Python imagenet_data_prep.py viene anche eseguito per riorganizzare il val set di dati come previsto da PyTorch.

Accelerazione di rete

Possiamo utilizzare Elastic Fabric Adapter (EFA) in combinazione con tipi di istanza EC2 supportati per accelerare il traffico di rete tra i nodi GPU nel tuo cluster. Ciò può essere utile quando si eseguono grandi lavori di formazione distribuiti in cui la comunicazione di rete standard può rappresentare un collo di bottiglia. Gli script per distribuire e testare il plug-in del dispositivo EFA nel cluster EKS che utilizziamo qui sono inclusi nel file plug-in-dispositivo efa cartella nel repository GitHub. Per abilitare un lavoro con EFA nel tuo cluster EKS, oltre ai nodi del cluster che dispongono dell'hardware e del software necessari, il plug-in del dispositivo EFA deve essere distribuito nel cluster e il tuo contenitore di lavoro deve avere CUDA e NCCL compatibili versioni installato.

Per dimostrare l'esecuzione dei test NCCL e la valutazione delle prestazioni di EFA su istanze p4d.24xlarge, dobbiamo prima distribuire l'operatore Kubeflow MPI eseguendo il corrispondente distribuire.sh script in mpi-operatore cartella. Quindi eseguiamo il distribuire.sh script e aggiornare il prova-efa-nccl.yaml manifestare quindi limiti e richieste di risorse vpc.amazonaws.com sono impostati su 4. I quattro adattatori EFA disponibili nei nodi p4d.24xlarge vengono raggruppati insieme per fornire il massimo throughput.

Correre kubectl apply -f ./test-efa-nccl.yaml per applicare il test e quindi visualizzare i log del test pod. La riga seguente nell'output del registro conferma che l'EFA è in uso:

NCCL INFO NET/OFI Selected Provider is efa

I risultati del test dovrebbero essere simili al seguente output:

[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

Possiamo osservare nei risultati del test che il throughput massimo è di circa 42 GB/sec e la larghezza di banda media del bus è di circa 8 GB.

Abbiamo anche condotto esperimenti con un singolo adattatore EFA abilitato e nessun adattatore EFA. Tutti i risultati sono riassunti nella tabella seguente.

Abbiamo anche scoperto che per modelli relativamente piccoli come ImageNet, l'uso della rete accelerata riduce il tempo di addestramento per epoca solo del 5–8% a una dimensione batch di 64. Per modelli più grandi e dimensioni batch più piccole, quando è necessaria una maggiore comunicazione di rete dei pesi , l'uso della rete accelerata ha un impatto maggiore. Abbiamo osservato una diminuzione del tempo di addestramento dell'epoca del 15–18% per l'addestramento di EfficientNet-B7 con dimensione batch 1. L'impatto effettivo di EFA sull'addestramento dipenderà dalle dimensioni del modello.

Monitoraggio GPU

Prima di eseguire il lavoro di formazione, possiamo anche impostare Amazon Cloud Watch metriche per visualizzare l'utilizzo della GPU durante l'addestramento. Può essere utile sapere se le risorse vengono utilizzate in modo ottimale o identificare potenzialmente la carenza di risorse e i colli di bottiglia nel processo di formazione.

Gli script pertinenti per configurare CloudWatch si trovano in gpu-metriche cartella. Innanzitutto, creiamo un'immagine Docker con amazon-cloudwatch-agent ed nvidia-smi. Possiamo usare il Dockerfile nel file gpu-metrics cartella per creare questa immagine. Supponendo che il registro ECR sia già impostato nel .env file del passaggio precedente, possiamo creare e inviare l'immagine utilizzando build.sh ed push.sh. Dopodiché, eseguendo il deploy.sh lo script completa automaticamente l'installazione. Lancia un daemonset con amazon-cloudwatch-agent e invia vari parametri a CloudWatch. Le metriche della GPU vengono visualizzate sotto il CWAgent spazio dei nomi sulla console CloudWatch. Il resto delle metriche del cluster viene visualizzato sotto il ContainerInsights spazio dei nomi.

Allenamento modello

Tutti gli script necessari per l'addestramento di PyTorch si trovano nel file lavoro elastico cartella nel repository GitHub. Prima di avviare il lavoro di formazione, è necessario eseguire il etcd server, utilizzato dal TEC per il rilevamento dei dipendenti e lo scambio di parametri. Il distribuire.sh script in elasticjob cartella fa esattamente questo.

Per sfruttare l'EFA nelle istanze p4d.24xlarge, è necessario utilizzare un'immagine Docker specifica disponibile nel Galleria pubblica Amazon ECR che supporta la comunicazione NCCL tramite EFA. Dobbiamo solo copiare il nostro codice di formazione in questa immagine Docker. Il Dockerfile sotto il campioni cartella crea un'immagine da utilizzare durante l'esecuzione del processo di formazione su istanze p4d. Come sempre, possiamo usare il costruire.sh ed spingere.sh script nella cartella per creare e inviare l'immagine.

I imagenet-efa.yaml file descrive il lavoro di formazione. Questo file .yaml imposta le risorse necessarie per l'esecuzione del processo di addestramento e monta anche il volume persistente con i dati di addestramento impostati nella sezione precedente.

Vale la pena sottolineare un paio di cose qui. Il numero di repliche deve essere impostato sul numero di nodi disponibili nel cluster. Nel nostro caso, lo abbiamo impostato su 3 perché avevamo tre nodi p4d.24xlarge. Nel imagenet-efa.yaml file, il nvidia.com/gpu parametro in risorse e nproc_per_node per args dovrebbe essere impostato sul numero di GPU per nodo, che nel caso di p4d.24xlarge è 8. Inoltre, l'argomento worker per lo script Python imposta il numero di CPU per processo. Abbiamo scelto che fosse 4 perché, nei nostri esperimenti, fornisce prestazioni ottimali durante l'esecuzione su istanze p4d.24xlarge. Queste impostazioni sono necessarie per massimizzare l'utilizzo di tutte le risorse hardware disponibili nel cluster.

Quando il lavoro è in esecuzione, possiamo osservare l'utilizzo della GPU in CloudWatch per tutte le GPU nel cluster. Quello che segue è un esempio di uno dei nostri lavori di addestramento con tre nodi p4d.24xlarge nel cluster. Qui abbiamo selezionato una GPU da ciascun nodo. Con le impostazioni menzionate in precedenza, l'utilizzo della GPU è vicino al 100% durante la fase di training dell'epoca per tutti i nodi del cluster.

Per addestrare un modello ResNet50 utilizzando istanze p3.8xlarge, abbiamo bisogno esattamente degli stessi passaggi descritti per il training EfficientNet usando p4d.24xlarge. Possiamo anche usare la stessa immagine Docker. Come accennato in precedenza, le istanze p3.8xlarge non sono dotate di EFA. Tuttavia, per il modello ResNet50, questo non è uno svantaggio significativo. Il imagenet-fsx.yaml lo script fornito nel repository GitHub configura il lavoro di training con risorse appropriate per il tipo di nodo p3.8xlarge. Il lavoro utilizza lo stesso set di dati dal file system FSx.

Ridimensionamento della GPU

Abbiamo eseguito alcuni esperimenti per osservare come scala i tempi di addestramento per il modello EfficientNet-B7 aumentando il numero di GPU. A tale scopo, abbiamo modificato il numero di repliche da 1 a 3 nel file .yaml di addestramento per ogni esecuzione di addestramento. Abbiamo osservato solo il tempo per una singola epoca durante l'utilizzo del set di dati ImageNet completo. La figura seguente mostra i risultati del nostro esperimento di ridimensionamento della GPU. La linea tratteggiata rossa rappresenta il modo in cui il tempo di allenamento dovrebbe diminuire da una corsa che utilizza 8 GPU aumentando il numero di GPU. Come possiamo vedere, il ridimensionamento è abbastanza vicino a quanto previsto.

Allo stesso modo, abbiamo ottenuto il grafico di ridimensionamento della GPU per l'addestramento di ResNet50 su istanze p3.8xlarge. In questo caso, abbiamo modificato le repliche nel nostro file .yaml da 1 a 4. I risultati di questo esperimento sono mostrati nella figura seguente.

ripulire

È importante ridurre le risorse dopo l'addestramento del modello per evitare i costi associati all'esecuzione di istanze inattive. Con ogni script che crea risorse, il file Repository GitHub fornisce uno script corrispondente per eliminarli. Per ripulire la nostra configurazione, dobbiamo eliminare il file system FSx prima di eliminare il cluster perché è associato a una sottorete nel VPC del cluster. Per eliminare il file system FSx, dobbiamo solo eseguire il seguente comando (dall'interno del file fsx cartella):

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

Nota che questo non solo eliminerà il volume persistente, ma eliminerà anche il file system FSx e tutti i dati sul file system andranno persi. Al termine di questo passaggio, è possibile eliminare il cluster utilizzando il seguente script nel file eks cartella:

./eks-delete.sh

Questo eliminerà tutti i pod esistenti, rimuoverà il cluster ed eliminerà il VPC creato all'inizio.

Conclusione

In questo post, abbiamo descritto in dettaglio i passaggi necessari per eseguire l'addestramento del modello parallelo di dati distribuiti PyTorch sui cluster EKS. Questo compito può sembrare scoraggiante, ma il AWS DevOps per EKS il progetto creato dal team ML Frameworks di AWS fornisce tutti gli script e gli strumenti necessari per semplificare il processo e rendere facilmente accessibile il training del modello distribuito.

Per ulteriori informazioni sulle tecnologie utilizzate in questo post, visitare Amazon EX ed Elastico distribuito a torcia. Ti invitiamo ad applicare l'approccio qui descritto ai tuoi casi d'uso di formazione distribuita.

Risorse

Circa gli autori

Imran Yunus è un Principal Solutions Architect per il team ML Frameworks di AWS. Si concentra su carichi di lavoro di machine learning e deep learning su larga scala nei servizi AWS come Amazon EKS e AWS ParallelCluster. Ha una vasta esperienza nelle applicazioni di Deep Leaning in Computer Vision e Industrial IoT. Imran ha conseguito il dottorato di ricerca in Fisica delle particelle delle alte energie, dove è stato coinvolto nell'analisi di dati sperimentali su scale peta-byte.

Alex Iankoulski è un software completo e un architetto di infrastrutture a cui piace fare un lavoro approfondito e pratico. Attualmente è Principal Solutions Architect per l'apprendimento automatico autogestito presso AWS. Nel suo ruolo si concentra sull'aiutare i clienti con la containerizzazione e l'orchestrazione di carichi di lavoro ML e AI su servizi AWS basati su container. È anche l'autore dell'open source Fai quadro e un capitano Docker che ama applicare le tecnologie dei container per accelerare il ritmo dell'innovazione mentre risolve le sfide più grandi del mondo. Negli ultimi 10 anni, Alex ha lavorato per combattere il cambiamento climatico, democratizzare l'IA e il machine learning, rendere i viaggi più sicuri, l'assistenza sanitaria migliore e l'energia più intelligente.