Autores:
(1) Sasun Hambardzumyan, Activeloop, Mountain View, CA, EE. UU.;
(2) Abhinav Tuli, Activeloop, Mountain View, CA, EE. UU.;
(3) Levon Ghukasyan, Activeloop, Mountain View, CA, EE. UU.;
(4) Fariz Rahman, Activeloop, Mountain View, CA, EE. UU.;
(5) Hrant Topchyan, Activeloop, Mountain View, CA, EE. UU.;
(6) David Isayan, Activeloop, Mountain View, CA, EE. UU.;
(7) Mark McQuade, Activeloop, Mountain View, CA, EE. UU.;
(8) Mikayel Harutyunyan, Activeloop, Mountain View, CA, EE. UU.;
(9) Tatevik Hakobyan, Activeloop, Mountain View, CA, EE. UU.;
(10) Ivo Stranic, Activeloop, Mountain View, CA, EE. UU.;
(11) Pescante Buniatyan, Activeloop, Mountain View, CA, EE. UU.
En esta sección, demostramos experimentalmente el rendimiento de Deep Lake a escala desde el punto de ingesta en el formato hasta el entrenamiento a escala con otros cargadores de datos y formatos. Comparamos conjuntos de datos de streaming de diferentes backends de almacenamiento y mostramos mejoras de rendimiento y escalabilidad mientras entrenamos en la nube.
Se descomprimieron y almacenaron 10.000 imágenes del conjunto de datos FFHQ [43] en formato NumPy. Cada imagen sin formato de 1024x1024x3 es una matriz de 3 MB. Luego, como se muestra en la Fig. 6, las imágenes se escribieron en serie en cada formato. Para aumentar el rendimiento, utilizamos TensorStore [23] para escribir en los formatos Zarr [52] y N5 [24]. Los experimentos se realizaron en la máquina AWS c5.9xlarge. Deep Lake logra un rendimiento de escritura significativamente más rápido en comparación con los formatos de matriz y a la par con formatos binarios como WebDataset [19] y FFCV Beton [39].
Como se muestra en la Fig. 7, Deep Lake logra una carga de datos más rápida en un bucle de entrenamiento de PyTorch sin un modelo. El experimento se llevó a cabo en una instancia AWS P3.2xlarge con una GPU Nvidia V100.
tarjeta. El conjunto de datos ha generado aleatoriamente 50.000 imágenes de 250x250x3 almacenadas como archivos JPEG. La lista de bibliotecas en las que se realizaron los benchmarks fue Deep Lake, FFCV [39], Squirrel [75], Webdataset [19] y el cargador de datos nativo PyTorch [58].
En este experimento, como se muestra en la Fig. 8, exploramos diferentes backends de almacenamiento para transmisión remota utilizando el mismo conjunto de datos que en la Sección 6.2. MinIO [17] se está ejecutando en otra máquina en una red local. En particular, Deep Lake logra un rendimiento similar como si los datos fueran locales en la máquina en comparación con AWS S3. Tanto WebDataset como Deep Lake son significativamente más lentos al transmitir los datos desde
MinIO en comparación con AWS S3. Para obtener comparativas de cargadores de datos más detalladas, recomendamos un estudio exhaustivo de descripción general del cargador de datos realizado por Ofeidis et al. [54].
Dado que Deep Lake se creó para ser lo primero en la nube, en esta y la siguiente sección demostramos los beneficios que brinda para los modelos de entrenamiento en la nube. Tomamos el conjunto de datos ImageNet [35] y lo almacenamos en AWS S3 [1] como formato de almacenamiento original y tensor. El conjunto de datos contiene 1,2 millones de imágenes y etiquetas en total 150 GB. Deep Lake logra un rendimiento de entrenamiento prácticamente similar al de si los datos fueran locales de la máquina. Esto ahorra hasta 4 veces el tiempo y el costo de cálculo de la GPU, como se muestra en la Fig. 9.
Como segundo experimento, tomamos el conjunto de datos LAION [67] que contiene 400 millones de pares de imagen-texto y entrenamos CLIP [60], un modelo de incrustación de imagen-texto con mil millones de parámetros. El conjunto de datos original es una tabla de archivos Parquet con una columna de URL de imágenes. La descarga del conjunto de datos desde la fuente tomó 100 horas, mientras que la transferencia al formato Tensor Storage tomó solo 6 horas, con un tamaño total de 1,9 TB. El conjunto de datos se almacenó en AWS en la región este de EE. UU. mientras se entrenaba la máquina GPU en la región central de EE. UU. Como se muestra en la Fig. 10, Deep Lake logra una alta utilización de la GPU al transmitir 5100 imágenes/s a 16 GPU Nvidia A100, mientras que sin modelo alcanza hasta 80 000 imágenes/s por máquina en la misma región.
Este documento está disponible en arxiv bajo licencia CC 4.0.