Un Transformer da 21 miliardi di parametri esegue il renderer di Doom senza addestramento

Cursor Horizon ha ora un insolito riferimento tecnico: un transformer da 21 miliardi di parametri che esegue il rendering di Doom senza essere stato addestrato. Lo sviluppatore Rob Porter ha compilato l'algoritmo di rendering del gioco direttamente nei pesi del transformer. Il risultato mette in discussione l'assunto secondo cui ogni grande transformer abbia appreso il proprio comportamento dai dati.

Questo modello non prevede come dovrebbe apparire un frame di Doom. Esegue un processo di rendering tradotto, un token generato alla volta. Un prompt fornisce la geometria della scena e lo stato della telecamera. L'output contiene calcoli intermedi e comandi di disegno che un piccolo programma host converte in pixel.

Questa distinzione separa il progetto dagli esperimenti generativi su Doom addestrati con video di gameplay. Crea inoltre la tensione centrale di questa storia su Cursor Horizon. L'inferenza dei transformer è diventata un insolito bersaglio per il software convenzionale, ma il programma risultante è drasticamente più lento del gioco originale.

Gli artefatti pubblici rendono l'affermazione insolitamente verificabile. Porter ha pubblicato il compilatore, il grafo del renderer, i checkpoint, il prompt, gli strumenti di decodifica e un'implementazione di riferimento. Tuttavia, la maggior parte dei risultati su prestazioni e accuratezza proviene ancora dai test del progetto stesso, anziché da repliche indipendenti.

Il renderer di Doom è diventato un checkpoint transformer standard

Il cambiamento importante non è che un modello di IA abbia prodotto un'immagine di Doom. È che il normale codice di rendering è diventato i pesi del modello.

Porter ha pubblicato il progetto il 13 agosto 2026, seguito da un dettagliato post per la community. Il suo approfondimento tecnico descrive un compilatore chiamato torchwright. Trasforma grafi computazionali nei pesi di attenzione e feed-forward di un transformer decoder-only.

Non esistono cicli di ottimizzazione, corpus di addestramento, aggiornamenti dei gradienti o approssimazioni apprese del gameplay di Doom. Il compilatore calcola i pesi del checkpoint a partire da un grafo scritto in Python. Quei pesi codificano le operazioni necessarie al renderer durante l'esecuzione.

L'artefatto generato usa l'architettura standard Phi3ForCausalLM. È rilevante perché Hugging Face Transformers sa già come caricarla ed eseguirla. Gli utenti non hanno bisogno di codice modello personalizzato né dell'impostazione potenzialmente sensibile trust_remote_code=True.

Il checkpoint principale contiene 38 livelli transformer e circa 21 miliardi di parametri. I suoi shard di pesi fp32 occupano 85,87 GB. Una versione più piccola da 80 per 50 usa 70 livelli e 34,09 GB di shard fp32.

Il checkpoint più grande riceve un prompt di 3.614 token che rappresenta la scena. Genera poi 53.747 token prima di completare il frame. La sequenza combinata raggiunge 57.361 token.

Solo una parte dell'output dipinge direttamente i pixel. I token rimanenti rappresentano operazioni del renderer, valori calcolati, flusso di controllo e stato temporaneo. Funzionano più come una traccia di esecuzione che come linguaggio naturale.

Il checkpoint pubblicato include la configurazione del modello, il tokenizer, il prompt, la palette e le utility di decodifica. Il suo tokenizer usa parole leggibili per operazioni e valori. Questa scelta rende comprensibili porzioni della traccia di esecuzione senza dover decodificare ID di token arbitrari.

Il programma host svolge un compito volutamente ristretto. Memorizza una posizione del cursore, seleziona colori dalla palette di Doom e dipinge le sequenze di pixel richieste. Non calcola visibilità, geometria, ordinamento delle pareti, coordinate delle texture o occlusione.

Cinque comandi di output controllano il disegno. Due comandi impostano le coordinate del cursore. Due scelgono se il cursore avanza orizzontalmente o verticalmente. Il quinto dipinge una sequenza di pixel con un colore e una larghezza specificati.

Questo confine è centrale per la credibilità del progetto. Un modello che si limitasse a chiedere a software esterno di renderizzare Doom sarebbe meno interessante. Qui, secondo quanto riportato, il checkpoint svolge il lavoro di rendering dipendente dalla visuale, mentre l'host applica meccanicamente le sue istruzioni di disegno.

