[Traitement Naturel du Langage] [Grand Modèle] BLOOM : Un modèle multilingue avec 176B de paramètres et en libre accès

BLOOM : Un paramètre 176B et un modèle multilingue en libre accès 《BLOOM : un modèle de langage multilingue à accès ouvert à 176 B paramètres》

Adresse papier : https://arxiv.org/pdf/2211.05100.pdf

Blog connexe
[Traitement du langage naturel] [Grand modèle] Analyse du code source de la structure du modèle BLOOM (version autonome)
[Traitement du langage naturel] [Grand modèle] Méthode de réglage fin du grand modèle à très faibles ressources LoRA et code d'implémentation BLOOM-LORA
[Naturel Traitement du langage] [Grand modèle] Gopher grand modèle de DeepMind
[Traitement du langage naturel] [Grand modèle] Chinchilla : un grand modèle de langage avec une formation et une utilisation informatique optimales
[Traitement du langage naturel] [Grand modèle] Grand modèle de langage Test de l'outil de raisonnement BLOOM
[Naturel Traitement du langage] [ Grand modèle] GLM-130B : un modèle de langage open source bilingue pré-entraîné
[Traitement du langage naturel] [Grand modèle] Introduction à la multiplication matricielle 8 bits pour les grands transformateurs
[Traitement du langage naturel] [Grand modèle] BLOOM : un paramètre 176B et peut Modèle multilingue en libre accès
[Traitement du langage naturel] [Grand modèle] PaLM : Un grand modèle de langage basé sur Pathways
[Traitement du langage naturel] [série chatGPT] Les grands modèles de langage peuvent s'améliorer eux-mêmes
[Traitement du langage naturel] [ChatGPT série] WebGPT : basé sur des questions et réponses assistées par un navigateur avec des commentaires humains
[Traitement du langage naturel] [Série ChatGPT] FLAN : Le réglage fin du modèle de langage est un apprenant Zero-Shot
[Traitement du langage naturel] [Série ChatGPT] D'où vient l'intelligence de ChatGPT vient-il ?
[Traitement du langage naturel] [Série ChatGPT] Émergence des grands modèles

1. Introduction

Les modèles linguistiques pré-entraînés sont devenus la pierre angulaire des pipelines modernes de traitement du langage naturel, car ils produisent de meilleurs résultats sur de petites quantités de données étiquetées. Avec le développement d'ELMo, ULMFiT, GPT et BERT, le paradigme de réglage fin des tâches en aval à l'aide de modèles pré-entraînés est largement utilisé. L’utilité du modèle linguistique pré-entraîné s’est par la suite avérée pour effectuer des tâches utiles sans aucune formation supplémentaire. En outre, l’observation empirique selon laquelle les performances des modèles linguistiques augmentent (parfois de manière prévisible, parfois brusquement) avec des modèles plus grands conduit également à une tendance vers des tailles de modèles de plus en plus grandes. Quel que soit l’environnement, le coût de formation d’un grand modèle linguistique (LLM) ne peut être supporté que par les organisations riches en ressources. De plus, jusqu’à la fin, la plupart des LLM n’ont pas été rendus publics. Par conséquent, la majeure partie de la communauté des chercheurs a été exclue du développement des LLM. Cela a des conséquences concrètes en cas de non-publication : par exemple, la plupart des LLM sont principalement formés sur des textes anglais.

Pour résoudre ces problèmes, nous proposons BigScience Large Open-science Open-access Multilingual Language Model (BLOOM). BLOOM est un modèle de langage de 176 milliards de paramètres formé sur 46 langages naturels et 13 langages de programmation, développé et publié par des centaines de chercheurs. La puissance de calcul utilisée pour entraîner BLOOM provient des subventions publiques françaises GENCI et IDRIS, en utilisant le supercalculateur Jean Zay de l'IDRIS. Pour construire BLOOM, chaque composant est conçu en détail, y compris les données de formation, l'architecture du modèle et les objectifs de formation, ainsi que les stratégies d'ingénierie pour l'apprentissage distribué. Nous avons également effectué une analyse de la capacité du modèle. Notre objectif global n'est pas seulement de publier publiquement un modèle linguistique multilingue à grande échelle comparable aux systèmes récemment développés, mais également de documenter le processus de coordination de son développement.

2. FLEUR

1. Données de formation

BLOOM est formé sur un corpus appelé ROOTS, qui est un corpus composé de 498 ensembles de données Hugging Face. Un total de 1,61 To de texte, dont 46 langages naturels et 13 langages de programmation. La figure 3 ci-dessus montre un aperçu de haut niveau de l'ensemble de données, tandis que le tableau 1 ci-dessus détaille chaque langue et son genre, sa famille linguistique et sa macrorégion. Outre la production du corpus, la démarche a également abouti au développement et à la diffusion de nombreux outils organisationnels et techniques.

1.1 Gestion des données

Les grands corpus de textes sont créés par et à propos de personnes. Différentes personnes ou institutions peuvent « légalement » posséder les données, ce que l'on appelle la propriété des données. À mesure que les développeurs de machine learning collectent et organisent ces données dans des ensembles de données de plus en plus vastes, il est de plus en plus important de prendre en compte les parties prenantes impliquées dans le développement des données, notamment : les développeurs, les personnes concernées et les titulaires de droits.

​ BigScience vise à résoudre ces problèmes en combinant des connaissances multidisciplinaires telles que la technologie, le droit et la sociologie. L'organisation se concentre sur deux objectifs principaux sur deux échelles de temps différentes : concevoir une structure internationale de gouvernance des données à long terme qui donne la priorité aux détenteurs de droits sur les données et fournir des recommandations spécifiques pour les données directement utilisées par les projets BigScience. Les progrès vers le premier objectif Jernite et al.sont montrés dans le travail, qui motive davantage la nécessité d'une gouvernance des données et décrit un réseau de dépositaires de données, de titulaires de droits et d'autres acteurs. Les interactions de ces acteurs sont conçues pour prendre en compte la confidentialité des données et des algorithmes, la propriété intellectuelle et les droits des utilisateurs. Cette approche repose notamment sur un accord structuré entre le fournisseur de données et l’hébergeur de données précisant la finalité des données.

