Crie arquiteturas de treinamento distribuídas flexíveis e escaláveis ​​usando Kubeflow na AWS e Amazon SageMaker

Neste post, mostramos como Kubeflow na AWS (uma distribuição de Kubeflow específica da AWS) usada com Contêineres de aprendizado profundo da AWS e Sistema de arquivos elástico da Amazon (Amazon EFS) simplifica a colaboração e oferece flexibilidade no treinamento de modelos de aprendizado profundo em escala em ambos Serviço Amazon Elastic Kubernetes (Amazon EKS) e Amazon Sage Maker utilizando uma abordagem de arquitetura híbrida.

O desenvolvimento de aprendizado de máquina (ML) depende de estruturas e kits de ferramentas de código aberto complexos e em constante evolução, bem como ecossistemas de hardware complexos e em constante evolução. Isso representa um desafio ao dimensionar o desenvolvimento de ML para um cluster. Os contêineres oferecem uma solução, pois podem encapsular totalmente não apenas o código de treinamento, mas toda a pilha de dependências até as bibliotecas de hardware. Isso garante um ambiente de ML consistente e portátil e facilita a reprodutibilidade do ambiente de treinamento em cada nó individual do cluster de treinamento.

O Kubernetes é um sistema amplamente adotado para automatizar a implantação de infraestrutura, dimensionamento de recursos e gerenciamento desses aplicativos em contêiner. No entanto, o Kubernetes não foi criado com ML em mente, portanto, pode parecer contra-intuitivo para os cientistas de dados devido à sua forte dependência de arquivos de especificação YAML. Não há uma experiência Jupyter e não há muitos recursos específicos de ML, como gerenciamento de fluxo de trabalho e pipelines, e outros recursos que os especialistas em ML esperam, como ajuste de hiperparâmetros, hospedagem de modelos e outros. Esses recursos podem ser construídos, mas o Kubernetes não foi projetado para fazer isso como seu objetivo principal.

A comunidade de código aberto tomou conhecimento e desenvolveu uma camada em cima do Kubernetes chamada Kubeflow. O Kubeflow visa tornar a implantação de fluxos de trabalho de ML de ponta a ponta no Kubernetes simples, portátil e escalável. Você pode usar o Kubeflow para implantar os melhores sistemas de código aberto para ML em diversas infraestruturas.

Kubeflow e Kubernetes fornecem flexibilidade e controle para equipes de cientistas de dados. No entanto, garantir a alta utilização de clusters de treinamento executados em escala com sobrecargas operacionais reduzidas ainda é um desafio.

Esta postagem demonstra como os clientes que têm restrições locais ou investimentos existentes em Kubernetes podem enfrentar esse desafio usando o Amazon EKS e o Kubeflow na AWS para implementar um pipeline de ML para treinamento distribuído com base em uma abordagem autogerenciada e usar o SageMaker totalmente gerenciado para um infraestrutura de treinamento otimizada para custos, totalmente gerenciada e em escala de produção. Isso inclui a implementação passo a passo de uma arquitetura de treinamento distribuída híbrida que permite escolher entre as duas abordagens em tempo de execução, conferindo o máximo de controle e flexibilidade com necessidades rigorosas para suas implantações. Você verá como pode continuar usando bibliotecas de código aberto em seu script de treinamento de aprendizado profundo e ainda torná-lo compatível para execução no Kubernetes e no SageMaker de maneira independente da plataforma.

Como o Kubeflow na AWS e o SageMaker ajudam?

Modelos de rede neural construídos com estruturas de aprendizado profundo como TensorFlow, PyTorch, MXNet e outros fornecem precisão muito maior usando conjuntos de dados de treinamento significativamente maiores, especialmente em casos de uso de visão computacional e processamento de linguagem natural. No entanto, com grandes conjuntos de dados de treinamento, leva mais tempo para treinar os modelos de aprendizado profundo, o que, em última análise, diminui o tempo de lançamento no mercado. Se pudéssemos dimensionar um cluster e reduzir o tempo de treinamento do modelo de semanas para dias ou horas, isso poderia ter um enorme impacto na produtividade e na velocidade dos negócios.

