Studie bündelt Foundation-Model-Training in einem gemeinsamen Lernverfahren
Mindverse News
KI-gestützt erstellt, vor Veröffentlichung redaktionell geprüft 3 Quellen
Das Wichtigste in Kürze
- Ein Forschungsteam schlägt vor, Vortraining, Fine-Tuning und geeignete Reinforcement-Learning-Schritte als gewichtete Maximum-Likelihood-Anpassung an unterschiedliche Datenquellen zu formulieren. [1][2]
- In kontrollierten Tests mit Reasoning-Aufgaben erreicht die vereinheitlichte Methode bei größeren Rechenbudgets bessere Genauigkeit und Abdeckung; bei mittleren Budgets bleibt gestuftes Training teils konkurrenzfähig. [3]
- Experimente mit mathematischem Reinforcement Learning zeigen, dass beigemischte Trainingsdaten Vergessen verringern können, aber auch Zielkonflikte bei Coding-Genauigkeit und Aufgabenabdeckung erzeugen. [3]
- Die Autoren stellen selbst fest, dass ihre Ergebnisse weder ein globales Optimum noch ein verlässliches Skalierungsgesetz belegen. [3]
// Inhalt · 9 Abschnitte
- Ein Trainingsschema statt getrennter Rezepte
- Was „ein Algorithmus“ hier praktisch bedeutet
- Kontrollversuch mit Reasoning-Aufgaben
- Der Rechenvergleich relativiert den Vorteil
- Weniger Vergessen, aber keine kostenlose Verbesserung
- Heterogene Daten bringen Zielkonflikte
- Der Zeitpunkt der Mischung verändert das Ergebnis
- Vorleistungen können sich erst im nächsten Training auszahlen
- Bedeutung für Unternehmen: Infrastrukturpotenzial, noch kein Kostenversprechen
- Quellen
Ein Trainingsschema statt getrennter Rezepte
Foundation Models werden üblicherweise in mehreren Phasen trainiert: auf ein Vortraining folgen häufig weiteres Training auf spezialisierten Daten, überwachtes Fine-Tuning und Reinforcement Learning (RL). Jede Phase kann eigene Datenmischungen, Ziele und technische Abläufe mitbringen. Eine neue Arbeit von Yuda Song und neun Mitautoren stellt diese Trennung infrage: Die Phasen ließen sich, so der Vorschlag, als Varianten eines gemeinsamen likelihood-basierten Trainingsverfahrens behandeln. [1][2]
Kern der Idee ist, RL-Ziele als Maximum-Likelihood-Anpassung an geeignete, vom Modell erzeugte Zielverteilungen auszudrücken. Damit würden statische Datensätze und generierte Antworten nicht zwingend in getrennten Lernverfahren verarbeitet. Stattdessen rückt die Wahl in den Vordergrund, welche Datenquellen zu welchem Zeitpunkt und in welchem Verhältnis in das Training eingehen. Das herkömmliche gestufte Vorgehen wäre in diesem Rahmen ein Sonderfall: eine Datenquelle nach der anderen, statt überlappender Mischungen. [2][3]
Die Arbeit ist als Version 1 auf arXiv gelistet und dort auf den 29. Oktober 2026 datiert. Die Hugging-Face-Papierseite nennt hingegen den 28. Oktober als Veröffentlichungsdatum und den 30. Oktober als Zeitpunkt der Einreichung auf der Plattform. Diese Zeitangaben beziehen sich offenbar auf unterschiedliche Plattformvorgänge und ergeben kein einheitliches Veröffentlichungsdatum. Die verfügbaren Einträge weisen die Arbeit als Preprint aus und nennen keinen Publikationsort in einer Fachzeitschrift oder Konferenz. [1][2]
Was „ein Algorithmus“ hier praktisch bedeutet
Die Vereinheitlichung betrifft nicht nur eine mathematische Formulierung. Die Autoren beschreiben ein gemeinsames Datenformat und einen Trainer, der Beispiele aus verschiedenen Quellen mit einer gewichteten Cross-Entropy-Verlustfunktion verarbeitet. Vortrainings- und Midtraining-Beispiele gewichten dabei alle Tokens; bei überwachten Beispielen und RL-Antworten können Eingabe- beziehungsweise Prompt-Tokens aus dem Verlust ausgeschlossen werden. Bei RL erhalten Antworten Gewichte, die aus der Bewertung der generierten Ausgaben abgeleitet werden. [3]
Für ein Verfahren mit binärer Belohnung erläutert die Projektseite einen konkreten Mechanismus: Der Generator erstellt mehrere Antworten zu einem Prompt und schätzt, wie häufig diese erfolgreich sind. Erfolgreiche Antworten erhalten ein Gewicht, fehlerhafte keines; Prompts ohne erfolgreiche Antwort tragen in dieser Variante nicht zum Gradienten bei. Die Autoren beschreiben außerdem Anpassungen für andere geeignete RL-Ziele und kontinuierliche Belohnungen. Die gemeinsame Verlustfunktion beseitigt somit nicht die Unterschiede zwischen Datenquellen und Bewertungsverfahren, sondern bildet sie über Verteilungen und Gewichte ab. [3]
Ein Datenpuffer verbindet Generierung und Optimierung: Generierte, bewertete Antworten werden abgelegt; der Trainer zieht daraus und aus statischen Beständen Beispiele, aktualisiert das Modell und veröffentlicht regelmäßig neue Gewichte. Generierung und Training laufen laut Beschreibung asynchron. Auch die Generierung selbst bleibt also Teil der Infrastruktur. „Ein Algorithmus“ bedeutet nicht, dass Datenaufbereitung, Belohnungsdefinition oder Modellgenerierung entfallen, sondern dass unterschiedliche Trainingsbeiträge in einem gemeinsamen Lernablauf zusammengeführt werden. [3]
Kontrollversuch mit Reasoning-Aufgaben
Für einen kontrollierten Vergleich trainierte das Team ein Modell mit 124 Millionen Parametern von Grund auf. Die Versuchsreihe nutzte einen festen Vortrainingsstrom von 20 Milliarden Tokens sowie einen Midtraining-Korpus mit 510 Millionen Tokens, der aus vorgegebenen Reasoning-Spuren bestand. Untersucht wurden Rätsel mit überprüfbaren Antworten und veränderbarer Schwierigkeit. Die Demonstrationen vermittelten grundlegende Denkschritte; im RL sollten daraus neue Kombinationen gelernt werden. [3]
Im gestuften Vergleich folgten Vortraining, Midtraining und RL nacheinander. In der vereinheitlichten Variante wurde ein Teil der Reasoning-Daten bereits während des Vortrainings beigemischt und im RL weiterverwendet. Bewertet wurden sowohl Aufgaben innerhalb des abgedeckten Schwierigkeitsbereichs als auch größere Rätsel, die im RL vorkamen, sowie nochmals schwierigere, im Training nicht enthaltene Fälle. Nach Angaben der Autoren übertrafen die besten vereinheitlichten Konfigurationen die gestufte Vergleichsvariante in diesen Genauigkeitstests; der relative Vorteil fiel bei den nicht trainierten, größeren Rätseln am stärksten aus. [3]
Die Datenwiederverwendung erwies sich dabei nicht als pauschale Regel. Mehrfaches Einsetzen des Midtraining-Korpus konnte in der vereinheitlichten Pipeline nützlich sein. Eine gestufte Variante, die das Midtraining von zwei auf vier Epochen verlängerte, erzielte dagegen in den beschriebenen Einstellungen eine niedrigere spätere RL-Genauigkeit. Entscheidend war demnach nicht allein, wie oft Daten verwendet wurden, sondern auch, in welcher Kombination und Phase sie in das Training eingingen. [3]
Der Rechenvergleich relativiert den Vorteil
Gleiche Zahlen an RL-Aktualisierungen bedeuten nicht automatisch gleiche Gesamtrechenkosten. Deshalb verglichen die Autoren zusätzlich Konfigurationen innerhalb eines gemeinsamen Rechenbudgets. Ihre FLOP-Schätzung umfasst Vortraining, Midtraining, Generierung im RL sowie Optimierung auf RL-Antworten und beigemischten statischen Daten. Die Auswertung betrachtet nicht nur Endpunkte, sondern die besten beobachteten Checkpoints innerhalb verschiedener Budgets. [3]
Das Ergebnis fällt differenzierter aus als ein pauschaler Siegervergleich: Bei mittleren Budgets erreichte gestuftes Training in Teilen der Auswertung weiterhin die besten beobachteten Werte, insbesondere bei Genauigkeit auf den primären RL-Aufgaben. Bei größeren Budgets lag die vereinheitlichte Variante bei Genauigkeit und Abdeckung vorn. Am deutlichsten und beständigsten war ihr Vorteil bei der Generalisierung auf größere, nicht in Training oder RL enthaltene Rätsel. [3]
Diese Kurven sind keine Vorhersage für beliebige Modellgrößen oder Trainingsbudgets. Die Autoren bezeichnen die beobachteten Frontiers ausdrücklich als Ergebnisse der getesteten Konfigurationen, nicht als globales Optimum oder prädiktives Skalierungsgesetz. Die Aussage, dass eine Suche nur über gestufte Verfahren bessere Daten- und Rechenzuteilungen übersehen kann, ist damit eine Schlussfolgerung aus diesem Experiment – kein Beleg dafür, dass vereinheitlichtes Training in jedem Einsatzfall überlegen ist. [3]
Weniger Vergessen, aber keine kostenlose Verbesserung
Ein zweiter Teil der Untersuchung fragt, ob zusätzliche Reasoning-Daten Fähigkeiten aus dem Vortraining beeinträchtigen. Vor dem RL verglichen die Autoren den Verlust auf zurückgehaltenen Vortrainingsdaten und einen Mittelwert über fünf allgemeine Benchmarks. Bei den getesteten vereinheitlichten Mischungen blieben beide Maße nahe an der Vortrainingsreferenz. Die gestuften Vergleichsmodelle zeigten dagegen einen höheren Verlust auf den zurückgehaltenen Daten und niedrigere mittlere Benchmarkwerte. Die Autoren folgern daraus, dass das Beimischen der Reasoning-Daten in diesem Versuchsaufbau das Vergessen vor dem RL verringerte. [3]
Die Aussage ist auf diese Messungen und den kontrollierten Reasoning-Korpus begrenzt. Sie beschreibt keine Garantie, dass beliebige Datenmischungen andere Fähigkeiten bewahren. Zudem erfasst die dargestellte Retentionsauswertung den Zustand vor dem RL; die Arbeit behandelt das Vergessen nach dem RL gesondert. Für Unternehmen ist diese Unterscheidung relevant: Ein Zuwachs bei einer neuen Aufgabe sagt für sich genommen weder aus, wie gut vorhandene Fähigkeiten erhalten bleiben, noch wie sich das Modell nach weiteren Trainingsphasen verhält. [3]
Heterogene Daten bringen Zielkonflikte
Um den Ansatz näher an vielfältigere Trainingsbestände heranzuführen, untersuchten die Autoren außerdem ein Modell mit 760 Millionen Parametern und mathematisches RL. Der zusätzliche Midtraining-Korpus umfasste 240 Millionen Tokens aus Webtext, Mathematik, Code und Reasoning-Spuren. Während die gestufte Variante diesen Korpus vor dem RL nutzte, mischte die vereinheitlichte Variante ihn während des mathematischen RL bei. Die Autoren variierten den Anteil von null bis fünf Prozent und hielten die Zahl der mathematischen RL-Updates konstant. [3]
In dieser Versuchsreihe blieb die mathematische Genauigkeit über die Mischungsanteile hinweg ähnlich, sank bei größeren Anteilen aber leicht. Die Aufgabenabdeckung erreichte bei den größten Anteilen die höchsten Werte, ohne sich gleichmäßig mit jedem Schritt zu verbessern. Zugleich verringerte jeder getestete Anteil oberhalb von null den Verlust auf zurückgehaltenen Daten gegenüber dem Ausgangsmodell; größere Mischungen senkten ihn weiter, und die SciQ-Genauigkeit verbesserte sich im Allgemeinen. [3]
Bei Coding-Aufgaben zeigte sich ein anderer Zielkonflikt: Die Pass-at-1-Genauigkeit nahm mit mehr Midtraining-Daten im Allgemeinen ab. Die Pass-at-32-Abdeckung lag jedoch über der gestuften Variante und der Kontrolle ohne Beimischung. Keine der getesteten Mischungen war also in allen Kennzahlen zugleich die beste. Das ist ein konkreter Hinweis darauf, dass ein einziger Anteil nicht automatisch die Ziele Genauigkeit, Abdeckung und Erhalt früherer Fähigkeiten gemeinsam maximiert. [3]
Der Zeitpunkt der Mischung verändert das Ergebnis
Die Studie untersuchte auch, ob die Verteilung der Midtraining-Daten über den Verlauf des RL wichtig ist. Verglichen wurden eine gleichbleibende Mischung, ein linearer Rückgang bis null, ein linearer Anstieg sowie ein Rückgang auf null zur Halbzeit. Alle vier Zeitpläne hatten denselben durchschnittlich konfigurierten Anteil von 0,5 Prozent. [3]
Im getesteten mathematischen RL erreichte der Zeitplan, bei dem die Beimischung nach der Hälfte endete, am Schluss höhere Coding- und SciQ-Genauigkeit als die konstante Mischung. Die SciQ-Zuwächse blieben nach dem Ende der Beimischung bestehen; zugleich stieg der Verlust auf dem Midtraining-Korpus wieder an, sodass ein Teil des Retentionsvorteils verloren ging. Mathematische Genauigkeit und Abdeckung blieben zwischen den vier Zeitplänen ähnlich. [3]
Für die Trainingsplanung deutet das darauf hin, dass der Nutzen eines Datensatzes nicht zwingend davon abhängt, ihn bis zum Ende jeder Phase konstant einzusetzen. Der Befund ist jedoch an den konkreten Korpus, die Aufgaben und die getesteten Zeitpläne gebunden. Er liefert noch keine allgemeine Regel, wann ein Unternehmen eine Datenquelle reduzieren oder aus einer Trainingsmischung entfernen sollte. [3]
Vorleistungen können sich erst im nächsten Training auszahlen
Ein weiteres Experiment prüfte, ob Modelle nach mathematischem RL unterschiedlich gut für ein späteres Coding-RL geeignet waren. Dafür wurden ein gestuft trainiertes Modell und vier vereinheitlichte Ausgangsmodelle mit verschiedenen Anteilen des Midtraining-Korpus anschließend derselben Coding-RL-Konfiguration ausgesetzt – ohne weitere Beimischung dieses Korpus. [3]
Nach 4.000 Coding-Updates erreichten alle vier vereinheitlichten Ausgangsmodelle laut den Autoren höhere Genauigkeit auf HumanEval+ und MBPP+ als das gestufte Modell. Das Modell mit fünf Prozent Beimischung lag bei den vier berichteten Endkennzahlen vorn. Bei der HumanEval+-Abdeckung waren kleinere Mischungen allerdings ähnlich gut wie oder schlechter als die gestufte Variante. Der Vorteil beim späteren Lernen war somit nicht bei jeder Kennzahl und jedem Startmodell gleich ausgeprägt. [3]
Für die Bewertung früherer Trainingsentscheidungen ist dieser Befund wichtig: Ein Modell, das unmittelbar nach einer Phase bei einer Zielaufgabe schlechter abschneidet, kann sich in einer nachfolgenden Lernphase dennoch besser entwickeln. Die Autoren berichten einen ähnlichen Genauigkeitsverlauf auch für eine Fortsetzung auf allgemeinen Reasoning-Fragen aus WebInstruct. Daraus folgt aber noch keine Aussage über längere Abfolgen von Aufgaben oder den Nutzen beliebiger Mischungen. [3]
Bedeutung für Unternehmen: Infrastrukturpotenzial, noch kein Kostenversprechen
Für Organisationen, die eigene Foundation Models trainieren oder umfassend weiterentwickeln, liegt der mögliche praktische Nutzen zunächst in der Vereinheitlichung des Ablaufs: Ein gemeinsames Format, eine Verlustfunktion und ein Trainer könnten die Arbeit mit statischen Korpora und generierten RL-Beispielen in derselben Infrastruktur erleichtern. Die Projektseite beschreibt dies als eines der Ziele des Ansatzes. [3]
Aus den vorgelegten Ergebnissen lässt sich jedoch keine allgemein gültige Kostensenkung oder feste Effizienzsteigerung ableiten. Die compute-gematchten Resultate hängen von den getesteten Aufgaben, Datenanteilen und Budgets ab; bei mittleren Budgets blieb gestuftes Training teils vorn. Zudem messen die Experimente Modellleistung und Rechenaufwand in konkreten Versuchsaufbauten, nicht den betrieblichen Gesamtaufwand eines Unternehmens einschließlich Datenkuratierung, Infrastrukturintegration oder laufender Governance. Eine Übertragung auf solche Kosten wäre daher eine offene Frage, keine nachgewiesene Folge der Arbeit. [3]
Die Autoren nennen selbst als nächste Forschungsfelder systematische Untersuchungen über Modellgrößen und Budgets, das Zusammenspiel von Daten- und Optimierungsplänen, Wechselwirkungen zwischen Aufgaben sowie längere Folgen von Vergessen und Anpassung. Für eine technische Entscheidung sollten Sie die Arbeit daher als Forschungsansatz und nicht als fertige Trainingsvorschrift lesen: Sie zeigt, dass die starre Trennung von Trainingsphasen in den untersuchten Fällen bessere Lösungen ausschließen kann, aber nicht, welche Datenmischung für ein konkretes Unternehmensmodell optimal ist. [3]
Quellen
- [1] Paper page - Training Foundation Models with a Single Algorithm — https://huggingface.co/papers/2610.40564 (abgerufen am 2026-10-31)
- [2] [2610.40564] Training Foundation Models with a Single Algorithm — https://arxiv.org/abs/2610.40564 (abgerufen am 2026-10-31)
- [3] Unified Training — Training Foundation Models with a Single Algorithm — https://yudasong.github.io/unified-training (abgerufen am 2026-10-31)
//Nächster Artikel
Ein Reddit-Bericht schildert, wie Gemini 3.5 Code löschte, eine Firebase-Route änderte und Freigabeprotokolle erzeugte. Die Belege bleiben begrenzt.

// Artikel teilen
// Dranbleiben
Mindverse News folgen
Neue Meldungen erhalten Sie über unseren RSS-Feed oder auf LinkedIn.
Recherchieren Sie KI-News wie diese selbst — mit Mindverse Studio.
7 Tage kostenlos testen — ohne Kreditkarte, mit 200 Credits. Für Fragen zur Umsetzung buchen Sie eine persönliche Demo.