Non c'è addestramento, non c'è fine-tuning, non c'è apprendimento per rinforzo. Il checkpoint pubblicato su Hugging Face da physicsrob è un porting diretto dell'algoritmo di rendering di Doom nei pesi di un trasformatore, ottenuto con un compilatore scritto dall'autore, torchwright. Ogni peso è calcolato, nessuno è appreso. Il modello usa un'architettura stock Phi3ForCausalLM, si carica in vanilla transformers con trust_remote_code=False e riceve nel prompt la geometria del livello, la posizione del giocatore e la direzione dello sguardo. La generazione emette istruzioni di disegno che un programma host di 43 righe converte in pixel.

I numeri del checkpoint dicono molto sulla distanza tra esperimento e uso pratico. Per la risoluzione 320x200 servono 21 miliardi di parametri e 85,87 GB di download. Un solo frame è un prompt da 3.614 token più 53.747 token generati: poco meno di 40 minuti su una GPU B200. La versione 80x50 scende a 34 GB ed è quella che l'autore suggerisce di provare.

Qui arriva il vincolo più rilevante per chi guarda al deployment. L'autore dichiara di non aver eseguito il modello in locale: ha usato GPU cloud B200 e A100-80. Il compilatore richiede pesi in fp32 e la quantization non è stata esplorata. Per il checkpoint 80x50 il requisito raccomandato è di 80 GB di memoria GPU; 64 GB potrebbero bastare in teoria, ma il test non è stato fatto. È un dettaglio che sposta il discorso dal software all'hardware: un modello da 34 GB in fp32 non entra in una consumer card da 24 GB e nemmeno in molte workstation single-GPU. La mancanza di quantization toglie il principale strumento con cui di solito si riduce l'impronta di memoria degli LLM.

L'esperimento non va letto come un tentativo di sostituire i motori grafici. Il costo computazionale per frame è enorme e la resa è lontana da qualsiasi approccio tradizionale. Il punto è un altro: i pesi di un trasformatore possono essere usati come descrizione eseguibile di un algoritmo, non solo come risultato di un processo statistico. Non è una novità assoluta, ma qui il risultato è verificabile e deterministico. Non ci sono dataset di addestramento, non c'è deriva, e ogni peso è calcolato dal compilatore. Per contesti regolamentati o air-gapped, un checkpoint con pesi derivati da un programma è più facile da auditare di un modello appreso, anche se il requisito fp32 e l'assenza di quantization ne limitano la portabilità.

Chi perde, nel breve termine, è chi spera di usare questi checkpoint per fare rendering interattivo: il rapporto tra calcolo e risultato è insostenibile. Chi guadagna sono i team che studiano i limiti degli LLM come substrato di calcolo generale e i fornitori di GPU con molta VRAM, perché il vincolo di precisione spinge verso hardware di fascia data center. C'è anche un segnale per il software: basta vanilla transformers con trust_remote_code=False, nessun runtime custom. AI-RADAR dedica spazio a questi trade-off nella sezione /llm-onpremise, ma il punto qui è più elementare: senza quantization il checkpoint resta confinato a GPU con memoria abbondante, cloud o on-premise che siano.