O Amazon EKS ajuda a provisionar o plano de controle gerenciado do Kubernetes. Você pode usar o Amazon EKS para criar clusters de treinamento em grande escala com instâncias de CPU e GPU e usar o kit de ferramentas Kubeflow para fornecer ferramentas de código aberto e amigáveis ​​para ML e operacionalizar fluxos de trabalho de ML portáteis e escaláveis ​​usando Kubeflow Pipelines para melhorar a produtividade de sua equipe e reduzir o tempo de colocação no mercado.

No entanto, pode haver alguns desafios com essa abordagem:

• Garantir a utilização máxima de um cluster entre as equipes de ciência de dados. Por exemplo, você deve provisionar instâncias de GPU sob demanda e garantir sua alta utilização para tarefas exigentes em escala de produção, como treinamento de aprendizado profundo, e usar instâncias de CPU para tarefas menos exigentes, como pré-processamento de dados
• Garantir a alta disponibilidade de componentes de infraestrutura pesada do Kubeflow, incluindo banco de dados, armazenamento e autenticação, que são implementados no nó do trabalhador do cluster Kubernetes. Por exemplo, o plano de controle do Kubeflow gera artefatos (como instâncias MySQL, logs de pod ou armazenamento MinIO) que crescem com o tempo e precisam de volumes de armazenamento redimensionáveis ​​com recursos de monitoramento contínuo.
• Compartilhar o conjunto de dados de treinamento, código e ambientes de computação entre desenvolvedores, clusters de treinamento e projetos é um desafio. Por exemplo, se você estiver trabalhando em seu próprio conjunto de bibliotecas e essas bibliotecas tiverem fortes interdependências, fica muito difícil compartilhar e executar o mesmo código entre cientistas de dados da mesma equipe. Além disso, cada execução de treinamento exige que você baixe o conjunto de dados de treinamento e crie a imagem de treinamento com novas alterações de código.

O Kubeflow na AWS ajuda a enfrentar esses desafios e fornece um produto Kubeflow semigerenciado de nível empresarial. Com o Kubeflow na AWS, você pode substituir alguns serviços do plano de controle do Kubeflow, como banco de dados, armazenamento, monitoramento e gerenciamento de usuários, por serviços gerenciados pela AWS, como Serviço de banco de dados relacional da Amazon (Amazônia RDS), Serviço de armazenamento simples da Amazon (Amazon S3), Sistema de arquivos elástico da Amazon (Amazônia EFS), Amazon FSx, Amazon CloudWatch e Amazon Cognito.

A substituição desses componentes do Kubeflow desacopla partes críticas do plano de controle do Kubeflow do Kubernetes, fornecendo um design seguro, escalável, resiliente e com custo otimizado. Essa abordagem também libera recursos de armazenamento e computação do plano de dados do EKS, que podem ser necessários para aplicativos como treinamento de modelo distribuído ou servidores de notebook do usuário. O Kubeflow na AWS também fornece integração nativa de notebooks Jupyter com imagens Deep Learning Container (DLC), que são pré-empacotadas e pré-configuradas com estruturas de aprendizado profundo otimizadas da AWS, como PyTorch e TensorFlow, que permitem que você comece a escrever seu código de treinamento imediatamente sem lidar com resoluções de dependência e otimizações de estrutura. Além disso, a integração do Amazon EFS com clusters de treinamento e o ambiente de desenvolvimento permite que você compartilhe seu código e conjunto de dados de treinamento processado, o que evita criar a imagem do contêiner e carregar grandes conjuntos de dados após cada alteração de código. Essas integrações com o Kubeflow na AWS ajudam você a acelerar a criação de modelos e o tempo de treinamento e permitem uma melhor colaboração com dados mais fáceis e compartilhamento de código.

O Kubeflow na AWS ajuda a criar uma plataforma de ML robusta e altamente disponível. Essa plataforma oferece flexibilidade para criar e treinar modelos de aprendizado profundo e fornece acesso a muitos kits de ferramentas de código aberto, insights sobre logs e depuração interativa para experimentação. No entanto, alcançar a utilização máxima dos recursos de infraestrutura durante o treinamento de modelos de aprendizado profundo em centenas de GPUs ainda envolve muitas despesas operacionais. Isso pode ser resolvido usando o SageMaker, que é um serviço totalmente gerenciado projetado e otimizado para lidar com clusters de treinamento de alto desempenho e com custo otimizado que são provisionados apenas quando solicitados, dimensionados conforme necessário e desligados automaticamente quando os trabalhos são concluídos, fornecendo assim cerca de 100 % de utilização de recursos. Você pode integrar o SageMaker ao Kubeflow Pipelines usando componentes gerenciados do SageMaker. Isso permite que você operacionalize os fluxos de trabalho de ML como parte dos pipelines do Kubeflow, onde você pode usar o Kubernetes para treinamento local e o SageMaker para treinamento em escala de produto em uma arquitetura híbrida.

