Ein Sprachmodell wird auf einem riesigen Datenstrom trainiert. Hochwertige Domänendaten machen darin nur einen kleinen Bruchteil aus. Wenn das Modell skaliert, wächst das Trainingsbudget proportional – und der relative Anteil dieser speziellen Daten sinkt weiter. Die Studie „Scaling Domain Data Repetition in LLM Pretraining“ von Jingwei Li und sieben weiteren Autorinnen und Autoren untersucht, wie sich dieser Verlust ausgleichen lässt. Die Frage ist, wie oft man dieselben Daten wiederholen darf, ohne dass das Modell sie nur auswendig lernt. Dieser Artikel fasst die wichtigsten Ergebnisse zusammen und erklärt, was sie für große Trainingsläufe bedeuten.
Das Dilemma: mehr Token, aber weniger Domänenanteil
In modernen Trainingspipelines steigt mit der Modellgröße auch die Anzahl der Trainings-Tokens. Das Verhältnis aus Tokens pro Parameter (TPP) bleibt dabei bewusst konstant, denn ein bestimmtes Verhältnis zwischen Datenmenge und Parameterzahl sorgt für stabile Ergebnisse. Doch hochwertige Domänendaten lassen sich nicht beliebig vermehren. Allgemeine Webdaten sind praktisch unerschöpflich. Der Anteil der Domäne am Trainingsmix verwässert also, je größer das Modell wird.
Eine naheliegende Gegenmaßnahme ist, die vorhandenen Domänendaten mehrfach durch das Training zu schleusen. Doch das hat einen Preis. Wird ein Datensatz zu oft wiederholt, beginnt das Modell ihn auswendig zu lernen statt daraus zu generalisieren – Overfitting. Wie oft darf man die gleichen Domänenbeispiele zeigen, bevor der Nutzen in Schaden kippt? Und wie hängt die optimale Wiederholungszahl von der Modellgröße ab?
Der Versuchsaufbau: Skalierung unter festem TPP
Die Autorinnen und Autoren trainieren mehrere Modellgrößen. Das Tokens-pro-Parameter-Verhältnis bleibt konstant. Variiert wird nur, wie oft die Domänendaten im Trainingsmix wiederholt werden. So lässt sich der Effekt der Wiederholung sauber von Skalierungseffekten trennen. Für jede Modellgröße messen sie den Validierungsverlust auf der Domäne und ermitteln die Wiederholungsanzahl, die diesen Verlust minimiert.
Der Validierungsverlust misst, wie gut das Modell auf bisher ungesehenen Beispielen derselben Domäne abschneidet. Ein niedriger Wert bedeutet, dass das Modell die Struktur der Domäne verstanden hat. Steigt der Verlust bei zu vielen Wiederholungen wieder an, ist das ein Signal für Überanpassung an die Trainingsbeispiele.
Größere Modelle vertragen etwas mehr Wiederholung
Hält man das TPP konstant, steigt die optimale Wiederholungszahl mit der Modellgröße leicht an. Das widerspricht der Erwartung, dass große Modelle schneller auswendig lernen. Größere Modelle nutzen offenbar einen Teil ihrer zusätzlichen Kapazität, um Wiederholungen produktiv zu verwerten, statt nur mechanisch zu memorieren.
Der Anstieg ist allerdings nicht drastisch. Wer mit einem kleinen Modell arbeitet, liegt mit seiner Schätzung der optimalen Wiederholungszahl nicht völlig falsch, wenn das große Modell unter den gleichen TPP-Bedingungen trainiert wird. Praktisch heißt das: Aufwendige Hyperparametersuchen auf dem großen Modell lassen sich teilweise durch billigere Experimente auf einem kleineren Proxy ersetzen.
Der Loss schlägt die Datenmenge
Der zweite Befund betrifft den Zusammenhang zwischen Wiederholungsanzahl und Validierungsverlust. Domänen, in denen das Modell ohnehin schon einen niedrigen Validierungsverlust erreicht, vertragen mehr Wiederholungen als Domänen mit hohem Loss. Mit anderen Worten: Wo das Modell die Domäne bereits gut beherrscht, lohnt sich häufigeres Wiederholen, weil die Gefahr der Überanpassung geringer ist.
Die Menge der einzigartigen Beispiele verrät dagegen kaum etwas über die optimale Wiederholungszahl. Die Autorinnen und Autoren finden nur einen schwachen Zusammenhang. Wer allein auf die Datenmenge schaut, um zu entscheiden, wie oft wiederholt werden soll, tappt im Dunkeln. Der Validierungsverlust ist das deutlich stärkere Signal.
Praktische Konsequenzen: Proxy-Modelle als Schätzer
Für die Trainingsplanung ergibt sich daraus eine konkrete Empfehlung. Wer ein großes Modell auf einer knappen Domäne trainieren will, kann zuerst ein deutlich kleineres Modell mit identischem TPP trainieren und dort die optimale Wiederholungsanzahl bestimmen. Der Fehler gegenüber der optimalen Einstellung beim großen Modell ist gering, solange das Verhältnis gleich bleibt.
Das spart Rechenressourcen. Anstatt auf dem eigentlichen Zielmodell mehrfach die Wiederholungsanzahl durchzuspielen – was bei modernen Modellgrößen schnell Millionen von GPU-Stunden verschlingt – genügt ein gut gewählter Proxy-Lauf. Entscheidend ist, dass das TPP übereinstimmt, sonst sind die Ergebnisse nicht übertragbar. Der Validierungsverlust auf dem kleinen Modell zeigt zudem, wie viel Wiederholung die Domäne auf der großen Skala verträgt.
Was das für Domänenmischungen bedeutet
Die Studie ist auch für die Zusammenstellung von Trainingsmischungen relevant. In der Praxis bestehen sie aus vielen Domänen, deren Qualität und Quantität stark variieren. Eine pauschale Obergrenze für Wiederholungen, wie sie oft in Pipeline-Konfigurationen steht, kann dann zu konservativ sein. Jede Domäne verdient eine eigene Betrachtung – der Validierungsverlust auf einem kleinen Modell gibt einen brauchbaren Anhaltspunkt.
Gleichzeitig sind die Grenzen klar. Die Studie untersucht einen kontrollierten Fall mit fester Domäne und festem TPP, nicht den vollen Trainingsmix mit Dutzenden konkurrierender Domänen. Wechselwirkungen zwischen Domänen, etwa wenn eine stark wiederholte Domäne den Lernfortschritt in einer anderen verdrängt, fehlen. Welche Daten genau als „hochwertige Domäne“ gelten, ist kontextabhängig. Wer die Ergebnisse anwenden will, sollte sie vor dem Hintergrund des eigenen Trainingssetups prüfen.
Kurz: Wiederholung ist kein Abfallprodukt knapper Daten, sondern ein Stellhebel. Die richtige Einstellung lässt sich mit überschaubarem Aufwand auf einem kleinen Modell finden, wenn man das TPP konstant hält und den Validierungsverlust als Maßstab nutzt. Für alle, die große Sprachmodelle mit begrenzten Domänenressourcen trainieren, ist das eine handfeste Orientierung.
Quelle: arxiv.org
