Nesformer: Compiling an NES into Qwen Weights

---

Background/ Phenomenon

On October 30, 2026, a project called Nesformer appeared on GitHub. Its self-introduction was very straightforward: “An NES CPU compiled into the weights of a stock Qwen3.5 model.” In other words, the author did not train a game AI or write a traditional emulator; instead, they compiled a Nintendo Entertainment System’s CPU into the weights of Qwen3.5. The entire model was not fine-tuned; all parameters were calculated directly by the compiler.

This incident quickly caught the attention of the tech community because it pushed the question of “whether large model weights can be considered a computer” to its extreme. In the past, we usually viewed LLMs as chat tools, with weights as a set of trained statistical rules. Nesformer’s approach essentially declared that weights are not just statistical containers for language but can also directly encode the CPU of a complete game console.

Its upstream is Divyansh Agrawal’s Qwenputer. The latter has already compiled CHIP-8 and RISC-V CPUs into Qwen3.5-4B, proving the feasibility of this idea. Nesformer replaced the target with the more complex NES, the red-and-white console that was popular worldwide in the 1980s. From CHIP-8 to RISC-V to NES, the complexity increases step by step, and the significance of proof-of-concept becomes increasingly clear.

The NES hardware itself is not complicated: a Ricoh 2A03 processor at 1.79 MHz (compatible with MOS 6502), 2 KB of memory, PPU for image output, and APU for sound. But to fit such a system into LLM weights, a complete mapping of CPU instruction sets, memory addressing, and I/O mappings is still required. The author dbreunig chose NES because it has classic games to demonstrate, and also because it is complex enough to truly test the boundaries of the proposition that “weights are computers.”

After this project was published on Hacker News as a Show HN, it quickly received a lot of discussion. Some people marveled at its creativity, while others questioned its practical value. But regardless of stance, most agreed: at least at an engineering level, it has turned something that sounded like science fiction into runnable code.

Technical Principles/Architecture

The core idea of Nesformer is to map the CPU, RAM, and ROM all into the state of the large model. The base model chosen was Qwen3.5-4B, with the actual structure significantly trimmed: only 7 layers of Gated DeltaNet are retained, plus one layer of all-zero attention layer to meet HuggingFace’s cache requirements. The total parameter count is 466.6M bf16, but there are only 9.3M non-zero parameters, and the compressed weights zip is only 3.3 MB.

The key trick lies in the state matrix of Gated DeltaNet. The author treats each row of the state matrix as an addressable memory cell, setting gate=1 to ensure no attenuation, write strength=1 to ensure full coverage, and then using one-hot keys for precise positioning. Thus, each write operation can accurately cover a specific row, simulating the behavior of CPU registers, RAM, and ROM.

Specifically, the model weights encode all 151 official opcode of the NES 6502 CPU, all addressing modes, flags, stack, and BRK/NMI entry points. 2 KB working RAM, 32 KB PRG-ROM (stored in two parts, one for instruction fetching and one for data reading), and 256 bytes of OAM DMA are all incorporated into the model. Rendering-related PPU operations, controller input, APU register writing, and vblank NMI injections are handled by an external host.py.

In other words, Nesformer breaks down the process of “running a NES game” into two parts: internally, the model handles CPU execution and memory state updates; externally, it converts token streams into screen pixels and user input. This division allows the weights to truly perform computational tasks, while the host is only responsible for visualizing the results.

Unlike traditional simulators that interpret opcodes through loops, Nesformer converts the entire CPU state machine into matrix multiplication. Each forward propagation corresponds to a CPU cycle, with token flow representing data transfer between registers and memory. DeltaNet’s recurrent state naturally suits discrete-time systems like “last state + current input → next state,” which is why it can incorporate the CPU without training it.

The size of the vocabulary is also noteworthy: 263,808 tokens. This large vocabulary isn’t for linguistic diversity but to encode CPU addresses, data buses, and control signals as discrete tokens. By inputting a token, the model can determine the next state update based on the current state and instructions. This design establishes a one-to-one correspondence between the model’s forward propagation process and CPU clock cycles.

Key Data/Case Studies

In terms of performance, Nesformer is still far from practical. Its speed is about 150 to 290 times slower than a real NES. With numba compilation for the fastest forward path and zero-jump block optimization, it can run at approximately 1,650 tokens per second on a single core; while using the stock transformers path, it can only reach 10 tokens per second. A real NES requires around 700,000 tokens per second to run full frames, highlighting the significant gap.

In terms of validation data, the author verified several NROM mapper games, including Super Mario Bros. and Donkey Kong. More stringent consistency tests showed that Thwaite 600 ran 1,916,527 tokens over 10.0 seconds, with 300 frames being frame-by-frame consistent with a conventional 6502 emulator; Doug Fraker’s Full Game ran 2,645,885 tokens at 420 frames, also achieving frame-by-frame consistency; the nestest consistency suite reached HALT status after 4,586 tokens. These data indicate that the model indeed reproduces the behavior of a 6502 CPU at the logical level.

However, all these data come from the README, and I did not perform local retesting; the running frame rate can also be affected by hardware and Numba versions. If readers truly want to replicate it, they need to download approximately 1GB of decompressed bf16 weights and verify them with shasum on SHA-256SUMS. The build environment requires Python 3.11 or higher, along with numpy, scipy, numba, and pillow. The command to run is python -m nesformer run ROM, supporting optional parameters such as --frames, --buttons, and --show.

