[ad_1]
La capacitación de modelos de lenguajes grandes (LLM) se ha vuelto cada vez más popular en el último año con el lanzamiento de varios modelos disponibles públicamente, como Llama2, Falcon y StarCoder. Los clientes ahora capacitan LLM de un tamaño sin precedentes, que van desde mil millones hasta más de 175 mil millones de parámetros. La capacitación de estos LLM requiere importantes recursos computacionales y tiempo, lo que requiere el uso de cientos a miles de unidades de procesamiento de gráficos (GPU) para procesar los enormes conjuntos de datos de capacitación y tamaños de modelos actuales. Un cuello de botella en la capacitación distribuida puede ser la comunicación de GPU, que es administrada por la Biblioteca de comunicación colectiva de NVIDIA (NCCL). En algunos trabajos de capacitación distribuidos de gran tamaño, es posible que se dedique más tiempo a la comunicación entre GPU que al cálculo de la GPU real. Para aliviar el cuello de botella en la comunicación de la GPU y permitir un entrenamiento más rápido, Amazon SageMaker se complace en anunciar las operaciones compartidas optimizadas de AllGather como parte de la biblioteca paralela de datos distribuidos (SMDDP) de SageMaker. AllGather es la operación colectiva más utilizada en soluciones populares de paralelismo de datos con eficiencia de memoria, como DeepSpeed Zero Redundancy Optimizer (ZeRO) y Fully Sharded Data Parallelism (FSDP), y es el mayor contribuyente a la sobrecarga de comunicación de la GPU. En esta publicación, mostraremos una descripción general de alto nivel de cómo funciona SMDDP, cómo puede habilitar SMDDP en sus scripts de capacitación de Amazon SageMaker y qué mejoras de rendimiento puede esperar.
Descripción general de la solución
El entrenamiento de datos paralelo tradicional implica replicar un modelo completo en múltiples GPU, y cada modelo se entrena en diferentes fragmentos de datos del conjunto de datos. Durante el paso hacia atrás, los gradientes se promedian entre los trabajadores de la GPU para que cada réplica del modelo se actualice con los mismos valores de gradiente aunque esté entrenada en diferentes fragmentos de datos. Esta técnica permite un entrenamiento mucho más rápido para grandes conjuntos de datos al paralelizar el consumo de datos de entrenamiento. Sin embargo, algunos de los modelos grandes actuales (por ejemplo, Llama2 70B) son demasiado grandes para caber completamente en la memoria de la GPU, lo que hace que el paralelismo de datos tradicional sea inutilizable. Para seguir aprovechando los beneficios del paralelismo de datos y al mismo tiempo superar la memoria limitada de la GPU, las soluciones paralelas de datos fragmentados como DeepSpeed ZeRO, PyTorch FSDP y la biblioteca de paralelismo de modelos de Amazon SageMaker están ganando popularidad.
Con el paralelismo de datos de fragmentos, el modelo completo no se replica en los trabajadores de GPU, sino que los parámetros, los historiales y los estados del optimizador del modelo se dividen y distribuyen (es decir, se fragmentan) entre las GPU en el trabajo de entrenamiento. Para realizar cálculos de paso hacia adelante y hacia atrás, se recopilan parámetros de fragmentos de otros trabajadores de GPU para formar una o más capas de modelo. Una vez realizado el cálculo, estas capas se liberan de la memoria para que se pueda ensamblar el siguiente conjunto de capas. Tenga en cuenta que existen variantes del paralelismo de datos fragmentados en las que solo se fragmentan los estados y los historiales del optimizador, pero no los parámetros del modelo. AllGather todavía se usa en este tipo de paralelismo de datos de fragmentos, pero solo antes del cálculo del paso directo para recopilar parámetros del modelo actualizados por diferentes fragmentos de estado de gradiente o optimizador de otros trabajadores de GPU. Tenga en cuenta los diferentes niveles de DeepSpeed Zero y el SHARD_GRAD_OP
Para obtener más detalles, consulte la estrategia de fragmentación de FSDP.
Cada vez que se borran los parámetros se realiza una operación conjunta de AllGather. NCCL proporciona la implementación estándar de código abierto de esta rutina. Como se muestra a continuación, cada trabajador de GPU involucrado en AllGather comienza con un búfer de entrada y finaliza concatenando todos los búferes de entrada de otros trabajadores. Cuando AllGather se utiliza en el paralelismo de datos de fragmentos, los búferes de entrada contienen los fragmentos de parámetros del modelo y los búferes de salida grandes contienen una o más capas de modelo materializadas a partir de los otros fragmentos.
Aunque NCCL se utiliza normalmente para AllGather en la capacitación distribuida, su implementación subyacente de bajo nivel no está adaptada a la infraestructura de red de las instancias de Amazon Elastic Compute Cloud (Amazon EC2) y, por lo tanto, su rendimiento puede ralentizar la capacitación de un extremo a otro. La biblioteca SMDDP es una biblioteca de comunicación colectiva para GPU NVIDIA que sirve como reemplazo directo de NCCL y proporciona un mejor rendimiento para trabajos de capacitación distribuidos utilizando PyTorch. En particular, SMDDP proporciona una implementación optimizada de AllGather para tipos de instancias p4d/p4de.
Dado que las operaciones colectivas como AllGather bloquean los cálculos de paso hacia adelante y hacia atrás, una ejecución más rápida de estas operaciones da como resultado directamente un tiempo de entrenamiento de un extremo a otro más corto sin efectos secundarios en la convergencia. Otras operaciones colectivas que se utilizan con menos frecuencia en el entrenamiento paralelo sobre datos fragmentados se manejan confiando en NCCL.
solución completa
AllGather optimizado para AWS
AWS Optimized AllGather aprovecha las siguientes técnicas para lograr un mejor rendimiento en la infraestructura de AWS en comparación con NCCL:
- Movemos datos entre instancias a través de la red Elastic Fabric Adapter (EFA) con un patrón de comunicación de todos a todos. EFA es la solución de red de alto rendimiento y baja latencia de AWS. Un patrón de comunicación de red global entre nodos se adapta mejor a las características de la infraestructura de red de EFA y AWS porque requiere menos saltos de paquetes en comparación con los patrones de comunicación del árbol de red en anillo o NCCL.
- GDRCopy para coordinar el tráfico de red local NVLink y EFA. GDRCopy es una biblioteca que permite la comunicación de baja latencia entre los procesos de la CPU y los núcleos CUDA de la GPU. Con esta tecnología somos capaces de canalizar el movimiento de datos dentro y entre nodos.
- Uso reducido de multiprocesadores de transmisión de GPU para devolver más potencia informática a los núcleos del modelo. Las instancias AWS P4d/P4de están equipadas con GPU NVIDIA A100, cada una con 108 multiprocesadores de transmisión. Mientras que NCCL requiere hasta 24 multiprocesadores de transmisión para ejecutar colectivos, los colectivos SMDDP solo usan hasta nueve multiprocesadores de transmisión. Los multiprocesadores de transmisión almacenados pueden ser adoptados por núcleos informáticos modelo para una ejecución más rápida.
usar
Los colectivos SMDDP se pueden integrar de forma nativa en PyTorch mediante la abstracción del grupo de procesos torch.distributed
Módulo. Un grupo de procesos define las interfaces para operaciones de recopilación comunes, como AllGather, ReduceScatter, AllReduce, etc. Los usuarios pueden escribir código distribuido genérico y luego seleccionar el código subyacente. backend
, que proporciona la implementación de estas operaciones en función del dispositivo informático utilizado. Los trabajos de entrenamiento de CPU a menudo utilizan el gloo
o mpi
Backend mientras las GPU NVIDIA lo usan nccl
Parte trasera.
La biblioteca SMDDP entra en juego registrándose como un backend personalizado en la abstracción del grupo de procesos. Esto se hace a través de la declaración de importación que se muestra en los siguientes fragmentos de código. Luego, cuando seleccione el backend para su trabajo de entrenamiento distribuido basado en GPU, simplemente reemplácelo nccl
con smddp
. El smddp
El backend sigue la misma semántica que ese. nccl
Backend y admite los mismos escenarios de entrenamiento.
Velocidad profunda
import smdistributed.dataparallel.torch.torch_smddp
deepspeed.init_distributed(dist_backend="smddp") # replacing "nccl"
FSDP
import smdistributed.dataparallel.torch.torch_smddp
dist.init_process_group(backend="smddp") # replacing "nccl"
Puntos de referencia
Comparamos el rendimiento del dispositivo AllGather independiente, donde las operaciones colaborativas se ejecutan de forma aislada y sin entrenamiento de modelos. A continuación se muestra un resultado de muestra para 32 instancias de p4d que comparan NCCL y SMDDP AllGather. Tienen 8 rangos por instancia de p4d que participan en la operación AllGather.
Estos microbenchmarks muestran que SMDDP supera a NCCL con dos características clave:
- El rendimiento máximo de SMDDP (aproximadamente 90 % de utilización del ancho de banda) es mayor que el de NCCL (aproximadamente 80 % de utilización del ancho de banda) en todas las configuraciones.
- SMDDP logra el máximo rendimiento con tamaños de búfer mucho más pequeños que NCCL. Esto mejora particularmente la velocidad de entrenamiento para modelos más pequeños o cuando el usuario establece un tamaño de búfer AllGather pequeño en DeepSpeed (donde el tamaño de AllGather no tiene que ser igual al tamaño de la capa).
Puntos de referencia de entrenamiento modelo
Para tareas de entrenamiento a gran escala donde la comunicación GPU es un cuello de botella importante, SMDDP puede mejorar significativamente la velocidad de entrenamiento medida por el modelo TFLOPS/GPU.
Construcción | Actuación | ||||
Modelo/formación | Clústeres | Solución de simultaneidad de datos fragmentados | Modelo TFLOPS/GPU con NCCL | Modelo TFLOPS/GPU con SMDDP | % acelerar |
13B Lama2 Longitud de secuencia: 4096 Tamaño del lote global: 4 millones de tokens |
64 nodos p4d.24xlarge (512 GPU NVIDIA A100) | FSDP de PyTorch | 97,89 | 121,85 | 24,40% |
65B GPT NeoX Duración de la secuencia: 2048 Tamaño del lote global: 4 millones de tokens |
64 nodos p4d.24xlarge (512 GPU NVIDIA A100) | DeepSpeed Zero etapa 3* | 99,23 | 108,66 | 9,50% |
*Se utilizó el repositorio Megatron DeepSpeed de EleutherAI. El paralelismo tensorial también se habilitó con un grado de paralelo tensorial de ocho.
Nota: El modelo TFLOPS/GPU se basa en el cálculo de utilización del modelo FLOPS definido en este artículo. Los números de referencia en otros lugares pueden mencionar TFLOPS/GPU de hardware como una métrica de rendimiento. Los TFLOPS/GPU de hardware se pueden aproximar a 4/3 x TFLOPS/GPU del modelo.
Diploma
En esta publicación, le mostramos cómo acelerar significativamente los trabajos de capacitación paralelos con datos fragmentados en Amazon SageMaker con solo dos líneas de código. La capacitación distribuida a gran escala se está volviendo más omnipresente con el aumento de los LLM, pero esta escala conlleva altos costos. Al reducir el cuello de botella de comunicación entre GPU, SMDDP le ayuda a entrenar de forma más rápida y escalable y a ahorrar recursos informáticos. Para obtener más ejemplos de SMDDP con entrenamiento paralelo de datos fragmentados, consulte el repositorio GitHub de ejemplos de Amazon SageMaker.
Sobre los autores
Apoorv Gupta es un ingeniero de desarrollo de software en AWS enfocado en crear sistemas óptimos de aprendizaje profundo para la infraestructura y el hardware de AWS. Está interesado en la informática distribuida, los sistemas de aprendizaje profundo y los aceleradores de aprendizaje automático. Fuera del trabajo, a Apoorv le gusta viajar, hacer senderismo y jugar videojuegos.
Karan Dhiman es ingeniero de desarrollo de software en AWS con sede en Toronto, Canadá. Tiene una gran pasión por el campo del aprendizaje automático y el desarrollo de soluciones para acelerar las cargas de trabajo informáticas distribuidas.
Ruhan Prasad es un ingeniero de desarrollo de software en AWS que trabaja para hacer que la capacitación en aprendizaje profundo distribuido sea más rápida, económica y fácil de usar en SageMaker. Fuera del trabajo, a Ruhan le gusta jugar tenis, viajar y cocinar.
Zhaoqi Zhu Es ingeniero sénior de desarrollo de software en AWS y le apasionan los sistemas distribuidos y las optimizaciones de bajo nivel. Le gusta ver partidos de fútbol mientras bebe limonada (sin hacer dieta).
[ad_2]