Tech Teardown 036 | Nesformer: Ein NES in den Qwen-Gewichten

Hintergrund/Phänomen

Am 30. Oktober 2026 erschien auf GitHub ein Projekt namens Nesformer. Seine Selbstpräsentation war sehr direkt: „An NES CPU compiled into the weights of a stock Qwen3.5 model.“ Das bedeutet, der Autor hat kein Spiel-AI trainiert und keinen traditionellen Simulator geschrieben, sondern den CPU von der Nintendo Entertainment System in die Gewichte des Qwen3.5 integriert. Das gesamte Modell wurde nicht feinjustiert, alle Parameter wurden direkt vom Compiler berechnet.

Dieser Vorgang erregte schnell die Aufmerksamkeit in der Technikwelt, da es die Frage „Kann das Gewicht eines großen Modells als einen Computer verwendet werden?“ auf eine extreme Stufe brachte. In der Vergangenheit betrachteten wir LLMs eher als Chattools und die Gewichte als eine Ansammlung trainierten statistischer Regeln. Nesformers Vorgehen war sozusagen ein Zeichen dafür, dass Gewichte nicht nur statistische Container für Sprache sind, sondern auch direkt eine vollständige Spielkonsolen-CPU kodieren können.

Sein Vorläufer ist Divyansh Agrawals Qwenputer. Letzterer hat bereits CHIP-8- und RISC-V-CPUs in Qwen3.5-4B integriert, was die Machbarkeit dieser Idee beweist. Nesformer hat das Objekt in ein komplexeres NES ersetzt, also den in den 80er Jahren weltweit beliebten Amiga. Von CHIP-8 über RISC-V bis zum NES steigt die Komplexität stetig, und der Nutzen der Konzeptverifizierung wird immer deutlicher.

Das NES selbst ist nicht kompliziert: Ein Ricoh 2A03-Prozessor mit 1.79 MHz (kompatibel mit MOS 6502), 2 KB Speicher, PPU für Bildausgabe, APU für Sound. Aber um ein solches System in die LLM-Gewichte zu integrieren, ist es notwendig, eine vollständige Übersetzung zwischen der CPU-Instruction-Suite, der Speicheradressierung und der I/O-Mapping vorzunehmen. Der Autor dbreunig wählte das NES, weil es klassische Spiele zur Demonstration bietet und weil es komplex genug ist, um die Grenzen der These „Gewichte sind Computer“ wirklich zu testen.

Nachdem dieses Projekt auf Hacker News in Form eines Show HN veröffentlicht wurde, erhielt es schnell viele Diskussionen. Einige waren begeistert von seiner Kreativität, andere stellten seine praktische Nutzbarkeit in Frage. Aber unabhängig von der Position stimmten die meisten zu: Es hat zumindest auf ingenieurtechnischer Ebene etwas, das wie Science-Fiction klingt, in lauffähigen Code verwandelt.

Technischer Prinzip/Architektur

Der Kerngedanke von Nesformer ist es, den CPU-, RAM- und ROM-Teil des großen Modells vollständig zu integrieren. Das gewählte Basismodell ist Qwen3.5-4B, wobei die tatsächliche Struktur stark reduziert wurde: Nur 7 Gated DeltaNet-Schichten sowie eine Schicht mit vollkommenen Nullen für die Attention-Funktion werden beibehalten, um die Anforderungen von HuggingFace an den Cache zu erfüllen. Die Gesamtzahl der Parameter beträgt 466,6 Mio. bf16, aber nur 9,3 Mio. Parameter sind nicht null, und nach Komprimierung beträgt das Gewicht nur 3,3 MB.

Der Schlüssel zum Trick liegt in der Zustandsmatrix von Gated DeltaNet. Der Autor betrachtet jede Zeile der Zustandsmatrix als eine adressierbare Speicherzelle und setzt gate=1 ein, um eine Abnahme zu verhindern, write strength=1, um eine vollständige Abdeckung zu gewährleisten, und verwendet anschließend einen one-hot-Key für die präzise Positionierung. So kann jeder Eintrag genau eine Zeile abdecken, was das Verhalten von CPU-Registern, RAM und ROM simuliert.

Konkret sind in den Modellgewichten alle 151 offiziellen opcode des NES 6502-CPU, alle Adressierungsmöglichkeiten, Flaggen, der Stack sowie die Eingangsbefehle BRK/NMI kodiert. 2 KB ArbeitsRAM, 32 KB PRG-ROM (zwei Versionen gespeichert: eine für Instruktionen, eine für Daten), sowie 256 Bytes OAM-DMA werden in das Modell eingebettet. Die Verarbeitung auf der PPU-Ebene, die Eingabe des Controllers, die Einrichtung der APU-Register und die Injektion des vblank-NMI werden von einer externen Host.py-Datei übernommen.

Mit anderen Worten, Nesformer teilt die Ausführung von NES-Spielen in zwei Teile auf: Das Modell selbst ist für die CPU-Exekution und den Zustandsupdatierung des Speichers zuständig, während das Modell extern den Token-Strom in Bildschirmpixel und Benutzerinput umwandelt. Diese Aufgabenverteilung ermöglicht es den Gewichten, die Rechenaufgaben zu übernehmen, während der Host nur dafür verantwortlich ist, die Ergebnisse visuell darzustellen.

Im Gegensatz zu traditionellen Simulatoren, die opcode durch Iterationen interpretieren, nutzt Nesformer die gesamte CPU-Zustandsmaschine als Matrizenmultiplikation. Jeder Vorwärtsprozess entspricht einem CPU-Zeitraum, und der Fluss der Tokens entspricht dem Transport von Daten zwischen den Registern und dem Speicher. Die recurrenten Zustände von DeltaNet eignen sich natürlich, um „letzter Zustand + aktueller Eingabe → nächster Zustand“ zu repräsentieren – das ist auch der Grund, warum es die CPU kompilieren kann, anstatt sie zu trainieren.

Auch die Größe des Wortschatzes ist erwähnenswert: 263.808 Tokens. Ein so großer Wortschatz dient nicht der Sprachvielfalt, sondern um CPU-Adressen, Datenbusse und Steuersignale in diskrete Tokens zu kodieren. Wenn ein Token eingegeben wird, kann das Modell die nächste Zustandsänderung basierend auf dem aktuellen Zustand und den Instruktionen vornehmen. Diese Konstruktion sorgt dafür, dass der Vorwärtsprozess des Modells eine direkte Korrespondenz mit den CPU-Zeiträumen hat.

Schlüsseldaten/Beispiele

In Bezug auf die Leistung ist Nesformer noch weit davon entfernt, praktisch zu sein. Seine Geschwindigkeit ist etwa 150 bis 290 Mal langsamer als die echten NES-Systeme. Mit der schnellsten kompilierten Vorwärtsroute mit numba und Optimierungen wie Jump-Zero-Block kann das Modell auf einem Kern etwa 1.650 Tokens pro Sekunde ablaufen; bei der traditionellen Stock-Transformers-Route sind es nur 10 Tokens pro Sekunde. Ein echtes NES-System benötigt für eine vollständige Frame-Laufzeit etwa 700.000 Tokens pro Sekunde – der Unterschied ist offensichtlich.

Bezüglich der Validierung der Daten haben die Autoren mehrere NROM-mapper-0-Spiele getestet, darunter Super Mario Bros. und Donkey Kong. strengere Konformitätstests zeigen, dass der Thwaite 600 bei 1.916.527 Tokens und einer simulierten Zeit von 10,0 Sekunden 300 Bilder pro Sekunde abspielte, die mit dem regulären 6502-Simulator exakt übereinstimmten; Doug Fraker Full Game 420 benötigte 2.645.885 Tokens für ebenfalls exakte Bildabspiele; das Nestest-Konformitätsset erreichte nach 4.586 Tokens den HALT-Zustand. Diese Daten zeigen, dass das Modell auf logischer Ebene tatsächlich das Verhalten des 6502-CPUs nachbildet.

Allerdings stammen alle diese Daten aus dem README, ich habe keine lokale Wiederholungstest durchgeführt, und die Laufgeschwindigkeit wird auch von den Hardware- und Numba-Versionen beeinflusst. Leser, die das tatsächlich nachbilden möchten, müssen zuerst etwa 1 GB des entpackten bf16-Wahrscheinlichkeitsfaktors herunterladen und diesen mit shasum auf SHA-256SUMS überprüfen. Die Konstruktionsumgebung erfordert Python 3.11 oder höher, zusammen mit numpy, scipy, numba und pillow. Der Laufbefehl lautet python -m nesformer run ROM, mit optionalen Parametern wie --frames, --buttons und --show.

Aus Sicht der Kompressibilität ist die Parameterdistribution von Nesformer auch interessant. Von den 466,6 Mio. bf16-Parametern sind nur 9,3 Mio. nicht Null, was eine Dichte von über 98% bedeutet. Nach dem Komprimieren beträgt der gesamte Wahrscheinlichkeitsfaktorkit nur 3,3 MB, was kleiner ist als viele NES-ROMs selbst. Dies zeigt, dass die kompilierten Wahrscheinlichkeitsfaktoren mit sehr wenig effektiver Information eine komplexe deterministische Berechnung ausdrücken können, was zumindest auf theoretischer Ebene das vorherige Vorurteil „Je größer die Parameter, desto besser“ in Frage stellt.