Il checkpoint non è il gioco Doom completo. Non implementa gameplay, nemici, sprite generici, audio o controllo del giocatore. Implementa una versione limitata del renderer per scene che usano una libreria di texture fissa.

L'output completo usa la risoluzione di visualizzazione 320 per 200 di Doom in modalità a basso dettaglio. Il renderer calcola 160 colonne e visualizza ciascuna su due pixel. Nel modello sono compilate nove texture per pareti e sei texture per pavimenti o soffitti.

La posizione del giocatore, la direzione di visuale, la geometria della mappa, le informazioni sui settori e l'albero di partizionamento binario dello spazio arrivano tramite il prompt. Un albero di partizionamento binario dello spazio, o albero BSP, divide la mappa per un efficiente ordinamento della visibilità.

Questi input possono cambiare senza ricostruire il checkpoint, purché la scena resti entro i limiti delle texture e della configurazione compilate. L'aggiunta di una texture non supportata richiede una ricompilazione.

Ecco perché la prospettiva di Cursor Horizon merita attenzione. Il progetto tratta un checkpoint transformer come un formato di pacchetto eseguibile, non come un archivio di conoscenza appresa. I suoi parametri sono materiale di programma generato da un compilatore.

Perché Cursor Horizon mette in discussione il modello basato prima sull'addestramento

Torwright trasforma l'architettura transformer in un substrato computazionale deterministico, anche se non offre alcuna sostituzione pratica ai processori convenzionali.

La maggior parte dei grandi modelli linguistici acquisisce comportamenti attraverso l'addestramento. Gli ingegneri selezionano un'architettura, la espongono ai dati, misurano gli errori e regolano i pesi tramite discesa del gradiente. Il modello finale contiene schemi appresi da quegli esempi.

Torwright ribalta questo flusso di lavoro. Uno sviluppatore definisce un grafo computazionale e il compilatore costruisce pesi che ne eseguono le operazioni. Il transformer completato continua a prevedere un token dopo l'altro, ma il processo di previsione segue un programma progettato.

La distinzione ricorda la differenza tra imparare la moltiplicazione dagli esempi ed eseguire un circuito di moltiplicazione. Entrambi possono produrre la stessa risposta. Le loro origini interne, i limiti di affidabilità e le modalità di errore differiscono.

Il compilatore open-source torchwright supporta operazioni lineari, lookup basati sull'attenzione, confronti, selezione e moltiplicazione. Pianifica i nodi del grafo attraverso i livelli transformer e conserva i valori calcolati nel flusso residuo.

Un flusso residuo è il vettore in evoluzione che passa attraverso i livelli di un transformer. Torchwright assegna porzioni di quel vettore ai valori del programma. Quando un valore non è più necessario, un'altra operazione lo annulla e riutilizza il suo spazio.

In questa configurazione, l'attenzione svolge più di un'associazione semantica. Recupera valori dai token precedenti confrontando campi strutturati. Tali campi possono rappresentare un identificatore di nodo, la profondità dell'albero, il tipo di operazione o una coordinata dello schermo.

I livelli feed-forward implementano operazioni non lineari. Torchwright offre librerie di operazioni costruite con attivazioni ReLU o SwiGLU. Il compilatore converte ogni operazione del grafo in righe specifiche di pesi feed-forward o teste di attenzione.

Questo approccio ha precedenti accademici. RASP ha introdotto un linguaggio di programmazione le cui primitive si mappano alle operazioni dei transformer. La ricerca Tracr di DeepMind ha compilato programmi RASP in pesi transformer per esperimenti di interpretabilità.

Torwright estende questa direzione verso normali grafi computazionali Python e un formato di output Phi-3 standard. Il bersaglio è significativo perché il software di inferenza esistente può caricare il risultato senza comprenderne l'insolita origine.

Questa compatibilità crea una possibilità provocatoria. Un checkpoint standard potrebbe contenere comportamento statistico appreso, logica compilata deliberatamente o una combinazione di entrambi. La sua struttura di file, da sola, non rivelerebbe quale percorso abbia prodotto i suoi pesi.

Per gli sviluppatori, questo cambia il modo in cui possono essere interpretati gli artefatti dei modelli. Il numero di parametri normalmente funge da segnale approssimativo della capacità appresa e del costo di inferenza. Qui, 21 miliardi di parametri riflettono principalmente un bersaglio di compilazione estremamente inefficiente.