Visão geral da solução

A arquitetura a seguir descreve como usamos o Kubeflow Pipelines para criar e implantar fluxos de trabalho de ML portáteis e escaláveis ​​de ponta a ponta para executar treinamento distribuído condicionalmente no Kubernetes usando o treinamento do Kubeflow ou o SageMaker com base no parâmetro de tempo de execução.

O treinamento Kubeflow é um grupo de operadores Kubernetes que adicionam ao Kubeflow o suporte para treinamento distribuído de modelos de ML usando diferentes frameworks como TensorFlow, PyTorch e outros. pytorch-operator é a implementação do Kubeflow do Kubernetes recurso personalizado (PyTorchJob) para executar trabalhos de treinamento PyTorch distribuídos no Kubernetes.

Usamos o componente PyTorchJob Launcher como parte do pipeline do Kubeflow para executar o treinamento distribuído do PyTorch durante a fase de experimentação, quando precisamos de flexibilidade e acesso a todos os recursos subjacentes para depuração e análise interativas.

Também usamos componentes do SageMaker para Kubeflow Pipelines para executar nosso treinamento de modelo em escala de produção. Isso nos permite aproveitar os recursos poderosos do SageMaker, como serviços totalmente gerenciados, trabalhos de treinamento distribuídos com utilização máxima da GPU e treinamento econômico por meio de Amazon Elastic Compute Nuvem (Amazon EC2) Instâncias Spot.

Como parte do processo de criação do fluxo de trabalho, você conclui as etapas a seguir (conforme mostrado no diagrama anterior) para criar esse pipeline:

1. Use o arquivo de manifesto do Kubeflow para criar um painel do Kubeflow e acessar os notebooks do Jupyter no painel central do Kubeflow.
2. Use o SDK de pipeline do Kubeflow para criar e compilar pipelines do Kubeflow usando o código Python. A compilação de pipeline converte a função Python em um recurso de fluxo de trabalho, que é um formato YAML compatível com Argo.
3. Use o cliente SDK do Kubeflow Pipelines para chamar o endpoint de serviço de pipeline para executar o pipeline.
4. O pipeline avalia as variáveis ​​de tempo de execução condicionais e decide entre SageMaker ou Kubernetes como o ambiente de execução de destino.
5. Use o componente Kubeflow PyTorch Launcher para executar treinamento distribuído no ambiente nativo do Kubernetes ou use o componente SageMaker para enviar o treinamento na plataforma gerenciada do SageMaker.

A figura a seguir mostra os componentes do Kubeflow Pipelines envolvidos na arquitetura que nos dão a flexibilidade de escolher entre ambientes distribuídos Kubernetes ou SageMaker.

Fluxo de trabalho de caso de uso

Usamos a seguinte abordagem passo a passo para instalar e executar o caso de uso para treinamento distribuído usando Amazon EKS e SageMaker usando Kubeflow na AWS.

Pré-requisitos

Para este passo a passo, você deve ter os seguintes pré-requisitos:

• An Conta da AWS.
• Uma máquina com Docker e o Interface de linha de comando da AWS (AWS CLI) instalado.
• Opcionalmente, você pode usar Nuvem AWS9, um ambiente de desenvolvimento integrado (IDE) baseado em nuvem que permite concluir todo o trabalho do seu navegador da web. Para obter instruções de configuração, consulte Configurar Cloud9 IDE. No seu ambiente Cloud9, escolha o sinal de mais e abra um novo terminal.
• Crie um papel com o nome sagemakerrole. Adicionar políticas gerenciadas AmazonSageMakerFullAccess e AmazonS3FullAccess para dar ao SageMaker acesso aos buckets do S3. Essa função é usada pelo trabalho do SageMaker enviado como parte da etapa Kubeflow Pipelines.
• Certifique-se de que sua conta tenha um limite de tipo de recurso de treinamento do SageMaker para ml.p3.2xlarge aumentou para 2 usando Console de cotas de serviço

