Crea architetture di formazione distribuite flessibili e scalabili utilizzando Kubeflow su AWS e Amazon SageMaker

In questo post, dimostriamo come Kubeflow su AWS (una distribuzione di Kubeflow specifica per AWS) utilizzata con Contenitori per l'apprendimento profondo AWS ed File system elastico Amazon (Amazon EFS) semplifica la collaborazione e offre flessibilità nella formazione di modelli di deep learning su larga scala su entrambi Servizio Amazon Elastic Kubernetes (Amazon EKS) e Amazon Sage Maker utilizzando un approccio di architettura ibrida.

Lo sviluppo dell'apprendimento automatico (ML) si basa su framework e toolkit open source complessi e in continua evoluzione, nonché su ecosistemi hardware complessi e in continua evoluzione. Ciò rappresenta una sfida quando si scala lo sviluppo di ML in un cluster. I container offrono una soluzione, perché possono incapsulare completamente non solo il codice di addestramento, ma l'intero stack delle dipendenze fino alle librerie hardware. Ciò garantisce un ambiente ML coerente e portabile e facilita la riproducibilità dell'ambiente di formazione su ogni singolo nodo del cluster di formazione.

Kubernetes è un sistema ampiamente adottato per automatizzare la distribuzione dell'infrastruttura, il ridimensionamento delle risorse e la gestione di queste applicazioni containerizzate. Tuttavia, Kubernetes non è stato creato pensando al ML, quindi può sembrare controintuitivo per i data scientist a causa della sua forte dipendenza dai file delle specifiche YAML. Non esiste un'esperienza Jupyter e non ci sono molte funzionalità specifiche di ML, come la gestione del flusso di lavoro e le pipeline, e altre funzionalità che gli esperti di ML si aspettano, come l'ottimizzazione degli iperparametri, l'hosting di modelli e altre. Tali capacità possono essere costruite, ma Kubernetes non è stato progettato per fare questo come obiettivo principale.

La comunità open source se ne accorse e sviluppò uno strato sopra Kubernetes chiamato Kubeflow. Kubeflow mira a rendere l'implementazione di flussi di lavoro ML end-to-end su Kubernetes semplice, portatile e scalabile. Puoi utilizzare Kubeflow per distribuire i migliori sistemi open source per ML in diverse infrastrutture.

Kubeflow e Kubernetes offrono flessibilità e controllo ai team di data scientist. Tuttavia, è ancora difficile garantire un utilizzo elevato dei cluster di formazione eseguiti su larga scala con costi operativi ridotti.

Questo post mostra come i clienti che hanno restrizioni locali o investimenti Kubernetes esistenti possono affrontare questa sfida utilizzando Amazon EKS e Kubeflow su AWS per implementare una pipeline ML per la formazione distribuita basata su un approccio autogestito e utilizzare SageMaker completamente gestito per un infrastruttura di formazione ottimizzata in termini di costi, completamente gestita e su scala di produzione. Ciò include l'implementazione passo passo di un'architettura di formazione ibrida distribuita che consente di scegliere tra i due approcci in fase di esecuzione, conferendo il massimo controllo e flessibilità con le esigenze rigorose per le implementazioni. Vedrai come puoi continuare a utilizzare le librerie open source nel tuo script di formazione di deep learning e renderlo compatibile per essere eseguito sia su Kubernetes che su SageMaker in modo indipendente dalla piattaforma.

In che modo Kubeflow su AWS e SageMaker aiuta?

I modelli di rete neurale costruiti con framework di deep learning come TensorFlow, PyTorch, MXNet e altri forniscono una precisione molto maggiore utilizzando set di dati di addestramento significativamente più grandi, specialmente nei casi d'uso di visione artificiale e elaborazione del linguaggio naturale. Tuttavia, con set di dati di addestramento di grandi dimensioni, l'addestramento dei modelli di deep learning richiede più tempo, il che alla fine rallenta il time-to-market. Se potessimo ridimensionare un cluster e ridurre il tempo di formazione del modello da settimane a giorni o ore, ciò potrebbe avere un enorme impatto sulla produttività e sulla velocità aziendale.

Amazon EKS aiuta il provisioning del piano di controllo Kubernetes gestito. Puoi utilizzare Amazon EKS per creare cluster di formazione su larga scala con istanze CPU e GPU e utilizzare il toolkit Kubeflow per fornire strumenti open source compatibili con il ML e rendere operativi flussi di lavoro ML portabili e scalabili utilizzando Kubeflow Pipelines per migliorare la produttività del tuo team e ridurre il time to market.

Tuttavia, potrebbero esserci un paio di sfide con questo approccio:

• Garantire il massimo utilizzo di un cluster tra i team di data science. Ad esempio, è necessario eseguire il provisioning di istanze GPU su richiesta e garantirne l'utilizzo elevato per attività impegnative su scala di produzione come il training di deep learning e utilizzare le istanze CPU per attività meno impegnative come la preelaborazione dei dati
• Garantire l'elevata disponibilità dei componenti dell'infrastruttura Kubeflow pesanti, inclusi database, archiviazione e autenticazione, che vengono distribuiti nel nodo di lavoro del cluster Kubernetes. Ad esempio, il piano di controllo Kubeflow genera artefatti (come istanze MySQL, pod log o storage MinIO) che crescono nel tempo e richiedono volumi di storage ridimensionabili con funzionalità di monitoraggio continuo.
• La condivisione del set di dati di addestramento, del codice e degli ambienti di elaborazione tra sviluppatori, cluster di addestramento e progetti è impegnativa. Ad esempio, se stai lavorando sul tuo set di librerie e quelle librerie hanno forti interdipendenze, diventa davvero difficile condividere ed eseguire lo stesso pezzo di codice tra data scientist nello stesso team. Inoltre, ogni esecuzione di addestramento richiede il download del set di dati di addestramento e la creazione dell'immagine di addestramento con nuove modifiche al codice.

