Autores:  (1) Iason Ofeidis, Departamento de Engenharia Elétrica, e Instituto Yale para Ciência de Redes, Universidade de Yale, New Haven {Contribuição igual};  (2) Diego Kiedanski, Departamento de Engenharia Elétrica, e Instituto Yale para Ciência de Redes, Universidade de Yale, New Haven {Contribuição igual};  (3) Leandros TassiulasLevon Ghukasyan, Activeloop, Mountain View, CA, EUA, Departamento de Engenharia Elétrica, e Instituto Yale para Ciência de Redes, Universidade de Yale, New Haven.  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:    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. • Código-fonte aberto:    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. • Viabilidade do Treinamento Remoto:    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. • Otimização de hiperparâmetros para velocidade:  Este artigo está   sob licença CC 4.0. disponível no arxiv  [1] Repositório Github: https://github.com/smartnets/dataloaderbenchmarks

Part of HackerNoon's growing list of open-source research papers, promoting free access to academic material.

Read My Stories

We cover the most cutting edge academic research and expert blog posts on serialization. Also big fans of the Serial pod

Serialization's blog

Este áudio é produzido no idioma original da história!

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

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

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Modelo Bitcoin UTXO, alimentando um ecossistema único

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Digital Nomads Ouçam: O que você precisa saber sobre o novo visto DTV da Tailândia

Modelo Bitcoin UTXO, alimentando um ecossistema único

Quer ganhar um concurso de redação do HackerNoon? Aqui está o que os vencedores do concurso #crypto-api recomendam

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps