5 dicas para treinamento em várias GPUs com Keras

• 21 de janeiro de 2018
• Vasilis Vryniotis
• . 1 comentário

Deep Learning (a palavra da moda favorita do final dos anos 2010 junto com blockchain / bitcoin e Data Science / Machine Learning) nos permitiu fazer coisas realmente legais nos últimos anos. Além dos avanços nos algoritmos (que reconhecidamente são baseados em ideias já conhecidas desde 1990, também conhecidas como "era da mineração de dados"), as principais razões de seu sucesso podem ser atribuídas à disponibilidade de grandes conjuntos de dados gratuitos, à introdução de bibliotecas de código aberto e o uso de GPUs. Nesta postagem do blog, vou me concentrar nos dois últimos e vou compartilhar com vocês algumas dicas que aprendi da maneira mais difícil.

Por que TensorFlow e Keras?

TensorFlow é uma biblioteca de Deep Learning muito popular desenvolvida pelo Google, que permite criar protótipos de redes complexas rapidamente. Ele vem com muitos recursos interessantes, como auto-diferenciação (que evita estimar / codificar os gradientes das funções de custo) e suporte de GPU (que permite que você obtenha facilmente uma melhoria de velocidade 200x usando um hardware decente). Além disso, oferece uma interface Python, o que significa que você pode prototipar rapidamente sem a necessidade de escrever código C ou CUDA. Admitidamente, existem muitos outros frameworks que podem ser usados ​​no lugar do TensorFlow, como Torch, MXNet, Theano, Caffe, Deeplearning4j, CNTK, etc, mas tudo se resume ao seu caso de uso e às suas preferências pessoais.

Mas por que Keras? Para mim, usar o TF diretamente é como fazer aprendizado de máquina com o Numpy. Sim, é viável e de vez em quando você tem que fazer isso (especialmente se você escrever camadas / funções de perda personalizadas), mas você realmente deseja escrever um código que descreva as redes complexas como uma série de operações vetoriais (sim, eu sei existem métodos de nível superior no TF, mas eles não são tão legais quanto Keras)? E se você quiser mudar para uma biblioteca diferente? Bem, então você provavelmente precisaria reescrever o código, o que é uma merda. Ta ta taaa, Keras ao resgate! Keras permite que você descreva suas redes usando conceitos de alto nível e escreva um código agnóstico de backend, o que significa que você pode executar as redes em diferentes bibliotecas de aprendizado profundo. Poucas coisas que amo no Keras é que ele é bem escrito, tem uma arquitetura orientada a objetos, é fácil de contribuir e tem uma comunidade amigável. Se você gosta, diga obrigado a François Chollet para desenvolvê-lo e abri-lo.

Dicas e truques para treinamento Multi-GPU

Sem mais delongas, vamos pular para algumas dicas sobre como aproveitar ao máximo o treinamento em GPU no Keras e algumas dicas que você deve ter em mente:

1. O treinamento Multi-GPU não é automático

O treinamento de modelos em GPU usando Keras e Tensorflow é perfeito. Se você tiver uma placa NVIDIA e tiver instalado o CUDA, as bibliotecas irão detectá-la automaticamente e usá-la para treinamento. Tão legal! Mas e se você for um pirralho mimado e tiver várias GPUs? Bem, infelizmente você terá que trabalhar um pouco para conseguir um treinamento multi-GPU.

Existem várias maneiras de paralelizar uma rede, dependendo do que você deseja alcançar, mas as duas abordagens principais são a paralelização de modelos e dados. O primeiro pode ajudá-lo se o seu modelo for muito complexo para caber em uma única GPU, enquanto o último ajuda quando você deseja acelerar a execução. Normalmente, quando as pessoas falam sobre o treinamento multi-GPU, elas se referem ao último. Costumava ser mais difícil de conseguir, mas felizmente Keras incluiu recentemente um método utilitário chamado mutli_gpu_model o que torna o treinamento / previsões paralelas mais fácil (atualmente disponível apenas com o backend TF). A ideia principal é que você passe seu modelo pelo método e ele seja copiado em diferentes GPUs. A entrada original é dividida em blocos que são alimentados para as várias GPUs e, em seguida, são agregados como uma única saída. Este método pode ser usado para obter treinamento e previsões paralelas, no entanto, tenha em mente que para o treinamento ele não é escalonado linearmente com a quantidade de GPUs devido à sincronização necessária.

2. Preste atenção ao tamanho do lote

Quando você faz o treinamento multi-GPU, preste atenção ao tamanho do lote, pois ele tem vários efeitos na velocidade / memória, convergência do seu modelo e se você não tiver cuidado, poderá corromper os pesos do seu modelo!

Velocidade / memória: Obviamente, quanto maior o lote, mais rápido será o treinamento / previsão. Isso ocorre porque há uma sobrecarga na inserção e retirada de dados das GPUs, portanto, pequenos lotes têm mais sobrecarga. Por outro lado, quanto maior o lote, mais memória você precisa na GPU. Especialmente durante o treinamento, as entradas de cada camada são mantidas na memória conforme são necessárias na etapa de retropropagação, portanto, aumentar muito o tamanho do lote pode levar a erros de falta de memória.

Convergência: Se você usar Stochastic Gradient Decent (SGD) ou algumas de suas variantes para treinar seu modelo, deve ter em mente que o tamanho do lote pode afetar a capacidade de sua rede de convergir e generalizar. Os tamanhos de lote típicos em muitos problemas de visão computacional estão entre 32-512 exemplos. Como Keskar e outros Em outras palavras, “tem sido observado na prática que ao usar um lote maior (que 512) há uma degradação na qualidade do modelo, medida por sua capacidade de generalizar.”. Observe que outros otimizadores diferentes têm propriedades diferentes e técnicas especializadas de otimização distribuída podem ajudar com o problema. Se você está interessado nos detalhes matemáticos, recomendo a leitura da Tese de Joeri Hermans “Sobre Aprendizado Profundo Escalável e Gradiente Descendente em Paralelo".