​ Bien qu'il ait été impossible d'établir une organisation internationale complète dans le laps de temps relativement court entre le début du projet et la formation du modèle, nous avons également travaillé dur pour tirer les leçons de ce processus : (1) BigScience tentera de obtenir une utilisation claire des données auprès des fournisseurs de données sous licence ; (2) maintenir l'indépendance d'une source unique et maintenir la traçabilité jusqu'à l'étape finale du prétraitement. (3) Adopter une méthode de publication combinée pour chaque source de données qui constitue l'ensemble du corpus, favorisant ainsi la réutilisabilité et les recherches ultérieures. La ressource du corpus ROOTS est accessible et visualisable dans l'organisation « BigScience Data » de Hugging Face.

1.2 Sources de données

Après avoir déterminé la stratégie de gestion des données, l’étape suivante consiste à déterminer la composition du langage de formation. Cette phase est motivée par plusieurs objectifs, intrinsèquement conflictuels. Ces conflits de mémoire incluent : la construction d'un modèle de langage accessible au plus grand nombre dans le monde, tout en exigeant également une connaissance suffisante du langage pour gérer des ensembles de données de taille comparable aux précédents pour améliorer la documentation standard, et le suivi du corps de les données et les algorithmes sont corrects.

• choix de langue

  Sur la base de ces considérations, nous adoptons une approche incrémentale pour sélectionner les langues incluses dans le corpus. Commencez par répertorier les 8 langues les plus parlées au monde, en promouvant activement ces langues dès le début du projet et en invitant les locuteurs parlant couramment cette langue à rejoindre le projet. Ensuite, le swahili dans la sélection originale a été étendu à la catégorie des langues Niger-Congo, et l'hindi et l'ourdou ont été étendus aux langues indiennes, comme suggéré par la communauté. En fin de compte, nous proposons que si une langue compte plus de 3 locuteurs courant, elle puisse être ajoutée à la liste de support.

• sélection des sources

  La plus grande partie du corpus a été organisée par les participants à l'atelier et les équipes de recherche, qui ont rédigé conjointement le « BigScience Catalog » : une liste couvrant divers langages traités et non traités. Cela prend la forme de hackathons organisés par des communautés telles que Machine Learning Tokyo, Masakhane et LatinX in AI. En plus de ces sources, d'autres participants au groupe de travail ont compilé des ressources spécifiques à certaines langues, telles que le référentiel Masader axé sur l'arabe. Cette approche ascendante a identifié un total de 252 sources, avec au moins 21 sources par langue. De plus, pour augmenter la couverture géographique des ressources en espagnol, chinois, français et anglais, les participants ont identifié des URL localement pertinentes pour les langues ajoutées au corpus via pseudocrawl.

• Code GitHub

  Les ensembles de données de langage de programmation de ce répertoire sont complétés par les ensembles de données GitHub sur BigQuer de Google, puis dédupliqués à l'aide d'une correspondance exacte.

• OSCAR

  Afin de ne pas s'écarter de la recherche standard utilisant des pages Web comme source de données de pré-formation et de répondre aux exigences de volume de données des coûts de calcul de la taille de BLOOM, nous utilisons en outre OSCAR version 21.09 comme source de données, correspondant à l'instantané Common Crawl. en février 2021, qui occupe 38% du corpus final.

1.3 Prétraitement des données

Après avoir identifié la source de données, le traitement des données implique plusieurs étapes de gestion des données. Dans la figure 2 ci-dessus, vous pouvez voir la vue globale du pipeline pour la construction de ROOTS. Tous les outils développés au cours de ce processus sont disponibles sur GitHub.

• obtenir les données sources

  La première étape consistait à obtenir des données textuelles à partir de sources de données identifiées, ce qui comprenait le téléchargement et l'extraction de champs de texte à partir d'ensembles de données PNL dans divers formats, la récupération et le traitement d'un grand nombre de fichiers PDF à partir d'archives, 192 sites Web à partir d'un catalogue. Le texte a été extrait et prétraité à partir d'un 456 sites supplémentaires géographiquement divers sélectionnés par les membres du groupe de travail sur les éléments et les données. Cette dernière a nécessité le développement de nouveaux outils pour extraire le texte du HTML dans les fichiers Common Crawl WARC. Nous avons pu localiser et extraire des données utilisables de toutes les URL de 539 réseaux.

• filtre de qualité

  Après avoir obtenu le texte, nous avons constaté que la plupart des sources contenaient une grande quantité de langage non naturel, tel que des erreurs de prétraitement, des pages de référencement ou des déchets. Pour filtrer le langage non naturel, nous définissons un ensemble de mesures de qualité, où un texte de haute qualité est défini comme « écrit par des humains pour des humains », sans distinguer de jugements a priori sur le contenu ou la grammaire. Il est important de noter que ces mesures sont adaptées aux besoins de chaque source de deux manières principales. Premièrement, leurs paramètres, tels que les seuils et les listes d'éléments pris en charge, sont choisis individuellement par les locuteurs maîtrisant chaque langue. Deuxièmement, nous examinons d’abord chaque source individuelle pour déterminer quelles mesures sont les plus susceptibles d’identifier un langage non naturel. Les deux processus sont soutenus par des outils permettant de visualiser l’impact.

• Déduplication et confidentialité

  En fin de compte, nous avons utilisé deux étapes d'itération pour supprimer les documents quasi-dupliqués et expurgé les informations personnellement identifiables identifiées dans le corpus OSCAR. Parce qu'elle est considérée comme la source du risque le plus élevé pour la vie privée, cela nous motive à utiliser l'édition basée sur les expressions régulières, même si les expressions ont quelques problèmes avec les faux positifs.

