Uma visão geral do cenário do Data-Loader: resumo e introdução

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.

ABSTRATO

Os dataloaders, responsáveis por mover dados do armazenamento para GPUs enquanto treinam modelos de aprendizado de máquina, podem ser a chave para melhorar drasticamente o desempenho dos trabalhos de treinamento. Avanços recentes mostraram-se promissores não apenas por diminuir consideravelmente o tempo de treinamento, mas também por oferecer novos recursos, como o carregamento de dados de armazenamento remoto como o S3. Neste artigo, somos os primeiros a distinguir o dataloader como um componente separado no fluxo de trabalho de Deep Learning (DL) e a delinear sua estrutura e recursos. Por fim, oferecemos uma comparação abrangente das diferentes bibliotecas de carregamento de dados disponíveis, suas vantagens e desvantagens em termos de funcionalidade, usabilidade e desempenho e os insights derivados delas.

1. INTRODUÇÃO

Treinar um modelo de aprendizado de máquina (profundo) requer um conjunto de dados, um modelo e o hardware, que para problemas reais envolve uma ou mais GPUs.

Estamos sempre interessados em reduzir o tempo computacional total necessário para treinar um modelo. Isto é desejável por vários motivos: custos mais baixos, mais fácil de iterar e mais acessível para equipes menores, entre outras coisas.

A relação entre os principais componentes de um pipeline de ML e o tempo de execução costuma ser explícita: um conjunto de dados maior leva mais tempo, um modelo maior leva mais tempo e uma GPU mais rápida reduz o tempo total de execução. Uma peça-chave do quebra-cabeça que muitas vezes é esquecida é a ligação entre todas essas partes: o dataloader. O dataloader se encarrega de carregar os dados de seu armazenamento permanente (RAM, disco ou rede), aplicar as transformações necessárias e enviar os dados transformados ao dispositivo apropriado para que o modelo possa ingeri-los.

A maioria dos desenvolvedores assume que o carregador de dados padrão em sua respectiva estrutura de aprendizado de máquina (Pytorch, Tensorflow, Jax) já está otimizado para sua aplicação e muitas vezes não depende de carregadores de dados de terceiros. Curiosamente, foi recentemente demonstrado que os carregadores de dados podem ser um dos gargalos mais significativos dos pipelines de ML (Mohan et al., 2020). Como resultado, temos visto muitas novas bibliotecas e projetos de pesquisa dedicados a otimizar e melhorar o desempenho do dataloader.

Por exemplo, FFCV (Leclerc et al., 2022), uma nova biblioteca de código aberto desenvolvida por uma equipe de pesquisa do MIT, conseguiu treinar ImageNet em uma fração do tempo que levaria usando o carregador de dados PyTorch padrão. Tais ganhos podem reduzir drasticamente os custos operacionais de empresas e equipes de pesquisa que dependem de infraestrutura como serviço (IaaS), como Amazon Web Services (AWS) e Google Cloud Platform (GPC).

Outro recurso promissor oferecido pelos dataloaders é a capacidade de carregar dados armazenados remotamente; por exemplo, de um bucket S3. Isto tem muitas vantagens práticas: o tempo para configurar o conjunto de dados localmente é evitado, a capacidade de disco necessária na máquina de computação é reduzida e o risco de os membros da equipe usarem versões diferentes do mesmo conjunto de dados é diminuído. A desvantagem natural de ter que transmitir os dados durante o treinamento é que, normalmente, as velocidades de transferência de rede são mais lentas do que a E/S de disco e, como resultado, o modelo deve demorar mais para treinar. Curiosamente, observamos que algumas bibliotecas, como Hub (Team, 2022a) e Deep Lake (Hambardzumyan et al., 2022), alcançam melhor desempenho na rede do que o carregador de dados Pytorch padrão lendo dados localmente para alguns cenários. Isso é possível porque o dataloader consegue pré-buscar os dados necessários antes que a GPU precise deles. Ofereceremos uma discussão mais extensa na Seção 5.

Nem todas as bibliotecas suportam carregamento remoto e aquelas que suportam não se integram necessariamente aos mesmos serviços de armazenamento remoto. Como o número de bibliotecas disponíveis que implementam dataloaders está crescendo, decidimos construir um benchmark abrangente para iluminar o estado da arte atual, quais problemas parecem já ter sido resolvidos e descobrir as áreas mais promissoras para melhorias no futuro. pesquisar.

Neste ponto, deve ser mencionado que uma diferença particular de nossos experimentos em relação a outros trabalhos como (Kumar & Sivathanu, 2020), (Mohan et al., 2020) é que nos concentramos em trabalhos executados em estações de trabalho de pequeno a médio porte com capacidade limitada (GPU, RAM, SSD). É mais provável que reflitam o hardware disponível para a maioria dos indivíduos e pequenas equipes do setor, para quem o orçamento não permite o uso de clusters em grande escala.

1.1 Contribuições

Podemos resumir nossas contribuições da seguinte forma:

• Código-fonte aberto: construímos um benchmark de código-fonte aberto que compara as bibliotecas de carregamento de dados mais populares no Pytorch[1]. O projeto permanecerá disponível para a comunidade para que novas bibliotecas e conjuntos de dados possam ser adicionados à medida que o interesse por eles aumentar. Também esperamos atualizar os resultados numéricos obtidos nesses benchmarks após quaisquer atualizações importantes em qualquer uma das bibliotecas avaliadas neste artigo.

• Viabilidade do Treinamento Remoto: Mostramos que é possível treinar um modelo de aprendizado de máquina usando um fluxo de dados através de uma conexão pública à Internet em circunstâncias razoáveis. Em particular, apontamos o impacto da computação que serve os dados. Nosso resultado é diferente daquele de (Mohan et al., 2020), uma vez que não assumimos que o conjunto de dados seja armazenado em cache localmente após o download.

• Otimização de hiperparâmetros para velocidade: As abordagens tradicionais de hiperparâmetros visam aumentar a precisão geral do modelo que está sendo treinado. Neste artigo, mostramos como também podemos otimizar a velocidade (amostras processadas ao longo do tempo) como um proxy do tempo total de execução. Essa otimização depende do hardware, por isso faz sentido executá-la antes de executar trabalhos demorados. Este processo deve ser pelo menos uma ordem de magnitude mais rápido do que métricas equivalentes de tempo até precisão.

[1] Repositório Github: https://github.com/smartnets/dataloaderbenchmarks