Kubeflow su AWS aiuta ad affrontare queste sfide e fornisce un prodotto Kubeflow semi-gestito di livello aziendale. Con Kubeflow su AWS, puoi sostituire alcuni servizi del piano di controllo Kubeflow come database, storage, monitoraggio e gestione degli utenti con servizi gestiti da AWS come Servizio di database relazionale Amazon (AmazonRDS), Servizio di archiviazione semplice Amazon (Amazon S3), File system elastico Amazon (EFS di Amazon), AmazonFSx, Amazon Cloud Watche Amazzonia Cognito.

La sostituzione di questi componenti Kubeflow disaccoppia le parti critiche del piano di controllo Kubeflow da Kubernetes, fornendo un design sicuro, scalabile, resiliente e con costi ottimizzati. Questo approccio libera anche risorse di archiviazione e di calcolo dal piano dati EKS, che potrebbero essere necessarie per applicazioni come il training di modelli distribuiti o i server notebook degli utenti. Kubeflow su AWS fornisce anche l'integrazione nativa dei notebook Jupyter con le immagini Deep Learning Container (DLC), che sono preconfezionate e preconfigurate con framework di deep learning ottimizzati per AWS come PyTorch e TensorFlow che ti consentono di iniziare subito a scrivere il codice di addestramento senza occuparti con risoluzioni delle dipendenze e ottimizzazioni del framework. Inoltre, l'integrazione di Amazon EFS con i cluster di addestramento e l'ambiente di sviluppo consente di condividere il codice e il set di dati di addestramento elaborato, evitando di creare l'immagine del container e di caricare enormi set di dati dopo ogni modifica del codice. Queste integrazioni con Kubeflow su AWS ti aiutano ad accelerare la creazione del modello e i tempi di addestramento e consentono una migliore collaborazione con una condivisione più semplice di dati e codice.

Kubeflow su AWS aiuta a creare una piattaforma ML altamente disponibile e robusta. Questa piattaforma offre flessibilità per creare e addestrare modelli di deep learning e fornisce accesso a molti toolkit open source, approfondimenti sui log e debug interattivo per la sperimentazione. Tuttavia, ottenere il massimo utilizzo delle risorse dell'infrastruttura durante l'addestramento di modelli di deep learning su centinaia di GPU comporta ancora molti costi operativi. Questo problema può essere risolto utilizzando SageMaker, che è un servizio completamente gestito progettato e ottimizzato per la gestione di cluster di formazione efficienti e con costi ottimizzati che vengono forniti solo quando richiesto, ridimensionati secondo necessità e si spengono automaticamente al completamento dei lavori, fornendo così quasi 100 % utilizzo delle risorse. Puoi integrare SageMaker con Kubeflow Pipelines utilizzando i componenti SageMaker gestiti. Ciò ti consente di rendere operativi i flussi di lavoro ML come parte delle pipeline Kubeflow, dove puoi utilizzare Kubernetes per la formazione locale e SageMaker per la formazione su scala di prodotto in un'architettura ibrida.

Panoramica della soluzione

L'architettura seguente descrive come utilizziamo Kubeflow Pipelines per creare e distribuire flussi di lavoro ML end-to-end portabili e scalabili per eseguire in modo condizionale training distribuito su Kubernetes utilizzando Kubeflow training o SageMaker in base al parametro runtime.

Kubeflow training è un gruppo di operatori Kubernetes che aggiungono a Kubeflow il supporto per il training distribuito di modelli ML utilizzando diversi framework come TensorFlow, PyTorch e altri. pytorch-operator è l'implementazione Kubeflow di Kubernetes risorsa personalizzata (PyTorchJob) per eseguire lavori di formazione PyTorch distribuiti su Kubernetes.

Usiamo il componente PyTorchJob Launcher come parte della pipeline Kubeflow per eseguire il training distribuito PyTorch durante la fase di sperimentazione quando abbiamo bisogno di flessibilità e accesso a tutte le risorse sottostanti per il debug e l'analisi interattivi.

Utilizziamo anche i componenti SageMaker per le condutture Kubeflow per eseguire la nostra formazione sui modelli su scala di produzione. Ciò ci consente di sfruttare le potenti funzionalità di SageMaker come servizi completamente gestiti, lavori di formazione distribuiti con il massimo utilizzo della GPU e formazione conveniente tramite Cloud di calcolo elastico di Amazon (Amazon EC2) Istanze Spot.

Come parte del processo di creazione del flusso di lavoro, completa i seguenti passaggi (come mostrato nel diagramma precedente) per creare questa pipeline:

1. Usa il file manifest Kubeflow per creare un dashboard Kubeflow e accedere ai notebook Jupyter dal dashboard centrale Kubeflow.
2. Usa l'SDK della pipeline Kubeflow per creare e compilare pipeline Kubeflow usando il codice Python. La compilazione della pipeline converte la funzione Python in una risorsa del flusso di lavoro, che è un formato YAML compatibile con Argo.
3. Usa il client Kubeflow Pipelines SDK per chiamare l'endpoint del servizio pipeline per eseguire la pipeline.
4. La pipeline valuta le variabili di runtime condizionali e decide tra SageMaker o Kubernetes come ambiente di esecuzione di destinazione.
5. Utilizza il componente Kubeflow PyTorch Launcher per eseguire la formazione distribuita nell'ambiente Kubernetes nativo oppure utilizza il componente SageMaker per inviare la formazione sulla piattaforma gestita da SageMaker.

La figura seguente mostra i componenti di Kubeflow Pipelines coinvolti nell'architettura che ci danno la flessibilità di scegliere tra ambienti distribuiti Kubernetes o SageMaker.

Usa flusso di lavoro caso

Utilizziamo il seguente approccio passo passo per installare ed eseguire il caso d'uso per la formazione distribuita utilizzando Amazon EKS e SageMaker utilizzando Kubeflow su AWS.

Prerequisiti

Per questa procedura dettagliata, è necessario disporre dei seguenti prerequisiti:

• An Account AWS.
• Una macchina con Docker e il Interfaccia della riga di comando di AWS (AWS CLI) installato.
• Facoltativamente, puoi usare AWS Cloud9, un ambiente di sviluppo integrato (IDE) basato su cloud che consente di completare tutto il lavoro dal tuo browser web. Per le istruzioni di configurazione, fare riferimento a Configura Cloud9 IDE. Dal tuo ambiente Cloud9, scegli il segno più e apri un nuovo terminale.
• Crea un ruolo con il nome sagemakerrole. Aggiungi criteri gestiti AmazonSageMakerFullAccess ed AmazonS3FullAccess per consentire a SageMaker di accedere ai bucket S3. Questo ruolo viene utilizzato dal lavoro SageMaker inviato come parte del passaggio Kubeflow Pipelines.
• Assicurati che il tuo account abbia un limite per il tipo di risorsa di formazione SageMaker ml.p3.2xlarge aumentato a 2 usando Console delle quote di servizio

1. Installa Amazon EKS e Kubeflow su AWS

Puoi utilizzare diversi approcci per creare un cluster Kubernetes e distribuire Kubeflow. In questo post, ci concentriamo su un approccio che riteniamo porti semplicità al processo. Innanzitutto, creiamo un cluster EKS, quindi distribuiamo Kubeflow su AWS v1.5 su di esso. Per ciascuna di queste attività, utilizziamo un corrispondente progetto open source che segue i principi del Fai quadro. Anziché installare una serie di prerequisiti per ogni attività, creiamo container Docker che dispongono di tutti gli strumenti necessari ed eseguiamo le attività dall'interno dei container.

In questo post utilizziamo il Do Framework, che automatizza la distribuzione di Kubeflow con Amazon EFS come componente aggiuntivo. Per le opzioni di distribuzione ufficiali di Kubeflow su AWS per le distribuzioni di produzione, fare riferimento a Distribuzione.

Configura la directory di lavoro corrente e l'AWS CLI

Configuriamo una directory di lavoro in modo da poterla fare riferimento come punto di partenza per i passaggi che seguono:

export working_dir=$PWD

Configuriamo anche un profilo AWS CLI. Per fare ciò, è necessario un ID chiave di accesso e una chiave di accesso segreta di un Gestione dell'identità e dell'accesso di AWS (SONO) Utente account con privilegi di amministratore (allegare la policy gestita esistente) e accesso programmatico. Vedere il codice seguente:

aws configure --profile=kubeflow
AWS Access Key ID [None]: 
AWS Secret Access Key [None]: 
Default region name [None]: us-west-2
Default output format [None]: json

# (In Cloud9, select “Cancel” and “Permanently disable” when the AWS managed temporary credentials dialog pops up)

export AWS_PROFILE=kubeflow

1.1 Creare un cluster EKS

Se hai già un cluster EKS disponibile, puoi passare alla sezione successiva. Per questo post, utilizziamo il progetto aws-do-eks per creare il nostro cluster.

1. Per prima cosa clona il progetto nella tua directory di lavoro

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-eks
   cd aws-do-eks/

2. Quindi costruisci ed esegui il aws-do-eks contenitore:

   ./build.sh
   ./run.sh

   I build.sh script crea un'immagine del contenitore Docker che dispone di tutti gli strumenti e gli script necessari per il provisioning e il funzionamento dei cluster EKS. Il run.sh lo script avvia un contenitore utilizzando l'immagine Docker creata e la mantiene attiva, in modo da poterla utilizzare come ambiente di gestione EKS. Per vedere lo stato del tuo aws-do-eks contenitore, puoi eseguire ./status.sh. Se il contenitore è in stato Exited, puoi utilizzare il ./start.sh è possibile eseguire uno script per richiamare il contenitore o per riavviare il contenitore ./stop.sh seguito da ./run.sh.

