Práticas recomendadas para treinamento de aceleração do TensorFlow 1.x no Amazon SageMaker

Hoje, muitos clientes estão usando o TensorFlow para treinar modelos de aprendizado profundo para sua taxa de cliques em recomendações de publicidade e personalização no comércio eletrônico. À medida que o comportamento de seus clientes muda, eles podem acumular grandes quantidades de novos dados todos os dias. A iteração do modelo é um dos trabalhos diários de um cientista de dados, mas eles enfrentam o problema de demorar muito para treinar em grandes conjuntos de dados.

Amazon Sage Maker é uma plataforma de aprendizado de máquina (ML) totalmente gerenciada que pode ajudar os cientistas de dados a se concentrarem em modelos em vez de infraestrutura, com suporte nativo para algoritmos e estruturas como TensorFlow e PyTorch. O SageMaker oferece opções flexíveis de treinamento distribuído que se ajustam aos seus fluxos de trabalho específicos. Como muitos cientistas de dados podem não ter experiência no processo de treinamento de aceleração, neste post mostramos os fatores que importam para o treinamento rápido de modelos de deep learning e as melhores práticas de treinamento de aceleração para TensorFlow 1.x no SageMaker. Também temos um código de exemplo de Deep FM treinamento distribuído no SageMaker no GitHub repo.

Há muitos fatores que você deve considerar para maximizar a utilização da CPU/GPU ao executar o script do TensorFlow no SageMaker, como infraestrutura, tipo de acelerador, método de treinamento distribuído, método de carregamento de dados, treinamento de precisão mista e muito mais.

Discutimos as melhores práticas nas seguintes áreas:

• Acelere o treinamento em uma única instância
• Acelere o treinamento em várias instâncias
• Pipelines de dados
• Treinamento automático de precisão mista

Acelere o treinamento em uma única instância

Ao executar o script do TensorFlow em uma única instância, você pode escolher uma série otimizada para computador, como a Amazon Elastic Compute Nuvem (Amazon EC2) série C5 ou uma série de computação acelerada com várias GPUs em uma única instância, como p3.8xlarge, p3.16xlarge, p3dn.24xlarge e p4d.24xlarge.

Nesta seção, discutimos estratégias para várias CPUs em uma única instância e treinamento distribuído com várias GPUs em uma única instância.

Várias CPUs em uma única instância

Nesta seção, discutimos a configuração manual do paralelismo dos operadores em dispositivos de CPU, o método de torre, TensorFlow MirroredStrategy e Horovod.

Configurando manualmente o paralelismo dos operadores em dispositivos de CPU

O TensorFlow seleciona automaticamente o número apropriado de threads para paralelizar o cálculo da operação no processo de treinamento. No entanto, você pode definir o intra_op pool de fios e inter_op configurações de paralelismo fornecidas pelo TensorFlow e use variáveis ​​de ambiente de MKL-DNN para definir a vinculação para o encadeamento do SO. Veja o seguinte código:

# Set parallelism of intra_op and inter_op
num_cpus = int(os.environ['SM_NUM_CPUS'])
config = tf.ConfigProto(allow_soft_placement=True, device_count={'CPU': num_cpus}, intra_op_parallelism_threads=num_cpus, inter_op_parallelism_threads=num_cpus)
run_config = tf.estimator.RunConfig().replace(session_config = config)

# Use Intel MKL-DNN Setting to accelerate training speed
os.environ["KMP_AFFINITY"]= "verbose,disabled"
os.environ['OMP_NUM_THREADS'] = str(num_cpus)
os.environ['KMP_SETTINGS'] = '1'

A variável de ambiente KMP_AFFINITY de MKL-DNN está definido para granularity=fine,compact,1,0 por padrão. Depois de definir intra e inter do TensorFlow para o número máximo de vCPUs da instância atual, o limite superior de uso da CPU é quase o mesmo que o número de núcleos físicos da instância de treinamento.

Se você definir os.environ["KMP_AFFINITY"]= "verbose,disabled", o thread do SO não está vinculado ao hyper thread de hardware e o uso da CPU pode exceder o número de núcleos físicos.

Em relação às configurações do intraparalelismo do TensorFlow, do inter paralelismo do TensorFlow e do número de threads MKL-DNN, diferentes combinações desses três parâmetros resultam em diferentes velocidades de treinamento. Portanto, você precisa testar cada caso para encontrar a melhor combinação. Uma situação comum é definir os três parâmetros (intra_op_parallelism_threads e inter_op_parallelism_threads para TensorFlow, os.environ['OMP_NUM_THREADS'] para MKL-DNN) para metade do número de vCPUs (núcleo físico) ou do número total de vCPUs.

Método da torre

Para replicar um modelo em GPUs, cada GPU obtém sua própria instância da passagem direta. A instância do passe para frente é chamada de Torre. O método de torre é quase sempre usado para dispositivos GPU. Para comparar a velocidade de treinamento com outros métodos, aqui também usamos o método da torre para nosso dispositivo de CPU.

Se você não definir o dispositivo de CPU manualmente, o TensorFlow não usará o método de torre para calcular a média dos gradientes, portanto, você não precisará dimensionar o tamanho do lote nesses casos.

1. Defina o dispositivo da CPU manualmente:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))

2. Use replicate_model_fn embrulhar model_fn:

DeepFM = tf.estimator.Estimator(model_fn=tf.contrib.estimator.replicate_model_fn(model_fn, devices=device_list), model_dir=FLAGS.model_dir, params=model_params, config=config)

3. Use TowerOptimizer embrulhar optimizer:

optimizer = tf.contrib.estimator.TowerOptimizer(optimizer)

4. Embrulhe o seu model_fn:

with tf.variable_scope(‘deepfm_model’, reuse=tf.AUTO_REUSE)

5. Dimensione o tamanho do lote para (NUM_CPU – 1).

Vejamos a diferença de utilização da CPU com o modo de torre habilitado. A figura a seguir mostra a utilização da CPU da instância ml.c5.18xlarge com a seguinte configuração:

Sem dados de torre + LibSVM + modo de canal + MKL-DNN desabilitar vinculação + configuração de paralelismo intra/inter operacional do TensorFlow para o número máximo de vCPUs da instância

A figura a seguir mostra a utilização da CPU da instância ml.c5.18xlarge com a seguinte configuração:

Torre com dispositivo de CPU definido + dados LibSVM + modo de canal + MKL-DNN desabilitar vinculação + configuração de paralelismo intra/inter operacional do TensorFlow para o número máximo de vCPUs da instância

O uso da CPU é maior ao usar o método de torre e excede o número de núcleos físicos.

Estratégia espelhada do TensorFlow

O TensorFlow MirroredStrategy significa treinamento síncrono em várias réplicas em uma máquina. Essa estratégia é normalmente usada para treinamento em uma máquina com várias GPUs. Para comparar a velocidade de treinamento com outro método, usamos MirroredStrategy para nosso dispositivo de CPU.

Ao usar o TensorFlow MirroredStrategy, se você não definir o dispositivo de CPU, o TensorFlow usará apenas uma CPU como único trabalhador, o que é um desperdício de recursos. Recomendamos configurar manualmente o dispositivo da CPU, pois ele fará uma operação de redução no /CPU:0, De modo a /CPU:0 dispositivo não é usado como uma réplica aqui. Veja o seguinte código:

device_list = []
if manual_CPU_device_set:
		cpu_prefix=’/cpu:’
		for I in range(1, num_cpus):
			devices_list.append(cpu_prefix + str(i))
mirrored_strategy = tf.distribute.MirroredStrategy(devices=devices_list)
	else:
mirrored_strategy = tf.distribute.MirroredStrategy()

# Set strategy to config:
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
eval_distribute=mirrored_strategy,
session_config = config)

Você precisa dimensionar o tamanho do lote ao usar MirroredStrategy; por exemplo, dimensione o tamanho do lote para um múltiplo do número de dispositivos GPU.

Para a subestratégia ao definir o dispositivo de CPU, se você não definir o cross_device_ops parâmetro em tf.distribute.MirroredStrategy(), o TensorFlow usa o ReductionToOneDevice subestratégia por padrão. No entanto, se você definir HierarchicalCopyAllReduce como a subestratégia, o TensorFlow apenas faz o trabalho de redução /CPU:0. Quando você usa a API do conjunto de dados do TensorFlow e distribui a estratégia em conjunto, o objeto do conjunto de dados deve ser retornado em vez de recursos e rótulos na função input_fn.

Normalmente, o TensorFlow MirroredStrategy é mais lento que o método de torre no treinamento da CPU, portanto, não recomendamos o uso do MirroredStrategy em um único host com várias CPUs.

Horovod

Horovod é uma estrutura de treinamento de aprendizado profundo distribuído para TensorFlow, Keras, PyTorch e Apache MXNet. O objetivo do Horovod é tornar o aprendizado profundo distribuído rápido e fácil de usar.

Existe um parâmetro de distribution na API do SageMaker Python SDK Estimator, que você pode usar para declarar o treinamento distribuído do Horovod. O SageMaker provisiona a infraestrutura e executa seu script com MPI. Veja o seguinte código:

hvd_processes_per_host = 4
distribution = {'mpi': { 
'enabled': True, 
'processes_per_host': hvd_processes_per_host,
'custom_mpi_options': '-verbose --NCCL_DEBUG=INFO -x OMPI_MCA_btl_vader_single_copy_mechanism=none' 
} 
}

Ao escolher uma instância de GPU, como ml.p3.8xlarge, você precisa fixar cada GPU para cada trabalhador:

config = tf.ConfigProto()
config.gpu_options.visible_device_list = str(hvd.local_rank())

Para acelerar a convergência do modelo, dimensione a taxa de aprendizado pelo número de trabalhadores de acordo com a documentação oficial do Horovod. No entanto, em projetos do mundo real, você deve dimensionar a taxa de aprendizado até certo ponto, mas não pelo número de trabalhadores, o que resulta em desempenho ruim do modelo. Por exemplo, se a taxa de aprendizado original for 0.001, dimensionamos a taxa de aprendizado para 0.0015, mesmo que o número de trabalhadores seja quatro ou mais.

Geralmente, apenas o primário (rank Horovod 0) salva o ponto de verificação e o modelo, bem como a operação de avaliação. Você não precisa dimensionar o tamanho do lote ao usar o Horovod. Ofertas do SageMaker Modo de tubo para transmitir dados de Serviço de armazenamento simples da Amazon (Amazon S3) em instâncias de treinamento. Ao habilitar o modo Pipe, esteja ciente de que diferentes trabalhadores no mesmo host precisam usar canais diferentes para evitar erros. Isso ocorre porque o primeiro processo de trabalho lê os dados do FIFO/canal e outros processos de trabalho na mesma instância travam porque não podem ler dados do mesmo FIFO/canal, portanto, o Horovod não funciona corretamente. Para evitar esse problema, defina os canais de acordo com o número de trabalhadores por instância. Pelo menos, certifique-se de que diferentes trabalhadores no mesmo host consumam canais diferentes; o mesmo canal pode ser consumido por trabalhadores em um host diferente.

Ao usar Horovod, você pode encontrar o seguinte erro:

“One or more tensors were submitted to be reduced, gathered or broadcasted by subset of ranks and are waiting for remainder of ranks for more than 60 seconds. This may indicate that different ranks are trying to submit different tensors or that only subset of ranks is submitting tensors, which will cause deadlock.”

A possível causa para esse problema é que uma determinada classificação (como a classificação 0) funciona mais lentamente ou faz mais trabalhos do que outras classificações, e isso faz com que outras classificações esperem muito tempo. Embora a classificação 0 às vezes tenha que fazer mais trabalho do que outras classificações, deve-se notar que a classificação 0 não deve fazer muito por um longo tempo. Por exemplo, para a avaliação do modelo no conjunto de validação e salvar pontos de verificação durante o treinamento, se for inevitável que essas operações demorem muito tempo, o que pode causar erros, uma solução alternativa é permitir que todos os trabalhadores façam o mesmo trabalho que a classificação 0 (pontos de verificação salvar, avaliar e assim por diante).