From the perspective of compression efficiency, the parameter distribution of Nesformer is also interesting. Out of 466.6M bf16 parameters, only 9.3M are non-zero, with a sparsity rate exceeding 98%. The compressed weight package weighs only 3.3MB, smaller than many NES ROMs themselves. This shows that compiled weights can express complex deterministic calculations with very little effective information, challenging the conventional notion that “the larger the parameters, the better” at least in theory.

Impact/Significance

The greatest significance of Nesformer is that it turns the metaphor “weights are computers” into an executable engineering fact. In the past, discussions about whether LLMs could perform arithmetic or run programs mostly remained at the prompt level. Nesformer proves that with proper architecture design, the state space of large models can directly encode general computing and storage structures without any training, all generated by the compiler.

This achievement provides two insights for model architecture research. First, it verifies the programmability of the Gated DeltaNet state matrix. By controlling the distribution of gates, write strength, and keys, state rows can be turned into addressable memory. Second, it suggests a new compression approach: with only 9.3M non-zero values in 466.6M bf16 parameters, compressing them to just 3.3MB indicates that sparsification and compiled generation may be more suitable for certain specific tasks than end-to-end training.

From a broader perspective, Nesformer, along with Qwenputer, has pushed the topic of “running virtual machines in LLM weights” to a higher complexity level. CHIP-8 and RISC-V are more like educational demonstrations, while NES involves CPU, memory, I/O, and rendering coordination, making it a more complete system. Similar approaches may be used in the future to embed more complex deterministic computing modules within models.

This project also blurs the boundary between “model” and “program”. In traditional software engineering, programs and memory are separate; Nesformer combines them into a single set of weights. If this direction continues, applications like one LLM weight encapsulating language understanding, reasoning capabilities, and fixed business rule engines may emerge in the future, requiring only one file for deployment.

For on-device deployment, this highly sparse compiled weight is also attractive. If future phones or IoT devices need to run a highly deterministic protocol stack or state machine, compiling it into the model weight might be more convenient than maintaining a separate runtime. Of course, this still requires finding a balance between reasoning efficiency and maintainability.

Controversies/Risks

First is the performance bottleneck. It’s 150 to 290 times slower than the real NES, meaning it can only serve as a proof of concept at this stage, far from providing an actual gaming experience. Even if in the future, through quantization, compilation optimization, or dedicated hardware acceleration, we can increase token throughput from thousands to over 100,000 for real machines, several orders of magnitude are still needed.

Second is maintainability and scalability. Compiling the CPU into the weights means any bug fixes or feature extensions require rerunning the compiler, unlike traditional emulators where just a few lines of code are modified. For more complex games like MMC3 and MMC5, the size of the weights could expand significantly, and whether the current solution can scale remains uncertain.

Third is the limitation of the evaluation criteria. All performance numbers and consistency tests in the repository’s README were run by the author themselves, with no independent third-party reproducibility. Additionally, it can only run games with a mapper 0, limiting its coverage. Readers must qualify these numbers with “author’s own claim” when citing them.

Finally, there’s a deeper issue: Does cramming general-purpose computing into LLM weights truly bring engineering advantages? For compatibility alone, traditional emulators are clearly faster and easier to debug. Nesformer’s value lies more in exploring boundaries than replacing existing solutions.

Furthermore, this method of compiling deterministic computations into neural network weights raises concerns about interpretability. Each line of code in a traditional emulator corresponds to a clear hardware behavior, whereas calculations in weights are highly distributed. Once a system fails, locating and fixing errors will be much more difficult than with traditional software.

Conclusion/Prospects

Nesformer is a high-purity technical demonstration. It doesn’t train any weights but compiles the CPU of an NES into Qwen3.5’s 7-layer Gated DeltaNet, reproducing the behavior of a 6502 CPU, RAM, ROM, and OAM with sparse parameters. It can run Super Mario Bros. and Donkey Kong, but at two orders of magnitude slower than real machines.

In the short term, this project will attract attention in three areas: model architecture, compilers, and retro game simulation. It provides a reproducible benchmark for researchers to directly test the upper limit of “state matrix as memory”. In the medium term, if such compilation methods can be extended to more complex mappers and more efficient reasoning paths, it may be possible to achieve scenarios where one model weight carries multiple deterministic functions on on-device devices. In the long term, it reminds us that the weight space of large models is much broader than chatting, summarizing, or reasoning; it can be programmed into any computational structure as long as we find the right compilation method.

An interesting future research direction is “mixed weights”: the language understanding and reasoning parts are still trained using traditional methods, while modules such as deterministic rules, protocol parsing, and state machines are embedded through compilation. This approach retains the flexibility of neural networks while achieving verifiable deterministic behavior. Nesformer has proven this path feasible; now it depends on whether we can move it from a toy project to real-world engineering applications. Another challenge is the universality of the compiler: currently, it makes extensive manual mappings for NESs. Whether this can be abstracted into a more general toolchain that “compiles any finite state machine into weights” will determine the ultimate value of this direction.

This project uses the MIT license, and both the code and build instructions are publicly available. If you’re interested in this concept of “weights as computers,” you can directly clone the repository and run it according to the steps in the README. Even if you can’t run the full-speed game, just watching how it recreates an NES with 9.3M non-zero parameters is worth pondering.

Signed by Yongliang