1. Instale o Amazon EKS e o Kubeflow na AWS

Você pode usar várias abordagens diferentes para criar um cluster Kubernetes e implantar o Kubeflow. Neste post, focamos em uma abordagem que acreditamos trazer simplicidade ao processo. Primeiro, criamos um cluster EKS e, em seguida, implantamos o Kubeflow na AWS v1.5 nele. Para cada uma dessas tarefas, usamos um projeto de código aberto correspondente que segue os princípios da Fazer estrutura. Em vez de instalar um conjunto de pré-requisitos para cada tarefa, criamos contêineres Docker que possuem todas as ferramentas necessárias e executamos as tarefas de dentro dos contêineres.

Usamos o Do Framework neste post, que automatiza a implantação do Kubeflow com o Amazon EFS como complemento. Para obter as opções oficiais de implantação do Kubeflow na AWS para implantações de produção, consulte desenvolvimento.

Configure o diretório de trabalho atual e a AWS CLI

Configuramos um diretório de trabalho para que possamos nos referir a ele como ponto de partida para as etapas a seguir:

export working_dir=$PWD

Também configuramos um perfil da AWS CLI. Para fazer isso, você precisa de um ID de chave de acesso e uma chave de acesso secreta de um Gerenciamento de acesso e identidade da AWS (IAM) usuário conta com privilégios administrativos (anexe a política gerenciada existente) e acesso programático. Veja o seguinte código:

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 Criar um cluster EKS

Se você já tiver um cluster EKS disponível, pule para a próxima seção. Para este post, usamos o projeto aws-do-eks para criar nosso cluster.

1. Primeiro clone o projeto em seu diretório de trabalho

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

2. Em seguida, construa e execute o aws-do-eks recipiente:

   ./build.sh
   ./run.sh

   A build.sh script cria uma imagem de contêiner do Docker que possui todas as ferramentas e scripts necessários para provisionamento e operação de clusters EKS. o run.sh O script inicia um contêiner usando a imagem do Docker criada e a mantém ativa, para que possamos usá-la como nosso ambiente de gerenciamento do EKS. Para ver o estado do seu aws-do-eks recipiente, você pode executar ./status.sh. Se o contêiner estiver com o status Exited, você pode usar o ./start.sh script para ativar o contêiner ou reiniciá-lo, você pode executar ./stop.sh seguido ./run.sh.

3. Abra um shell em execução aws-do-eks recipiente:
4. Para revisar a configuração do cluster EKS para nossa implantação do KubeFlow, execute o seguinte comando:

   vi ./eks-kubeflow.yaml

   Por padrão, essa configuração cria um cluster chamado eks-kubeflow no us-west-2 Região com seis nós m5.xlarge. Além disso, a criptografia de volumes do EBS não está habilitada por padrão. Você pode habilitá-lo adicionando "volumeEncrypted: true" para o grupo de nós e ele irá criptografar usando a chave padrão. Modifique outras configurações, se necessário.

5. Para criar o cluster, execute o seguinte comando:

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

   O processo de provisionamento de cluster pode levar até 30 minutos.

6. Para verificar se o cluster foi criado com sucesso, execute o seguinte comando:

   kubectl get nodes

   A saída do comando anterior para um cluster que foi criado com sucesso se parece com o seguinte código:

   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

Criar um volume EFS para o trabalho de treinamento do SageMaker

Nesse caso de uso, você acelera o trabalho de treinamento do SageMaker treinando modelos de aprendizado profundo a partir de dados já armazenados no Amazon EFS. Essa opção tem o benefício de iniciar diretamente seus trabalhos de treinamento a partir dos dados no Amazon EFS sem a necessidade de movimentação de dados, resultando em tempos de início de treinamento mais rápidos.

Criamos um volume EFS e implantamos o driver EFS Container Storage Interface (CSI). Isso é feito por um script de implantação localizado em /eks/deployment/csi/efs dentro do aws-do-eks recipiente.

Este script pressupõe que você tenha um cluster EKS em sua conta. Definir CLUSTER_NAME= caso você tenha mais de um cluster EKS.

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