3. Apri una shell in esecuzione aws-do-eks contenitore:
4. Per rivedere la configurazione del cluster EKS per la nostra distribuzione KubeFlow, esegui il comando seguente:

   vi ./eks-kubeflow.yaml

   Per impostazione predefinita, questa configurazione crea un cluster denominato eks-kubeflow nel us-west-2 Regione con sei nodi m5.xlarge. Inoltre, la crittografia dei volumi EBS non è abilitata per impostazione predefinita. Puoi abilitarlo aggiungendo "volumeEncrypted: true" al gruppo di nodi e crittograferà utilizzando la chiave predefinita. Modificare altre impostazioni di configurazione, se necessario.

5. Per creare il cluster, eseguire il comando seguente:

   export AWS_PROFILE=kubeflow
   eksctl create cluster -f ./eks-kubeflow.yaml

   Il processo di provisioning del cluster può richiedere fino a 30 minuti.

6. Per verificare che il cluster sia stato creato correttamente, eseguire il comando seguente:

   kubectl get nodes

   L'output del comando precedente per un cluster che è stato creato correttamente è simile al codice seguente:

   root@cdf4ecbebf62:/eks# kubectl get nodes
   NAME                                           STATUS   ROLES    AGE   VERSION
   ip-192-168-0-166.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-13-28.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-45-240.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-63-84.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-75-56.us-west-2.compute.internal    Ready       23m   v1.21.14-eks-ba74326
   ip-192-168-85-226.us-west-2.compute.internal   Ready       23m   v1.21.14-eks-ba74326

Crea un volume EFS per il lavoro di formazione SageMaker

In questo caso d'uso, acceleri il processo di addestramento di SageMaker addestrando modelli di deep learning dai dati già archiviati in Amazon EFS. Questa scelta ha il vantaggio di avviare direttamente i tuoi lavori di formazione dai dati in Amazon EFS senza che sia necessario spostare i dati, con conseguente tempi di inizio della formazione più rapidi.

Creiamo un volume EFS e distribuiamo il driver EFS Container Storage Interface (CSI). Ciò viene eseguito da uno script di distribuzione che si trova in /eks/deployment/csi/efs all'interno aws-do-eks contenitore.

Questo script presuppone che tu abbia un cluster EKS nel tuo account. Impostare CLUSTER_NAME= nel caso in cui tu abbia più di un cluster EKS.

cd /eks/deployment/csi/efs
./deploy.sh

Questo script effettua il provisioning di un volume EFS e crea destinazioni di montaggio per le sottoreti del cluster VPC. Quindi distribuisce il driver CSI EFS e crea il file efs-sc classe di archiviazione e efs-pv volume persistente nel cluster EKS.

Al completamento con successo dello script, dovresti vedere un output come il seguente:

Generating efs-sc.yaml ...

Applying efs-sc.yaml ...
storageclass.storage.k8s.io/efs-sc created
NAME            PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
efs-sc          efs.csi.aws.com         Delete          Immediate              false                  1s
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  36m

Generating efs-pv.yaml ...
Applying efs-pv.yaml ...
persistentvolume/efs-pv created
NAME     CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
efs-pv   5Gi        RWX            Retain           Available           efs-sc                  10s

Done ...

Crea un endpoint VPC Amazon S3

Utilizzi un VPC privato a cui hanno accesso il tuo lavoro di formazione SageMaker e il file system EFS. Per consentire al cluster di formazione SageMaker di accedere ai bucket S3 dal tuo VPC privato, crea un endpoint VPC:

cd /eks/vpc 
export CLUSTER_NAME= 
export REGION= 
./vpc-endpoint-create.sh

Ora puoi uscire da aws-do-eks guscio del contenitore e procedere alla sezione successiva:

exit

root@cdf4ecbebf62:/eks/deployment/csi/efs# exit
exit
TeamRole:~/environment/aws-do-eks (main) $

1.2 Distribuisci Kubeflow su AWS su Amazon EKS

Per distribuire Kubeflow su Amazon EKS, utilizziamo il progetto aws-do-kubeflow.

1. Clona il repository usando i seguenti comandi:

   cd ${working_dir}
   git clone https://github.com/aws-samples/aws-do-kubeflow
   cd aws-do-kubeflow

2. Quindi configura il progetto:

   ./config.sh

   Questo script apre il file di configurazione del progetto in un editor di testo. È importante per REGIONE_AWS da impostare sulla regione in cui si trova il tuo cluster, così come AWS_CLUSTER_NAME in modo che corrisponda al nome del cluster creato in precedenza. Per impostazione predefinita, la tua configurazione è già impostata correttamente, quindi se non hai bisogno di apportare modifiche, chiudi l'editor.

   ./build.sh
   ./run.sh
   ./exec.sh

   I build.sh script crea un'immagine del contenitore Docker che dispone di tutti gli strumenti necessari per distribuire e gestire Kubeflow su un cluster Kubernetes esistente. Il run.sh lo script avvia un contenitore, utilizzando l'immagine Docker, e lo script exec.sh apre una shell dei comandi nel contenitore, che possiamo utilizzare come ambiente di gestione Kubeflow. Puoi usare il ./status.sh script per vedere se il aws-do-kubeflow il contenitore è attivo e funzionante e il ./stop.sh ed ./run.sh script per riavviarlo secondo necessità.

3. Dopo aver aperto una shell nel file aws-do-eks container, è possibile verificare che il contesto del cluster configurato sia come previsto:

   root@ip-172-31-43-155:/kubeflow# kubectx
   kubeflow@eks-kubeflow.us-west-2.eksctl.io

