Seul 1 % des paramètres d'intégration sont nécessaires, les coûts matériels sont réduits de dix fois et la solution open source utilise un seul GPU pour entraîner un grand modèle recommandé.

Les modèles de recommandation approfondie (DLRM) sont devenus le scénario technique le plus important pour l'application de l'apprentissage profond dans les sociétés Internet, tels que la recommandation vidéo, la recherche d'achats, la diffusion publicitaire et d'autres services de monétisation du trafic, qui ont considérablement amélioré l'expérience utilisateur et le commerce commercial. valeur. Cependant, les données massives des utilisateurs et des entreprises, les exigences de mises à jour itératives fréquentes et les coûts de formation élevés posent tous de sérieux défis à la formation DLRM.

Dans DLRM, vous devez d'abord effectuer une recherche dans la table intégrée (EmbeddingBags), puis terminer le calcul en aval. Les tables intégrées contribuent souvent à plus de 99 % des besoins en mémoire du DLRM, mais seulement à 1 % du calcul. Grâce à la mémoire haute vitesse intégrée au GPU (High Bandwidth Memory) et à une puissante puissance de calcul, le GPU est devenu le matériel principal pour la formation DLRM. Cependant, avec l’approfondissement de la recherche sur les systèmes de recommandation, la taille croissante des tables d’intégration et la mémoire GPU limitée constituent une contradiction importante. Comment utiliser le GPU pour former efficacement de très grands modèles DLRM tout en dépassant les limites du mur de mémoire GPU est devenu un problème clé qui doit être résolu dans le domaine du DLRM.

Colossal-AI a déjà utilisé avec succès des stratégies hétérogènes pour augmenter des centaines de fois la capacité des paramètres des modèles NLP formés sur le même matériel. Récemment, il l'a étendu avec succès au système de recommandation, en utilisant le cache logiciel. (Cache) pour augmenter la capacité des paramètres du modèle NLP des centaines de fois et stocker dynamiquement les tables intégrées dans la mémoire GPU. Basé sur la conception du cache logiciel, Colossal-AI ajoute également la prélecture de pipeline pour réduire la récupération du cache logiciel et la surcharge de déplacement des données en observant les données d'entraînement qui seront saisies à l'avenir. Dans le même temps, il entraîne l'intégralité du modèle DLRM sur le GPU de manière synchrone, ce qui, combiné à la méthode d'entraînement parallèle hybride largement utilisée, peut être étendu à plusieurs GPU. Les expériences montrent que Colossal-AI n'a besoin de conserver que 1 % des paramètres d'intégration dans le GPU et peut toujours maintenir une excellente vitesse d'entraînement de bout en bout. Par rapport à d'autres solutions PyTorch, les besoins en mémoire graphique sont réduits d'un ordre de grandeur et une seule carte graphique peut former un modèle de recommandation au niveau du téraoctet. L'avantage en termes de coût est significatif. Par exemple, seulement 5 Go de mémoire vidéo sont nécessaires pour former un DLRM qui occupe un sac d'intégration de 91 Go. Le coût du matériel de formation est décuplé, passant de deux A100 d'environ 200 000 yuans à une carte graphique d'entrée de gamme telle que celle-ci. comme le RTX 3050 qui ne coûte qu'environ 2 000 yuans.

Adresse Open source : https://github.com/hpcaitech/ColossalAI

Technologie d'extension de table d'intégration existante

La table d'intégration mappe les caractéristiques entières discrètes en caractéristiques à virgule flottante continue Vector, ce qui suit La figure montre le processus de formation de la table d'intégration dans DLRM. Tout d'abord, recherchez la ligne correspondant à la table d'intégration pour chaque fonctionnalité dans la table d'intégration, puis utilisez des opérations de réduction, telles que les opérations max, moyenne et somme, pour la transformer en vecteur de fonctionnalités et la transmettre au réseau neuronal dense suivant. . On peut voir que le processus de formation des tables intégrées du DLRM consiste principalement en des opérations d'accès à la mémoire irrégulières, il est donc sévèrement limité par la vitesse d'accès à la mémoire matérielle.

La table intégrée du DLRM de qualité industrielle peut atteindre des centaines de Go, voire des niveaux de To, dépassant de loin la capacité maximale de mémoire vidéo de plusieurs dizaines de Go d'un seul GPU. Il existe de nombreuses façons de briser le mur de mémoire d'un seul GPU pour augmenter la taille de la table intégrée du DLRM. En prenant comme exemple le diagramme de hiérarchie de mémoire du cluster GPU présenté dans la figure ci-dessous, analysons les avantages et les inconvénients de plusieurs solutions courantes.

Parallélisme des modèles GPU : La table d'intégration est divisée et distribuée dans la mémoire de plusieurs GPU, et les résultats intermédiaires sont synchronisés via le réseau d'interconnexion entre GPU pendant l'entraînement. L'inconvénient de cette méthode est que la charge de segmentation des tables intégrées n'est pas uniforme et que le problème d'évolutivité est difficile à résoudre. Deuxièmement, le coût matériel initial de l'ajout d'un GPU est élevé et la puissance de calcul du GPU n'est pas entièrement utilisée pendant la formation DLRM, mais seul son avantage en termes de bande passante HBM est utilisé, ce qui entraîne une faible utilisation du GPU.

Entraînement partiel du CPU : Divisez la table d'intégration en deux parties, une partie est entraînée sur le GPU et l'autre partie est entraînée sur le CPU. En tirant parti de l'effet de longue traîne de la distribution des données, nous pouvons réduire au maximum la proportion de calculs CPU et la proportion de calculs GPU la plus grande possible. Cependant, à mesure que la taille du lot augmente, il est difficile pour toutes les données du mini-lot d'atteindre le CPU ou le GPU. Si les données atteignent le CPU ou le GPU en même temps, cette méthode est difficile à gérer. De plus, étant donné que la bande passante DDR et le HBM sont séparés d'une grandeur de données, même si 10 % des données d'entrée sont formées sur le processeur, l'ensemble du système sera ralenti d'au moins la moitié. De plus, le CPU et le GPU doivent transmettre des résultats intermédiaires, ce qui entraîne également une surcharge de communication considérable et ralentit encore davantage la vitesse d'entraînement. Par conséquent, les chercheurs ont conçu des méthodes telles que les mises à jour asynchrones pour éviter ces défauts de performances. Cependant, les méthodes asynchrones peuvent entraîner une incertitude dans les résultats de la formation et ne constituent pas le premier choix des ingénieurs en algorithmes dans la pratique.

Cache logiciel : Garantit que toute la formation est effectuée sur le GPU. La table d'intégration est stockée dans un espace hétérogène composé de CPU et de GPU. À chaque fois, les pièces requises sont échangées dans le GPU via la méthode de cache logiciel. . Cette méthode peut étendre à moindre coût les ressources de stockage pour répondre aux besoins croissants des tables intégrées. De plus, par rapport à l'utilisation du CPU pour le calcul, l'ensemble du processus de formation de cette manière est entièrement réalisé sur GPU, tirant pleinement parti des avantages de la bande passante HBM. Cependant, les requêtes de cache et les déplacements de données entraîneront des pertes de performances supplémentaires.

Il existe déjà d'excellentes solutions de cache logicielles pour l'intégration de tables, mais elles utilisent souvent des implémentations personnalisées du noyau EmbeddingBags, telles que fbgemm, ou utilisent des frameworks d'apprentissage en profondeur tiers. Colossal-AI n'apporte aucune modification au niveau du noyau basée sur le PyTorch natif et fournit un ensemble de logiciels prêts à l'emploi d'implémentation de Cache EmbeddingBags. Il optimise davantage le processus de formation DLRM et propose un pipeline de prélecture pour. réduire davantage les frais généraux du cache.

Hiérarchie de la mémoire

Cache du logiciel de table intégré de Colossal-AI

Colossal-AI implémente un cache logiciel et le conditionne dans nn.Module pour que les utilisateurs puissent l'utiliser dans leurs propres modèles. . La table d'intégration du DLRM est généralement constituée de EmbeddingBags composés de plusieurs Embeddings et réside dans la mémoire du processeur. Cette partie de l'espace mémoire est appelée CPU Weight. Une petite partie des données d'EmbeddingBags est stockée dans la mémoire du GPU, qui comprend les données à utiliser pour l'entraînement. Cette partie de l’espace mémoire est nommée CUDA Cached Weight. Lors de la formation DLRM, vous devez d'abord déterminer les lignes de la table intégrée correspondant aux données saisies dans le mini-batch pour cette itération. Si certaines lignes ne sont pas dans le GPU, elles doivent être transférées du poids du CPU vers le CUDA. Poids mis en cache. S'il n'y a pas assez d'espace dans le GPU, il utilise l'algorithme LFU pour expulser les données les moins utilisées en fonction de la fréquence historique d'accès au cache.

