Melhore o desempenho de preço do seu treinamento de modelo usando clusters heterogêneos do Amazon SageMaker

Este post foi co-escrito com Chaim Rand da Mobileye.

Certas cargas de trabalho de aprendizado de máquina (ML), como treinamento de modelos de visão computacional ou aprendizado de reforço, geralmente envolvem a combinação da tarefa intensiva de GPU ou acelerador de treinamento de modelo de rede neural com a tarefa intensiva de CPU de pré-processamento de dados, como aumento de imagem. Quando os dois tipos de tarefas são executados no mesmo tipo de instância, o pré-processamento de dados fica afunilado na CPU, levando a uma menor utilização da GPU. Esse problema piora com o tempo, pois a taxa de transferência das novas gerações de GPUs cresce em um ritmo mais acentuado do que o das CPUs.

Para resolver esse problema, em julho de 2022, lançado agrupamentos heterogêneos para Amazon Sage Maker treinamento de modelo, que permite iniciar trabalhos de treinamento que usam diferentes tipos de instância em um único trabalho. Isso permite descarregar partes do pipeline de pré-processamento de dados para otimizado para computação tipos de instância, enquanto a tarefa de rede neural profunda (DNN) continua a ser executada em GPU ou computação acelerada tipos de instância. Nossos benchmarks mostram um benefício de desempenho de preço de até 46% após habilitar clusters heterogêneos em um treinamento de modelo de visão computacional TensorFlow vinculado à CPU.

Para um caso de uso semelhante, Mobileye, uma empresa de desenvolvimento de tecnologias de veículos autônomos, tinha isso para compartilhar:

“Ao mover o treinamento de modelo de visão computacional de aprendizado profundo vinculado à CPU para executar em vários tipos de instância (aceleradores de CPU e GPU/ML), usando um tf.data.service com base na solução que construímos, conseguimos reduzir o tempo de treinamento em 40% e, ao mesmo tempo, reduzir o custo de treinamento em 30%. Estamos entusiasmados com os clusters heterogêneos que nos permitem executar essa solução no Amazon SageMaker.”

— Engenharia de IA, Mobileye

Neste post, abordamos os seguintes tópicos:

• Como clusters heterogêneos ajudam a remover gargalos de CPU
• Quando usar clusters heterogêneos e outras alternativas
• Implementações de referência no PyTorch e no TensorFlow
• Resultados de benchmark de desempenho
• Aglomerados heterogêneos em Mobileye

AWS instância de computação acelerada família inclui aceleradores de chips personalizados da AWS (Inferência da AWS, Treinamento AWS), NVIDIA (GPUs), E Aceleradores de Gaudi da Habana Labs (uma empresa Intel). Observe que neste post, usamos os termos GPU e acelerador de forma intercambiável.

Como clusters heterogêneos removem gargalos de processamento de dados

Os cientistas de dados que treinam modelos de aprendizado profundo visam maximizar a eficiência de custo do treinamento e minimizar o tempo de treinamento. Para conseguir isso, um objetivo básico de otimização é ter alta utilização de GPU, o recurso mais caro e escasso dentro do Amazon Elastic Compute Nuvem (Amazon EC2). Isso pode ser mais desafiador com cargas de trabalho de ML que combinam a propagação para frente e para trás do modelo clássico de rede neural com uso intenso de GPU com tarefas com uso intensivo de CPU, como processamento e aumento de dados em visão computacional ou execução de uma simulação de ambiente em aprendizado por reforço. Essas cargas de trabalho podem acabar sendo vinculadas à CPU, onde ter mais CPU resultaria em maior taxa de transferência e treinamento mais rápido e barato, pois os aceleradores existentes estão parcialmente ociosos. Em alguns casos, os gargalos de CPU podem ser resolvidos alternando para outro tipo de instância com uma proporção maior de CPU:GPU. No entanto, há situações em que a mudança para outro tipo de instância pode não ser possível devido à arquitetura da família de instâncias, armazenamento ou dependências de rede.

Em tais situações, você precisa aumentar a quantidade de energia da CPU misturando tipos de instância: instâncias com GPUs e CPU. Somados, isso resulta em uma taxa geral de CPU:GPU mais alta. Até recentemente, os trabalhos de treinamento do SageMaker limitavam-se a ter instâncias de um único tipo de instância escolhido. Com os clusters heterogêneos do SageMaker, os cientistas de dados podem executar facilmente um trabalho de treinamento com vários tipos de instância, o que permite descarregar algumas das tarefas de CPU existentes das instâncias de GPU para instâncias de CPU otimizadas para computação dedicada, resultando em maior utilização de GPU e mais rapidez e custo treinamento eficiente. Além disso, com o poder extra da CPU, você pode fazer com que as tarefas de pré-processamento que tradicionalmente eram feitas offline como uma etapa preliminar do treinamento se tornem parte de seu trabalho de treinamento. Isso torna mais rápido iterar e experimentar tanto o pré-processamento de dados quanto as suposições e hiperparâmetros de treinamento de DNN.