4. Per distribuire Kubeflow nel cluster EKS, esegui il file deploy.sh sceneggiatura:

   ./kubeflow-deploy.sh

   La distribuzione ha esito positivo quando tutti i pod nello spazio dei nomi kubeflow entrano nello stato In esecuzione. Un output tipico è simile al codice seguente:

   Waiting for all Kubeflow pods to start Running ...
   
   Waiting for all Kubeflow pods to start Running ...
   
   Restarting central dashboard ...
   pod "centraldashboard-79f489b55-vr6lp" deleted
   /kubeflow/deploy/distro/aws/kubeflow-manifests /kubeflow/deploy/distro/aws
   /kubeflow/deploy/distro/aws
   
   Kubeflow deployment succeeded
   Granting cluster access to kubeflow profile user ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   clusterrolebinding.rbac.authorization.k8s.io/kubeflow-user-example-com-cluster-admin-binding created
   Setting up access to Kubeflow Pipelines ...
   Argument not provided, assuming default user namespace kubeflow-user-example-com ...
   
   Creating pod-default for namespace kubeflow-user-example-com ...
   poddefault.kubeflow.org/access-ml-pipeline created

5. Per monitorare lo stato dei pod KubeFlow, in una finestra separata, puoi utilizzare il comando seguente:

   watch kubectl -n kubeflow get pods

6. Rassegna Stampa Ctrl + C quando tutti i pod sono in esecuzione, esponi il dashboard Kubeflow all'esterno del cluster eseguendo il comando seguente:

   ./kubeflow-expose.sh

Dovresti vedere un output simile al seguente codice:

root@ip-172-31-43-155:/kubeflow# ./kubeflow-expose.sh
root@ip-172-31-43-155:/kubeflow# Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080

Questo comando inoltra il servizio gateway di ingresso Istio dal tuo cluster alla tua porta locale 8080. Per accedere al dashboard Kubeflow, visita http://localhost:8080 e accedi utilizzando le credenziali utente predefinite (utente@example.com/12341234). Se stai eseguendo il aws-do-kubeflow container in AWS Cloud9, quindi puoi scegliere Anteprima, Quindi scegliere Anteprima dell'applicazione in esecuzione. Se stai utilizzando Docker Desktop, potrebbe essere necessario eseguire il ./kubeflow-expose.sh sceneggiatura al di fuori del aws-do-kubeflow contenitore.

2. Configura Kubeflow nell'ambiente AWS

Per configurare il tuo Kubeflow in ambiente AWS, creiamo un volume EFS e un notebook Jupyter.

2.1 Creare un volume EFS

Per creare un volume EFS, completare i seguenti passaggi:

• Nella dashboard di Kubeflow, scegli Volumi nel pannello di navigazione.
• Ha scelto Nuovo volume.
• Nel Nome, accedere efs-sc-claim.
• Nel Dimensioni del volume, accedere 10.
• Nel Classe di archiviazionescegli efs-sc.
• Nel Modalità di accessoscegli LeggiScriviUna Volta.
• Scegli Creare.

2.2 Creare un taccuino Jupyter

Per creare un nuovo taccuino, completare i seguenti passaggi:

• Nella dashboard di Kubeflow, scegli Notebook nel pannello di navigazione.
• Scegli Nuovo taccuino.
• Nel Nome, accedere aws-hybrid-nb.
• Nel Immagine di Jupyter Docket, scegli l'immagine c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (l'ultima immagine disponibile del DLC jupyter-pytorch).
• Nel CPU, accedere 1.
• Nel Memorie, accedere 5.
• Nel GPU, lascia come Nessuna.
• Non apportare modifiche al Volume dell'area di lavoro .
• Nel Volumi di dati sezione, scegliere Allega volume esistente ed espandi la sezione Volume esistente
• Nel Nomescegli efs-sc-claim.
• Nel Monte sentiero, accedere /home/jovyan/efs-sc-claim.
  Questo monta il volume EFS sul tuo pod del notebook Jupyter e puoi vedere la cartella efs-sc-claim nell'interfaccia del tuo laboratorio Jupyter. Il set di dati di addestramento e il codice di addestramento vengono salvati in questa cartella in modo che i cluster di addestramento possano accedervi senza dover ricostruire le immagini del contenitore per il test.
• Seleziona Consenti l'accesso alle pipeline Kubeflow nella sezione Configurazione.
• Scegli Lancio.
  Verifica che il tuo taccuino sia stato creato correttamente (potrebbero essere necessari un paio di minuti).
• Sulla Notebook pagina, scegli Connettiti per accedere all'ambiente JupyterLab.
• Sulla Idiota menù, scegliere Clona un repository.
• Nel Clona un repository, accedere https://github.com/aws-samples/aws-do-kubeflow.
  

3. Eseguire la formazione distribuita

Dopo aver configurato il notebook Jupyter, puoi eseguire l'intera demo utilizzando i seguenti passaggi di alto livello dalla cartella aws-do-kubeflow/workshop nel repository clonato:

• Script di formazione PyTorch Distributed Data Parallel (DDP): Fare riferimento allo script di addestramento DDP di PyTorch cifar10-distributed-gpu-final.py, che include una rete neurale convoluzionale di esempio e una logica per distribuire l'addestramento su un cluster di CPU e GPU multinodo. (Fare riferimento a 3.1 per i dettagli)
• Installa le librerie: Esegui il taccuino 0_initialize_dependencies.ipynb per inizializzare tutte le dipendenze. (Fare riferimento a 3.2 per i dettagli)
• Esegui la formazione sul lavoro PyTorch distribuita su Kubernetes: Esegui il taccuino 1_submit_pytorchdist_k8s.ipynb per creare e inviare formazione distribuita su un container principale e due di lavoro utilizzando il file YAML PyTorchJob della risorsa personalizzata Kubernetes utilizzando il codice Python. (Fare riferimento a 3.3 per i dettagli)
• Crea una pipeline Kubeflow ibrida: Esegui il taccuino 2_create_pipeline_k8s_sagemaker.ipynb per creare la pipeline Kubeflow ibrida che esegue la formazione distribuita su SageMaker o Amazon EKS utilizzando la variabile di runtime training_runtime. (Fare riferimento a 3.4 per i dettagli)

Assicurati di aver eseguito il notebook 1_submit_pytorchdist_k8s.ipynb prima di iniziare il taccuino 2_create_pipeline_k8s_sagemaker.ipynb.

Nelle sezioni successive, discuteremo in dettaglio ciascuno di questi passaggi.

3.1 Script di formazione PyTorch Distributed Data Parallel (DDP).

Come parte del training distribuito, formiamo un modello di classificazione creato da una semplice rete neurale convoluzionale che opera sul set di dati CIFAR10. Il copione di formazione cifar10-distributed-gpu-final.py contiene solo le librerie open source ed è compatibile per l'esecuzione su entrambi i cluster di formazione Kubernetes e SageMaker su dispositivi GPU o istanze CPU. Diamo un'occhiata ad alcuni aspetti importanti dello script di formazione prima di eseguire i nostri esempi di notebook.

Usiamo il torch.distributed modulo, che contiene il supporto PyTorch e le primitive di comunicazione per il parallelismo multiprocesso tra i nodi del cluster:

...
import torch
import torch.distributed as dist
import torch.nn as nn
import torch.nn.functional as F
import torch.optim as optim
import torch.utils.data
import torch.utils.data.distributed
import torchvision
from torchvision import datasets, transforms
...

Creiamo un semplice modello di classificazione delle immagini utilizzando una combinazione di livelli convoluzionali, max pooling e lineari a cui viene applicata una funzione di attivazione relu nel passaggio in avanti del training del modello:

# Define models
class Net(nn.Module):
def __init__(self):
super(Net, self).__init__()
self.conv1 = nn.Conv2d(3, 6, 5)
self.pool = nn.MaxPool2d(2, 2)
self.conv2 = nn.Conv2d(6, 16, 5)
self.fc1 = nn.Linear(16 * 5 * 5, 120)
self.fc2 = nn.Linear(120, 84)
self.fc3 = nn.Linear(84, 10)

def forward(self, x):
x = self.pool(F.relu(self.conv1(x)))
x = self.pool(F.relu(self.conv2(x)))
x = x.view(-1, 16 * 5 * 5)
x = F.relu(self.fc1(x))
x = F.relu(self.fc2(x))
x = self.fc3(x)
return x

Utilizziamo la torcia DataLoader che combina il set di dati e DistributedSampler (carica un sottoinsieme di dati in modo distribuito utilizzando torch.nn.parallel.DistributedDataParallel) e fornisce un iteratore a processo singolo o multiprocesso sui dati:

# Define data loader for training dataset
def _get_train_data_loader(batch_size, training_dir, is_distributed):
logger.info("Get train data loader")

train_set = torchvision.datasets.CIFAR10(root=training_dir,
train=True,
download=False,
transform=_get_transforms())

train_sampler = (
torch.utils.data.distributed.DistributedSampler(train_set) if is_distributed else None
)

return torch.utils.data.DataLoader(
train_set,
batch_size=batch_size,
shuffle=train_sampler is None,
sampler=train_sampler)
...

Se il cluster di formazione dispone di GPU, lo script esegue il training sui dispositivi CUDA e la variabile del dispositivo contiene il dispositivo CUDA predefinito:

device = "cuda" if torch.cuda.is_available() else "cpu"
...

Prima di eseguire la formazione distribuita utilizzando PyTorch DistributedDataParallel per eseguire l'elaborazione distribuita su più nodi, è necessario inizializzare l'ambiente distribuito chiamando init_process_group. Viene inizializzato su ogni macchina del cluster di addestramento.

dist.init_process_group(backend=args.backend, rank=host_rank, world_size=world_size)
...

Istanziamo il modello classificatore e copiamo il modello sul dispositivo di destinazione. Se la formazione distribuita è abilitata per l'esecuzione su più nodi, il DistributedDataParallel class viene utilizzata come oggetto wrapper attorno all'oggetto modello, che consente l'addestramento distribuito sincrono su più macchine. I dati di input vengono suddivisi sulla dimensione batch e una replica del modello viene posizionata su ciascuna macchina e ciascun dispositivo.

model = Net().to(device)

if is_distributed:
model = torch.nn.parallel.DistributedDataParallel(model)

...

3.2 Installare le librerie

Installerai tutte le librerie necessarie per eseguire l'esempio di formazione distribuito PyTorch. Ciò include Kubeflow Pipelines SDK, Training Operator Python SDK, client Python per Kubernetes e Amazon SageMaker Python SDK.

#Please run the below commands to install necessary libraries

!pip install kfp==1.8.4

