Glonce

Qwenputer compiles a RISC-V CPU into Qwen 3.5 4B weights

researchThe Glonce editorsHacker News🔥79Glonce rating79Impact55Novelty80Relevance85Surprise80Players20Credibility70
Qwenputer compiles a RISC-V CPU into Qwen 3.5 4B weights

Divyansh Agrawal has published Qwenputer, an experimental model built on a stock Qwen 3.5 4B. The addition is a RISC-V CPU embedded in the weights, which uses the model's own Gated DeltaNet (GDN) attention layers as RAM. The CPU runs entirely within the model's forward passes and can run arithmetic, C and MicroPython code with no external runtime or tool. The author is blunt about it: "it is not a plugin, a tool or a sandbox."

The starting point is a property of Qwen3-Next and Qwen 3.5, where 3 out of 4 attention layers use Gated DeltaNet, a linear RNN. Each head keeps a state matrix that the delta rule updates. The author found that setting the gate to 1 (nothing fades), the write strength beta to 1 (an old value is fully replaced, not blended) and using one-hot keys (each key points at exactly one row) makes every write overwrite exactly one row and every one-hot query return an exact value. The GDN layers then behave as RAM. Unlike attention's KV cache, a GDN head's state stays the same size however long the conversation gets. The post notes the idea of the delta rule as memory is not new: Schlag, Irie and Schmidhuber showed it in a 2021 ICML paper on linear transformers as fast weight programmers. The claimed novelty is making it exact and addressable inside a production model, reliably enough to run a whole CPU. Default Qwen 3.5 does not keep exact values in the GDN.

No training is involved. A compiler sets every weight directly: the CPU is described as a circuit of small steps such as "read this register" or "jump if zero", and each step becomes part of a transformer layer. Attention heads do lookups, feed-forward units do arithmetic and DeltaNet heads hold the RAM. Each instruction becomes a few generated tokens: one names the memory row to write (ADDR), the next carries the value (VAL), and a STEP token ends the instruction. Those tokens are the CPU's execution trace, so the CPU is running while Qwen generates them.

The CPU is a 32-bit RISC-V core (RV32IM, plus the Zba extension and a small bignum unit for big-number arithmetic) and takes up 11 layers in front of Qwen's 32. The author says it passes the official riscv-tests, its programs match qemu, and it has run 18 million instructions free-running, meaning on its own outputs with no reference machine correcting it, without a single error. It is not a Linux-class chip yet, but it implements the full RV32IM instruction set. C and MicroPython run quite well, if a bit slowly.

Qwen 3.5 4B uses the CPU without any post-training. The model piggybacks on the tool-call format it already knows: it sends the CPU instructions and reads back results, with no external tool calls. A small driver called RvChat loads the firmware into the GDN state and keeps trace tokens out of Qwen's layers. Qwen's original weights stay exactly as they are; the computer weights sit on top, in extra dims and layers.

Benchmark results on DeepMind sets (Qwenputer vs Qwen 3.5 4B with a Python tool vs base Qwen): div_big 97.5% vs 95% vs 72.5%; mul_big 97.5% vs 100% vs 55%; mul_div_multiple_longer 100% vs 97.5% vs 90%; add_or_sub_big 97.5% vs 97.5% vs 87.5%. On NUPA's long-integer arithmetic, Qwenputer goes from 48.6% (base) to 100%, the same as the Python tool. The author replayed about 230,000 output positions against a reference machine and found zero mismatches. Ordinary text stays within noise of base Qwen (KL 6e-4, against a noise floor of 5e-4).

The author also added an experimental in-model filesystem with internal put, append, get, list and delete operations, again with no tool calls. File names are hashed into one of 1,024 slots in a directory kept in the DeltaNet state; text is stored in other heads, eight tokens per row, chained together. Colliding names go to the next slot. Lookup takes roughly two or three steps, and the store holds up to 512 files, about 53,000 tokens of text. State can be saved at the end of a conversation and loaded into the next. With it, Qwen gets facts that changed between chats right 90% of the time, against 30% when old chats are pasted back in, and it is on par with Python-run memory tools (83.3% vs 78.9%). The code lives on the rv-store branch.