1.4 Ensemble de données invité

Le réglage fin des invites multitâches (également appelé réglage des instructions) implique le réglage fin d'un modèle de langage pré-entraîné sur un ensemble de données affiné composé d'un grand nombre de tâches différentes via des invites en langage naturel. T0 démontre la forte généralisation sans tir de modèles affinés sur des ensembles de données multitâches mixtes. De plus, T0 surpasse les modèles de langage qui sont d'un ordre de grandeur plus grand sans un tel réglage. Inspirés par ces résultats, nous explorons l’utilisation d’ensembles de données en langage naturel existants pour un réglage fin multi-tâches.

T0 est formé sur le sous-ensemble Public Pool of Prompt (P3), qui est une collection d'invites pour divers ensembles de données en langage naturel appliqué open source existants. Cette collection d'invites a été créée grâce à une série de hackathons auxquels les collaborateurs de BigScience ont participé, au cours desquels les participants au hackathon ont écrit plus de 2 000 invites pour plus de 170 ensembles de données. Les ensembles de données de P3 couvrent diverses tâches en langage naturel, notamment l'analyse des sentiments, la réponse aux questions, le raisonnement en langage naturel, et excluent les contenus préjudiciables ou le langage non naturel. PromptSource, une boîte à outils open source qui facilite la création, le partage et la consommation d'invites en langage naturel.

Après la pré-formation de BLOOM, nous appliquons le même réglage multitâche à grande échelle pour que BLOOM se généralise aux tâches multilingues sans tir. Nous appelons le modèle résultant BLOOMZ. Pour former BLOOMZ, nous étendons P3 pour inclure de nouveaux ensembles de données et de nouvelles tâches dans des langues autres que l'anglais, comme la traduction. Cela a donné xP3, une collection renforcée de 83 ensembles de données couvrant 46 langues et 16 tâches. Comme mentionné dans la figure 4 ci-dessus, xP3 reflète la distribution linguistique de ROOTS. Les tâches dans XP3 incluent à la fois multilingues et monolingues. Nous utilisons PromptSource pour collecter ces invites, en ajoutant des métadonnées supplémentaires aux invites, telles que la langue de saisie et la langue cible. Pour étudier l'importance des invites multilingues, nous traduisons également automatiquement les invites anglaises de xP3 dans la langue de l'ensemble de données correspondante pour générer une collection appelée xP3mt.

2. Architecture du modèle

2.1 Méthode de conception

​ Le choix de conception architecturale est très vaste et il est impossible de l’explorer pleinement. Une option consiste à reproduire complètement l’architecture d’un grand modèle existant. D’un autre côté, de nombreux travaux visant à améliorer les architectures existantes ont rarement été adoptés, et l’adoption de certaines pratiques recommandées peut conduire à un meilleur modèle. Nous adoptons une position intermédiaire, en choisissant des familles de modèles qui se sont avérées bien évolutives et qui sont raisonnablement prises en charge dans les outils et les bases de code accessibles au public. Nous avons effectué des expériences d'ablation sur les composants et les hyperparamètres du modèle, cherchant à maximiser notre budget de calcul final.

• Conception expérimentale d'ablation

  Le principal attrait des LLM réside dans leur capacité à effectuer des tâches de manière « zéro/quelques coups » : des modèles suffisamment grands peuvent simplement effectuer de nouvelles tâches à partir d'instructions et d'exemples contextuels, sans formation sur des échantillons supervisés. Étant donné que le réglage fin d'un modèle 100B+ est fastidieux, nous évaluons les décisions architecturales en nous concentrant sur les capacités de généralisation sans tir et ne prenons pas en compte l'apprentissage par transfert. Plus précisément, nous mesurons les performances zéro de différents ensembles de tâches : 29 tâches du harnais d'évaluation du modèle de langage EleutherAI (EAI-Eval) et 9 tâches de l'ensemble de validation de T0 (T0-Eval). Il existe un grand chevauchement entre les deux : une seule tâche dans T0-Eval n'est pas dans EAI-Eval, bien que toutes les invites des deux soient différentes.

  De plus, des expériences d’ablation sont également réalisées à l’aide de modèles plus petits. Utilisez le modèle 6.7B pour mener des expériences d'ablation sur des cibles pré-entraînées et utilisez le modèle 1.3B pour mener des expériences d'ablation sur l'intégration de position, les fonctions d'activation et la normalisation des couches. Récemment, Dettmers a découvert une transition de phase dans un modèle supérieur à 6,7B et a observé l'apparition de « caractéristiques anormales ». Alors, est-il possible d'extrapoler à partir de la taille finale du modèle à l'échelle 1,3B ?

• Schéma hors de portée

  Nous n'avons pas pris en compte le mélange d'experts (MoE) en raison du manque de bases de code basées sur GPU largement utilisées et adaptées à la formation à grande échelle. De même, nous ne considérons pas les modèles d’espace d’états. Lorsque BLOOM a été conçu, leurs performances sur les tâches en langage naturel étaient médiocres. Les deux approches sont prometteuses et démontrent désormais des résultats compétitifs sur le MoE à grande échelle et à plus petite échelle en utilisant des modèles espace-états avec H3.

2.2 Architecture et objectifs de pré-formation

Bien que la plupart des modèles de langage modernes soient basés sur l'architecture Transformer, il existe des différences significatives entre les implémentations architecturales. De toute évidence, le Transformer d'origine est basé sur l'architecture encodeur-décodeur, et de nombreux modèles populaires choisissent uniquement des méthodes d'encodeur uniquement ou de décodeur uniquement. Actuellement, tous les modèles de pointe comportant plus de 100 B de paramètres sont des modèles à décodeur uniquement. Ceci est contraire aux conclusions de Raffel et al., où le modèle codeur-décodeur surpasse considérablement le modèle décodeur uniquement en termes d'apprentissage par transfert.

