Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Introducción al paralelismo de modelos

El paralelismo de modelos es un método de entrenamiento distribuido en el que el modelo de aprendizaje profundo se divide en varios dispositivos, dentro de las instancias o entre ellas. Esta página de introducción proporciona una descripción general sobre el paralelismo de modelos, una descripción de cómo ayudar a superar los problemas que surgen al entrenar modelos DL que suelen ser de un tamaño muy grande y ejemplos de lo que ofrece la biblioteca de paralelismo de modelos de SageMaker para ayudar a gestionar las estrategias de paralelismo de modelos, así como el consumo de memoria.

¿Qué es el paralelismo de modelos?

Al aumentar el tamaño de los modelos de aprendizaje profundo (capas y parámetros), se obtiene mayor precisión en tareas complejas, como la visión artificial y el procesamiento del lenguaje natural. Sin embargo, existe un límite en el tamaño máximo de modelo que puede caber en una sola GPU. Al entrenar modelos de DL, las limitaciones de memoria de la GPU pueden ser cuellos de botella de las siguientes maneras:

Para superar las limitaciones asociadas al entrenamiento de un modelo en una única GPU, puede utilizar el paralelismo de modelos para distribuir y entrenar el modelo en varios dispositivos informáticos. Además, con la biblioteca, puede lograr un entrenamiento distribuido más optimizado utilizando dispositivos compatibles con EFA, que mejoran el rendimiento de la comunicación entre nodos con baja latencia, alto rendimiento y omisión del sistema operativo.

Calcule los requisitos de memoria antes de utilizar el paralelismo de modelos

Antes de utilizar la biblioteca de paralelismo de modelos de SageMaker, tenga en cuenta lo siguiente para hacerse una idea de los requisitos de memoria necesarios para el entrenamiento de modelos DL de gran tamaño.

Para un trabajo de entrenamiento que utilice los optimizadores AMP (FP16) y Adam, la memoria de GPU necesaria por parámetro es de unos 20 bytes, que podemos desglosar de la siguiente manera:

Incluso para un modelo DL relativamente pequeño con 10 000 millones de parámetros, puede requerir al menos 200 GB de memoria, que es mucho más grande que la memoria típica de una GPU (por ejemplo, la NVIDIA A100 con 40 GB/80 GB de memoria y la V100 con 16/32 GB) disponible en una sola GPU. Tenga en cuenta que, además de los requisitos de memoria para los estados del modelo y del optimizador, hay otros consumidores de memoria, como las activaciones que se generan en la transferencia directa. La memoria requerida puede superar con creces los 200 GB.

Para el entrenamiento distribuido, le recomendamos que utilice instancias P3 y P4 de Amazon EC2 que tengan GPU NVIDIA V100 y A100 Tensor Core, respectivamente. Para obtener más información sobre especificaciones como los núcleos de la CPU, la RAM, el volumen de almacenamiento adjunto y el ancho de banda de la red, consulte la sección Computación acelerada de la página Tipos de instancias de Amazon EC2.

Incluso con las instancias de computación acelerada, es evidente que los modelos con unos 10 000 millones de parámetros, como Megatron-LM y la T5, e incluso modelos más grandes con cientos de miles de millones de parámetros, como el GPT-3, no caben réplicas de modelos en cada dispositivo con GPU.

Cómo emplea la biblioteca el paralelismo de modelos y las técnicas de ahorro de memoria

La biblioteca consta de varios tipos de funciones de paralelismo de modelos y funciones de ahorro de memoria, como la fragmentación del estado del optimizador, los puntos de control de activación y la descarga de la activación. Todas estas técnicas se pueden combinar para entrenar de manera eficiente modelos grandes que constan de cientos de miles de millones de parámetros.

Paralelismo de datos fragmentados (disponible para PyTorch)

El paralelismo de datos partidos es una técnica de entrenamiento distribuido que ahorra memoria y que divide el estado de un modelo (parámetros del modelo, gradientes y estados del optimizador) entre las GPU de un grupo de paralelismo de datos.

SageMaker AI implementa el paralelismo de datos partidos mediante la implementación de MiCS, que es una biblioteca que minimiza la escala de comunicación y se analiza en la publicación del blog Escalado casi lineal del entrenamiento de modelos gigantescos en AWS.

Puede aplicar el paralelismo de datos partidos a su modelo como estrategia independiente. Además, si utiliza las instancias de GPU de mayor rendimiento equipadas con las GPU NVIDIA A100 Tensor Core, ml.p4d.24xlarge, puede aprovechar la velocidad de entrenamiento mejorada gracias a la operación AllGather ofrecida por SMDDP Collectives.

Para profundizar en el paralelismo de datos partidos y aprender a configurarlo o utilizar una combinación del paralelismo de datos fragmentados con otras técnicas, como el paralelismo de tensores y el entrenamiento con FP16, consulte Paralelismo de datos partidos.

Paralelismo de canalización (disponible para PyTorch y TensorFlow)

El paralelismo de canalización divide el conjunto de capas u operaciones en el conjunto de dispositivos, dejando intacta cada operación. Al especificar un valor para el número de particiones del modelo (pipeline_parallel_degree), el número total de GPU (processes_per_host) debe ser divisible por el número de particiones de modelos. Para configurarlo correctamente, debe especificar los valores correctos de los parámetros pipeline_parallel_degree y processes_per_host. La matemática simple es la siguiente:

(pipeline_parallel_degree) x (data_parallel_degree) = processes_per_host

La biblioteca se encarga de calcular el número de réplicas del modelo (también denominadas data_parallel_degree) teniendo en cuenta los dos parámetros de entrada que usted proporciona.

Por ejemplo, si establece "pipeline_parallel_degree": 2 y "processes_per_host": 8 para utilizar una instancia de machine learning con ocho procesadores de GPU comoml.p3.16xlarge, la biblioteca configura automáticamente el modelo distribuido entre las GPU y el paralelismo de datos cuádruple. La siguiente imagen ilustra cómo se distribuye un modelo en las ocho GPU, logrando un paralelismo de datos de cuatro vías y un paralelismo de canalización de dos vías. Cada réplica del modelo, donde la definimos como un grupo de paralelismo de canalización y la etiquetamos como PP_GROUP, está dividida en dos GPU. Cada partición del modelo se asigna a cuatro GPU, donde las cuatro réplicas de particiones se encuentran en un grupo de paralelismo de datos y se etiquetan como DP_GROUP. Sin paralelismo de tensores, el grupo de paralelismo de canalizaciones es esencialmente el grupo de paralelismo de modelos.

Para profundizar en el paralelismo de las canalizaciones, consulte Características principales de la biblioteca de paralelismo de modelos de SageMaker.

Para empezar a ejecutar el modelo mediante el paralelismo de canalización, consulte Ejecutar un trabajo de entrenamiento distribuido de SageMaker con la biblioteca de paralelismo de modelos de SageMaker.

Paralelismo de tensores (disponible para PyTorch)

El paralelismo de tensores divide capas individuales onn.Modules, entre dispositivos, para que se ejecuten en paralelo. La siguiente figura muestra el ejemplo más simple de cómo la biblioteca divide un modelo con cuatro capas para lograr un paralelismo de tensores bidireccional ("tensor_parallel_degree": 2). Las capas de cada réplica del modelo están divididas en dos y distribuidas en dos GPU. En este caso de ejemplo, la configuración paralela del modelo también incluye "pipeline_parallel_degree": 1 y "ddp": True (usa el paquete PyTorch DistributedDataParallel en segundo plano), por lo que el grado de paralelismo de datos pasa a ser ocho. La biblioteca gestiona la comunicación entre las réplicas del modelo distribuido por tensores.

La utilidad de esta función reside en el hecho de que puede seleccionar capas específicas o un subconjunto de capas para aplicar el paralelismo de tensores. Para profundizar en el paralelismo de tensores y otras funciones de ahorro de memoria de PyTorch, y para aprender a configurar una combinación de paralelismo de tensores y de canalización, consulte Paralelismo de tensores.

Partición de estado del optimizador (disponible para PyTorch)

Para entender cómo la biblioteca realiza la partición del estado del optimizador, considere un modelo de ejemplo simple con cuatro capas. La idea clave para optimizar la partición de estados es que no es necesario replicar el estado del optimizador en todas las GPU. En cambio, una única réplica del estado del optimizador se divide en rangos de datos paralelos, sin redundancia entre los dispositivos. Por ejemplo, la GPU 0 mantiene el estado del optimizador para la capa uno, la siguiente GPU 1 mantiene el estado del optimizador para la capa 2, y así sucesivamente. La siguiente figura animada muestra una propagación hacia atrás con la técnica de partición del estado del optimizador. Al final de la propagación hacia atrás, hay tiempo de cálculo y de red para que la operación optimizer apply (OA) actualice los estados del optimizador y la operación all-gather (AG) para actualizar los parámetros del modelo para la siguiente iteración. Y lo que es más importante, la operación reduce puede superponerse con el procesamiento de la GPU 0, lo que resulta en una mayor eficiencia de la memoria y una propagación hacia atrás más rápida. En la implementación actual, las operaciones de AG y OA no se superponen con compute. Esto puede provocar un cálculo prolongado durante la operación de AG, por lo que podría haber una compensación.

Para obtener más información acerca de cómo utilizar esta función, consulte Partición del estado del optimizador.

Activación, descarga y puntos de control (disponible para PyTorch)

Para ahorrar memoria en la GPU, la biblioteca admite puntos de control de activación para evitar almacenar las activaciones internas en la memoria de la GPU para los módulos especificados por el usuario durante la transferencia. La biblioteca vuelve a calcular estas activaciones durante la pasada hacia atrás. Además, la función de descarga de activaciones transfiere las activaciones almacenadas a la memoria de la CPU y las recupera en la GPU durante la transferencia hacia atrás para reducir aún más el consumo de memoria de activación. Para obtener más información sobre cómo utilizar estas características, consulte Puntos de control de activación y Descarga de activación.

Elegir las técnicas adecuadas para su modelo

Para obtener más información sobre cómo elegir las técnicas y configuraciones correctas, consulte las Prácticas recomendadas del paralelismo de modelos distribuidos de SageMaker y los Consejos y dificultades de la configuración.