Pour implémenter la récupération du cache, certaines structures de données auxiliaires sont nécessaires : cached_idx_map est un tableau unidimensionnel qui stocke la correspondance entre les numéros de ligne dans le poids du CPU et le poids mis en cache CUDA, ainsi que la fréquence. informations sur les lignes correspondantes accessibles sur le GPU. Le rapport entre la taille du poids mis en cache CUDA et la taille du poids du CPU est nommé cache_ratio et la valeur par défaut est de 1,0 %.

Le cache s'exécute avant chaque itération pour ajuster les données dans CUDA Weight, plus précisément en trois étapes.

Étape 1 : Index CPU : Récupérez le numéro de ligne qui doit être mis en cache dans le poids du CPU

Il doit prendre l'intersection des input_ids et cached_idx_map du mini-lot d'entrée, et trouver la ligne numéro qui doit être déplacé du CPU vers le GPU dans le numéro de ligne de poids du CPU.

Étape 2 : Index GPU : Trouver les lignes qui peuvent être expulsées dans CUDA Weight en fonction de la fréquence d'utilisation

Cela nous oblige à prendre la partie après l'ensemble des différences de cache_idx_map et input_ids dans l'ordre de bas à élevé en fonction de la fréquence. opération top-k (prendre le maximum de nombres k).

Étape 3 : Déplacement des données :

Déplacez les lignes correspondantes dans le poids mis en cache CUDA vers le poids du processeur, puis déplacez les lignes correspondantes dans le poids du processeur vers le poids CUDA.

Le module de transmission de données est responsable de la transmission bidirectionnelle des données entre le poids mis en cache CUDA et le poids du CPU. Contrairement à la transmission ligne par ligne inefficace, elle utilise d'abord le cache, puis la transmission centralisée pour améliorer l'utilisation de la bande passante PCI-e. Les lignes intégrées dispersées dans la mémoire sont rassemblées en blocs de données contigus dans la mémoire locale du périphérique source, et les blocs sont ensuite transférés entre le CPU et le GPU et dispersés vers les emplacements correspondants dans la mémoire cible. Le déplacement de données en blocs peut améliorer l'utilisation de la bande passante PCI-e, et les opérations de fusion et de dispersion impliquent uniquement des accès à la mémoire sur puce pour le CPU et le GPU, de sorte que la surcharge n'est pas très importante.

Colossal-AI utilise un tampon de taille limitée pour transférer des données entre le CPU et le GPU. Dans le pire des cas, tous les identifiants d'entrée manquent le cache et un grand nombre d'éléments doivent être transférés. Pour éviter que le tampon n'occupe trop de mémoire, la taille du tampon est strictement limitée. Si les données transférées sont plus volumineuses que la mémoire tampon, le transfert sera effectué plusieurs fois.

Cached EmbeddingBag Workflow

Analyse des performances du cache logiciel

Les opérations de cache Step1 et Step2 ci-dessus nécessitent toutes deux un accès mémoire intensif. Par conséquent, afin de profiter de la bande passante du GPU HBM, ils sont exécutés sur le GPU et implémentés à l'aide d'API encapsulées par des frameworks d'apprentissage profond. Néanmoins, la surcharge des opérations de Cache est particulièrement importante par rapport aux opérations de formation sur le GPU pour l'intégration de tables.

Par exemple, dans une tâche de formation qui dure 199 secondes, la surcharge du fonctionnement du cache est de 99 secondes, ce qui représente près de 50 % du temps de calcul total. Après analyse, la principale surcharge du cache est principalement causée par les étapes 1 et 2. La position de base dans la figure ci-dessous montre la répartition temporelle de la surcharge du cache à ce moment-là. Les étapes rouge et orange des étapes 1 et 2 du cache représentent 70 % de la surcharge totale du cache.

Répartition temporelle des opérations de cache

La raison du problème ci-dessus est que la stratégie de cache traditionnelle est quelque peu "à courte vue" et ne peut ajuster le cache qu'en fonction du mini actuel -situation par lots, c'est donc un gros problème Une partie du temps est perdue sur les opérations de requête.

Cache Pipeline Prefetch

Afin de réduire la surcharge du cache, Colossal-AI a conçu un mécanisme de cache « prospectif » . Au lieu d'effectuer uniquement des opérations de cache sur le premier mini-lot, Colossal-AI pré-extrait plusieurs mini-lots qui seront utilisés ultérieurement et exécute les opérations de requête de cache de manière unifiée.

