L'emulatore NES di Qwen compila la logica della CPU Nintendo in circa 1 GB di pesi
Il progetto dell'emulatore NES di Qwen, nesformer, racchiude una CPU Nintendo in 933 MB di pesi del modello compilati, secondo il suo repository. Le dimostrazioni includono Super Mario Bros., ma software esterno continua a disegnare lo schermo e a gestire i controller. La distinzione è importante: si tratta di un esperimento di calcolo programmato all'interno di un'architettura di modello, non di un chatbot che impara i giochi Nintendo.
Lo sviluppatore Drew Breunig ha condiviso il progetto su Hacker News, dove il titolo descriveva un Nintendo funzionante in circa 1 GB di pesi Qwen. Il repository avanza un'affermazione più circoscritta e interessante. Un compilatore costruisce la logica del processore e i token generati ne portano avanti l'esecuzione. I risultati pubblicati richiedono una riproduzione indipendente, ma il progetto fornisce codice e percorsi di verifica espliciti.
Il punto di riferimento è Qwenputer, il precedente esperimento di Divyansh Agrawal che incorpora un processore nell'architettura di Qwen. Entrambi i progetti pongono una domanda agli sviluppatori che costruiscono sistemi di IA: quali operazioni appartengono al calcolo del modello e quali al software convenzionale? Nesformer rende visibile questa domanda attraverso giochi familiari, documentando al contempo notevoli limiti di velocità e compatibilità.
L'emulatore NES di Qwen esegue una CPU, mentre un host completa la console
L'affermazione centrale di nesformer riguarda la CPU Nintendo e la sua memoria, anziché ogni componente di una console completa. Questo confine definisce sia il risultato ottenuto sia i suoi limiti.
Il progetto afferma di collocare il core del processore 6502 del NES all'interno di un checkpoint di modello compatibile con Qwen, una raccolta salvata di parametri del modello. Colloca inoltre la memoria operativa e i dati del programma della cartuccia nello stato interno variabile del modello.
La distinzione tra parametri e stato è importante. I parametri specificano il comportamento della macchina; lo stato conserva le informazioni che cambiano durante l'esecuzione del gioco. Definire tutto “pesi” comprime queste diverse responsabilità in un titolo accattivante.
Secondo il design della CPU compilata, il modello genera token, simboli discreti in uscita, che rappresentano il registro di esecuzione del processore. Questi simboli descrivono operazioni anziché normale testo conversazionale.
Un programma host fornisce il comportamento della console circostante. Renderizza la grafica, elabora gli input del controller e fornisce gli eventi associati alla temporizzazione del display. Input e output attraversano il confine tramite il registro di esecuzione.
Questa configurazione attribuisce al modello un ruolo sostanziale senza collocare al suo interno l'intero sistema Nintendo. Un'immagine in movimento da sola nasconderebbe questa divisione. La descrizione dell'architettura nel repository rende la divisione ispezionabile.
L'implementazione del processore copre tutti i 151 opcode ufficiali, le istruzioni codificate che indicano al processore quale operazione eseguire. Include aritmetica, ramificazioni, flag del processore e comportamento dello stack.
L'architettura di memoria documentata include 2 KB di RAM operativa, memoria che il gioco in esecuzione può modificare. Include anche 32 KB di ROM di programma della cartuccia, i dati di programma memorizzati.
Il programma della cartuccia viene caricato nello stato all'avvio dell'esecuzione. Di conseguenza, il progetto afferma che i giochi supportati possono condividere gli stessi pesi compilati senza ricostruire il processore per ogni titolo.
Questa è una distinzione significativa rispetto alla preparazione di un'animazione separata per ogni dimostrazione. L'artefatto previsto è un'implementazione riutilizzabile del processore con un intervallo di compatibilità limitato.
L'esempio pubblicato di Super Mario Bros. offre una scena riconoscibile. I giochi di test inclusi forniscono un punto di partenza più utile per la verifica, perché i relativi file e le informazioni sulle licenze accompagnano il progetto.
Le azioni del controller possono seguire uno script che specifica quando premere i pulsanti. La sequenza Mario documentata avvia il gioco, si sposta a destra e salta a intervalli programmati.
Questo non dimostra che un agente IA abbia imparato a giocare a Mario. È l'affermazione che una logica del processore compilata può eseguire le istruzioni del gioco ricevendo input prescritti.
Il ruolo di Nintendo qui è quello di obiettivo hardware e riferimento videoludico. Il repository presenta un esperimento indipendente, non un prodotto Nintendo né una partnership annunciata con Qwen.
La pubblicazione modifica quindi ciò che gli sviluppatori possono ispezionare: un'implementazione pubblica collega parametri del modello, comportamento del processore e output visibile del gioco. Il suo significato si basa su questa connessione ispezionabile.
La logica compilata cambia ciò che la dimostrazione dice sull'IA
Il meccanismo importante è la costruzione deliberata: i pesi compilati di nesformer codificano il comportamento del processore senza addestrare un modello a scoprirlo.
L'addestramento normalmente modifica i parametri usando esempi e un processo di ottimizzazione. La compilazione traduce un design specificato in un'altra rappresentazione eseguibile. Il repository di nesformer afferma che il suo compilatore calcola direttamente i parametri.
Questo rende il progetto diverso dal chiedere a un chatbot preaddestrato di imitare un processore. Il compilatore fornisce le regole, mentre l'architettura del modello fornisce il meccanismo matematico che le esegue.
Il risultato non dovrebbe essere interpretato come prova che un modello Qwen conversazionale comprenda segretamente l'hardware Nintendo. Né la dimostrazione stabilisce che la generazione di linguaggio ordinaria sia diventata un sostituto esatto del software.
Esplora invece se gli stessi blocchi architetturali possano supportare una macchina digitale specificata deliberatamente. È una questione di rappresentazione ed esecuzione, le cui implicazioni più ampie richiedono ancora esperimenti.
Il componente chiave è Gated DeltaNet, un meccanismo di modello che mantiene una matrice di memoria interna variabile. Nesformer utilizza quello stato per archiviare le informazioni della macchina attraverso token generati successivamente.
Il suo design assegna posizioni di memoria a righe all'interno di queste matrici. Letture e aggiornamenti costruiti con attenzione consentono a registri del processore, memoria operativa e dati della cartuccia di occupare tali posizioni.
Un registro, una piccola posizione di archiviazione usata direttamente dal processore, deve conservare un valore esatto finché un'istruzione non lo modifica. Un richiamo approssimativo corromperebbe l'esecuzione.
Il compilatore mappa inoltre la decodifica delle istruzioni e l'aritmetica nei livelli del modello. Un forward pass, il calcolo che produce il successivo output, fa avanzare la macchina codificata nel suo registro di esecuzione.
Il progetto riporta che la maggior parte delle istruzioni richiede un singolo token. Alcune necessitano di registri più lunghi e la media documentata per il codice di gioco varia da 1,1 a 1,3 token per istruzione.
Questa relazione collega una misura familiare delle prestazioni del modello a un carico di lavoro computazionale convenzionale. Generare token più rapidamente è importante perché la sequenza di token trasporta l'esecuzione del processore, anziché limitarvisi a descriverla in seguito.
Qwenputer ha fornito la base tecnica immediata. Il resoconto di Agrawal sul calcolo nel modello, pubblicato il 22 ottobre 2026, descrive la compilazione della logica del processore e l'uso dello stato interno come memoria.
Il confronto tra Qwenputer e nesformer comincia quindi dalla continuità. Nesformer riutilizza il precedente compilatore e la tecnica di memoria, poi prende di mira il processore NES e lo collega a un comportamento host specifico della console.
I loro design circostanti differiscono. Agrawal descrive il mantenimento dei pesi linguistici originali di Qwen con l'aggiunta di meccanismi di calcolo. Nesformer pubblica un checkpoint più piccolo e focalizzato sul processore, con una diversa disposizione dei livelli.
Questa distinzione evita una conclusione fuorviante sulle dimensioni. Il download di nesformer non dimostra che un modello Qwen conversazionale completo, più un Nintendo completo, rientri nell'ingombro indicato dal titolo.
Stabilisce una proposizione più delimitata: componenti architetturali selezionati di Qwen possono ospitare un design di processore compilato. Se ciò diventerà utile nei prodotti di IA generalisti rimane una questione ingegneristica aperta.
L'esecuzione convenzionale resta il parametro di riferimento per l'utilità
Nesformer crea un'alternativa architetturale, ma le sue prestazioni pubblicate lasciano il software convenzionale come standard pratico per eseguire i giochi.
Il confronto immediato è tra l'esecuzione delle istruzioni in codice ordinario di emulazione e l'espressione della loro esecuzione tramite operazioni del modello. Un risultato visibile non stabilisce quale percorso sia utile.
Un emulatore, software che riproduce il comportamento di un'altra macchina, ha già un compito chiaro in questo caso. Deve eseguire accuratamente programmi compatibili e fornire i relativi output a una velocità accettabile.
Nesformer aggiunge un altro obiettivo: eseguire il processore tramite una rappresentazione dei parametri compatibile con il modello. Questo obiettivo spiega l'esperimento anche quando l'esecuzione convenzionale rimane più efficiente.
Il repository riporta circa 1.650 token al secondo per il suo motore ottimizzato predefinito su un singolo core del processore. Riporta circa 210 token per il suo motore numerico più semplice.
Il suo percorso standard Transformers raggiungerebbe circa 10 token al secondo. Transformers è la libreria software per l'esecuzione dei modelli usata per caricare ed eseguire il checkpoint pubblicato.
Queste cifre descrivono diversi percorsi di esecuzione. Non dovrebbero essere riunite in un'unica affermazione sulle prestazioni del modello standard né trattate come un confronto controllato su hardware non specificato.
Il motore predefinito salta i blocchi i cui parametri sono zero. Questo conta perché la maggior parte dei parametri del checkpoint è zero, rendendo la sua struttura insolitamente adatta a un'esecuzione specializzata.
Il repository descrive inoltre il salto dei cicli ripetuti di inattività quando non eseguono scritture in memoria o input-output. Questi cicli attendono il successivo evento di visualizzazione rilevante.
Quell'ottimizzazione riduce il lavoro non necessario, ma deve figurare in qualsiasi spiegazione delle cifre di velocità. L'host aiuta a evitare la ripetizione di calcoli che non modificherebbero il comportamento visibile.
Anche con queste ottimizzazioni, il progetto riporta un funzionamento da 150 a 290 volte più lento rispetto alla console originale. La stima per 600 frame è di circa 25 minuti.
Quei 600 frame rappresentano 10 secondi di tempo NES nell'esempio documentato. La dimostrazione riguarda quindi l'esecuzione eventuale, non una sostituzione reattiva per giocare normalmente.
Questo pone l'onere pratico sui sostenitori del calcolo all'interno dei pesi del modello. Devono identificare vantaggi che giustifichino il lavoro di esecuzione aggiuntivo e la complessità di integrazione.
I potenziali vantaggi richiedono misurazioni anziché supposizioni. Mantenere un'operazione all'interno del calcolo di un modello è una proprietà architetturale; non migliora automaticamente latenza, affidabilità o usabilità.
La pressione immediata ricade sulle affermazioni di ricerca e sul design della valutazione, non sulle aziende esistenti di emulatori. Nesformer non fornisce prove che gli emulatori convenzionali siano minacciati da una sostituzione.
Uno sviluppatore che considera meccanismi simili dovrebbe confrontare i percorsi completi. Caricare lo stato, far avanzare l'esecuzione, gestire gli input e leggere gli output incidono tutti sul risultato vissuto da un utente.
Il confronto tra Qwenputer e nesformer rafforza questa necessità di precisione. Diversi obiettivi di processore, componenti circostanti e motori di esecuzione impediscono semplici classifiche basate sulle dimensioni del checkpoint o sul throughput indicato dal titolo.
Per ora, il percorso convenzionale fornisce sia l'alternativa pratica sia il comportamento di riferimento. Nesformer merita attenzione perché rende ispezionabile un altro percorso, senza stabilire che debba sostituire quello esistente.
I test sono più informativi dell’animazione di Mario
L’evidenza più solida è il confronto stratificato del progetto con il comportamento di riferimento, sebbene i risultati pubblicati restino riportati dagli autori.
Un’animazione di un gioco dimostra che è apparso qualcosa di riconoscibile. Non rivela se le istruzioni siano state eseguite correttamente, se un sistema di riferimento abbia fornito correzioni o quale software abbia prodotto ciascun fotogramma.
La documentazione di Nesformer separa queste domande. Descrive controlli per il processore di riferimento, il circuito compilato, il checkpoint salvato e sequenze di esecuzione più lunghe.
La distinzione inizia con la CPU di riferimento, l’implementazione convenzionale usata come risultato atteso. Un riferimento difettoso potrebbe rendere meno significativo il fatto che gli output coincidano.
Il repository riferisce di aver confrontato quel riferimento con nestest, un test di conformità del processore con registri di esecuzione attesi. Dichiara che il riferimento corrisponde a 3.348 istruzioni nell’ambito supportato.
Riferisce inoltre un confronto con py65, un altro emulatore di processore, su 5,7 milioni di istruzioni di codice di gioco. Ciò fornisce un controllo aggiuntivo dell’implementazione di riferimento.
Il circuito compilato riceve quindi confronti propri. La documentazione riferisce concordanza su nestest e su 283.610 posizioni nelle sequenze di avvio di due giochi.
Questi risultati riguardano il comportamento del circuito specificato. Da soli, non dimostrano che un modello salvato produca risultati identici attraverso ogni motore di esecuzione.
Il repository riferisce quindi un controllo separato su Transformers standard che copre 2.651 posizioni da nestest e Full Game. Riferisce l’assenza di discrepanze in quel campione.
Il controllore del checkpoint standard mostra come funziona questo confronto. Carica il modello, inizializza lo stato della macchina e confronta gli output previsti con una sequenza di riferimento fornita.
Questo metodo usa il teacher forcing, che alimenta l’output precedente noto in ogni fase del confronto. Verifica previsioni locali senza dimostrare un’esecuzione autonoma e ininterrotta altrettanto lunga.
L’esecuzione a ciclo libero alimenta invece il sistema con i propri output. Un errore può modificare lo stato successivo, quindi la concordanza su una sequenza prolungata risponde a una diversa domanda di verifica.
Il progetto riferisce un’esecuzione a ciclo libero di Thwaite che copre 1.916.527 token e 600 fotogrammi. Afferma che tutti i 300 fotogrammi salvati corrispondono all’output di riferimento.
Per Full Game, riferisce 2.645.885 token e 420 fotogrammi. La documentazione afferma che tutti i 210 fotogrammi salvati corrispondono.
Questi conteggi sono specifiche affermazioni di evidenza, non una garanzia universale. Riguardano giochi, sequenze di input, percorsi di esecuzione e durate particolari.
I test di verifica del processore espongono confronti automatizzati per il riferimento, il circuito, i motori di esecuzione e l’ottimizzazione dei cicli inattivi. La loro disponibilità rende possibile una riproduzione mirata.
Tuttavia, leggere i test è diverso dall’eseguirli. Questa analisi ha esaminato l’implementazione e la documentazione pubblicate; non ha eseguito in modo indipendente il checkpoint né riprodotto le prestazioni riportate.
La distinzione dovrebbe sopravvivere alla diffusione della storia. Il progetto offre più prove di una dichiarazione social non supportata, ma codice pubblico e concordanza riportata dagli autori non equivalgono a una validazione indipendente.
Per l’emulatore NES di Qwen, il prossimo passo credibile è una riproduzione più ampia con motori di esecuzione chiaramente identificati. Un’animazione più grande aggiungerebbe meno fiducia di una traccia documentata che coincide.
Il titolo da 1GB nasconde sia l’archiviazione sparsa sia l’hardware mancante
La dimensione del checkpoint è reale come impronta di file riportata, ma non descrive una console completa né la memoria totale a runtime.
Il repository elenca 466,6 milioni di parametri archiviati in bfloat16, un formato numerico che usa 16 bit per valore. Indica l’impronta risultante dei parametri come 933 MB.
Secondo la documentazione, solo 9,3 milioni di parametri sono diversi da zero. Il progetto afferma che questa regolarità consente di comprimere i pesi in un archivio da 3,3 MB.
Si tratta di quantità diverse. Un download di archivio, un file di parametri espanso e la memoria consumata da un processo in esecuzione rispondono a domande operative differenti.
La descrizione approssimativa dell’articolo di 1GB riguarda i pesi espansi. Non dovrebbe trasformarsi nell’affermazione che l’applicazione completa richieda soltanto quella quantità di memoria.
La struttura sparsa modifica anche l’interpretazione delle prestazioni. Un motore specializzato che evita blocchi di zeri svolge un lavoro diverso da un’implementazione che elabora l’intero layout dei parametri.
Questo non invalida l’affermazione sul checkpoint. Significa che compatibilità, archiviazione ed efficienza di esecuzione richiedono misurazioni separate invece di un unico titolo compresso.
Il confine hardware impone un’ulteriore precisazione. L’unità di elaborazione grafica, il componente NES responsabile del comportamento grafico, rimane nel software host.
Anche l’unità di elaborazione audio, l’hardware sonoro della console, è esterna ai pesi. Il repository afferma che l’implementazione attuale non produce alcun suono.
Anche la fedeltà grafica presenta limiti. L’host renderizza scanline, righe orizzontali dell’immagine, e non riproduce effetti che si verificano a metà di una riga.
La documentazione descrive anche un comportamento approssimativo per determinate condizioni di stato degli sprite. Uno sprite è un elemento d’immagine controllato separatamente, usato per personaggi e altri oggetti in movimento.
Il supporto per le cartucce è limitato a NROM, una semplice configurazione della scheda senza commutazione dei banchi di programma. La commutazione dei banchi cambia quale parte di un programma di cartuccia più grande il processore può accedere.
Il design documentato di Nesformer usa una tabella di programma fissa. Supportare cartucce più complesse richiederebbe stato aggiuntivo e logica di selezione degli indirizzi, non soltanto un nuovo titolo in un elenco di compatibilità.
Le restrizioni di esecuzione si estendono oltre il formato della cartuccia. Le istruzioni non ufficiali non supportate arrestano il sistema e il codice deve essere eseguito dalla memoria della cartuccia anziché dalla RAM di lavoro.
Il progetto elenca inoltre comportamenti di interrupt mancanti, segnali che fanno rispondere il processore a eventi hardware. Alcuni eventi supportati funzionano, ma la copertura documentata è incompleta.
Questi limiti definiscono il significato di “funzionante”. Un sistema può eseguire correttamente giochi particolari entro un ambito definito restando inadatto a una libreria più ampia.
Impediscono inoltre di generalizzare i test riportati a tutto il software Nintendo. La concordanza sulle istruzioni supportate non colma i comportamenti hardware che l’implementazione omette esplicitamente.
I pesi compilati di nesformer sono quindi valutati al meglio come un artefatto di processore collegato a un’implementazione parziale della console. Questa descrizione preserva l’insolito contributo del progetto senza ampliare le sue affermazioni di compatibilità.
Per gli sviluppatori, la domanda scettica utile è concreta: quale comportamento osservato deriva dalla logica del processore compilato e quale da assunzioni dell’host? Il repository offre ai revisori una mappa iniziale.
Riproduzione indipendente, compatibilità più ampia e velocità dell’intero sistema vengono dopo
La prossima evidenza utile dovrebbe ampliare fiducia, copertura e praticità misurata, in quest’ordine. Questi segnali sono più informativi di un’altra ondata di attenzione.
Per prima cosa, osservate la riproduzione indipendente dei confronti di tracce pubblicati. Un rapporto credibile dovrebbe identificare il checkpoint, gli input di gioco, il motore di esecuzione e il metodo di confronto.
Riprodurre il comportamento di Transformers standard rafforzerebbe l’affermazione che l’artefatto funzioni attraverso la sua interfaccia modello pubblicizzata. Confronti a ciclo libero più lunghi verificherebbero una concordanza sostenuta oltre brevi campioni alimentati dal riferimento.
Una discrepanza richiederebbe una diagnosi anziché un’immediata liquidazione. Comportamento numerico, inizializzazione dello stato, differenze tra motori e funzionalità non supportate sono possibili cause distinte con implicazioni diverse.
In secondo luogo, osservate miglioramenti di compatibilità supportati da test di conformità. Un supporto aggiuntivo per le cartucce sarebbe significativo se l’implementazione documentasse il comportamento della memoria e validasse programmi rappresentativi.
Il suono e una temporizzazione grafica più accurata affronterebbero lacune separate. I revisori dovrebbero distinguere tra trasferire più hardware nei pesi e migliorare l’implementazione convenzionale dell’host.
Entrambi i cambiamenti possono migliorare l’applicazione, ma solo il primo amplia l’ambito dell’affermazione sul calcolo all’interno dei pesi. Confini chiari manterranno interpretabili i confronti futuri.
In terzo luogo, osservate misurazioni complete delle prestazioni su hardware specificato. Una reportistica utile coprirebbe l’avvio, l’esecuzione, il lavoro dell’host e il tempo necessario per produrre la sequenza di gioco richiesta.
Un aumento di velocità limitato a un calcolo selezionato rafforzerebbe un’affermazione più circoscritta. Un’esecuzione completa più veloce nei giochi supportati fornirebbe prove più forti di progresso pratico.
La discussione per sviluppatori di Breunig offre un’altra prospettiva sul significato del progetto. Egli attribuisce allo sviluppo assistito dall’IA il merito di materiale di riferimento esistente, un compilatore precedente e test di conformità.
I commentatori favorevoli hanno sottolineato il valore di tali controlli di riferimento. I partecipanti scettici hanno messo in dubbio l’efficienza della traduzione del codice in operazioni del modello invece dell’esecuzione diretta del normale codice.
Nessuna delle due reazioni risolve la questione ingegneristica. Insieme, identificano il valore immediato del progetto: un esperimento con output visibili, confini espliciti e comportamenti che altri sviluppatori possono verificare.
Per gli ingegneri, questo evidenzia anche il valore di mantenere una base di conoscenza ricercabile contenente specifiche, implementazioni di riferimento e prove di test. Tale materiale supporta la revisione oltre che l’implementazione.
Iniziate dal percorso di verifica anziché dall’animazione quando valutate l’emulatore NES di Qwen. Confrontate ciò che il checkpoint calcola con ciò che l’host fornisce, quindi esaminate le tracce di esecuzione riportate. Tenete separati dimensione del file, memoria a runtime e velocità dell’applicazione completa. Se seguite il progetto, cercate esecuzioni indipendenti corrispondenti prima di trattare i risultati pubblicati come consolidati. Poi osservate se la compatibilità si espande attraverso comportamenti testati di processore e cartucce, oppure principalmente tramite modifiche al software circostante. Queste distinzioni consentono agli sviluppatori di apprezzare l’esperimento prendendo al contempo decisioni solide sulla sua rilevanza. Quale prossimo risultato cambierebbe maggiormente la vostra valutazione: riproduzione indipendente, copertura hardware più ampia o una riduzione misurata del tempo di esecuzione completo?