Corrompendo os pesos: Este é um detalhe técnico desagradável que pode ter resultados devastadores. Quando você faz um treinamento multi-GPU, é importante alimentar todas as GPUs com dados. Pode acontecer que o último lote da sua época tenha menos dados do que o definido (porque o tamanho do seu conjunto de dados não pode ser dividido exatamente pelo tamanho do seu lote). Isso pode fazer com que algumas GPUs não recebam dados durante a última etapa. Infelizmente, algumas camadas Keras, mais notavelmente a camada de normalização em lote, não conseguem lidar com isso, levando a valores nan que aparecem nos pesos (a média e variação em execução na camada BN). Para tornar as coisas ainda mais desagradáveis, não se observará o problema durante o treinamento (enquanto a fase de aprendizagem é 1) porque a camada específica usa a média / variância do lote nas estimativas. No entanto, durante as previsões (fase de aprendizagem definida como 0), a média / variância corrente é usada, que em nosso caso pode se tornar nan, levando a resultados ruins. Portanto, faça um favor a si mesmo e sempre certifique-se de que o tamanho do lote seja fixo ao fazer o treinamento multi-GPU. Duas maneiras simples de fazer isso são rejeitando lotes que não correspondem ao tamanho predefinido ou repetir os registros dentro do lote até atingir o tamanho predefinido. Por último, mas não menos importante, lembre-se de que em uma configuração de várias GPUs, o tamanho do lote deve ser um múltiplo do número de GPUs disponíveis em seu sistema.

3. A fome de dados da GPU, também conhecida como CPUs, não consegue acompanhar as GPUs

Normalmente, a parte mais cara durante o treinamento / previsão de redes profundas é a estimativa que acontece nas GPUs. Os dados são pré-processados ​​nas CPUs em segundo plano e são enviados para as GPUs periodicamente. No entanto, não se deve subestimar a velocidade das GPUs; pode acontecer que se sua rede for muito superficial ou a etapa de pré-processamento for muito complexa que suas CPUs não consigam acompanhar suas GPUs ou, em outras palavras, elas não as alimentam com dados rápido o suficiente. Isso pode levar a uma baixa utilização da GPU, o que se traduz em desperdício de dinheiro / recursos.

Keras normalmente realiza as estimativas dos lotes em paralelo, no entanto, devido ao GIL (Global Interpreter Lock) do Python, você não pode realmente alcançar o multithreading verdadeiro no Python. Existem duas soluções para isso: ou use vários processos (observe que existem muitas pegadinhas neste que não vou cobrir aqui) ou mantenha sua etapa de pré-processamento simples. No passado, enviei um Pull-Request no Keras para aliviar parte do esforço desnecessário que colocamos nas CPUs durante o pré-processamento de imagens, de modo que a maioria dos usuários não deve ser afetada se usarem os geradores padrão. Se você tiver geradores personalizados, tente empurrar o máximo de lógica possível para bibliotecas C, como Numpy porque alguns desses métodos realmente liberar o GIL o que significa que você pode aumentar o grau de paralelização. Uma boa maneira de detectar se você está enfrentando falta de dados da GPU é monitorar a utilização da GPU, no entanto, esteja avisado de que esse não é o único motivo para observar isso (a sincronização que acontece durante o treinamento entre as várias GPUs também é responsável pela baixa utilização ) Normalmente, a privação de dados da GPU pode ser detectada observando os surtos de GPU seguidos por longas pausas sem utilização. No passado, abri o código-fonte de uma extensão para Dstat que pode ajudá-lo a medir sua utilização de GPU, então dê uma olhada no postagem de blog original.

4. Salvando seus modelos paralelos

Digamos que você tenha usado o método mutli_gpu_model para paralelizar seu modelo, o treinamento terminou e agora você deseja manter seus pesos. A má notícia é que você não pode simplesmente chamar save () nele. Atualmente Keras tem uma limitação que não permite que você salvar um modelo paralelo. Existem 2 maneiras de contornar isso: chame o save () na referência do modelo original (os pesos serão atualizados automaticamente) ou você precisa serializar o modelo cortando a versão paralelizada e limpando todas as conexões desnecessárias. A primeira opção é muito mais fácil, mas no futuro pretendo abrir o código-fonte de um método serialize () que execute o último.

5. Contar as GPUs disponíveis tem um efeito colateral desagradável

Infelizmente, no momento, há um efeito colateral desagradável no método tensorflow.python.client.device_lib.list_local_devices () que faz com que uma nova sessão do TensorFlow seja criada e a inicialização de todas as GPUs disponíveis no sistema. Isso pode levar a resultados inesperados, como visualizar mais GPUs do que o especificado ou inicializar prematuramente novas sessões (você pode ler todos os detalhes neste solicitação pull) Para evitar surpresas semelhantes, recomendamos usar o método K.get_session (). List_devices () de Keras, que retornará a você todas as GPUs registradas atualmente na sessão. Por último, mas não menos importante, lembre-se de que chamar o método list_devices () é de alguma forma caro, então se você estiver interessado apenas no número de GPUs disponíveis, chame o método uma vez e armazene seu número em uma variável local.

É isso! Espero que você tenha achado esta lista útil. Se você encontrou outras pegadinhas / dicas para treinamento de GPU no Keras, compartilhe-as abaixo nos comentários. 🙂