Comme le montre la figure ci-dessous, Colossal-AI utilise la prélecture pour fusionner plusieurs données en mini-lots pour des opérations de cache unifiées, et utilise également une approche pipeline pour chevaucher la surcharge de lecture et de calcul des données. Dans l’exemple, le numéro du mini-lot de prélecture est 2. Avant de commencer l'entraînement, les données du mini-lot 0,1 sont lues du disque vers la mémoire GPU, puis l'opération de cache est lancée, puis la propagation vers l'avant et vers l'arrière et les mises à jour des paramètres des deux mini-lots sont effectuées. Dans le même temps, la lecture initiale des données pour les mini-lots 2 et 3 peut être effectuée, et cette surcharge peut chevaucher le calcul.

Par rapport à la méthode d'exécution du cache de base, la figure [Répartition temporelle des opérations de cache] compare la répartition temporelle du cache du mini-lot de prélecture 8 et de la ligne de base. Le temps total de formation est passé de 201 secondes à 120 secondes, et la proportion de temps de fonctionnement de la phase de cache indiquée dans la figure a également diminué de manière significative. On peut voir que par rapport au fait que chaque mini-lot effectue des opérations de cache indépendamment, le temps de chaque partie est réduit, en particulier les deux premières étapes des opérations de cache.

Pour résumer, la prélecture du pipeline de cache apporte deux avantages.

a. Diluer la surcharge de l'index du cache

L'avantage le plus évident de la prélecture est de réduire la surcharge de l'étape 1 et de l'étape 2, ce qui fait que cette opération en deux étapes représente moins de 5 % du processus de formation total. Comme le montre la section [Répartition temporelle des opérations de cache], en prélevant 8 données en mini-lots, la surcharge de la requête de cache est considérablement réduite par rapport à la ligne de base sans prélecture.

b. Augmentez la bande passante de mouvement des données CPU-GPU

Améliorez la granularité de la transmission des données en concentrant plus de données, exploitant ainsi pleinement la bande passante de transmission CPU-GPU. Pour l'exemple ci-dessus, la bande passante CUDA->CPU passe de 860 Mo/s à 1 477 Mo/s, et la bande passante CPU->CUDA passe de 1 257 Mo/s à 2 415 Mo/s, ce qui double presque le gain de performances.

Facile à utiliser

L'utilisation est la même que celle de Pytorch EmbeddingBag Lors de la création d'un modèle de recommandation, seules les lignes de code suivantes sont requises pour l'initialisation, ce qui peut augmenter considérablement la capacité de la table d'intégration et atteindre une recommandation importante au niveau de la To. formation sur modèle à faible coût.

Bashfrom colossalai.nn.parallel.layers.cache_embedding import CachedEmbeddingBag
emb_module = CachedEmbeddingBag(num_embeddings=num_embeddings,embedding_dim=embedding_dim,mode="sum"include_last_offset=True,sparse=True,_weight=torch.randn(num_embeddings, embedding_dim),warmup_ratio=0.7,cache_ratio = 0.01,)

Test de performances

Sur les plates-formes matérielles NVIDIA A100 GPU (80 Go) et AMD EPYC 7543 32-Core Processor (512 Go), Colossal-AI utilise le modèle DLRM de Meta comme cible de test, en utilisant les données ultra volumineuses set Cretio 1 To et dlrm_datasets de Meta génèrent des ensembles de données en tant que modèles de test. Dans l'expérience, la vitesse d'entraînement PyTorch de stockage de toutes les tables d'intégration sur le GPU est utilisée comme référence.

Cretio 1 To

La table d'intégration Cretio 1 To a un total de 177944275 lignes, définissant l'intégration dim = 128, et sa mémoire requise pour la table d'intégration est de 91,10 Go. Même le Nvidia A100 80 Go le plus haut de gamme ne peut pas répondre aux besoins en mémoire nécessaires au stockage de tous les EmbeddingBags dans une seule mémoire GPU.

Mais en utilisant Colossal-AI, la formation est toujours effectuée sur un seul GPU. Lorsque le taux de cache = 0,05, la consommation de mémoire n'est que de 5,01 Go, ce qui est directement réduit d'environ 18 fois. Elle peut être encore étendue pour implémenter un. Système de recommandation au niveau du téraoctet sur un seul GPU Formation de modèle. En termes de vitesse de formation, comme le montre la figure ci-dessous, elle montre le retard de formation de 100 millions d'échantillons sous différentes tailles de lots. Le Prefetch1 vert est le délai sans prélecture, et le Prefetch8 bleu est le délai utilisant la prélecture (mini-batch de prélecture = 8). On peut voir que l'optimisation du pipeline de prélecture joue un rôle important dans l'amélioration des performances globales. La partie sombre de chaque colonne de la figure représente la surcharge du cache. Après avoir utilisé la prélecture, la surcharge du cache est contrôlée dans les 15 % du temps total de formation.

