Ein Ingenieur beobachtet an einem Dienstagmorgen ein Diagramm, in dem eine Speicherkurve langsam nach oben wandert. Jeder neue Token, den das Sprachmodell ausgibt, legt eine weitere Zeile in einem Zwischenspeicher ab, irgendwann ist die Linie so steil, dass die Batch-Größe halbiert werden muss. Das ist der Preis einer Architektur, die bei jedem Schritt auf die gesamte bisherige Geschichte zurückgreift. Hier setzt eine Arbeit an: Recurrent Looped Transformer.
Wer sich mit Sprachmodellen beschäftigt, kennt das Muster: Ein Transformer verarbeitet eine Sequenz in fester Tiefe. Jeder Token läuft durch dieselbe Anzahl von Blöcken, das Kontextwissen liegt in einem KV-Cache, der mit jedem Schritt wächst. Der Recurrent Looped Transformer dreht daran. Er trennt die Arbeit in zwei Teile: einen kausalen Encoder, der bekannten Text in einem Zug verarbeitet, und einen rekurrenten Decoder, der seinen eigenen Zustand von Token zu Token weiterträgt. Das klingt nach einem kleinen Umbau. Es ist keiner.
Rekurrenter Decoder: ein Zustand, der an der Serving-Grenze nicht zurückgesetzt wird
Der Encoder arbeitet wie ein Archiv, das in einem Durchgang aufgebaut wird. Weil der bekannte Text vollständig vorliegt, lassen sich seine Schlüssel-Wert-Paare in einem kausalen Batch berechnen. Das Ergebnis ist ein globaler Speicher, aus dem der Decoder später schöpft. Eine Einschränkung bleibt: Der Encoder-Speicher ist präfixbeschränkt, ein Token sieht also nur Positionen, die vor ihm liegen.
Der Decoder dagegen ist ein Notizbuch, das von Hand zu Hand wandert. Er trägt zwei Dinge über jeden Token hinweg: seinen eigenen rekurrenten Ausgangszustand und den KV-Cache seiner Sliding-Window-Attention. Jede SWA-Schicht liest nur ihre eigenen jüngsten Schlüssel und Werte; ein Fenster von n Einträgen enthält den aktuellen Token und behält höchstens n-1 historische Einträge für den nächsten Schritt. Der vorherige Ausgang geht in die folgende Zusammenführung ein. Nichts davon wird an der Grenze zwischen Prompt und Antwort zurückgesetzt. Beide teilen sich einen Zustandsübergang.
Daraus entsteht eine Art latentes Reasoning durch die rekurrente Decoder-Architektur, nicht durch Prompting. Das Modell muss den Zwischenstand seiner Überlegung nicht bei jedem Schritt neu aus dem Text rekonstruieren, weil dieser Zustand selbst weiterläuft. Jeder neue Token verlängert den Pfad durch den vollständigen Decoder. Nach n Tokens läuft die Rechnung durch n mal 48 Decoder-Blöcke, die Zahl der Blöcke pro Token bleibt konstant. Der Pfad wächst mit der Sequenz, die Arbeit pro Schritt nicht.
Drei Designprinzipien: wachsende Tiefe, Hardware, Reinforcement Learning
Das erste Prinzip ist die zeitliche Tiefe. Ein rekurrenter Transformer mit unbegrenzter zeitlicher Tiefe klingt spektakulärer, als er gemeint ist. Gemeint ist ein erweiterbarer zeitlicher Pfad, nicht unendlich viel Arbeit innerhalb eines Tokens. Die Rechenlast pro Token bleibt fest, die Tiefe des Pfades wächst mit der Länge der Sequenz. Diese Trennung erklärt, warum die Architektur überhaupt mit heutiger Hardware diskutierbar ist.
Das zweite Prinzip ist Modell-Hardware-Co-Design. Um einen rekurrenten Kern herum lässt sich vieles parallel erledigen: Encoder-Arbeit für bekannte Token, unabhängige Decoder-Aktualisierungen, Sequenz-Batching. Gewichte und Speicher werden wiederverwendet, Aktivierungen lassen sich checkpointen, solange die Referenzrechnung unangetastet bleibt. Der Kern bleibt sequenziell, die Umgebung nicht. Diese Aufteilung entscheidet, ob eine solche Architektur auf realen Beschleunigern mehr kostet, als sie einbringt.
Das dritte Prinzip verbindet Modell und Lernverfahren. Sampling und Replay sollen denselben Übergang benutzen. Beim Current-Policy-Replay für Reinforcement Learning wird die vollständige Historie unter den aktuellen Parametern neu aufgebaut, einschließlich der Prompt-Zustände und des Decoder-SWA-KV. Die aufgezeichneten Verhaltenswahrscheinlichkeiten müssen an den tatsächlichen Sampler gebunden bleiben. Sonst beschreibt die Rechnung ein Modell, das so nie gelaufen ist.
Ein vollständiger Zustandsübergang für Prefill, Generierung, Pretraining, SFT und Replay
Die Arbeit listet fünf Betriebsarten auf, in denen dieselbe Übergangslogik gilt. Beim Prompt-Prefill läuft der Encoder als kausaler Batch, während der Decoder den kompletten Zustand durch jeden Prompt-Token aktualisiert. In der Generierung wird inkrementell gearbeitet: Aus dem vorangehenden Zustand wird gesampelt, danach wird jeder Token genau einmal konsumiert. Beim Pretraining läuft der Encoder wieder als Batch, diesmal mit vollständigem Backpropagation Through Time über alle gültigen Next-Token-Ziele. Beim SFT gilt eine Verlustfunktion auf die Assistant-Ziele, wobei alle Kontext-Token einen differenzierbaren Zustand aktualisieren. Beim Current-Policy-Replay schließlich wird die Historie mit den aktuellen Gewichten neu aufgebaut und jede Aktion bewertet, bevor sie konsumiert wird.
Der Punkt dieser Vereinheitlichung ist unspektakulär: Wenn Training und Auslieferung denselben Übergang benutzen, verschwindet die strukturelle Lücke zwischen Prompt-Grenze und Antwort-Grenze. Es bleibt kein Ort, an dem das Modell während des Trainings anders rechnet als später im Betrieb. Das garantiert keine korrekten Zahlen, ist aber die Voraussetzung dafür, dass Abweichungen als Abweichungen auffallen.
Warum ein alter KV-Cache beim Current-Policy-Replay nicht mehr stimmt
Sobald sich Parameter ändern, werden alte Caches für ein exaktes Replay unter aktueller Policy ungültig. Wer einen gespeicherten Zwischenstand aus einem früheren Lauf einfach weiterverwendet, rechnet mit einem Zustand, den das aktuelle Modell nie erzeugt hätte. Deshalb muss die vollständige Historie neu durchlaufen werden, inklusive der rekurrenten Ausgaben und der schichtweisen Decoder-Caches. Erst dann beschreiben die Verhaltens-Log-Wahrscheinlichkeiten die Verteilung, aus der tatsächlich gesampelt wurde. Für exaktes Importance Sampling kommt eine zweite Bedingung hinzu: Die Trägerverteilung muss abgedeckt sein.
Von dieser Frage zu trennen ist der Gradientenfluss. Vorwärtskonsistenz und vollständige Gradienten sind zwei verschiedene Anforderungen, die man leicht verwechselt. Vollständiges BPTT enthält Pfade durch die rekurrenten Ausgaben, durch den Decoder-KV und durch den Encoder-Speicher. Trennt man einen dieser Pfade ab, ändert sich der Gradient, still und ohne Fehlermeldung. Solche Architekturen verlangen beim Training deshalb mehr Sorgfalt als im reinen Inferenzbetrieb.
Was danach übrig bleibt, sind eigene Baustellen: die numerische Parität zwischen verschiedenen Kernels und die Off-Policy-Schätzung selbst. Auch der Unterschied zwischen Prefill- und Decode-Kernels gehört dazu. Das sind keine Nebensächlichkeiten, sondern die Stellen, an denen eine saubere Architekturidee in der Praxis Rauschen erzeugt.
48 plus 48 Layer: was die konkrete Konfiguration über die Rechnung verrät
Die beschriebene Konfiguration nennt 48 Encoder-Layer und 48 Decoder-Layer, wobei kompatible Attention- und FFN-Gewichte über die Stufen hinweg geteilt werden. Geteilte Gewichte bedeuten Speicherersparnis und eine andere Rechnung, als sie ein Modell mit 96 unabhängigen Blöcken hätte. Pro Token werden 96 logische Blöcke ausgeführt. Weil im Decoder Cross-Attention dazukommt, sind diese Blöcke allerdings nicht gleich teuer: Ein Block mit Zugriff auf den Encoder-Speicher kostet mehr als einer ohne. Die Zahl 96 beschreibt also eine Struktur, nicht einen FLOP-Wert.
Hier wird Modell-Hardware-Co-Design für Transformer konkret. Parallelisierbare Encoder-Arbeit, sequenzielle Decoder-Schritte, Speicherwiederverwendung und Checkpointing greifen ineinander. Ob am Ende mehr herauskommt als bei einem klassischen Aufbau, hängt weniger an der Architektur als an der Frage, wie gut diese Teile auf der vorhandenen Hardware zusammenarbeiten. Die Arbeit selbst bleibt vorsichtig und nennt den Hardware-Wirkungsgrad als offene Größe.
Was damit belegt ist und was offen bleibt
Der Autor formuliert seine Erwartungen nüchtern: Reale Gewinne beim Reasoning, Effizienzvorteile auf der Hardware und Skalierung im Reinforcement Learning stehen noch nicht fest. Für ein Papier, das drei Prinzipien und eine vollständige Ausführungsbeschreibung vorlegt, ist das ungewöhnlich offen. Man bekommt keinen Benchmark-Sieg, sondern einen Bauplan mit konsistenter Rechengeschichte, inklusive der Stellen, an denen die Rechnung weh tut.
Für dich heißt das: Wenn du Inferenz-Infrastruktur baust, lohnt der Blick auf die Idee eines einzigen vollständigen Zustandsübergangs, der Prompt und Antwort nicht auseinanderreißt. Wenn du mit Reinforcement Learning arbeitest, ist der Hinweis auf ungültig werdende Caches nach Parameterupdates auch unabhängig von dieser Architektur relevant. Und wenn du wissen willst, ob rekurrente Decoder mit Sliding-Window-Attention klassische Transformer ablösen, musst du auf Zahlen warten. Es gibt einen Entwurf, aber noch keinen Beweis.
Quelle: yifanzhang-pro.github.io
