A RISC-V CPU lives inside Qwen3.5's weights, and the arithmetic is the least interesting part
A developer compiled a working 32-bit RISC-V CPU into Qwen3.5-4B's weights. The benchmark table is a wash; the memory trick and the oversight claim are not.
Vlad Makarovreviewed and published
Qwenputer is a stock Qwen3.5-4B plus eleven transformer layers that form a working 32-bit RISC-V processor. It runs C and MicroPython inside the forward pass, passes riscv-tests, and keeps its registers and memory in the model's Gated DeltaNet state. Divyansh Agrawal published the write-up on 22 October with the weights and code alongside; it surfaced on r/LocalLLaMA on 28 October and reached 675 points on Hacker News the next morning.
The arithmetic is the least remarkable part: on the author's own suite it lands within a few points of handing Qwen a Python interpreter, which is far cheaper to build. What is worth arguing about is architectural — exact memory without a runtime, a state that does not grow with the conversation, and fixed weights as a monitoring surface the model cannot edit.
Nothing in the computer was trained
A compiler writes every weight. Agrawal describes the CPU as a circuit of small steps, like read this register or jump if zero, and the compiler turns each into a slice of a transformer layer: attention heads that look things up, feed-forward blocks that do arithmetic, DeltaNet heads that hold memory. Qwen's own 32 layers keep their values. The computer sits in front, the hidden dimension widens from 2,560 to 3,968, and the vocabulary gains 230,324 trace tokens.
The core is RV32IM plus the Zba extension and a small bignum unit for wide integers.
Three claims carry it: it passes the official riscv-tests, its programs match qemu, and it has run 18 million instructions free-running, consuming its own emitted tokens while no reference machine corrected it between steps. The last matters most, because a demo could otherwise be propped up by its harness.
DeltaNet state, turned into exact memory
Three of every four attention layers in Qwen3.5 are Gated DeltaNet, a linear RNN with a state matrix per head. That state normally decays: a gate below 1 fades it at each token, and a write blends a new value in rather than replacing it. Set the gate to 1, the write strength to 1, and encode the key as a one-hot vector, and the arithmetic changes character. Each write overwrites exactly one row, each query reads exactly one value back. The state becomes addressable memory rather than a fading summary.
The consequence is size: a KV cache grows with the conversation; a DeltaNet head's state does not, so the CPU's memory costs the same at ten tokens or ten thousand. Schlag, Irie and Schmidhuber showed in 2021 that this delta rule acts as an associative memory; making it exact and addressable inside a production checkpoint is the step claimed here, and it is more portable than the CPU.
The benchmark table is a wash
Greedy decoding, 40 problems per set, printed on the model card. The Python column is base Qwen calling a real interpreter on the host.
| Benchmark | Base Qwen3.5-4B | Qwenputer | Python tool |
|---|---|---|---|
| Synthetic integer arithmetic | 75.0 | 97.5 | 97.5 |
| DeepMind mul_big | 55.0 | 97.5 | 100 |
| DeepMind div_big | 72.5 | 97.5 | 95.0 |
| DeepMind mul_div_multiple_longer | 90.0 | 100.0 | 97.5 |
| DeepMind add_or_sub_big | 87.5 | 97.5 | 97.5 |
Qwenputer is ahead of the host interpreter on two rows, behind it on one, and level on the rest. On NUPA's long-integer set the author reports a move from 48.6% to 100%, identical to the Python tool. That does not show a compiled CPU beats shelling out to Python; it shows one can match it.
Two objections the framing invites
The sharpest Hacker News objection came from gcr, who pointed out that a host runtime is still in the loop:
"a custom host runtime is still responsible for loading firmware, booting the CPU to the starting point, and compiling/loading the program to run."
The write-up half-concedes it: RvChat boots the firmware into the DeltaNet state, keeps trace tokens out of Qwen's layers and skips Qwen's own layers while the CPU runs, and the limits section says the model does not run on a plain generate() call yet. The narrower claim is that no runtime executes the computation — a driver still orchestrates the forward pass, and a driver is code you trust. What has been removed is the executor that runs a model-authored string on the host, which is where a tool's blast radius lives.
The second objection is blunter. gavinray wrote that he was "not sure I understand how a calculator that isn't 100% accurate is useful". The table does show misses, and that flattens two failure modes. The CPU is exact: about 230,000 output positions were replayed through a reference machine with zero mismatches. What is not exact is Qwen's handling of the call — emitting it, carrying the value through, copying the digits back. A host Python tool fails at the same joint. The compiled CPU removes the interpreter, not the model's ability to fumble the handoff.
Every instruction is paid for in tokens
Each instruction costs a few decoded tokens: an ADDR token naming the row to write, a VAL token carrying the value, a STEP token to close it. Those tokens are the execution trace, so the CPU advances at the speed the model generates. The batched executor used for the benchmarks manages about 3,200 trace tokens a second on an L4, so a large multiplication takes seconds. MicroPython works, slowly.
The checkpoint is 18.8 GB in bf16, roughly double base Qwen, because most of the widened tensor is zero padding. Hugging Face's sidebar reports 9B parameters for it; that is a safetensors storage figure, not an architecture: a 4B base plus a million nonzero compiled weights plus padding. The download counter reads 321 for the last month, against a thread far louder than that install base.
The oversight argument is the one to watch
Two companion posts, both dated 22 October, take this somewhere less whimsical: one argues hybrid models can hide reasoning in their RNN state and evade chain-of-thought monitoring, the other that compiled weights serve as oversight tools the model cannot tamper with. The second claim does not depend on the CPU being fast. A checker compiled into fixed weights is not something a fine-tune or a prompt can edit, and its verdict does not depend on the model's willingness to report it.
That is real, and narrower than tamper-proof: a compiled checker is exact about what it measures and blind to everything outside its circuit. What gets compiled is a human decision made once, and a model that recognizes a check can still route around it. The filesystem experiment on the rv-store branch points the same way: names hashed into 1,024 directory slots in DeltaNet state, text in other heads at eight tokens per row, up to 512 files or about 53,000 tokens, and 90% correct on facts that changed between chats against 30% when old chats are pasted back.
Nobody outside the author has checked it
Every correctness figure here comes from Agrawal's own harness: the replay, the qemu comparison, the 18 million instructions, the table, the KL divergence of 6e-4 against a 5e-4 noise floor. That is not an accusation. The code is public, MIT in the repository and Apache-2.0 on the model card, and the whole thing runs on a single 24 GB GPU, which makes replication cheap.
What would settle the interesting questions is not another arithmetic score. It is a third party reproducing the exactness claim on hardware the author does not control, the trace-token overhead surviving at program sizes people would run, and someone building on the DeltaNet-as-RAM trick without a novelty CPU. Until then, a deterministic computer has been compiled into a language model and demonstrably runs, it roughly matches a Python one-liner on the tasks it was scored on, and the idea underneath is worth more than the leaderboard on top.
