- En entraînant des modèles de langage et multimodaux à grande échelle à partir de zéro, Reka a dû bâtir une infrastructure d’entraînement neuve ; plus que l’accès au calcul, les principaux goulots d’étranglement ont été les écarts de qualité des clusters et l’instabilité opérationnelle
- Même avec les mêmes GPU H100, selon le fournisseur et le cluster, pannes de nœuds, problèmes de câblage, erreurs GPU, goulots d’étranglement I/O et système de fichiers, suppressions de checkpoints et retards de livraison se combinaient, créant une sorte de loterie du matériel
- Contrairement à l’expérience des TPU et de l’infrastructure interne de Google, les environnements GPU externes présentaient de fortes différences en entraînement multinœud, câblage et qualité du support, si bien que le MFU et les temps d’arrêt variaient beaucoup d’un cluster à l’autre
- Il a fallu composer avec plusieurs clusters, de gros transferts de données et les contraintes de bases de code externes ; en migrant vers PyTorch, Reka a construit elle-même la supervision, des checkpoints efficaces et un système de fichiers sur mesure
- Faute de calcul suffisant, au lieu d’un scaling systématique à la Big Tech, l’équipe a dû s’appuyer sur un petit nombre d’expériences d’ablation courtes et maîtrisées, ainsi que sur des Yolo runs ; cela lui a permis de créer Reka Flash 21B et un modèle edge 7B
Construire une infrastructure d’entraînement à partir de zéro
- En entraînant un puissant modèle de langage multimodal, Reka a construit de toutes pièces l’infrastructure nécessaire pour entraîner à partir de zéro des modèles de langage et multimodaux à grande échelle
- La difficulté centrale n’était pas de choisir entre TPU et GPU, mais d’obtenir, dans des environnements d’infrastructure et de code externes, une qualité opérationnelle suffisante pour faire tourner l’entraînement de façon fiable
La loterie du matériel à l’ère des LLM
- La première condition pour entraîner un modèle est l’accès au calcul, mais en pratique, les écarts entre fournisseurs, clusters et qualité d’interconnexion des accélérateurs deviennent la variable la plus déterminante
- Même avec les mêmes GPU H100, la qualité globale des clusters variait fortement ; ici, le « matériel » désigne davantage la qualité du cluster dans son ensemble que la puce elle-même
- Reka a loué auprès de plusieurs fournisseurs de calcul des clusters allant de quelques centaines à quelques milliers de puces, avec des états allant de relativement gérables à des échecs toutes les quelques heures
- Certains clusters voyaient des nœuds échouer à intervalles courts à cause de problèmes de câblage ou d’erreurs matérielles GPU
- Même entre clusters d’un même fournisseur, la robustesse variait fortement
- Même avec des nœuds stables, de mauvaises performances I/O et de système de fichiers pouvaient provoquer des timeouts lors de l’enregistrement des checkpoints ou faire chuter fortement l’utilisation du cluster
- Certaines sources de calcul exigeaient une couche logicielle complètement différente pour exécuter les tâches, ajoutant un coût de migration pour les équipes arrivant avec leur propre base de code
- Il était difficile de savoir à l’avance quel matériel serait reçu, et à quel point l’expérience serait robuste et tolérante aux pannes
- Si un fournisseur ne livrait pas à temps, des retards de plusieurs mois pouvaient s’accumuler, et il pouvait aussi être impossible de s’approvisionner ailleurs pendant des semaines ou des mois
- Certains fournisseurs ont même supprimé des checkpoints par erreur
Outils internes pour le MFU et la gestion des pannes
- Le Model Flop Utilisation (MFU) variait selon les clusters, et des nœuds mal câblés ou des problèmes côté fournisseur pouvaient gaspiller une quantité non négligeable de calcul
- Dans des environnements où le système de fichiers était très inefficace, le simple fait que quelqu’un lance un gros transfert de données entre clusters pouvait faire s’effondrer le MFU d’un entraînement en cours
- Le niveau de support des fournisseurs variait aussi beaucoup
- Cela allait d’un support courtois à des réponses indifférentes
- Il y avait aussi des réponses formatées « façon ChatGPT » ou des réactions attribuant tous les problèmes à l’utilisateur
- Chaque cluster avait ses propres difficultés et modes de défaillance, au point de donner l’impression qu’il fallait un hotfix distinct pour chacun
- Pour créer un environnement utilisable, Reka a développé plusieurs outils internes
- Outils de supervision
- Checkpoints efficaces
- Diverses optimisations
- Installation d’un système de fichiers sur mesure pour un stockage de données extensible
- Cette combinaison d’outils a réduit les temps d’arrêt et amélioré sensiblement le MFU, même sur du matériel médiocre
Différences entre les expériences GPU et TPU
- Reka a entraîné la plupart de ses modèles sur GPU
- Comparé à l’expérience chez Google, où les TPUs étaient principalement utilisés pour l’entraînement de grands modèles de langage, CUDA et nccl constituaient un environnement peu familier
- Le taux de panne des GPU était très différent de l’expérience des TPUs chez Google
- Le UL2 20B de Google a continué à tourner accidentellement pendant un mois sans échouer
- Dans un environnement GPU, il aurait probablement échoué dès les premiers jours
- Cela dit, cette différence pourrait être davantage liée aux compétences de l’équipe matérielle qui gère les accélérateurs et à la qualité du support fournisseur qu’aux puces elles-mêmes
- L’entraînement multinœud dans les environnements GPU ne donnait pas l’impression d’être un concept de premier ordre, comme dans un pod TPU, mais plutôt un élément ajouté après coup
- Les méthodes de câblage permettant l’entraînement multinœud semblaient varier selon les fournisseurs, ce qui accentuait les différences d’un site à l’autre
Le poids de l’exploitation multi-cluster
- L’infrastructure interne de Google, basée sur Borg, Xmanager et Colossus, était accessible de partout
- Dans des environnements externes, il fallait configurer soi-même de nouveaux environnements sur plusieurs clusters, ce qui différait fortement de l’expérience précédente
- À moins de construire soi-même un grand pool d’accélérateurs en un seul lieu, l’utilisation de pools d’accélérateurs répartis sur plusieurs clusters semble inévitable
- La pénurie de GPU transforme naturellement l’approvisionnement en une forme de clusters distribués
- L’entraînement de grands modèles nécessite des dizaines de téraoctets de données, ce qui rend le transfert de données lui-même très lourd
- À très grande échelle, la réplication des données n’est pas simple non plus et coûte cher
- La forme idéale serait une couche d’orchestration envoyant les tâches vers différents serveurs, mais il est difficile pour une startup légère et nouvelle de disposer dès le départ d’une infrastructure d’entraînement ML aussi sophistiquée
- Reka a atténué le problème avec plusieurs workflows internes et continue d’avancer vers une infrastructure d’expérimentation de niveau mondial
- Selon l’auteur, ce type de configuration débrouillarde est généralement courant en dehors des acteurs de tout premier plan ou des grandes entreprises
Bases de code externes et choix de PyTorch
- Les bases de code préférées étaient T5X et Mesh Tensorflow, mais elles n’étaient pas des options réalistes chez Reka
- Peu de support en dehors de Google
- Un certain degré d’obsolescence
- Peu accueillantes pour les membres de l’équipe ne venant pas de Google
- Reka a choisi PyTorch, plus proche d’une solution vanilla, apparemment stable et largement utilisée
- Au début, il a fallu s’adapter à des environnements de développement externes comme pip, git et docker
- Il est aussi possible que les bases de code de Google aient été difficiles à utiliser de manière stable et conviviale en dehors de l’entreprise
- La qualité des bases de code externes semblait très en retrait par rapport à celles auxquelles l’équipe était habituée chez Google
- Les bases de code internes de Google semblaient souvent écrites directement par des chercheurs ML comme Noam Shazeer, Barret Zoph, Adam Roberts ou Hyung Won Chung
- Parmi le code produit par d’autres entreprises, certains cas étaient particulièrement insatisfaisants en termes de qualité
- Dans certaines bases de code, il fallait écrire un convertisseur dédié pour modifier la configuration de parallélisation du modèle, car les changements de parallélisation n’étaient pas fournis automatiquement
- Le support de l’entraînement à grande échelle d’encoder-decoder ou de prefixLM était également insuffisant
- Selon l’auteur, malgré une demande raisonnable dans les issues GitHub, flash attention ne fournissait toujours pas de support pour l’entraînement prefixLM, c’est-à-dire les masques personnalisés
- Il existait l’idée qu’il fallait utiliser Jax, mais pour avancer vite en startup, Reka a choisi PyTorch
Calcul limité et Yolo run
- Le scaling systématique des modèles consiste généralement à mener plusieurs séries d’expériences, en allant de petits modèles vers de plus grands — par exemple 1B → 8B → 64B → 300B — puis à sélectionner les gagnants et à continuer de les agrandir
- Dans une startup, le calcul disponible pour réaliser de grands sweeps d’hyperparamètres était beaucoup plus limité
- Reka s’est appuyée sur de nombreux Yolo runs, et estime que cela a finalement bien fonctionné
- Avec seulement un petit nombre d’expériences d’ablation plus courtes et à plus petite échelle, l’équipe est parvenue à un solide Reka Flash 21B, à un modèle edge 7B et à son plus grand modèle core à venir
- Trouver une bonne recette avec un nombre limité d’exécutions est difficile, et l’espace de recherche est si vaste qu’il fallait modifier beaucoup de variables à la fois
- Au lieu de la systématicité de la Big Tech, il a fallu s’appuyer largement sur le Yolo, le feeling et l’intuition
- L’intuition accumulée par les membres de l’équipe au cours de leurs carrières précédentes en ML a aidé à viser juste en peu d’essais
- Même après avoir entraîné de bons modèles dans un poste précédent, les différences d’infrastructure d’entraînement, de données, d’intégration de nouvelles idées et d’environnement peuvent influencer sensiblement les résultats
- Une forte expérience préalable a fortement réduit l’espace de recherche, ce qui constitue l’une des explications simples au fait qu’il ait été possible d’entraîner de puissants modèles avec peu de tentatives, de ressources et d’expériences
Des résultats en moins d’un an et les défis restants
- Le manque de calcul et l’instabilité des fournisseurs de calcul ont créé des difficultés bien plus importantes que prévu
- Reka a lancé l’entreprise, levé des fonds, acheté des puces, puis tout construit à partir de zéro
- En moins d’un an, elle affirme avoir atteint un niveau comparable à Gemini Pro/GPT-3.5 et dépassé de nombreux modèles
- Le pipeline de données et l’évaluation humaine restent des sujets à traiter davantage
1 commentaires
Avis Hacker News
Dans ce contexte, une startup ressemble finalement à une organisation disposant d’un petit nombre de personnes et de gros moyens à consacrer à un cluster d’entraînement.
L’article part du principe qu’il existe plusieurs loueurs de serveurs, et que ces serveurs vont à différentes startups ou entreprises établies.
Au bout du compte, plusieurs créateurs de LLM entraînent du texte et des images avec du matériel similaire et des données similaires, font globalement la même chose, et cherchent chacun à se différencier par leur « sauce secrète ».
Cette sauce secrète peut certes faire une différence dans la qualité de sortie d’un LLM, mais dans l’ensemble, cela ressemble à une énorme duplication de travail très énergivore.
Au final, seule une infime proportion obtiendra ne serait-ce qu’un succès correct, mais c’est le coût à payer à la frontière du progrès.
Un monopole planifié peut être plus efficace, mais ce genre de structure bat rarement le marché en matière d’innovation.
Les fondateurs semblent espérer se faire racheter simplement parce qu’ils peuvent entraîner un LLM « presque à l’état de l’art », et ce niveau de compétence et d’infrastructure peut avoir suffisamment de valeur pour construire quelque chose par-dessus.
Cela dit, c’est une histoire beaucoup plus difficile à expliquer aux investisseurs.
En réalité, j’imagine que beaucoup de startups emploient des écrivains et des photographes pour créer des données d’entraînement non contaminées et très bien étiquetées.
En regardant du côté de civitai, on voit jusqu’où on peut aller avec un petit budget de calcul, simplement grâce à un étiquetage dense.
La plupart des cas d’usage des LLM peuvent être couverts en affinant des modèles de fondation existants.
Si l’on entraîne un modèle de fondation depuis zéro, on entre sur un marché difficile à monétiser, et il suffit qu’un gros acteur sorte un nouveau modèle de fondation pour qu’il fasse plus de 95 % de ce que fait votre modèle.
Pour situer le contexte, Yi Tay était tech lead sur Google PaLM, UL2, Flan, Bard, etc., et il est maintenant cofondateur de Reka.
Reka a publié d’intéressants petits modèles multimodaux qui sont déjà passés ici.
Comme c’est quelqu’un venu de Google qui entraîne désormais des LLM dans une startup indépendante, je lui ai demandé d’écrire cet article : https://twitter.com/YiTayML/status/1765105066263052718
L’enregistrement de la conversation est ici : https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
Cet article m’a fait découvrir reka.ai, et il me semble que les LLM de Reka n’ont pas encore été beaucoup abordés sur HN [1].
Par curiosité, pendant la dernière heure, j’ai testé des prompts via l’interface de chat [2] en les comparant à ChatGPT 4, Gemini Advanced, Claude 3 et Mistral Large, puis j’ai publié les résultats ici [3].
Dans l’ensemble, Reka Flash ne semble ni nettement pire ni nettement meilleur que les autres modèles.
Bien sûr, il faudrait beaucoup plus de tests pour en avoir le cœur net.
[1] https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
[2] https://chat.reka.ai/chat
[3] https://gally.net/temp/20240307llmcomparison.html
Il vaut la peine de relever que l’auteur suppose simplement que les lecteurs comprennent « la nature sauvage » comme tout ce qui n’est pas Google.
L’article attribue beaucoup de mérite aux équipes infrastructure et hardware de Google, et j’aimerais aussi lire le point de vue de quelqu’un qui était à l’intérieur puis a travaillé sur des sujets similaires ailleurs.
Plus précisément, cela revient plutôt à dire : « pendant toute ma carrière, j’ai utilisé des TPU Google chez Google et j’étais habitué à leurs modes de panne, mais je ne connaissais pas du tout ceux des GPU ».
Quand je suis passé de l’usage principal de GPU aux TPU, mes jobs échouaient sans cesse pour des raisons difficiles à déboguer.
La couche d’indirection entre les puces x86 et les appareils TPU me faisait souvent m’arracher les cheveux pendant des heures, d’une manière que je ne rencontrais pas avec x86+NVIDIA+PyTorch.
Il y a 10 à 15 ans, Google a produit beaucoup de data scientists valant plus de 10 millions de dollars, les ingénieurs Sawzall, et lorsqu’ils sont eux aussi partis dans « la nature sauvage », ils ont eu des réactions similaires.
Cet article me semble davantage servir à promouvoir son entreprise et sa marque personnelle qu’à laisser une trace utile pour la communauté.
Pour ma part, je ne pense pas avoir déjà rencontré de panne GPU, même sur de l’entraînement à grande échelle.
Mon job d’entraînement actuel utilise un fichier JSON de 20 Go qui prend à lui seul 6 heures à charger, tourne sans problème depuis plus de 15 jours, et utilise une Tesla T4 plus ancienne.
Les GPU ont des contraintes mémoire, mais si l’on peut les anticiper et les contourner, je n’ai en pratique jamais vu de crash.
La métaphore me semble assez claire : pour une startup qui mène des projets d’infrastructure à grande échelle, il faut construire soi-même toute la logistique, comme si l’on installait un campement en pleine nature.
Ça se lit comme une scène où Seven of Nine est détachée du Collective et se rend compte qu’elle doit dépendre des capacités dérisoires des humains.
Les observations sur les fournisseurs étaient utiles.
J’imagine qu’on ne perd pas toute la progression de l’entraînement ; la douleur est donc surtout dans le diagnostic du problème et le redémarrage du cluster, sans trop avoir à s’inquiéter de la perte de données ?
Mais quel est donc le produit qu’ils vendent ?
La page d’accueil de Reka.AI ressemble à un clone classique de ChatGPT facturé au token.
Je ne vois pas ce qui les différencie des autres entreprises, et les prix semblent aussi proches de ChatGPT 3.5-Turbo.
Le problème de l’entraînement d’un LLM à partir de zéro est un sujet très important, qui influe autant sur la vitesse et l’ampleur des itérations en IA que les améliorations du matériel brut.
L’article est intéressant mais un peu superficiel ; si l’on a géré des clusters GPU sous une forme ou une autre pendant des années, il n’est ni très profond techniquement ni surprenant.
Le point de vue d’un ancien de Google était intéressant, mais je ne vois pas bien pourquoi, lorsqu’il s’agit de faire des LLM en dehors de Google, ses anciens collègues recommandaient JAX plutôt que PyTorch.
J’aimerais que cette jeune entreprise publie plus tard un rapport plus technique sur son parcours d’entraînement. Par exemple quelque chose comme ce PDF : https://github.com/facebookresearch/metaseq/tree/main/projec...
Il y a probablement aussi un biais Google là-dedans.
La grande question, c’est comment une petite startup qui n’a pas le bon parcours ni le bon pedigree peut lever des fonds avec un produit LLM.
Le monde des startups LLM commence à ressembler à celui des hedge funds et du private equity.
Les prérequis pour un seed et une levée de fonds semblent être A) un parcours prestigieux et le bon pedigree, B) un solide réseau d’investisseurs prêts à se lancer avant même que le produit ne démarre.
C’est probablement aussi pour cela que les VC investissent dans ce type d’entreprise.
Dans le monde entier, très peu de personnes ont l’expérience adéquate pour lever des fonds, et seules celles qui peuvent lever des fonds peuvent acquérir cette expérience ; cela crée donc une barrière à l’entrée naturelle.
Du moins jusqu’à ce que les coûts de calcul deviennent suffisamment bas.
Quand je lis qu’ils ont « créé une entreprise, levé de l’argent, acheté des puces et tout construit à partir de zéro en moins d’un an, pour égaler Gemini Pro/GPT 3.5 et dépasser de nombreux modèles », je me demande quel était l’ordre de grandeur du budget consacré aux puces ou aux GPU cloud pour atteindre un LLM du niveau de GPT 3.5.
À la louche, était-ce de l’ordre de 2 à 5 millions de dollars ?
Je me demande si le titre ne devrait pas être « from the ground up » plutôt que « ground zero » : https://en.wikipedia.org/wiki/Hypocenter
Comme expression idiomatique, c’est un usage tout à fait acceptable.
Cela pourrait vouloir dire que les LLM sont une bombe nucléaire métaphorique pour l’industrie tech, mais honnêtement, moi aussi j’ai trouvé ça déroutant.
Je n’aurais pas envie d’apprendre auprès de ce genre d’auteur.
Les systèmes de Google sont stables parce que Google a investi des dizaines de milliards de dollars pendant 25 ans dans le développement de matériel, de logiciels et de processus pour ses datacenters.
Même une équipe extrêmement compétente dans une organisation plus petite et moins mature produira toujours des résultats de qualité nettement inférieure.
Il faut aussi tenir compte des priorités.
Google privilégie la stabilité et met au rebut les composants qui tombent en panne de façon répétée, même si ces pannes sont relativement rares.
Des datacenters plus petits et moins sophistiqués continuent d’utiliser des composants qui tombent souvent en panne, ou ne surveillent même pas le taux de défaillance de certains composants.
Les petits datacenters achètent parfois d’anciens composants de Google, moins fiables.
Le fait que les machines soient instables ne dit donc rien des compétences de l’équipe matériel.
Si la faible fiabilité du matériel ralentit le travail, il suffit soit d’améliorer le logiciel pour tolérer un matériel instable, soit de passer à un fournisseur de matériel plus fiable et plus cher.