Amazon Simple Storage Service (Amazon S3) es un servicio altamente elástico que se escala automáticamente con la demanda de la aplicación y ofrece el alto rendimiento requerido para las cargas de trabajo de aprendizaje automático modernas. Los conectores de cliente de alto rendimiento, como Amazon S3 Connector para PyTorch y Mountpoint para Amazon S3, proporcionan integración nativa de S3 en canales de capacitación sin tratar directamente con las API REST de S3.
En esta publicación, presentamos técnicas prácticas y recomendaciones para optimizar el rendimiento en cargas de trabajo de capacitación de aprendizaje automático que leen datos directamente desde depósitos de uso general de Amazon S3. Dicho esto, muchas de las técnicas de optimización de la carga de datos que se analizan aquí son ampliamente aplicables en diferentes estructuras de almacenamiento.
Para validar estas recomendaciones, comparamos una carga de trabajo de capacitación representativa de Visión por Computadora (CV), específicamente, una tarea de clasificación de imágenes con decenas de miles de pequeños archivos JPEG. Evaluamos múltiples patrones de acceso a datos desde depósitos de S3 y comparamos el rendimiento de diferentes clientes de S3, incluidos Amazon S3 Connector para PyTorch y Mountpoint para Amazon S3.
Nuestros hallazgos muestran que la consolidación de conjuntos de datos en fragmentos de datos de tamaño adecuado, generalmente en el rango de 100 MB a 1 GB, combinado con patrones de acceso secuencial, ofrece un rendimiento significativamente mayor. El almacenamiento en caché de los datos de entrenamiento a los que se accede con frecuencia mejora aún más la eficiencia en escenarios de entrenamiento de múltiples épocas. Finalmente, entre los clientes de S3 evaluados, Amazon S3 Connector para PyTorch logró consistentemente el mayor rendimiento, superando a otros métodos comúnmente utilizados para acceder a datos en S3.
Cuellos de botella de rendimiento en los canales de formación de ML
Si bien las GPU desempeñan un papel vital en la aceleración de los cálculos de aprendizaje automático, el entrenamiento es un proceso multifacético con varias etapas interdependientes, cualquiera de las cuales puede convertirse en un cuello de botella. El siguiente diagrama ilustra un proceso de capacitación típico de un extremo a otro y destaca dónde ocurren estas etapas. Aunque factores como el algoritmo de entrenamiento, la arquitectura del modelo, los detalles de implementación y el hardware son importantes, es útil pensar en una carga de trabajo de entrenamiento como una canalización con los siguientes cuatro pasos recurrentes de alto nivel:
Leer muestras de entrenamiento del almacenamiento persistente en la memoria. Preprocesamiento de muestras de entrenamiento en la memoria con pasos como decodificación, transformación y aumento. Actualización de los parámetros del modelo en función de gradientes calculados y sincronizados entre GPU. Guardar el punto de control de capacitación periódicamente para la tolerancia a fallas al permitir que la capacitación se reanude desde el estado más reciente en caso de fallas.
El rendimiento efectivo de cualquier canal de capacitación de ML se ve limitado por su paso más lento. Si bien el paso 3 (el cálculo real de las actualizaciones del modelo) es lo que en última instancia nos importa, las cargas de trabajo de aprendizaje automático basadas en la nube podrían enfrentar desafíos únicos. En entornos de nube donde los recursos informáticos y de almacenamiento suelen estar desacoplados por diseño, la canalización de entrada de datos (pasos 1 y 2) suele surgir como cuellos de botella críticos. Los puntos de control (paso 4) también podrían afectar la eficiencia general de la capacitación, pero no lo cubriremos en esta publicación.
Incluso las GPU más modernas no pueden acelerar el entrenamiento si están inactivas, esperando que se procesen los datos. Cuando se produce una escasez de datos, las inversiones adicionales en hardware informático más potente generan rendimientos decrecientes, una ineficiencia costosa en los entornos de producción. Lograr la máxima utilización de la GPU requiere una optimización cuidadosa de su canal de datos para un flujo continuo de muestras de entrenamiento que estén listas para ser consumidas por las GPU.
El desafío de la carga de datos
Uno de los factores más importantes que influyen en el rendimiento de la carga de datos desde Amazon S3 es el patrón en el que se accede a los datos durante el entrenamiento. En particular, la distinción entre lecturas secuenciales y aleatorias juega un papel en la determinación del rendimiento y la latencia generales. Comprender cómo estos patrones de acceso interactúan con las características subyacentes de Amazon S3 es clave para diseñar canales de entrada eficientes.
Lecturas secuenciales y aleatorias en cargas de trabajo de ML en Amazon S3
La lectura de datos de Amazon S3 se puede comparar con el comportamiento de las unidades de disco duro (HDD) tradicionales con brazos actuadores mecánicos. Como se muestra en la siguiente ilustración, los HDD leen bloques de datos secuencialmente cuando están ubicados contiguos, lo que permite que el brazo actuador minimice el movimiento. Por el contrario, las lecturas aleatorias requieren que el brazo actuador salte a través de la superficie del disco para acceder a bloques dispersos, lo que introduce retrasos debido al reposicionamiento físico del brazo.
Al acceder a datos en Amazon S3, la situación es algo similar al ejemplo del HDD. Para ser precisos, cada solicitud de S3 genera una sobrecarga de tiempo hasta el primer byte (TTFB) antes de que comience la transferencia de datos real. Esta sobrecarga comprende varios componentes: establecimiento de la conexión, latencia de ida y vuelta de la red, operaciones internas de S3 (como localizar los datos y acceder a ellos en el disco) y manejo de la respuesta del lado del cliente. Si bien el tiempo de transferencia de datos en sí aumenta con el tamaño de los datos que se recuperan, la sobrecarga TTFB de la solicitud GET de S3 es en gran medida fija e independiente del tamaño del objeto de datos, que es lo que demuestra la siguiente ilustración.
Siguiendo la analogía del HDD cuando hablamos de cargas de trabajo de ML, podemos decir que tenemos patrones de lectura aleatorios del almacenamiento en la nube, cuando, por ejemplo, los conjuntos de datos constan de numerosos archivos pequeños almacenados en S3, y cada archivo contiene una única muestra de entrenamiento. Alternativamente, el acceso aleatorio a S3 también ocurre cuando los scripts de entrenamiento obtienen muestras de diferentes partes dentro de un fragmento de archivo más grande utilizando, por ejemplo, solicitudes GET de S3 de rango de bytes. Esto es similar a ver un vídeo de YouTube saltando constantemente escenas de un lado a otro.
Por el contrario, los patrones de lectura secuencial ocurren cuando los conjuntos de datos se organizan en fragmentos de archivos grandes, y cada fragmento contiene muchas muestras de entrenamiento, que se pueden iterar secuencialmente una tras otra. En este caso, una única solicitud GET de S3 puede recuperar varias muestras, lo que permite un rendimiento de datos mucho mayor que en el escenario de lectura aleatoria. Este enfoque también agiliza la captura previa de datos, ya que el siguiente lote de muestras se puede anticipar, recuperar y almacenar en memoria intermedia, dejándolo disponible para que la GPU lo tome.
Análisis de las implicaciones del rendimiento: un estudio de caso de visión por computadora
Para comprender mejor cómo los diferentes patrones de acceso a datos afectan el rendimiento, veamos dos escenarios en una tarea de visión por computadora donde el conjunto de datos consta de muchos archivos de imágenes relativamente pequeños (alrededor de 100 KB cada uno). En el primer escenario, el conjunto de datos se almacena tal cual en la clase de almacenamiento estándar de Amazon S3 y el script de entrenamiento recupera cada imagen a pedido. Esto crea un patrón de acceso de lectura aleatorio, donde cada muestra de entrenamiento requiere su propia solicitud S3 GET. Debido a que la latencia de tiempo hasta el primer byte (TTFB) para S3 Standard es del orden de decenas de milisegundos y el tiempo de descarga real para archivos pequeños es mínimo en comparación, el rendimiento del cargador de datos queda limitado por la latencia. En otras palabras, los subprocesos del cliente pasan la mayor parte del tiempo inactivos mientras esperan que lleguen los datos.
En el segundo escenario, el conjunto de datos se consolida en fragmentos de archivos más grandes (por ejemplo, ~100 MB cada uno) antes de almacenarse en S3. Ahora, el cargador de datos lee varias muestras de entrenamiento de forma secuencial con una única solicitud GET de S3. Esto hace que la carga de trabajo esté limitada al ancho de banda, lo que elimina el impacto TTFB por muestra y permite la transmisión eficiente de muestras consecutivas durante la fase de descarga.
Técnicas de optimización para la carga de datos desde Amazon S3
Ahora que hemos repasado los patrones de acceso a datos aleatorios y secuenciales para cargas de trabajo de ML de S3, repasemos las formas en que podemos optimizar las canalizaciones de ingesta de datos en la práctica.
Utilice clientes de archivos y de alto rendimiento optimizados para S3
Elegir un cliente de archivos S3 de buen rendimiento puede resultar un desafío dada la gran cantidad de opciones disponibles. Para solucionar este problema, en 2023, AWS presentó dos clientes nativos de código abierto para S3: Mountpoint para Amazon S3 y Amazon S3 Connector para PyTorch. Ambos se basan en AWS Common Runtime (CRT), una colección de primitivas basadas en C altamente optimizadas que incluye un cliente S3 nativo que implementa optimizaciones de rendimiento de mejores prácticas, como paralelización de solicitudes, tiempos de espera, reintentos y reutilización de conexiones para que los clientes logren el máximo rendimiento de S3 con el mínimo esfuerzo.
Mountpoint para Amazon S3 es un cliente de archivos de código abierto que puede utilizar para montar un depósito S3 en su instancia informática y acceder a él como un sistema de archivos local sin necesidad de realizar cambios en su código existente. Esto lo convierte en una excelente opción para una amplia gama de cargas de trabajo, incluida la capacitación en aprendizaje automático.
Para entornos de Kubernetes, el controlador Mountpoint para la interfaz de almacenamiento de contenedores (CSI) de Amazon S3 amplía esta capacidad al presentar un depósito de S3 como un volumen de almacenamiento, lo que permite que los contenedores accedan a objetos de S3 a través de una interfaz de sistema de archivos familiar. Con el reciente lanzamiento de Mountpoint para Amazon S3 CSI v2, el controlador también introduce el almacenamiento en caché compartido entre pods, de modo que las cargas de trabajo de aprendizaje automático distribuidas puedan reutilizar datos almacenados en caché localmente, lo que aumenta tanto el rendimiento como la eficiencia de los recursos. El controlador CSI es compatible con cualquier aplicación basada en Kubernetes y puede integrarse con Amazon Elastic Kubernetes Service (Amazon EKS), donde está disponible como complemento administrado para una instalación optimizada y una gestión del ciclo de vida.
Amazon S3 Connector para PyTorch proporciona primitivas nativas de PyTorch que integran estrechamente S3 con canales de capacitación. La integración permite un acceso de alto rendimiento a datos de entrenamiento y puntos de control eficientes directamente a Amazon S3. Aplica automáticamente optimizaciones de rendimiento al leer datos de entrenamiento o escribir puntos de control del modelo.
El conector admite conjuntos de datos de estilo mapa para acceso aleatorio y conjuntos de datos de estilo iterable para acceso secuencial en streaming, lo que lo hace adecuado para una variedad de patrones de entrenamiento de aprendizaje automático. También incluye una interfaz de puntos de control incorporada que permite guardar y cargar puntos de control desde S3 sin depender del almacenamiento local. La instalación es liviana (por ejemplo, usando pip) y el conector no requiere clientes de sistema de archivos adicionales ni una configuración compleja del sistema; solo cambios mínimos en su código de capacitación, como se demuestra en GitHub.
Fragmentar conjuntos de datos y utilizar patrones de lectura secuencial
Una estrategia eficaz para optimizar la carga de datos desde S3 es serializar conjuntos de datos en menos fragmentos de archivos más grandes, cada uno de los cuales contiene muchas muestras de entrenamiento, y leer esas muestras de forma secuencial utilizando su cargador de datos. En nuestras micropruebas de referencia de S3, los tamaños de fragmentos entre 100 MB y 1 GB generalmente ofrecían un rendimiento excelente. Sin embargo, el tamaño ideal puede variar según su carga de trabajo. Los fragmentos más pequeños pueden mejorar el comportamiento de muestreo casi aleatorio de los buffers de captación previa, mientras que los fragmentos más grandes generalmente ofrecen un mejor rendimiento sin procesar.
Los formatos de archivo comunes para fragmentación incluyen tar (usado con frecuencia en PyTorch a través de bibliotecas como WebDataset) y TFRecord (usado con tf.data en TensorFlow). Dicho esto, fragmentar datos no garantiza lecturas secuenciales. Si su cargador de datos accede aleatoriamente a muestras dentro de un fragmento, algo común en formatos como Parquet o HDF5, se pueden perder los beneficios del acceso secuencial. Para obtener mejoras de rendimiento totales, le recomendamos que diseñe su cargador de datos de modo que las muestras se lean en orden dentro de cada fragmento.
Paralelización, captación previa y almacenamiento en caché de muestras de entrenamiento
Optimizar las etapas de ingesta y preprocesamiento de datos de una canalización de aprendizaje automático es fundamental para maximizar el rendimiento del entrenamiento, especialmente cuando los patrones aleatorios de acceso a datos son inevitables. Técnicas como la paralelización, la captación previa y el almacenamiento en caché desempeñan un papel central a la hora de minimizar los cuellos de botella de E/S y mantener las GPU en pleno uso.
La paralelización es una de las formas más efectivas de mejorar el rendimiento en los canales de carga de datos, particularmente porque la decodificación y el preprocesamiento de datos a menudo son vergonzosamente paralelos, lo que significa que pueden dividirse en muchos procesos independientes que se ejecutan simultáneamente sin necesidad de comunicarse. Puede utilizar marcos como TensorFlow (tf.data) y PyTorch (DataLoader nativo) para ajustar el tamaño de sus grupos de trabajadores (procesos o subprocesos de CPU) para paralelizar la ingesta de datos.
Para patrones de acceso secuencial, una buena regla es hacer coincidir la cantidad de subprocesos de trabajo con la cantidad de núcleos de CPU disponibles. Sin embargo, en instancias con un número elevado de CPU (por ejemplo, más de 20), el uso de un grupo ligeramente más pequeño puede mejorar la eficiencia.
Por el contrario, para los patrones de acceso aleatorio, particularmente cuando se lee directamente desde S3, los tamaños de grupo mayores que el número de CPU han demostrado ser beneficiosos en nuestras pruebas comparativas. Por ejemplo, en una instancia EC2 con 8 vCPU, aumentar la configuración de PyTorch num_workers a 64 o más mejoró significativamente el rendimiento de datos.
Dicho esto, aumentar el paralelismo no es una solución milagrosa. La paralelización excesiva puede saturar los recursos de CPU y memoria, desplazando el cuello de botella de la E/S al preprocesamiento. Es importante realizar comparaciones dentro del contexto de su carga de trabajo específica para encontrar el equilibrio adecuado.
La captación previa complementa la paralelización al desacoplar la carga de datos del cálculo de la GPU. Utilizando un patrón productor-consumidor, la captación previa permite que los datos se preparen de forma asincrónica y se almacenen en la memoria para que el siguiente lote esté listo cuando la GPU lo necesite. Los buffers de captación previa de buen tamaño y los tamaños de grupos de trabajadores ajustados adecuadamente ayudan a amortizar la E/S y la latencia de preprocesamiento, lo que mejora el rendimiento general de la capacitación.
El almacenamiento en caché es particularmente eficaz para cargas de trabajo de entrenamiento de varias épocas con patrones de acceso aleatorio, donde las mismas muestras de datos se leen varias veces. Herramientas como Mountpoint para Amazon S3 ofrecen mecanismos de almacenamiento en caché integrados que almacenan objetos de conjuntos de datos localmente en el almacenamiento de instancias (por ejemplo, discos NVMe), volúmenes de EBS o memoria. Al eliminar las solicitudes repetidas de S3 GET, el almacenamiento en caché mejora la velocidad del entrenamiento y la rentabilidad.
Debido a que el conjunto de datos de entrada generalmente permanece estático durante el entrenamiento, recomendamos configurar Mountpoint con metadatos TTL indefinidos (configurando –metadata-ttl indefinite, consulte la documentación de Mountpoint para S3) para reducir la sobrecarga de solicitudes de S3. Además, en nuestras pruebas comparativas, también habilitamos el almacenamiento en caché de datos en NVMe, lo que permitió a Mountpoint almacenar objetos localmente. La caché administra automáticamente el espacio expulsando los archivos utilizados menos recientemente, manteniendo al menos el 5% del espacio disponible de forma predeterminada (configurable). Para beneficiarse plenamente del almacenamiento en caché, asegúrese de que su instancia tenga suficiente espacio en disco para almacenar los datos a los que se accede con frecuencia.
Estudio de caso de rendimiento: carga de datos desde Amazon S3 Standard
Para validar las mejores prácticas analizadas anteriormente, realizamos una serie de pruebas comparativas que simulaban una carga de trabajo de capacitación realista en visión por computadora (CV) bajo patrones de acceso a datos aleatorios y secuenciales. Si bien los resultados exactos pueden variar según su caso de uso específico, las tendencias y los conocimientos de rendimiento son ampliamente aplicables en todos los canales de capacitación de ML.
Configuración de referencia
Todas las pruebas se ejecutaron en una instancia g5.8xlarge de Amazon Elastic Compute Cloud (Amazon EC2) equipada con una GPU NVIDIA A10G y 32 vCPU. La carga de trabajo de referencia utilizó el modelo ViT principal google/vit-base-patch16-224-in21k para una tarea de clasificación de imágenes, entrenándose en un conjunto de datos de 10 GB que contiene 100 000 imágenes JPEG sintéticas (~115 KB cada una). El conjunto de datos se transmitió directamente desde Amazon S3 Standard a pedido mediante el script de capacitación utilizando uno de los siguientes clientes S3:
Cargador de datos basado en fsspec: implementación de TorchData DataPipes basado en fsspec, una popular interfaz de código abierto para almacenes de objetos en la nube. Aunque TorchData dejó de utilizar DataPipes en la versión 0.10, fsspec sigue siendo ampliamente utilizado para el acceso a datos de ML desde S3. Mountpoint para Amazon S3 (sin almacenamiento en caché de datos): un cliente de archivos de código abierto de alto rendimiento desarrollado por AWS. En esta configuración, el almacenamiento en caché de metadatos está habilitado, pero las muestras de entrenamiento no se almacenan en caché localmente entre épocas. Mountpoint para Amazon S3 (almacenamiento en caché de datos): idéntico al cliente anterior, pero con el almacenamiento en caché del disco local habilitado para almacenar muestras a las que se accede con frecuencia en distintas épocas. Conector S3 para PyTorch: una interfaz S3 de código abierto y alto rendimiento estrechamente integrada con las API del conjunto de datos de PyTorch, también mantenida por AWS.
Cada configuración de referencia transmitió el conjunto de datos a pedido durante el entrenamiento, sin descargas locales ni preprocesamiento previo.
Objetivos de referencia
Los puntos de referencia fueron diseñados para explorar:
El efecto de ajustar la configuración de paralelización en el cargador de datos. El impacto en el rendimiento del almacenamiento en caché del disco local mediante Mountpoint para Amazon S3. El rendimiento mejora al adoptar un patrón de lectura secuencial. La relación entre el tamaño del fragmento del conjunto de datos y el rendimiento sostenido de la carga de datos.
Para ambos patrones de acceso, la etapa de preprocesamiento incluyó la decodificación JPEG y el cambio de tamaño a 224 × 224 × 3, seguido del procesamiento por lotes en mini lotes de 128. Esta configuración liviana nos ayudó a mantener una canalización realista de un extremo a otro y al mismo tiempo minimizar la sobrecarga vinculada a la CPU.
Reproducibilidad y mejores prácticas.
Para reproducir pruebas comparativas similares en su propio entorno, proporcionamos una herramienta de evaluación comparativa dedicada que admite una variedad de configuraciones de carga de datos de S3.
Para obtener resultados consistentes y significativos:
Utilice tipos de instancia EC2 idénticos para cada cliente S3. Coloque cada conjunto de datos de prueba en depósitos S3 separados para aislar el tráfico y evitar interferencias entre clientes. Ejecute experimentos en la misma región de AWS que sus depósitos S3 para minimizar la latencia y la variabilidad de la red.
Puede obtener mediciones limpias y comparar de manera confiable diferentes estrategias de carga de datos en sus propias cargas de trabajo siguiendo estas mejores prácticas.
Punto de referencia de una sola época con acceso aleatorio
Para evaluar el efecto de la paralelización al transmitir conjuntos de datos directamente desde Amazon S3, ejecutamos un punto de referencia de una época (un único barrido completo a través del conjunto de datos de entrenamiento) para evitar interferencias del posible almacenamiento en caché a nivel del sistema operativo.
Con un número bajo de trabajadores, todos los clientes de S3 presentan cuellos de botella en la ingesta de datos, lo que limita el rendimiento general. A medida que aumenta el grado de paralelización, el rendimiento mejora significativamente. En particular, el conector S3 para PyTorch alcanza casi la saturación de GPU (a ~138 muestras/seg) con más de 16 trabajadores.
Sin embargo, el escalamiento agresivo del grupo de trabajadores aumenta la presión de la CPU y la memoria. Esto es particularmente evidente con el cargador de datos basado en fsspec, que alcanza ~100 % de utilización de la CPU con 32 trabajadores, lo que provoca un cuello de botella vinculado a la CPU que degrada la utilización de la GPU y reduce el rendimiento general de la muestra. Por el contrario, el conector S3 para PyTorch mantiene una mejor eficiencia bajo carga, lo que resalta la importancia de utilizar un cliente S3 de alto rendimiento.
Mountpoint para Amazon S3, con y sin almacenamiento en caché de datos, ofrece un rendimiento casi idéntico en este punto de referencia de una época, como se esperaba, porque cada muestra se lee solo una vez y el almacenamiento en caché no ofrece ninguna ventaja. Revisaremos los beneficios del almacenamiento en caché en el escenario de múltiples épocas que se analiza a continuación.
Punto de referencia de varias épocas con acceso aleatorio
La función de almacenamiento en caché de Mountpoint para Amazon S3 aumenta significativamente el rendimiento del entrenamiento al almacenar objetos S3 a los que se accede con frecuencia en el almacenamiento local, lo que reduce la latencia de recuperación y los costos de solicitud en todas las épocas. En nuestro punto de referencia, los archivos del conjunto de datos a los que se accede durante la primera época se almacenan en caché localmente. A partir de la segunda época, todo el conjunto de datos se sirve desde el disco, saturando completamente la GPU y maximizando el rendimiento, incluso con un grupo de trabajadores del cargador de datos de 16.
Como se ilustra en el siguiente gráfico, el almacenamiento en caché no solo acelera el entrenamiento sino que también minimiza el tráfico de red y el volumen de solicitudes de S3. Al final de la primera época (alrededor de los 2 minutos), Mountpoint elimina más solicitudes GET, LIST y HEAD a S3. Por el contrario, los clientes S3 sin almacenamiento en caché vuelven a descargar continuamente los mismos datos en cada época, lo que incurre en una mayor latencia y costos operativos.
Punto de referencia de una sola época con acceso secuencial
Para validar los beneficios del acceso secuencial a los datos, volvimos a ejecutar los puntos de referencia utilizando la misma configuración que antes (con 8 trabajadores del cargador de datos), pero cambiamos a un conjunto de datos serializados en formato tar con tamaños de fragmentos que oscilan entre 4 MB y 256 MB.
A primera vista, los resultados de este punto de referencia pueden parecer poco espectaculares: todos los gráficos de líneas son planos. Pero espera, ¿no es esa la parte espectacular? La carga de la GPU es consistentemente plana con una utilización de aproximadamente el 100 %, lo que significa que estamos saturando completamente nuestras GPU en todos los tamaños de fragmentos de archivos. ¡Combine eso con un uso consistentemente bajo de CPU y obtendrá un logro bastante notable!
Punto de referencia de derechos con acceso secuencial
Los resultados del punto de referencia anterior plantean una pregunta interesante: ¿cuál es el rendimiento máximo teórico que podemos lograr en esta configuración con acceso secuencial? Para averiguarlo, ejecutamos una prueba comparativa de derechos en la que eliminamos por completo de la ecuación la etapa de entrenamiento del modelo vinculado a la GPU y mantuvimos solo las etapas de lectura y preprocesamiento en las CPU. Los resultados para un tamaño de grupo de trabajadores de 8 se muestran en el siguiente gráfico.
Los resultados muestran que el rendimiento mejora con fragmentos de mayor tamaño para todos los clientes, excepto para el cargador de datos basado en fsspec. El conector S3 para PyTorch ofrece el mayor rendimiento, alcanzando más de 8000 muestras/s en el tamaño de fragmento probado más grande. Con un mayor paralelismo (32 a 64 trabajadores) o fragmentos más grandes, el rendimiento aumenta aún más, superando las 12 000 muestras/s en nuestras pruebas ampliadas.
Conclusión
Optimizar la ingesta de datos es crucial para desbloquear completamente el rendimiento de los canales de capacitación de ML modernos en la nube. En esta publicación, mostramos cómo los patrones de lectura aleatorios y los tamaños de archivos pequeños pueden limitar severamente el rendimiento debido a los gastos generales de latencia, mientras que los conjuntos de datos consolidados con patrones de acceso secuencial pueden maximizar el ancho de banda y mantener las GPU en pleno uso.
Exploramos cómo el uso de clientes de Amazon S3 de alto rendimiento, como Mountpoint para Amazon S3 y S3 Connector para PyTorch, puede marcar una diferencia significativa en el rendimiento del entrenamiento. También demostramos los beneficios de fragmentar conjuntos de datos en archivos más grandes, ajustar la configuración de paralelización y aplicar el almacenamiento en caché para minimizar las solicitudes redundantes de S3. Nuestros puntos de referencia, centrados en cargas de trabajo que acceden a datos de Amazon S3 Standard, confirman que estas mejores prácticas pueden reducir sustancialmente el tiempo de inactividad de la GPU y ayudarle a obtener el máximo valor de sus recursos informáticos.
A medida que crezcan sus cargas de trabajo de capacitación, siga revisando el diseño de su canal de datos. Las decisiones bien pensadas sobre la carga de datos pueden generar ganancias enormes en términos de rentabilidad y tiempo de obtención de resultados.
Sobre los autores
El Dr. Alexander Arzhanov es un arquitecto senior de soluciones especializado en IA/ML con sede en Frankfurt, Alemania. Ayuda a los clientes de AWS a diseñar e implementar sus soluciones de aprendizaje automático en toda la región EMEA. Antes de unirse a AWS, Alexander estaba investigando los orígenes de elementos pesados en nuestro universo y se apasionó por el aprendizaje automático después de usarlo en sus cálculos científicos a gran escala.
Ilya Isaev es ingeniero de software en Amazon S3 y reside en Cambridge, Reino Unido. Trabaja para ayudar a los clientes a almacenar y administrar de manera eficiente datos de entrenamiento y puntos de control de modelos en Amazon S3, enfocándose en mejorar el rendimiento del acceso a datos en tiempo real para grandes grupos de instancias de GPU de alto rendimiento.
Roy Allela es arquitecto senior de soluciones especializado en IA/ML en AWS. Ayuda a los clientes de AWS, desde pequeñas empresas emergentes hasta grandes empresas, a capacitar e implementar modelos básicos de manera eficiente en AWS. Le apasionan los problemas de optimización computacional y la mejora del rendimiento de las cargas de trabajo de IA.