Il numero non significa che il checkpoint possieda un'ampia conoscenza linguistica. Non può rispondere a domande generiche né improvvisare scene di Doom al di fuori del renderer supportato. I suoi pesi implementano un programma vincolato, anziché un modello linguistico aperto.

Cursor Horizon cattura quindi un problema di confine più ampio. L'ecosistema dei transformer fornisce ormai loader, acceleratori, sharding, strumenti di distribuzione e classi di modelli standardizzate. Un compilatore può sfruttare questa infrastruttura per software che non è mai stato addestrato.

Questo non rende i transformer preferibili alle CPU. Dimostra che la loro macchina di esecuzione è abbastanza generale da ospitare algoritmi costruiti esplicitamente. Generalità, efficienza e utilità restano questioni separate.

Il contributo più forte del progetto è concettuale, non commerciale. Rende visibile la distinzione tra architettura e addestramento. Un transformer è una struttura matematica. Un LLM è una sua applicazione familiare costruita addestrando quella struttura sul linguaggio.

Il modello di Porter elimina il processo di apprendimento preservando il familiare comportamento di inferenza. Accetta token, applica livelli di attenzione e feed-forward, seleziona un token successivo e ripete. Il ciclo appare ordinario anche quando il calcolo al suo interno non lo è.

Questa proprietà offre anche un ambiente di ricerca controllato. Poiché ogni peso deriva da operazioni note del grafo, i ricercatori possono tracciare il motivo per cui appare un valore. Ciò differisce nettamente dall'interpretazione di un modello le cui caratteristiche interne sono emerse dall'addestramento.

Tuttavia, il checkpoint di Doom è molto più grande dei tipici modelli di test per l'interpretabilità. La sua scala dimostra che le costruzioni compilate possono raggiungere l'infrastruttura dei modelli moderni. Rende inoltre costose l'ispezione e la riproduzione indipendente.

Il Transformer esegue Doom un token alla volta

Il renderer funziona convertendo lo stato di esecuzione mutabile di Doom in una cronologia di token append-only su cui l'attenzione può effettuare ricerche.

Il renderer di Doom attraversa un albero BSP dalle regioni vicine a quelle lontane. Proietta le pareti sulle colonne dello schermo, tiene traccia delle aree già coperte e salta la geometria nascosta dietro superfici più vicine.

Il codice convenzionale aggiorna variabili e strutture dati in memoria. La generazione autoregressiva non può modificare token precedenti. Ogni nuovo token si aggiunge a una sequenza append-only che rimane disponibile ai passaggi successivi del transformer.

Il renderer compilato risolve questa discrepanza rappresentando ogni cambiamento di stato come un altro token. Le operazioni successive usano l'attenzione per trovare il record rilevante più recente o combinare più record precedenti.

Un attraversamento ricorsivo dell'albero normalmente si basa su uno stack di chiamate. Il modello emette invece record di breadcrumb durante la discesa. Quando raggiunge una foglia, l'attenzione recupera il breadcrumb appropriato e determina dove deve riprendere l'esecuzione.

La copertura delle pareti richiede un'altra strategia. Doom memorizza gli intervalli orizzontali coperti in una struttura mutabile chiamata solidsegs. Questi intervalli lo aiutano a evitare di disegnare pareti già nascoste da geometrie più vicine.

Il transformer non può unire o sovrascrivere record di intervalli precedenti. Aggiunge ogni intervallo appena coperto. Le operazioni successive interrogano la cronologia accumulata per scoprire se una colonna è coperta e dove termina l'intervallo coperto.

Pavimenti e soffitti seguono un modello correlato. Il passaggio delle pareti registra i loro confini visibili per ogni colonna dello schermo. Un passaggio successivo recupera tali record ed emette sequenze di disegno orizzontali.

Il risultato è una sequenza di token che svolge diversi ruoli. È un flusso di istruzioni, memoria di lavoro, stack delle chiamate, registro di stato e protocollo di output. L’attenzione fornisce il meccanismo di ricerca che collega questi ruoli.

Anche i calcoli lunghi vengono suddivisi tra token generati. Un layer transformer può svolgere solo una quantità limitata di lavoro sequenziale prima di passare il suo flusso residuo al layer successivo. Catene di dipendenze più lunghe richiederebbero più layer.

