Présentation du parallélisme des modèles

Le parallélisme de modèle est une méthode d'entraînement distribué dans laquelle le modèle de deep learning est partitionné sur plusieurs appareils, au sein des instances ou entre celles-ci. Cette page d'introduction fournit une présentation générale du parallélisme des modèles, une description de la manière dont il peut aider à résoudre les problèmes qui surviennent lors de l'entraînement de modèles DL généralement de très grande taille, et des exemples de ce que propose la bibliothèque de modèles SageMaker parallèles pour aider à gérer les stratégies de modélisation parallèle ainsi que la consommation de mémoire.

Qu'est-ce que le parallélisme des modèles ?

L'augmentation de la taille des modèles de deep learning (couches et paramètres) permet une meilleure précision pour des tâches complexes telles que la reconnaissance d'image et le traitement du langage naturel. Toutefois, il y a une limite à la taille maximale de modèle que vous pouvez faire tenir dans la mémoire d'un GPU individuel. Lors de l'entraînement de modèles DL, les limites de mémoire du GPU peuvent constituer un goulet d'étranglement :

• Elles limitent la taille du modèle que vous pouvez entraîner, car l'empreinte mémoire d'un modèle évolue proportionnellement au nombre de paramètres.

• Elles limitent la taille de lot par GPU pendant l'entraînement, ce qui réduit l'utilisation du GPU et l'efficacité de l'entraînement.

Pour surmonter les limites associées à l'entraînement d'un modèle sur un seul GPU, SageMaker fournit la bibliothèque model parallel qui permet de distribuer et d'entraîner efficacement les modèles DL sur plusieurs nœuds de calcul. En outre, cette bibliothèque vous permet de profiter d'un entraînement distribué optimisé à l'aide d'appareils intégrant EFA, qui améliorent les performances de la communication entre les nœuds avec une faible latence, un débit élevé et le contournement du système d'exploitation.

Estimation des besoins en mémoire avant d'utiliser le parallélisme de modèle

Avant d'utiliser la bibliothèque SageMaker model parallel, considérez les points suivants pour vous faire une idée des besoins en mémoire liés à l'entraînement de grands modèles DL.

Pour une tâche d'entraînement utilisant les optimiseurs AMP (FP16) et Adam, la mémoire GPU requise par paramètre est d'environ 20 octets, que nous pouvons décomposer comme suit :

• Un paramètre FP16 ~ 2 octets

• Un gradient FP16 ~ 2 octets

• Un état d'optimiseur FP32 ~ 8 octets en fonction des optimiseurs Adam