Évolutivité multi-GPU

Utilisez 8192 comme taille de lot globale, utilisez le partitionnement par table comme EmbeddingBags sur 8 cartes GPU pour entraîner le DLRM en parallèle et entraînez 100 millions d'échantillons. À ce stade, définissez la taille de Prefetch sur 4, ColossalAI-mem-cr0.05 a un rapport de cache = 0,05 et ColossalAI-mem-cr0.5 = 0,5. La figure ci-dessous montre la latence d'entraînement pour différents scénarios GPU. Sauf que PyTorch OOM ne peut pas être entraîné lors de l'utilisation de 1 GPU, les temps d'entraînement de PyTorch et Colossal-AI sont similaires dans les autres cas. On peut observer que l'utilisation de 4 et 8 GPU n'apporte pas d'améliorations significatives des performances, car 1. La synchronisation des résultats nécessite une énorme surcharge de communication. 2. Le partitionnement par table entraînera un déséquilibre de charge de partitionnement. Cela montre également que l'utilisation de plusieurs GPU pour étendre l'évolutivité de la formation des tables d'intégration n'est pas très bonne.

L'image ci-dessous montre l'utilisation de la mémoire vidéo. L'utilisation de la mémoire vidéo est différente selon les cartes. Lorsqu'un seul GPU est utilisé, seule la méthode de cache logiciel de Colossal-AI peut être entraînée, et la mémoire occupée par plusieurs cartes en parallèle est également considérablement réduite à plusieurs reprises.

L'ensemble de données synthétiques dlrm_datasets de Meta Research imite le comportement d'accès à la formation des tables intégrées dans l'industrie, il est donc souvent utilisé comme référence de test pour les conceptions logicielles et matérielles liées aux systèmes de recommandation dans la recherche. Sélectionnez 500 millions de lignes d'éléments de tableau incorporés en tant que sous-ensemble de données et construisez deux EmbeddingBags de 256 Go et 128 Go à des fins de test.

PyTorch ne peut pas être entraîné sur une seule carte A100 en raison d'une mémoire vidéo insuffisante. En revanche, le cache logiciel de Colossal-AI réduira considérablement les besoins en mémoire GPU, suffisamment pour entraîner des tables d'intégration allant jusqu'à 256 Go, et pourra être étendu jusqu'au niveau de la To. De plus, la prélecture du pipeline peut également avoir des effets d'accélération. Lorsque le nombre de prélecture est de 32, la durée totale est réduite de 60 % par rapport à l'absence de prélecture et la demande de stockage GPU n'augmente pas.

One More Thing

Colossal-AI, un système d'apprentissage profond général pour l'ère des grands modèles, utilise un certain nombre de technologies de pointe auto-développées telles que le parallélisme automatique multidimensionnel efficace, hétérogène gestion de la mémoire et bibliothèques d'optimisation à grande échelle, planification adaptative des tâches, etc. pour réaliser un déploiement efficace et rapide de la formation et de l'inférence de grands modèles d'IA, et réduire le coût de l'application de grands modèles d'IA.

Les solutions liées à Colossal-AI ont été mises en œuvre avec succès par des fabricants renommés dans les domaines de la conduite autonome, du cloud computing, de la vente au détail, de la médecine, des puces et d'autres secteurs, et ont été largement saluées.

Colossal-AI se concentre sur la création de communautés open source, fournit des didacticiels en chinois, ouvre des communautés d'utilisateurs et des forums, effectue une communication efficace et des mises à jour itératives pour les commentaires des utilisateurs et ajoute continuellement des applications de pointe telles que PaLM, AlphaFold et OPT.

Depuis qu'il était naturellement open source, Colossal-AI s'est classé à plusieurs reprises au premier rang mondial sur les listes chaudes de GitHub et Papers With Code, et a attiré l'attention au pays et à l'étranger avec de nombreux projets open source vedettes comptant des dizaines de milliers de personnes. d'étoiles !

Adresse open source du projet : https://github.com/hpcaitech/ColossalAI

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!