Qwenputer: a full RISC-V CPU compiled into Qwen 3.5's weights, using the model's DeltaNet state as RAM
A stock Qwen 3.5 4B now hosts a full RV32IM core whose every added weight is compiler-set, running on the model's own Gated DeltaNet state as exact, addressable RAM.
A developer compiled a full 32-bit RISC-V CPU directly into the weights of a stock Qwen 3.5 4B model, using the model's own Gated DeltaNet recurrent state as exact, addressable RAM — no training involved, every added weight computed by a compiler. The "Qwenputer" passes the official riscv-tests, matches QEMU, runs C and MicroPython inside the model's forward passes, and has rendered a single frame of DOOM.
What shipped
Divyansh Agrawal (@divagr1925) built Qwenputer on the stock Qwen/Qwen3.5-4B checkpoint, whose own weights are unchanged. The CPU is implemented as 11 transformer layers prepended to Qwen's 32; none of those layers' weights are learned — a compiler computes every one. The result is an RV32IM core (plus Zba and a bignum coprocessor) that runs inside the model's forward passes.
The trick is treating Qwen's Gated DeltaNet (GND) state as RAM. Qwen 3.5 mixes full attention with DeltaNet — a linear RNN where 3 of every 4 attention layers are DeltaNet, and each head maintains a state matrix updated by a gated delta rule. Agrawal pins the gate to 1 (nothing fades) and the write strength to 1 (replace, not blend), then uses a one-hot key to overwrite exactly one row (a RAM write) and a one-hot query to read that row back (a RAM read). Low address bits select the head, remaining bits select the row, and each row stores one byte as bits. Registers, the program counter, and the call stack each get their own heads.
Each instruction becomes a few generated tokens — an ADDR token names the row, a VAL token carries the value, a STEP token ends the instruction — so the token stream is literally the CPU's execution log. There is no external runtime: Qwen writes a <tool_call> block for calc exactly as it would for any tool, but nothing outside the model executes it; the compiled layers run it on the CPU and the model writes the <tool_response> digit by digit. A small driver, RvChat, boots the CPU by loading firmware into the DeltaNet state after the prompt and keeps trace tokens out of Qwen's language layers.
The "fast weights" lineage goes back to Schlag, Irie and Schmidhuber's Linear Transformers Are Secretly Fast Weight Programmers (ICML 2021); Agrawal says the new part is making that state "exact and addressable, inside a production model".
Verification. Agrawal reports the CPU "passes the official riscv-tests, its programs match qemu, and it has run 18 million instructions free-running without a single error" (free-running meaning no reference machine correcting between steps). He also reports replaying ~230,000 of the computer's output positions through a reference model with zero mismatches, and text behaviour vs base Qwen at KL 6e-4 against a noise floor of 5e-4.
The filesystem. Because RAM is already in place, Agrawal added a filesystem that also lives in the DeltaNet state: 1,024 slots, file names hashed to a slot, text stored in other heads at 8 tokens per row, holding up to 512 files (~53,000 tokens). It persists if you save the state at the end of a conversation and load it into the next one. On a 90-question multi-session recall test he reports base Qwen at 7.8, Qwenputer with the filesystem at 83.3, and a Python tool baseline at 78.9.
DOOM. The DOOM frame is the proof-of-life. Aditya Narayana's qwenputer-doom repo compiled DOOM E1M1 to RV32IM firmware and ran it on the compiled CPU circuit on one RTX 5070 Ti (16 GB): 6,342,933 trace tokens, zero mismatches against an independent reference CPU, 25/25 strips read back, and the final frame bytes and all 65,536 bytes of final RAM matching the reference exactly. It is one verified frame, not gameplay — about 50.7 minutes on the first run, 24.1 minutes with a fused executor. Qwen's language layers were not loaded for the run.
Size and cost. The extra layers and wider hidden size make the checkpoint 18.8 GB in bf16 per the model card — roughly double base Qwen, though "mostly zero padding; the computer has about 1M nonzero weights" — and Agrawal recommends a single 24 GB GPU. He reports throughput of roughly 3,200 trace tokens/second on an L4.
Open source. Code is on GitHub under MIT; weights are Apache-2.0 on Hugging Face and ModelScope.
Why it matters
The interesting thing here is the inversion of the usual LLM story. Instead of a model predicting computation, a stock checkpoint now hosts computation — a full RV32IM core whose every added weight is compiler-set, running on the model's own recurrent state as exact, addressable RAM. The arithmetic weakness that plagues LLMs is sidestepped entirely: Agrawal reports synthetic integer arithmetic going from 75.0 to 97.5, DeepMind mul_big from 55.0 to 97.5, and NUPA long-integer arithmetic from 48.6% to 100%.
That same property is the unsettling part. The exactness comes from a linear recurrent state that can be pinned to be exact and addressable — and Agrawal's own follow-up posts argue hybrid models can hide reasoning in that same RNN state from chain-of-thought monitoring, and that compiled weights can serve as in-model monitors the model cannot disable. NYU RITS flags both as deserving more scrutiny than a blog post can give. The practical takeaway for engineers is narrower: "fast weights" went from a 2021 theory to working RAM inside a production model, and the mechanism is now documented and reproducible.
Caveats
Nearly every headline number is author-reported and not independently reproduced. Sesame Disk's critical analysis notes that exactness is local, not system-wide: an earlier multi-hot read left fp32 residues ~2e-8 that broke a crc32 test, batching breaks surrounding text (batch 8 vs batch 1 diverged at token 8,390 on one of six records), and a stale kernel autotuner corrupted a result. It also flags that riscv-tests "is not a certification standard," and that in-model failures were attributed to Qwen's call/retry behaviour (610 of 1,040 calc calls returned errors under fraction-only semantics).
The "horrendously inefficient and impractical" verdict — a comment on Tom's Hardware's coverage — is broadly accepted even by sympathetic write-ups: seconds per calculation, ~68 ms per text token at batch 1, and a 50-minute single DOOM frame. This is not a Linux-class machine — no F/D floating point, no compressed instructions in the booted image, CSR reads folded to constants, no privilege modes. There is also a discrepancy between the blog's "18 million instructions" and Sesame Disk's "15.3 million" for free-running runs, which the sources do not reconcile.