Esse script provisiona um volume EFS e cria destinos de montagem para as sub-redes da VPC do cluster. Em seguida, ele implanta o driver EFS CSI e cria o efs-sc classe de armazenamento e efs-pv volume persistente no cluster EKS.

Após a conclusão bem-sucedida do script, você deverá ver uma saída como a seguinte:

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 ...

Criar um VPC endpoint do Amazon S3

Você usa uma VPC privada à qual o trabalho de treinamento do SageMaker e o sistema de arquivos EFS têm acesso. Para conceder ao cluster de treinamento do SageMaker acesso aos buckets do S3 de sua VPC privada, você cria um VPC endpoint:

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

Agora você pode sair do aws-do-eks shell do contêiner e vá para a próxima seção:

exit

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

1.2 Implantar o Kubeflow na AWS no Amazon EKS

Para implantar o Kubeflow no Amazon EKS, usamos o projeto aws-do-kubeflow.

1. Clone o repositório usando os seguintes comandos:

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

2. Em seguida, configure o projeto:

   ./config.sh

   Este script abre o arquivo de configuração do projeto em um editor de texto. É importante para AWS_REGION para ser definido para a região em que seu cluster está, bem como AWS_CLUSTER_NAME para corresponder ao nome do cluster que você criou anteriormente. Por padrão, sua configuração já está devidamente definida, portanto, se você não precisar fazer nenhuma alteração, basta fechar o editor.

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

   A build.sh O script cria uma imagem de contêiner do Docker que possui todas as ferramentas necessárias para implantar e gerenciar o Kubeflow em um cluster Kubernetes existente. o run.sh O script inicia um contêiner, usando a imagem do Docker, e o script exec.sh abre um shell de comando no contêiner, que podemos usar como nosso ambiente de gerenciamento do Kubeflow. Você pode usar o ./status.sh script para ver se aws-do-kubeflow recipiente está em funcionamento e o ./stop.sh e ./run.sh scripts para reiniciá-lo conforme necessário.

3. Depois de ter um shell aberto no aws-do-eks container, você pode verificar se o contexto do cluster configurado está conforme o esperado:

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

4. Para implantar o Kubeflow no cluster EKS, execute o deploy.sh script:

   ./kubeflow-deploy.sh

   A implantação é bem-sucedida quando todos os pods no namespace kubeflow entram no estado Em execução. Uma saída típica se parece com o seguinte código:

   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. Para monitorar o estado dos pods do KubeFlow, em uma janela separada, você pode usar o seguinte comando:

   watch kubectl -n kubeflow get pods

6. Press Ctrl + C quando todos os pods estiverem em execução, exponha o painel do Kubeflow fora do cluster executando o seguinte comando:

   ./kubeflow-expose.sh

Você deve ver uma saída que se parece com o seguinte código:

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

Este comando encaminha o serviço de gateway de entrada do Istio do cluster para a porta local 8080. Para acessar o painel do Kubeflow, visite http://localhost:8080 e faça login usando as credenciais de usuário padrão (user@example.com/12341234). Se você estiver executando o aws-do-kubeflow container no AWS Cloud9, então você pode escolher visualização, Em seguida, escolha Pré-visualizar aplicativo em execução. Se você estiver executando no Docker Desktop, talvez seja necessário executar o ./kubeflow-expose.sh roteiro fora do aws-do-kubeflow recipiente.

2. Configure o ambiente Kubeflow no AWS

Para configurar seu ambiente Kubeflow na AWS, criamos um volume EFS e um notebook Jupyter.

2.1 Criar um volume EFS

Para criar um volume EFS, conclua as etapas a seguir:

• No painel do Kubeflow, escolha Calculo de volumes e distâncias no painel de navegação.
• Escolheu Novo volume.
• Escolha Nome, entrar efs-sc-claim.
• Escolha Tamanho do volume, entrar 10.
• Escolha Classe de armazenamento, escolha efs-sc.
• Escolha Modo de acesso, escolha ReadWriteOnce.
• Escolha Crie.

2.2 Criar um notebook Jupyter

Para criar um novo bloco de anotações, conclua as etapas a seguir:

• No painel do Kubeflow, escolha Notebooks no painel de navegação.
• Escolha Novo bloco de anotações.
• Escolha Nome, entrar aws-hybrid-nb.
• Escolha Imagem de registro do Jupyter, escolha a imagem c9e4w0g3/notebook-servers/jupyter-pytorch:1.11.0-cpu-py38-ubuntu20.04-e3-v1.1 (a última imagem DLC jupyter-pytorch disponível).
• Escolha CPU, entrar 1.
• Escolha Memória, entrar 5.
• Escolha GPUs, deixe como nenhum.
• Não faça nenhuma alteração no Volume do espaço de trabalho seção.
• No Volumes de dados seção, escolha Anexar volume existente e expanda a seção Volume existente
• Escolha Nome, escolha efs-sc-claim.
• Escolha Caminho de montagem, entrar /home/jovyan/efs-sc-claim.
  Isso monta o volume EFS no seu pod de notebook Jupyter e você pode ver a pasta efs-sc-claim na interface do laboratório Jupyter. Você salva o conjunto de dados de treinamento e o código de treinamento nessa pasta para que os clusters de treinamento possam acessá-lo sem precisar reconstruir as imagens de contêiner para teste.
• Selecionar Permitir acesso ao Kubeflow Pipelines na seção Configuração.
• Escolha Apresentação livro.
  Verifique se o seu notebook foi criado com sucesso (pode levar alguns minutos).
• No Notebooks página, escolha Contato para fazer login no ambiente JupyterLab.
• No Git menu, escolha Clonar um repositório.
• Escolha Clonar um repositório, entrar https://github.com/aws-samples/aws-do-kubeflow.
  

3. Execute treinamento distribuído

Depois de configurar o notebook Jupyter, você pode executar a demonstração inteira usando as seguintes etapas de alto nível da pasta aws-do-kubeflow/workshop no repositório clonado:

• Script de treinamento do PyTorch Distributed Data Parallel (DDP): Consulte o script de treinamento do PyTorch DDP cifar10-distributed-gpu-final.py, que inclui uma rede neural convolucional de amostra e lógica para distribuir o treinamento em um cluster de CPU e GPU de vários nós. (Consulte 3.1 para detalhes)
• Instalar bibliotecas: Execute o caderno 0_initialize_dependencies.ipynb para inicializar todas as dependências. (Consulte 3.2 para detalhes)
• Execute o treinamento de trabalho distribuído do PyTorch no Kubernetes: Execute o caderno 1_submit_pytorchdist_k8s.ipynb para criar e enviar treinamento distribuído em um contêiner principal e dois de trabalho usando o arquivo YAML PyTorchJob de recurso personalizado do Kubernetes usando código Python. (Consulte 3.3 para detalhes)
• Crie um pipeline híbrido do Kubeflow: Execute o caderno 2_create_pipeline_k8s_sagemaker.ipynb para criar o pipeline híbrido do Kubeflow que executa o treinamento distribuído no SageMaker ou no Amazon EKS usando a variável de tempo de execução training_runtime. (Consulte 3.4 para detalhes)

Certifique-se de executar o notebook 1_submit_pytorchdist_k8s.ipynb antes de iniciar o notebook 2_create_pipeline_k8s_sagemaker.ipynb.

Nas seções subsequentes, discutiremos cada uma dessas etapas em detalhes.

3.1 Script de treinamento PyTorch Distributed Data Parallel (DDP)

Como parte do treinamento distribuído, treinamos um modelo de classificação criado por uma rede neural convolucional simples que opera no conjunto de dados CIFAR10. O roteiro de treinamento cifar10-distributed-gpu-final.py contém apenas as bibliotecas de código aberto e é compatível para execução em clusters de treinamento Kubernetes e SageMaker em dispositivos de GPU ou instâncias de CPU. Vejamos alguns aspectos importantes do script de treinamento antes de executarmos nossos exemplos de notebook.

Usamos o torch.distributed módulo, que contém suporte a PyTorch e primitivas de comunicação para paralelismo de vários processos entre nós no 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
...

Criamos um modelo de classificação de imagem simples usando uma combinação de camadas convolucionais, de pool máximo e lineares às quais uma função de ativação relu é aplicada na passagem direta do treinamento do modelo:

# 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

