Autores:
(1) Iason Ofeidis, Departamento de Ingeniería Eléctrica e Instituto de Ciencias de Redes de Yale, Universidad de Yale, New Haven {Contribución igual};
(2) Diego Kiedanski, Departamento de Ingeniería Eléctrica e Instituto de Ciencias de Redes de Yale, Universidad de Yale, New Haven {Contribución igual};
(3) Leandros Tassiulas Levon Ghukasyan, Activeloop, Mountain View, CA, EE. UU., Departamento de Ingeniería Eléctrica e Instituto de Ciencias de Redes de Yale, Universidad de Yale, New Haven.
Los cargadores de datos, encargados de mover datos del almacenamiento a las GPU mientras entrenan modelos de aprendizaje automático, podrían ser la clave para mejorar drásticamente el rendimiento de los trabajos de entrenamiento. Los avances recientes se han mostrado prometedores no sólo al reducir considerablemente el tiempo de capacitación sino también al ofrecer nuevas funciones como la carga de datos desde un almacenamiento remoto como S3. En este artículo, somos los primeros en distinguir el cargador de datos como un componente separado en el flujo de trabajo de aprendizaje profundo (DL) y en describir su estructura y características. Finalmente, ofrecemos una comparación exhaustiva de las diferentes bibliotecas de carga de datos disponibles, sus ventajas y desventajas en términos de funcionalidad, usabilidad y rendimiento y los conocimientos que se derivan de ellas.
Entrenar un modelo de aprendizaje automático (profundo) requiere un conjunto de datos, un modelo y el hardware, que para problemas reales implica una o más GPU.
Siempre estamos interesados en reducir el tiempo computacional total requerido para entrenar un modelo. Esto es deseable por varias razones: menores costos, más fácil de iterar y más accesible para equipos más pequeños, entre otras cosas.
La relación entre los componentes principales de una canalización de ML y el tiempo de ejecución suele ser explícita: un conjunto de datos más grande lleva más tiempo, un modelo más grande lleva más tiempo y una GPU más rápida reduce el tiempo de ejecución total. Una pieza clave del rompecabezas que a menudo se pasa por alto es el pegamento entre todas estas partes: el cargador de datos. El cargador de datos se encarga de cargar los datos desde su almacenamiento permanente (RAM, disco o red), aplicar las transformaciones necesarias y enviar los datos transformados al dispositivo apropiado para que el modelo pueda ingerirlos.
La mayoría de los desarrolladores asumen que el cargador de datos predeterminado en su respectivo marco de aprendizaje automático (Pytorch, Tensorflow, Jax) ya está optimizado para su aplicación y no suelen confiar en cargadores de datos de terceros. Curiosamente, recientemente se ha demostrado que los cargadores de datos pueden ser uno de los cuellos de botella más importantes de los procesos de aprendizaje automático (Mohan et al., 2020). Como resultado, hemos visto muchas bibliotecas nuevas y proyectos de investigación dedicados a optimizar y mejorar el rendimiento del cargador de datos.
Por ejemplo, FFCV (Leclerc et al., 2022), una nueva biblioteca de código abierto desarrollada por un equipo de investigación del MIT, logró entrenar ImageNet en una fracción del tiempo que llevaría usar el cargador de datos predeterminado de PyTorch. Estas ganancias pueden reducir drásticamente los costos operativos de las empresas y los equipos de investigación que dependen de la infraestructura como servicio (IaaS), como Amazon Web Services (AWS) y Google Cloud Platform (GPC).
Otra característica prometedora que ofrecen los cargadores de datos es la capacidad de cargar datos almacenados de forma remota; por ejemplo, desde un depósito S3. Esto tiene muchas ventajas prácticas: se evita el tiempo necesario para configurar el conjunto de datos localmente, se reduce la capacidad de disco requerida en la máquina informática y se reduce el riesgo de que los miembros del equipo utilicen diferentes versiones del mismo conjunto de datos. El inconveniente natural de tener que transmitir los datos durante el entrenamiento es que, normalmente, las velocidades de transferencia de la red son más lentas que las de E/S del disco y, como resultado, el modelo debería tardar más en entrenar. Curiosamente, hemos observado que algunas bibliotecas, como Hub (Team, 2022a) y Deep Lake (Hambardzumyan et al., 2022), logran un mejor rendimiento en la red que el cargador de datos predeterminado de Pytorch al leer datos localmente en algunos escenarios. Esto es posible porque el cargador de datos logra capturar previamente los datos requeridos antes de que la GPU los necesite. Ofreceremos una discusión más extensa en la Sección 5.
No todas las bibliotecas admiten la carga remota y aquellas que lo hacen no necesariamente se integran con los mismos servicios de almacenamiento remoto. Dado que el número de bibliotecas disponibles que implementan cargadores de datos está creciendo, nos propusimos construir un punto de referencia integral para iluminar el estado actual del arte, qué problemas parecen haberse resuelto ya y descubrir las áreas más prometedoras para mejorar en el futuro. investigación.
En este punto, cabe mencionar que una diferencia particular con respecto a nuestros experimentos con respecto a otros trabajos como (Kumar & Sivathanu, 2020), (Mohan et al., 2020) es que nos centramos en trabajos que se ejecutan en estaciones de trabajo pequeñas y medianas con Capacidad limitada (GPU, RAM, SSD). Es más probable que estos reflejen el hardware disponible para la mayoría de las personas y equipos pequeños de la industria, para quienes el presupuesto no permite el uso de clústeres a gran escala.
Podemos resumir nuestras contribuciones de la siguiente manera:
• Código de fuente abierta: creamos un punto de referencia de fuente abierta que compara las bibliotecas de carga de datos más populares en Pytorch[1]. El proyecto permanecerá disponible para la comunidad para que se puedan agregar nuevas bibliotecas y conjuntos de datos a medida que aumente el interés en ellos. También esperamos actualizar los resultados numéricos obtenidos en estos puntos de referencia luego de cualquier actualización importante de cualquiera de las bibliotecas evaluadas en este documento.
• Viabilidad de la capacitación remota: mostramos que es posible entrenar un modelo de aprendizaje automático utilizando un flujo de datos a través de una conexión pública a Internet en circunstancias razonables. En particular, señalamos el impacto de la informática al servicio de los datos. Nuestro resultado es diferente al de (Mohan et al., 2020) ya que no asumimos que el conjunto de datos se almacene en caché localmente después de la descarga.
• Optimización de hiperparámetros para la velocidad: los enfoques de hiperparámetros tradicionales tienen como objetivo aumentar la precisión general del modelo que se está entrenando. En este artículo, mostramos cómo también podemos optimizar la velocidad (muestras procesadas a lo largo del tiempo) como indicador del tiempo total de ejecución. Esta optimización depende del hardware, por lo que tiene sentido realizarla antes de trabajos de ejecución prolongada. Este proceso debería ser al menos un orden de magnitud más rápido que las métricas de tiempo de precisión equivalentes.
Este documento está disponible en arxiv bajo licencia CC 4.0.
[1] Repositorio de Github: https://github.com/smartnets/dataloaderbenchmarks