Berichte über OpenAIs Modell Astra sorgen in der KI-Szene für Aufsehen. Sie erwähnen eine neuartige „Recurrent Depth“-Architektur oder einen „Looped Transformer“. Die Grundidee ist weder brandneu noch ein Geheimnis aus dem Hause OpenAI. Nanbeige 4.2, ein offenes Modell, veröffentlichte die technischen Details vor etwa zwei Monaten und nutzt genau diesen Ansatz. Die Beschreibung „Nanbeige4.2-3B ist von Grund auf mit 28 Billionen Tokens trainiert und verwendet einen Looped Transformer, der den Layer-Stack wiederverwendet, um die Kapazität ohne zusätzliche Parameter zu erhöhen“, fasst das Prinzip knapp zusammen. Weil viele Halbwahrheiten kursieren, lohnt ein genauer Blick auf die Architektur.
Was ein Looped Transformer technisch macht
Die Grundidee ist einfach: Statt einen Stapel Transformer-Layers einmal zu durchlaufen, wird derselbe Stapel mehrfach auf die Daten angewendet. Bei Nanbeige 4.2 umfasst der Kern 22 Transformer-Layers. Üblicherweise durchlaufen Eingabetokens den Stapel genau einmal. Im Looped-Design sind es zwei Durchläufe, also effektiv 44 Layer. Die Gewichte werden dabei nicht dupliziert.
Das hat zwei Konsequenzen, die oft verwechselt werden. Erstens bleibt der Speicherbedarf nahezu gleich, weil keine Parameter hinzukommen. Zweitens verdoppeln sich die Rechenkosten, weil pro Token doppelt so viele Layer-Berechnungen anfallen. Wer einen Looped Transformer für eine kostenlose Kapazitätssteigerung hält, liegt falsch. Es ist ein Trade-off: Speicher sparen, Rechenzeit investieren.
Die Nanbeige-Forscher fanden, dass zwei Durchläufe den optimalen Punkt darstellen. Mehr Durchläufe brachten kaum messbare Qualitätsgewinne, verlängerten aber das Training und trieben den Rechenaufwand in die Höhe. Zwei Passes erreichten rund 75 Prozent der Token-Effizienz eines klassischen, tieferen Modells. Das klingt nach einem Kompromiss. In der Praxis ist es oft attraktiv, weil Deployments meist unter Speicher- und Latenzbeschränkungen leiden, nicht unter Trainingsbudgets.
Herkunft: Mixture-of-Recursions und die Wurzeln der Idee
Die Idee, denselben Layer-Stapel mehrfach zu verwenden, ist älter als Nanbeige. Das NeurIPS-Papier „Mixture-of-Recursions: Learning dynamic recursive depths for adaptive token-level computation“ formulierte den Grundgedanken und entwickelte ihn weiter. Statt jeden Token gleich oft durch den Loop zu schicken, lernt ein kleines Routing-Modul pro Token, wie viele Durchläufe nötig sind. Einfache Tokens verlassen den Stapel früh, schwierige Tokens erhalten zusätzliche Recursion-Durchläufe.
Diese dynamische Variante ist flexibler als ein starrer Loop mit fester Wiederholungszahl. Sie passt die Rechenkosten an die Schwierigkeit jedes Tokens an. Ein Satz wie „Hallo, wie geht es dir?“ benötigt weniger Recursion als eine mehrstufige mathematische Herleitung. Das ist keine simple Verdopplung der Tiefe, sondern ein fein einstellbares Rechenbudget.
Nanbeige 4.2 nutzt derzeit einen festen Faktor von zwei und verzichtet auf adaptives Routing. Das hält die Implementierung einfach und die Trainingspipeline vorhersagbar. Allerdings entgeht ihm so der Effizienzgewinn, den Mixture-of-Recursions verspricht.
Astra, Recurrent Depth und die Aussage zur Chain-of-Thought
Zur eigentlichen Kontroverse: In Berichten über Astra heißt es, die neue Technik mache das Chain-of-Thought-Reasoning unsichtbar. Wer mit Modellen arbeitet, die vor der Antwort explizite Gedankenschritte generieren, kann diese mitlesen und steuern. Die neue Architektur, so die Behauptung, verschleiere diesen Zwischenschritt.
So pauschal ist das nicht haltbar. Ein Looped Transformer macht Chain-of-Thought nicht unsichtbar. Was tatsächlich passiert: Mehr Recursion-Durchläufe verlagern einen Teil der Verarbeitung in die internen Hidden States. Diese Aktivierungen existieren, werden aber nicht als Text ausgegeben. Mehr Berechnung in den Hidden States heißt: Es sind weniger explizite Reasoning-Tokens nötig, um zur gleichen Antwort zu kommen.
Derselbe Effekt tritt auf, wenn man ein klassisches Transformer-Modell einfach tiefer skaliert. Vergleicht man GPT-Modelle unterschiedlicher Größe, braucht das größere weniger sichtbare Zwischenschritte, weil es pro Layer mehr Denkleistung erbringt. Das ist keine neue Eigenschaft von Looped Transformers, sondern ein generelles Muster beim Skalieren.
Wahrscheinlich vermengen Journalistinnen und Journalisten zwei Dinge: die Recurrent-Depth-Architektur und einen unabhängigen Effekt, der bei jeder Form gesteigerter Berechnung auftritt. Recurrent Depth mag bei Astra eine Rolle spielen. Warum Chain-of-Thought kürzer wirkt, erklärt allein das nicht.
Speicher versus Rechenzeit: der Trade-off
Ein häufiges Missverständnis betrifft den Unterschied zwischen Modellgröße und Rechenaufwand. Ein Looped Transformer spart VRAM, weil die Gewichte nur einmal vorliegen. Das ist nützlich für Self-Hosting, Edge-Deployment und Szenarien, in denen Speicher der limitierende Faktor ist. In Cloud-Setups mit H100-Clustern wiegt dieser Vorteil weniger, weil dort oft die Rechenzeit der knappe Faktor ist.
Was ist dann der strategische Sinn? OpenAI, Mistral und andere Anbieter betreiben riesige GPU-Farmen, Speicher ist dort relativ günstig. Warum also auf Looped Transformer setzen? Eine Erklärung: Astra soll auch auf Endgeräten laufen, und dort ist Speicher knapp. Eine andere: Kleinere Modelle laden schneller und ermöglichen so eine Latenz-Optimierung.
Für alle, die Modelle selbst betreiben: Ein Looped Transformer ist kein Allheilmittel, sondern eine Designentscheidung mit klaren Kompromissen. Wer Speicher sparen muss und etwas mehr Rechenzeit investieren kann, profitiert. Wer Rechenzeit optimieren muss, fährt mit einem klassischen tieferen Modell besser.
Was bleibt von der Aufregung
Was Astra wirklich leistet, hängt von Trainingsdaten, Alignment und Gesamtarchitektur ab. Recurrent Depth ist ein Baustein von vielen, nicht der revolutionäre Kern. Wer die Berichterstattung verfolgt, sollte drei Dinge auseinanderhalten: die Architekturinnovation, die sichtbare Chain-of-Thought und die Frage, wie viel Reasoning in den Hidden States geschieht.
Die Looped-Transformer-Idee ist keine Erfindung von OpenAI. Nanbeige 4.2 hat sie kürzlich in einem offenen Modell demonstriert. Mixture-of-Recursions lieferte die theoretischen Grundlagen. Astra setzt vermutlich eine leistungsfähige Variante ein, aber die zugrundeliegende Mechanik ist verstanden.
Für Entwicklerinnen und Entwickler, die mit KI-Modellen arbeiten, heißt das: Lasst euch nicht vom Hype blenden. Prüft, ob die Architektur zu eurem Use Case passt, ob der Speichervorteil den Rechenzeitnachteil aufwiegt und ob das Modell hält, was Schlagzeilen versprechen. Entscheidend ist die Leistung in der konkreten Anwendung, nicht die Architekturbezeichnung auf dem Papier.
Quelle: sebastianraschka.com
