RLT est l'abréviation de Recurrent Looped Transformer, un modèle Transformer qui réalise une profondeur temporelle infinie grâce à un état à variables latentes en boucle inter-token.

Comment RLT réalise-t-il une profondeur temporelle infinie ?

RLT allonge le nombre de blocs traversés par le chemin récursif à mesure que la séquence s'allonge, réalisant ainsi un chemin de calcul effectif qui s'étend indéfiniment avec la séquence, d'où la profondeur temporelle infinie.

Où se trouve le dépôt RLT ?

L'adresse du dépôt RLT est yifanzhang-pro/recurrent-looped-tranformer, qui a obtenu environ 743 étoiles et 77 forks en septembre 2026.

Démontage technique 009｜RLT : connecter une boucle temporelle au Transformer, l'inférence à variables latentes et la véritable face de la 'profondeur temporelle infinie'

Démontage technique : analyse des cadres technologiques de l’IA — explication, analyse, évaluation technique, jugement de valeur, mise en œuvre. Auteur : Yongliang

Le Transformer a une contrainte rarement confrontée directement : quelle que soit la longueur de la séquence, le nombre de couches traversées par chaque token est fixe. Lorsque la séquence passe de 100 à 100 000 tokens, la profondeur de calcul d’un seul token ne bouge pas — le modèle devient « plus large », mais pas « plus profond ». En septembre 2026, Yifan Zhang a publié un rapport technique intitulé Recurrent Looped Transformer (RLT), plaidant pour libérer la profondeur du nombre de couches : en utilisant un état à variables latentes en boucle inter-token, le « chemin de calcul effectif » s’allonge à mesure que la séquence grandit. Il nomme cette propriété infinite temporal depth — profondeur temporelle infinie. Le dépôt a été créé il y a seulement trois jours et, en septembre 2026, il avait déjà récolté environ 743 étoiles et 77 forks. Cet article démonte six choses : ce que c’est, le mécanisme central jusqu’à la définition des états et des caches, l’évaluation technique, si cela vaut le coup de s’y intéresser, comment le mettre en œuvre, et — si vous souhaitez écrire vous-même un Transformer à rétroaction en boucle minimaliste, à quoi ressemble le squelette minimal.

I. Qu’est-ce que c’est

Positionnement en une phrase : RLT est un projet de type article de recherche, dont la proposition centrale est latent reasoning with infinite temporal depth (raisonnement latent à profondeur temporelle infinie) — échanger un raisonnement à variables latentes contre un chemin de calcul effectif qui s’étend indéfiniment avec la séquence, plutôt que d’empiler des couches pour gagner en profondeur.

Exposons d’abord les faits clés. Le dépôt yifanzhang-pro/recurrent-looped-tranformer (notez que le nom du dépôt est bien tranformer, l’orthographe d’origine sans le s), par l’auteur Yifan Zhang, est un rapport technique à auteur unique, publié en septembre 2026, et son contenu est open source sous licence Apache-2.0. En septembre 2026, il compte environ 743 étoiles et 77 forks, et a été créé le 12 septembre 2026 — il y a trois jours. GitHub indique que le langage principal de ce dépôt est le HTML, car le contenu du dépôt est actuellement principalement la page d’accueil du projet, sans implémentation de code officielle ; les chiffres expérimentaux cités dans le rapport proviennent d’une petite implémentation tierce d’environ 79K paramètres, réalisée par un contributeur indépendant. Le dépôt inclut le PDF du papier (Recurrent_Looppped_Transformer.pdf, les trois p dans le nom de fichier étant également l’orthographe d’origine) et une note sur le Prefill-Decode kernel mismatch (décalage de noyau Prefill-Decode), placée dans le dépôt Pretraining-RL-Science de l’auteur.

