WorldTUI: Un Modello da 360M Che Simula un Terminale Senza Shell

Simon Edwardsson, uno sviluppatore noto per i suoi esperimenti stravaganti con l'AI, ha svelato WorldTUI, un modello linguistico da 360 milioni di parametri ottimizzato per simulare un terminale. A differenza dei tradizionali emulatori di terminale, non c'è una shell o un filesystem dietro di esso: ogni pressione di tasto viene inserita e il modello prevede come cambia lo schermo. Il risultato è un terminale interattivo e convincente in grado di creare file, eseguire vim e tmux, giocare a snake e persino ricordare ciò che hai scritto pochi comandi prima.

La demo è disponibile nel browser (download da 208 MB) e viene eseguita interamente in locale tramite WebGPU. È meglio utilizzarla in Chrome o Edge su un desktop con una tastiera fisica. Come dice Edwardsson: "Provala nel tuo browser e digita pythoon per vedere che non è una shell reale."

Da Genie 3 a un Modello del Mondo del Terminale

L'ispirazione di Edwardsson è venuta da Genie 3 di DeepMind, che genera mondi di gioco a partire da testo o immagini. Voleva addestrare il proprio modello del mondo, ma non disponeva di enormi cluster GPU e dati video. Così ha ridimensionato il progetto: invece di un mondo di gioco, ha scelto un terminale, una griglia di caratteri anziché pixel. Questa scelta è stata pragmatica: poteva generare dati di addestramento etichettati illimitati eseguendo shell reali, e un modello linguistico preaddestrato sa già cosa dovrebbero stampare comandi come ls o cat.

La domanda centrale era se il modello potesse mantenere un mondo coerente, non solo generare output convincenti. Il modello finale, basato su Qwen2.5-Coder-0.5B, è stato ottimizzato su sessioni di terminale registrate da programmi reali all'interno di Docker. L'addestramento ha richiesto circa 75 ore GPU su una RTX 4090.

Come Vede un Terminale

I LLM standard prevedono token di testo in sequenza, ma un terminale non è lineare. Una singola pressione di tasto come esc in vim cambia le modalità, e clear cancella lo schermo. Così Edwardsson ha trattato il terminale come una griglia di caratteri, con il modello che prevede le modifiche alla griglia anziché un flusso di testo.

Ogni sessione inizia con un'istantanea: dimensioni dello schermo, contenuti e posizione del cursore. Ad esempio, un prompt potrebbe essere codificato come BOS SCREEN_START 32 96 ROW_0 0 'simedw@laptop:~$ ' CURSOR 0 17 1 SCREEN_END. Successivamente, ogni pressione di tasto viene fornita come byte grezzi (ad esempio, Invio come \r, Escape come 0x1b). Il modello restituisce quali righe riscrivere e dove finisce il cursore.

Per gestire lo scorrimento in modo efficiente, Edwardsson ha aggiunto un'operazione COPY che copia le righe dallo schermo precedente. Uno scorrimento ora costa tre token per riga invece di circa 96. Il modello utilizza un vocabolario ridotto di 333 token: 256 token di byte, 64 token di riga e alcune operazioni speciali. La decodifica è vincolata dalla grammatica, garantendo che ogni previsione sia un aggiornamento valido dello schermo.

Dati di Addestramento: Sessioni Sintetiche da Docker

Edwardsson non ha trovato dataset esistenti con un allineamento preciso tra pressione dei tasti e schermo, quindi ha creato il proprio. La ricetta prevedeva:

Randomizzazione di nomi utente, hostname, stili di prompt e dimensioni del terminale.
Randomizzazione di directory e file basati su personaggi fittizi (sviluppatore, sysadmin, ecc.).
Selezione di 6–24 attività pesate (modifica file, vim, python, tmux).
Tracciamento dello stato in modo che le sessioni aprano per lo più file esistenti.
Digitazione come un umano: una pressione di tasto alla volta, con completamento tramite tab e un tasso di errori di battitura dell'1,2%.
Avvio del 35% delle sessioni a metà per forzare l'apprendimento da qualsiasi stato.

Il dataset finale includeva 336.000 episodi, circa 2 miliardi di token. Per confronto, il modello base ha visto circa 18 trilioni di token durante il preaddestramento.

Addestramento e Autocorrezione

Edwardsson ha inizialmente utilizzato un semplice addestramento supervisionato: data una cronologia dello schermo e una pressione di tasto, prevedere il delta dello schermo. La digitazione ordinaria è stata appresa rapidamente, ma gli errori si accumulavano in sessioni più lunghe. Per risolvere questo problema, ha adottato un approccio in stile DAgger:

Scegliere un punto in una sessione registrata.
Lasciare che il modello preveda i successivi 1-4 eventi.
Confrontare lo schermo risultante con quello reale.
Se la differenza è piccola, costruire una correzione che ripari lo schermo del modello alla successiva pressione di tasto.
Continuare l'addestramento sul fotogramma corretto.

Questo ha insegnato al modello a riparare i propri errori. Circa un terzo delle sessioni campionate ha prodotto correzioni utili. Questa tecnica, insieme a dati aggiuntivi, ha migliorato i punteggi PresetBench da 24/47 a 38/47 con quantizzazione int4.

continua a leggere sotto...

Prestazioni e Memoria

Edwardsson ha testato il modello su tre benchmark: ShellBench (106 comandi), PresetBench (47 casi scriptati) e un test di memoria (32 mondi con letture di file). I risultati sono stati impressionanti:

ShellBench: WorldTUI ha ottenuto 80/106, contro 52 per Qwen2.5-Coder con prompt e 60 per Qwen3-0.6B.
Test di memoria: WorldTUI ha indovinato 9/13 letture, contro 2/13 e 3/13 per i modelli di base.

Tuttavia, è ancora lontano da un filesystem affidabile. Combinare comandi in modi nuovi può causare problemi; ad esempio, dopo echo green >> colors, eseguire cat colors spesso non mostra la riga aggiunta.

Renderlo Veloce: Righe Parallele e Decodifica Speculativa

La decodifica autoregressiva iniziale era troppo lenta: un ridisegno completo richiedeva fino a 12 secondi su una RTX 4090. La svolta di Edwardsson è stata rendersi conto che la maggior parte delle righe in un fotogramma sono indipendenti. Eseguendo un elemento batch per riga, il costo di decodifica è sceso dalla somma di tutte le righe (~3.000 passi) alla lunghezza della riga più lunga (~100 passi). La latenza p95 per fotogrammi grandi è scesa da 6,7 secondi a 0,87 secondi.

Tuttavia, l'indipendenza ha causato problemi di coordinazione: vim potrebbe aprirsi sulla riga 3 invece che sulla riga 0, o più righe aggiungerebbero cibo in snake. La soluzione è stata la decodifica speculativa, in cui le righe parallele producono una bozza e il modello la verifica in sequenza. Nel browser su un Mac M4, la digitazione richiede circa 60 ms, e un aggiornamento più grande come man test richiede 0,9 secondi con la bozza parallela.

Ridurre il Modello per il Browser

Per essere eseguito in un browser, Edwardsson ha eliminato quasi l'intera tabella di embedding da 151.936 token (136 milioni di parametri), mantenendo solo i 333 token necessari. Questo ha ridotto il modello da 494 milioni a circa 360 milioni di parametri (da 990 MB a 716 MB). La quantizzazione int4 lo ha portato a 208 MB, abbastanza piccolo per un decoder WGSL/WebGPU personalizzato.

Ha anche sperimentato con la distillazione, ma ha scoperto che rimuovere il layer 7 influiva a malapena sull'accuratezza del token successivo (dal 99,3% al 98,9%) ma faceva crollare le letture di memoria da 64/64 a 0/64. Uno studente a 16 layer che manteneva i layer chiave superava tutti i test di memoria ma otteneva punteggi inferiori su ShellBench (65 contro 78). Alla fine, ha rinunciato alla distillazione.

Cosa Può Fare e Cosa Non Può Fare

WorldTUI eccelle nel mantenere un mondo coerente in sessioni brevi. Può creare file, modificarli in vim, salvarli e leggerli in un altro pannello di tmux. Gestisce il REPL di Python con operazioni semplici, anche se quelle complesse producono allucinazioni. È anche indulgente con gli errori di battitura: pythoon avvia Python, ma ython no.

I limiti includono: nessun accesso a Internet (quindi strumenti come lynx sono noiosi), le directory annidate possono confonderlo e Firefox è circa 20 volte più lento di Chrome a causa delle differenze in WebGPU.

Perché è Importante

WorldTUI è una prova di concetto che i modelli del mondo possono funzionare per applicazioni interattive senza regole esplicite. Come nota Edwardsson: "È ovviamente un modello del mondo piuttosto debole, e mi piacerebbe vedere fino a che punto questo approccio potrebbe arrivare con una migliore coerenza e un modo diverso di generare aggiornamenti dello schermo." Prevede di addestrarsi su migliaia di applicazioni generate casualmente per vedere se il modello può prevedere il comportamento di app mai viste.

Il progetto evidenzia anche tecniche pratiche per l'AI su dispositivo: riduzione del vocabolario, quantizzazione int4 e decodifica parallela. Queste sono lezioni che potrebbero applicarsi a qualsiasi sistema AI interattivo in esecuzione in ambienti con risorse limitate.

I pesi saranno pubblicati presto e la demo è attiva. Provatela, cercate di romperla e vedete con i vostri occhi.