Avant notre travail, la littérature manquait d'évaluation systématique de la généralisation du tir zéro pour différentes architectures et objectifs de pré-formation. Nous Wang et al.(2022a)explorons cette question dans les travaux de et al., qui explorent les architectures et les interactions de codeur-décodeur et de décodeur uniquement avec des modèles pré-entraînés de modélisation causale, de préfixe et de langage masqué. Nos résultats montrent que le modèle causal uniquement avec décodeur fonctionne mieux après la pré-formation, validant ainsi le choix du LLM de pointe.

2.3 Détails de la modélisation

En plus du choix de l'architecture et de la cible de pré-formation, de nombreuses modifications sont proposées par rapport à l'architecture originale du Transformer. Par exemple, des schémas d'intégration d'emplacements alternatifs ou de nouvelles fonctions d'activation. Nous avons réalisé une série d'expériences pour évaluer chaque modification, sur Le Scao et al.le modèle causal uniquement décodeur. Nous utilisons deux variantes de BLOOM :

• Intégration de position ALiBi

  Par rapport à l'ajout d'informations de localisation dans la couche d'intégration, ALiBi atténue directement le score d'attention en fonction de la distance entre les clés et les requêtes. Alors que la motivation initiale d'ALiBi était sa capacité à extrapoler à des séquences plus longues, nous avons constaté qu'il conduit également à un entraînement plus équilibré et à de meilleures performances en aval sur la longueur de la séquence d'origine, au-delà des intégrations apprenables et pivotées.

• Incorporation de LayerNorm

  Dans un premier essai de formation d'un modèle de paramètres 104B, nous avons essayé la normalisation des couches immédiatement après la couche d'intégration, comme recommandé par la bibliothèque bitsandbytes et sa couche StableEmbedding. Nous avons constaté que cela peut améliorer considérablement la stabilité de l'entraînement. Bien que nous Le Scao et al.ayons constaté dans notre travail qu'il y avait une pénalité pour la généralisation sans tir, nous avons ajouté une couche de normalisation de couche supplémentaire après la première couche d'intégration de BLOOM pour éviter l'instabilité de la formation. Notez que float16 est utilisé dans l'expérience préliminaire 104B et bfloat16 est utilisé dans la formation finale. Car float16 a été identifié comme la cause de nombreuses instabilités observées lors de la formation des LLM. bfloat16 a le potentiel de réduire le besoin d'intégrer LayerNorm.

  L'ensemble de l'architecture de BLOOM est illustré dans la figure 5 ci-dessus.

3. Tokenisation

Les choix de conception des tokenizers sont souvent ignorés au profit du paramètre « par défaut ». Par exemple, OPT et GPT-3 utilisent le tokenizer de GPT-2, formé pour l'anglais. En raison de la nature diversifiée des données de formation de BLOOM, des choix de conception minutieux sont nécessaires pour garantir que le tokenizer encode les phrases sans perte.

3.1 Vérification

Nous comparons le tokenizer (Acs, 2019) utilisé dans cet article avec les tokenizers monolingues existants comme mesure de détection de l'intégrité. La fertilité est définie comme le nombre de sous-mots créés par le tokenizer par mot ou par ensemble de données, que nous mesurons à l'aide des dépendances universelles 2.9 et du sous-ensemble OSCAR de la langue d'intérêt. Avoir une fertilité très élevée sur une langue par rapport à un tokenizer monolingue peut indiquer une dégradation des performances sur plusieurs langues en aval. Notre objectif est de garantir que la capacité de fertilité de chaque langue n'est pas inférieure de plus de 10 points de pourcentage lorsque l'on compare notre tokenizer multilingue avec son homologue linguistique. Dans toutes les expériences, la bibliothèque Hugging Face Tokenizers a été utilisée pour concevoir et former des tokenizers de test.

3.2 Données de formation du tokenizer

Nous utilisons initialement un sous-ensemble non répétitif de ROOTS. Cependant, une étude qualitative sur les vocabulaires des tokenizer a révélé des problèmes avec les données de formation. Par exemple, sur les versions antérieures du tokenizer, nous avons constaté que les URL complètes étaient stockées sous forme de jetons, ce qui était dû à plusieurs documents contenant de nombreuses duplications. Ce problème nous motive à supprimer les lignes en double dans les données de formation du tokenizer.

3.3 Taille du vocabulaire

Un vocabulaire important réduit le risque de sur-segmenter certaines phrases, notamment pour les langues à faibles ressources. Nous effectuons des expériences de validation en utilisant des tailles de vocabulaire de 150 000 et 250 000 pour comparaison avec la littérature de modélisation multilingue existante. Par rapport au tokeniseur monolingue, nous avons finalement déterminé que la taille du vocabulaire était de 250 000 jetons pour atteindre l'objectif initial de fertilité. Étant donné que la taille du vocabulaire détermine la taille de la matrice d'intégration, la taille d'intégration doit être divisible par 128 pour l'efficacité du GPU, et elle doit être divisible par 4 afin d'utiliser le parallélisme tensoriel. Nous avons fini par utiliser une taille de vocabulaire de 250 680, avec 200 jetons réservés pour de futures applications, telles que l'utilisation de jetons d'espace réservé pour éliminer des informations privées.

3.4 BPE au niveau octet

Le tokenizer est un tokenzier de sous-mots apprenable formé à l'aide de l'algorithme Byte Pair Encoding (BPE). Afin de ne pas perdre d'informations pendant le processus de tokenisation, le tokenizer crée des fusions à partir d'octets au lieu de caractères comme plus petite unité. De cette façon, la tokenisation ne peut jamais générer de jetons inconnus, puisque les 256 octets peuvent être inclus dans le vocabulaire du tokenizer. De plus, le BPE au niveau octet maximise le partage de vocabulaire entre les langues.