Fixons d’abord le sens précis de l’expression « profondeur temporelle infinie », car toute la valeur du projet repose sur ces quelques mots : après avoir parcouru t tokens, le chemin récursif a cumulé t×L_D blocs (L_D étant le nombre de couches du décodeur), mais le nombre de blocs réellement exécutés par token est fixe. En d’autres termes, il s’agit d’un chemin de calcul temporel évolutif qui croît avec la séquence — la profondeur s’étend « dans le temps », ce n’est pas une infinité de calculs obtenue à l’intérieur d’un seul token. L’auteur lui-même souligne à plusieurs reprises cette distinction dans le rapport, et toutes les évaluations dans la suite de cet article suivront cette même interprétation.

II. Mécanismes fondamentaux

2.1 Structure globale : l’encodeur gère la mémoire globale, le décodeur gère la mémoire locale plus le feedback temporel

RLT divise la pile de couches traditionnelle de type decoder-only en deux piles aux rôles distincts. L’encodeur est causal, exécute le prompt une fois et construit une mémoire KV globale (global KV memory) — les informations de toutes les positions de la séquence sont compressées dans cette mémoire, prêtes à être consultées par le décodeur à tout moment. Le décodeur est récursif : 48 couches d’encodeur pour 48 couches de décodeur, les poids d’attention et de FFN sont partagés entre les étapes. Il y a ici un calcul facile à mal interpréter : chaque bloc du décodeur, en plus de l’auto-attention, doit effectuer une cross-attention supplémentaire sur la mémoire de l’encodeur, donc « un nombre égal de couches » ne signifie pas « un nombre égal de FLOPs » — le coût réel d’une seule couche du décodeur est supérieur à celui d’une seule couche de l’encodeur, cette asymétrie est inhérente à l’architecture.

2.2 Mode d’attention : trois types de mémoire gèrent chacun un segment

À chaque étape, le décodeur doit faire face à trois types de mémoire simultanément, avec une division du travail très claire.

Le contexte global s’appuie sur la cross-attention : le décodeur ne peut lire la mémoire de l’encodeur qu’à partir de la position actuelle, plutôt que de balayer à nouveau l’historique complet à chaque position. La mémoire locale s’appuie sur l’attention par fenêtre glissante (SWA) : la fenêtre W contient le token actuel, le cache conserve W-1 entrées d’historique, et l’historique en dehors de la fenêtre ne réside pas dans le décodeur ; pour y accéder, il faut le récupérer depuis la mémoire de l’encodeur. Le feedback temporel s’appuie sur la récursivité : la sortie finale du décodeur de l’étape précédente entre en tant que variable latente dans le calcul du prochain token. La superposition de ces trois mécanismes permet au modèle de disposer d’une vue globale à long terme, d’un contexte local, et d’un état temporel implicite traversant toute la séquence.

2.3 État et cache : définition complète de H_t

Dans cette conception, ce qui mérite le plus d’être lu mot pour mot est la définition de l’état du décodeur. L’état complet du décodeur s’écrit H_t = (s_t, C_t^D) : s_t est la sortie récursive (l’état caché final de l’étape précédente), C_t^D est le cache KV SWA de chaque couche, et l’état initial est H_0 = (s_*, ∅) — la sortie récursive part d’une valeur initiale spéciale, et le cache part de l’ensemble vide. Deux détails d’ingénierie illustrent le mieux l’intention de conception : premièrement, à la frontière entre le prompt et la réponse, ni la sortie récursive ni le cache SWA ne sont réinitialisés, les échantillons d’entraînement et les séquences générées partagent la même trajectoire d’état ; deuxièmement, la « profondeur infinie » émerge de cette définition d’état — chaque token ne passe qu’une seule fois vers l’avant à travers un nombre fixe de couches, mais s_t apporte les informations de l’étape précédente, et la longueur totale du chemin récursif s’accumule linéairement avec t.

2.4 Le parcours complet d’un token

Relions les trois types de mémoire pour voir comment évolue un token. Le t-ième token entre en scène et fusionne d’abord avec la sortie récursive de la génération précédente — s_{t-1} passe par une projection de feedback et se combine avec l’embedding du token actuel pour former l’entrée du décodeur. Cette entrée traverse ensuite 48 couches de blocs du décodeur à poids partagés : chaque couche effectue d’abord une auto-attention dans une fenêtre glissante de largeur W, récupère le cache KV de cette couche depuis C_t^D, effectue ensuite une cross-attention sur la mémoire globale de l’encodeur, et passe enfin par le FFN. Après avoir traversé les 48 couches, l’état caché final se divise en deux : une partie, après normalisation, devient s_t, remplaçant s_{t-1} pour le prochain cycle récursif ; l’autre partie est connectée à la tête de sortie pour fournir la prédiction du token actuel. Tout au long du processus, il n’y a jamais de « nouveau balayage de l’historique complet » — les informations globales sont uniquement extraites à la demande depuis la mémoire de l’encodeur, les informations locales sont uniquement extraites de la fenêtre, et tout ce qui précède se trouve dans la variable latente s. C’est à quoi ressemble concrètement la « profondeur qui croît dans le temps » : la passe avant d’un seul token fait toujours 48 couches, mais chaque token se tient sur les épaules des 48 couches de l’étape précédente.

2.5 Une sémantique d’exécution unique traversant l’entraînement et l’inférence

L’affirmation la plus orientée ingénierie dans le rapport RLT est que le pré-entraînement, le SFT, l’échantillonnage et la RL utilisent la même transition d’état complet (complete-state transition), où la définition de l’état inclut à la fois la récursion du prompt et le cache SWA. L’allure de chacun des quatre scénarios est la suivante : le prefill encode par lots de manière causale, construisant récursivement le KV SWA token par token de prompt ; la generation encode de manière incrémentale, échantillonne à partir de l’état précédent, et chaque token n’est consommé qu’une seule fois ; le pré-entraînement utilise le full BPTT, supervisant chaque prédiction de next-token valide, le gradient traversant toute la trajectoire récursive ; le SFT ne supervise que les cibles de l’assistant, mais l’état continue d’être mis à jour le long de la séquence complète. Dans les approches traditionnelles, l’entraînement est déroulé selon le teacher forcing et l’inférence selon un déroulement autorégressif, la sémantique des états des deux côtés étant incohérente, ce qui rend la frontière du prompt la plus sujette aux biais implicites ; l’approche de RLT comble cette faille dès sa définition.

2.6 Section RL : plus hardcore que l’architecture, l’honnêteté de l’objectif d’entraînement

La section RL du rapport est d’une densité assez élevée, avec quatre conclusions à retenir telles quelles. Premièrement, le current-policy replay doit reconstruire le cache dépendant des paramètres après la mise à jour des poids — le KV mis en cache dans l’état est calculé avec les anciens paramètres, sans reconstruction, l’état du replay est erroné. Deuxièmement, le gradient complet doit traverser la sortie récursive, le cache KV du decoder et la mémoire de l’encoder ; tout detach est une approximation du gradient, et non une rétropropagation exacte. Troisièmement, le log-prob comportemental doit décrire la véritable distribution d’échantillonnage ; pour calculer un importance sampling précis, il faut également satisfaire la support coverage — si les actions apparaissant dans les anciennes trajectoires ont une probabilité nulle sous la nouvelle stratégie après la mise à jour, les poids n’ont pas de définition. Quatrièmement, la sémantique d’exécution partagée élimine le mismatch structurel à la frontière du prompt, elle ne garantit pas la kernel parity au niveau numérique, et ne fournit pas automatiquement un objectif off-policy non biaisé. Ces points se lisent comme des normes de construction établies pour les chercheurs ultérieurs : quels pièges ont déjà été comblés au niveau de la définition, et quels pièges restent intacts.

2.7 Synergie modèle et matériel, modèle et algorithme

Le rapport liste également deux ensembles de principes de conception collaborative. Côté modèle-matériel : l’encoder effectue un traitement par lots parallèle, le decoder fait du batching inter-séquences, réutilisation de la mémoire, activation checkpointing en échange de mémoire vidéo. Côté modèle-algorithme RL : il s’agit de la transition d’état partagée de la section 2.5. Il faut garder un esprit critique sur le fait que les auteurs déclarent eux-mêmes que l’amélioration de l’inférence, l’accélération matérielle et la mise à l’échelle de la RL sont des objectifs de recherche, et non des résultats déjà mesurés dans ce rapport — la section 2.7 décrit des principes de conception, et non des données de performance.

III. Évaluation technique

Commençons par la forme des preuves : ce projet ne dispose que d’expériences de synthèse préliminaires documentées dans le README, les chiffres proviennent tous d’une petite implémentation d’environ 79K paramètres, avec 3 graines aléatoires, et l’auteur précise explicitement que les FLOPs ne correspondent pas et qu’il s’agit d’une preuve de concept de synthèse indépendante, et non d’une validation d’inférence à grande échelle ou d’extension RL. L’évaluation ne peut se faire que dans ce cadre.

Configuration expérimentale : deux tâches de synthèse, entraînement sur des séquences d’opérations d’une longueur de 32 pas, évaluation de l’extrapolation à 128 pas — soit 4 fois la longueur d’entraînement, avec 2048 programmes de test pour chaque tâche et chaque longueur. Pour la première tâche de parity (parité), RLT atteint près de 100 % dans la longueur d’entraînement, contre 72 % pour le Transformer classique de référence ; extrapolé à 128 pas, RLT atteint 60,8 %, le groupe de référence 48 %, tandis que la ligne de base aléatoire est de 50 % — autrement dit, le groupe de référence à une longueur d’extrapolation de 4 fois tombe déjà en dessous du niveau aléatoire, alors que RLT parvient à se maintenir au-dessus de la ligne aléatoire. Pour la deuxième tâche de five-state transitions (transitions à cinq états), RLT atteint également près de 100 % dans la longueur d’entraînement, contre seulement 24 % pour le groupe de référence ; mais extrapolé à 128 pas, RLT retombe à 20,7 %, la ligne de base aléatoire étant de 20 % — sur cette tâche, après une extrapolation de 4 fois, tout le monde revient à des suppositions aléatoires. En synthèse : la rétroaction récurrente apporte effectivement au modèle une marge de généralisation au-delà de la longueur d’entraînement, marge qui est évidente sur la tâche de parity ; mais cette marge dépend fortement de la tâche, et sur la tâche de five-state, elle ne résiste pas à une extrapolation de 4 fois. Deux tâches, 79K paramètres, FLOPs inégaux — cet ensemble de chiffres peut prouver que le « mécanisme est viable et mérite d’être étudié plus en profondeur », mais ne peut pas prouver que « cette voie fonctionnera à coup sûr ».

Comparé aux travaux de pointe dans la même direction, la différence de RLT réside dans la granularité de conception de l’état : il définit explicitement l’état complet du décodeur (sortie récurrente plus cache SWA couche par couche) et s’en tient à une sémantique de transition d’état commune pour l’entraînement et l’inférence, une discipline qui n’est pas courante dans la direction du latent reasoning (raisonnement latent) — la plupart des solutions ont des formes d’entraînement et de déploiement qui constituent deux ensembles de codes distincts. Le coût est également clair : plus la définition de l’état est complète, moins il est possible de faire des raccourcis lors de l’implémentation, et les quatre spécifications de construction de la section 2.5 en sont la liste des coûts.

Il faut tempérer l’engouement. Auteur unique, dépôt créé il y a trois jours, langage principal HTML (pas de code officiel, les expériences sont de petites implémentations tierces) — avec environ 743 stars en septembre 2026, cela reflète l’attractivité de l’idée de « profondeur temporelle infinie », et non la maturité de l’ingénierie. Lu en tant que document de conception et programme de recherche, il a une grande valeur ; lu en tant que modèle ou framework utilisable, il n’y a pour le moment rien.

IV. Jugement de valeur

Le vrai problème est réel : la profondeur de calcul par token de Transformer est figée par le nombre de couches, le calcul total « vu » par le modèle sur de longues séquences augmente, mais la profondeur de « réflexion à chaque étape » n’augmente pas, la voie du latent reasoning (raisonnement latent) vise précisément à combler cette lacune. La réponse apportée par RLT est une définition d’état claire associée à une sémantique d’exécution partagée — en particulier le fait d’avoir un seul ensemble de transitions d’état pour l’entraînement et l’inférence, ce qui constitue une conception disciplinée rare dans ce domaine.

Les limites sont tout aussi claires. Premièrement, il n’y a pas d’implémentation officielle, ceux qui veulent voir le code ne peuvent actuellement que lire de petites expériences tierces. Deuxièmement, les expériences sont des tâches synthétiques de l’ordre de 79K paramètres, les FLOPs ne sont pas appariés, et il n’y a absolument aucune donnée sur les performances en modélisation linguistique à grande échelle. Troisièmement, les auteurs ont eux-mêmes fixé les limites : l’amélioration de l’inférence, l’accélération matérielle et l’extension RL (apprentissage par renforcement) sont des objectifs de recherche, et non des résultats testés — toute reformulation écrivant que « RLT a déjà accompli » ces trois choses constitue une surinterprétation. Quatrièmement, la tâche five-state retombe au niveau aléatoire lors d’une extrapolation 4x, ce qui montre que la marge apportée par la rétroaction cyclique a des limites selon la tâche et n’est pas une capacité universelle. Quand cela vaut-il la peine de s’y intéresser : pour ceux qui travaillent sur le latent reasoning, la modélisation d’état des longues séquences et la recherche de cohérence entre entraînement et inférence, la définition d’état et les spécifications de construction de ce rapport méritent d’être lues point par point. Quand cela ne vaut-il pas la peine de s’y intéresser : pour ceux qui veulent un modèle prêt à l’emploi, ce dépôt ne contient actuellement que le papier et la page du projet.

5. Comment mettre en œuvre

À proprement parler, cette section n’a pas d’« installation » au sens traditionnel — il n’y a pas de code officiel à installer. Trois choses peuvent être mises en pratique. Premièrement, lire l’article : le dépôt contient un PDF, où se trouvent la définition des états, la sémantique d’exécution et l’argumentation complète de la section RL. Deuxièmement, lire les notes associées : l’auteur a placé les notes sur le « Prefill-Decode kernel mismatch » dans le dépôt Pretraining-RL-Science, qui traitent des incohérences numériques et de planification entre les deux phases de pré-remplissage et de décodage — c’est précisément le type de lacune que RLT cherche à combler en utilisant une sémantique d’exécution partagée ; il faut lire les deux côte à côte pour comprendre la motivation de la conception. Troisièmement, reproduire l’expérience : l’expérience synthétique dans le README est de très petite taille (environ 79K paramètres), écrivez la vôtre selon la sémantique d’exécution de la section 2.4, et comparez-la à un Transformer classique à l’aide de la tâche de parité ; une personne familière avec PyTorch peut livrer une première version en une ou deux semaines. Le contenu du dépôt est open source sous licence Apache-2.0, et l’article et la documentation peuvent être librement cités et réécrits.

VI. Comment créer votre propre solution similaire

« Écrire sa propre version » est particulièrement réalisable dans ce contexte, car le cœur de RLT se résume à une définition d’état et une discipline d’entraînement. Le squelette minimal comporte six étapes :

Séparer les deux rôles : Prenez un bloc Transformer standard et copiez-le en deux piles à poids partagés. La pile de l’encodeur code de manière causale l’intégralité de l’entrée, conservant les K et V de chaque couche comme mémoire globale ; la pile du décodeur est responsable de la génération token par token. Le nombre de couches n’a pas besoin d’être 48, 4 couches contre 4 couches suffisent pour valider le mécanisme.
Définir l’état complet : L’état du décodeur s’écrit comme un couple H_t = (s_t, C_t), où s_t est l’état caché final de l’étape précédente, et C_t est le cache KV des fenêtres glissantes de chaque couche (la fenêtre W inclut le token courant, conservant W-1 entrées d’historique). L’état initial est H_0 = (s_, ∅), où s_ peut être appris comme paramètre.
Connecter le retour temporel : L’entrée de chaque nouveau token est formée en fusionnant son embedding avec l’état s_{t-1} de l’étape précédente (il suffit de passer par une petite couche de projection puis d’additionner), puis entre dans la pile du décodeur : chaque couche effectue d’abord une SWA (Sliding Window Attention) sur la fenêtre, puis une cross-attention sur la mémoire de l’encodeur, et enfin passe par un FFN.
Maintenir la frontière sans réinitialisation : À la frontière entre le prompt et la réponse, s et le cache SWA restent tels quels — cette règle est l’âme de tout le mécanisme, les réinitialiser le ferait dégénérer en un Transformer ordinaire.
Entraînement full BPTT : Déroulement avec teacher forcing, à chaque étape on supervise le prochain token valide, et le gradient traverse toute la trajectoire récursive. Il est possible de détacher (detach) pour gagner en vitesse, mais rappelez-vous qu’il s’agit d’une approximation du gradient, et qu’il faut juger en fonction des conclusions de cette approximation.
Reconstruire le cache lors du RL : À chaque mise à jour de la politique, tous les caches liés aux paramètres sont recalculés ; le log-prob du comportement est calculé en utilisant la véritable distribution d’échantillonnage, et la couverture de support (support coverage) est vérifiée avant l’importance sampling.

La boucle principale compressée en pseudo-code donne ceci :

H = (s_star, empty_cache)                     # État initial
for t in séquence:
    x = embed(token[t]) + W_fb @ H.s          # Retour temporel : état caché final de l'étape précédente
    for l in 1..L_D:                          # Chaque couche du décodeur utilise ses propres poids (partagés avec l'encodeur à travers les étapes)
        x = SWA(x, H.cache[l], window=W)      # Mémoire locale : ne conserve que W-1 entrées d'historique
        x = cross_attention(x, enc_kv)        # Mémoire globale : lit uniquement à partir de la position courante
        x = FFN(x)
        H.cache[l].push(KV(x))
    H.s = final_norm(x)
    loss += CE(head(H.s), token[t+1])         # Full BPTT, ne pas couper à mi-chemin
# Frontière prompt/response : H.s et H.cache ne sont pas réinitialisés

En additionnant ces six étapes, une reproduction de niveau validation de mécanisme peut donner des résultats en un mois avec une ou deux personnes. Le plus difficile n’est pas de l’écrire, mais de maintenir la discipline des étapes 4 et 5 — ne pas réinitialiser la frontière et ne pas couper le gradient ressemble à seulement deux lignes de code, mais elles sont l’unique source de la « profondeur temporelle infinie ».

Conclusion

RLT découple la profondeur de calcul du Transformer du nombre de couches : 48 couches d’encoder pour la mémoire globale, 48 couches de decoder à poids partagés reposant sur une fenêtre glissante et un feedback temporel, permettant au chemin de calcul effectif de s’allonger linéairement avec la séquence, et avec une définition d’état complète traversant l’entraînement et l’inférence qui bloque le biais structurel des frontières de prompt. Il s’agit actuellement d’un rapport de recherche à auteur unique, réalisé en trois jours, totalisant environ 743 étoiles, sans code officiel, les expériences n’étant qu’une validation de concept synthétique à l’échelle de 79K paramètres, les FLOPs n’étant pas appariés — les étoiles récompensent l’idée, non l’ingénierie. Mais pour ceux qui s’intéressent au latent reasoning, sa définition d’état et ce chapitre RL façon cahier des charges comptent parmi les documents de conception les plus dignes d’être lus ligne par ligne dans cette direction actuellement.

Sources de référence

Dépôt GitHub Recurrent Looped Transformer (README branche master, page d’accueil du projet, PDF du papier Recurrent_Looppped_Transformer.pdf) : https://github.com/yifanzhang-pro/recurrent-looped-tranformer
Métadonnées du dépôt GitHub (star/fork/date de création/langage principal/licence, api.github.com, à septembre 2026)
Données des expériences synthétiques préliminaires (section « Preliminary synthetic experiments » du README, implémentation d’environ 79K paramètres par le contributeur indépendant @AradhyeAgarwal)
Notes sur le mismatch du kernel Prefill-Decode (dépôt yifanzhang-pro/Pretraining-RL-Science)