Autores:  (1) Sasun Hambardzumyan, Activeloop, Mountain View, CA, EUA;  (2) Abhinav Tuli, Activeloop, Mountain View, CA, EUA;  (3) Levon Ghukasyan, Activeloop, Mountain View, CA, EUA;  (4) Fariz Rahman, Activeloop, Mountain View, CA, EUA;.  (5) Hrant Topchyan, Activeloop, Mountain View, CA, EUA;  (6) David Isayan, Activeloop, Mountain View, CA, EUA;  (7) Mark McQuade, Activeloop, Mountain View, CA, EUA;  (8) Mikayel Harutyunyan, Activeloop, Mountain View, CA, EUA;  (9) Tatevik Hakobyan, Activeloop, Mountain View, CA, EUA;  (10) Ivo Stranic, Activeloop, Mountain View, CA, EUA;  (11) Davit Buniatyan, Activeloop, Mountain View, CA, EUA.  Tabela de links   Resumo e introdução   Desafios Atuais   Formato de armazenamento tensor   Visão geral do sistema Deep Lake   Casos de uso de aprendizado de máquina   Referências de desempenho   Discussão e Limitações   Trabalho relatado   Conclusões, agradecimentos e referências  6. REFERÊNCIAS DE DESEMPENHO  Nesta seção, demonstramos experimentalmente o desempenho do Deep Lake em escala, desde o ponto de ingestão no formato até o treinamento em escala em outros dataloaders e formatos. Comparamos conjuntos de dados de streaming de diferentes back-ends de armazenamento e demonstramos ganhos de desempenho e escalabilidade durante o treinamento na nuvem.  6.1 Velocidade de ingestão para vários formatos   10.000 imagens do conjunto de dados FFHQ [43] foram descompactadas e armazenadas no formato NumPy. Cada imagem bruta de 1024x1024x3 é uma matriz de 3 MB. Então, como mostrado na Fig. 6, as imagens foram escritas em série em cada formato. Para aumentar o desempenho, usamos o TensorStore [23] para escrever nos formatos Zarr [52] e N5 [24]. Os experimentos foram realizados na máquina AWS c5.9xlarge. Deep Lake atinge desempenho de gravação significativamente mais rápido em comparação com formatos de array e no mesmo nível de formatos binários como WebDataset [19] e FFCV Beton [39]  6.2 Comparação de dataloaders locais  Conforme mostrado na Fig. 7, Deep Lake alcança carregamento de dados mais rápido em um loop de treinamento PyTorch sem um modelo. O experimento foi realizado na instância AWS P3.2xlarge com uma GPU Nvidia V100   cartão. O conjunto de dados gerou aleatoriamente 50.000 imagens 250x250x3 armazenadas como arquivos JPEG. A lista de bibliotecas nas quais os benchmarks foram realizados foi Deep Lake, FFCV [39], Squirrel [75], Webdataset [19] e dataloader nativo PyTorch [58].  6.3 Dataloader transmitível de diferentes locais   Neste experimento mostrado na Figura 8, exploramos diferentes backends de armazenamento para streaming remoto usando o mesmo conjunto de dados da Seção 6.2. MinIO [17] está rodando em outra máquina em uma rede local. Notavelmente, Deep Lake atinge desempenho semelhante como se os dados fossem locais para a máquina em comparação com AWS S3. Tanto o WebDataset quanto o Deep Lake são significativamente mais lentos durante o streaming dos dados de   MinIO em comparação com AWS S3. Para benchmarks mais detalhados do dataloader, recomendamos um estudo exaustivo de visão geral do dataloader feito por Ofeidis et al. [54].  6.4 Treinamento ImageNet na nuvem  Como o Deep Lake foi desenvolvido para priorizar a nuvem, nesta e na próxima seção demonstramos os benefícios que ele oferece para modelos de treinamento na nuvem. Pegamos o conjunto de dados ImageNet [35] e o armazenamos no AWS S3 [1] como original e no formato de armazenamento Tensor. O conjunto de dados contém 1,2 milhão de imagens e rótulos em um total de 150 GB. Deep Lake atinge desempenho de treinamento virtualmente semelhante, como se os dados fossem locais para a máquina. Isso economiza até 4x o tempo e o custo de computação da GPU, conforme mostrado na Fig.  6.5 Treinamento distribuído de um grande conjunto de dados multimodal  Como um segundo experimento, pegamos o conjunto de dados LAION [67] contendo 400 milhões de pares de imagem-texto e treinamos o CLIP [60], modelo de incorporação de imagem-texto com 1 bilhão de parâmetros. O conjunto de dados original é uma tabela de arquivos Parquet com uma coluna de URLs de imagens. O download do conjunto de dados da fonte levou 100 horas, enquanto a ingestão para o formato Tensor Storage levou apenas 6 horas, totalizando 1,9 TB de tamanho. O conjunto de dados foi armazenado na AWS na região leste dos EUA durante o treinamento da máquina GPU na região central dos EUA. Conforme mostrado na Fig. 10, Deep Lake atinge alta utilização de GPU transmitindo 5.100 imagens/s em 16 GPUs Nvidia A100, sem modelo, até 80.000 imagens/s por máquina na mesma região.  Este artigo está   sob licença CC 4.0. disponível no arxiv

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

Dataology.TECH

Dataology is the study of data. We publish the highest quality university papers & blog posts about the essence of data.

Dataology

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

Muito longo; Para ler

Boost your HackerNoon story @ $159.99! 🚀

Deep Lake, um Lakehouse para Deep Learning: Benchmarks de desempenho

About Author

COMENTARIOS

Rótulos

ESTE ARTIGO FOI APRESENTADO EM

Related Stories

De fóruns a feeds: como os algoritmos de mídia social moldam a interação digital

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Modelo Bitcoin UTXO, alimentando um ecossistema único

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

De fóruns a feeds: como os algoritmos de mídia social moldam a interação digital

Crescimento de Criptomoedas: Criando Personas de Usuários Eficazes

Modelo Bitcoin UTXO, alimentando um ecossistema único

As camadas invisíveis: por que as entrevistas com usuários são um ativo insubstituível

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps