No Training Required: What Does It Mean to Compile a CPU into Qwen's Weights?

Large language models can't perform exact calculations—it's a structural flaw. A model that generates answers by predicting the next token will almost inevitably make mistakes on multi-digit multiplication. When asked to precisely compute 40 multiplication problems step by step using the 4-billion-parameter version of Qwen 3.5 without external tools, it got only 22 correct.

Developer DVN, also known as Agro, took a different approach: compiling a complete 32-bit CPU directly into the model's weights. On the same 40 problems, it got 39 correct. This CPU underwent zero training—every one of its weights was computed and filled in directly by a compiler.

Why the model can't calculate accurately, and why this approach can produce exact results

State matrix: from fuzzy memory to precise storage

The Qwen 3.5 version has 32 layers in total, and three out of every four layers use the Gated Delta Net structure, which contains multiple state matrices internally. Each time the model reads a token, it rewrites the table according to a fixed formula. There are two key parameters in the formula: the gate determines how much old content is retained, and the write strength determines the mixing ratio of new data with old data.

In a normal model, a single write affects multiple rows simultaneously, so the state matrix can only remember an approximation and cannot store exact values. The author's approach was to set the gate to 1, the write strength to 1, and make each key target exactly one row—so each write replaces exactly one entire row, leaving other rows unaffected. Reading by row number returns the number without any error. This is memory.

I verified this in my own small model: writing 7, 3, and 4 sequentially into an 8-row table, the table with gate 0.9 had only 1.55 left of 4 after 9 steps; the table with write strength 0.5 only wrote in half of 7; the table whose keys didn't target single rows produced a large amount of noise. Only the table with both gate and write strength set to 1 remained unchanged throughout.

Gated Delta Net is a linear attention variant whose core is replacing the key-value cache in traditional attention with an updatable state matrix. Unlike standard Transformer attention, it doesn't need to retain key-value pairs for all historical tokens as generation length grows; instead, it compresses historical information into a fixed-size matrix. Each time a new token is read, a gating mechanism decides how much old state to retain, and then new information is mixed in according to write strength. This structure has constant memory usage over long sequences, but the compression process is inherently lossy, so by default it cannot exactly reconstruct values. The author exploits its programmability by pushing the gate and write strength to extreme values, causing the state matrix to degenerate into precisely addressable memory.

Feedforward layers: building lookup tables out of neurons

After remembering numbers, it still needs to compute. This is handled by the feedforward layers in each layer—a large array of neurons, each of which multiplies inputs by weights and sums them, outputting 0 if the result is less than 0. As long as the weights are set correctly, a neuron can output 1 when the input is exactly a certain combination of 0s and 1s, and output 0 for all other combinations. A row of such neurons is a lookup table that can determine whether an instruction is an addition or a jump, and which cell to read.

The numbers in a 32-bit CPU are too large, so they need to be split into 4-bit segments and computed separately, for the same reason as in the 8-bit small model.

ReLU feedforward layers are the two fully connected networks after each block in a Transformer, usually used to increase nonlinear expressive capacity. Their computation is: the first layer maps the input to a higher-dimensional space, and after ReLU activation, the second layer maps it back to the original dimension. When the weights are carefully set, each neuron can act as an AND gate: only when specific dimensions of the input vector are simultaneously 1 is the weighted sum positive, and the output after ReLU is nonzero. By combining multiple such neurons, the feedforward layer can implement any Boolean function, i.e., a lookup table. The author encodes instruction decoding, register selection, and other logic entirely into these weights, allowing the feedforward layer to perform deterministic computation.

From an 8-bit toy to 32-bit RISC-V: scale and validation

The author first built and validated an 8-bit small CPU: a small 4-layer network with more than 8,000 nonzero weights, all computed by the compiler. Registers and the program counter are all stored in the state matrix. The network outputs one token at a time—an instruction takes two or three tokens: first say which register to change, then say what to change it to, and finally say where the next instruction is. After each token is generated, it is written back to the state table, and the CPU advances one small step.

Given 13 times 11 (implemented via repeated addition), it executed 38 instructions, generated 90 tokens, and finally wrote 143. Across 1,000 random programs and more than 1.16 million instructions, every token was compared one by one with a Python interpreter, with no inconsistency found.

This precision is extremely sensitive to parameters: changing just one number—the gate of the register table from 1 to 0.999 (forgetting one thousandth per step)—made the same program compute 132; with gate 0.99 it computed 61; with gate 0.999, errors began at the 31st token.