!pip install kubeflow-training

!pip install kubernetes

!pip install sagemaker

3.3 Esegui la formazione sul lavoro PyTorch distribuita su Kubernetes

Il notebook 1_submit_pytorchdist_k8s.ipynb crea il file YAML PyTorchJob della risorsa personalizzata Kubernetes utilizzando il training Kubeflow e l'SDK Python del client Kubernetes. Di seguito sono riportati alcuni frammenti importanti di questo taccuino.

Creiamo il PyTorchJob YAML con i container primari e di lavoro come mostrato nel codice seguente:

# Define PyTorchJob custom resource manifest
pytorchjob = V1PyTorchJob(
api_version="kubeflow.org/v1",
kind="PyTorchJob",
metadata=V1ObjectMeta(name=pytorch_distributed_jobname,namespace=user_namespace),
spec=V1PyTorchJobSpec(
run_policy=V1RunPolicy(clean_pod_policy="None"),
pytorch_replica_specs={"Master": master,
"Worker": worker}
)
)

Questo viene inviato al piano di controllo di Kubernetes utilizzando PyTorchJobClient:

# Creates and Submits PyTorchJob custom resource file to Kubernetes
pytorchjob_client = PyTorchJobClient()

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Visualizza i registri di formazione Kubernetes

Puoi visualizzare i registri di formazione dallo stesso notebook Jupyter utilizzando il codice Python o dalla shell del client Kubernetes.

3.4 Creare una pipeline Kubeflow ibrida

Il notebook 2_create_pipeline_k8s_sagemaker.ipynb crea una pipeline Kubeflow ibrida basata su una variabile di runtime condizionale training_runtime, come mostrato nel codice seguente. Il taccuino utilizza il SDK delle pipeline Kubeflow e viene fornito un set di pacchetti Python per specificare ed eseguire le pipeline del flusso di lavoro ML. Come parte di questo SDK, utilizziamo i seguenti pacchetti:

• Il decoratore di pacchetti DSL (Domain-Specific Language). dsl.pipeline, che decora le funzioni Python per restituire una pipeline
• I dsl.Condition pacchetto, che rappresenta un gruppo di operazioni che vengono eseguite solo quando viene soddisfatta una determinata condizione, come il controllo di training_runtime valore come sagemaker or kubernetes

Vedi il seguente codice:

# Define your training runtime value with either 'sagemaker' or 'kubernetes'
training_runtime='sagemaker'

# Create Hybrid Pipeline using Kubeflow PyTorch Training Operators and Amazon SageMaker Service
@dsl.pipeline(name="PyTorch Training pipeline", description="Sample training job test")
def pytorch_cnn_pipeline():

# Pipeline Step 1: to evaluate the condition. You can enter any logic here. For demonstration we are checking if GPU is needed for training
condition_result = check_condition_op(training_runtime)

# Pipeline Step 2: to run training on Kuberentes using PyTorch Training Operators. This will be executed if gpus are not needed
with dsl.Condition(condition_result.output == 'kubernetes', name="PyTorch_Comp"):
train_task = pytorch_job_op(
name=training_job_name,
namespace=user_namespace,
master_spec=json.dumps(master_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_master_spec.yml
worker_spec=json.dumps(worker_spec_loaded), # Please refer file at pipeline_yaml_specifications/pipeline_worker_spec.yml
delete_after_done=False
).after(condition_result)

# Pipeline Step 3: to run training on SageMaker using SageMaker Components for Pipeline. This will be executed if gpus are needed
with dsl.Condition(condition_result.output == 'sagemaker', name="SageMaker_Comp"):
training = sagemaker_train_op(
region=region,
image=train_image,
job_name=training_job_name,
training_input_mode=training_input_mode,
hyperparameters='{ 
"backend": "'+str(pytorch_backend)+'", 
"batch-size": "64", 
"epochs": "3", 
"lr": "'+str(learning_rate)+'", 
"model-type": "custom", 
"sagemaker_container_log_level": "20", 
"sagemaker_program": "cifar10-distributed-gpu-final.py", 
"sagemaker_region": "us-west-2", 
"sagemaker_submit_directory": "'+source_s3+'" 
}',
channels=channels,
instance_type=instance_type,
instance_count=instance_count,
volume_size=volume_size,
max_run_time=max_run_time,
model_artifact_path=f's3://{bucket_name}/jobs',
network_isolation=network_isolation,
traffic_encryption=traffic_encryption,
role=role,
vpc_subnets=subnet_id,
vpc_security_group_ids=security_group_id
).after(condition_result)

Configuriamo la formazione distribuita SageMaker utilizzando due istanze ml.p3.2xlarge.

Dopo che la pipeline è stata definita, puoi compilare la pipeline in base a una specifica Argo YAML utilizzando l'SDK di Kubeflow Pipelines kfp.compiler pacchetto. Puoi eseguire questa pipeline utilizzando il client Kubeflow Pipeline SDK, che chiama l'endpoint del servizio Pipelines e passa le intestazioni di autenticazione appropriate direttamente dal notebook. Vedere il codice seguente:

# DSL Compiler that compiles pipeline functions into workflow yaml.
kfp.compiler.Compiler().compile(pytorch_cnn_pipeline, "pytorch_cnn_pipeline.yaml")

# Connect to Kubeflow Pipelines using the Kubeflow Pipelines SDK client
client = kfp.Client()