Il renderer a volte emette un risultato intermedio e lo utilizza durante un passaggio di decodifica successivo. Questa strategia impiega più token per ridurre la profondità necessaria a ciascun passaggio.

La proiezione delle pareti illustra il compromesso. Il modello calcola gli angoli nel mondo, li converte in angoli relativi alla telecamera e quindi proietta gli estremi sullo schermo. I token degli angoli intermedi separano queste fasi dipendenti.

Questo design mantiene il modello di punta a 38 layer. Contribuisce anche al rollout di 53.747 token richiesto per un frame. Ogni passaggio intermedio aggiuntivo comporta un altro passaggio completo del modello.

Il codice sorgente del renderer espone questa pipeline. I moduli gestiscono gli input della scena, l’attraversamento, la proiezione, la rasterizzazione, le texture e il protocollo di output. Un renderer Python separato funge da riferimento di correttezza.

Il modello genera token in modo greedy, ossia seleziona il token successivo con il punteggio più alto senza campionamento. La casualità sarebbe inappropriata perché il checkpoint è progettato per eseguire logica deterministica.

La parola chiave Cursor Horizon diventa utile qui come metafora del confine di stato del modello. Il suo cursore di output avanza attraverso un’immagine renderizzata, mentre il suo orizzonte di attenzione si estende all’indietro nella cronologia dell’esecuzione.

Eppure il meccanismo è più letterale che poetico. Ogni nuova operazione può ispezionare i fatti precedenti della scena e i record generati. Nulla nel processo richiede la flessibilità semantica associata ai modelli conversazionali.

Il prompt agisce come memoria in sola lettura. Contiene i fatti della mappa indipendenti dalla vista, oltre alla posizione e alla direzione del giocatore. La porzione generata agisce come memoria di lavoro append-only per calcoli dipendenti dalla vista.

L’host interpreta successivamente i token di disegno usando la palette a 256 colori di Doom. Sposta un cursore software e dipinge le sequenze richieste. La dimostrazione minimale di Porter implementa quel lato in 43 righe di Python.

Questo piccolo host non dimostra che ogni calcolo di rendering risieda nel checkpoint. Tuttavia, il codice sorgente pubblico rende verificabile il confine. I revisori possono ispezionare la costruzione del prompt, i moduli del grafo, la decodifica dell’output e il confronto con il riferimento.

Il progetto riporta verifiche pixel per pixel rispetto al suo renderer Python. Per il frame di punta, ha misurato copertura completa dei pixel, una concordanza del 99,9 percento entro le opzioni di colore consentite e una concordanza esatta del 96,7 percento.

Queste cifre differiscono leggermente dal 97 percento arrotondato usato nell’articolo originale. Il file dei fatti canonici del repository attribuisce le misurazioni più recenti a un rendering di produzione del 9 agosto.

Il checkpoint a risoluzione inferiore avrebbe raggiunto copertura completa, concordanza completa dei colori tra le opzioni disponibili e una concordanza esatta del 93,9 percento. Il suo frame conteneva 3.964 pixel confrontati.

Si tratta di misurazioni riportate dal progetto. Test indipendenti non hanno ancora stabilito se gli stessi risultati valgano in ambienti, prompt o variazioni della scena diversi.

Il Vero Risultato Sono 35 Frame al Giorno

Il progetto riesce come dimostrazione di un compilatore proprio perché fallisce in modo così clamoroso come renderer Doom pratico.

Doom originale puntava a 35 frame al secondo sull’hardware dei primi anni Novanta. Il checkpoint completo di Porter produce circa 0,0004 frame al secondo su un acceleratore Nvidia B200.

La decodifica greedy ha richiesto 2.383,5 secondi durante l’esecuzione di produzione riportata. Il caricamento del modello e altri overhead hanno portato il tempo end-to-end a 2.528,1 secondi, ovvero 42,1 minuti.

Questo produce circa 35 frame al giorno, presupponendo un funzionamento continuo e tempistiche simili. Il confronto è diventato la battuta più memorabile del progetto. Espone inoltre il costo centrale della compilazione di software ordinario nell’inferenza autoregressiva.

Ogni token emesso richiede un altro passaggio attraverso un modello da 21 miliardi di parametri. Disegnare un frame comporta decine di migliaia di tali passaggi. L’architettura serializza operazioni che l’hardware convenzionale esegue tramite istruzioni compatte e pipeline parallele.

