XYZNOT

Articles · arXiv 2203.15556

Entraînement de grands modèles de langage optimaux en calcul

Training Compute-Optimal Large Language Models

Publié le cs.CLcs.LG arXivPDF

Lire avec traduction et IA

Résumé en trois lignes

  1. 🎯 Déterminer le compromis optimal entre paramètres du modèle et tokens d'entraînement sous un budget de calcul fixe.
  2. 🔧 Ajuster empiriquement les lois d'échelle sur plus de 400 runs de transformers à l'aide d'enveloppes de perte minimale, de coupes IsoFLOP et d'une modélisation paramétrique de la perte.
  3. 📈 Les paramètres et les tokens doivent croître de manière égale (, ). Le modèle Chinchilla de 70B entraîné sur 1,4T tokens égale le budget de calcul de Gopher et atteint 67,6 % sur MMLU.

Résumé

Nous étudions la taille optimale du modèle et le nombre de tokens pour entraîner un modèle de langage transformer sous un budget de calcul donné. Nous constatons que les grands modèles de langage actuels sont nettement sous-entraînés, conséquence de l'attention récemment portée à l'agrandissement de la taille des modèles tout en maintenant constante la quantité de données d'entraînement. En entraînant plus de 400 modèles de langage allant de 70 millions à plus de 16 milliards de paramètres sur 5 à 500 milliards de tokens, nous montrons que pour un entraînement optimal en calcul, la taille du modèle et le nombre de tokens d'entraînement doivent croître à parts égales : à chaque doublement de la taille du modèle, le nombre de tokens d'entraînement devrait également doubler. Nous validons cette hypothèse en entraînant un modèle prédit comme optimal en calcul, Chinchilla, qui utilise le même budget de calcul que Gopher mais avec 70B de paramètres et 4 plus de données. Chinchilla surpasse uniformément et significativement Gopher (280B), GPT-3 (175B), Jurassic-1 (178B) et Megatron-Turing NLG (530B) sur un large éventail de tâches d'évaluation en aval. Cela signifie également que Chinchilla nécessite considérablement moins de calcul pour le fine-tuning et l'inférence, facilitant grandement son utilisation en aval. Notamment, Chinchilla atteint une précision moyenne record de 67,5 % sur le benchmark MMLU, soit une amélioration de plus de 7 % par rapport à Gopher.

Résumé original (anglais)

We investigate the optimal model size and number of tokens for training a transformer language model under a given compute budget. We find that current large language models are significantly undertrained, a consequence of the recent focus on scaling language models whilst keeping the amount of training data constant. By training over 400 language models ranging from 70 million to over 16 billion parameters on 5 to 500 billion tokens, we find that for compute-optimal training, the model size and the number of training tokens should be scaled equally: for every doubling of model size the number of training tokens should also be doubled. We test this hypothesis by training a predicted compute-optimal model, Chinchilla, that uses the same compute budget as Gopher but with 70B parameters and 4 more more data. Chinchilla uniformly and significantly outperforms Gopher (280B), GPT-3 (175B), Jurassic-1 (178B), and Megatron-Turing NLG (530B) on a large range of downstream evaluation tasks. This also means that Chinchilla uses substantially less compute for fine-tuning and inference, greatly facilitating downstream usage. As a highlight, Chinchilla reaches a state-of-the-art average accuracy of 67.5% on the MMLU benchmark, greater than a 7% improvement over Gopher.

Guide de lecture

Problème et motivation

Les travaux antérieurs (notamment Kaplan et al., 2020) suggéraient que lorsque le calcul augmente, les paramètres du modèle doivent croître agressivement () tandis que le volume de tokens n'augmente que beaucoup plus lentement (). En conséquence, de grands modèles tels que GPT-3 (175B), Jurassic-1 (178B), Gopher (280B) et MT-NLG (530B) ont systématiquement été entraînés sur environ 300 milliards de tokens. Cependant, cela a conduit à des modèles considérablement sous-entraînés au regard des investissements de calcul consentis. Ce travail réexamine cet arbitrage : pour un budget de calcul fixé, comment allouer le nombre de paramètres et le nombre de tokens pour minimiser la perte sur le jeu de test ?

Idées clés

  • Scaling équivalent : Pour chaque doublement des paramètres du modèle, le nombre de tokens d'entraînement doit également doubler (, ).
  • Alignement du schedule en cosinus : La planification du taux d'apprentissage doit correspondre à l'horizon réel d'entraînement. Utiliser des points intermédiaires issus d'un run décroissant sur un horizon long fixe (par exemple 130B tokens) surestime la perte pour les petits volumes de tokens et biaise les estimations empiriques de scaling.
  • Efficacité en aval : Entraîner un modèle plus compact sur un volume de tokens substantiellement plus grand permet d'obtenir une précision identique ou supérieure à parité de calcul de pré-entraînement, tout en réduisant drastiquement l'empreinte mémoire, le coût de fine-tuning et la latence d'inférence.

Méthode (avec les équations clés)

Les auteurs évaluent plus de 400 modèles (de 70M à 16B paramètres, entraînés sur 5B à 500B tokens) selon trois approches complémentaires :

  1. Minimum sur les courbes d'apprentissage : Faire varier l'horizon sur 4 durées pour des architectures de modèles données. Extraire l'enveloppe de perte minimale par FLOP et ajuster des lois de puissance : ce qui donne , .

  2. Profils IsoFLOP : Fixer le nombre total de FLOPs à travers 9 budgets discrets ( à ) avec une décroissance en cosinus ajustée à l'horizon. Ajuster des paraboles sur les décomptes de paramètres pour trouver les minima de perte, ce qui donne , .

  3. Ajustement paramétrique de la perte : Modéliser la perte lissée à l'aide d'une décomposition du risque : où représente l'entropie naturelle du texte, la sous-optimalité de représentation, et la sous-optimalité due à l'arrêt précoce ou au volume fini de données. Minimiser la perte de Huber sur les résidus logarithmiques produit , , , , . Sous la contrainte :