A fragmentação de dados é uma das coisas mais importantes a serem consideradas ao usar o treinamento distribuído. Você pode usar o TensorFlow dataset.shard() em seu roteiro. O SageMaker também oferece um recurso de fragmento de conjunto de dados no canal de entradas definindo distribution=S3shardbykey no canal do conjunto de dados. Veja o seguinte código:

dataset = PipeModeDataset(channel, record_format='TFRecord')

number_host = len(FLAGS.hosts)

if FLAGS.enable_data_multi_path : # If there are multi channels mapping with different S3 path
    if FLAGS.enable_s3_shard == False :
        if number_host > 1:
            index = hvd.rank() // FLAGS.worker_per_host
            dataset = dataset.shard(number_host, index)
else :
    if FLAGS.enable_s3_shard :
        dataset = dataset.shard(FLAGS.worker_per_host, hvd.local_rank())
    else :
        dataset = dataset.shard(hvd.size(), hvd.rank())

A figura a seguir mostra o resultado ao usar o Horovod (ml.c5.18xlarge, Horovod + LibSVM + configuração padrão intra op e inter op), que você pode comparar com o método de torre.

Treinamento distribuído com várias GPUs em uma única instância

É normal iniciar o treinamento distribuído com várias GPUs em uma única instância, porque os cientistas de dados precisam gerenciar apenas uma instância e aproveitar a interconexão de alta velocidade entre as GPUs. Os trabalhos de treinamento do SageMaker oferecem suporte a vários tipos de instância que têm várias GPUs em uma única instância, como ml.p3.8xlarge, ml.p3.16xlarge, ml.p3dn.24xlarge e ml.p4d.24xlarge. O método é o mesmo de várias CPUs em uma única instância, mas com algumas alterações no script.

Método da torre

O método de torre aqui é quase o mesmo do treinamento multi-CPU. Você precisa dimensionar o tamanho do lote de acordo com o número de GPUs em uso.

Estratégia espelhada do TensorFlow

A subestratégia padrão de MirroredStrategy is NcclAllReduce. Você precisa dimensionar o tamanho do lote de acordo com o número de GPUs em uso. Veja o seguinte código:

mirrored_strategy = tf.distribute.MirroredStrategy()
config = tf.estimator.RunConfig(train_distribute=mirrored_strategy,
				eval_distribute=mirrored_strategy)

Acelere o treinamento em várias instâncias

O dimensionamento é sempre uma opção para melhorar a velocidade do treinamento. Mais e mais cientistas de dados escolhem isso como uma opção padrão em relação ao treinamento distribuído. Nesta seção, discutimos estratégias para treinamento distribuído com vários hosts.

Várias CPUs com várias instâncias

Existem quatro métodos principais para usar várias CPUs com várias instâncias ao habilitar o treinamento distribuído:

• • Servidor de parâmetros sem configurar manualmente o paralelismo dos operadores em dispositivos de CPU
  • Servidor de parâmetros com configuração manual do paralelismo dos operadores em dispositivos de CPU
  • Servidor de parâmetros com torre (configurando dispositivos de CPU manualmente e allow_soft_placement=True in tf.ConfigProto)
  • Horovod

Ao usar um servidor de parâmetros no tf.estimator API, o caminho do ponto de verificação deve ser um caminho compartilhável, como Amazon S3 ou o caminho local de Serviço de arquivo elástico da Amazon (Amazon EFS) para o contêiner. Para um servidor de parâmetros em tf.keras, o caminho do ponto de verificação pode ser definido como o caminho local. Para Horovod, o caminho do ponto de verificação pode ser definido como um caminho local da instância de treinamento.

