4 Punkte von GN⁺ 2024-01-25 | 1 Kommentare | Auf WhatsApp teilen
  • Machine Learning Engineering Open Book ist eine öffentliche Sammlung von Methoden, Tools und Schritt-für-Schritt-Befehlen, um Training, Fine-Tuning und Inferenz von LLM-, VLM- und RAG-Modellen erfolgreich durchzuführen
  • Zielgruppe sind LLM/VLM-Training-Engineers und Betreiber; das Material enthält viele Skripte und direkt kopierbare Befehle, damit Probleme schnell gelöst werden können
  • Die Inhalte basieren auf Know-how aus dem Training von BLOOM-176B im Jahr 2022, IDEFICS-80B im Jahr 2023 und RAG-Modellen bei Contextual.AI im Jahr 2024
  • Der Umfang reicht von Cloud-Auswahl, Beschleunigern, Storage und Netzwerk über Orchestrierung, Training, Inferenz, Debugging und Tests bis zu Ressourcen; außerdem werden PDF- und EPUB-E-Books bereitgestellt
  • Es ist ein öffentliches Wissens-Repository, das Communities, die große ML-Compute-Cluster nur schwer selbst betreiben können, indirekt Betriebswissen aus realer Large-Scale-Training-Erfahrung vermittelt

Zweck des Buchs und Zielgruppe

  • Machine Learning Engineering Open Book ist eine öffentliche Wissenssammlung für Training, Fine-Tuning und Inferenz großer Sprachmodelle und multimodaler Modelle
  • Es hat einen stark technischen Charakter und enthält Skripte sowie kopier- und ausführbare Befehle, damit LLM/VLM-Training-Engineers und Betreiber sie schnell anwenden können
  • Die Inhalte des Repositorys entstanden ursprünglich aus persönlichen Notizen, um früher recherchierte und tatsächlich funktionierende Lösungen schnell wiederzufinden, und wurden mit der breiteren ML-Community geteilt

Erfahrungsbasierter Umfang

  • Ein großer Teil des Know-hows wurde aus realer Erfahrung mit dem Training großer Modelle gesammelt
    • Training des Open-Source-Modells BLOOM-176B im Jahr 2022
    • Training des multimodalen Modells IDEFICS-80B im Jahr 2023
    • Training von RAG-Modellen bei Contextual.AI im Jahr 2024
  • Der Fokus liegt darauf, der Community indirektes Lernen in einem Bereich zu ermöglichen, in dem direkte Erfahrung wegen der hohen Mietkosten großer ML-Compute-Cluster schwer zugänglich ist

Behandelte Themen

  • Insights

    • AI Battlefield Engineering
    • Wie man einen Cloud-Anbieter auswählt
  • Hardware

    • Compute: Beschleuniger, CPU, CPU-Arbeitsspeicher
    • Storage: lokale, verteilte und gemeinsam genutzte Dateisysteme
    • Network: Networking innerhalb von Nodes und zwischen Nodes
  • Orchestration

    • Orchestrierungssysteme zur Verwaltung von Containern und Ressourcen
    • SLURM: Simple Linux Utility for Resource Management
  • Training / Inference

    • Leitfäden zum Modelltraining
    • Insights zur Modellinferenz
  • Development

    • Debugging und Troubleshooting für einfache wie schwierige Probleme
    • The Art of Debugging Open book mit zugehörigen Rezepten und Methoden
    • Tipps und Tools, die beim Schreiben von Tests helfen
  • Miscellaneous

    • Ressourcen zur Chronik von LLMs/VLMs

Schnell auffindbare Vergleichstabellen und Tools

  • Die Vergleichstabelle für Hochleistungsbeschleuniger behandelt theoretische TFLOPS sowie Größe und Geschwindigkeit des Beschleunigerspeichers
  • Die Netzwerk-Vergleichstabelle behandelt die theoretischen Geschwindigkeiten des Networking zwischen Nodes und innerhalb von Nodes
  • Häufig verwendete Tools werden als separate Schnellzugriffe bereitgestellt
    • all_reduce_bench.py: ein Tool, um Netzwerkdurchsatz einfacher als mit nccl-tests zu benchmarken
    • torch-distributed-gpu-test.py: ein Tool, um die Konnektivität zwischen Nodes schnell zu testen
    • mamf-finder.py: ein Tool, um Messungen der auf Beschleunigern tatsächlich erreichbaren TFLOPS zu finden
  • Häufig verwendete Guides werden ebenfalls als separate Schnellzugriffe bereitgestellt
    • Debugging-Lösungen, die sich schnell anwenden lassen, wenn PyTorch-Anwendungen hängen bleiben oder abstürzen
    • Cheat Sheet und Tricks für SLURM-Nutzer
    • Methoden zum Erstellen kleiner Modelle, Datensätze und Tokenizer
    • Sammlung öffentlich verfügbarer LLM/VLM-Trainings-Logbücher

Distributionsformate und Mitwirkung

  • Das E-Book wird auf dem Hugging Face Hub bereitgestellt
  • Das E-Book soll etwa alle paar Wochen neu gebaut werden; außerdem werden Anweisungen bereitgestellt, um das neueste E-Book selbst zu bauen
  • Diskussionen rund um ML Engineering sind in den community discussions des Repositorys möglich
  • Bugs, Tippfehler und Verbesserungsvorschläge können als Issue oder PR eingereicht werden
  • Die Inhaltslizenz ist Attribution-ShareAlike 4.0 International
  • Die Zitierinformationen enthalten Machine Learning Engineering Open Book, die Jahre 2023-2026 und die URL des GitHub-Repositorys

1 Kommentare

 
GN⁺ 2024-01-25
Hacker-News-Kommentare
  • Ich arbeite in einer Research-Support-Rolle täglich daran, LLM-Trainings-Setups zu debuggen, und denke mir: Es wäre wirklich großartig gewesen, solche Notizen gehabt zu haben, als ich angefangen habe.

    • Als Spieleentwickler versuche ich gerade, in Machine Learning/Deep Learning einzusteigen. Die größte Herausforderung war, ein Problem zu finden, das nicht zu schwer ist, um beim Lernen daran zu arbeiten, aber trotzdem echten Wert hat. Ich glaube, ich habe eines gefunden, und würde gern Meinungen dazu hören.
      Derzeit gibt es bei der Erfassung von Motion-Capture-Daten für Spiele- und Film-Animationen zwei Systeme: inertiale und optische. Inertiale Systeme sind einfacher und günstiger, haben aber viele Capture-Fehler und Ungenauigkeiten, die manuell korrigiert werden müssen. Optische Systeme sind genauer und benötigen weniger Bereinigung, sind aber bei Hardware und Platzbedarf teuer.
      Die Idee wäre, jemanden einen inertialen Motion-Capture-Anzug tragen zu lassen und gleichzeitig eine optische Session aufzuzeichnen, um dann mit Machine Learning eine automatische Korrektur von Motion-Capture-Daten zu trainieren. Theoretisch könnte man inertiale Aufnahmen durch das Machine-Learning-Modell laufen lassen und Präzision auf dem Niveau optischer Systeme erreichen.
      Mich würde interessieren, ob das als erstes Projekt machbar ist, wie man es angehen sollte und ob es bestehende Projekte gibt, die als Referenz taugen.
  • Ich unterstütze angewandte Wissenschaftler bei Arbeiten rund um Modelltraining und Deployment und frage mich, wie ich mehr Einblick in Low-Level-Engineering-Aufgaben wie Optimierung und Performance bekommen kann.
    Wir haben zwar ein ML-Infrastrukturteam im Unternehmen, aber dessen Ziel ist eher, Tools rund um die Plattform zu bauen, nicht Workloads optimal laufen zu lassen.

    • Optimierung ist ohne Profiling meiner Meinung nach nicht möglich. Sich mit Tools vertraut zu machen, die die Modell-Performance verständlich machen, könnte ein erster Schritt sein.
      Beispiel: https://pytorch.org/tutorials/recipes/recipes/profiler_recip...
    • Brendan Greggs Material zu System-Performance und Profiling ist ein guter Ausgangspunkt. Ein erheblicher Teil von ML-Performance-Problemen läuft am Ende entweder auf Linux perf hinaus oder darauf, herauszufinden, was in High-Performance-Computing-Scheduling-Systemen wie SLURM eigentlich passiert.
      https://www.brendangregg.com/linuxperf.html
  • Der Abschnitt Unsolicited Advice im Bereich AI Battlefield hat mir besonders gefallen. Er behandelt sehr realistisch, wie sich alles rasend schnell bewegt und welche emotionale Belastung daraus entsteht, dass man sich angesichts des unablässigen, radikalen Fortschritts in der AI-Entwicklung ständig fühlt, als würde man unter Wasser geraten.
    https://github.com/stas00/ml-engineering/blob/master/insight...

  • Wie verbreitet ist Slurm?

    • Slurm ist in der High-Performance-Computing(HPC)-Community praktisch überall. Als ähnliche Konkurrenten im HPC-Bereich sehe ich höchstens Resource Scheduler wie SGE [1] und Torque/PBS [2].
      Genaue Zahlen kenne ich nicht, aber ich vermute, dass die überwältigende Mehrheit der Top-500-Supercomputer [3] Slurm einsetzt. Wie andere schon gesagt haben, nutzen auch die meisten akademischen Research-Computing-Zentren Slurm, und in den nationalen Laboren des US DoE ist Slurm ebenfalls dominierend.
      Und als interessante Randnotiz, vielleicht auch eher Legende: Der Name „Simple Linux Utility for Resource Management (SLURM)“ soll ein Backronym sein, das vom Getränk Slurm aus Futurama stammt [4].
      [1] https://en.wikipedia.org/wiki/Oracle_Grid_Engine
      [2] https://github.com/adaptivecomputing/torque
      [3] https://www.top500.org/
      [4] https://futurama.fandom.com/wiki/Slurm
    • Laut Wikipedia wird „Slurm auf etwa 60 % der TOP500-Supercomputer als Workload Manager eingesetzt“. Ich habe es in den letzten etwa zehn Jahren auf den meisten Compute-Clustern als Job-Manager-Frontend verwendet.
    • Auch das Llama-2-Modell wurde auf Slurm trainiert.
    • In dem Zusammenhang würde mich interessieren, ob jemand, der hauptsächlich große Modelle auf vielen GPUs auf physischen Clustern trainiert, erfolgreich von Slurm zu Kubernetes migriert ist.
    • Es wird auf den meisten High-Performance-Computing-Clustern verwendet. Standorte, die noch bei Torque geblieben sind, dürften die Ausnahme sein.
  • Ich habe zufällig den Abschnitt zur Reproduzierbarkeit angeklickt, frage mich aber immer noch, wie man Reproduzierbarkeit bei verteiltem Training erreicht. Wird es nicht langsamer, wenn man deterministische Synchronisierung erzwingt? Trotzdem habe ich gehört, dass Training zumindest bei einigen großen Unternehmen reproduzierbar ist.

    • Man möchte die Trainings-Updates möglichst kommutativ machen. Dann ist es egal, in welcher Reihenfolge die Updates angewendet werden.
  • Wie kann man solche Dinge erleben, wenn man keinen Job in dem Bereich hat?

    • Man kann Materialien wie das eingereichte Buch lesen und selbst kleine Projekte umsetzen.
      Das unterscheidet sich nicht wesentlich davon, Programmieren zu lernen, ohne bereits einen Programmierjob zu haben.
      Natürlich heißt das nicht, dass beides leicht wäre; es erfordert erhebliches Engagement.
    • Wenn das Ziel eine Anstellung ist, sollte man realistische Erwartungen haben.
      Verglichen mit Bereichen wie Webentwicklung ist der Arbeitsmarkt hier sehr klein, und die Projekte verlangen Experten mit sehr tiefem Wissen. Das ist nicht die Art von Arbeit, bei der ChatGPT oder Stack Overflow enorm weiterhelfen.
    • Mach Side Projects oder beteilige dich an den Side Projects anderer. Am wichtigsten ist, mit der Community in Kontakt zu kommen und die technische Sprache zu lernen, mit der man sich dort austauschen kann.
      Diese Community ist relativ klein, und für den Einstieg braucht man einiges: ein gewisses Maß an Machine Learning, solide Programmierfähigkeiten, Wissen darüber, wie moderne Beschleuniger funktionieren, und die Fähigkeit, Papers in dieser Richtung zu lesen und zu verstehen.
    • Meiner Erfahrung nach sind Side Projects der beste Weg. Lerne nicht nur die Technik, sondern such dir ein machbares Projekt, das die neue Technik nutzt, die du lernen willst, und arbeite dich hinein.
      Etwas „Machbares“ auszuwählen ist oft knifflig; hab also keine Angst, nach ein paar Wochen neu zu bewerten und die Erwartungen bei Bedarf anzupassen.
      Wichtig ist, in Bewegung zu bleiben.
    • Mach den fast.ai-Kurs. Mit etwas Mühe und Kreativität solltest du auch nach mehr als zwei Wochen ein Modell feinabstimmen und Ergebnisse auf aktuellem Stand erreichen können.
  • Ich würde das gern ausprobieren, habe aber keine vernünftige GPU. Mich würde interessieren, wie ihr das in der Praxis laufen lasst.

  • Welche Twitter-Accounts sollte man folgen, um auf dem neuesten Stand zu bleiben?

  • Gibt es irgendwo ein PDF? Ich sehe Build-Anweisungen, aber keine eigentliche Datei.