3.5 Normalisation

​ En amont de l'algorithme BPE, afin d'obtenir le modèle le plus général possible, le texte n'est pas normalisé. L'ajout d'une normalisation Unicode telle que NFKC ne réduit pas la fécondité de plus de 0,8 % dans tous les cas, mais au prix de rendre le modèle moins général. Par exemple, ce qui donne $2^2$ et 22 sont codés de la même manière.

3.6 Pré-tokenizer

Notre pré-tokenisation a deux objectifs : produire la première partition du texte, et limiter la longueur maximale des séquences de jetons produites par l'algorithme BPE. L'échelle de pré-tokenisation utilise l'expression régulière suivante :?[^(\S|[.,!?...。，、|_])]+ , qui sépare les mots tout en préservant tous les caractères, en particulier les séquences d'espaces et de nouvelle ligne qui sont cruciales pour les langages de programmation. Nous n'utilisons pas les partitions centrées sur l'anglais qui sont courantes dans d'autres tokeniseurs. Nous n'utilisions pas non plus la division sur les nombres, ce qui posait des problèmes avec l'arabe et le code.

4. Ingénierie

4.1 Matériel

Le modèle a été formé sur Jean Zay, un supercalculateur financé par le gouvernement français, propriété de GENCI et géré par l'IDRIS, le centre de calcul national du Centre national de la recherche scientifique (CNRS). La formation BLOOM a duré 3,5 mois et a consommé 1 082 990 heures de calcul. La formation a été effectuée sur 48 nœuds, chacun avec 8 GPU NVIDIA A100 de 80 Go (384 GPU au total) ; nous avons également conservé 4 nœuds de rechange en raison d'éventuels dommages matériels pendant la formation. Les nœuds sont équipés de 2 processeurs AMD EPYC 7543 à 32 cœurs et de 512 Go de RAM, tandis que le stockage est un hybride de système de fichiers parallèle SpectrumScale (GPFS) composé de disques 100 % Flash et de disques durs.

4.2 Cadre

BLOOM est formé à l'aide de Megatron-DeepSpeed, un framework pour la formation distribuée à grande échelle. Il se compose de deux parties : Megatron-LM fournit l'implémentation de Transformer, le parallélisme tenseur et les primitives de chargement de données, tandis que DeepSpeed ​​​​fournit l'optimiseur ZeRO, le pipeline de modèles et les composants de formation distribués. Ce cadre nous permet d'utiliser le parallélisme 3D pour une formation efficace : une fusion de trois méthodes complémentaires d'apprentissage profond distribué. Ces méthodes sont décrites ci-dessous :

• Parallélisme des données (Parallélisme des données, DP)

  Répliquez plusieurs copies du modèle, chaque copie est placée sur un appareil différent et saisissez des fragments de données. Ce processus s'effectue en parallèle, toutes les copies du modèle étant synchronisées à la fin de chaque étape de formation.

• Parallélisme tensoriel (TP)

  Divisez les couches indépendantes de votre modèle sur plusieurs appareils. De cette façon, au lieu de mettre l'intégralité du tenseur d'activation ou du tenseur de gradient sur un seul GPU, nous mettons des fragments de ce tenseur sur un seul GPU. Cette technique est parfois appelée parallélisme horizontal ou parallélisme intra-modèle.

• Parallélisme des pipelines (PP)

  Divisez les couches du modèle sur plusieurs GPU, chaque GPU ne plaçant qu'une fraction des couches du modèle. Ceci est aussi parfois appelé parallélisme vertical.

En fin de compte, le Zero Redundancy Optimizer (ZeRO) exécute différents processus ne contenant qu'une partie des données (paramètres, gradients et état de l'optimiseur) et les données nécessaires à une étape de formation. Nous utilisons ZeRO étape 1, ce qui signifie que seul l'état de l'optimiseur est fragmenté de cette façon.

La combinaison des quatre composants décrits ci-dessus peut s'adapter à des centaines de GPU avec une utilisation extrêmement élevée du GPU. Nous avons pu atteindre 156 TFLOP sur la configuration la plus rapide du GPU A100, soit la moitié du pic théorique de 312 TFLOP.

4.3 Format à virgule flottante

Lors d'expériences préliminaires avec un modèle de paramètres 104B sur des GPU NVIDIA V100, nous avons observé une instabilité numérique conduisant à une divergence irréversible de formation. Nous émettons l'hypothèse que ces instabilités proviennent de l'utilisation originale de IEEE float16, un format de nombres à virgule flottante de 16 bits avec une plage dynamique très limitée pouvant conduire à un débordement. Nous avons finalement obtenu l'autorisation de prendre en charge le format bfloat16, qui a la même plage dynamique que float32. En revanche, la précision de bfloat16 est encore bien inférieure, ce qui nous motive à utiliser un entraînement de précision mixte. La technique effectue des opérations sensibles à la précision telles que l'accumulation de gradient et le softmax en précision float32, et utilise une faible précision pour les opérations restantes, ce qui permet un équilibre entre hautes performances et stabilité de l'entraînement. Enfin, nous avons effectué l'entraînement final avec une précision mixte bfloat16, ce qui s'est avéré résoudre le problème de l'instabilité de l'entraînement.

4.4 Fusion des cœurs CUDA

En général, les GPU ne peuvent pas effectuer ces calculs en même temps que la récupération des données. De plus, les performances de calcul des GPU modernes sont bien supérieures à la vitesse de transfert de mémoire requise pour chaque opération (appelée noyau dans la programmation GPU). La fusion du noyau est une méthode d'optimisation basée sur le calcul GPU en effectuant plusieurs opérations consécutives en un seul appel au noyau. Cette méthode permet de minimiser les transferts de données : les résultats intermédiaires sont laissés dans les registres GPU au lieu d'être copiés dans la VRAM, ce qui permet d'économiser des frais généraux.