Usamos a tocha DataLoader que combina o conjunto de dados e DistributedSampler (carrega um subconjunto de dados de maneira distribuída usando torch.nn.parallel.DistributedDataParallel) e fornece um iterador de processo único ou multiprocesso sobre os dados:

# 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 o cluster de treinamento tiver GPUs, o script executa o treinamento em dispositivos CUDA e a variável de dispositivo mantém o dispositivo CUDA padrão:

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

Antes de executar o treinamento distribuído usando o PyTorch DistributedDataParallel para executar o processamento distribuído em vários nós, você precisa inicializar o ambiente distribuído chamando init_process_group. Isso é inicializado em cada máquina do cluster de treinamento.

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

Instanciamos o modelo do classificador e copiamos o modelo para o dispositivo de destino. Se o treinamento distribuído estiver habilitado para execução em vários nós, o DistributedDataParallel class é usado como um objeto wrapper em torno do objeto de modelo, que permite o treinamento distribuído síncrono em várias máquinas. Os dados de entrada são divididos na dimensão do lote e uma réplica do modelo é colocada em cada máquina e em cada dispositivo.

model = Net().to(device)

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

...

3.2 Instalar bibliotecas

Você instalará todas as bibliotecas necessárias para executar o exemplo de treinamento distribuído do PyTorch. Isso inclui Kubeflow Pipelines SDK, Training Operator Python SDK, Python client for 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 Executar treinamento de trabalho distribuído do PyTorch no Kubernetes

O caderno 1_submit_pytorchdist_k8s.ipynb cria o arquivo YAML PyTorchJob do recurso personalizado do Kubernetes usando o treinamento do Kubeflow e o SDK do Python do cliente do Kubernetes. A seguir estão alguns trechos importantes deste caderno.

Criamos o YAML PyTorchJob com os contêineres primário e de trabalho, conforme mostrado no código a seguir:

# 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}
)
)

Isso é submetido ao plano de controle do Kubernetes usando PyTorchJobClient:

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

pytorch_job_manifest=pytorchjob_client.create(pytorchjob):

Ver os registros de treinamento do Kubernetes

Você pode visualizar os logs de treinamento no mesmo notebook Jupyter usando código Python ou no shell do cliente Kubernetes.

3.4 Criar um pipeline híbrido do Kubeflow

O caderno 2_create_pipeline_k8s_sagemaker.ipynb cria um pipeline híbrido do Kubeflow com base na variável de tempo de execução condicional training_runtime, conforme mostrado no código a seguir. O caderno usa o SDK do Kubeflow Pipelines e é fornecido um conjunto de pacotes Python para especificar e executar os pipelines de fluxo de trabalho de ML. Como parte deste SDK, usamos os seguintes pacotes:

• O decorador de pacote de linguagem específica de domínio (DSL) dsl.pipeline, que decora as funções do Python para retornar um pipeline
• A dsl.Condition pacote, que representa um grupo de operações que só são executadas quando uma determinada condição é atendida, como verificar o training_runtime valor como sagemaker or kubernetes

Veja o seguinte código:

# 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)

Configuramos o treinamento distribuído do SageMaker usando duas instâncias ml.p3.2xlarge.

Depois que o pipeline é definido, você pode compilar o pipeline para uma especificação Argo YAML usando o SDK do Kubeflow Pipelines kfp.compiler pacote. Você pode executar esse pipeline usando o cliente Kubeflow Pipeline SDK, que chama o endpoint de serviço Pipelines e transmite os cabeçalhos de autenticação apropriados diretamente do notebook. Veja o seguinte código:

# 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 você conseguir um sagemaker import erro, execute !pip install sagemaker e reinicie o kernel (no Núcleo menu, escolha Reiniciar Kernel).

Escolha o Detalhes da execução link na última célula para visualizar o pipeline do Kubeflow.

Repita a etapa de criação do pipeline com training_runtime='kubernetes' para testar o pipeline executado em um ambiente Kubernetes. o training_runtime variável também pode ser passada em seu pipeline de CI/CD em um cenário de produção.

Visualize os logs de execução do pipeline do Kubeflow para o componente SageMaker

A captura de tela a seguir mostra os detalhes do nosso pipeline para o componente SageMaker.

Escolha a etapa do job de treinamento e no Logs guia, escolha o link de logs do CloudWatch para acessar os logs do SageMaker.

