O blog da AWS
Identifique gargalos, melhore a utilização de recursos e reduza os custos de treinamento de ML com a funcionalidade de deep profiling no Amazon SageMaker Debugger
Por Mona Mona, Prem Ranga e Sireesha Muppala
O aprendizado de máquina (ML) demonstrou um grande potencial para aplicação em diversos campos, como análise preditiva, processamento de fala, reconhecimento de imagem, sistemas de recomendação, bioinformática e muito mais. Treinar modelos de ML é um processo intensivo em tempo e computação, exigindo várias execuções de treinamento com hiperparâmetros diferentes até que um modelo atinja precisão aceitável. O treinamento distribuído baseado em CPU e GPU com frameworks como Horovod e Parameter Servers endereça esse problema, permitindo que o treinamento seja facilmente escalável para um cluster. No entanto, o treinamento distribuído dificulta a identificação e depuração de gargalos de recursos. Obter informações sobre o treinamento em andamento, tanto no nível do framework de ML quanto no nível dos recursos computacionais subjacentes, é um passo crítico para entender os padrões de uso de recursos e reduzir o desperdício. Analisar problemas de gargalo é tarefa necessária para maximizar a utilização de recursos computacionais e otimizar o desempenho do treinamento para produzir modelos de ML estado da arte com a precisão desejada.
O Amazon SageMaker é um serviço totalmente gerenciado que permite que desenvolvedores e cientistas de dados criem, treinem e implementem modelos de ML em grande escala com rapidez e facilidade. O Amazon SageMaker Debugger (que nos referiremos como Debugger) é um recurso do treinamento do SageMaker que facilita o treinamento mais rápido de modelos de ML, capturando métricas em tempo real, como gradientes e pesos. Isso fornece transparência no processo de treinamento, para que você possa corrigir anomalias em funções de custo, overfitting e overtraining. O Debugger fornece regras pré-configuradas para analisar facilmente dados emitidos, incluindo tensores, que são críticos para o sucesso dos trabalhos de treinamento.
Com a nova funcionalidade de profiling, o Debugger agora monitora automaticamente os recursos do sistema, como CPU, GPU, rede, E/S e memória, fornecendo uma visualização completa da utilização de recursos dos trabalhos de treinamento. Você também pode criar o perfil de todo o seu trabalho de treinamento ou partes dele para emitir métricas detalhadas do framework durante diferentes fases do trabalho de treinamento. As métricas do framework são métricas capturadas de dentro do script de treinamento, como duração de cada etapa, carregamento de dados, pré-processamento e tempo de execução na CPU e GPU.
O Debugger correlaciona as métricas do sistema e do framework, o que ajuda a identificar possíveis causas raiz. Por exemplo, se a utilização na GPU cair para zero, você poderá inspecionar o que está acontecendo dentro do script de treinamento neste momento específico. Você pode dimensionar os recursos corretos, identificar rapidamente gargalos e corrigi-los usando insights do profiler.
Você pode realocar recursos com base em recomendações da funcionalidade de profiling. Métricas e insights são capturados e monitorados programaticamente usando o SDK Python do SageMaker ou visualmente por meio do Amazon SageMaker Studio.
Neste post, demonstramos a funcionalidade de profiling do Debugger usando um caso de uso de análise de sentimento baseado em TensorFlow. No notebook incluído neste post, definimos uma Rede Neural Convolucional (CNN) usando o modo de script TensorFlow no SageMaker. Para nosso conjunto de dados, usamos o conjunto de dados IMDB, que consiste em críticas de filmes rotuladas como sentimento positivo ou negativo. Usamos o Debugger para mostrar como obter visibilidade sobre a utilização de recursos das instâncias de treinamento, criar perfil de métricas de framework e identificar componentes subutilizados devido a gargalos. Demonstramos ainda mais como melhorar a utilização de recursos depois de implementar as recomendações do Debugger.
Visão geral do passo a passo
O restante desse post detalha como usar o profiler do SageMaker Debugger para obter visibilidade em trabalhos de treinamento de ML e análise das recomendações do profiler. O notebook inclui detalhes sobre o uso de treinamento distribuído TensorFlow com Horovod, onde a capacidade de criação de perfil nos permitiu melhorar a utilização de recursos em até 36%. A primeira execução de treinamento foi em três instâncias p3.8xlarge por 503 segundos, e a segunda execução de treinamento após a implementação das recomendações do profiler levou 502 segundos em duas instâncias p3.2xlarge, resultando em economia de custos de 83%. A análise do profiler da segunda execução de treinamento forneceu recomendações adicionais que destacam a possibilidade de mais economia de custos e melhor utilização dos recursos.
O passo a passo inclui as seguintes etapas:
- Treinamento de um modelo de CNN para análise de sentimento com TensorFlow e usando o treinamento distribuído do SageMaker com configuração personalizada do profiler.
- Visualização das métricas do sistema e do framework geradas e posterior análise dos dados do profiler.
- Acesso ao Debugger Insights no SageMaker Studio.
- Análise do relatório do profiler gerado pelo Debugger .
- Análise e implementação de recomendações do relatório do profiler.
Etapas adicionais, como importar as bibliotecas necessárias e examinar o conjunto de dados, estão incluídas no notebook. Revise o notebook para obter todos detalhes.
Treinamento de um modelo de CNN usando o treinamento distribuído do SageMaker com configuração personalizada do profiler
Nesta etapa, você treina o modelo de análise de sentimento usando o estimador do TensorFlow com o profiler ativado.
Primeiro, certifique-se de que as bibliotecas do Debugger sejam importadas. Consulte o seguinte código:
# import debugger libraries
from sagemaker.debugger import ProfilerConfig, DebuggerHookConfig, Rule, ProfilerRule, rule_configs, FrameworkProfile
Em seguida, configure a distribuição Horovod para treinamento distribuído com TensorFlow. Horovod é um framework de treinamento distribuído de deep learning para TensorFlow, Keras e PyTorch. O objetivo é utilizar um script de treinamento para uma GPU única e dimensioná-lo com sucesso para treinar várias GPUs em paralelo. Depois que um script de treinamento foi escrito visando a escala com Horovod, ele pode ser executado em uma única GPU, várias GPUs ou até mesmo vários hosts sem quaisquer alterações adicionais de código. Além de ser fácil de usar, Horovod é rápido. Para obter mais informações, consulte a página do Horovod no GitHub.
Podemos configurar hiperparâmetros como número de épocas, tamanho do lote e aumento de dados:
Alterar esses hiperparâmetros pode afetar a utilização de recursos em seu trabalho de treinamento.
Para nosso treinamento, começamos a usar três instâncias p3.8xlarge (depois alteraremos nossa configuração de treinamento com base nas recomendações do profiler do SageMaker Debugger):
A instância p3.8xlarge vem com 4 GPUs e 32 núcleos de vCPU com desempenho de rede de 10 Gbps. Para obter mais informações, consulte Tipos de instância do Amazon EC2. Leve em consideração os limites da conta da AWS ao configurar o instance_type e o instance_count do cluster.
Em seguida, definimos a configuração do profiler. Com a seguinte configuração de parâmetro profiler_config , o Debugger chama as configurações padrão de monitoramento e criação de perfil. Ele monitora as métricas do sistema a cada 500 milissegundos. Você especifica detalhes adicionais sobre quando iniciar e qual a duração da execução do profiler. Você pode definir diferentes configurações no profiler para inspecionar etapas específicas e intervalos de tempo em detalhes.
profiler_config = ProfilerConfig( system_monitor_interval_millis=500, framework_profile_params=FrameworkProfile(start_step=2, num_steps=7) )
Para obter uma lista completa de parâmetros, consulte do Amazon SageMaker Debugger.
Em seguida, configuramos um trabalho de treinamento usando o estimador TensorFlow e passamos a configuração do profiler. Para framework_version e py_version, especifique a versão do framework TensorFlow e a versão Python suportada, respectivamente:
estimator = TensorFlow(
role=sagemaker.get_execution_role(),
base_job_name= 'tf-keras-silent',
image_uri=f"763104351884.dkr.ecr.{region}.amazonaws.com/tensorflow-training:2.3.1-gpu-py37-cu110-ubuntu18.04",
model_dir=model_dir,
instance_count=instance_count,
instance_type=train_instance_type,
entry_point= 'sentiment-distributed.py',
source_dir='./tf-sentiment-script-mode',
profiler_config=profiler_config,
script_mode=True,
hyperparameters=hyperparameters,
distribution=distributions
)
Para obter uma lista completa das versões de framework suportadas e da versão correspondente do Python a ser usada, consulte o Amazon SageMaker Debugger.
Finalmente, inicie o trabalho de treinamento:
estimator.fit(inputs, wait= False)
Visualizando as métricas do sistema e do framework geradas
Agora que nosso trabalho de treinamento está sendo executado, podemos realizar uma análise interativa dos dados capturados pelo Debugger . A análise é organizada na ordem das fases de treinamento: inicialização, treinamento e finalização. Os resultados dos dados de criação de perfil são categorizados como métricas do sistema e métricas de algoritmo (framework). Depois que o trabalho de treinamento é iniciado, o Debugger começa a coletar métricas do sistema e do framework. A biblioteca smdebug fornece ferramentas de análise de perfil que permitem acessar e analisar os dados de criação de profiling.
Primeiro, coletamos as métricas de sistema e framework usando a biblioteca S3SystemMetricsReader :
from smdebug.profiler.system_metrics_reader import S3SystemMetricsReader import time path = estimator.latest_job_profiler_artifacts_path() system_metrics_reader = S3SystemMetricsReader(path)
Verifique se temos métricas disponíveis para análise:
while system_metrics_reader.get_timestamp_of_latest_available_file() == 0:
system_metrics_reader.refresh_event_file_list()
client = sagemaker_client.describe_training_job(
TrainingJobName=training_job_name
)
if 'TrainingJobStatus' in client:
training_job_status = f"TrainingJobStatus: {client['TrainingJobStatus']}"
if 'SecondaryStatus' in client:
training_job_secondary_status = f"TrainingJobSecondaryStatus: {client['SecondaryStatus']}"
Quando os dados estiverem disponíveis, podemos consultá-los e inspecioná-los:
system_metrics_reader.refresh_event_file_list() last_timestamp = system_metrics_reader.get_timestamp_of_latest_available_file() events = system_metrics_reader.get_events(0, last_timestamp)
Junto com o notebook, o SDK smdebug contém várias classes de utilidade que podem ser usadas para visualizações. A partir dos dados coletados, você pode visualizar os valores de utilização de CPU e GPU como um histograma usando a classe de utilitário MetricHistogram. O MetricHistogram calcula um histograma em valores de utilização de GPU e CPU. Os intervalos estão entre 0-100. Uma boa utilização do sistema significa que o centro da distribuição deve estar entre 80-90. No caso de treinamento com várias GPU, se as distribuições dos valores de utilização de GPU não forem semelhantes, isso indica um problema com a distribuição da carga de trabalho.
O código a seguir plota os histogramas por métrica. Para traçar somente métricas específicas, defina a lista select_dimensions e select_events. Uma dimensão pode ser CPUUtilization, GPUUtilization, ou GPUMemoryUtilization. Se nenhum evento for especificado, então, para a utilização da CPU, um histograma para cada núcleo único e uso total da CPU é mostrado.
from smdebug.profiler.analysis.notebook_utils.metrics_histogram import MetricsHistogram system_metrics_reader.refresh_event_file_list() metrics_histogram = MetricsHistogram(system_metrics_reader)
A captura de tela a seguir mostra nossos histogramas.
De forma semelhante às métricas do sistema, vamos recuperar todos os eventos emitidos a partir das métricas de framework ou algoritmo usando o seguinte código:
from smdebug.profiler.algorithm_metrics_reader import S3AlgorithmMetricsReader
framework_metrics_reader = S3AlgorithmMetricsReader(path)
events = []
while framework_metrics_reader.get_timestamp_of_latest_available_file() == 0 or len(events) == 0:
framework_metrics_reader.refresh_event_file_list()
last_timestamp = framework_metrics_reader.get_timestamp_of_latest_available_file()
events = framework_metrics_reader.get_events(0, last_timestamp)
framework_metrics_reader.refresh_event_file_list()
last_timestamp = framework_metrics_reader.get_timestamp_of_latest_available_file()
events = framework_metrics_reader.get_events(0, last_timestamp)
Podemos inspecionar um dos eventos gravados para obter o seguinte:
print("Event name:", events[0].event_name,
"\nStart time:", timestamp_to_utc(events[0].start_time/1000000000),
"\nEnd time:", timestamp_to_utc(events[0].end_time/1000000000),
"\nDuration:", events[0].duration, "nanosecond")
Event name: Step:ModeKeys.TRAIN
Start time: 2020-12-04 22:44:14
End time: 2020-12-04 22:44:25
Duration: 10966842000 nanosecond
Para obter mais informações sobre métricas de sistema e framework, consulte a documentação.
Em seguida, usamos a classe de utilitário StepHistogram para criar um histograma de valores de duração de etapas. Outliers em durações de etapas são uma indicação de um gargalo. Isso permite que você identifique facilmente clusters de valores de duração das etapas.
from smdebug.profiler.analysis.notebook_utils.step_histogram import StepHistogram framework_metrics_reader.refresh_event_file_list() step_histogram = StepHistogram(framework_metrics_reader)
A captura de tela a seguir mostra nossa visualização.
Para uma visualização alternativa das utilizações de CPU e GPU, o código a seguir cria um mapa de calor onde cada linha corresponde a uma métrica (utilizações de núcleo de CPU e GPU) e o eixo x é a duração do trabalho de treinamento. Ele permite que você detecte mais facilmente gargalos da CPU como, por exemplo, quando há uma baixa utilização na GPU, mas uma alta utilização de um ou mais núcleos.
from smdebug.profiler.analysis.notebook_utils.heatmap import Heatmap view_heatmap = Heatmap( system_metrics_reader, framework_metrics_reader, select_dimensions=["CPU", "GPU", "I/O"], # optional select_events=["total"], # optional plot_height=450 )
A captura de tela a seguir mostra o mapa de calor de um trabalho de treinamento que tem usado 4 GPUs e 32 núcleos de CPU. As primeiras linhas mostram a utilização das GPUs e as linhas restantes mostram a utilização em núcleos de CPU. Amarelo indica utilização máxima, e roxo significa que a utilização foi 0. As GPUs têm ciclos paralisados frequentes onde a utilização cai para 0, enquanto que, ao mesmo tempo, a utilização dos núcleos de CPU fica no máximo. Esta é uma indicação clara de um gargalo da CPU onde as GPUs estão aguardando a chegada dos dados. Tal gargalo pode ocorrer por um pré-processamento muito pesado de computação.
Acessando insights do Debugger no Studio
Você também pode usar o Studio para realizar treinamento com esse notebook. O Studio fornece visualizações integradas para analisar insights do profiling. Como alternativa, você pode mover para a próxima seção deste post para analisar diretamente o relatório do profiler.
Se você treinou em uma instância do notebook SageMaker, ainda poderá encontrar os insights do Debugger para esse treinamento no Studio se o treinamento aconteceu na mesma região.
Para obter mais informações sobre como configurar o Studio, consulte Configuração do Amazon SageMaker.
Revisando relatórios do Debugger
Depois de configurar e executar este notebook no Studio, você pode acessar o Debugger Insights.
- No painel de navegação, escolha Components and registries.
- Escolha Experiments and trails.
- Escolha seu trabalho de treinamento (clique com o botão direito).
- Escolha Open Debugger for insights.
Uma guia do Debugger é aberta para este trabalho de treinamento. Para obter mais informações, consulte Insights do Debugger.
Resumo do trabalho de treinamento
Esta seção do relatório mostra detalhes do trabalho de treinamento, como a hora de início, a hora de término, a duração e o tempo gasto em fases individuais do treinamento. A visualização do gráfico de pizza mostra uma comparação do tempo gasto nas fases de inicialização, treinamento e finalização.
Estatísticas de uso do sistema
Esta parte do relatório fornece estatísticas detalhadas sobre o uso do sistema para todas as instâncias de treinamento envolvidas no treinamento, juntamente com análises e sugestões de melhorias. O texto a seguir é um trecho do relatório, com as principais questões destacadas:
O 95º quantil da utilização total da GPU no nó “algo-1” é de apenas 13%. O 95º quantil da utilização total da CPU é de apenas 24%. O nó “algo-1” está subutilizado. Você pode considerar mudar para um tipo de instância menor. O 95º quantil da utilização total da GPU no nó “algo-2” é de apenas 13%. O 95º quantil da utilização total da CPU é de apenas 24%. O nó “algo-2” está subutilizado. Você pode considerar mudar para um tipo de instância menor. O 95º quantil da utilização total da GPU no nó “algo-3” é de apenas 13%. O 95º quantil da utilização total da CPU é de apenas 24%. O nó “algo-3” está subutilizado. Você pode considerar mudar para um tipo de instância menor.
A tabela a seguir mostra estatísticas de uso por nó de trabalho, como utilização total de CPU e GPU, CPU total e uso de memória. A tabela também inclui tempo total de espera de E/S e total de bytes enviados e recebidos. A tabela mostra os valores mínimo e máximo, bem como os percentis p99, p90 e p50.
Resumo das métricas de framework
Nesta seção, os gráficos de pizza a seguir mostram o detalhamento das operações de framework em CPUs e GPUs.
Insights
O Insights fornece sugestões e detalhes adicionais, como o número de vezes que cada regra foi acionada, os parâmetros da regra e limiares para avaliar o desempenho do trabalho de treinamento. De acordo com os insights para nosso trabalho de treinamento com TensorFlow, as regras do profiler foram executadas (e problemas foram encontrados) para três dos oito insights. A captura de tela a seguir mostra os insights.
Se você escolher um insight, poderá visualizar as recomendações do profiler.
Por padrão, estamos mostrando o relatório de visão geral, mas você pode escolher Nodes para mostrar o painel.
Você pode expandir cada nó para obter informações detalhadas, como utilização de CPU, utilização de rede e métricas do sistema durante o treinamento.
Além disso, você pode analisar a utilização da memória da GPU ao longo do tempo e a utilização do sistema ao longo do tempo para cada nó.
Analisando o relatório do profiler gerado pelo Debugger
Faça o download do relatório do profiler escolhendo Download report.
Como alternativa, se você não estiver usando o Studio, você pode baixar seu relatório diretamente do Amazon Simple Storage Service (Amazon S3) em s3://<your bucket>/tf-keras-sentiment-<job id>/profiler-output/.
Em seguida, analisamos algumas seções do relatório gerado. Para obter detalhes adicionais, consulte Relatório do Debugger do SageMaker. Você também pode usar a biblioteca do SMDebug para analisar os dados.
Resumo das métricas de framework
Nesta seção do relatório, você verá um gráfico de pizza do trabalho de treinamento que mostra o tempo gasto na fase de treinamento, na fase de validação ou “outros”. “Outros” representa o tempo acumulado entre as etapas; ou seja, o tempo entre quando uma etapa terminou, mas a próxima etapa não foi iniciada. Idealmente, a maioria do tempo deve ser gasto em etapas de treinamento.
Identificando o operador de CPU mais custoso
Esta seção fornece informações sobre os operadores de CPU em detalhes. A tabela mostra a porcentagem do tempo e o tempo cumulativo absoluto gasto nos operadores de CPU mais frequentemente chamados.
A tabela a seguir mostra uma lista de operadores que seu trabalho de treinamento executa na CPU. O operador mais caro na CPU foi ExecutorState::Process com 16%.
Identificando o operador de GPU mais custoso
Esta seção fornece informações sobre os operadores de GPU em detalhes. A tabela mostra a porcentagem do tempo e o tempo cumulativo absoluto gasto nos operadores de GPU mais frequentemente chamados.
A tabela a seguir mostra uma lista de operadores que seu trabalho de treinamento executou na GPU. O operador mais caro na GPU foi Adam com 29%.
Resumo das regras
Nesta seção, o Debugger agrega todos os resultados da avaliação de regras, análises, descrições de regras e sugestões. A tabela a seguir mostra um resumo das regras do profiler executadas. A tabela é classificada pelas regras que são acionadas com mais frequência. No trabalho de treinamento, esse foi o caso da regra LowGPUUtilization. Ela processou 1.001 datapoints e foi acionada 8 vezes.
Como as regras foram acionadas para LowGPUUTilization, Batchsize, e CPUBottleneck, vamos aprofundar em cada uma e entender as recomendações do profiler.
LowGPUUtilization
A regra LowGPUUTilization verifica o uso de GPU baixo e flutuante. Se o uso for consistentemente baixo, as causas podem ser gargalos ou um tamanho batch ou modelo muito pequeno. Se o uso estiver fortemente flutuando, a causa pode ser gargalos ou bloqueio de chamadas.
A regra computou o 95º e 5º quantil de utilização de GPU em 500 datapoints contínuos e encontrou oito casos em que o p95 estava acima de 70% e o p5 estava abaixo de 10%. Se o p95 é alto e o p5 é baixo, isso indica que o uso é altamente flutuante. Se ambos os valores forem muito baixos, isso significa que a máquina está subutilizada. Durante a inicialização, a utilização é provavelmente 0, portanto, a regra ignorou os primeiros 1.000 datapoints. A regra analisou 1.001 datapoints e foi acionada oito vezes. Além disso, também é fornecido o momento em que esta regra foi acionada pela última vez.
BatchSize
A regra Batchsize ajuda a detectar se a GPU é subutilizada devido ao tamanho do batch ser muito pequeno. Para detectar isso, a regra analisa o uso de memória da GPU e a utilização de CPU e GPU. A regra analisou 1.000 datapoints e foi acionada quatro vezes. Seu trabalho de treinamento está subutilizando a instância. Você pode considerar mudar para um tipo de instância menor ou aumentar o tamanho do batch de treinamento do modelo. Além disso, também é fornecido o momento em que esta regra foi acionada pela última vez.
O boxplot a seguir é uma captura de tela dessa data/hora que mostra para cada nó a utilização total da CPU e a utilização e o uso de memória por GPU.
CPUBottleneck
A regra CPUBottleneck verifica quando a utilização da CPU estava acima do cpu_threshold de 90% e a utilização da GPU estava abaixo do gpu_threshold de 10%. Durante a inicialização, a utilização é provavelmente 0, portanto, a regra ignorou os primeiros 1.000 datapoints. Com esta configuração, a regra encontrou 2.129 gargalos da CPU, que é 70% do tempo total. Isto está acima do limiar de 50%. A regra analisou 3.019 datapoints e foi acionada quatro vezes.
O gráfico a seguir (à esquerda) mostra quantos datapoints estavam abaixo do gpu_threshold de 10% e quantos desses pontos provavelmente foram causados por um gargalo da CPU. A regra encontrou 3.000 de 3.019 datapoints que tinham uma utilização de GPU abaixo de 10%. Desses pontos de dados, 70,52% provavelmente foram causados por gargalos de CPU. O segundo gráfico (à direita) mostra se os gargalos da CPU aconteceram principalmente durante o treinamento ou a fase de validação.
Analisando e implementando recomendações do relatório do profiler
Vamos agora analisar e implementar as recomendações do profiler para nosso trabalho de treinamento e melhorar a utilização de recursos. Primeiro vamos rever a configuração do nosso trabalho de treinamento e verificar as três regras que foram acionadas pelo Debugger durante a execução do treinamento.
A tabela a seguir resume a configuração do trabalho de treinamento.
| Tipo de instância | Número de instâncias | Número de processos por host | Configuração de profiling | Número de Epochs | Tamanho do batch |
| P3.8xLarge | 3 | 3 | FrameworkProfile(start_step=2, num_steps=7), Monitoring Interval = 500 milliseconds | 25 | 256 |
A tabela a seguir resume as recomendações de profiling do Debugger .
| Regra acionada | Razão | Recomendações |
| BatchSize | Verifica se a GPU é subutilizada devido ao tamanho do lote ser muito pequeno. | Execute em um tipo de instância menor ou aumente o tamanho do batch. |
| LowGPUUtilização | Verifica se a utilização da GPU é baixa ou sofre de flutuações. Isso pode acontecer se houver gargalos, muitas chamadas bloqueantes devido a sincronizações ou o tamanho do batch ser muito pequeno. | Verifique se há gargalos, minimize o bloqueio de chamadas, altere a estratégia de treinamento distribuído, aumente o tamanho do batch. |
| CPUBottleneck
|
Verifica se o uso da CPU é alto, mas o uso da GPU é baixo ao mesmo tempo, o que pode indicar um gargalo da CPU onde a GPU está aguardando a chegada dos dados da CPU. | Os gargalos da CPU podem acontecer quando o pré-processamento de dados é muito intensivo em computação. Você deve considerar aumentar o número de processos no dataloader ou aplicar pre-fetching. |
Com base na recomendação de mudar para um tipo de instância menor e aumentar o tamanho do lote, alteramos as configurações de treinamento e executamos novamente o treinamento. No notebook, as instâncias de treinamento são alteradas de instâncias p3.8xlarge para p3.2xlarge, o número de instâncias é reduzido para duas e apenas um processo por host para o MPI é configurado para aumentar o número de dataloaders. O tamanho do batch também é alterado em paralelo para 512.
A tabela a seguir resume a configuração do trabalho de treinamento revisado.
| Tipo de instância | Número de instâncias | Número de processos por host | Configuração de profiling | Número de Epochs | Tamanho do batch |
| P3.2xLarge | 2 | 1 | FrameworkProfile(start_step=2, num_steps=7), Monitoring Interval = 500 milliseconds | 25 | 512 |
Depois de executar o segundo trabalho de treinamento com as novas configurações, um novo relatório é gerado, mas sem regras acionadas, indicando que todos os problemas identificados na execução anterior foram resolvidos. Agora vamos comparar a análise do relatório dos dois trabalhos de treinamento e entender o impacto das alterações de configuração feitas.
O resumo do trabalho de treinamento mostra que o tempo de treinamento foi quase semelhante, com 502 segundos no treinamento revisado e com 503 segundos no primeiro treinamento. O tempo gasto no laço de treinamento para ambos os trabalhos de treinamento foi similares, 45%.
Examinando as estatísticas de uso do sistema nos mostra que a utilização da CPU e da GPU das duas instâncias de treinamento aumentou quando comparada à execução original. Para a primeira execução de treinamento, a utilização da GPU foi constante em 13,5% nas três instâncias para o 95º quantil de utilização de GPU, e a utilização da CPU foi constante em 24,4% nas três instâncias para o 95º quantil de utilização da CPU. Na segunda execução de treinamento, a utilização da GPU aumentou para 46% para o 95º quantil, e a utilização da CPU aumentou para 61% para o 95º quantil.
Embora nenhuma regra tenha sido acionada durante essa execução, ainda há espaço para melhorias na utilização de recursos.
A captura de tela a seguir mostra o resumo das regras para nossa execução de treinamento revisada.
Você pode continuar a ajustar seu trabalho de treinamento, alterar os parâmetros de treinamento, executar novamente o treinamento e comparar os resultados com as execuções de treinamento anteriores. Repita este processo para ajustar sua estratégia de treinamento e recursos de treinamento e alcançar a combinação ideal de custo de treinamento e desempenho de treinamento de acordo com as necessidades da sua empresa.
Otimização de custos
A tabela a seguir mostra uma comparação de custos das duas execuções de treinamento.
| Número de instâncias | Tipo de instância | Tempo de Treinamento (em Segundos) | Custo Horário da Instância ( us-west-2) |
Custo de Treinamento | Economia de custos | |
| Primeira execução de treinamento | 3 | p3.8xlarge | 503 | 14,688 US$ | $6.16 | N/A |
| Segunda execução de treinamento com recomendações de profiling do Debugger | 2 | p3.2xlarge | 502 | $3,825 | $1,07 | 82,6% |
Considerando o custo das instâncias de treinamento em uma região específica, por exemplo us-west-2, o treinamento com três instâncias ml.p3.8xlarge por 503 segundos custa US$6,16 e o treinamento com dois ml.p3.2xlarge por 502 segundos custa US$1,07. Isso é uma economia de 83% de custos simplesmente implementando a recomendação do profiler e reduzindo o tamanho da instância.
Conclusão
A funcionalidade de profiling do SageMaker Debugger é uma ferramenta poderosa para ganhar visibilidade nos trabalhos de treinamento de ML. Neste post, fornecemos informações sobre a utilização de recursos de treinamento para identificar gargalos, analisar as várias fases do treinamento e identificar funções caras no framework. Também mostramos como analisar e implementar recomendações do profiler. Aplicamos recomendações do profiler a um treinamento distribuído com TensorFlow Horovod para um modelo de análise de sentimento e alcançamos uma melhoria na utilização de recursos de até 60% e economia de 83%. O Debugger fornece funcionalidades de criação de perfil para todas os principais frameworks de aprendizado profundo, incluindo TensorFlow, PyTorch e Keras.
Experimente o profiler do Debugger e deixe seu feedback nos comentários. Para obter informações adicionais sobre o SageMaker Debugger, confira o post do lançamento abaixo.
Este artigo foi traduzido do Blog da AWS em Inglês.
Sobre os Autores
Mona Mona é uma Arquiteta de Soluções Especializadas em AI/ML com sede em Arlington, VA. Ela trabalha com a equipe do setor público mundial e ajuda os clientes a adotar o aprendizado de máquina em grande escala. Antes de ingressar na Amazon, ela trabalhou como consultora de TI e concluiu seu mestrado em Computer Information Systems pela Georgia State University, com foco em análise de big data. Ela é apaixonada por NLP e explicabilidade em AI/ML.
Prem Ranga é um Arquiteto de Soluções no setor de Enterprise com sede em Houston, Texas. Ele faz parte da Comunidade Técnica de aprendizado de máquina AWS e adora trabalhar com os clientes em sua jornada de ML e IA. Prem é apaixonado por robótica, é um pesquisador de Veículos Autônomos, e também construiu uma solução Beer Pours controlada pela Alexa em Houston e outros locais.
Sireesha Muppala é uma arquiteta de soluções especialista em AI/ML, fornecendo orientação aos clientes sobre como arquitetar e implementar soluções de machine learning em grande escala. Ela recebeu seu Ph.D. em Ciência da Computação pela Universidade do Colorado, Colorado Springs. Em seu tempo livre, Sireesha adora correr e caminhar trilhas no Colorado.
Revisor
Marcelo Cunha é um arquiteto de soluções da AWS especialista em AI/ML. Em sua função, ele ajuda os clientes a criar soluções de ML para resolver os seus desafios de negócio utilizando a plataforma AWS. De uma família de médicos e profissionais da saúde, ele também tem interesse em aplicações de ML nesse setor.