​ Nous avons utilisé Megatron-LM pour fournir plusieurs cœurs CUDA fusionnés personnalisés. Tout d'abord, nous utilisons un noyau optimisé pour exécuter LayerNorm et utilisons le noyau pour fusionner diverses combinaisons d'opérations de mise à l'échelle, de masquage et de softmax. Ajoutez un terme de biais aux activations GeLU à l'aide de la fonctionnalité JIT de Pytorch. À titre d'exemple utilisant des cœurs fusionnés, l'ajout d'un terme de biais à l'opération GeLU n'ajoute aucun temps supplémentaire car l'opération est liée à la mémoire : le calcul supplémentaire est négligeable par rapport aux transferts de données entre la VRAM GPU et les registres. Ainsi, la fusion des deux opérations réduit considérablement leur temps d’exécution.

4.5 Défis supplémentaires

La mise à l'échelle jusqu'à 384 GPU a nécessité deux modifications : la désactivation des lancements asynchrones du noyau CUDA (pour faciliter le débogage et éviter les blocages) et la division des groupes de paramètres en sous-groupes plus petits (pour éviter une allocation excessive de mémoire CPU).

Au cours du processus de formation, nous avons été confrontés au problème des pannes matérielles : en moyenne, 1 à 2 pannes de GPU par semaine. Étant donné que les nœuds de sauvegarde sont disponibles et utilisés automatiquement et que les points de contrôle sont enregistrés toutes les trois heures, cela n'affecte pas de manière significative le débit de formation. Le bogue de blocage de Pytorch et la défaillance de l'espace disque dans le chargeur de données peuvent entraîner un temps d'arrêt de 5 à 10 heures. Étant donné que les problèmes d'ingénierie étaient relativement rares et que le modèle s'est rétabli rapidement en raison d'un seul pic de perte, l'intervention humaine était moins nécessaire que des projets similaires.

5. Formation

• modèle pré-entraîné

  Nous entraînons les 6 variantes de taille de BLOOM en utilisant les hyperparamètres détaillés dans le tableau 3 ci-dessus. L'architecture et les hyperparamètres sont dérivés de nos résultats expérimentaux (Le Scao et al.) et de la formation préalable de grands modèles de langage (Brown et al.). La profondeur et la largeur du modèle non-176B suivent à peu près la littérature précédente (Brown et al.), et l'écart de 3B et 7.1B vise simplement à faciliter l'adaptation à notre cadre de formation. En raison du vocabulaire multilingue plus large, la taille des paramètres d'intégration de BLOOM est plus grande. Lors du développement du modèle paramétrique 104B, nous avons utilisé différents Adam $Les\; paramètres\; \beta$ , la décroissance du poids et l'écrêtage du gradient ont été utilisés pour expérimenter la stabilité objective, mais ne se sont pas révélés utiles. Pour tous les modèles, nous utilisons un programme de décroissance du taux d'apprentissage du cosinus à 410 B jetons, qui est utilisé comme limite supérieure de la durée d'entraînement si le calcul le permet, et réchauffe 375 M jetons. Nous utilisons la perte de poids, l'écrêtage de dégradé et l'absence d'abandon. L'ensemble de données ROOTS contient le texte des jetons 341B. Cependant, sur la base des lois de mise à l'échelle révisées publiées lors de la formation, nous avons décidé de former de grands modèles avec 25 milliards de jetons supplémentaires sur des données répétées. Étant donné que les jetons d'échauffement + les jetons de désintégration sont supérieurs au nombre total de jetons, la décroissance du taux d'apprentissage n'a jamais atteint la fin.

• Ajustement multitâche

  Le modèle BLOOMZ affiné conserve les mêmes hyperparamètres architecturaux que le modèle BLOOM. Les hyperparamètres affinés sont approximativement basés sur T0 et FLAN. Le taux d'apprentissage doit doubler le taux d'apprentissage minimum du modèle pré-entraîné correspondant, puis arrondir. Pour les variantes plus petites, la taille globale du lot est multipliée par 4 pour augmenter le débit. Le modèle est affiné sur des jetons 13B et le point de contrôle optimal est sélectionné sur la base d'un ensemble de validation indépendant. Après avoir affiné les jetons 1 à 6 milliards, les performances ont tendance à être stables.

• réglage fin du contraste

  Nous avons également utilisé le schéma SGPT Bi-Encoder pour un ajustement comparatif des modèles BLOOM avec les paramètres 1.3B et 7.1B afin de former des modèles qui produisent des intégrations de texte de haute qualité. Nous avons créé SGPT-BLOOM-1.7B-msmarco pour la recherche d'informations multilingues et SGPT-BLOOM-1.7B-nli pour la similarité sémantique multilingue. Cependant, des benchmarks récents ont montré que de tels modèles peuvent également se généraliser à diverses autres tâches d'intégration, telles que l'exploration de bitextes, le réarrangement ou l'extraction de caractéristiques pour la classification en aval.

6. Publier

​ L'ouverture est au cœur du développement de BLOOM, et nous voulons nous assurer qu'il est facile à utiliser pour la communauté.

6.1 Carte modèle

​ Conformément aux meilleures pratiques de publication de modèles d'apprentissage automatique, les modèles BLOOM sont publiés avec une carte modèle détaillée, qui décrit les spécifications techniques, les détails de la formation, l'utilisation prévue, les utilisations hors de portée et les limitations du modèle. Les participants des groupes de travail travaillent ensemble pour générer la carte modèle finale et chaque carte de point de contrôle.

6.2 Licence

