Das neue Architekturmodell HRM-Text bricht Rekorde: Mit 1 Milliarde Parametern und einer Kosten von nur 1000 USD hat sich sogar ein Turing-Preisträger persönlich daran beteiligt.
Ein Modell mit etwa 1 Milliarde Parametern erreichte auf MATH 56,2, auf GSM8K 84,5 und auf ARC-Challenge 81,9. Die Trainingskosten beliefen sich auf etwa 1.500 US-Dollar, und es wurden 16 H100-Grafikkarten weniger als zwei Tage lang betrieben.
Dies ist das am 18. Mai 2026 von Sapient Intelligence veröffentlichte HRM-Text. Das Team hat gleichzeitig die Forschungsarbeit, die Modellgewichte und den Code für das Pre-Training veröffentlicht.
Wenn man nur diese Zahlen betrachtet, könnte die intuitive Reaktion sein: Ist dies möglicherweise das Ergebnis einer Feinabstimmung? Steht man auf den Schultern von Riesen, ist es natürlich leichter.
HRM-Text ist jedoch nicht so. Es wurde von Grund auf neu trainiert und nutzte nur etwa 40 Milliarden eindeutige Token (nach Berücksichtigung der wiederholten Stichprobenahme wird die Gesamtmenge an trainierten Token in der Experimenttabelle auf etwa 60 Milliarden Token geschätzt), was etwa 1/225 der Trainingsmenge von Llama 3.2 3B (9 Billionen Token) und 1/900 der Trainingsmenge von Qwen3.5 2B (36 Billionen Token) entspricht.
Vergleich von HRM-Text mit anderen Modellen in Bezug auf Trainings-FLOPs, trainierte Token und Benchmarks.
Die Frage stellt sich natürlich: Wie ist das möglich?
In den letzten Jahren hat sich in der Branche der großen Modelle eine fast standardmäßige Wachstumslogik entwickelt: Je größer das Modell, desto mehr Daten und desto stärker die Rechenleistung, desto höher wird die Intelligenzfähigkeit.
Dieser Ansatz hat sich als effektiv erwiesen. Die kontinuierliche Weiterentwicklung von Modellen wie GPT, Claude, DeepSeek und Qwen hängt von der Erweiterung der Parametergröße, der Datenmenge und der Trainingsrechenleistung ab. Gleichzeitig wird das Training von Basis-Modellen immer mehr zu einer Schwerindustrie: längere Trainingszyklen, teurere GPU-Clustern, komplexere Daten-Engineering-Prozesse und immer höhere Einstiegshürden.
HRM-Text möchte jedoch einen anderen Ansatz verfolgen: Kann man bei begrenzten Daten und begrenzter Rechenleistung durch eine gemeinsame Gestaltung von Architektur und Trainingsziel die Effizienz jeder einzelnen Berechnung verbessern?
Der Titel der Forschungsarbeit gibt direkt an, welche Richtung es zu meistern versucht: Efficient Pretraining Beyond Scaling.
- Titel der Forschungsarbeit: HRM-Text: Efficient Pretraining Beyond Scaling
- Link zur Forschungsarbeit: https://arxiv.org/abs/2605.20613
- GitHub: https://github.com/sapientinc/HRM-Text
- Hugging Face: https://huggingface.co/sapientinc/HRM-Text-1B
- X Launch post: https://x.com/Sapient_Int/status/2056510383935172798
Einfach ausgedrückt, hat HRM-Text sowohl die Art der Berechnung als auch das zu lernende Material des Modells angepasst: Einerseits führt es mehrere interne Berechnungsschritte mit begrenzten Parametern durch, um die effektive Rechentiefe zu erhöhen; andererseits berechnet es den Verlust nur für die Antwortteile, um das Trainingssignal stärker auf das Verständnis der Aufgabe und die Generierung von Antworten zu konzentrieren.
Es ist wichtig zu beachten, dass HRM-Text kein fertiges Chat-Modell ist, das bereits Post-Training oder Optimierung durch Reinforcement Learning durchlaufen hat. Das Team definiert die aktuelle Version als Proof of Concept: Ihr Wert liegt nicht darin, die endgültige Form eines Sprachmodells zu finden, sondern darin, ein überprüfbares Beispiel zu liefern, das zeigt, dass es immer noch viel Raum für architektonische Innovationen bei der Effizienz des Pre-Trainings von Basis-Modellen gibt.
Mehrere interne Berechnungsschritte vor einer Ausgabe
Die erste Veränderung bei HRM-Text besteht in der Neuorganisation des internen Berechnungsprozesses des Modells.
Ein Standard-Transformer besteht normalerweise aus einer Reihe von Netzwerkebenen mit voneinander unabhängigen Parametern. Die Eingabe wird entlang der Tiefe des Modells weitergeleitet: Sie durchläuft die erste Ebene, dann die zweite und so weiter, bis schließlich die Ausgabe erzeugt wird. Ein direkter Weg, die Fähigkeiten des Modells zu verbessern, besteht darin, mehr Ebenen zu stapeln, die versteckte Dimension zu erhöhen oder mehr Parameter zu trainieren.
HRM-Text folgt nicht einfach diesem Ansatz. Es führt zwei Module ein, die auf unterschiedlichen Zeitskalen funktionieren: das Hochschichtmodul H und das Tiefschichtmodul L.
Eine anschaulichere Analogie: Ein Standard-Transformer ist wie ein Prozess, bei dem ein Material nacheinander an mehrere verschiedene Redakteure weitergegeben wird, die jeweils einmal bearbeiten und es dann weiterleiten; HRM-Text hingegen ist wie ein Prozess, bei dem zwei Gruppen von Redakteuren dasselbe interne Entwurfsmaterial wiederholt bearbeiten. Das Modell erhöht nicht einfach die Anzahl der Parameter, sondern lässt begrenzte Parameter an tieferen effektiven Berechnungen teilnehmen.
Laut den Erklärungen in einem Interview mit dem Team unterscheidet sich diese Designentscheidung auch von den gängigen "Großhirn-Kleinhirn"-Kollaborationslösungen in der Branche. Letztere trainieren normalerweise zwei Modelle unterschiedlicher Größe getrennt voneinander, wobei das große Modell für komplexe Planung und das kleine Modell für schnelle Ausführung zuständig ist. Die Modelle tauschen Informationen hauptsächlich über textuelle Schnittstellen aus.
Die Module H und L von HRM gehören jedoch demselben Netzwerk. Sie sind keine zwei unabhängigen Modelle und tauschen keine Aufgaben über den Textraum aus, sondern iterieren wiederholt denselben internen Zustand in demselben latenten Raum. Welche Informationen zwischen den Modulen übertragen werden und wie die Arbeit aufgeteilt wird, wird durch einen einheitlichen Optimierungsprozess gemeinsam bestimmt.
Genauer gesagt, integriert HRM nicht einfach einen Planer und einen Ausführungsmechanismus außerhalb des Modells, sondern baut die schichtweise Berechnung direkt in ein einzelnes Modell ein.
Das Tiefschichtmodul wird schneller aktualisiert und übernimmt lokale Berechnungen und iterative Korrekturen; das Hochschichtmodul wird langsamer aktualisiert, erhält einen stabileren semantischen Kontext und bietet langfristigere Beschränkungen für die Tiefschichtberechnungen. Gemäß der Festlegung in der Forschungsarbeit werden bei jeder Vorwärtsausbreitung zwei Hochschichtzyklen durchgeführt. In jedem Zyklus werden zunächst drei Aktualisierungen des L-Moduls und dann eine Aktualisierung des H-Moduls durchgeführt.
Das bedeutet, dass das Modell vor der Vorhersage eines Tokens 8 rekursive Aktualisierungen durchführt: 6 Tiefschichtaktualisierungen und 2 Hochschichtaktualisierungen.
Rekursive Struktur mit doppelter Zeitskala H/L, interne Struktur der Module und PrefixLM-Attentionsmaske.
Hier ist zu betonen, dass "mehrere interne Berechnungsschritte" nicht bedeutet, dass das Modell in der Lage ist, die Denkzeit dynamisch an die Schwierigkeit der Aufgabe anzupassen. Die aktuelle Version verwendet einen festen Rekursionsplan: Unabhängig davon, ob die Aufgabe einfach oder komplex ist, führt das Modell die internen Aktualisierungen gemäß der voreingestellten Anzahl aus. Adaptive Rechenzeiten werden in zukünftigen Untersuchungen erforscht.
Dies bedeutet auch, dass 1 Milliarde Parameter nicht gleichbedeutend mit einer identischen Inferenzkosten wie bei einem normalen 1-Milliarden-Dense-Transformer sind. Die rekursive Aufrufung erhöht die Parameterausnutzung, erhöht aber auch die serielle Rechenmenge vor der Ausgabe jedes Tokens. Daher müssen die Parametergröße, die Trainingskosten und die tatsächliche Inferenzeffizienz separat betrachtet werden.
Dieser Ansatz hat auch seine Kosten.
Je tiefer die interne Schleife, desto mehr Möglichkeiten hat das Modell, seine Repräsentation kontinuierlich zu korrigieren. Doch nach wiederholtem Aufrufen derselben Module kann die Varianz der Aktivierungswerte stetig ansteigen, und die Gradienten neigen stärker dazu, zu verschwinden oder explodieren. Die rekursive Architektur ist kein neues Konzept. Die eigentliche Herausforderung besteht darin, wie man eine tiefe Rekursion in offenen Sprachaufgaben stabil trainieren kann.
HRM-Text führt daher zwei Designentscheidungen ein: MagicNorm und warmup deep credit assignment.
Das Ziel von MagicNorm ist es, gleichzeitig die Stabilität der Vorwärts- und Rückwärtsausbreitung zu gewährleisten. Innerhalb des Moduls bleibt die PreNorm-Struktur, die für den Gradientenfluss vorteilhaft ist, erhalten. Am Ende jedes Rekursionsmoduls wird jedoch zusätzlich eine Normalisierung durchgeführt. Dadurch kann sowohl das Wachstum der Varianz der Aktivierungswerte in wiederholten Schleifen begrenzt als auch ein reibungsloser Gradientenpfad möglichst aufrechterhalten werden.
Warmup deep credit assignment steuert, wie weit der Gradient zurückverfolgt werden muss. Zu Beginn des Trainings wird der Gradient nur für die letzten beiden Rekursionsschritte zurückpropagiert. Mit zunehmender Stabilität des Trainings wird der Rückpropagationsbereich linear auf die letzten fünf Schritte erweitert.
Dies kann als eine schrittweise "Verantwortlichkeitszuweisung" verstanden werden: Zu Beginn des Trainings wird das Modell zunächst für die letzten internen Berechnungsschritte in der Nähe der Ausgabe verantwortlich gemacht. Nach der Stabilisierung werden die früheren Berechnungsschritte schrittweise auch zur Verantwortung gezogen. Auf diese Weise kann die tiefere rekursive Berechnung genutzt werden, und es kann verhindert werden, dass das Modell von Anfang an einem zu langen Gradientenpfad ausgesetzt ist.
Die Forschungsarbeit analysiert auch diese Struktur aus der Perspektive der effektiven Tiefe.
In einem Standard-Transformer oder in einigen looped Transformer-Modellen kann die Veränderung des versteckten Zustands in späteren Ebenen mit zunehmender Anzahl der Ebenen allmählich abnehmen, und das Modell neigt frühzeitig zu einer relativ stabilen Ausgabeverteilung. Die Analyse von HRM-Text zeigt jedoch, dass seine tiefen Berechnungen immer noch deutliche Veränderungen in der Repräsentation aufweisen. Dies bedeutet, dass die rekursiven Schritte nicht einfach wiederholt werden, sondern dass das interne Zustand weiterhin modifiziert wird und tiefere Berechnungsschritte immer noch zusätzliche Informationen liefern können.
Vergleich der effektiven Tiefe verschiedener Architekturen.
Weniger Vorhersagen, mehr Fokus auf die Antwort
Abgesehen von der architektonischen Veränderung hat sich HRM-Text auch bei den Pre-Trainingszielen verändert.
Die meisten Sprachmodelle verwenden die autoregressive "Vorhersage des nächsten Tokens": Gegeben ein Text, wird der nächste Token vorhergesagt. Unabhängig davon, ob die Eingabe eine Webseite, ein Buch, eine Forenantwort oder Code ist, muss das Modell lernen, jede Position in der Sequenz fortzusetzen. Dieses Ziel ist sehr universell, bedeutet aber auch, dass eine große Menge an Trainingssignalen für die Vorhersage von Texten verwendet wird, die nur wenig mit der Aufgabe zu tun haben.
HRM-Text wählt einen gezielteren Ansatz: Es überspringt die Phase des Pre-Trainings mit großen Mengen an Rohtext und trainiert direkt mit "Befehl - Antwort"-Daten von Grund auf neu. Gegeben ein Befehl und die entsprechende Antwort, berechnet das Modell nur den Token-Level-Verlust für die Antwortteile.
Dies bedeutet nicht, dass der Befehlsteil überhaupt nicht an der Lernphase beteiligt ist. Der Antwortverlust beeinflusst weiterhin über den Attentionspfad, wie das Modell den Befehl versteht und nutzt. Das Modell muss jedoch nicht mehr die "Vorhersage der Frage selbst" übernehmen, sondern konzentriert das Aktualisierungssignal stärker auf die Generierung passender Antworten.
Eine anschaulichere Analogie: Wenn ein Lehrer eine Prüfung korrigiert, bewertet er nicht mehr die "Aufgabenstellung", sondern nur die Antworten.
Dem "Nur-Antwort-Ziel" entspricht die PrefixLM-Maske. In der Standard-Causal-Maske kann jeder Token nur den Inhalt vor sich selbst sehen. Diese Designentscheidung eignet sich gut für die Links-nach-Rechts-Generierung, ist aber für einen vollständig vorgegebenen Befehl nicht unbedingt erforderlich.
HRM-Text erlaubt es, dass die Tokens im Befehlsteil sich gegenseitig bidirektional sehen können. Beim Übergang zur Antwort wird dann die Standard-Causal-Generierung wiederhergestellt.
Das Modell kann somit zunächst den gesamten Befehl als vollständigen Kontext integrieren und dann schrittweise die Antwort generieren. In der Implementierung mit nur einem Decoder erhält es eine Art Encoder-Decoder-Aufteilung: Die Befehlsseite ähnelt eher einem Encoder, die Antwortseite eher einem Decoder.
Die Attentionsanalyse in der Forschungsarbeit zeigt, dass die PrefixLM im Vergleich zur reinen Causal-Maske eine höhere Attentionsentropie und ein globaleres und vielfältigeres Attentionsmuster aufweist. Es handelt sich nicht nur um eine Änderung einer Maske, sondern um eine Verbesserung der Art und Weise, wie das Modell die Befehlsinformationen nutzt.
