In einem Startup LLMs von Grund auf trainieren
(yitay.net)- Reka baute in einem Greenfield-Ansatz eine Trainingsinfrastruktur für große Sprach- und multimodale Modelle auf; der größere Engpass als die reine Beschaffung von Compute waren dabei Qualitätsschwankungen der Cluster und operative Instabilität
- Selbst bei denselben H100-GPUs führten je nach Anbieter und Cluster Node-Ausfälle, Verkabelungsprobleme, GPU-Fehler, I/O- und Dateisystem-Engpässe, gelöschte Checkpoints und Lieferverzögerungen zu einer Art Hardware-Lotterie
- Anders als mit Googles TPUs und interner Infrastruktur unterschieden sich in externen GPU-Umgebungen Multi-Node-Training, Verkabelung und Supportqualität stark, sodass sich MFU und Downtime je Cluster deutlich unterschieden
- Man musste mehrere Cluster, große Datenbewegungen und die Einschränkungen externer Codebasen in Kauf nehmen; Reka wechselte auf PyTorch-Basis und baute Monitoring, effiziente Checkpoints und ein eigenes Dateisystem selbst auf
- Wegen begrenzter Compute-Ressourcen musste man sich statt auf systematisches Skalieren im Stil von Big Tech auf wenige kurze Ablationsexperimente und Yolo runs verlassen; so entstanden letztlich Reka Flash 21B und ein 7B-Edge-Modell
Eine Trainingsinfrastruktur im Greenfield-Ansatz aufbauen
- Reka baute beim Training eines starken multimodalen Sprachmodells die Infrastruktur neu auf, die nötig ist, um große Sprach- und multimodale Modelle von Grund auf zu trainieren
- Die zentrale Schwierigkeit war nicht die Wahl zwischen TPU und GPU, sondern die Sicherstellung ausreichender operativer Qualität, damit echtes Training in externer Infrastruktur und mit externer Code-Umgebung stabil laufen kann
Die Hardware-Lotterie im LLM-Zeitalter
- Die erste Voraussetzung für Modelltraining ist Compute, doch in der Praxis war die Streuung bei Anbietern, Clustern und der Qualität der Accelerator-Anbindung der größte Einflussfaktor
- Selbst bei denselben H100-GPUs unterschied sich die Qualität ganzer Cluster stark; mit Hardware ist hier weniger der Chip selbst gemeint als die Gesamtqualität des Clusters
- Reka mietete Cluster mit einigen Hundert bis einigen Tausend Chips von mehreren Compute-Anbietern; der Zustand reichte von relativ gut beherrschbar bis zu Ausfällen im Abstand von wenigen Stunden
- Einige Cluster hatten wegen Verkabelungsproblemen oder GPU-Hardwarefehlern Nodes, die in kurzen Intervallen ausfielen
- Selbst Cluster desselben Anbieters unterschieden sich stark in ihrer Robustheit
- Selbst wenn die Nodes stabil waren, konnten schlechtes I/O und schwache Dateisysteme dazu führen, dass das Speichern von Checkpoints in Timeouts lief oder die Clusterauslastung stark sank
- Einige Compute-Quellen verlangten zum Betrieb eine völlig andere Software-Schicht, was für Teams mit eigener Codebasis zusätzliche Migrationskosten verursachte
- Vorab war schwer zu wissen, welche Hardware man tatsächlich bekommen würde und wie robust oder fehlertolerant die Erfahrung ausfallen würde
- Wenn Anbieter nicht rechtzeitig liefern konnten, kam es zu Verzögerungen von mehreren Monaten, und auch bei anderen Bezugsquellen konnte Beschaffung über Wochen oder Monate unmöglich sein
- Einige Anbieter löschten sogar versehentlich Checkpoints
Interne Tools für MFU und Ausfallbewältigung
- Je nach Cluster unterschied sich die Model Flop Utilisation (MFU), und bei falsch verkabelten Nodes oder Problemen auf Anbieterseite ging spürbar Compute verloren
- In Umgebungen mit sehr ineffizienten Dateisystemen konnte bereits der Start großer Datentransfers zwischen Clustern die MFU eines Trainingslaufs stark einbrechen lassen
- Auch das Supportniveau der Anbieter variierte stark
- Es reichte von höflicher Unterstützung bis zu gleichgültiger Reaktion
- Mitunter gab es „ChatGPT-artige“ Standardantworten oder Reaktionen, die alle Probleme den Nutzern zuschoben
- Jeder Cluster hatte eigene Schmerzpunkte und Fehlermodi, und es fühlte sich an, als brauche jeder Cluster eigene Hotfixes
- Reka entwickelte mehrere interne Tools, um nutzbare Umgebungen zu schaffen
- Monitoring-Tools
- effiziente Checkpoints
- verschiedene Optimierungen
- Installation eines benutzerdefinierten Dateisystems für skalierbare Datenspeicherung
- Diese Werkzeugkombination reduzierte selbst auf schwacher Hardware die Downtime und verbesserte die MFU spürbar
Unterschiede zwischen GPU- und TPU-Erfahrung
- Reka trainierte seine Modelle überwiegend auf GPUs
- Im Vergleich zu früheren Erfahrungen bei Google, wo für das Training großer Sprachmodelle vor allem TPUs genutzt wurden, waren CUDA und nccl ungewohnt
- Die GPU-Ausfallrate unterschied sich stark von den Erfahrungen mit TPUs bei Google
- Googles UL2 20B lief versehentlich einen Monat lang weiter, ohne auszufallen
- In einer GPU-Umgebung wäre der Lauf aus ihrer Sicht schon in den ersten Tagen gescheitert
- Dieser Unterschied könnte jedoch weniger am Chip selbst liegen als an der Leistungsfähigkeit des Hardware-Teams, das die Acceleratoren betreut, sowie an der Qualität des Anbietersupports
- Multi-Node-Training in GPU-Umgebungen fühlte sich nicht wie bei TPU-Pods als erstklassiges verteiltes Trainingskonzept an, sondern eher wie ein nachträglich ergänztes Element
- Je nach Anbieter schien sich auch die Verkabelung für Multi-Node-Training zu unterscheiden, was die Unterschiede zwischen Standorten weiter vergrößerte
Die Belastung durch den Betrieb mehrerer Cluster
- Googles interne Infrastruktur war mit Borg, Xmanager und Colossus eine Umgebung, die von überall zugänglich war
- In externen Umgebungen mussten neue Setups für mehrere Cluster direkt aufgebaut werden, was sich stark von früheren Erfahrungen unterschied
- Solange man nicht selbst an einem Ort einen großen Accelerator-Pool aufbaut, scheint die Nutzung mehrerer Accelerator-Pools über verschiedene Cluster hinweg unvermeidlich
- Der Mangel an verfügbaren GPUs macht die Beschaffung ganz natürlich zu einer verteilten Cluster-Situation
- Für das Training großer Modelle werden Datenmengen im Bereich von Dutzenden TB benötigt, sodass schon der Datentransport selbst zu einer erheblichen Belastung wird
- In sehr großem Maßstab ist auch Datenreplikation weder einfach noch günstig
- Ideal wäre eine Orchestrierungsschicht, die Jobs an mehrere Server verteilt, doch für ein schlankes neues Startup ist eine so ausgefeilte ML-Trainingsinfrastruktur in der Anfangsphase schwer aufzubauen
- Reka milderte die Probleme mit mehreren internen Workflows und bewegt sich weiter in Richtung einer Experimentierinfrastruktur auf Weltklasseniveau
- Solche improvisierten Setups seien, so habe man gehört, außerhalb der absoluten Spitzengruppe oder großer Konzerne weitgehend normal
Externe Codebasen und die Wahl von PyTorch
- Die bevorzugten Codebasen waren T5X und Mesh Tensorflow, bei Reka waren sie jedoch keine realistische Wahl
- Außerhalb von Google gibt es dafür nur begrenzten Support
- Sie sind teilweise in einem deprecated Zustand
- Für Teammitglieder ohne Google-Hintergrund sind sie wenig zugänglich
- Reka entschied sich für das verbreitete PyTorch, das näher an Vanilla lag und stabiler wirkte
- Anfangs musste sich das Team an externe Entwicklungsumgebungen wie pip, git und docker gewöhnen
- Möglicherweise wäre es auch außerhalb von Google schwierig gewesen, Googles Codebasen stabil und benutzerfreundlich zu nutzen
- Die Qualität externer Codebasen erschien deutlich schwächer als die Codebasen, an die man bei Google gewöhnt war
- Interne Google-Codebasen seien oft direkt von ML-Forschern wie Noam Shazeer, Barret Zoph, Adam Roberts und Hyung Won Chung geschrieben worden
- Bei Code anderer Unternehmen gab es teils besonders frustrierende Qualitätsprobleme
- In manchen Codebasen musste eigens ein Konverter geschrieben werden, um die Konfiguration der Modellparallelisierung zu ändern; eine automatische Anpassung der Parallelisierung gab es nicht
- Auch die Unterstützung für großskaliges Encoder-Decoder-Training oder PrefixLM-Training war schwach
- Flash Attention bot trotz nachvollziehbarer Nachfrage in GitHub-Issues weiterhin keine Unterstützung für PrefixLM-Training, also für benutzerdefinierte Masken
- Es gab zwar die Wahrnehmung, dass man Jax nutzen sollte, doch um sich als Startup schnell zu bewegen, entschied man sich für PyTorch
Begrenzte Compute-Ressourcen und Yolo runs
- Systematisches Modell-Scaling läuft üblicherweise in mehreren Stufen vom kleinen zum großen Modell, etwa 1B → 8B → 64B → 300B, wobei in jeder Stufe verschiedene Experimente laufen und die Gewinner weiter skaliert werden
- In einem Startup standen deutlich weniger Compute-Ressourcen für große Sweeps zur Überprüfung von Hyperparametern zur Verfügung
- Reka verließ sich stark auf viele Yolo runs, und rückblickend scheint das gut funktioniert zu haben
- Mit nur wenigen kleineren und kürzeren Ablationsexperimenten erreichte man ein starkes Reka Flash 21B, ein 7B-Edge-Modell und sogar das geplante größte Core-Modell
- Mit einer begrenzten Zahl an Läufen ist es schwer, eine gute Recipe zu finden; der Suchraum ist sehr groß, sodass oft viele Variablen gleichzeitig geändert werden mussten
- Statt der Systematik von Big Tech musste man sich stark auf Yolo, Gefühl und Intuition verlassen
- Die Intuition, die die Teammitglieder aus früheren ML-Stationen mitbrachten, half dabei, mit wenigen Versuchen richtig zu liegen
- Selbst wenn man im vorherigen Job gute Modelle trainiert hat, können Unterschiede bei Trainingsinfrastruktur, Daten, Integration neuer Ideen und Umgebungsproblemen die Ergebnisse deutlich beeinflussen
- Starke Vorerfahrung verringerte den Suchraum erheblich und ist eine der naheliegenden Erklärungen dafür, dass mit wenigen Versuchen, wenig Ressourcen und wenigen Experimenten dennoch starke Modelle trainiert werden konnten
Ergebnisse nach weniger als einem Jahr und verbleibende Aufgaben
- Compute-Knappheit und instabile Compute-Anbieter erwiesen sich als weit größere Hürden als erwartet
- Reka gründete das Unternehmen, beschaffte Finanzierung, kaufte Chips und baute anschließend alles von Grund auf auf
- In weniger als einem Jahr habe man ein Niveau auf Augenhöhe mit Gemini Pro/GPT-3.5 erreicht und viele Modelle übertroffen
- Datenpipeline und menschliche Evaluation bleiben Themen für eine spätere Behandlung
1 Kommentare
Hacker-News-Kommentare
In diesem Kontext wirkt ein Startup letztlich wie eine Organisation mit wenigen Mitarbeitenden und viel Kapital für einen Trainings-Cluster.
Der Artikel setzt voraus, dass es mehrere Server-Vermieter gibt und diese Server an verschiedene Startups oder etablierte Unternehmen gehen.
Am Ende trainieren mehrere LLM-Hersteller mit ähnlicher Hardware und ähnlichen Daten Text und Bilder, machen im Großen und Ganzen dasselbe und versuchen, sich jeweils über ihre „geheime Zutat“ zu differenzieren.
Diese geheime Zutat kann zwar einen Unterschied bei der Qualität der LLM-Ausgaben machen, insgesamt wirkt es aber wie eine riesige, energieintensive Doppelarbeit.
Am Ende wird nur ein sehr kleiner Anteil auch nur mäßig erfolgreich sein, aber an der Frontlinie des Fortschritts ist das der Preis, den man zahlt.
Ein geplantes Monopol mag effizienter sein, aber solche Strukturen schlagen den Markt bei Innovation nur selten.
Die Gründer hoffen wohl darauf, übernommen zu werden, allein weil sie ein „fast State-of-the-Art“-LLM trainieren können; diese Kompetenz und Infrastruktur könnte wertvoll genug sein, um darauf etwas aufzubauen.
Allerdings ist diese Geschichte Investoren deutlich schwerer zu erklären.
In Wirklichkeit stellen viele Startups wahrscheinlich Autoren und Fotografen ein, um nicht kontaminierte und sehr gut gelabelte Trainingsdaten zu erstellen.
Wenn man sich civitai ansieht, erkennt man, wie weit man selbst mit kleinem Compute-Budget allein durch engmaschiges Labeling kommen kann.
Die meisten LLM-Anwendungsfälle lassen sich durch Fine-Tuning fertiger Foundation Models abdecken.
Wer ein Foundation Model von Grund auf trainiert, betritt einen schwer zu monetarisierenden Markt; und sobald ein großer Anbieter ein neues Foundation Model veröffentlicht, kann es über 95 % dessen erledigen, was das eigene Modell macht.
Dem Kontext nach war Yi Tay Tech Lead für Google PaLM, UL2, Flan, Bard usw. und ist heute Mitgründer von Reka.
Reka hat interessante kleine multimodale Modelle veröffentlicht, die auch hier schon einmal auftauchten.
Da er jemand von Google ist, der nun in einem unabhängigen Startup LLMs trainiert, wurde er gebeten, diesen Beitrag zu schreiben: https://twitter.com/YiTayML/status/1765105066263052718
Die Gesprächsaufzeichnung ist hier: https://sub.thursdai.news/p/thursdai-feb-15-2024-openai-chan...
Durch diesen Beitrag bin ich auf reka.ai aufmerksam geworden, und HN scheint Rekas LLMs bisher noch nicht oft behandelt zu haben [1].
Aus Neugier habe ich in der letzten Stunde über das Chat-Interface [2] Prompts gegen ChatGPT 4, Gemini Advanced, Claude 3 und Mistral Large getestet und die Ergebnisse unter [3] veröffentlicht.
Insgesamt scheint Reka Flash weder deutlich schlechter noch besser als die anderen Modelle zu sein.
Natürlich bräuchte es für ein belastbares Urteil deutlich mehr Tests.
[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
Bemerkenswert ist, dass der Autor einfach voraussetzt, dass die Leser „Wildnis“ als nicht Google verstehen.
Der Beitrag schreibt Googles Infrastruktur- und Hardware-Teams viel Verdienst zu; ich würde gern auch die Perspektive von jemandem lesen, der dort war und anschließend anderswo an ähnlichen Dingen gearbeitet hat.
Genauer gesagt eher: „Ich habe meine ganze Karriere lang innerhalb von Google Google-TPUs genutzt und war mit deren Ausfallmustern vertraut, kannte die Ausfallmuster von GPUs aber überhaupt nicht.“
Als ich überwiegend GPUs nutzte und dann TPUs ausprobierte, scheiterten Jobs aus schwer zu debuggenden Gründen immer wieder.
Wegen der Indirektionsschicht zwischen x86-Chips und TPU-Geräten habe ich mir oft stundenlang die Haare gerauft; das war eine Art Problem, die ich bei x86+NVIDIA+PyTorch nicht erlebt habe.
Vor 10 bis 15 Jahren hat Google viele Data Scientists mit einem Wert von über 10 Millionen Dollar hervorgebracht, also Sawzall-Ingenieure, und auch sie gingen in die „Wildnis“ und reagierten ähnlich.
Dieser Beitrag wirkt weniger wie ein nützlicher Beitrag zur Dokumentation für die Community, sondern eher so, als wolle der Autor sein Unternehmen und seine persönliche Marke nach vorn bringen.
Meiner Erfahrung nach hatte ich selbst bei groß angelegtem Training noch nie einen GPU-Ausfall.
Mein aktueller Trainings-Batch-Job ist eine 20-GB-JSON-Datei, deren Laden allein 6 Stunden dauert, läuft seit über 15 Tagen problemlos und nutzt sogar die ältere Tesla T4.
Bei GPUs gibt es zwar Speicherbeschränkungen, aber wenn man sie einplant und umgehen kann, habe ich in der Praxis noch keinen Crash gesehen.
Das wirkt wie eine ziemlich klare Metapher, und ein Startup, das große Infrastrukturprojekte angeht, muss wie beim Aufschlagen eines Camps in der echten Wildnis seine Logistik selbst aufbauen.
Es liest sich wie eine Szene, in der Seven of Nine vom Collective getrennt wird und erkennt, dass sie sich auf die armseligen Fähigkeiten von Menschen verlassen muss.
Die Einblicke zu Lieferanten waren nützlich.
Man verliert ja wohl kaum den gesamten Trainingsfortschritt; liegt der Schmerz also vor allem darin, das Problem zu diagnostizieren und den Cluster wieder hochzufahren, während man sich um Datenverlust keine Sorgen machen muss?
Aber was ist eigentlich das Produkt, das sie verkaufen?
Die Hauptseite von Reka.AI sieht aus wie ein gewöhnlicher ChatGPT-Klon, bei dem man pro Token bezahlt.
Ich erkenne nicht, was sie von anderen Unternehmen unterscheidet, und die Preise wirken ähnlich wie bei ChatGPT 3.5-Turbo.
Das Problem, ein LLM von Grund auf zu trainieren, ist ein sehr wichtiges Thema, das die Iterationsgeschwindigkeit und -breite in der AI ebenso stark beeinflusst wie Verbesserungen bei der Roh-Hardware.
Der Artikel ist interessant, aber etwas oberflächlich; wenn man über Jahre in irgendeiner Form mit GPU-Clustern gearbeitet hat, ist er technisch weder besonders tiefgehend noch überraschend.
Die Perspektive eines ehemaligen Googlers war gut, aber ich verstehe nicht ganz, warum frühere Kollegen außerhalb von Google für LLMs JAX statt PyTorch empfohlen haben.
Es wäre schön, wenn dieses junge Unternehmen später einen technischeren Bericht über seinen Trainingsweg veröffentlichen würde. Zum Beispiel so etwas wie dieses PDF hier: https://github.com/facebookresearch/metaseq/tree/main/projec...
Vermutlich spielt auch eine Google-Prägung mit hinein.
Die große Frage ist, wie ein kleines Startup ohne den richtigen Hintergrund und Stammbaum mit einem LLM-Produkt Geld einwirbt.
Die Welt der LLM-Startups ähnelt zunehmend der Welt von Hedgefonds und Private Equity.
Die Voraussetzungen für Seed-Investments und Fundraising scheinen A) eine Elite-Karriere und der richtige Stammbaum sowie B) ein belastbares Investorennetzwerk zu sein, das bereit ist einzusteigen, noch bevor das Produkt überhaupt loslegt.
Das dürfte auch der Grund sein, warum VCs in solche Unternehmen investieren.
Weltweit gibt es nur sehr wenige Menschen mit genau der richtigen Erfahrung, um Kapital einwerben zu können, und nur wer Kapital einwerben kann, kann diese Erfahrung sammeln; dadurch entsteht eine natürliche Eintrittsbarriere.
Zumindest dürfte das so bleiben, bis Rechenleistung ausreichend billig wird.
Bei der Passage „ein Unternehmen gründen, Geld einsammeln, Chips kaufen und in weniger als einem Jahr alles von Grund auf aufbauen, dabei Gemini Pro/GPT 3.5 erreichen und viele Modelle übertreffen“ frage ich mich, wie groß das Budget war, das für Chips oder Cloud-GPUs ausgegeben wurde, um auf das Niveau eines GPT-3.5-LLM zu kommen.
Lag es grob in der Größenordnung von 2 bis 5 Millionen US-Dollar?
Ich frage mich, ob der Titel nicht eher „from the ground up“ statt „ground zero“ heißen müsste: https://en.wikipedia.org/wiki/Hypocenter
Als Redewendung ist das eine völlig akzeptable Verwendung.
Es könnte bedeuten, dass LLMs eine metaphorische Atombombe für die Tech-Branche sind, aber ehrlich gesagt war ich auch verwirrt.
Von so einem Autorentyp möchte ich nichts lernen.
Der Grund, warum Googles Systeme stabil sind, ist, dass Google über 25 Jahre hinweg zig Milliarden Dollar in die Entwicklung von Rechenzentrums-Hardware, Software und Prozessen investiert hat.
Selbst sehr kompetente Teams in kleineren und weniger reifen Organisationen werden zwangsläufig immer Ergebnisse von deutlich niedrigerer Qualität liefern.
Außerdem sollte man die Prioritäten berücksichtigen.
Google priorisiert Stabilität und mustert Komponenten aus, die wiederholt ausfallen, selbst wenn die Ausfälle relativ selten sind.
Kleinere und weniger ausgefeilte Rechenzentren nutzen häufig ausfallende Komponenten weiter oder überwachen nicht einmal die Ausfallrate bestimmter Teile.
Kleine Rechenzentren kaufen und verwenden mitunter auch Googles alte Teile sowie weniger zuverlässige Komponenten.
Dass Maschinen instabil sind, sagt daher nichts über die Kompetenz des Hardware-Teams aus.
Wenn die geringe Zuverlässigkeit der Hardware die Arbeit verlangsamt, kann man entweder die Software verbessern, damit sie instabile Hardware besser verkraftet, oder zu einem zuverlässigeren, teureren Hardware-Anbieter wechseln.