Compte tenu des cas d'utilisation potentiellement dangereux que BLOOM pourrait apporter, j'ai choisi de trouver un équilibre entre un accès illimité au développement et une utilisation responsable, y compris un code de conduite pour limiter l'application du modèle aux cas d'utilisation potentiellement dangereux. Ces termes sont généralement inclus dans les « Licences d'IA Responsables (RAIL) », les licences adoptées par la communauté lors de la sortie des modèles. La différence significative avec la licence RAIL adoptée par BLOOM au départ est qu'elle sépare « code source » et « modèle ». Il comprend également des définitions détaillées de « l'utilisation » du modèle et du « travail dérivé » pour garantir une identification claire des utilisations en aval grâce à des incitations, un réglage fin, une distillation, l'utilisation de logits et des distributions de probabilité. La licence contient 13 restrictions d'utilisation comportementale, qui sont déterminées en fonction de l'utilisation prévue et des restrictions décrites par la carte modèle BLOOM et le code d'éthique BigScience. La licence fournit le modèle gratuitement et les utilisateurs peuvent utiliser le modèle librement tant qu'ils en respectent les termes. Le code source de BLOOM a été rendu accessible sous la licence open source Apache 2.0.

3. Évaluation

L'évaluation se concentre sur les réglages zéro tir et quelques tirs. Notre objectif est de présenter une image précise de BLOOM par rapport aux LLM existants. En raison de la taille de ces modèles, les approches basées sur des invites et un « apprentissage en contexte » en quelques étapes sont plus courants que le réglage fin.

1. Conception expérimentale

1.1 Invites

Sur la base de recherches récentes sur l'impact des invites sur les performances des modèles de langage, nous avons décidé de créer une suite d'évaluation de modèles de langage qui nous permet de faire varier les données de tâches sous-jacentes, ainsi que d'inviter à des tâches « contextualisées ». Notre invite a été développée avant la version BLOOM sans aucune amélioration préalable utilisant le modèle. Notre objectif en concevant l'invite de cette manière est de simuler les résultats zéro ou unique que les nouveaux utilisateurs attendent de BLOOM.

Nous utilisons promptsource pour générer plusieurs invites pour chaque tâche. Nous avons suivi Sanh et al.(2022)le processus utilisé, les invites ont été générées par le crowdsourcing, nous avons donc pu voir différentes longueurs et styles d'invites. Pour promouvoir la qualité et la clarté, effectuez plusieurs évaluations par les pairs sur chaque invite.

Le tableau 5 ci-dessus montre quelques invites finales pour les tâches WMT'14. En raison de contraintes de ressources, nous générons également des invites pour de nombreuses tâches non incluses dans cet article. Toutes les invites pour toutes les tâches sont accessibles publiquement.

1.2 Infrastructures

Notre framework étend le harnais d'évaluation de modèle de langage d'EleutherAI en intégrant la bibliothèque promptsource. Nous avons publié le harnais d'évaluation du modèle de langage invité en tant que bibliothèque open source que les utilisateurs peuvent utiliser. Nous utilisons ce cadre pour mener des expériences et regrouper les résultats.

1.3 Ensemble de données

• Super colle

  Nous utilisons un sous-ensemble de la suite d'évaluation des tâches de classification SuperGLUE, en particulier : les tâches Ax-b, Ax-g, BoolQ, CB, WiC, WSC et RTE. Nous avons exclu les tâches restantes car elles nécessitaient un ordre de grandeur supérieur à toutes les tâches que nous avons considérées combinées. Les tâches sont rédigées dans un anglais simple, principalement pour faciliter la comparaison avec les travaux antérieurs. Nous notons également que les performances utilisant les paramètres d'invite zéro et unique sur ces tâches ne sont pas largement rapportées. La première exception est T0, mais le modèle est réglé sur les instructions, il ne peut donc pas être directement comparé à BLOOM et OPT. Pour chaque tâche, nous sélectionnons au hasard 5 échantillons dans la source d'invite, puis évaluons tous les modèles sur l'ensemble d'invites.

• Traduction automatique (MT)

  Nous évaluons BLOOM sur trois ensembles de données : WMT14 $\text{fra}\leftrightarrow \text{fre}$和$\text{fra}\leftrightarrow \text{hin}$ , Flores-101 et DiaBLa. Nous utilisons sacrebleu, une implémentation BLEU, pour l'évaluation. Utilisez le décodage gourmand dans le processus de génération jusqu'au jeton EOS, ajoutez \n###\n pour 1-shot.

• Récapitulation

  Nous évaluons la synthèse sur l'ensemble de données WikiLingua. WikiLingua est un ensemble de données de synthèse multilingue composé d'articles WikiHow et de paires de résumés étape par étape. Les modèles de taille comparable à BLOOM ne signalent généralement pas la génération ponctuelle de langage naturel conditionnel. PaLM est la première exception, faisant rapport sur WikiLingua ; cependant, seule la capacité de résumé en anglais du modèle est examinée. À titre de comparaison, nous testons les capacités multilingues de BLOOM en évaluant des résumés dans la langue source. Nous nous concentrons sur 9 langues (arabe, anglais, espagnol, français, hindi, portugais, vietnamien et chinois) qui sont les objectifs de BigScience.

1.4 Modèle de référence

• mGPT : modèles de style GPT formés sur 60 langues ;
• GPT-Neo, GPT-J-6B, GPT-NeoX : famille de modèles de style GPT formée sur Pile ;
• T0 : variante T5 affinée par le multitâche promu sur l'ensemble de données P3 ;
• OPT : un modèle de style GPT, formé sur des ensembles de données mixtes ;
• XGLM : modèle multilingue de style GPT formé sur les variantes CC100 ;
• M2M : modèle d'encodeur-décodeur entraîné avec des fonctions objectives masquées et causales sur Wikipédia et mC4 ;
• mTk-Instruct : variante T5 pour un réglage fin multi-tâches sur l'ensemble de données Super-NaturalInstructions ;
• Codex : modèle GPT affiné sur le code de GitHub ;
• GPT-fr : modèle de style GPT entraîné sur le texte français ;

