Salta al contenuto

Cos'è un looped transformer?

Modello che riattraversa più volte gli stessi strati per pensare più a lungo, senza scrivere alcun passaggio intermedio.

Un looped transformer è un modello che attraversa più volte gli stessi strati, invece di attraversare una volta sola una pila più lunga. I pesi sono condivisi: lo stesso blocco viene rieseguito, e il risultato di ogni giro rientra come input del giro successivo. L'intuizione è quella di rileggere lo stesso paragrafo finché non torna, invece di leggere un libro più spesso. La differenza rispetto ai modelli che ragionano scrivendo è che qui non viene prodotto nessun testo intermedio: il lavoro resta nello spazio interno del modello, in forma numerica, e diventa parole solo alla fine. Il numero di giri, poi, non è fissato una volta per tutte in addestramento: si decide al momento della domanda, alzandolo su un problema difficile e abbassandolo su uno banale. È questo a rendere l'architettura interessante fuori dai laboratori, perché sposta una scelta di costo dal progetto all'esercizio quotidiano.

Leggi anche: Test-time compute · La quantità di calcolo spesa in fase di inferenza per migliorare una risposta, non in fase di addestramento.

Cosa compra il loop

Il termine nasce da un risultato teorico: nel 2023 il gruppo di Angeliki Giannou e Dimitris Papailiopoulos ha mostrato (Looped Transformers as Programmable Computers) che un transformer di tredici strati messo in loop può emulare un piccolo calcolatore con program counter, salti condizionali e chiamate di funzione. È una prova di espressività, non di prestazioni. Il lato pratico è arrivato dopo, su due strade. La prima è la tenuta sugli input lunghi, quella che in letteratura si chiama length generalization: nel lavoro accettato a ICLR 2025 (Looped Transformers for Length Generalization) un looped transformer a passi adattivi regge molto meglio, nei compiti iterativi, su sequenze più lunghe di quelle viste in addestramento, semplicemente girando di più al momento della domanda. La seconda è la scala: il modello a profondità ricorrente di Jonas Geiping e colleghi (Scaling up Test-Time Compute with Latent Reasoning), 3,5 miliardi di parametri addestrati su 800 miliardi di token, migliora sui benchmark di ragionamento fino a un carico di calcolo equivalente a 50 miliardi di parametri. È un modo particolare di spendere test-time compute, non un suo sostituto. E non va confuso con la mixture of experts, che cambia quali parametri si usano per ogni token: il loop cambia quante volte si usano gli stessi.

Il rovescio: un ragionamento che non si legge

In un reasoning trace i passaggi sono token visibili, che si possono archiviare e rileggere; qui non c'è nessun token da leggere, perché i giri restano numeri interni. Il ragionamento resta quindi senza una traccia leggibile: gli stati interni si possono ispezionare, ma non si archiviano e non si mostrano a un revisore, e per chi deve documentare come si è arrivati a una decisione è un problema di governance, non un dettaglio. Diverso anche dai recursive language models, che spendono calcolo fuori dal modello chiamando sotto-modelli in un ambiente esterno: nel looped transformer tutto avviene dentro un singolo passaggio in avanti. Va detta anche una cosa sul rumore di mercato: circola la voce che GPT-6 Astra sia costruito così, ma nessuna documentazione del produttore lo conferma. Esiste però un modello di questo tipo, con tanto di rapporto tecnico pubblico: Nanbeige4.2-3B, pre-addestrato da zero su 28 mila miliardi di token riusando sempre gli stessi strati.

Perché conta per chi decide

Il loop separa il calcolo dal numero di pesi: venticinque strati iterati quattro volte tengono in memoria i pesi di venticinque strati e costano il calcolo di cento. Il risparmio è sui pesi, non su tutta la memoria: cache e attivazioni crescono a ogni giro, e per tenerle sotto controllo si dichiara in anticipo un tetto ai giri. Per chi tiene i modelli in casa, dove il vincolo che stringe è la memoria della scheda e non il tempo, è la differenza fra "ci sta sull'hardware che abbiamo" e "serve un altro server". Il budget di ragionamento diventa poi una manopola da girare domanda per domanda, senza riaddestrare e senza cambiare modello. Il prezzo sull'altro piatto della bilancia è l'assenza di una traccia leggibile: dove serve rendere conto del percorso, non è l'architettura giusta.

Domande frequenti

Costa meno memoria di pesi e più calcolo. Tiene in memoria i pesi dei suoi strati reali, che sono pochi, ma cache e attivazioni si gonfiano a ogni giro, e ogni giro in più si paga in tempo e in energia: conviene dove il vincolo è la dimensione della scheda, molto meno dove il vincolo è la latenza.

No. I giri restano rappresentazioni numeriche interne e non producono testo, quindi non esiste una traccia leggibile da archiviare o mostrare a un revisore, e non c'è nulla da allegare a una pratica o da far leggere a chi controlla. Dove serve documentare il percorso di una decisione, un modello che scrive i propri passaggi resta la scelta più difendibile.
  • Test-time compute · La quantità di calcolo spesa in fase di inferenza per migliorare una risposta, non in fase di addestramento.
  • Reasoning trace · La sequenza di passaggi intermedi che un modello produce prima della risposta finale, distinta da risposta e riassunto.
  • Recursive Language Models (RLM) · Strategia di inferenza in cui un LLM esplora il contesto in un REPL esterno, invocando sotto-modelli invece di caricare tutto in memoria.
  • Mixture of experts (MoE) · Architettura sparsa che attiva solo una parte dei parametri per token: meno costo e latenza di un modello denso equivalente.
  • Reasoning models · Modelli che ragionano passo dopo passo prima di rispondere, spendendo più calcolo al momento dell'inferenza per problemi complessi.

Vedi nell'universo

Se l'AI ti serve in produzione, non in una demo, è il mio lavoro.

VEDI INTEGRAZIONI AI

Oppure scrivimi.