L’esecuzione su B200 avrebbe riservato al picco 151 GiB di memoria. Il solo checkpoint occupa quasi 80 GiB se misurato in gibibyte binari. Non è un programma che la maggior parte dei lettori possa testare su una GPU desktop.

Il checkpoint per consumatori riduce la risoluzione a 80 per 50 pixel. Produce un rollout di 7.007 token e avrebbe una decodifica di 338,3 secondi su una A100 con 80 GB di memoria.

Il suo checkpoint da 34,09 GB può anche essere distribuito su due GPU consumer da 32 GB tramite mappatura automatica dei dispositivi. Questa versione rende la replica più accessibile, pur rimanendo dispendiosa per un frame minuscolo.

La precisione crea un’altra limitazione. I modelli pubblicati usano pesi fp32. Le distribuzioni LLM convenzionali riducono spesso memoria e calcolo tramite formati a precisione inferiore o quantizzazione.

La quantizzazione è rischiosa qui perché gli errori numerici non si limitano ad attenuare le probabilità linguistiche. Possono corrompere lo stato del programma, i confronti, le ricerche simili a indirizzi e la cancellazione all’interno del flusso residuo.

La documentazione del compilatore Torwright riconosce che alcune costruzioni non lineari usano approssimazioni lineari a tratti. I suoi test misurano limiti di errore per singole operazioni e confrontano i nodi del grafo compilato con la valutazione diretta.

Queste salvaguardie forniscono evidenza, non certezza matematica per ogni esecuzione completa. I limiti di errore per operazione non si compongono automaticamente lungo catene lunghe. Il compilatore si basa quindi su sonde più ampie del grafo e confronti dell’output.

La discussione pubblica del progetto su Reddit ha sollevato direttamente questa preoccupazione. Porter ha affermato di aspettarsi che una quantizzazione eseguita con leggerezza producesse output corrotto anziché un’immagine a fedeltà inferiore. Ha inoltre osservato di non aver testato quello scenario.

Un’altra limitazione riguarda la generalità. Il checkpoint supporta una regione selezionata, una risoluzione fissa e le texture necessarie attorno all’area iniziale di E1M1. Non riproduce l’intero renderer per tutti i contenuti di Doom.

Gli sprite restano non implementati. L’arma e la barra di stato sono fissate allo stato iniziale con pistola. Il modello renderizza una scena, non un ciclo di gioco interattivo con i normali sistemi di gameplay.

Anche il prompt della mappa del progetto viene preparato prima dell’inferenza. Il codice lato host ritaglia il livello a una regione fissa nello spazio del mondo e codifica i fatti statici come token. Il repository descrive quel confine come paragonabile al caricamento di un livello.

I critici possono ragionevolmente chiedersi se questo conti ancora come Doom in esecuzione dentro un transformer. La risposta più difendibile è più circoscritta: la logica di rendering dipendente dalla vista viene eseguita all’interno di un checkpoint compilato per una scena Doom vincolata.

Sarebbe inesatto affermare che Doom stesso sia diventato un LLM. Il checkpoint non possiede abilità linguistiche apprese e non implementa il gioco completo. “Renderer ospitato da transformer” è una descrizione più pulita.

L’angolazione di Cursor Horizon dovrebbe preservare questa distinzione. Il progetto amplia ciò che un file di modello standard può rappresentare, ma non mostra una nuova strada competitiva per il calcolo grafico.

Inoltre, non ha ricevuto un’ampia verifica indipendente. Il repository fornisce codice, pesi, prompt, misurazioni e strumenti di confronto. Riprodurre il risultato di punta richiede comunque hardware costoso e una notevole capacità di download.

La reazione della community riflette entrambi gli aspetti. Gli sviluppatori hanno elogiato l’idea del compilatore e riso delle sue prestazioni. Altri hanno chiesto se output paralleli, architetture alternative o sistemi di diffusione potrebbero renderizzare frame in modo più efficiente.

Questi suggerimenti trascurano in parte il vincolo deliberato del progetto. Porter voleva un modello standard di generazione del testo che le normali classi Hugging Face potessero caricare. Questa scelta ha legato il renderer a un inefficiente ciclo di un token per passaggio.

Cambiare l’architettura potrebbe migliorare la velocità indebolendo però la dimostrazione. Il progetto è interessante perché accetta i limiti di un transformer causale vanilla e completa comunque il processo di rendering.

