Drei Ressourcen gehören zusammen
Ein größeres Modell kann mehr Muster darstellen, braucht aber geeignete Daten und ausreichend Optimierung. Mehr Daten helfen nur, wenn das Modell genügend Rechenzeit erhält, sie zu nutzen. Eine höhere Schrittzahl auf demselben kleinen Korpus vergrößert das verarbeitete Tokenbudget, aber nicht die Menge neuer Information.
Eine Gleitkommaoperation ist eine einzelne Rechnung mit entsprechend gespeicherten Zahlen, etwa eine Addition oder Multiplikation. FLOPs zählt solche Operationen. Das Wort beschreibt die Arbeitsmenge; eine Zeit kommt erst hinzu, wenn wir durch Operationen pro Sekunde teilen.
Deshalb notieren wir Parameterzahl N, tatsächlich verarbeitete Trainingstokens D und die Arbeitsmenge. Bei einem dichten Transformer ist eine häufig verwendete grobe Näherung für Pretraining-FLOPs. Sie vereinfacht mehrere Details, insbesondere kontextabhängige Attentionkosten. Die 6 setzt sich grob aus 2 FLOPs pro Parameter und Token im Forward und 4 im Backward zusammen (Kaplan et al., 2020; dort ohne Embeddingparameter). N zählt Parameter, D zählt in diesem Kapitel verarbeitete Trainingstokens; D bedeutet hier also ausdrücklich nicht Embeddingbreite. Die Schätzung ist kein universelles Performancegesetz.
Für 15 Millionen Parameter und 300 Millionen Trainingstokens ergibt die Näherung FLOPs, also 27 PFLOP Rechenarbeit. PFLOP ist hier eine Menge von Operationen. PFLOP/s wäre eine Geschwindigkeit.
Vom Rechenbudget zur Zeit
Teile die benötigte Arbeit durch einen tatsächlich erreichten Durchsatz, nicht durch eine Marketing-Spitzenzahl. Eine theoretische GPU-Leistung setzt ideale Formen, Dtypes und Auslastung voraus. Datenverarbeitung, Startkosten, Kommunikation und kleine Operationen können den realen Durchsatz deutlich senken.
Für dein Projekt ist die direkte Messung von Trainingstokens pro Sekunde oft praktischer. Wenn du 2.000 Tokens pro Sekunde misst, brauchen 10 Millionen verarbeitete Tokens grob 5.000 Sekunden, ohne zusätzliche Pausen, Evaluations- und Speicherzeiten. Diese Zahl ist eine Rechnung aus einer angenommenen Messung, keine Behauptung über deinen Mac.
Die Idee hinter Chinchilla
Die Chinchilla-Arbeit untersuchte, wie ein festes Pretraining-Rechenbudget zwischen Modellgröße und Trainingsdaten verteilt werden kann. Ihre Ergebnisse motivieren, beide Größen gemeinsam zu skalieren. Eine häufig genannte grobe Faustregel von etwa 20 Trainingstokens pro Parameter ist an bestimmte Annahmen und einen compute-optimalen Trainingspunkt gebunden. Sie ist kein Qualitätsminimum und kein Gesetz für jedes Modell.
Wenn du ein kleines Modell später sehr häufig betreiben möchtest, kann längeres Training eines kleineren Modells wirtschaftlich sinnvoll sein, obwohl es nicht den minimalen Pretraining-Aufwand für denselben Loss hat. Trainingskosten und Inferenzkosten sind verschiedene Optimierungsziele. In der Praxis werden kleinere Modelle deshalb oft weit über 20 Tokens pro Parameter hinaus trainiert: Llama 3 8B sah über 15 Billionen Tokens, also fast 2000 Tokens pro Parameter. Training Compute-Optimal Large Language Models.
Der Speicher ist ein anderer Engpass
Ein Modell kann in den Speicher passen und trotzdem für deinen Zeitrahmen zu langsam sein. Es kann auch rechnerisch schnell genug sein, aber nicht mit dem gewünschten Batch und Kontext passen. Die Parameterzahl allein entscheidet weder Laufzeit noch Spitzenverbrauch.
Vergrößere zuerst nur eine Variable: Breite, Tiefe oder Kontext. Miss danach Token-Durchsatz, vollständigen Trainingsspeicher und Validierungs-Loss. So erkennst du, ob dein Engpass Matrixdurchsatz, Speicher, Python-Overhead oder Datenvorbereitung ist.
Verteiltes Training: ein Überblick
Data Parallelism repliziert das Modell und verteilt verschiedene Batches; Gradienten werden synchronisiert. Tensor Parallelism verteilt Teile einzelner Operationen über Geräte. Pipeline Parallelism verteilt aufeinanderfolgende Schichten. Sharding von Optimizer und Parametern kann den Speicher pro Gerät reduzieren.
Diese Verfahren bringen Kommunikation, Synchronisation und Fehlerfälle hinzu. Eine Architektur mit Millionen Parametern auf einem Gerät ist darum ein sinnvoller erster Schritt. Verteilte Systeme sollten ein gemessenes Problem lösen, nicht bloß moderner wirken.
Datenaufbereitung mit skalieren
Das naive Byte-BPE in unserem Download ist leicht zu verstehen, aber für große Daten nicht effizient. Lange Pythonlisten und wiederholte Merge-Zählungen können zum Engpass werden. Ein produktiver nächster Schritt ist, das Format und die Tests zu behalten und den Tokenizertrainer durch eine optimierte Implementierung zu ersetzen.
Genauso können Memory-Mapping, parallele Datenleser und vorab tokenisierte Shards helfen. Ändere dabei nicht still den Tokenizer oder die Validierungsmethode. Eine schnellere Pipeline, die andere Daten sieht, ist kein reiner Performancevergleich.
Budget vor dem Lauf
Schätze zuerst Datentokens, Modellparameter, Speicher und Zeit aus einem kurzen Benchmark. Führe dann einen kleinen Pilotlauf durch. Wenn der Loss nicht sinnvoll reagiert, starte noch nicht den zehnmal längeren Lauf. Das teuerste Experiment ist oft ein langes Training mit einem bereits im ersten Batch erkennbaren Fehler.
Drei sinnvolle Meilensteine
Zuerst: Ein korrektes Micro-Modell kann ein kleines Batch überanpassen. Danach: Ein kleines Modell schlägt die Bigram-Baseline auf unabhängigen Dokumenten. Schließlich: Ein größerer geeigneter Korpus plus SFT liefert auf festgelegten neuen Fragen verständliche und teilweise verlässliche Antworten. Diese Meilensteine bauen Fähigkeiten und Evidenz zusammen auf.