Ao usar um servidor de parâmetros e o tf.estimator API com o caminho do ponto de verificação para o Amazon S3, se o modelo for muito grande, você poderá encontrar um erro do primário travado ao salvar o ponto de verificação no S3. Você pode usar o contêiner integrado TensorFlow 1.15 ou TensorFlow 1.15.2 do SageMaker ou usar o Amazon EFS como o caminho do ponto de verificação do compartilhamento.

Ao usar um servidor de parâmetros para vários hosts, a carga de parâmetros em cada processo do servidor de parâmetros pode ficar desequilibrada (especialmente quando há variáveis ​​de tabela de incorporação relativamente grandes), o que pode causar erros. Você pode verificar o tamanho do arquivo de cada ponto de verificação do estilhaço no Amazon S3 para determinar se os parâmetros no servidor de parâmetro estão balanceados, pois cada servidor de parâmetro corresponde a um fragmento do arquivo de ponto de verificação. Para evitar esses problemas, você pode usar a função de particionador para tentar fazer com que os parâmetros de cada servidor de parâmetros sejam distribuídos uniformemente:

with tf.variable_scope('deepfm_model', reuse=tf.AUTO_REUSE, partitioner = tf.fixed_size_partitioner(num_shards=len(FLAGS.hosts))):

GPU única com várias instâncias

Os trabalhos de treinamento do SageMaker são compatíveis com instâncias que têm apenas uma GPU, como as séries ml.p3.xlarge, ml.g4dn e ml.g5. Existem dois métodos principais usados ​​neste cenário: servidores de parâmetros e Horovod.

O método de treinamento distribuído do servidor de parâmetros integrado do SageMaker é iniciar um processo do servidor de parâmetros e um processo de trabalho para cada instância de treinamento (cada servidor de parâmetros é responsável apenas por parte dos parâmetros do modelo), portanto, o padrão é multi-máquina single- Treinamento de GPU. O treinamento distribuído do servidor de parâmetros integrado do SageMaker é um método de atualização de gradiente assíncrono. Para reduzir o impacto de atualizações assíncronas na convergência de treinamento, é recomendável reduzir a taxa de aprendizado. Se você quiser usar todas as GPUs na instância, precisará usar uma combinação de servidores de parâmetros e o método de torre.

Para Horovod, basta definir processes_per_host=1 no parâmetro de distribuição da API SageMaker Python Estimator.

Várias GPUs com várias instâncias

Para servidores de parâmetros e o método de torre, as alterações de código são basicamente as mesmas do método de torre para uma única instância com várias GPUs, e não há necessidade de configurar manualmente os dispositivos de GPU.

Para Horovod, defina processos_per_host no parâmetro de distribuição para o número de GPUs de cada instância de treinamento. Se você usar o modo Pipe, o número de workers por instância precisa corresponder ao número de canais.

Pipelines de dados

Além da infraestrutura que discutimos, há outra coisa importante a ser considerada: o pipeline de dados. Um pipeline de dados refere-se a como você carrega dados e transforma dados antes que eles sejam alimentados em redes neurais. A CPU é usada para preparar os dados, enquanto a GPU é usada para calcular os dados da CPU. Como a GPU é um recurso caro, mais tempo ocioso da GPU é ineficiente; um bom pipeline de dados em seu trabalho de treinamento pode melhorar a utilização de GPU e CPU.

Ao tentar otimizar seu pipeline de entrada de dados do TensorFlow, considere a ordem da API usada em Conjuntos de dados do TensorFlow, o tamanho dos dados de treinamento (muitos arquivos pequenos ou vários arquivos grandes), tamanho do lote e assim por diante.

Vejamos a interação entre GPU e CPU durante o treinamento. As figuras a seguir comparam interações com e sem um pipeline.

Um pipeline melhor poderia reduzir o tempo ocioso da GPU. Considere as seguintes dicas:

• Use lógica de função simples na extração de recursos e rótulos
• Pré-buscar amostras na memória
• Reduza a E/S de disco e a E/S de rede desnecessárias
• Armazene em cache os recursos e rótulos processados ​​na memória
• Reduza o número de tempos de replicação entre CPU e GPU
• Faça com que diferentes trabalhadores lidem com diferentes partes do conjunto de dados de treinamento
• Reduza o tempo de chamada da API do conjunto de dados do TensorFlow

