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 de alto nivel sobre el paralelismo de modelos, una descripción de cómo puede 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 modelos SageMaker paralelos para ayudar a gestionar las estrategias de modelos paralelos, 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 cuanto al tamaño máximo de modelo que puede caber en la memoria de un solo modelo. GPU Al entrenar modelos DL, las limitaciones de GPU memoria pueden ser un obstáculo de las siguientes maneras:

• Limitan el tamaño del modelo que se puede entrenar, ya que el consumo de memoria de un modelo se amplía proporcionalmente al número de parámetros.

• Limitan el tamaño de cada GPU lote durante el entrenamiento, lo que reduce la GPU utilización y la eficiencia del entrenamiento.

Para superar las limitaciones asociadas con el entrenamiento de un modelo en un único modeloGPU, SageMaker proporciona la biblioteca de modelos parallel para ayudar a distribuir y entrenar los modelos DL de manera eficiente en varios nodos de cómputo. Además, con la biblioteca, puede lograr un entrenamiento distribuido más optimizado utilizando dispositivos EFA compatibles, 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 SageMaker modelos parallel, 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 GPU memoria necesaria por parámetro es de unos 20 bytes, que podemos desglosar de la siguiente manera:

• Un FP16 parámetro: ~ 2 bytes

• Un FP16 gradiente de ~ 2 bytes

• Un estado del FP32 optimizador de ~ 8 bytes basado en los optimizadores Adam

• Una FP32 copia del parámetro de ~ 4 bytes (necesaria para la operación optimizer apply (OA))

• Una FP32 copia del gradiente de aproximadamente 4 bytes (necesaria para la operación OA)

Incluso para un modelo DL relativamente pequeño con 10 000 millones de parámetros, puede requerir al menos 200 GB de memoria, lo que es mucho más grande que la GPU memoria típica (por ejemplo, la NVIDIA A100 con 40 GB/80 GB de memoria y la V100 con 16/32 GB) disponible en una sola unidad. 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 la formación distribuida, le recomendamos que utilice instancias EC2 P3 y P4 de Amazon que tengan NVIDIA V100 y A100 Tensor Core, respectivamente. GPUs Para obtener más información sobre especificaciones como los CPU núcleosRAM, el volumen de almacenamiento adjunto y el ancho de banda de la red, consulte la sección Computación acelerada de la página de tipos de EC2 instancias de Amazon.

Incluso con las instancias de computación acelerada, es evidente que los modelos con alrededor de 10 000 millones de parámetros, como Megatron-LM y T5, e incluso modelos más grandes con cientos de miles de millones de parámetros, como GPT -3, no caben réplicas de modelos en cada dispositivo. 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 fragmentados 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) dentro de un grupo de datos paralelos. GPUs

SageMaker implementa el paralelismo de datos fragmentados mediante la implementación de MIC, que es una biblioteca que minimiza la comunicación a escala y que se analiza en la entrada del blog Near-linear Scaling of Gigantic-model training on. AWS

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

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

PyTorch TensorFlowParalelismo de canalización (disponible para y)

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 GPUs (processes_per_host) debe ser divisible por el número de particiones del modelo. 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 configura "pipeline_parallel_degree": 2 y va "processes_per_host": 8 a utilizar una instancia de aprendizaje automático con ocho elementos GPU de trabajoml.p3.16xlarge, la biblioteca configura automáticamente el modelo distribuido en el paralelismo de datos GPUs y en cuatro direcciones. En la siguiente imagen, se muestra cómo se distribuye un modelo entre los ocho modelos, GPUs consiguiendo 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 paralelo de tuberías y la etiquetamos comoPP_GROUP, está dividida en dosGPUs. Cada partición del modelo se asigna a cuatroGPUs, donde las cuatro réplicas de particiones están en un grupo paralelo de datos y se etiquetan comoDP_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 SageMaker modelos.

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

Paralelismo tensorial (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 se dividen en dos y se distribuyen en dos. GPUs En este caso de ejemplo, la configuración paralela del modelo también incluye "pipeline_parallel_degree": 1 y "ddp": True (usa el PyTorch DistributedDataParallel paquete en segundo plano), por lo que el grado de paralelismo de los 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 tensorial y otras funciones que ahorran memoria y aprender a configurar una combinación de paralelismo tensorial y de canalización PyTorch, consulte. Paralelismo de tensores

Optimizador PyTorch de fragmentación de estados (disponible para)

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 fragmentación de estados es que no es necesario replicar el estado del optimizador en todos los estados. GPUs En cambio, una única réplica del estado del optimizador se divide en rangos de datos paralelos, sin redundancia entre los dispositivos. Por ejemplo, GPU 0 contiene el estado del optimizador para la capa uno, el siguiente GPU 1 contiene el estado del optimizador para la L2, 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 reduce operación puede superponerse con el cálculo de GPU 0, lo que resulta en una propagación hacia atrás más rápida y eficiente desde el punto de vista de la memoria. 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 GPU memoria, la biblioteca admite puntos de control de activación para evitar almacenar las activaciones internas en la GPU memoria de los módulos especificados por el usuario durante la transferencia hacia adelante. La biblioteca vuelve a calcular estas activaciones durante la pasada hacia atrás. Además, la función de descarga de activaciones descarga las activaciones almacenadas en la CPU memoria y las recupera GPU durante la transferencia hacia atrás para reducir aún más el consumo de memoria de las activaciones. 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 para modelos SageMaker distribuidos en paralelo y los consejos y dificultades de configuración.