BLOG
Technische Analyse 009|RLT: Dem Transformer eine Zeitschleife geben, latente Variablen-Inferenz und das wahre Gesicht der 'unendlichen zeitlichen Tiefe'
Technische Analyse: KI-Technologie-Frameworks entschlüsseln – Erklärung, Analyse, technische Bewertung, Werturteil und praktischer Einsatz. Autor: Yongliang
Der Transformer hat eine selten direkt betrachtete Einschränkung: Egal wie lang die Sequenz ist, die Anzahl der Schichten, die ein einzelner Token passiert, bleibt unverändert. Wenn die Sequenz von 100 Token auf 100.000 ansteigt, bleibt die Berechnungstiefe eines einzelnen Token völlig unberührt – das Modell wird „breiter”, aber nicht „tiefer”. Im September 2026 veröffentlichte Yifan Zhang einen technischen Bericht über den Recurrent Looped Transformer (RLT), der vorschlägt, die Tiefe aus der Anzahl der Schichten zu befreien: Mit einem über Token hinweg zirkulierenden latenten Variablenzustand soll der „effektive Berechnungspfad” mit dem Wachstum der Sequenz verlängert werden. Er nennt diese Eigenschaft infinite temporal depth – unendliche zeitliche Tiefe. Nur drei Tage nach der Erstellung des Repositorys hatte es bis September 2026 bereits etwa 743 Sterne und 77 Forks erhalten. Dieser Artikel analysiert sechs Aspekte: Was es ist, die Kernmechanik bis hin zur Definition von Zustand und Cache, die technische Bewertung, ob es sich lohnt, ihm zu folgen, wie es in der Praxis eingesetzt wird, und – falls du selbst einen minimalistischen rekursiven Feedback-Transformer schreiben möchtest, wie das minimale Grundgerüst aussieht.
1. Was ist das?
Kurzbeschreibung: RLT (Recurrent Looped Transformer) ist ein Forschungsprojekt im Stil eines wissenschaftlichen Papiers. Die Kernbehauptung lautet “latent reasoning with infinite temporal depth” – durch latentes Schließen wird ein effektiver Berechnungspfad gewonnen, der sich mit der Sequenz unendlich verlängert, anstatt Tiefe durch das Stapeln von Schichten zu erreichen.
Zunächst die wichtigsten Fakten. Das Repository yifanzhang-pro/recurrent-looped-tranformer (beachten Sie, dass der Repository-Name tatsächlich tranformer lautet – die ursprüngliche Schreibweise ohne ein s), Autor Yifan Zhang, Einzelautoren-Bericht, veröffentlicht im September 2026, der Repository-Inhalt ist unter der Apache-2.0-Lizenz quelloffen. Stand September 2026 ca. 743 Sterne, 77 Forks, erstellt am 12. September 2026 – vor drei Tagen. GitHub kennzeichnet die Hauptsprache dieses Repositories als HTML, da der Hauptbestandteil des Repositories derzeit die Projekt-Homepage ist und es keine offizielle Code-Implementierung gibt; die im Bericht zitierten experimentellen Zahlen stammen aus einer kleinen Drittanbieter-Implementierung mit ca. 79K Parametern von einem unabhängigen Mitwirkenden. Im Repository befinden sich das PDF des Papiers (Recurrent_Looppped_Transformer.pdf, auch hier sind die drei p im Dateinamen die ursprüngliche Schreibweise) und ein Notiz zu “Prefill-Decode kernel mismatch”, die im Pretraining-RL-Science-Repository des Autors abgelegt ist.
Zunächst soll die genaue Bedeutung von “unendlicher zeitlicher Tiefe” festgelegt werden, da der Wert des gesamten Projekts auf diesen wenigen Worten ruht: Nach dem Durchlaufen von t Token hat der rekursive Pfad kumulativ t×L_D Blöcke durchlaufen (L_D ist die Anzahl der Decoderschichten), aber die Anzahl der tatsächlich ausgeführten Blöcke pro Token ist fest. Mit anderen Worten: Dies ist ein skalierbarer zeitlicher Berechnungspfad, der mit der Sequenz wächst – die Tiefe liegt “in der Zeit”, nicht darin, dass ein einzelner Token unendliche Berechnung erhält. Der Autor selbst betont diese Unterscheidung im Bericht wiederholt; alle folgenden Bewertungen in diesem Artikel richten sich nach diesem Maßstab.
2. Kernmechanismen
2.1 Gesamtstruktur: Der Encoder verwaltet das globale Gedächtnis, der Decoder das lokale Gedächtnis plus Zeit-Feedback
RLT teilt den traditionellen Schichtstapel eines Decoder-only-Modells in zwei rollengetrennte Stacks. Der Encoder ist kausal, durchläuft den Prompt einmal und baut ein globales KV-Gedächtnis (global KV memory) auf – die Informationen aller Positionen in der Sequenz sind in diesem Gedächtnis komprimiert, damit der Decoder sie jederzeit abrufen kann. Der Decoder ist rekursiv: 48 Encoder-Schichten stehen 48 Decoder-Schichten gegenüber, wobei die Aufmerksamkeits- (Attention) und FFN-Gewichte über die Phasen hinweg geteilt werden. Hier gibt es eine Rechnung, die man leicht falsch sieht: Jeder Block des Decoders muss neben der Selbstaufmerksamkeit (Self-Attention) zusätzlich ein Cross-Attention auf das Encoder-Gedächtnis durchführen, daher bedeutet „gleiche Anzahl an Schichten“ nicht „gleiche FLOPs“ – die tatsächlichen Kosten pro Decoder-Schicht sind höher als die einer Encoder-Schicht; diese Asymmetrie ist der Architektur inhärent.
2.2 Aufmerksamkeitsmodus: Drei Arten von Gedächtnis, jeweils für einen Abschnitt zuständig
Jeder Schritt des Decoders sieht sich gleichzeitig mit drei Arten von Gedächtnis konfrontiert, wobei die Arbeitsteilung sehr sauber ist.
Der globale Kontext wird durch Cross-Attention abgedeckt: Der Decoder liest das Encoder-Gedächtnis nur über die aktuelle Position, anstatt an jeder Position die gesamte Historie neu zu scannen. Das lokale Gedächtnis wird durch Sliding-Window-Attention (SWA) abgedeckt: Das Fenster W enthält das aktuelle Token, im Cache werden W-1 Historieneinträge behalten; die Historie außerhalb des Fensters verbleibt nicht im Decoder, sondern muss bei Bedarf erneut aus dem Encoder-Gedächtnis abgerufen werden. Das Zeit-Feedback erfolgt durch Rekursion: Die endgültige Decoder-Ausgabe des vorherigen Schritts geht als latente Variable in die Berechnung des nächsten Tokens ein. Durch die Überlagerung dieser drei Mechanismen verfügt das Modell sowohl über eine langfristige globale Ansicht als auch über einen lokalen Kontext und trägt zudem einen impliziten Zeitstatus mit sich, der sich durch die gesamte Sequenz zieht.
2.3 Status und Cache: Die vollständige Definition von H_t
Das Lesenswerteste an diesem Design, Wort für Wort, ist die Definition des Decoder-Status. Der vollständige Decoder-Status wird als H_t = (s_t, C_t^D) geschrieben: s_t ist die rekursive Ausgabe (der endgültige Hidden State des vorherigen Schritts), C_t^D ist der SWA-KV-Cache der einzelnen Schichten, und der Anfangsstatus ist H_0 = (s_*, ∅) – die rekursive Ausgabe startet von einem speziellen Anfangswert, der Cache startet von der leeren Menge. Zwei technische Details spiegeln die Designabsicht am besten wider: Erstens werden an der Grenze zwischen Prompt und Response weder die rekursive Ausgabe noch der SWA-Cache zurückgesetzt; Trainingsproben und generierte Sequenzen teilen sich dieselbe Status-Trajektorie. Zweitens: Die „unendliche Tiefe“ erwächst aus dieser Statusdefinition – jedes Token durchläuft den Vorwärtsdurchlauf nur in einer festen Anzahl von Schichten, aber s_t bringt die Informationen des vorherigen Schritts mit, sodass sich die Gesamtlänge des rekursiven Pfades linear mit t kumuliert.
2.4 Die vollständige Reise eines Tokens
Betrachten wir, wie ein Token die drei Gedächtnisarten durchläuft. Das t-te Token tritt ein und wird zunächst mit der rekursiven Ausgabe der vorherigen Generation zusammengeführt – s_{t-1} durchläuft eine Feedback-Projektion und wird mit dem Embedding des aktuellen Tokens zur Eingabe des Decoders kombiniert. Diese Eingabe durchdringt dann 48 Gewichte teilende Decoder-Blöcke: In jeder Schicht wird zunächst innerhalb eines Sliding Windows der Breite W eine Selbstaufmerksamkeit (Self-Attention) durchgeführt, wobei der KV-Cache dieser Schicht aus C_t^D entnommen wird, dann erfolgt ein Cross-Attention auf das globale Gedächtnis des Encoders und schließlich wird die FFN durchlaufen. Nach den 48 Schichten wird der endgültige Hidden State in zwei Teile aufgespalten: Der eine Teil wird reguliert und wird zu s_t, das s_{t-1} in der nächsten Rekursionsrunde ersetzt; der andere Teil geht an den Ausgabekopf (Output Head), um die Vorhersage für das aktuelle Token zu liefern. Während des gesamten Prozesses gibt es kein einziges Mal ein „erneutes Scannen der gesamten Historie“ – globale Informationen werden nur bei Bedarf aus dem Encoder-Gedächtnis abgerufen, lokale Informationen nur aus dem Fenster, und alles, was davor liegt, steckt in der latenten Variable s. Dies ist die konkrete Form von „Tiefe wächst über die Zeit“: Der Vorwärtsdurchlauf eines einzelnen Tokens bleibt bei 48 Schichten, aber jedes Token steht auf den Schultern der 48 Schichten des vorherigen Schritts.
2.5 Eine einheitliche Ausführungssemantik durchzieht Training und Inferenz
Die am stärksten ingenieurtechnisch geprägte Behauptung im RLT-Bericht ist, dass Pre-Training, SFT, Sampling und RL denselben complete-state transition (Zustandsübergang mit vollständigem Zustand) verwenden, wobei die Zustandsdefinition sowohl eine Prompt-Rekursion als auch einen SWA-Cache (Sliding Window Attention) umfasst. Das Aussehen der vier Szenarien ist jeweils: Prefill wird durch kausale Batch-Codierung durchgeführt, wobei der SWA-KV rekursiv pro Prompt-Token aufgebaut wird; Generation erfolgt durch inkrementelle Codierung, wobei aus dem vorherigen Zustand gesampelt wird und jedes Token nur einmal konsumiert wird; Pre-Training verwendet full BPTT (Backpropagation Through Time), wobei jede legitime Next-Token-Vorhersage überwacht wird und der Gradient durch die gesamte rekursive Trajektorie fließt; SFT überwacht nur die Assistant-Ziele, aber der Zustand wird entlang der gesamten Sequenz kontinuierlich aktualisiert. In traditionellen Ansätzen wird das Training mittels Teacher Forcing entfaltet und die Inferenz autoregressiv, was zu inkonsistenten Zustandssemantiken auf beiden Seiten führt, wobei an den Prompt-Grenzen am ehesten versteckte Verzerrungen auftreten; der Ansatz von RLT glättet diese Nahtstelle bereits durch die Definition.
2.6 RL-Kapitel: Härter als die Architektur ist die Ehrlichkeit des Trainingsziels
Das RL-Kapitel des Berichts ist recht dicht, und vier Schlussfolgerungen sind es wert, so wie sie sind gemerkt zu werden. Erstens: current-policy replay muss nach der Gewichtungsaktualisierung den parameterabhängigen Cache neu aufbauen – das im Zustand zwischengespeicherte KV wurde mit alten Parametern berechnet; ohne Neuaufbau ist der Replay-Zustand falsch. Zweitens: Der vollständige Gradient muss durch den rekursiven Output, den Decoder-KV-Cache und das Encoder-Gedächtnis fließen; jedes detach ist eine Gradientenannäherung und keine exakte Backpropagation. Drittens: Die Verhaltens-log-prob muss die tatsächliche Sampling-Verteilung beschreiben; um ein exaktes importance sampling zu berechnen, muss zudem die support coverage erfüllt sein – wenn nach einer Richtlinienaktualisierung Aktionen, die in alten Trajektorien auftraten, unter der neuen Richtlinie eine Wahrscheinlichkeit von Null haben, sind die Gewichte undefiniert. Viertens: Die gemeinsame Ausführungssemantik beseitigt den strukturellen mismatch an den Prompt-Grenzen, garantiert aber keine kernel parity auf numerischer Ebene und liefert auch nicht automatisch ein unvoreingenommenes off-policy-Ziel. Diese Punkte lesen sich wie eine Bauvorschrift für nachfolgende Forscher: Welche Fallgruben auf Definitionsebene bereits gefüllt wurden und welche weiterhin unangetastet bleiben.
2.7 Synergie zwischen Modell und Hardware sowie Modell und Algorithmus
Der Bericht listet zudem zwei Gruppen von kooperativen Designprinzipien auf. Auf der Modell-Hardware-Seite: Der Encoder führt parallele Batch-Verarbeitung durch, der Decoder nutzt Cross-Sequence-Batching, es gibt Speichermultiplexing und activation checkpointing zur VRAM-Einsparung. Auf der Modell-RL-Algorithmus-Seite: genau jener in 2.5 beschriebene gemeinsame Zustandsübergang. Es ist nüchtern zu betrachten, dass die Autoren selbst erklären, Verbesserungen bei der Inferenz, Hardware-Beschleunigung und RL-Skalierung seien Forschungsziele und keine in diesem Bericht bereits gemessenen Ergebnisse – Abschnitt 2.7 beschreibt Designprinzipien, keine Leistungsdaten.
3. Technische Bewertung
Zuerst zur Art der Beweise: Dieses Projekt verfügt nur über im README dokumentierte erste synthetische Experimente. Die Zahlen stammen alle aus einer kleinen Implementierung mit ca. 79K Parametern und 3 zufälligen Seeds. Der Autor hat ausdrücklich vermerkt, dass die FLOPs nicht übereinstimmen und es sich um einen unabhängigen synthetischen Proof-of-Concept handelt, nicht um eine Verifizierung für Inferenz oder RL-Skalierung im großen Maßstab. Die Bewertung kann nur innerhalb dieses Rahmens stattfinden.
Experimentaufbau: Zwei synthetische Aufgaben, trainiert mit Operationssequenzen der Länge 32, die Evaluierung extrapoliert auf 128 Schritte – das 4-fache der Trainingslänge, wobei für jede Aufgabe und jede Länge 2048 Testprogramme verwendet wurden. Bei der ersten parity-Aufgabe erreicht RLT innerhalb der Trainingslänge fast 100%, während das vergleichbare konventionelle Transformer-Modell 72% erreicht; extrapoliert auf 128 Schritte erreicht RLT 60.8%, die Kontrollgruppe 48% und die zufällige Baseline 50% – das heißt, die Kontrollgruppe ist bei der 4-fachen Extrapolationslänge bereits unter das Zufallsniveau gefallen, während RLT noch über der Zufallslinie gehalten werden kann. Bei der zweiten five-state transitions-Aufgabe erreicht RLT innerhalb der Trainingslänge ebenfalls fast 100%, die Kontrollgruppe nur 24%; aber extrapoliert auf 128 Schritte fällt RLT auf 20.7% zurück, während die zufällige Baseline bei 20% liegt – bei dieser Aufgabe fallen nach der 4-fachen Extrapolation alle auf reines Raten zurück. Zusammenfassend: Das zyklische Feedback bringt dem Modell tatsächlich eine Generalisierungsmarge über die Trainingslänge hinaus, bei der parity-Aufgabe ist diese Marge deutlich; aber diese Marge ist stark aufgabenabhängig, bei der five-state-Aufgabe hält sie der 4-fachen Extrapolation nicht stand. Zwei Aufgaben, 79K Parameter, nicht äquivalente FLOPs – diese Zahlen können beweisen, dass der „Mechanismus durchführbar ist und eine weitere Erforschung wert ist“, aber nicht, dass „dieser Weg definitiv zum Ziel führt“.
Im Vergleich zu den führenden Arbeiten in dieselbe Richtung liegt der Unterschied von RLT im Design-Granularitätsgrad des Zustands: Es definiert explizit den vollständigen Decoder-Zustand (rekursiver Output plus schichtweiser SWA-Cache) und beharrt darauf, für Training und Inferenz dieselbe Zustandsübergangssemantik zu verwenden. Diese Disziplin ist im Bereich von latent reasoning unüblich – bei den meisten Ansätzen sind Trainings- und Bereitstellungsform zwei verschiedene Codebasen. Der Preis ist ebenfalls klar: Je vollständiger der Zustand definiert ist, desto weniger kann bei der Implementierung an irgendeiner Stelle geschludert werden; die vier Konstruktionsstandards in Abschnitt 2.5 sind die Preisliste.
Die Euphorie muss gedämpft werden. Einzelner Autor, Repository seit drei Tagen, Hauptsprache HTML (kein offizieller Code, Experimente sind kleine Drittimplementierungen) – rund 743 Sterne bis September 2026 spiegeln die Anziehungskraft der Idee der „unendlichen Zeittiefe“ wider, nicht die technische Reife. Als Designdokument und Forschungsagenda gelesen, ist es sehr wertvoll; als nutzbares Modell oder Framework gelesen, gibt es derzeit nichts.
4. Werturteil
Das echte Problem ist real: Die Berechnungstiefe eines einzelnen Tokens bei Transformer (Architektur) ist durch die Anzahl der Schichten festgenagelt. Bei langen Sequenzen steigt die Gesamtmenge der Berechnungen, die das Modell ‘gesehen’ hat, aber die Tiefe des ‘Denkens pro Schritt’ nimmt nicht zu. Genau diese Lücke soll der Ansatz des latent reasoning (latentes Schlussfolgern) schließen. Die Antwort, die RLT liefert, besteht aus einer klaren Zustandsdefinition plus geteilter Ausführungssemantik – insbesondere die Tatsache, dass Training und Inferenz denselben Satz an Zustandsübergängen nutzen, ist eine in diesem Bereich selten anzutreffende disziplinierte Designentscheidung.
Die Grenzen sind ebenso klar. Erstens: Es gibt keine offizielle Implementierung; wer den Code sehen möchte, kann derzeit nur kleine Experimente von Drittanbietern lesen. Zweitens: Die Experimente sind synthetische Aufgaben im Bereich von 79K Parametern, die FLOPs sind nicht abgeglichen, und es gibt keinerlei Daten über die Leistung beim groß angelegten Sprachmodellieren. Drittens: Die Autoren selbst haben die Grenze gezogen: Inferenzverbesserung, Hardware-Beschleunigung und RL-Erweiterung sind Forschungsziele, keine getesteten Ergebnisse – jede Wiedergabe, die diese drei Dinge als ‘von RLT bereits erreicht’ darstellt, ist eine Überinterpretation. Viertens: Bei der five-state-Aufgabe fällt die 4-fache Extrapolation auf das Zufallsniveau zurück, was zeigt, dass der durch zirkuläres Feedback gewonnene Spielraum eine aufgabenbezogene Grenze hat und keine universelle Fähigkeit darstellt. Wann es sich lohnt, weiter zu verfolgen: Für diejenigen, die an latent reasoning, Zustandsmodellierung für lange Sequenzen und der Erforschung der Konsistenz von Training und Inferenz arbeiten, lohnt es sich, die Zustandsdefinitionen und die Konstruktionsvorgaben dieses Berichts Punkt für Punkt zu lesen. Wann es sich nicht lohnt, weiter zu verfolgen: Für diejenigen, die ein sofort einsatzbereites Modell wollen, enthält dieses Repository derzeit nur das Paper und die Projektseite.
Fünf. Wie man es in die Praxis umsetzt
Streng genommen gibt es in diesem Abschnitt keine „Installation“ im traditionellen Sinne – es gibt keinen offiziellen Code zum Installieren. Es gibt drei Dinge, die man in die Praxis umsetzen kann. Erstens, das Paper lesen: Im Repository ist ein PDF enthalten, in dem sich die vollständige Argumentation zu Zustandsdefinitionen, Ausführungssemantik und dem RL-Kapitel befindet. Zweitens, die begleitenden Notizen lesen: Der Autor hat im Pretraining-RL-Science-Repository Notizen zum Prefill-Decode kernel mismatch hinterlegt, die sich mit den numerischen und zeitlichen Unstimmigkeiten zwischen den beiden Phasen des Prefillings und Decodings befassen – genau dies ist die Art von Lücke, die RLT durch eine gemeinsame Ausführungssemantik schließen möchte. Nur wenn man beide Texte zusammen liest, kann man das Designmotiv verstehen. Drittens, das Experiment reproduzieren: Das synthetische Experiment im README ist sehr klein (ca. 79K Parameter). Man kann nach der Ausführungssemantik aus Abschnitt 2.4 eine eigene Version schreiben und diese mit einem regulären Transformer anhand einer Parity-Aufgabe vergleichen. Eine Person, die mit PyTorch vertraut ist, kann innerhalb von ein bis zwei Wochen eine erste Version abliefern. Die Inhalte des Repositories sind als Open Source unter Apache-2.0 lizenziert; das Paper und die Dokumentation können frei zitiert und umgeschrieben werden.
Sechs. Wie man selbst ein ähnliches System entwickelt
„Selbst schreiben” ist bei diesem Thema besonders durchführbar, da der Kern von RLT aus einer Zustandsdefinition und einer Trainingsdisziplin besteht. Das minimale Gerüst in sechs Schritten:
- Zwei Rollen aufteilen: Nehmen Sie einen Standard-Transformer-Block und kopieren Sie ihn in zwei Stacks mit gemeinsamen Gewichten. Der Encoder-Stack kodiert kausal die gesamte Eingabe und behält die K und V jeder Schicht als globales Gedächtnis; der Decoder-Stack ist für die tokenweise Generierung zuständig. Die Schichtanzahl muss nicht 48 betragen; 4 Schichten gegen 4 Schichten genügen zur Verifikation des Mechanismus.
- Vollständigen Zustand definieren: Der Zustand des Decoders wird als Paar H_t = (s_t, C_t) geschrieben, wobei s_t der endgültige verborgene Zustand des vorherigen Schritts ist und C_t der KV-Cache des gleitenden Fensters jeder Schicht ist (Fenster W enthält den aktuellen Token, behält W-1 Historieneinträge). Der Anfangszustand H_0 = (s_, ∅), wobei s_ als Parameter erlernbar sein kann.
- Zeitliches Feedback anschließen: Die Eingabe jedes neuen Tokens entsteht durch die Verbindung seines Embeddings mit dem vorherigen
s_{t-1}(durch eine kleine Projektionsschicht und anschließende Addition), und geht dann in den Decoder-Stack: jede Schicht führt zuerst SWA innerhalb des Fensters durch, dann Cross-Attention auf das Encoder-Gedächtnis und schließlich FFN. - Grenze einhalten ohne Zurücksetzen: An der Grenze zwischen Prompt und Response bleiben s und der SWA-Cache unverändert — dies ist die Seele des gesamten Mechanismus; ein Zurücksetzen führt zu einem gewöhnlichen Transformer zurück.
- Full-BPTT-Training: Teacher-Forcing-Entfaltung, jeder Schritt überwacht den nächsten gültigen Token, Gradienten durchlaufen die gesamte rekursive Trajektorie. Ein Detach zur Geschwindigkeitssteigerung ist möglich, aber beachten Sie, dass es sich um eine Gradientenapproximation handelt; ziehen Sie Schlussfolgerungen entsprechend der Approximation.
- Cache bei RL rekonstruieren: Bei jeder Aktualisierung der Policy werden alle parameterabhängigen Caches vollständig neu berechnet; die log-prob der Aktion wird mit der tatsächlichen Sampling-Verteilung berechnet, und vor dem Importance Sampling wird die Support-Abdeckung geprüft.
Der Kernzyklus in Pseudocode zusammengefasst:
H = (s_star, empty_cache) # Anfangszustand
for t in 序列:
x = embed(token[t]) + W_fb @ H.s # Zeitliches Feedback: verborgener Endzustand des vorherigen Schritts
for l in 1..L_D: # Decoder-Schichten verwenden jeweils eigene Gewichte (mit Encoder über Phasen hinweg geteilt)
x = SWA(x, H.cache[l], window=W) # Lokales Gedächtnis: nur W-1 Historieneinträge behalten
x = cross_attention(x, enc_kv) # Globales Gedächtnis: nur von aktueller Position lesen
x = FFN(x)
H.cache[l].push(KV(x))
H.s = final_norm(x)
loss += CE(head(H.s), token[t+1]) # full BPTT, nicht mittendrin abschneiden
# prompt/response-Grenze: H.s und H.cache werden nicht zurückgesetzt
Die sechs Schritte zusammengebracht ergeben eine Reproduktion auf Mechanismus-Verifikationsniveau, die innerhalb eines Monats von ein bis zwei Personen Ergebnisse liefert. Das wirklich Schwierige ist nicht das Schreiben, sondern die Disziplin in den Schritten 4 und 5 — Grenze nicht zurücksetzen und Gradienten nicht abschneiden sehen wie nur zwei Codezeilen aus, aber sie sind die alleinige Quelle der „unendlichen zeitlichen Tiefe”.
Fazit
RLT entkoppelt die Berechnungstiefe des Transformers von der Schichtanzahl: 48 Encoder-Schichten dienen dem globalen Gedächtnis, 48 Decoder-Schichten mit Gewichtsteilung nutzen ein gleitendes Fenster und zeitliches Feedback, wodurch sich der effektive Berechnungspfad mit der Sequenz linear verlängert, und blockiert mit einer durchgängigen, vollständigen Zustandsdefinition, die Training und Inferenz umfasst, die strukturelle Abweichung an den Grenzen des Prompts. Es ist derzeit ein Forschungsbericht eines einzelnen Autors aus drei Tagen mit etwa 743 Sternen, ohne offiziellen Code, bei dem die Experimente lediglich synthetische Proof-of-Concepts auf dem Niveau von 79K Parametern sind und die FLOPs nicht übereinstimmen – die Sternzahl kauft die Idee, nicht das Engineering. Für diejenigen, die sich für latent reasoning (latentes Schließen) interessieren, gehören jedoch seine Zustandsdefinition und das wie eine Bauspezifikation formulierte RL-Kapitel (Reinforcement Learning) zu den Design-Dokumenten in diesem Bereich, die es am meisten wert sind, Punkt für Punkt gelesen zu werden.
Referenzquellen
- Recurrent Looped Transformer GitHub-Repository (README master-Branch, Projekt-Homepage, Paper-PDF Recurrent_Looppped_Transformer.pdf): https://github.com/yifanzhang-pro/recurrent-looped-tranformer
- GitHub-Repository-Metadaten (Star/Fork/Erstellungszeit/Hauptsprache/Lizenz, api.github.com, Stand September 2026)
- Daten vorläufiger synthetischer Experimente (Abschnitt ‘Preliminary synthetic experiments’ im README, Implementierung mit ca. 79K Parametern vom unabhängigen Mitwirkenden @AradhyeAgarwal)
- Notizen zum Prefill-Decode Kernel-Mismatch (Repository yifanzhang-pro/Pretraining-RL-Science)