Einfluss/Grundlagen

Der größte Nutzen von Nesformer besteht darin, dass es die Metapher „Wahrscheinlichkeitsfaktoren sind wie Computer“ in eine ausführbare Ingenieurgeschichte verwandelt hat. In der Vergangenheit wurde diskutiert, ob LLMs Rechenoperationen durchführen und Programme ausführen können, meist auf der Ebene von Anweisungen. Nesformer zeigt, dass, wenn die Architektur richtig gestaltet ist, der Zustandsraum eines großen Modells direkt in allgemeine Berechnungs- und Speicherstrukturen kodiert werden kann, ohne jegliche Trainingskosten, alles wird vom Compiler generiert.

Dies bietet zwei Arten von Anregungen für die Forschung über Modellarchitektur. Erstens bestätigt es die Programmierbarkeit der Gated DeltaNet-Zustandsmatrix. Wenn man die Verteilung von Gate, Write-Stärke und Schlüssel gut kontrolliert, kann man den Zustand als adressierbaren Speicher verwenden. Zweitens gibt es einen neuen Ansatz zur Komprimierung: Von den 466,6 Mio. bf16-Parametern sind nur 9,3 Mio. nicht Null, und nach dem Komprimieren beträgt der Umfang nur 3,3 MB, was darauf hindeutet, dass Dichtereduzierung und kompilierende Generierung für bestimmte Aufgaben möglicherweise besser geeignet sind als end-to-end-Training.

Aus einer größeren Perspektive betrachtet, bringt Nesformer zusammen mit Qwenputer das Thema „Eine virtuelle Maschine in den LLM-Wahrscheinlichkeitsfaktoren laufen zu lassen“ zu einer höheren Komplexität. CHIP-8 und RISC-V ähneln eher Lehrmodellen, während NES CPU, Speicher, I/O und Rendering-Koordination umfasst und ein vollständigeres System darstellt. In Zukunft könnte ein ähnlicher Ansatz verwendet werden, um in Modellen komplexere deterministische Berechnungsmodule einzubetten.

Dieses Projekt verschwimmt die Grenzen zwischen „Model“ und „Programm“. In der traditionellen Softwareentwicklung sind Programm und Speicher getrennt; Nesformer haben sie in dieselbe Gewichtung integriert. Wenn sich diese Entwicklungsrichtung fortsetzt, könnten zukünftig Anwendungen entstehen, bei denen ein LLM-Gewicht gleichzeitig Sprachverständnis, Rechenfähigkeit und einen festen Geschäftsregel引擎 enthält. Dabei ist nur ein Datei zur Implementierung erforderlich.

Für die Endgerät-Implementierung ist diese hochdichte kompilierte Gewichtung attraktiv. Wenn zukünftige Handys oder IoT-Geräte eine sehr deterministische Protokollstack oder Zustandsmaschine verwenden müssen, könnte es bequemer sein, sie in das Modellgewicht zu kompilieren als einen separaten Laufzeitbereich zu pflegen. Natürlich muss dabei ein Gleichgewicht zwischen Rechenleistung und Wartbarkeit gefunden werden.

Kontroversen/Risiken

Erstens gibt es ein Leistungsproblem. Es ist 150 bis 290 Mal langsamer als das echte NES, was bedeutet, dass es derzeit nur als Proof-of-Concept dienen kann und noch weit davon entfernt ist, eine echte Spielerfahrung zu bieten. Selbst wenn in Zukunft durch Quantisierung, Kompilieroptimierung oder spezielle Hardwarebeschleunigung die Token-Auslastungsrate von tausend auf hunderttausend oder mehr für echte Systeme gesteigert werden kann, ist es immer noch notwendig, eine Größenordnung zu verbessern.

Zweitens gibt es Probleme mit Wartbarkeit und Skalierbarkeit. Das Kompilieren der CPU in das Gewicht bedeutet, dass jede Fehlerbehebung oder Funktionserweiterung wieder mit dem Compiler durchgeführt werden muss, anstatt wie bei traditionellen Simulatoren nur ein paar Codezeilen geändert zu werden. Für komplexere Spiele wie MMC3 und MMC5 könnte die Größe des Gewichts stark ansteigen, und ob der aktuelle Ansatz skalierbar ist, ist ungewiss.