A captura de tela a seguir mostra os logs do CloudWatch para cada uma das duas instâncias ml.p3.2xlarge.

Escolha qualquer um dos grupos para ver os logs.

Visualize os logs de execução do pipeline do Kubeflow para o componente Kubeflow PyTorchJob Launcher

A captura de tela a seguir mostra os detalhes do pipeline para nosso componente Kubeflow.

Execute os seguintes comandos usando Kubectl no shell do cliente Kubernetes conectado ao cluster Kubernetes para ver os logs (substitua o namespace e os nomes do pod):

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

4.1 Limpeza

Para limpar todos os recursos que criamos na conta, precisamos removê-los na ordem inversa.

1. Exclua a instalação do Kubeflow executando ./kubeflow-remove.sh no aws-do-kubeflow recipiente. O primeiro conjunto de comandos é opcional e pode ser usado caso você ainda não tenha um shell de comando em seu aws-do-kubeflow recipiente aberto.

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

2. De aws-do-eks pasta container, remova o volume EFS. O primeiro conjunto de comandos é opcional e pode ser usado caso você ainda não tenha um shell de comando em seu aws-do-eks recipiente aberto.

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

   A exclusão do Amazon EFS é necessária para liberar a interface de rede associada à VPC que criamos para nosso cluster. Observe que a exclusão do volume EFS destrói todos os dados armazenados nele.

3. De aws-do-eks recipiente, execute o eks-delete.sh script para excluir o cluster e quaisquer outros recursos associados a ele, incluindo a VPC:

   cd /eks
   ./eks-delete.sh

Resumo

Neste post, discutimos alguns dos desafios típicos de treinamento de modelo distribuído e fluxos de trabalho de ML. Fornecemos uma visão geral da distribuição do Kubeflow na AWS e compartilhamos dois projetos de código aberto (aws-do-eks e aws-do-kubeflow) que simplificam o provisionamento da infraestrutura e a implantação do Kubeflow nela. Por fim, descrevemos e demonstramos uma arquitetura híbrida que permite que as cargas de trabalho façam uma transição perfeita entre a execução em um Kubernetes autogerenciado e uma infraestrutura SageMaker totalmente gerenciada. Recomendamos que você use essa arquitetura híbrida para seus próprios casos de uso.

Você pode seguir o Repositório do AWS Labs para rastrear todas as contribuições da AWS para o Kubeflow. Você também pode nos encontrar no Kubeflow #AWS Canal Slack; seus comentários nos ajudarão a priorizar os próximos recursos para contribuir com o projeto Kubeflow.

Agradecimentos especiais a Sree Arasanagatta (Software Development Manager AWS ML) e Suraj Kota (Software Dev Engineer) por seu apoio ao lançamento deste post.

Sobre os autores

Kanwaljit Khurmi é arquiteto de soluções especialista em IA/ML na Amazon Web Services. Ele trabalha com o produto, a engenharia e os clientes da AWS para fornecer orientação e assistência técnica, ajudando-os a melhorar o valor de suas soluções de ML híbridas ao usar a AWS. A Kanwaljit é especializada em ajudar os clientes com aplicativos em contêiner e de aprendizado de máquina.

Gautama Kumar é engenheiro de software com o AWS AI Deep Learning. Ele desenvolveu AWS Deep Learning Containers e AWS Deep Learning AMI. Ele é apaixonado por construir ferramentas e sistemas para IA. Em seu tempo livre, ele gosta de andar de bicicleta e ler livros.

Alex Iankoulski é um arquiteto de infraestrutura e software full-stack que gosta de fazer um trabalho profundo e prático. Atualmente, ele é o principal arquiteto de soluções para aprendizado de máquina autogerenciado na AWS. Em sua função, ele se concentra em ajudar os clientes com conteinerização e orquestração de cargas de trabalho de ML e IA em serviços da AWS baseados em contêiner. Ele também é o autor do código aberto Fazer estrutura e um capitão do Docker que adora aplicar tecnologias de contêineres para acelerar o ritmo da inovação enquanto resolve os maiores desafios do mundo. Nos últimos 10 anos, Alex trabalhou no combate às mudanças climáticas, democratizando a IA e o ML, tornando as viagens mais seguras, a saúde melhor e a energia mais inteligente.