Por exemplo, considere um poderoso tipo de instância de GPU, ml.p4d.24xlarge (96 vCPU, 8 x NVIDIA A100 GPUs), com uma relação CPU:GPU de 12:1. Vamos supor que seu trabalho de treinamento precise de 20 vCPUs para pré-processar dados suficientes para manter uma GPU 100% utilizada. Portanto, para manter todas as 8 GPUs 100% utilizadas, você precisa de um tipo de instância de 160 vCPUs. No entanto, ml.p4d.24xlarge tem menos de 64 vCPUs, ou 40%, limitando a utilização da GPU a 60%, conforme ilustrado à esquerda do diagrama a seguir. Adicionar outra instância ml.p4d.24xlarge ajudaria? Não, porque a proporção CPU:GPU do trabalho permaneceria a mesma.

Com clusters heterogêneos, podemos adicionar dois ml.c5.18xlarge (72 vCPU), conforme mostrado à direita do diagrama. A vCPU total líquida neste cluster é 210 (96+2*72), levando a uma proporção CPU:GPU de 30:1. Cada uma dessas instâncias otimizadas para computação será descarregada com uma tarefa intensiva de CPU de pré-processamento de dados e permitirá a utilização eficiente da GPU. Apesar do custo extra do ml.c5.18xlarge, a maior utilização da GPU permite um processamento mais rápido e, portanto, benefícios de desempenho de preço mais altos.

Quando usar clusters heterogêneos e outras alternativas

Nesta seção, explicamos como identificar um gargalo de CPU e discutimos como resolvê-lo usando a escala vertical de tipo de instância versus clusters heterogêneos.

A maneira rápida de identificar um gargalo de CPU é monitorar CPU e GPU métricas de utilização para trabalhos de treinamento do SageMaker em Amazon CloudWatch. Você pode acessar essas visualizações a partir do Console de gerenciamento da AWS no hiperlink de métricas de instância da página de trabalho de treinamento. Escolha as métricas relevantes e mude de resolução de 5 minutos para 1 minuto. Observe que a escala é de 100% por vCPU ou GPU, portanto, a taxa de utilização de uma instância com 4 vCPUs/GPUs pode chegar a 400%. A figura a seguir é um exemplo das métricas do CloudWatch, em que a CPU é aproximadamente 100% utilizada, indicando um gargalo da CPU, enquanto a GPU é subutilizada.

Para um diagnóstico detalhado, execute os trabalhos de treinamento com Depurador do Amazon SageMaker para criar um perfil de status de utilização de recursos, estatísticas e operações de estrutura, adicionando uma configuração de criador de perfil ao construir um estimador SageMaker usando o SageMaker Python SDK. Depois de enviar o trabalho de treinamento, revise o resultado relatório do criador de perfil para gargalos de CPU.

Se você concluir que seu trabalho pode se beneficiar de uma proporção de computação CPU:GPU mais alta, primeiro considere escalar para outro tipo de instância na mesma família de instâncias, se houver uma disponível. Por exemplo, se você estiver treinando seu modelo em ml.g5.8xlarge (32 vCPUs, 1 GPU), considere escalar até ml.g5.16xlarge (64 vCPUs, 1 GPU). Ou, se você estiver treinando seu modelo usando a instância multi-GPU ml.g5.12xlarge (48 vCPUs, 4 GPUs), considere dimensionar até ml.g5.24xlarge (96 vCPUs, 4 GPUs). Consulte o G5 especificação da família de instâncias para obter mais detalhes.

Às vezes, a expansão não é uma opção, porque não há nenhum tipo de instância com uma proporção vCPU:GPU mais alta na mesma família de instâncias. Por exemplo, se você estiver treinando o modelo em ml.trn1.32xlarge, ml.p4d.24xlarge ou ml.g5.48xlarge, você deve considerar clusters heterogêneos para treinamento do modelo SageMaker.

Além de escalar, gostaríamos de observar que existem alternativas adicionais para um cluster heterogêneo, como NVIDIA DALI, que descarrega o pré-processamento de imagem para a GPU. Para obter mais informações, consulte Superando gargalos de pré-processamento de dados com TensorFlow Data Service, NVIDIA DALI e outros métodos.