experiment = client.create_experiment(name="kubeflow")

# Run a specified pipeline
my_run = client.run_pipeline(experiment.id, "pytorch_cnn_pipeline", "pytorch_cnn_pipeline.yaml")

# Please click “Run details” link generated below this cell to view your pipeline. You can click every pipeline step to see logs.

Se ottieni un file sagemaker import errore, eseguire !pip install sagemaker e riavviare il kernel (sul file nocciolo menù, scegliere Riavvia il kernel).

Scegliere il Dettagli dell'esecuzione collegamento sotto l'ultima cella per visualizzare la pipeline Kubeflow.

Ripetere il passaggio di creazione della pipeline con training_runtime='kubernetes' per testare l'esecuzione della pipeline in un ambiente Kubernetes. Il training_runtime la variabile può anche essere passata nella pipeline CI/CD in uno scenario di produzione.

Visualizza i log di esecuzione della pipeline Kubeflow per il componente SageMaker

Lo screenshot seguente mostra i dettagli della nostra pipeline per il componente SageMaker.

Scegli la fase del lavoro di formazione e sul Registri scheda, scegli il collegamento ai log di CloudWatch per accedere ai log di SageMaker.

Lo screenshot seguente mostra i log di CloudWatch per ciascuna delle due istanze ml.p3.2xlarge.

Scegli uno dei gruppi per vedere i log.

Visualizza i log di esecuzione della pipeline Kubeflow per il componente Kubeflow PyTorchJob Launcher

Lo screenshot seguente mostra i dettagli della pipeline per il nostro componente Kubeflow.

Esegui i seguenti comandi usando Kubectl sulla shell del tuo client Kubernetes connesso al cluster Kubernetes per vedere i log (sostituisci il tuo spazio dei nomi e i nomi dei pod):

kubectl get pods -n kubeflow-user-example-com
kubectl logs  -n kubeflow-user-example-com -f

4.1 Ripulire

Per ripulire tutte le risorse che abbiamo creato nell'account, dobbiamo rimuoverle in ordine inverso.

1. Elimina l'installazione di Kubeflow eseguendo ./kubeflow-remove.sh nel aws-do-kubeflow contenitore. Il primo set di comandi è facoltativo e può essere utilizzato nel caso in cui non si disponga già di una shell dei comandi nel proprio aws-do-kubeflow contenitore aperto.

   cd aws-do-kubeflow
   ./status.sh
   ./start.sh
   ./exec.sh
   
   ./kubeflow-remove.sh

2. Dal aws-do-eks cartella contenitore, rimuovere il volume EFS. Il primo set di comandi è facoltativo e può essere utilizzato nel caso in cui non si disponga già di una shell dei comandi nel proprio aws-do-eks contenitore aperto.

   cd aws-do-eks
   ./status.sh
   ./start.sh
   ./exec.sh
   
   cd /eks/deployment/csi/efs
   ./delete.sh
   ./efs-delete.sh

   L'eliminazione di Amazon EFS è necessaria per rilasciare l'interfaccia di rete associata al VPC che abbiamo creato per il nostro cluster. Si noti che l'eliminazione del volume EFS distrugge tutti i dati archiviati su di esso.

3. Dal aws-do-eks contenitore, eseguire il eks-delete.sh script per eliminare il cluster e qualsiasi altra risorsa ad esso associata, incluso il VPC:

   cd /eks
   ./eks-delete.sh

Sommario

In questo post, abbiamo discusso alcune delle sfide tipiche dell'addestramento di modelli distribuiti e dei flussi di lavoro ML. Abbiamo fornito una panoramica della distribuzione Kubeflow su AWS e condiviso due progetti open source (aws-do-eks ed aws-do-kubeflow) che semplificano il provisioning dell'infrastruttura e la distribuzione di Kubeflow su di essa. Infine, abbiamo descritto e dimostrato un'architettura ibrida che consente ai carichi di lavoro di passare senza interruzioni dall'esecuzione su un Kubernetes autogestito a un'infrastruttura SageMaker completamente gestita. Ti invitiamo a utilizzare questa architettura ibrida per i tuoi casi d'uso.

Puoi seguire il Repository di AWS Labs per tenere traccia di tutti i contributi AWS a Kubeflow. Ci puoi trovare anche sul Canale Kubeflow #AWS Slack; il tuo feedback ci aiuterà a stabilire la priorità delle funzionalità successive per contribuire al progetto Kubeflow.

Un ringraziamento speciale a Sree Arasanagatta (Software Development Manager AWS ML) e Suraj Kota (Software Dev Engineer) per il loro supporto al lancio di questo post.

Circa gli autori

Kanwaljit Khurmi è un architetto specializzato in soluzioni AI/ML presso Amazon Web Services. Collabora con il prodotto, l'ingegneria e i clienti AWS per fornire guida e assistenza tecnica, aiutandoli a migliorare il valore delle loro soluzioni di machine learning ibride quando utilizzano AWS. Kanwaljit è specializzato nell'aiutare i clienti con applicazioni containerizzate e di machine learning.

Gautama Kumar è un software engineer con AWS AI Deep Learning. Ha sviluppato AWS Deep Learning Containers e AWS Deep Learning AMI. È appassionato di creazione di strumenti e sistemi per l'IA. Nel tempo libero ama andare in bicicletta e leggere libri.

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.