O TensorFlow fornece uma API de transformação relacionada aos formatos de conjunto de dados, e a ordem da API de transformação no TensorFlow afeta muito a velocidade de treinamento. A melhor ordem de chamada da API do conjunto de dados do TensorFlow precisa ser testada. Seguem alguns princípios básicos:

• Use um mapa vetorizado. Isso significa chamar primeiro a API de lote do conjunto de dados do TensorFlow e, em seguida, a API do mapa do conjunto de dados. A função de análise personalizada fornecida na função map, como decode_tfrecord no código de exemplo, analisa um minilote de dados. Pelo contrário, mapear primeiro e depois batch é um mapa escalar, e a função de analisador personalizado processa apenas uma amostra.
• Use a API de cache do conjunto de dados do TensorFlow para armazenar recursos e rótulos em cache. Coloque a API de cache do conjunto de dados do TensorFlow antes da API de repetição do conjunto de dados do TensorFlow, caso contrário, a utilização da RAM aumentará linearmente de época a época. Se o conjunto de dados for tão grande quanto a RAM, não use a API de cache do conjunto de dados do TensorFlow. Se você precisar usar a API de cache do conjunto de dados do TensorFlow e a API de embaralhamento, considere usar a seguinte ordem: criar objeto de conjunto de dados do TensorFlow -> API de cache -> API de embaralhamento -> API de lote -> API de mapa -> API de repetição -> API de pré-busca.
• Use o tfrecord formato do conjunto de dados mais do que o formato LibSVM.
• O modo de arquivo ou modo Pipe depende do formato do conjunto de dados e da quantidade de arquivos. o tfrecorddataset API pode definir num_parallel_reads para ler vários arquivos em paralelo e definir buffer_size para otimizar a leitura dos dados, enquanto o pipemodedataset A API não possui essas configurações. O modo Pipe é mais adequado para situações em que um único arquivo é grande e o número total de arquivos é pequeno. Recomendamos usar um trabalho de processamento do SageMaker para fazer o trabalho de pré-processamento, como juntar vários arquivos a um arquivo maior de acordo com rótulos, usar um método de amostragem para tornar o conjunto de dados mais balanceado e embaralhar o conjunto de dados balanceado.

Veja o seguinte exemplo de código:

def decode_tfrecord(batch_examples):
        # The feature definition here should BE consistent with LibSVM TO TFRecord process.
        features = tf.parse_example(batch_examples,
                                           features={
                                               "label": tf.FixedLenFeature([], tf.float32),
                                               "ids": tf.FixedLenFeature(dtype=tf.int64, shape=[FLAGS.field_size]),
                                               "values": tf.FixedLenFeature(dtype=tf.float32, shape=[FLAGS.field_size]) 
                                           })
        
        batch_label = features["label"]
        batch_ids = features["ids"]
        batch_values = features["values"]
        
        return {"feat_ids": batch_ids, "feat_vals": batch_values}, batch_label


    def decode_libsvm(line):
        columns = tf.string_split([line], ' ')
        labels = tf.string_to_number(columns.values[0], out_type=tf.float32)
        splits = tf.string_split(columns.values[1:], ':')
        id_vals = tf.reshape(splits.values,splits.dense_shape)
        feat_ids, feat_vals = tf.split(id_vals,num_or_size_splits=2,axis=1)
        feat_ids = tf.string_to_number(feat_ids, out_type=tf.int32)
        feat_vals = tf.string_to_number(feat_vals, out_type=tf.float32)
        return {"feat_ids": feat_ids, "feat_vals": feat_vals}, labels