• Une copie de paramètre FP32 ~ 4 octets (requis pour l'opération optimizer apply (OA))

• Une copie de gradient FP32 ~ 4 octets (requis pour l'opération OA)

Même un modèle DL relativement petit, avec 10 milliards de paramètres, peut nécessiter au moins 200 Go de mémoire, ce qui dépasse nettement la mémoire GPU standard (par exemple, NVIDIA A100 avec 40/80 Go de mémoire et V100 avec 16/32 Go) disponible sur un GPU individuel. Notez qu'en plus des besoins en mémoire pour les états de modèle et d'optimiseur, il existe d'autres consommateurs de mémoire tels que les activations générées dans la transmission vers l'avant. La mémoire requise peut être largement supérieure à 200 Go.

Pour un entraînement distribué, nous vous recommandons d'utiliser des instances Amazon EC2 P3 et P4 dotées de GPU Tensor Core NVIDIA V100 et A100, respectivement. Pour plus de détails sur les spécifications telles que les cœurs de processeur, la RAM, le volume de stockage attaché et la bande passante du réseau, consultez la section Calcul accéléré de la page Types d'instances Amazon EC2.

Même avec les instances de calcul accéléré, il est évident que des modèles avec environ 10 milliards de paramètres, tels que Megatron-LM et T5, et des modèles encore plus grands avec des centaines de milliards de paramètres, tels que GPT-3, ne peuvent pas faire tenir les réplicas de modèles dans chaque périphérique GPU.

Utilisation par la bibliothèque des techniques d'économie de mémoire et de parallélisme de modèle

La bibliothèque comprend différents types de fonctionnalités de parallélisme de modèle et de fonctionnalités d'économie de mémoire, telles que le partitionnement de l'état de l'optimiseur, les points de contrôle d'activation et le déchargement d'activation. Toutes ces techniques peuvent être combinées pour entraîner efficacement des modèles de grande taille composés de centaines de milliards de paramètres.

Parallélisme de données fragmenté (disponible pour) PyTorch

Le parallélisme de données partitionnées est une technique d'entraînement distribué qui permet d'économiser de la mémoire et qui divise l'état d'un modèle (paramètres du modèle, gradients et états de l'optimiseur) entre les GPU dans un groupe de parallélisme de données.

SageMaker implémente le parallélisme des données fragmenté grâce à la mise en œuvre de MICS, une bibliothèque qui minimise l'échelle de la communication et dont il est question dans le billet de blog sur la mise à l'échelle quasi linéaire d'un gigantesque modèle d'entraînement sur. AWS

Vous pouvez appliquer le parallélisme de données partitionnées à votre modèle en tant que stratégie autonome. De plus, si vous utilisez les instances de GPU les plus performantes équipées de GPU Tensor Core NVIDIA A100, ml.p4d.24xlarge, vous pouvez profiter de la vitesse d'entraînement améliorée grâce au fonctionnement AllGather proposé par SMDDP Collectives.

Pour approfondir le parallélisme de données partitionnées et découvrir comment le configurer ou utiliser une combinaison du parallélisme de données partitionnées avec d'autres techniques telles que le parallélisme de tenseurs et l'entraînement FP16, consultez Parallélisme des données partitionnées.

Parallélisme du pipeline (disponible pour PyTorch et) TensorFlow

Le parallélisme de pipeline partitionne l'ensemble de couches ou d'opérations sur l'ensemble de dispositifs, laissant chaque opération intacte. Lorsque vous spécifiez une valeur pour le nombre de partitions de modèle (pipeline_parallel_degree), le nombre total de GPU (processes_per_host) doit être divisible par le nombre de partitions de modèle. Pour configurer cela correctement, vous devez spécifier les bonnes valeurs pour les paramètres pipeline_parallel_degree et processes_per_host. Le calcul simple est le suivant :

(pipeline_parallel_degree) x (data_parallel_degree) = processes_per_host

La bibliothèque se charge de calculer le nombre de réplicas du modèle (également appelé data_parallel_degree) en fonction des deux paramètres d'entrée que vous fournissez.

Par exemple, si vous définissez "pipeline_parallel_degree": 2 et "processes_per_host": 8 pour utiliser une instance ML avec huit collaborateurs GPU tels que ml.p3.16xlarge, la bibliothèque configure automatiquement le modèle distribué sur l'ensemble des GPU et un parallélisme de données à quatre voies. L'image suivante illustre la distribution d'un modèle sur les huit GPU avec un parallélisme des données à quatre voies et un parallélisme de pipeline bidirectionnel. Chaque réplica de modèle pour lequel nous le définissons comme un groupe de parallélisme de pipeline et lui appliquons l'étiquette PP_GROUP est partitionné sur deux GPU. Chaque partition du modèle est affectée à quatre GPU, et les quatre réplicas de partition se trouvent dans un groupe de parallélisme de données et sont étiquetés DP_GROUP. Sans parallélisme de tenseur, le groupe de parallélisme de pipeline est essentiellement le groupe de parallélisme de modèle.

Pour explorer le parallélisme de pipeline, consultez Principales fonctionnalités de la bibliothèque de parallélisme des SageMaker modèles.

Pour commencer à exécuter votre modèle à l'aide du parallélisme de pipeline, voir Run a SageMaker Distributed Training Job with the SageMaker Model Parallel Library.

Parallélisme tensoriel (disponible pour) PyTorch

Le parallélisme de tenseurs divise les couches individuelles, ou nn.Modules, entre les dispositifs, pour qu'elles soient exécutées en parallèle. La figure suivante illustre l'exemple le plus simple de la façon dont la bibliothèque divise un modèle à quatre couches pour obtenir un parallélisme de tenseur bidirectionnel ("tensor_parallel_degree": 2). Les couches de chaque réplica de modèle sont divisées et distribuées dans deux GPU. Dans ce cas d'exemple, la configuration parallèle du modèle inclut également "pipeline_parallel_degree": 1 et "ddp": True (utilise le PyTorch DistributedDataParallel package en arrière-plan), de sorte que le degré de parallélisme des données passe à huit. La bibliothèque gère la communication entre les réplicas de modèles distribués par tenseur.

L'utilité de cette fonctionnalité réside dans le fait que vous pouvez sélectionner des couches spécifiques ou un sous-ensemble de couches pour appliquer le parallélisme de tenseur. Pour en savoir plus sur le parallélisme des tenseurs et d'autres fonctionnalités permettant d'économiser de la mémoire PyTorch, et pour apprendre à définir une combinaison de parallélisme de pipeline et de tenseur, voir. Parallélisme de tenseur

Sharding de l'état de l'optimiseur (disponible pour) PyTorch

Pour comprendre comment la bibliothèque effectue le partitionnement de l'état de l'optimiseur, envisagez un exemple de modèle simple à quatre couches. L'idée clé de l'optimisation du partitionnement de l'état est que vous n'avez pas besoin de répliquer l'état de votre optimiseur dans tous vos GPU. Au lieu de cela, un seul réplica de l'état de l'optimiseur est partitionné entre les rangs parallèles de données, sans redondance entre les appareils. Par exemple, le GPU 0 conserve l'état de l'optimiseur pour la couche 1, le GPU 1 suivant contient l'état de l'optimiseur pour la couche 2 (L2), etc. La figure animée suivante montre une propagation vers l'arrière avec la technique de partitionnement de l'état de l'optimiseur. À la fin de la propagation vers l'arrière, il y a le temps de calcul et de réseau pour l'opération optimizer apply (OA) pour mettre à jour les états de l'optimiseur et l'opération all-gather (AG) pour mettre à jour les paramètres du modèle pour la prochaine itération. Surtout, l'opération reduce peut chevaucher le calcul sur GPU 0, ce qui entraîne une propagation vers l'arrière plus rapide et plus efficace en termes de mémoire. Dans l'implémentation actuelle, les opérations AG et OA ne chevauchent pas compute. Cela peut entraîner un calcul étendu pendant l'opération AG, pouvant donner lieu à un compromis.

Pour plus d'informations sur l'utilisation de cette fonctionnalité, consultez Partitionnement de l'état de l'optimiseur.

Activation, déchargement et point de contrôle (disponible pour) PyTorch

Pour enregistrer la mémoire GPU, la bibliothèque prend en charge les points de contrôle d'activation afin d'éviter de stocker des activations internes dans la mémoire GPU pour les modules spécifiés par l'utilisateur pendant la transmission vers l'avant. La bibliothèque recalcule ces activations pendant la transmission vers l'arrière. En outre, la fonctionnalité de déchargement d'activation décharge les activations stockées dans la mémoire CPU et les récupère dans le GPU pendant la transmission vers l'arrière, afin de réduire encore l'empreinte mémoire d'activation. Pour plus d'informations sur l'utilisation de ces fonctionnalités, consultez Points de contrôle d'activation et Déchargement de l'activation.

Choix des techniques appropriées pour votre modèle

Pour plus d'informations sur le choix des techniques et des configurations appropriées, consultez les meilleures pratiques parallèles en matière de modèles SageMaker distribués et les conseils et pièges en matière de configuration.