The real QNPUTER is a 32-bit RISC-V CPU placed before Qwen's original 32 layers, making the whole model 43 layers. None of Qwen's original weights were changed; the 11 new layers contain about 1.04 million nonzero weights (Qwen itself has about 4.1 billion parameters). It passed the official RISC-V test suite, and the author used 61 programs to confirm that its output matched the reference machine and the QEMU emulator exactly, with every token aligned with the reference machine. These 11 layers can even run a stripped-down version of Python on their own.

RISC-V is an open-standard instruction set architecture initiated by UC Berkeley in 2010. Because it is free, modular, and extensible, it is widely used in academic research and industrial chip design. Unlike x86 or ARM, anyone can implement a RISC-V processor without a license. The author chose RISC-V as the target architecture partly because its instruction set is concise and regular, making it easy to simulate in a neural network using lookup tables, and partly because mature official test suites and the QEMU emulator are available for cross-validation. 32-bit RISC-V means the register width is 32 bits and the address space is 4GB, enough to run a stripped-down Python interpreter.

How the model calls this CPU

The author borrowed Qwen's existing tool-calling syntax. Qwen writes the format for calling a calculator as usual, but no external program catches it—the preceding 11 layers read the expression, compute it on the CPU, and then the model itself writes out the result token by token, after which Qwen continues.

Effect comparison: on 40 large-number multiplication problems, original Qwen got 22 correct, the CPU-equipped version got 39 correct, and real Python got 40 correct. The author checked the CPU's returned results one by one, and they were all correct; the errors came from Qwen itself, such as dropping a sign when copying the answer, or repeatedly calling 44 times without finishing. In everyday chat, the two are almost indistinguishable, and the output difference is comparable to running the same model twice with a different underlying program.

Tool calling is a capability of large models: during generation, the model outputs text in a specific format (such as JSON or special tokens), an external system parses it and performs the corresponding operation (such as a calculator, search, or code execution), and then returns the result to the model to continue generation. Qwen 3.5 itself supports this format. The author cleverly embeds the CPU into the first 11 layers of the model. When the model writes the marker for calling a calculator, these 11 layers directly take over generation of subsequent tokens, perform the computation on the internal CPU, and output the result token by token without any external process. This essentially simulates the tool-calling protocol using model weights, but execution happens entirely inside the model.

Costs and boundaries

The first is speed. For every instruction the CPU executes, the model must generate one or two more tokens. On an NVIDIA L4 GPU, one calculator call takes half a second to a second, and that already uses an acceleration program specially written by the author; using only ordinary model code would be more than ten times slower.

The second is size. The model file grows from 9.3GB to 18.8GB, most of the increase being padding zeros.

The third is that a small driver program is needed to load the CPU firmware into the state table at startup and, at runtime, keep those tokens out of Qwen's own 32 layers. Hacker News user GCR questioned that the claim of "not relying on an external runtime environment" was not honest enough. The author's response was: the driver does no computation and does not parse expressions, and every token is still computed by the weights; the acceleration program computes the same circuit, and its results are consistent with those obtained through the weights.

The author also made corrections: two days before publishing the blog, he fixed a bug where a later calculation in the same conversation could print digits left over from the previous one; on the same day, he removed the statement that "this version has never printed an incorrect result." Later he released an experimental version: running a small language model with 260,000 parameters as a C program on this CPU, with weights loaded as data into CPU memory, taking about 41 seconds per generated token. Developer Drew Brionig, meanwhile, used QNPUTER's compiler to compile an NES processor into a model with the same structure and ran NES games inside it.

What this means

The significance of this work is not that "the model can do arithmetic," but that it demonstrates that weights can carry deterministic computation. Trained weights and compiler-written weights can coexist in the same model: the former handles language, the latter handles precise execution. This provides empirical evidence for hybrid architectures: not all capabilities must be learned from data; some can be constructed directly.

The costs are equally clear—speed, size, and engineering complexity are all substantial. It is more a proof-of-concept milestone than a directly deployable solution. But it opens a question: what else can be put into model weights?

One-line Summary

Compiling a 32-bit RISC-V CPU into Qwen's weights achieves exact computation without training, raising multiplication accuracy from 22/40 to 39/40.

Paragraph Summary

A developer compiled a complete 32-bit RISC-V CPU directly into the weights of Qwen 3.5 without any training and without changing the original model's weights. By setting the gate and write strength of the Gated Delta Net state matrices to 1, exact storage is achieved, and feedforward layers are used to build lookup tables for instruction execution. The 11 new layers contain about 1.04 million nonzero weights carrying the CPU logic. On 40 large-number multiplication problems, original Qwen got 22 correct, while the CPU-equipped version got 39 correct. The costs include slower speed, model file growth from 9.3GB to 18.8GB, and the need for a driver. The work proves that trained weights and compiler-generated deterministic computation weights can coexist in the same model, providing a proof of concept for hybrid architectures.