Para simplificar a tomada de decisão, consulte o fluxograma a seguir.

Como usar clusters heterogêneos do SageMaker

Para começar rapidamente, você pode pular diretamente para os exemplos do TensorFlow ou do PyTorch fornecidos como parte desta postagem.

Nesta seção, mostramos como usar um cluster heterogêneo do SageMaker com um exemplo simples. Assumimos que você já sabe como treinar um modelo com o SDK SageMaker Python e a classe Estimator. Se não, consulte Usando o SDK Python do SageMaker antes de continuar.

Antes desse recurso, você inicializava a classe Estimator do job de treinamento com o InstanceCount e os parâmetros InstanceType, que pressupõem implicitamente que você tenha apenas um único tipo de instância (um cluster homogêneo). Com o lançamento de clusters heterogêneos, introduzimos o novo sagemaker.instance_group.InstanceGroup classe. Isso representa um grupo de uma ou mais instâncias de um tipo de instância específico, projetado para desempenhar uma função lógica (como processamento de dados ou otimização de rede neural. Você pode ter dois ou mais grupos e especificar um nome personalizado para cada grupo de instâncias, a instância tipo e o número de instâncias para cada grupo de instâncias. Para obter mais informações, consulte Usando o SDK Python do SageMaker e Usando as APIs SageMaker de baixo nível.

Depois de definir os grupos de instâncias, você precisa modificar seu script de treinamento para ler o SageMaker informações do ambiente de treinamento que inclui configuração de cluster heterogêneo. A configuração contém informações como os grupos de instâncias atuais, os hosts atuais em cada grupo e em qual grupo o host atual reside com sua classificação. Você pode criar lógica em seu script de treinamento para atribuir os grupos de instâncias a determinadas tarefas de treinamento e processamento de dados. Além disso, seu script de treinamento precisa cuidar da comunicação do grupo entre instâncias ou dos mecanismos de carregamento de dados distribuídos (por exemplo, tf.data.service no TensorFlow ou genérico gRPC cliente-servidor) ou qualquer outra estrutura (por exemplo, Apache Spark).

Vamos passar por um exemplo simples de iniciar um trabalho de treinamento heterogêneo e ler a configuração do ambiente em tempo de execução.

1. Ao definir e iniciar o job de treinamento, configuramos dois grupos de instâncias usados ​​como argumentos para o estimador do SageMaker:

   from sagemaker.instance_group import InstanceGroup
   data_group = InstanceGroup("data_group", "ml.c5.18xlarge", 2)
   dnn_group = InstanceGroup("dnn_group", "ml.p4d.24xlarge", 1)
   
   from sagemaker.pytorch import PyTorch
   estimator = PyTorch(...,
       entry_point='launcher.py',
       instance_groups=[data_group, dnn_group]
   )

2. No script de treinamento do ponto de entrada (chamado launcher.py), lemos a configuração do cluster heterogêneo para saber se a instância executará o código de pré-processamento ou DNN:

   from sagemaker_training import environment
   env = environment.Environment()
   if env.current_instance_group == 'data_group': ...;

Com isso, vamos resumir as tarefas que o SageMaker realiza em seu nome e as tarefas pelas quais você é responsável.

O SageMaker executa as seguintes tarefas:

1. Provisione diferentes tipos de instância de acordo com a definição do grupo de instâncias.
2. Provisione canais de entrada em todos ou em grupos de instâncias específicos.
3. Distribua scripts de treinamento e dependências para instâncias.
4. Configure um cluster MPI em um grupo de instâncias específico, se definido.

Você é responsável pelas seguintes tarefas:

1. Modifique seu script de job de treinamento inicial para especificar grupos de instâncias.
2. Implemente um pipeline de dados distribuídos (por exemplo, tf.data.service).
3. Modifique seu script de ponto de entrada (consulte launcher.py no notebook de exemplo) para ser um único ponto de entrada que será executado em todas as instâncias, detectará em qual grupo de instâncias está sendo executado e acionará o comportamento relevante (como processamento de dados ou otimização de DNN).
4. Quando o loop de treinamento terminar, você deve certificar-se de que seu processo de ponto de entrada seja encerrado em todas as instâncias em todos os grupos de instâncias. Isso é importante porque o SageMaker espera que todas as instâncias terminem o processamento antes de marcar o trabalho como concluído e interromper o faturamento. o launcher.py O script nos notebooks de exemplo do TensorFlow e do PyTorch fornece uma implementação de referência de sinalizar instâncias do grupo de dados para sair quando as instâncias do grupo DNN terminarem seu trabalho.

Notebooks de exemplo para clusters heterogêneos do SageMaker

Nesta seção, apresentamos um resumo das cadernos de exemplo para estruturas TensorFlow e PyTorch ML. Nos notebooks, você pode encontrar os detalhes da implementação, orientações sobre como o código funciona, trechos de código que podem ser reutilizados em seus scripts de treinamento, diagramas de fluxo e análise de comparação de custos.

Observe que em ambos os exemplos, você não deve esperar que o modelo convirja de maneira significativa. Nossa intenção é apenas medir o pipeline de dados e a taxa de transferência de otimização da rede neural expressa em tempo de época/passo. Você deve comparar com seu próprio modelo e conjunto de dados para produzir benefícios de desempenho de preço que correspondam à sua carga de trabalho.

Cluster heterogêneo usando um carregador de dados distribuído baseado em tf.data.service (TensorFlow)

Esta caderno demonstra como implementar um cluster heterogêneo para treinamento do SageMaker usando o TensorFlow tf.data.service pipeline de dados distribuídos. Treinamos um modelo de visão computacional de aprendizado profundo Resnet50 que requer aumento de dados com uso intensivo de CPU. Ele usa Horvod para paralelismo de dados distribuídos multi-GPU.

Executamos a carga de trabalho em duas configurações: primeiro como um cluster homogêneo, instância única ml.p4d.24xlarge, usando um padrão tf.data pipeline que mostra gargalos de CPU levando a uma menor utilização de GPU. Na segunda execução, alternamos de um único tipo de instância para dois grupos de instâncias usando um cluster heterogêneo do SageMaker. Essa execução descarrega parte do processamento de dados para instâncias de CPU adicionais (usando tf.data.service).

Em seguida, comparamos as configurações homogêneas e heterogêneas e encontramos os principais benefícios de desempenho de preço. Conforme mostrado na tabela a seguir, o job heterogêneo (86ms/step) é 2.2 vezes mais rápido para treinar do que o job homogêneo (192ms/step), tornando 46% mais barato treinar um modelo.

Exemplo 1 (TF)	ml.p4d.24xl	ml.c5.18xl	Preço por hora*	Tempo médio da etapa	Custo por Etapa	Melhoria do desempenho do preço
homogéneo	1	0	$37.688	192 ms	$0.201	.
Heterogêneo	1	2	$45.032	86 ms	$0.108	46%

* O preço por hora é baseado em us-east-1 Preços sob demanda do SageMaker

Essa aceleração é possível utilizando a vCPU extra, fornecida pelo grupo de dados, e um pré-processamento mais rápido. Veja o caderno para mais detalhes e gráficos.

Cluster heterogêneo usando um carregador de dados distribuído baseado em cliente-servidor gRPC (PyTorch)

Esta caderno demonstra uma carga de trabalho de amostra usando um cluster heterogêneo para treinamento do SageMaker usando um carregador de dados distribuído baseado em gRPC cliente-servidor. Este exemplo usa uma única GPU. Usamos o modelo PyTorch com base no seguinte exemplo oficial do MNIST. O código de treinamento foi modificado para ser pesado no pré-processamento de dados. Treinamos esse modelo nos modos de cluster homogêneo e heterogêneo e comparamos o desempenho do preço.

Neste exemplo, presumimos que a carga de trabalho não pode se beneficiar de várias GPUs e depende de uma arquitetura de GPU específica (NVIDIA V100). Executamos trabalhos de treinamento homogêneos e heterogêneos e encontramos os principais benefícios de desempenho de preço, conforme mostrado na tabela a seguir. O trabalho heterogêneo (1.19s/passo) é 6.5 vezes mais rápido para treinar do que o trabalho homogêneo (0.18s/passo), tornando 77% mais barato treinar um modelo.

Exemplo 2 (PT)	ml.p3.2xl	ml.c5.9xl	Preço por hora*	Tempo médio da etapa	Custo por Etapa	Melhoria do desempenho do preço
homogéneo	1	0	$3.825	1193 ms	$0.127	.
Heterogêneo	1	1	$5.661	184 ms	$0.029	77%

* O preço por hora é baseado em us-east-1 Preços sob demanda do SageMaker

Isso é possível porque com uma contagem de CPU mais alta, poderíamos usar 32 trabalhadores do carregador de dados (em comparação com 8 com ml.p3.2xlarge) para pré-processar os dados e manter a GPU próxima a 100% utilizada em intervalos frequentes. Veja o caderno para mais detalhes e gráficos.

Aglomerados heterogêneos em Mobileye

A Mobileye, uma empresa da Intel, desenvolve sistemas avançados de assistência ao motorista (ADAS) e tecnologias de veículos autônomos com o objetivo de revolucionar o setor de transporte, tornar as estradas mais seguras e salvar vidas. Essas tecnologias são habilitadas usando modelos sofisticados de visão computacional (CV) que são treinados usando o SageMaker em grandes quantidades de dados armazenados em Serviço de armazenamento simples da Amazon (Amazônia S3). Esses modelos usam técnicas de rede neural de aprendizado profundo de última geração.

Observamos que, para um de nossos modelos de CV, o gargalo da CPU foi causado principalmente pelo pré-processamento pesado de dados, levando a GPUs subutilizadas. Para essa carga de trabalho específica, começamos a procurar soluções alternativas, avaliamos tecnologias de pipeline de dados distribuídos com clusters heterogêneos baseados em instâncias do EC2 e criamos implementações de referência para ambos TensorFlow e PyTorch. O lançamento do cluster heterogêneo do SageMaker nos permite executar essa e outras cargas de trabalho semelhantes no SageMaker para obter melhores benefícios de desempenho de preço.

Considerações

Com o lançamento do recurso de cluster heterogêneo, o SageMaker oferece muito mais flexibilidade para misturar e combinar tipos de instância em seu trabalho de treinamento. No entanto, considere o seguinte ao usar esse recurso:

• O recurso de cluster heterogêneo está disponível por meio do SageMaker PyTorch e TensorFlow classes de estimador de framework. As estruturas compatíveis são PyTorch v1.10 ou posterior e TensorFlow v2.6 ou posterior.
• Todos os grupos de instâncias compartilham a mesma imagem do Docker.
• Todos os grupos de instâncias compartilham o mesmo script de treinamento. Portanto, seu script de treinamento deve ser modificado para detectar a qual grupo de instâncias ele pertence e a bifurcação deve ser executada de acordo.
• Os nomes de host das instâncias de treinamento (por exemplo, alog-1, algo-2 e assim por diante) são atribuídos aleatoriamente e não indicam a qual grupo de instâncias eles pertencem. Para obter a função da instância, recomendamos obter sua associação ao grupo de instâncias durante o tempo de execução. Isso também é relevante ao revisar os logs em CloudWatch, porque o nome do fluxo de logs [training-job-name]/algo-[instance-number-in-cluster]-[epoch_timestamp] tem o nome do host.
• Uma estratégia de treinamento distribuído (geralmente um cluster MPI) pode ser aplicada apenas a um grupo de instâncias.
• SageMaker Piscinas aquecidas gerenciadas e SageMaker Modo local não pode ser usado atualmente com treinamento de cluster heterogêneo.

Conclusão

Neste post, discutimos quando e como usar o recurso de cluster heterogêneo do treinamento do SageMaker. Demonstramos uma melhoria de desempenho de preço de 46% em um caso de uso do mundo real e ajudamos você a começar rapidamente com o carregador de dados distribuído (tf.data.service e gRPC cliente-servidor). Você pode usar essas implementações com alterações mínimas de código em seus scripts de treinamento existentes.

Para começar, experimente o nosso cadernos de exemplo. Para saber mais sobre esse recurso, consulte Treinar usando um cluster heterogêneo.

---

Sobre os autores

Gili Nachum é um arquiteto de soluções especialista em IA/ML sênior que trabalha como parte da equipe EMEA Amazon Machine Learning. Gili é apaixonado pelos desafios de treinar modelos de aprendizado profundo e como o aprendizado de máquina está mudando o mundo como o conhecemos. Nas horas vagas, Gili gosta de jogar tênis de mesa.

Hrushikesh Gangur é o principal arquiteto de soluções para startups de IA/ML com experiência em treinamento de ML e rede da AWS. Ele ajuda startups em tecnologias de Autonomous Vehicle, Robotics, CV, NLP, MLOps, ML Platform e Robotics Process Automation para executar seus negócios de forma eficiente e eficaz na AWS. Antes de ingressar na AWS, Hrushikesh adquiriu mais de 20 anos de experiência no setor principalmente em plataformas de nuvem e dados.

Gal Oshri é gerente de produto sênior da equipe do Amazon SageMaker. Ele tem 7 anos de experiência trabalhando em ferramentas, frameworks e serviços de Machine Learning.

Chaim Rand é um desenvolvedor de algoritmos de aprendizado de máquina que trabalha em tecnologias de aprendizado profundo e visão computacional para soluções de veículos autônomos na Mobileye, uma empresa da Intel. Confira o seu Blogs.