Answer.AI publie son premier projet : un système entièrement open source qui, pour la première fois, peut entraîner efficacement un grand modèle de langage de 70b sur un ordinateur de bureau ordinaire avec deux ou plusieurs GPU de jeu standard (RTX 3090 ou 4090). Ce système, qui combine FSDP et QLoRA, est le résultat d'une collaboration entre Answer.AI, Tim Dettmers (U Washington), et Hugging Face's Titus von Koeller et Sourab Mangrulkar.Ce système aidera la communauté open source à produire de meilleurs modèles. Teknium, le créateur des modèles et des ensembles de données OpenHermes extrêmement populaires, avec plus d'un demi-million de téléchargements, a déclaré :
"Grâce à cette capacité, nous pouvons porter localement d'énormes modèles à de nouveaux sommets, et des modèles gigantesques, comportant des centaines de milliards de paramètres, sont désormais accessibles à de petits laboratoires."
Contexte
La grande idée
Il existe deux niveaux très différents de matériel utilisé pour entraîner les modèles d'apprentissage profond. Il y a d'abord le matériel destiné aux centres de données, comme les H100 et les A100, qui coûte des centaines de milliers de dollars. Ensuite, il y a les ordinateurs de bureau contenant des GPU de jeu, comme les doubles 4090, qui coûtent moins de 10 000 dollars (et qui peuvent être assemblés à partir de pièces d'occasion pour moins de la moitié du prix d'un système pré-construit).
Mais voici le point clé : les GPU de jeu ont des performances similaires à celles des GPU de centre de données qui coûtent plus de 10 fois plus cher ! Ce serait formidable si on pouvait utiliser ces cartes 10 fois moins chères (mais presque aussi rapides) pour entraîner de grands modèles de langage, mais ce n'est pas possible, car elles ont beaucoup moins de mémoire. Les meilleures cartes actuellement disponibles pour les centres de données disposent de 80 Go de RAM, tandis que les cartes de jeu ne dépassent pas 24 Go de RAM. Étant donné que seuls les modèles les plus volumineux produisent les meilleurs résultats, la création des meilleurs modèles est largement inaccessible à la plupart des gens.
Answer.AI :
Nous nous sommes rendu compte qu'il n'y avait pas de raison intrinsèque à cela. Le matériel super rapide est là, attendant d'être utilisé - nous avons juste besoin d'un moyen de l'alimenter avec le modèle et les données d'une manière qui respecte ses contraintes de mémoire. La question évidente est : pourquoi cela n'a-t-il pas été fait ? Tous les grands laboratoires industriels disposent déjà d'un matériel dix fois plus coûteux, ce qui ne les incite pas vraiment à se pencher sur la question.
L'idée est simple : trouver comment utiliser ces GPU de jeu moins chères et à faible mémoire pour entraîner les meilleurs modèles open source disponibles. L'objectif est donc le suivant : entraîner un modèle à 70 milliards de paramètres (70b) en utilisant uniquement des GPU de jeu, ce qui signifie que notre mémoire par GPU sera au maximum de 24 Go. Ce sera un défi, car chaque paramètre prend normalement 16 bits (2 octets), ce qui fait 70*2=140Go pour stocker les poids - et c'est sans compter toutes les autres données telles que les activations, les gradients et l'état de l'optimisation !
Nous nous sommes rendu compte qu'il n'y avait pas de raison intrinsèque à cela. Le matériel super rapide est là, attendant d'être utilisé - nous avons juste besoin d'un moyen de l'alimenter avec le modèle et les données d'une manière qui respecte ses contraintes de mémoire. La question évidente est : pourquoi cela n'a-t-il pas été fait ? Tous les grands laboratoires industriels disposent déjà d'un matériel dix fois plus coûteux, ce qui ne les incite pas vraiment à se pencher sur la question.
L'idée est simple : trouver comment utiliser ces GPU de jeu moins chères et à faible mémoire pour entraîner les meilleurs modèles open source disponibles. L'objectif est donc le suivant : entraîner un modèle à 70 milliards de paramètres (70b) en utilisant uniquement des GPU de jeu, ce qui signifie que notre mémoire par GPU sera au maximum de 24 Go. Ce sera un défi, car chaque paramètre prend normalement 16 bits (2 octets), ce qui fait 70*2=140Go pour stocker les poids - et c'est sans compter toutes les autres données telles que les activations, les gradients et l'état de l'optimisation !
Pourquoi ce projet ?
Answer.AI est un type d'organisation très inhabituel - un laboratoire de R&D à but lucratif plus proche dans l'esprit des laboratoires d'électricité du 19ème siècle que des groupes de recherche en IA d'aujourd'hui. Trouver comment rendre l'entraînement de grands modèles peu coûteux et accessible est exactement le genre de chose qu'Eric Ries et Jeremy Howard espéraient que Answer.AI serait capable de faire lorsque l'organisation a été lancée à NeurIPS l'année dernière.
Résoudre ce problème est difficile. Il faut comprendre de nombreuses bibliothèques distinctes (par exemple bitsandbytes, PEFT, Transformers, Accelerate et PyTorch), ainsi que des concepts informatiques et mathématiques (par exemple discrétisation, calcul distribué, programmation GPU, algèbre linéaire, concepts SGD tels que le point de contrôle du gradient), et la manière dont ils interagissent tous.
Le monde universitaire regorge de personnes brillantes qui résolvent des problèmes difficiles. Mais le monde universitaire n'a pas résolu ce problème particulier. En effet, il est difficile pour les chercheurs universitaires de justifier le temps qu'ils consacrent à ce type de travail. La combinaison d'outils et de techniques existants n'est généralement pas considérée comme suffisamment "nouvelle" pour donner lieu à une publication dans une revue à fort impact, mais c'est la monnaie d'échange dont les universitaires ont besoin. En outre, on attend généralement des universitaires qu'ils deviennent très spécialisés dans leur domaine, ce qui rend difficile le regroupement de tant d'éléments en une seule solution.
Et, bien sûr, les grandes entreprises technologiques sont également remplies de personnes brillantes qui résolvent des problèmes difficiles. Mais ce problème particulier, l'entraînement de modèles avec des GPU grand public, n'est pas un problème qu'elles doivent résoudre - elles ont déjà acheté les grosses GPU coûteuses ! De nombreuses startups sont également composées de personnes brillantes qui résolvent des problèmes difficiles ! Mais, comme l'explique Eric Ries, "le marché financier actuel oblige les entreprises à privilégier les gains à court terme sur tout le reste". Il est extrêmement difficile pour une startup de justifier auprès des investisseurs pourquoi elle dépense ses fonds pour des logiciels open source et la recherche publique.
Answer.AI :
Alors que les universités, les grandes entreprises technologiques et les startups avaient de bonnes raisons de ne pas résoudre ce problème, ce sont précisément les raisons pour lesquelles ce problème convenait parfaitement à Answer.AI. Tous les employés de l'entreprise ont construit les types de systèmes avec lesquels nous devions travailler sur ce problème, ce qui nous a permis de comprendre comment toutes les pièces s'emboîtaient les unes dans les autres. Les personnes qui aiment à la fois comprendre en profondeur les fondements des logiciels et de l'IA, et qui aiment aussi bidouiller des systèmes de bout en bout amusants et intéressants sont le genre de personnes qui sont attirées par Answer.AI, et vice versa.
Les problèmes que nous choisissons de résoudre ensemble sont sélectionnés par les mêmes personnes qui feront la résolution. Nous avons donc tendance à choisir des projets qui impliquent de rassembler plusieurs idées pour créer des solutions utiles sur le plan pratique. Et comme nous sommes une entreprise d'utilité publique dont la charte vise à tirer des avantages à long terme de l'IA, les logiciels libres et la recherche publique sont directement en phase avec notre mission.
Alors que les universités, les grandes entreprises technologiques et les startups avaient de bonnes raisons de ne pas résoudre ce problème, ce sont précisément les raisons pour lesquelles ce problème convenait parfaitement à Answer.AI. Tous les employés de l'entreprise ont construit les types de systèmes avec lesquels nous devions travailler sur ce problème, ce qui nous a permis de comprendre comment toutes les pièces s'emboîtaient les unes dans les autres. Les personnes qui aiment à la fois comprendre en profondeur les fondements des logiciels et de l'IA, et qui aiment aussi bidouiller des systèmes de bout en bout amusants et intéressants sont le genre de personnes qui sont attirées par Answer.AI, et vice versa.
Les problèmes que nous choisissons de résoudre ensemble sont sélectionnés par les mêmes personnes qui feront la résolution. Nous avons donc tendance à choisir des projets qui impliquent de rassembler plusieurs idées pour créer des solutions utiles sur le plan pratique. Et comme nous sommes une entreprise d'utilité publique dont la charte vise à tirer des avantages à long terme de l'IA, les logiciels libres et la recherche publique sont directement en phase avec notre mission.
Deux projets ont été publiés récemment, qui ont franchi les premières étapes critiques pour faire de ce projet une réalité : QLoRA (par Tim Dettmers et al), et FSDP (par l'équipe PyTorch de Meta).
QLoRA est une combinaison simple mais brillante de deux avancées cruciales dans les réseaux neuronaux modernes : la quantification et LoRA. La quantification est une technique qui consiste à utiliser 4 bits (ou même moins) au lieu de 16 ou même 32 bits pour stocker les poids d'un réseau neuronal. Il n'y a que 16 valeurs possibles pour un nombre de 4 bits, mais Dettmers et Zettlemoyer ont montré que cela pouvait suffire dans les grands modèles de langage qui sont populaires aujourd'hui. Tim Dettmers a facilité la création de ces modèles "quantifiés" à 4 bits, grâce à sa bibliothèque bitsandbytes, et Hugging Face a récemment pris le relais pour aider à maintenir et à documenter cette bibliothèque, notamment grâce à l'initiative de Titus von Koeller.
Malheureusement, une fois qu'un modèle est quantifié, il ne peut plus être entraîné avec les approches habituelles - avec seulement 16 valeurs possibles, la méthode de descente de gradient utilisée pour l'entraînement du modèle observera des gradients nuls presque partout, et ne pourra donc pas faire de mises à jour des poids quantifiés. Il s'agit d'un problème majeur, car cela signifie que la quantification ne peut être utilisée que pour l'inférence, et non pour un pré-entraînement continu ou un réglage fin. Bien que l'inférence soit utile et importante, elle ne fait que consommer des modèles. Mais Answer.AI veut que tout le monde puisse contribuer à la création de modèles !
L'astuce pour éviter cette limitation consiste à utiliser LoRA - "Low-Rank Adaptation of Large Language Models" (Adaptation à faible rang des grands modèles de langage). LoRA n'entraîne pas du tout le grand modèle de langage, mais ajoute des "adaptateurs", qui sont de très petites matrices (généralement inférieures à 1 % du modèle complet) qui sont entraînées, tout en gardant le reste du modèle constant. Si vous avez joué avec des modèles tels que la diffusion stable, vous avez probablement vu ces adaptateurs à de nombreuses reprises ; c'est ainsi que ces modèles sont généralement partagés, et c'est pourquoi ils sont si petits et si rapides à télécharger.
Tim s'est rendu compte que la LoRA pouvait être combinée avec la quantification : utiliser un modèle de base quantifié, qui n'est pas du tout modifié par l'entraînement, et ajouter des adaptateurs LoRA entraînables qui ne sont pas quantifiés. Cette combinaison est appelée QLoRA. L'équipe de Tim a pu l'utiliser pour, pour la première fois, entraîner un modèle qui (non quantifié) est plus grand que la GPU : ils ont entraîné un modèle de 65b (qui est 130 Go non quantifié) sur une carte de 48 Go.
Hugging Face est intervenu une fois de plus ici, en créant la bibliothèque PEFT, qui a rendu l'entraînement LoRA beaucoup plus simple, et en l'intégrant directement à bitsandbytes pour permettre à quiconque d'utiliser QLoRA avec seulement quelques lignes de code. L'équipe de Hugging Face a travaillé sans relâche dans les coulisses pour s'assurer que la communauté open source puisse utiliser ces technologies pour entraîner ses modèles. Si vous avez déjà utilisé Transformers pour charger un modèle de 4 bits à l'aide d'un seul argument de fonction, vous devez les remercier (et même si ce n'est pas le cas, vous avez certainement utilisé le travail de personnes qui ont construit leur modèle à l'aide de cet écosystème).
Cependant, Answer.AI a remarqué que QLoRA n'a pas tout à fait résolu le problème qu'ils s'étaient fixés, à savoir entraîner un modèle de 70b sur des cartes de 24GB, mais il s'en est rapproché plus que jamais. Lorsqu'il est quantifié à 4 bits (soit 0,5 octet), le modèle 70b prend 70/2 = 35 Go, ce qui est plus grand que les GPU de jeu de 24 Go qu'ils voulaient utiliser.
QLoRA présente d'autres limites. Une carte de 48 Go est très chère, et l'entraînement d'un modèle de 65b tient tout juste sur une telle carte. Cela peut être un problème, car on doit stocker beaucoup d'autres choses, notamment les activations, les gradients et l'état d'optimisation du modèle pendant l'apprentissage. S'il ne reste pas beaucoup de mémoire après avoir chargé les poids du modèle, il n'y a pas assez de mémoire de travail pour soutenir la formation.
Par exemple, l'un des avantages des modèles de langage est qu'ils peuvent être utilisés pour "discuter", comprendre ou analyser de longs documents ou conversations. Pour créer des modèles capables de gérer de longues séquences, on doit leur montrer des exemples de longues séquences pendant la formation. La séquence la plus longue utilisée lors de la formation est appelée "longueur de la séquence". Essayer d'utiliser une longueur de séquence autre que courte provoquera une erreur lors de l'apprentissage d'un modèle QLoRA de 65b sur une carte de 48 Go, car il n'y a pas assez de mémoire pour stocker toutes les informations relatives à la séquence ; la quasi-totalité de la mémoire est utilisée uniquement pour stocker le modèle lui-même.
Answer.AI :
Si le modèle ne peut examiner qu'une seule séquence à la fois, il lui faudra beaucoup de temps pour traiter toutes les données de notre ensemble d'apprentissage. Nous voulons donc pouvoir "grouper" quelques séquences à la fois. Le nombre de séquences incluses est la "taille du lot". Lorsqu'il reste très peu d'espace sur la GPU après avoir chargé les poids du modèle, nous ne pouvons utiliser que des lots de très petite taille, ce qui entraîne une formation extrêmement lente.
Si le modèle ne peut examiner qu'une seule séquence à la fois, il lui faudra beaucoup de temps pour traiter toutes les données de notre ensemble d'apprentissage. Nous voulons donc pouvoir "grouper" quelques séquences à la fois. Le nombre de séquences incluses est la "taille du lot". Lorsqu'il reste très peu d'espace sur la GPU après avoir chargé les poids du modèle, nous ne pouvons utiliser que des lots de très petite taille, ce qui entraîne une formation extrêmement lente.
Une solution évidente au problème des limitations de mémoire vive d'une seule GPU grand public consiste à utiliser plusieurs GPU ! Une approche très courante dans la communauté open source consiste à placer quelques couches du modèle sur chaque carte. Ainsi, pour l'entraînement, vous exécutez les premières couches sur la première GPU, puis les suivantes sur la deuxième GPU, et ainsi de suite. Par exemple, un modèle de 70b (140Go) peut être réparti sur 8 GPU de 24GB, en utilisant 17,5GB sur chacun d'eux. Il existe même un paramètre pratique dans Hugging Face Transformers, device_map='auto', que vous avez peut-être déjà utilisé ; c'est ce que cela fait en fait dans les coulisses. Cela fait l'affaire, mais il y a un gros inconvénient : une seule GPU est active à la fois, car tous les autres attendent leur "tour". Cela signifie que 7/8 du calcul est gaspillé.
Les données parallèles distribuées (DDP) constituaient auparavant l'approche de référence pour l'entraînement efficace des modèles sur plusieurs GPU. Si vous avez un petit modèle (par exemple un modèle 2b, qui nécessite 4 Go de RAM), vous pouvez simplement charger l'ensemble sur chaque GPU séparément et faire en sorte que chaque GPU traite les exemples d'entraînement en parallèle. Par exemple, si vous disposez de 4 GPU, la vitesse d'apprentissage est multipliée par 4. Mais le DDP ne fonctionne pas si le modèle ne tient pas sur une GPU, avec suffisamment de place pour les données nécessaires au processus d'apprentissage.
Answer.AI :
Nous avons donc besoin de quelque chose qui puisse diviser un modèle entre les GPU (comme device_map='auto') et les utiliser en parallèle (comme DPP). C'est là que la bibliothèque Fully Sharded Data Parallel (FSDP) de Meta entre en jeu. Elle "divise" un grand modèle en répartissant ses paramètres sur plusieurs GPU, ce qui permet d'utiliser toutes les GPU simultanément. Lorsqu'une couche du réseau neuronal est calculée sur une GPU particulière pendant l'entraînement, tous les shards nécessaires y sont copiés. Le calcul est ensuite effectué et les parties copiées sont supprimées de cette GPU. Bien que cela semble terriblement inefficace, en réalité, en copiant intelligemment les données de la couche suivante au moment où la couche actuelle est occupée à calculer, il est possible que cette approche n'entraîne aucun ralentissement par rapport à la méthode DDP.
La capacité de FSDP à apporter les performances de DDP à des modèles plus grands que n'importe quelle GPU a été une révélation. Par exemple, un modèle non quantifié de 70b (70 milliards de paramètres) nécessite 140 Go de RAM (parce que chaque paramètre est stocké en 16 bits, soit 2 octets), mais même la carte H100 de NVIDIA (qui coûte environ 40 000 $ pour une seule carte !) ne suffit pas, avec ses 80 Go de RAM. Mais avec le FSDP, quatre GPU H100 peuvent être combinés pour un total de 320 Go de RAM. (Attention, une telle machine coûte environ 150 000 dollars...).
Nous avons donc besoin de quelque chose qui puisse diviser un modèle entre les GPU (comme device_map='auto') et les utiliser en parallèle (comme DPP). C'est là que la bibliothèque Fully Sharded Data Parallel (FSDP) de Meta entre en jeu. Elle "divise" un grand modèle en répartissant ses paramètres sur plusieurs GPU, ce qui permet d'utiliser toutes les GPU simultanément. Lorsqu'une couche du réseau neuronal est calculée sur une GPU particulière pendant l'entraînement, tous les shards nécessaires y sont copiés. Le calcul est ensuite effectué et les parties copiées sont supprimées de cette GPU. Bien que cela semble terriblement inefficace, en réalité, en copiant intelligemment les données de la couche suivante au moment où la couche actuelle est occupée à calculer, il est possible que cette approche n'entraîne aucun ralentissement par rapport à la méthode DDP.
La capacité de FSDP à apporter les performances de DDP à des modèles plus grands que n'importe quelle GPU a été une révélation. Par exemple, un modèle non quantifié de 70b (70 milliards de paramètres) nécessite 140 Go de RAM (parce que chaque paramètre est stocké en 16 bits, soit 2 octets), mais même la carte H100 de NVIDIA (qui coûte environ 40 000 $ pour une seule carte !) ne suffit pas, avec ses 80 Go de RAM. Mais avec le FSDP, quatre GPU H100 peuvent être combinés pour un total de 320 Go de RAM. (Attention, une telle machine coûte environ 150 000 dollars...).
Réunir FSDP et QLoRA
Answer.AI :
Chez Answer.AI, notre étoile polaire est de rendre l'IA utile plus accessible. 150 000 $ pour créer votre propre modèle personnalisé de haute qualité n'est certainement pas considéré comme accessible ! Le premier projet dans lequel nous nous sommes lancés était donc de rendre possible l'utilisation d'un ordinateur de bureau avec des GPU de jeu grand public pour entraîner efficacement un modèle 70b. Nous avons pensé que si nous pouvions utiliser QLoRA pour réduire la taille d'un modèle d'environ 400 % (de sorte qu'un modèle de 70b tiendrait dans 35 Go de RAM), et que nous utilisions ensuite FSDP pour répartir ce modèle sur deux cartes grand public de 24 Go ou plus, il resterait suffisamment de RAM pour entraîner un modèle.
Chez Answer.AI, notre étoile polaire est de rendre l'IA utile plus accessible. 150 000 $ pour créer votre propre modèle personnalisé de haute qualité n'est certainement pas considéré comme accessible ! Le premier projet dans lequel nous nous sommes lancés était donc de rendre possible l'utilisation d'un ordinateur de bureau avec des GPU de jeu grand public pour entraîner efficacement un modèle 70b. Nous avons pensé que si nous pouvions utiliser QLoRA pour réduire la taille d'un modèle d'environ 400 % (de sorte qu'un modèle de 70b tiendrait dans 35 Go de RAM), et que nous utilisions ensuite FSDP pour répartir ce modèle sur deux cartes grand public de 24 Go ou plus, il resterait suffisamment de RAM pour entraîner un modèle.
Fin 2023, Jeremy et Tim ont discuté de l'idée de réunir FSDP et QLoRA. Tim a mis Jeremy en contact avec Titus von Koeller, et Jeremy et Titus ont travaillé ensemble pour essayer d'explorer, de comprendre et de documenter les problèmes survenus lorsque les deux bibliothèques ont été combinées.
Johno Whitaker d'Answer.AI a réalisé une première étape importante : un simple script de test autonome qui a permis de mieux comprendre le problème et de tester des solutions. Une avancée majeure a eu lieu au début de l'année 2024 lorsque Benjamin Warner et Titus d'Answer.AI ont eu une idée clé : stocker les paramètres quantifiés dans un type de données sélectionnable, où ce type de données de stockage est le même type de données que le "type de calcul" du modèle.
Benjamin a réalisé ce prototype dans les 24 heures qui ont suivi le développement de l'idée, mais ils ont alors découvert un autre problème : FSDP ne copiait pas les informations de quantification nécessaires à l'utilisation du modèle par chacun des tessons ! Cela s'explique par le fait que le FSDP a une opinion bien arrêtée sur le sous-ensemble de données qu'il synchronisera entre les GPU. Ils ont réalisé que s'ils quantifaient le modèle sur chaque GPU, les métadonnées manquantes resteraient intactes sur toutes les GPU. En outre, ils ont dû déplacer l'"état de quantification" (les informations nécessaires pour (dé)quantifier les paramètres) des paramètres vers les couches, afin de s'assurer qu'ils ne seraient pas supprimés lorsque FSDP déplacerait les shards.
Une fois ces problèmes résolus, ils ont avons pu entraîner avec succès le premier lot de données avec un modèle quantifié en utilisant FSDP ! Benjamin et Kerem Tugutlu d'Answer.AI ont été en mesure d'emballer ceci avec tous les tests et le refactoring nécessaires dans une pull request pour bitsandbytes. Les mainteneurs du projet bitsandbytes ont été très réactifs dans la gestion du PR à travers leurs processus.
Mission accomplie, ou presque
Answer.AI :
À ce stade, nous pensions une fois de plus que les choses seraient réglées assez rapidement et, une fois de plus, nous avions sous-estimé la complexité de la tâche ! La première chose dont nous nous sommes rendu compte, c'est qu'il n'était toujours pas possible de charger un modèle quantifié plus grand qu'une seule GPU, puisque le processus de chargement et de quantification lui-même exigeait que le modèle entier soit placé sur une seule GPU.
À ce stade, nous pensions une fois de plus que les choses seraient réglées assez rapidement et, une fois de plus, nous avions sous-estimé la complexité de la tâche ! La première chose dont nous nous sommes rendu compte, c'est qu'il n'était toujours pas possible de charger un modèle quantifié plus grand qu'une seule GPU, puisque le processus de chargement et de quantification lui-même exigeait que le modèle entier soit placé sur une seule GPU.
Benjamin a réalisé qu'avec quelques ajustements, il serait possible d'effectuer le chargement et la discrétisation une couche à la fois, évitant ainsi d'avoir tout le modèle sur une seule GPU. Il a également trouvé comment empêcher la bibliothèque PEFT de déplacer l'état de quantification vers la CPU. Kerem a écrit une implémentation personnalisée de l'algorithme LoRA afin qu'il puisse fonctionner avec les changements apportés par Benjamin.
Answer.AI :
Grâce à cela, nous avons pu affiner un modèle 70b sur deux GPU de jeu 3090 pour la première fois ! Pour ce faire, nous avons bénéficié non seulement de FSDP et de QLoRA, mais aussi d'une vaste gamme de techniques intelligentes développées au cours des deux dernières années par les communautés académiques et open source. Nous avons utilisé :
Grâce à cela, nous avons pu affiner un modèle 70b sur deux GPU de jeu 3090 pour la première fois ! Pour ce faire, nous avons bénéficié non seulement de FSDP et de QLoRA, mais aussi d'une vaste gamme de techniques intelligentes développées au cours des deux dernières années par les communautés académiques et open source. Nous avons utilisé :
- le contrôle du gradient (également connu sous le nom de contrôle de l'activation) pour éviter de stocker des gradients complets, en enregistrant plutôt les activations à un certain nombre de "points de contrôle" tout au long du modèle, puis en recalculant les gradients en réexécutant l'étape de calcul en avant, si nécessaire.
- le délestage de la CPU pour stocker les poids dans la mémoire vive de la CPU plutôt que sur la GPU lorsqu'ils ne sont pas utilisés, ce qui réduit considérablement la mémoire requise par la GPU. Cette technique n'est pas très utile pour les "riches en GPU" utilisant des GPU H100, qui disposent de moyens très optimisés pour se transmettre les poids. Mais pour notre cas d'utilisation, elle est absolument nécessaire, puisque les GPU de jeu et les cartes mères ne disposent pas de ces systèmes.
- Flash Attention 2 pour calculer efficacement l'attention en utilisant un noyau Cuda à mémoire optimisée.
Après tout ce travail, ils ont constaté qu'ils pouvaient entraîner de grands modèles avec des GPU grand public. Jeremy avait réalisé une analyse comparative détaillée des recettes originales de llama sur une gamme de matériel GPU, et Kerem a développé un système d'analyse comparative complet pour le nouveau projet. En comparant les deux, ils ont réalisé qu'ils n'étaient toujours pas en mesure d'utiliser les longueurs de séquence ou les tailles de lot espérés - pour une raison quelconque, plus de mémoire était utilisée que prévu.
En y regardant de plus près, il s'est avéré que ce n'était pas du tout dû à l'intégration FSDP/QLoRA - mais en fait, lorsque ils ont augmenté seqlen en bitsandbytes, même sans FSDP, l'utilisation de la mémoire a augmenté de façon super-linéaire, aboutissant finalement à une utilisation de la mémoire encore plus élevée que sans quantification ! Il s'avère qu'ils n'ont pas été les premiers à avoir découvert ce problème. Ils n'ont pas encore de solution bitsandbytes (mais elle est à l'étude), mais cela a conduits à une découverte passionnante...
Découvrir HQQ
Answer.AI :
Nous aimons collaborer avec des gens qui ont les mêmes idées que nous, alors quand nous avons vu le travail extraordinaire fait par Daniel Han sur Unsloth, nous avons voulu en savoir plus et voir si nous pouvions nous aider mutuellement. Nous avons demandé à Daniel s'il y avait d'autres projets intéressants dans ce domaine que nous devrions suivre, et il nous a indiqué HQQ.
Nous aimons collaborer avec des gens qui ont les mêmes idées que nous, alors quand nous avons vu le travail extraordinaire fait par Daniel Han sur Unsloth, nous avons voulu en savoir plus et voir si nous pouvions nous aider mutuellement. Nous avons demandé à Daniel s'il y avait d'autres projets intéressants dans ce domaine que nous devrions suivre, et il nous a indiqué HQQ.
D'autres approches, telles que GPTQ et AWQ, plus récente, vont dans une direction différente, où les paramètres de quantification sont optimisés sur la base du comportement réel du modèle lorsque des données représentatives lui sont transmises. Ces méthodes tendent à produire des modèles plus précis, potentiellement avec moins de 4 bits par paramètre, mais elles présentent l'inconvénient que le processus d'optimisation peut prendre des heures, voire des jours, pour chaque modèle.
HQQ combine le meilleur des deux mondes. Il est 50 fois plus rapide que GPTQ pour traiter un modèle de 70b, tout en étant plus précis. Kerem a décidé de vérifier si HQQ fonctionnerait bien avec FSDP.
Il a découvert que pour faire fonctionner HQQ et FSDP ensemble, il fallait suivre exactement les mêmes étapes que pour bitsandbytes, ce qui lui a permis de réaliser un exemple de travail complet en quelques jours. Les gens de mobius.ml n'auraient pas pu être plus réactifs et utiles pour s'assurer que le PR a été fusionné avec succès : FSDP fonctionne aussi avec HQQ !
Comment utiliser FSDP/QLoRA par Answer.AI
Pour utiliser le FSDP, vous aurez bien sûr besoin de plus d'une GPU. Si vous n'avez pas accès à un tel système, vous pouvez louer une double boîte 3090 à partir du Runpod Community Cloud pour environ 0,60 $/heure. Il existe de nombreux autres fournisseurs ; cloud-gpus est un excellent endroit pour voir ce qui est proposé.
Vous aurez besoin d'installer la dernière version de Transformers, PEFT, et bitsandbytes (et HQQ si vous l'utilisez). Ensuite, clonez notre repo et suivez le README qui s'y trouve. L'exécution de python train.py --help affichera les options disponibles. Pour entraîner llama2-7b sur le jeu de données alpaca inclus sur deux cartes de 24 Go, vous pouvez exécuter :
Nous avons regroupé tout ce qui est nécessaire dans ce seul fichier pour qu'il soit plus facile de voir ce qui se passe et de modifier les choses si nécessaire.
Vous devez considérer ce script comme une version alpha/preview. Bien que nous l'ayons utilisé pour entraîner avec succès une variété de modèles utiles en pratique sur une gamme de matériel, il en est encore à ses débuts. Si vous n'êtes pas à l'aise avec les tests et le débogage de modèles, nous vous suggérons de vous abstenir pendant quelques mois, le temps que la communauté teste l'approche de manière plus approfondie.
Vous aurez besoin d'installer la dernière version de Transformers, PEFT, et bitsandbytes (et HQQ si vous l'utilisez). Ensuite, clonez notre repo et suivez le README qui s'y trouve. L'exécution de python train.py --help affichera les options disponibles. Pour entraîner llama2-7b sur le jeu de données alpaca inclus sur deux cartes de 24 Go, vous pouvez exécuter :
| Code : | Sélectionner tout |
python train.py --train_type qlora --dataset alpaca --batch_size 8 --gradient_accumulation_steps 2 --output_dir qlora_output --log_to wandb
Vous devez considérer ce script comme une version alpha/preview. Bien que nous l'ayons utilisé pour entraîner avec succès une variété de modèles utiles en pratique sur une gamme de matériel, il en est encore à ses débuts. Si vous n'êtes pas à l'aise avec les tests et le débogage de modèles, nous vous suggérons de vous abstenir pendant quelques mois, le temps que la communauté teste l'approche de manière plus approfondie.
Une première étape
À l'origine, Answer.AI avait prévu de présenter quelques points de référence dans un article, ainsi que des conseils basés sur les résultats des points de référence sur la façon de tirer le meilleur parti de FSDP/QLoRA. Cependant, ils ont dû retarder la publication d'un tel article, car ils continuaient à apporter des améliorations majeures tous les jours ! Ils publieront donc un article sur l'analyse comparative et les recommandations dans les semaines à venir.
Ce qui a été montré ici n'est qu'une première étape. Answer.AI a encore beaucoup d'idées d'amélioration, et pense que la communauté open source aura beaucoup d'autres idées aussi !
Answer.AI :
Nous espérons que cette preuve de concept, qui montre qu'il est possible de mettre à l'échelle une formation QLoRA efficace en termes de ressources sur des GPU de jeu peu coûteuses, contribuera à attirer l'attention sur le problème de la réduction du coût de la formation aux modèles. Il est dans l'intérêt de tous de rendre l'IA plus accessible et de permettre à un plus grand nombre de personnes non seulement de consommer, mais aussi de construire des modèles de valeur.
Nous espérons que cette preuve de concept, qui montre qu'il est possible de mettre à l'échelle une formation QLoRA efficace en termes de ressources sur des GPU de jeu peu coûteuses, contribuera à attirer l'attention sur le problème de la réduction du coût de la formation aux modèles. Il est dans l'intérêt de tous de rendre l'IA plus accessible et de permettre à un plus grand nombre de personnes non seulement de consommer, mais aussi de construire des modèles de valeur.
Et vous ?
Pensez-vous que ce système est crédible ou pertinent ? Quel est votre avis sur le sujet ?Voir aussi :
La puce d'IA Nvidia H100 à 40 000 dollars est devenue le matériel informatique le plus convoité au monde et rapproche Nvidia des 1 000 milliards de dollars de capitalisation boursière Une solution open source reproduirait le processus de formation de ChatGPT, avec seulement 1,6 Go de mémoire GPU, selon Colossal-AI La "distillation pas-à-pas", un nouveau paradigme d'apprentissage pour surpasser les performances des grands LLM avec moins de données d'entraînement et des modèles d'IA de plus petite taille