Résultats (avec les chiffres les plus importants)

  • Chinchilla 70B : Entraîné avec le même budget de FLOPs que Gopher ( FLOPs, ou selon une comptabilisation exacte) en utilisant 70B paramètres et 1,4 billion (trillion) de tokens.
  • Benchmark MMLU : Chinchilla atteint 67,6 % de précision moyenne en 5-shot, surpassant Gopher (60,0 %), GPT-3 (43,9 %) et dépassant les prévisions d'experts humains pour juin 2023 (63,4 %). Il atteint de précision sur 4 tâches MMLU distinctes.
  • Benchmarks en aval : Surpasse Gopher sur BIG-bench (65,1 % contre 54,4 %), LAMBADA (77,4 % contre 74,5 %) et Natural Questions en closed-book (31,5 % en 5-shot contre 24,5 %).
  • Biais et toxicité : La toxicité non guidée (sans prompt ciblé) reste comparable entre Gopher et Chinchilla (médiane de 0,064 contre 0,066), tandis que la précision sur Winogender s'améliore globalement de 71,4 % à 78,3 %.

Limites et questions ouvertes

  • Seuls deux points à la frontière d'échelle ont été vérifiés empiriquement à parité (Gopher 280B vs Chinchilla 70B) en raison du coût d'entraînement.
  • L'analyse suppose un entraînement sur une seule époque sur des jeux de données web ; le comportement lors de la réutilisation de données sur plusieurs époques n'a pas été exploré.
  • Des observations empiriques montrent une légère concavité négative dans pour de très hauts budgets de calcul, ce qui suggère que les lois de puissance pourraient encore légèrement surestimer la taille optimale du modèle.

Termes clés

Chinchilla
Modèle de langage autorégressif de 70 milliards de paramètres entraîné sur 1,4 billion de tokens en utilisant le même budget de calcul que Gopher.
Gopher
Modèle de langage transformer de 280 milliards de paramètres entraîné sur 300 milliards de tokens, servant de baseline équivalente en calcul.
IsoFLOP profiles
Méthodologie consistant à faire varier le nombre de paramètres d'un modèle tout en maintenant les FLOPs totaux constants afin d'identifier la taille minimisant la perte.
Compute-optimal frontier
Courbe mathématique reliant le calcul disponible (en FLOPs) à l'allocation optimale entre nombre de paramètres et volume de tokens d'entraînement.
Parametric loss function
Décomposition statistique de la perte du modèle de langage en entropie de Bayes irréductible, déficit de capacité des paramètres et erreur d'optimisation liée à l'échantillon de tokens.
Huber loss
Fonction de perte robuste utilisée dans l'Approche 3 pour ajuster les runs empiriques tout en atténuant l'impact des valeurs aberrantes résiduelles aux petites échelles de calcul.
MassiveText
Corpus de pré-entraînement multi-domaines contenant des pages web, des livres, des actualités, du code et Wikipédia, utilisé pour entraîner à la fois Gopher et Chinchilla.
FLOPs calculation
Budget d'opérations de multiplication-accumulation, approximé par environ sur les passes avant et arrière, ou calculé par décompte couche par couche.

Questions

Pourquoi Kaplan et al. ont-ils conclu que les paramètres devaient croître plus vite que les tokens ?

Kaplan et al. utilisaient une planification en cosinus du taux d'apprentissage avec un horizon fixe (par ex. décroissant jusqu'à 130B tokens) et évaluaient des points intermédiaires non convergés pour les volumes de tokens plus réduits. Comme la planification en cosinus se dégrade si la durée du cycle dépasse largement le nombre réel d'itérations, ces pertes intermédiaires étaient artificiellement élevées, sous-estimant ainsi l'efficacité d'entraîner des modèles plus petits sur moins de tokens.

Quelle est la règle empirique de scaling compute-optimal selon Chinchilla ?

Le nombre de paramètres du modèle et le nombre de tokens d'entraînement doivent augmenter dans des proportions approximativement égales : pour chaque augmentation d'un facteur du calcul, la taille du modèle doit être multipliée par et le nombre de tokens par .

Combien de tokens sont recommandés pour entraîner un modèle de 175B optimal en calcul ?

Selon les prédictions de l'article, un modèle de 175 milliards de paramètres requiert environ 3,7 à 4,3 billions (trillions) de tokens et entre et FLOPs pour être optimal en calcul, ce qui dépasse largement les 300 milliards de tokens utilisés classiquement pour GPT-3.

Quels changements d'architecture ont été introduits entre Gopher et Chinchilla ?

En plus de la réduction du nombre de couches et de la dimension cachée pour passer de 280B à 70B, Chinchilla a remplacé l'optimiseur Adam par AdamW, a conservé les poids maîtres en float32 dans l'état distribué de l'optimiseur et a supprimé la normalisation NFKC du tokenizer SentencePiece.

La présentation de cette page a été rédigée par une IA à partir de l'article et peut contenir des erreurs. Consultez l'article pour les détails.

Lire avec traduction et IA