- Environ 1,8M de paramètres pour un modèle transformer de style GPT entraîné en 5 minutes sur un MacBook Pro avec quelque 20M de tokens TinyStories, pour atteindre une perplexité d’environ 9,6
- La principale contrainte d’un entraînement en moins de 5 minutes est la taille du modèle et le nombre de tokens traitables ; plus le modèle est grand, plus la convergence est lente et moins un petit volume de données est efficace
- Côté optimisation des performances, le plus efficace est de choisir un petit modèle plutôt que d’utiliser MPS, la compilation/quantification/l’accumulation de gradient ou des alternatives à PyTorch
- Des jeux de données simples et cohérents comme TinyStories ont un impact plus positif sur les petits modèles que des données de type encyclopédique
- L’architecture transformer donne de meilleurs résultats que les approches LSTM ou diffusion dans des conditions de petite taille et de temps d’entraînement très court
Vue d’ensemble
Cet article présente les résultats d’une expérience visant à déterminer le modèle de langage IA le plus performant qu’il est possible d’entraîner en 5 minutes sur un ordinateur portable (MacBook Pro), ainsi que des enseignements sur la stratégie d’entraînement optimale, le choix du jeu de données et l’architecture du modèle.
Résumé des résultats expérimentaux
- Un modèle transformer de style GPT d’environ 1,8M de paramètres a été entraîné sur environ 20M de données TinyStories, avec une perplexité de 9,6
- Les exemples générés sont courts mais prennent la forme d’histoires cohérentes, avec un anglais globalement correct sur le plan grammatical
- L’auteur souligne que, pour un modèle entraîné en 5 minutes, le niveau obtenu est plus pratique et convaincant qu’attendu
Contexte de l’expérience et limites
- L’expérience est née d’une curiosité peu réaliste : entraîner rapidement un modèle puissant dans un environnement d’ordinateur portable
- En pratique, il est possible d’entraîner des modèles bien plus puissants dans le cloud avec des GPU haut de gamme (comme le H100), mais ici la contrainte de l’expérience est le temps : 5 minutes
- À mesure que la taille du modèle augmente, la vitesse de traitement des tokens diminue, ce qui rend difficile l’obtention de bons résultats en 5 minutes
- Les modèles trop petits (par exemple 10K paramètres) n’apprennent pas une complexité suffisante
- La plage réellement exploitable se situe autour de 1M à 2M de paramètres
Optimisation du débit
- L’utilisation de MPS (Metal Performance Shaders d’Apple) est ce qui fonctionne le mieux
- Diverses optimisations mathématiques comme
torch.compile, float16, MLX, etc., apportent moins de gains que prévu, voire dégradent les performances - L’accumulation de gradient peut servir à gérer la mémoire, mais en pratique elle ralentit fortement l’exécution
- Pour être efficace, le modèle doit pouvoir mettre à jour rapidement ses poids dans la mémoire interne
Choix du jeu de données
- Avec un nombre limité de tokens (environ 10 à 20M), des données de type Simple English Wikipedia ont d’abord été utilisées ; elles permettaient d’obtenir une certaine cohérence grammaticale, mais pas de réelle cohérence sémantique
- La prédominance des noms propres et l’énumération de faits au rendu artificiel limitaient la génération de contenu réellement pertinent
- Avec le jeu de données TinyStories, la structure narrative est claire et la langue est simple, ce qui produit des résultats bien plus cohérents et plus riches de sens
- Comme il s’agit d’histoires de niveau enfant de 4 ans, même un petit modèle les apprend bien
Tokenizer et tokenisation
- L’entraînement du tokenizer n’est pas inclus dans les 5 minutes et, vu la petite taille des données, il y a peu de besoin d’optimisation
- L’apprentissage de tokens multioctets est plus facile pour le modèle
Expérimentations sur l’architecture du modèle
-
Utilisation d’une architecture transformer (style GPT-2)
- Réglage de divers hyperparamètres comme 2 à 3 couches, des fonctions d’activation comme SwiGLU, les positional embeddings, etc.
- Les LSTM obtiennent des performances proches, mais le transformer reste meilleur en termes de perplexité
- Le dropout et le mixture-of-experts sont inefficaces à cette petite échelle
- Le curriculum learning a peu d’effet car la durée d’entraînement est trop courte
-
Tentative avec un modèle de diffusion (D3PM)
- Comme le langage naturel est composé de tokens discrets, le processus de diffusion ne génère que des tokens aléatoires sans signification, ce qui mène à un échec
- Il est plus difficile d’y former rapidement une structure de phrase que dans un transformer ou un LSTM
Relation entre taille du modèle et débit en tokens/s
- Les modèles de 1M à 2M de paramètres constituent le meilleur sweet spot
- Trop grands, ils ne convergent pas en 5 minutes ; trop petits, ils atteignent immédiatement leurs limites de performance
- La loi de scaling de Chinchilla correspond globalement aux résultats observés
- Une taille de modèle idéale d’environ le nombre total de tokens d’entraînement / 20 a également été confirmée dans cette expérience
Conclusion et implications
- Même avec très peu de temps et un matériel limité, il est possible d’entraîner un modèle de storytelling cohérent
- Un entraînement de 5 minutes n’est pas adapté au développement de modèles puissants, mais il a un intérêt pour la conception de modèles petits et ultra-légers ainsi que pour les expérimentations d’optimisation matérielle et architecturale
- Avec les progrès futurs des GPU pour ordinateurs portables et des architectures de modèles, les performances de modèles entraînables en quelques minutes pourraient encore progresser
1 commentaires
Commentaires Hacker News
Dit qu’il aimerait voir sa conférence sur la cryptographie quantique, et se demande si quelqu’un connaît le lien vers cette conférence mentionnée au début de la vidéo.
L’entraînement optimisé de petits modèles est important non seulement pour l’accessibilité, mais aussi pour la recherche scientifique sur les LLM. Comme en biologie où l’on utilise des organismes simples comme la levure, il faut étudier le transformeur le plus simple possible qui présente les comportements intéressants des grands modèles, afin de mieux les comprendre et les contrôler.
L’un des podcasts récents les plus marquants portait sur l’article et le jeu de données Tiny Stories. Ce dataset ne contient que des mots et concepts simples, du niveau de contes pour jeunes enfants, mais il permet malgré tout à de petits modèles de générer de l’anglais avec grammaire, diversité et raisonnement. Le podcast avec l’auteur explique aussi très bien les capacités des LLM à travers un exemple de recherche petit et contrôlé. Dans l’analogie biologique, le dataset serait sans doute une boîte de Petri très simple et contrôlée. Liens associés : épisode du podcast, article TinyStories.
Beaucoup d’entreprises peuvent résoudre de vrais problèmes métier avec de petits modèles entraînés sur des jeux de données privés comme l’historique d’achat de leurs utilisateurs. Les avancées issues des grands modèles de langage peuvent aussi être appliquées telles quelles à de petits problèmes, à condition de pouvoir représenter la séquence d’entrée dans un langage spécialisé.
Il est largement reconnu que certains comportements et optimisations observés sur les petits modèles se reproduisent mal à grande échelle.
Ce que fait ici l’auteur relève du préentraînement, ce que réalisent habituellement les créateurs de modèles comme Google ou Meta. Pour une entreprise, le fine-tuning ou, dans une moindre mesure, du préentraînement additionnel est bien plus pratique. Souligne que l’auteur tente cela pour des raisons académiques.
Intéressé par les modèles qui tournent rapidement sur un laptop, mais l’entraînement en lui-même peut tout de même prendre plusieurs jours, voire plus.
Pense qu’il serait préférable de raisonner en énergie plutôt qu’en temps : le vrai comparatif serait d’entraîner le meilleur modèle possible sous un budget énergétique donné, en joules, ce qui rendrait aussi la comparaison entre un MBP et un H100 plus équitable.
Le point central ici n’est pas l’efficacité, mais l’« accessibilité », car un H100 n’est pas un produit du quotidien, contrairement à un laptop.
D’après ce qu’il comprend, le Mac est plus compétitif du point de vue de la consommation électrique, puisqu’il ne tire pas autant de puissance qu’un GPU Nvidia. À noter qu’on peut louer un H100 pour moins de 10 dollars de l’heure ; ce serait donc intéressant de comparer les performances de modèles qu’on peut entraîner en moins d’une heure.
Estime que n’importe quel critère peut convenir, même s’il est un peu arbitraire.
Si l’idée est d’exprimer un indicateur concret basé sur le laptop, ou sur le MacBook Pro, il aimerait que l’objectif soit formulé plus clairement.
Donne l’impression qu’il faudrait maintenant lancer des Jeux olympiques de l’efficacité en IA : laptop ou desktop, téléphone, 5 minutes, 1 heure, 1 jour, 1 semaine, sur un bateau ou avec une chèvre, peu importe l’endroit, sur un ton amusé.
« Avec une chèvre », c’est sans doute une référence à Llama. Les rimes sont limitées, mais ce serait encore plus drôle avec un accent de Boston.
Dans un roman de Vernor Vinge, des humains fabriquent un ordinateur d’échecs portable pour l’utiliser comme assistant pendant les parties. Si un tournoi fournissait non seulement une pendule d’échecs mais aussi l’alimentation électrique, cela pourrait devenir original, car les participants devraient réfléchir aux coups favorables à leur propre IA.
Blague formulée comme si un Mac Studio M3 Ultra 512GB poussé à l’extrême pouvait fournir des performances démesurées ; avec un tel bateau, on pourrait même faire flotter une chèvre.
Blague disant que la chèvre a tellement de paramètres qu’elle est quasiment au niveau de GPT-4.
Serait prêt à payer si GoatLM sortait.
À propos de l’exemple absurde « Paris, France is a city in North Carolina... », dit aimer l’expression « officially major people » et se demande comment l’utiliser dans une conversation courante.
Dit que cela lui rappelle l’article « cramming » d’il y a quelques années, et partage le lien vers l’article, qui décrit une tentative de l’auteur pour entraîner un modèle optimal en une journée sur un laptop moderne.
Pense qu’on pourrait faire bien mieux rien qu’en appliquant quelques astuces issues des essais GPT-2 speedrun — Muon, une meilleure initialisation des poids, et un réglage minutieux du taux d’apprentissage. Ressource associée : ici.
Pense qu’il manque à l’IA une culture demoscene, au sens des démos graphiques des années 90 où l’on montrait sa maîtrise technique avec très peu de ressources.
Trouve qu’il y a de la valeur à créer de petits modèles plus spécialisés, voire à les fabriquer à la demande selon les besoins. On n’a pas forcément besoin d’un grand modèle qui sait tout ; on a davantage besoin d’un modèle extrêmement rapide, focalisé comme un laser uniquement sur le domaine dans lequel on travaille. Il aimerait pouvoir demander à un grand LLM : « écris-moi un script pour entraîner un modèle optimisé pour <tâche nécessaire> », puis l’exécuter avec ce modèle. Mais entre-temps, pendant qu’il écrivait son commentaire, Google a sorti Gemma 3 270M.
En prenant comme exemple des absurdités du type « Paris, France is a city in North Carolina... », estime que les petits modèles deviendraient bien plus utiles s’ils savaient simplement dire « je ne sais pas ». Si d’énormes LLM sont nécessaires, c’est surtout parce que leur champ est si vaste qu’ils doivent éviter d’inventer des réponses. Ce serait bien de pouvoir entraîner sur un laptop, dans un temps raisonnable, un chatbot de support client, mais en dehors de son domaine il aurait de fortes chances de répondre complètement à côté.