Cosa Dovrebbe Osservare Cursor Horizon

Il prossimo test non è un altro screenshot impressionante. È verificare se soggetti esterni possano riprodurre, comprimere e generalizzare l’esecuzione compilata.

Il primo segnale è la riproduzione indipendente. Una terza parte dovrebbe eseguire il checkpoint a bassa risoluzione rilasciato, confrontarne l’output con il renderer di riferimento e pubblicare i dettagli hardware e software.

Una replica riuscita rafforzerebbe l’affermazione che un checkpoint standard esegue il grafo documentato. Un output divergente esporrebbe la sensibilità a versioni del transformer, kernel numerici, posizionamento dei dispositivi o comportamento in virgola mobile.

Il secondo segnale è l’esecuzione a precisione inferiore. Una build bf16, fp16 o quantizzata convalidata ridurrebbe la barriera hardware del progetto. Verificherebbe inoltre se torchwright possa gestire la cancellazione residua e i confronti a precisione ridotta.

Il successo renderebbe i transformer compilati più facili da studiare e distribuire. Il fallimento chiarirebbe che il comportamento numerico esatto rimane un vincolo importante per questo modello di programmazione.

Il terzo segnale è un supporto più ampio della scena. Lo stesso checkpoint dovrebbe renderizzare posizioni, direzioni e regioni di mappa compatibili multiple senza ricompilazione. I confronti pubblicati dovrebbero coprire più della vista E1M1 di punta.

Questo test distinguerebbe un’implementazione di renderer generale da un percorso dimostrativo altamente ottimizzato. Mostrerebbe inoltre come il meccanismo di stato append-only si comporta al variare della geometria e del numero di token.

Il parallelismo rimane un’importante questione a più lungo termine. Il design attuale di Porter usa un token generato per ogni passaggio computazionale delimitato. Un sistema che emettesse diverse operazioni sicure per passaggio potrebbe ridurre l’enorme onere di decodifica.

Tuttavia, tale cambiamento deve preservare l’affermazione centrale del progetto. Spostare i calcoli geometrici o le decisioni di visibilità nel codice host migliorerebbe le prestazioni ricollocando il renderer, non migliorando l’esecuzione del transformer compilato.

Futuri esempi di torchwright potrebbero risultare più informativi di frame Doom più veloci. Parser deterministici, validatori di protocolli, calcolatrici e moduli algoritmici trasparenti si adattano meglio ai punti di forza del compilatore rispetto alla grafica in tempo reale.

La logica compilata potrebbe anche essere combinata con componenti addestrati. Un modello appreso potrebbe gestire il linguaggio ambiguo mentre una sottorete costruita impone un calcolo o un protocollo. Questa possibilità resta speculativa e tecnicamente difficile.

I ricercatori di sicurezza dovrebbero osservare anche i formati di checkpoint standard. Gli scanner di modelli esistenti si concentrano spesso su codice serializzato, caricamento non sicuro o file sospetti. I pesi costruiti direttamente introducono comportamento senza distribuire codice eseguibile convenzionale.

Questo non rende torchwright malevolo. Il suo codice sorgente e il suo intento sono insolitamente aperti. La lezione più ampia è che “nessun codice personalizzato” non significa “nessun comportamento programmato”.

Gli sviluppatori dovrebbero inoltre evitare di trattare il numero di parametri come un punteggio di intelligenza. Questo checkpoint ha 21 miliardi di parametri perché il suo compilatore mappa un renderer in un’architettura ingombrante. La sola dimensione rivela poco sulla conoscenza appresa o sul ragionamento utile.

Per i lettori di Cursor Horizon, l’insegnamento pratico è un modello mentale più preciso dei transformer. L’addestramento è un modo per impostarne i pesi. La compilazione è un altro, anche quando il risultato è estremamente inefficiente.

Il progetto è più prezioso come argomento eseguibile. Mostra che l’infrastruttura familiare dei modelli può ospitare programmi deterministici, non solo memorie statistiche. Mostra anche perché i computer convenzionali restano eccezionalmente bravi nel calcolo convenzionale.

Provate a leggere la traccia di esecuzione, a ispezionare il grafo del compilatore o a riprodurre il checkpoint più piccolo. Poi ponete la domanda che conta oltre Doom: quali algoritmi traggono davvero vantaggio dall’esecuzione nativa per transformer e quali diventano soltanto costose curiosità?