Drittens gibt es Einschränkungen bezüglich der Bewertungskriterien. Alle Leistungszahlen und Konformitätstests im README des Repos wurden von den Autoren selbst durchgeführt, es gibt keine unabhängige Dritte, die sie wiederholen können. Zudem kann es nur Spiele mit Mapper-0-Status spielen, was eine begrenzte Reichweite bedeutet. Leser müssen bei der Verwendung dieser Zahlen den Hinweis auf „autorisierte Angaben des Autors“ hinzufügen.

Schließlich gibt es ein tieferliegendes Problem: Kann die Integration von deterministischer Berechnung in das LLM-Gewicht tatsächlich engineeringbezogene Vorteile bringen? Für Kompatibilität sind traditionelle Simulatoren offensichtlich schneller und einfacher zu debuggen. Der Wert von Nesformer liegt eher darin, Grenzen zu erkunden, als bestehende Lösungen zu ersetzen.

Außerdem hat diese Methode, deterministische Berechnungen in das neuronale Gewicht zu integrieren, Bedenken hinsichtlich der Erklärbarkeit hervorgerufen. Jede Zeile Code eines traditionellen Simulators entspricht einem klaren Hardwareverhalten, während die Berechnungen im Gewicht stark verteilt sind. Wenn ein System Fehler erleidet, ist die Lokalisierung und Behebung viel schwieriger als bei traditionellen Softwarelösungen.

Schlussfolgerung/Ausblick

Nesformer ist eine hochwertige technische Demonstration. Es trainierte kein Gewicht, sondern integrierte den CPU eines NES in das 7-Schicht-Gated DeltaNet von Qwen3.5 und simulierte damit das Verhalten des 6502-CPUs, der RAM, der ROM und des OAM. Es kann Super Mario Bros. und Donkey Kong spielen, aber die Geschwindigkeit ist zwei Größenordnungen langsamer als auf einem echten System.

Kurzfristig wird dieses Projekt Aufmerksamkeit in den Bereichen Modellarchitektur, Kompilierung und Simulation von Retro-Spielen auf sich ziehen. Es bietet eine reproduzierbare Benchmark, die Forschern ermöglicht, direkt das Maximum des „Zustandsmatrix als Speicher“ zu testen. Mittelfristig könnte, wenn solche Kompilierungsmethoden auf komplexere Mapper und effizientere Rechenwege ausgedehnt werden können, es möglich sein, auf Endgeräten ein Modellgewicht zu realisieren, das mehrere deterministische Funktionen gleichzeitig unterstützt. Langfristig erinnert uns dies daran: Der Gewichtsspace für große Modelle ist viel breiter als Chatten, Zusammenfassungen und Rechenfähigkeiten. Es kann in beliebige Berechnungsstrukturen programmiert werden, solange wir die richtige Kompilierungsmethode finden.

Eine interessante Forschungsrichtung in der Zukunft ist „gemischte Gewichte“: Der Teil der Sprachverständnis und -abwägung wird weiterhin mit traditionellen Trainingsmethoden erstellt, während Module wie sicherheitsbetonte Regeln, Protokollanalyse und State-Machines durch Kompilierung eingebettet werden. Dadurch kann die Flexibilität der neuronalen Netze erhalten bleiben, während gleichzeitig verifizierbar sicheres Verhalten erreicht wird. Nesformer hat bereits gezeigt, dass dieser Weg funktioniert. Nun hängt es davon ab, ob man ihn von einem Spielprojekt zu einer echten ingenieurtechnischen Anwendung weiterentwickeln kann. Ein weiteres ungelöstes Problem ist die Universalität des Compilers: Derzeit wird eine große Anzahl von manuellen Übertragungen für NESs durchgeführt. Ob es möglich ist, dies in eine allgemeinere Werkzeugkette umzuwandeln, die beliebige endliche Zustandsmaschinen in Gewichte kompiliert, wird den Endwert dieser Richtung bestimmen.

Dieses Projekt verwendet das MIT-Lizenzrecht, und sowohl der Code als auch die Build-Anleitungen sind öffentlich zugänglich. Wenn Sie an diesem Ansatz mit „Gewichte als Computer“ interessiert sind, können Sie direkt den Repository klonen und die Schritte in dem README durchführen. Selbst wenn es nicht möglich ist, ein vollständiges Spiel mit höchster Geschwindigkeit zu spielen, ist es dennoch wert, darüber nachzudenken, wie es mit 9,3 Mio. nicht-leeren Parametern ein NES nachbildet.

Unterschrift: Yongliang