Limits: the checkpoint is 18.8 GB, roughly double base Qwen, though most of it is zero padding. The model needs the RvChat driver and does not run with a plain generate() call yet. Every CPU instruction costs a few decoded tokens, so a big calculation takes seconds rather than milliseconds; the batched executor used for benchmarks runs about 3,200 CPU tokens a second on an L4. Next, the author wants Qwen to write Python and run it on the in-weights MicroPython through a python() tool, and to make the CPU faster. Two follow-up write-ups cover how hybrid models can learn to hide reasoning in RNN state and evade chain-of-thought monitoring, and how compiled weights can act as monitoring tools the model cannot tamper with. Code is on GitHub and models are on Hugging Face and ModelScope.

Key facts

  • Qwenputer is a stock Qwen 3.5 4B with a compiled, not trained, 32-bit RISC-V CPU (RV32IM plus Zba and a bignum unit) in 11 extra layers ahead of Qwen's 32; Gated DeltaNet state serves as exact RAM.
  • The author reports 97.5% on div_big, 97.5% on mul_big, 100% on mul_div_multiple_longer and 97.5% on add_or_sub_big, and 100% on NUPA long-integer arithmetic (base Qwen: 48.6%), roughly level with a Python tool.
  • The CPU has run 18 million instructions free-running without an error, and about 230,000 replayed output positions had zero mismatches against a reference machine.
  • An experimental in-model filesystem holds up to 512 files (about 53,000 tokens) and got changed facts right 90% of the time, against 30% for pasted-back chats.
  • It is slow, needs the RvChat driver, and has an 18.8 GB checkpoint; it runs on a single 24 GB GPU, and the code and models are open.

Why it matters

The demo shows that part of a production language model can be turned into exact, addressable memory and made to run a real instruction set inside its forward passes, with no tool server or sandbox. The post is explicit that the delta rule as memory is old (Schlag, Irie and Schmidhuber, ICML 2021); the claimed new part is making it exact inside a production model, reliably enough for a whole CPU. Because a GDN head's state does not grow with conversation length, unlike a KV cache, the author argues it is a cheap kind of RAM.

Who it affects

Mainly researchers and tinkerers working on hybrid and linear-attention architectures, interpretability and AI safety. The author calls Qwenputer a testbed for safety research and points to two follow-ups: hybrid models hiding reasoning in RNN state to evade chain-of-thought monitoring, and compiled weights as in-weight monitors the model cannot switch off. It is not a product for everyday users.

How to use it

The model runs on a single 24 GB GPU. You need uv and the Hugging Face CLI. Clone github.com/divagr18/qwenputer, go to experimental/riscv, run uv sync --extra hf, download divagr1925/Qwen3.5-4B-Qwenputer with hf download, then start the chat driver (chipformer.rv.chat) with a firmware file and a prompt such as "Use calc: what is 123456789 * 987654321?". The driver is required; plain generate() does not work yet. The filesystem version is a separate model and lives on the rv-store branch. Models are on Hugging Face and ModelScope. No licence is stated.

How solid is it

The results are the author's own, reported in a blog post. No independent replication or peer review is mentioned, and the benchmark sample sizes are not stated. Supporting evidence the author cites includes passing the official riscv-tests, matching qemu, 18 million error-free free-running instructions and zero mismatches across about 230,000 replayed output positions. Against a Python tool the accuracy is mixed: higher on div_big and mul_div_multiple_longer, equal on add_or_sub_big and NUPA, lower on mul_big (97.5% vs 100%). The code and models are open, so the claims can be checked.

Risks and caveats

The author calls it very much an experiment. The checkpoint is 18.8 GB, about double base Qwen, though mostly zero padding. It needs the RvChat driver and does not work with plain generate(). It is slow: each CPU instruction costs a few decoded tokens, so big calculations take seconds, and the batched benchmark executor manages about 3,200 CPU tokens a second on an L4. The CPU is not Linux-class yet. The filesystem is still experimental. Planned work, such as a python() tool backed by the in-weights MicroPython, is not delivered.

“To be very clear, it is not a plugin, a tool or a sandbox.”

— Divyansh Agrawal, Qwenputer blog post