if FLAGS.pipe_mode == 0:
        dataset = tf.data.TFRecordDataset(filenames)
    else :
        # Enter Pipe mode
        dataset = PipeModeDataset(channel, record_format='TFRecord')
        
    if FLAGS.enable_s3_shard == False:
        host_rank = FLAGS.hosts.index(FLAGS.current_host)
        number_host = len(FLAGS.hosts)
        dataset = dataset.shard(number_host, host_rank)
    
    dataset = dataset.batch(batch_size, drop_remainder=True) # Batch size to use
    dataset = dataset.map(decode_tfrecord,
                          num_parallel_calls=tf.data.experimental.AUTOTUNE) 

    if num_epochs > 1:
        dataset = dataset.repeat(num_epochs)
    dataset = dataset.prefetch(buffer_size=tf.data.experimental.AUTOTUNE)

Para treinamento em instâncias de CPU, definir o paralelismo de intra op, inter op, e a variável de ambiente de MKL-DNN é um bom ponto de partida.

Treinamento automático de precisão mista

A última coisa que discutimos é o treinamento automático de precisão mista, que pode acelerar a velocidade e resultar no desempenho do modelo. Até o momento, a GPU Nvidia V100 (instância P3) e A100 (instância P4dn) suportam o núcleo Tensor. Você pode habilitar o treinamento de precisão mista no TensorFlow ao usar esses tipos de instâncias. A partir da versão 1.14, o TensorFlow oferece suporte ao treinamento automático de precisão mista. Você pode usar a seguinte instrução para encapsular seu otimizador original:

tf.train.experimental.enable_mixed_precision_graph_rewrite(optimizer)

Se o modelo for pequeno e a utilização da GPU for baixa, não há vantagem no treinamento automático de precisão mista. Se o modelo for grande, o treinamento automático de precisão mista pode acelerar a velocidade do treinamento.

Conclusão

Ao iniciar o treinamento do modelo de aprendizado profundo no SageMaker, considere as dicas a seguir para obter uma velocidade de treinamento mais rápida:

• Experimente primeiro o método de instância única com várias CPUs ou o método de instância única com GPU única primeiro. Se a utilização de CPU/GPU for muito alta (por exemplo, mais de 90%), passe para a próxima etapa.
• Experimente mais CPUs em um único host ou mais GPUs em um único host. Se a utilização estiver próxima da utilização máxima de CPUs ou GPUs, vá para a próxima etapa.
• Experimente várias CPUs ou várias GPUs com vários hosts.
• Você precisa modificar os códigos ao usar servidores de parâmetros ou Horovod. A modificação do código não é a mesma para a API baseada em sessão do TensorFlow, tf.estimator API e tf.keras API. Um servidor de parâmetros ou Horovod pode mostrar diferentes velocidades de treinamento em diferentes casos e tarefas de treinamento, portanto, tente os dois métodos se tiver tempo e orçamento para determinar o melhor.

Tenha em mente os seguintes conselhos:

• Verifique a utilização antes de dimensionar, otimize seu pipeline de dados e faça a sobreposição de CPU e GPU na linha do tempo.
• Primeiro dimensione, depois dimensione.
• Se você não conseguir aumentar a utilização da GPU após todos os métodos, tente CPU. Há muitos casos (especialmente para o modelo de classificação de taxa de cliques) em que o tempo total de treinamento de instância de CPU é menor e mais econômico do que o treinamento de instância de GPU.

Também temos um exemplo de código no GitHub repo, onde mostramos dois exemplos de treinamento distribuído do DeepFM no SageMaker. Um é um servidor de parâmetros do TensorFlow em instâncias de CPU, o outro é Horovod em instâncias de GPU.

Sobre os autores

Yuhui Liang é arquiteto de soluções de aprendizado de máquina sênior. Ele está focado na promoção e aplicação de aprendizado de máquina e profundamente envolvido em projetos de aprendizado de máquina de muitos clientes. Ele tem uma rica experiência em treinamento distribuído de aprendizado profundo, sistemas de recomendação e publicidade computacional.

Shishuai Wang é arquiteto de soluções de aprendizado de máquina sênior. Ele trabalha com clientes da AWS para ajudá-los a adotar o aprendizado de máquina em grande escala. Ele gosta de assistir filmes e viajar pelo mundo.