train-llm-from-scratch: Pretraining, SFT und GRPO in reinem PyTorch

Ein Lehrpfad statt einer Trainingsbibliothek

Das Projekt versteht sich laut README nicht als Werkzeug für den Produktivbetrieb, sondern als durchgehender Pfad: von Rohtext über Tokenisierung und Vortraining bis zu SFT, Reward Model und mehreren Reinforcement-Learning-Varianten. Der Autor schreibt, es habe als Pretraining-Tutorial begonnen und decke inzwischen auch Alignment und Reasoning ab. Die Zielgruppe benennt das README selbst in drei Rollen: Studierende, die von oben nach unten lesen, Entwickler, die Kommandos und Dateipfade direkt übernehmen, und Forschende, für die laut README die Post-Training-Hälfte der interessante Teil ist. Die Einschränkung steht offen im Text: kein trl, kein peft, kein transformers. Wer eine Bibliothek sucht, die ihm Arbeit abnimmt, ist hier falsch. Wer sehen will, wie ein Bradley-Terry-Reward-Model oder PPO mit GAE tatsächlich implementiert wird, findet den Code im Repository.

Der Datenfluss: von Rohtext zu Token-IDs auf der Platte

Der Ablauf folgt einer Kette, die das README als Diagramm zeigt: raw text, tokens, ein Transformer, Next-Token-Loss, ein Basismodell. Danach folgt die zweite Kette: Basismodell, SFT, Reward Model, dann PPO oder DPO, anschließend GRPO, zuletzt Evaluation und Chat. Die Farbcodierung der Diagramme ist im README dokumentiert und nicht bloß Dekoration: Grün steht für Rohdaten, Türkis für tokenisierte Daten auf der Festplatte, Blau für einen Verarbeitungsschritt, Gelb für das Modell oder einen Trainingsschritt, Orange für Reinforcement Learning und Reward, Rot für einen Loss, Grau für einen gespeicherten Checkpoint, Violett für Ausgabe oder Evaluation. Bemerkenswert ist der türkise Schritt: Die Tokenisierung wird offenbar materialisiert, das heißt einmal in Token-IDs umgewandelt und abgelegt, statt bei jedem Trainingslauf neu zu tokenisieren. Das spart Rechenzeit in späteren Läufen, bindet aber den gewählten Tokenizer an den einmal erzeugten Datenbestand. Wer den Tokenizer später tauscht, muss neu tokenisieren.

Der Transformer wird Stück für Stück zusammengesetzt

Die Modellbeschreibung im README ist bewusst kleinteilig und folgt der Struktur des Papers Attention is All You Need. Die Abschnitte lauten Multi Layer Perceptron, Single Head Attention, Multi Head Attention, Transformer Block und schließlich der vollständige Transformer. Das ist keine Architekturinnovation, sondern eine didaktische Zerlegung: Jede Komponente steht in reinem PyTorch, bevor sie zusammengesetzt wird. Für Leser, die Attention bisher nur als Aufruf in einer Bibliothek gesehen haben, ist das der eigentliche Wert des Repositories. Für Leser, die eine optimierte Implementierung mit Flash Attention oder Fusionskernels erwarten, ist es das Gegenteil. Das README nennt keine Kernel-Optimierungen, und die Modellgrößen bewegen sich laut Tabelle im Bereich von 13 Millionen bis wenigen Milliarden Parametern auf einer einzelnen GPU. Die handgeschriebene Attention ist damit als Lernobjekt brauchbar, nicht als Durchsatzargument.

Installation und die optionalen Extras

Das Setup ist knapp. Das README gibt drei Befehle vor: git clone des Repositories, cd in das Verzeichnis, dann pip install -e . Der editable install legt laut README die Verzeichnisse config, src, data_loader und ui auf den Importpfad, sodass PYTHONPATH nicht mehr manuell gesetzt werden muss. Das ist ein konkretes Detail, das bei älteren Anleitungen dieser Art häufig fehlt und regelmäßig zu Importfehlern führt. Dazu kommen zwei Extras: pip install -e ".[train]" zieht datasets und wandb für Datenbeschaffung und Logging, pip install -e ".[ui]" zieht streamlit, pandas und altair für das im README erwähnte Streamlit Control Panel. Das README verweist zusätzlich auf eine Dokumentationsseite unter fareedkhan-dev.github.io. Wer nur den Modellcode lesen will, braucht keines der Extras. Wer Daten herunterladen und Läufe protokollieren will, braucht das erste.

Speicher ist die harte Grenze, nicht die Parameterzahl

Die Tabelle im README ordnet GPUs nach Speicher und praktischer Modellgröße. Eine Tesla T4 mit 16 GB reicht für das 13-Millionen-Modell, aber nicht für 2 Milliarden Parameter. Eine RTX 4060 mit 8 GB wird mit etwa 1 Milliarde Parametern als Obergrenze angegeben. Für 2 Milliarden Parameter listet das README A100 mit 40 GB, RTX 4090 und RTX 3090 mit je 24 GB sowie die RTX 5090 mit 32 GB als ausreichend. Die Spalte für die RTX 5090 ist dabei auffällig ehrlich: Dort steht, dass 13 Millionen Parameter verifiziert sind und größere Konfigurationen noch offen. Solche Angaben sind selten und sprechen dafür, dass die Tabelle nicht aus Datenblättern abgeschrieben wurde. Gegen Speicherdruck bietet das Pretraining-Skript laut README die Flags --amp, --grad-checkpointing und --grad-accum, die sich einzeln zuschalten lassen. Ob sie zusammen mit jeder Modellkonfiguration funktionieren, sagt das README nicht.

Post-Training: fünf Verfahren auf demselben kleinen Transformer

Der zweite Teil des Repositories deckt SFT, ein Reward Model nach Bradley-Terry, PPO mit GAE, DPO, ORPO und KTO sowie GRPO beziehungsweise RLVR ab. Alle Verfahren laufen laut README auf demselben kleinen Transformer und auf öffentlichen Datensätzen. Das ist der inhaltlich dichteste Teil des Projekts und zugleich der, bei dem die Erwartungshaltung am häufigsten falsch ist. Ein GRPO-Lauf auf einem 13-Millionen-Modell liefert keinen Assistenten, sondern eine Demonstration des Verfahrens. Das README zeigt als Beispielausgabe eines 13-Millionen-Modells einen Textausschnitt, der thematisch driftet und an einer Stelle in eine unklare Formulierung kippt. Das ist keine Schwäche der Implementierung, sondern die erwartbare Ausgabe dieser Größenordnung, und es ist verdienstvoll, dass das README sie ungeglättet zeigt. Wer aus dem Repository ein brauchbares Chatmodell erwartet, hat den Maßstab falsch gesetzt.

Wartung, Lizenz und der Autor im Hintergrund

Das Repository steht unter der MIT-Lizenz. Diese erlaubt Weitergabe und Änderung, verlangt aber, dass der Urheberrechtsvermerk und der Lizenztext erhalten bleiben. Wer den Code in ein eigenes Produkt übernimmt, muss diesen Vermerk mitführen. Das ist keine Rechtsberatung, sondern der Hinweis, den die Lizenzkennung im Repository nahelegt. Zum Wartungsaufwand lässt sich aus dem Material wenig Belastbares ableiten: Es gibt keine abgerufenen Releases, und das README dokumentiert keine Versionskompatibilität über die Angabe Python 3.9+ hinaus. Wer das Projekt forkt, übernimmt damit auch die Pflege der Abhängigkeiten aus setup.py. Ein Punkt, der bei der Bewertung eine Rolle spielt: Das README enthält oben die Angabe, dass der Autor eine PhD-Stelle sucht. Das ist legitim und offen kommuniziert, bedeutet aber, dass die Weiterentwicklung an eine einzelne Person gebunden ist. Für ein Lernrepository ist das unproblematisch. Für Code, der in einer Pipeline landen soll, ist es ein Risiko, das man vorher kennen sollte.

Wann TRL und peft die bessere Wahl sind

Der offensichtliche Vergleich ist Hugging Face TRL zusammen mit peft und transformers. Der Unterschied liegt nicht in der Funktionalität, sondern im Ansatz. TRL stellt fertige Trainer-Klassen bereit und stützt sich auf die Modell- und Tokenizer-Ökosysteme von transformers, mit vortrainierten Checkpoints als Ausgangspunkt und LoRA-Adaptern über peft. Das Projekt hier geht den umgekehrten Weg: Es definiert den Transformer selbst, trainiert ihn von zufälligen Gewichten aus und implementiert jedes Alignment-Verfahren von Hand. Daraus folgen zwei praktische Konsequenzen. Erstens gibt es keine vortrainierten Gewichte, jeder Lauf beginnt bei null und braucht entsprechend Daten und Zeit. Zweitens ist der Anschluss an das Hugging-Face-Ökosystem nicht Teil des Entwurfs, ein Austausch von Checkpoints mit anderen Werkzeugen ist also nicht vorgesehen. Wer ein vorhandenes Modell feinabstimmen will, ist mit TRL deutlich schneller am Ziel. Wer verstehen will, was DPO oder PPO im Kern tun, lernt bei diesem Repository mehr, weil kein Trainer die Details verdeckt.

Redaktionelles Fazit

Sinnvoll ist das Repository für Leser, die den Trainingspfad von der Tokenisierung bis GRPO in reinem PyTorch nachvollziehen wollen, sowie für kleine Experimente auf einer einzelnen GPU mit 16 GB. Wer verteiltes Training, fertige Checkpoints oder reproduzierbare Benchmarks braucht, sollte bei TRL und peft bleiben. Vor dem ersten Lauf ist zu klären, ob der eigene Datensatz das vom Skript erwartete Format hat, welche Konfigurationsdatei unter config/ zur Zielgröße passt und ob die Bibliotheksversionen aus setup.py mit der eigenen CUDA-Umgebung zusammenpassen.

Offizielle Quellen

1. FareedKhan-dev/train-llm-from-scratch on GitHub
2. Issues
3. License: MIT
4. Project website
5. README