2. Effet Zero-Shot

Dans les tâches de compréhension et de génération du langage naturel, nous avons constaté que les performances zéro des modèles de langage pré-entraînés sont presque aléatoires. La figure 7 ci-dessus montre les performances du tir zéro.

2.1 SuperGLUE

Sur SuperGLUE, bien que certaines invites indépendantes affichent une amélioration des performances d'environ 10 points, l'amélioration moyenne des invites individuelles est presque aléatoire . Sauf pour le modèle T0, qui présente un fort effet. Cependant, ce modèle est affiné dans le paramètre multitâche pour améliorer l'effet de l'invite de tir zéro.

2.2 Traduction automatique

Dans le cadre du zéro-shot, les résultats de la traduction automatique sont très médiocres . Il existe deux problèmes principaux avec les résultats générés : (1) surgénération ; (2) impossibilité de générer un langage correct.

3. Résultats ponctuels

3.1 SuperGLUE

​ L'affichage de la figure 7 ci-dessus montre également l'effet du one-shot. Par rapport à l'effet du tir zéro, la variabilité de l'effet unique de toutes les invites et modèles sur SuperGLUE est réduite. Dans l’ensemble, il n’y a pas d’amélioration significative dans le réglage one-shot : la précision du modèle est encore proche du hasard. Nous effectuons des analyses supplémentaires sur BLOOM à différentes tailles de modèles. À titre de référence, nous mesurons également la précision ponctuelle de modèles OPT de taille similaire. Les familles de modèles OPT et BLOOM s'améliorent légèrement avec l'échelle. BLOOM-176B surpasse l'OPT-175B sur Ax-B, CB et WiC.

3.2 Traduction automatique

Dans le paramètre 1-shot, nous utilisons l'invite XGLM pour tester les instructions de langage centrales sur l'ensemble de test de développement Flores-101. Nous sélectionnons au hasard des échantillons uniques dans le même ensemble de données, qui peuvent différer des travaux antérieurs. Nous séparons les différents résultats par paires de langues à ressources élevées, paires de langues à ressources élevées à moyennes, paires de langues à faibles ressources et familles de langues romanes. Selon la proportion de langues dans ROOTS, les langues sont classées en ressources faibles, moyennes et élevées. Pour les paires de langues à ressources élevées et moyennes-élevées, nous comparons avec les résultats supervisés du modèle M2M-124 avec 615 millions de paramètres. De plus, nous comparons les résultats XGLM (7,5B) en 1 prise avec les résultats AlexaTM en 32 prises. **Bons résultats pour les traductions des langues à ressources élevées et des langues à ressources élevées vers les langues à ressources moyennes. **Cela montre que BLOOM a une bonne capacité multilingue. Par rapport aux modèles M2M supervisés, les résultats sont souvent comparables, voire meilleurs, dans le cadre d'une seule prise, et dans de nombreux cas, les résultats sont comparables à ceux d'AlexaTM.

**La qualité de traduction est bonne pour de nombreuses langues à faibles ressources, comparable voire meilleure que les modèles M2M supervisés. **Cependant, les performances entre le swahili et le yoruba sont assez médiocres, en raison du manque de données d'entraînement BLOOM.

3.3 Résumé

​ La figure 9 ci-dessus montre la comparaison des résultats uniques de BLOOM et d'OPT-175B. Chaque point représente un score préalable. La conclusion clé est que BLOOM atteint des performances supérieures à OPT en matière de synthèse multilingue, et que les performances augmentent à mesure que les paramètres du modèle augmentent. Nous pensons que cela est dû à la formation multilingue de BLOOM.

4. Ajustement multitâche

En nous appuyant sur des travaux récents sur le réglage fin multitâche, nous explorons l’utilisation du réglage fin multitâche multilingue pour améliorer les performances zéro tir des modèles BLOOM. Nous utilisons le corpus xP3 pour effectuer un réglage fin multitâche multilingue sur BLOOM. Nous constatons que la capacité à réaliser des performances sans tir est considérablement améliorée. Dans la figure 10 ci-dessus, nous comparons l'effet zéro-shot des modèles BLOOM et XLGM avec le réglage fin multitâche de BLOOMZ, T0 et mTk-Instruct. Les performances de BLOOM et XGLM sont résolues selon des lignes de base aléatoires. Après un réglage fin multilingue et multitâche (BLOOMZ), l'effet du zéro-shot est considérablement amélioré. Bien qu'il soit affiné sur plusieurs tâches, puisque T0 est un modèle anglais monolingue, il fonctionne mal sur des ensembles de données multilingues. Cependant, Muennighoff et al.des résultats supplémentaires que nous avons fournis montrent que le modèle affiné sur l'ensemble de données anglais xP3 surpasse toujours T0 lors du contrôle de la taille et de l'architecture. Cela pourrait être dû au fait que l'ensemble de données affiné T0 (P3) contient une plus faible diversité d'ensembles de données et d'invites que xP3.

5. Génération de codes

Le corpus de pré-formation BLOOM ROOTS contient environ 11 % du code. Le tableau 9 ci-dessus montre les résultats de référence de BLOOM sur HumanEval. Nous constatons que BLOOM pré-entraîné fonctionne aussi bien qu'un modèle GPT de taille similaire formé sur Pile. La pile contient des données en anglais et environ 13 % de code, ce qui est similaire à la source de données de code et à la proportion dans ROOTS. Le modèle Codex, qui est affiné uniquement sur le code, est beaucoup plus puissant que les autres modèles. Comparé au modèle BLOOM, le modèle BLOOMZ multitâche affiné ne s’améliore pas de manière significative. Nous supposons que cela est dû au fait que l’ensemble de données de réglage fin xP3 ne contient pas une grande quantité de code pur.