Uma visão geral do cenário do Data-Loader: Dataloaders

Tabela de Links

• Resumo e introdução
• Carregadores de dados
• Configuração Experimental
• Resultados numéricos
• Discussão
• Trabalho relatado
• Conclusão, agradecimentos e referências
• A. Resultados Numéricos Cont.

2. CARREGADORES DE DADOS

No processo de treinamento de um modelo de Deep Learning, o conjunto de dados precisa ser lido da memória e pré-processado, antes de poder ser passado como entrada para o modelo. Esta operação requer o carregamento de todos os dados na memória de uma só vez. Na maioria dos casos e, especialmente, com grandes conjuntos de dados, surge uma falta de memória devido à quantidade limitada disponível no sistema, o que também deteriora o tempo de resposta do sistema. Esse gargalo é frequentemente resolvido em bibliotecas de aprendizagem profunda usando o chamado dataloader. Essa estrutura fornece uma maneira de iterar o conjunto de dados, aproveitando o processamento paralelo, a pré-busca, o lote e outras técnicas para reduzir ao máximo o tempo de carregamento de dados e a sobrecarga de memória (Paszke et al., 2019).

O principal objetivo de um dataloader é realizar as ações responsáveis pela transferência de amostras de dados de um local de armazenamento para a memória co-localizada com as unidades de processamento para treinamento, a fim de formar um lote de amostras a serem alimentadas no modelo. Essas ações são restringidas pela largura de banda do sistema de armazenamento e, especificamente, pelo seu desempenho de E/S. Assim, dependendo das especificações de hardware do sistema, do sistema de arquivos que o atende e do rendimento do link com as unidades de computação, isso pode ter uma influência imensa no tempo total necessário para concluir o treinamento.

A seguinte especificação do componente dataloader é focada principalmente no PyTorch (torch.DataLoader() (PyTorch Core Team)), enquanto sua contraparte TensorFlow (tf.Dataset() (Abadi et al., 2015)), embora não seja a mesma, guarda grandes semelhanças.

Ao utilizar um dataloader, além de fornecer o conjunto de dados para entrada, o usuário tem a opção de configurar uma série de hiperparâmetros, adaptados às suas necessidades e recursos. Um comum disponível em todos os dataloaders é o tamanho do lote, que, como mencionado anteriormente, define o número de amostras que serão utilizadas antes da atualização dos parâmetros internos do modelo. Este parâmetro está intrinsecamente ligado ao conceito de “minilote” na descida gradiente estocástica (Hinton et al., 2012) e, portanto, é um dos primeiros parâmetros que geralmente sofre ajustes quando é necessário obter melhores resultados de treinamento. .

Em segundo lugar, o usuário pode definir a abordagem de amostragem, que determina a estratégia para extrair amostras do conjunto de dados e inseri-las em um lote. Isto poderia incluir a seleção de amostras com base em critérios específicos, bem como uma distribuição de probabilidade. Nesta etapa existe a opção de embaralhamento, onde as amostras podem ser reorganizadas antes de cada iteração do conjunto de dados, com o objetivo geralmente de melhorar a generalização do modelo de treinamento. Outro parâmetro é a função de agrupamento/preenchimento, que essencialmente especifica o processo de vincular todas as amostras individuais dentro de um lote (pense em empilhar vetores em um tensor), a fim de formar um único elemento a ser alimentado como entrada para o modelo de treinamento . Além disso, o dataloader pode ser configurado para armazenar automaticamente amostras de dados buscadas em memória fixa (bloqueada por página), permitindo assim uma transferência de dados mais rápida para dispositivos habilitados para CUDA.

Os dataloaders vêm com um componente chamado trabalhadores, cujo objetivo é otimizar esse processo de transferência de dados. Workers são definidos como subprocessos responsáveis por realizar o carregamento dos dados de forma assíncrona. Ao criar uma instância de um dataloader, o usuário tem a opção de especificar a quantidade de trabalhadores que serão gerados e estarão no controle desta operação. Se o número de trabalhadores for igual a zero, nenhum subprocesso será criado, o que, por sua vez, significa que a busca de dados acontece de forma síncrona no mesmo processo e, assim, as unidades de computação (GPU) terão que aguardar o carregamento dos dados. a ser concluído (Equipe principal do PyTorch). Inversamente, serão gerados subprocessos iguais ao número de trabalhadores, o que evitará o bloqueio do código de computação com carregamento de dados. Isso é feito pré-buscando lotes futuros com antecedência para que estejam prontos quando necessário.