Die Frage hinter dem Projekt
Ein Sprachmodell über eine API zu nutzen, ist etwas anderes, als seine Mechanismen selbst zu implementieren und ihre Wirkung zu untersuchen.
Mit nlm möchte ich nachvollziehen, was zwischen Text und Vorhersage passiert: Wie wird ein Vokabular gelernt? Wie entstehen Embeddings? Was berechnet Attention? Wie verändert der Backward Pass die Parameter? Und woran erkenne ich, ob nach dem Training tatsächlich brauchbare Texte entstehen?
Dafür habe ich ein kleines Transformer-Sprachmodell von Grund auf implementiert und ohne GPU trainiert. Das Ziel ist kein allgemeiner Chatbot, sondern ein überschaubares, überprüfbares System für kurze, einfache englische Geschichten.
Das erste Pre-Training ist inzwischen abgeschlossen. Seitdem untersuche ich nicht nur, was nlm ausgibt, sondern auch, welche Strukturen es gelernt hat und welche Komponenten unter den getesteten Bedingungen besonders wichtig sind.
Was nlm ist
- Eigener Byte-Level-BPE-Tokenizer mit einem Vokabular von 4.096 Tokens, von Grund auf implementiert.
- Selbst implementierte Transformer-Architektur mit 12 Layern, 8 Attention-Heads pro Layer, 256 Embedding-Dimensionen und einer Kontextlänge von 512 Tokens.
- Rund 10,66 Millionen Parameter, einschließlich gelernter Token- und Positions-Embeddings.
- Gemeinsam verwendete Gewichte für Token-Embedding und Ausgabeprojektion, sogenanntes Weight Tying.
- Manuell implementierter Backward Pass und eigene Trainingsschleife.
- Selbstüberwachtes Pre-Training auf TinyStories, ausgehend von zufällig initialisierten Gewichten statt von einem fertigen Basismodell.
- CPU-only-Training auf einem VPS, ohne GPU.
- Begleitendes Buch und öffentliche Projektbeiträge zu Aufbau, Experimenten, Ergebnissen und offenen Fragen.
Training abgeschlossen – Bewertung begonnen
Der erste Pre-Training-Lauf umfasst 100.550 Schritte und dauerte rund sechs Tage. Der finale Validation-Loss liegt bei etwa 0,93.
Das ist ein technischer Meilenstein, aber noch kein umfassendes Qualitätsurteil.
Der Loss misst die Vorhersageleistung auf den verwendeten Validierungsdaten. Ob daraus lesbare, zusammenhängende Geschichten entstehen, muss zusätzlich untersucht werden.
Deshalb folgt auf das Training eine eigene Evaluierungsphase:
Modell trainieren
↓
Texte generieren
↓
Ergebnisse systematisch prüfen
↓
Interne Komponenten gezielt untersuchen
↓
Nächste Änderung begründen
Was bisher geprüft wurde
Textgenerierung über mehrere Prompts und Temperaturen
Für eine erste systematische Untersuchung habe ich 40 Geschichten erzeugt: zehn Prompts mit jeweils vier Temperaturen.
Automatisch erfasst wurden Wiederholungen, Vokabularvielfalt und das Ende auf einem Satzzeichen. Inhaltliche Kohärenz wurde zusätzlich durch Lesen beurteilt.
Eine erste Erwartung bestätigte sich dabei nicht: Die wenigsten Wiederholungen traten in diesem Test bei Temperatur 1,0 auf, nicht bei der niedrigsten getesteten Temperatur 0,5.
Das ist kein allgemeingültiges Urteil über die beste Temperatureinstellung. Es zeigt aber, warum einzelne gelungene Ausgaben und intuitive Annahmen keine ausreichende Entscheidungsgrundlage sind.
Eine Auffälligkeit aus den Trainingsdaten
In acht der 40 Generierungen erzeugte nlm die Zeichenfolge <|endoftext|> und begann danach eine neue Geschichte.
Diese Zeichenfolge wird in der verwendeten Pipeline nicht als eigenes Steuer-Token behandelt. Sie kommt als Text im Rohkorpus vor und wurde entsprechend mitgelernt.
Die Beobachtung zeigt, wie sich eine Entscheidung in der Datenpipeline später im generierten Text bemerkbar machen kann.
Ablation aller 96 Attention-Heads
Ich habe jeden Attention-Head einzeln deaktiviert und die Veränderung des Validation-Loss auf denselben Vergleichsdaten gemessen.
Layer 11, Head 0 fiel besonders auf: Seine Deaktivierung erhöhte den Loss um 0,0647 – fast dreimal so stark wie die des nächstwichtigsten einzeln getesteten Heads.
Alle 96 gemessenen Loss-Differenzen waren positiv.
Die Aussage bleibt bewusst begrenzt: Die Untersuchung zeigt, welche Eingriffe die Vorhersageleistung unter diesen Testbedingungen besonders beeinträchtigen. Sie erklärt noch nicht, welche konkrete Funktion ein Head erfüllt oder welche Kombinationen von Heads sich gegenseitig ersetzen könnten.
Untersuchung der gelernten Embeddings
Zusätzlich habe ich die trainierten Token- und Positions-Embedding-Tabellen geöffnet und ihre Vektoren untersucht.
Bei ausgewählten Tokenpaaren zeigen sich Ähnlichkeitsstrukturen, die zur Verwendung der Wörter passen. Beispielsweise sind die Vektoren von dog und cat ähnlich ausgerichtet. Auch das Gegensatzpaar happy und sad zeigt eine positive Ähnlichkeit.
Untersucht werden außerdem die Normen der Token-Embeddings und die Beziehungen zwischen Positionsvektoren.
Solche Messungen liefern Hinweise auf gelernte Strukturen. Einzelne Ähnlichkeiten sind aber noch keine vollständige Erklärung dafür, wie das Modell Sprache verarbeitet.
Aufbau
nlm ist in Python implementiert. Kein High-Level-Framework stellt die Transformer-Architektur oder die Trainingsschleife bereit; die zentralen Modelloperationen und ihre Gradienten sind im Projekt nachvollziehbar umgesetzt.
| Bestandteil | Konfiguration |
|---|---|
| Modelltyp | Autoregressives Transformer-Sprachmodell |
| Trainingsziel | Vorhersage des nächsten Tokens |
| Trainingsdaten | TinyStories |
| Vokabular | 4.096 Tokens |
| Tokenizer | Eigener Byte-Level-BPE-Tokenizer |
| Transformer-Layer | 12 |
| Attention-Heads | 8 pro Layer, insgesamt 96 |
| Embedding-Dimension | 256 |
| Kontextlänge | 512 Tokens |
| Positionsinformation | Gelernte absolute Positions-Embeddings |
| Parameterzahl | Rund 10,66 Millionen |
| Ausgabeprojektion | Mit Token-Embedding geteilte Gewichte |
| Training | CPU-only auf einem VPS |
Die Architektur bleibt bewusst klein. So lassen sich nicht nur einzelne Ausgaben beobachten, sondern auch Parameter, Zwischenergebnisse und gezielte Eingriffe praktisch untersuchen.
Das begleitende Buch
Das Buch dokumentiert den Aufbau anhand des tatsächlichen Projekts – nicht anhand einer davon getrennten Beispielimplementierung.
Es umfasst vier Teile:
- Grundlagen: Sprachmodelle, Tokens, Embeddings, BPE und Datapipeline.
- Architektur: Attention, Feed-Forward, LayerNorm, Residual Connections und Transformer-Blöcke.
- Training: Loss, manueller Backward Pass, Optimizer, Speicher, Checkpointing und Validation.
- Betrieb und Bewertung: Textgenerierung, Interpretation des Loss, Qualitätsprüfung, Debugging und CPU-Training unter realen Bedingungen.
Guardrails
| Grundsatz | Konsequenz |
|---|---|
| Mechanismen selbst nachvollziehen | Tokenizer, Architektur, Backward Pass und Trainingsschleife werden im eigenen Code untersucht. |
| Kein allgemeiner Chatbot-Anspruch | Die Aufgabe bleibt auf kurze, einfache englische Geschichten begrenzt. |
| Loss ist kein Qualitätsversprechen | Vorhersageleistung und Qualität generierter Texte werden getrennt betrachtet. |
| Beobachtung vor Verallgemeinerung | Ergebnisse werden mit ihren Testbedingungen und Grenzen dokumentiert. |
| Ablation ist keine vollständige Erklärung | Ein messbarer Eingriffseffekt zeigt noch nicht die genaue Funktion einer Komponente. |
| Änderungen brauchen eine Begründung | Weitere Trainingsläufe oder Architekturänderungen sollen aus konkreten Befunden folgen. |
| Modell | nlm bezeichnet das technische Modell: ein autoregressives Decoder-only-Sprachmodell. |
Aktueller Stand
Der erste vollständige Pre-Training-Lauf ist abgeschlossen. Textgenerierung, ein systematischer Generierungstest und eine Einzel-Head-Ablation über alle 96 Attention-Heads wurden durchgeführt.
Das begleitende Buch ist in Arbeit. Öffentliche Beiträge dokumentieren ausgewählte Schritte und Ergebnisse.
Die weitere Arbeit konzentriert sich darauf, das Buch für die Veröffentlichung fertigzustellen und die bisherigen Beobachtungen gezielter zu prüfen: Welche Muster erklären die Wiederholungen? Welche Funktion erfüllt der auffällige Attention-Head? Und welche Änderungen verbessern die Ergebnisse tatsächlich?
Das Repository ist derzeit noch nicht öffentlich zugänglich. Es wird gemeinsam mit dem Buch veröffentlicht.
nlm ist damit nicht mehr nur ein Modell im Training, sondern ein trainiertes System, dessen Fähigkeiten und Grenzen systematisch untersucht werden. Zusammen mit dem Buch, dem nachvollziehbaren Code und den begleitenden Übungen entsteht daraus ein eigenständiges Lernprodukt: ein praktischer Zugang zum Aufbau, Training und zur Bewertung eines Sprachmodells.
KI bauen. Ergebnisse prüfen.