Qwenputer compiles a 32-bit RISC-V CPU into Qwen3.5-4B's weights — the forward pass becomes byte-exact RAM
Not a fine-tune: a compiler hand-places ~1M weights so the model's Gated DeltaNet state acts as addressable memory. NUPA arithmetic goes 48.6% → 100% by construction — but every number is author-reported, and no independent reproduction exists yet.
Qwenputer, released this week by developer Divyansh Agrawal, puts a real 32-bit RISC-V core inside Qwen3.5-4B — not an emulator the model was fine-tuned to imitate, but a processor whose weights a compiler computes directly. No weights are trained. The model's Gated DeltaNet recurrent state becomes byte-exact RAM, and executing a program means generating trace tokens, one write to memory at a time.
What shipped
The checkpoint is stock Qwen3.5-4B with 11 compiler-generated "chip" layers inserted in front of the model's original 32, hidden size widened from 2560 to 3968 (per the design doc). The class stays Qwen3_5ForCausalLM; it is a config-only change, and Qwen's own weights are untouched. Agrawal frames the build as a circuit description: "the compiler turns each step into a piece of a transformer layer" (write-up).
It is a complete instruction set, not a toy. The model card claims the full RV32IM set plus the Zba extension and a small bignum coprocessor; the design doc details the custom-0/custom-1 instructions (BMAC, BMSB, BLD, BSCAN, BGET, BPRD) that drive eight 128-digit decimal registers. Memory maps to 32 KB RAM at 0x0, 128 KB read-only data at 0x20000, and 256 KB code at 0x40000; the program counter, registers, and call stack live in dedicated DeltaNet heads (rv32.md).
The trick that makes it exact is how the recurrent state is addressed. Gated DeltaNet writes a row only when the gate and write strength are both 1, so with the gate at α=1, the write strength at β=1, and a one-hot key, each generated token overwrites exactly one row of a head's state — that is RAM, byte-addressable and non-destructive to everything else. The repo README spells out the token contract: an ADDR token names the row, the VAL token that follows carries the value, and STEP ends the instruction. "Each generated trace token is one write to the computer's memory."
Author-reported verification is strong but single-source. The write-up and model card claim the core "passes the official riscv-tests" and "its programs match qemu", that it has "run 18 million instructions free-running without a single error", and that replaying roughly 230,000 output positions against a reference machine produced zero mismatches, with 0 lock errors and 0 head mismatches in every run. The project's bridge.Session harness checks every trace token in lockstep against a reference machine (README, docs). The compiler, the checkpoint, and the harness are all public, so the result is rerunnable — yet no independent reproduction has been published.
Arithmetic accuracy jumps to tool level. On the DeepMind arithmetic sets, base Qwen3.5-4B scores 55.0 on mul_big; Qwenputer scores 97.5, and base Qwen handed a Python tool scores 100.0. On synthetic integer arithmetic, both Qwenputer and the Python-tool variant hit 97.5 versus the base's 75.0. On the NUPA arithmetic benchmark, the author reports Qwenputer going "from 48.6% to 100%", matching what giving Qwen a Python tool achieves (write-up). Text fidelity barely moves: mean KL of 6e-4 against base Qwen versus a 5e-4 noise floor, and greedy text identical on 10 of 16 prompts.
There is also an experimental filesystem variant that adds put/append/get/list/delete across 1,024 hash slots holding about 512 files (~53,000 tokens). Multi-session recall rises from 7.8 to 83.3 (a host Python-memory tool gets 78.9) and changed-fact tracking from 3.3 to 90.0 (tool: 83.3) per the repo. Agrawal's earlier, smaller version compiled a CHIP-8 machine into the same model line.
The release is Apache-2.0 and runs on a single 24 GB GPU. The checkpoint is 18.8 GB in bf16 (model card) — about 9B parameters, "mostly... zero padding" — and the computer itself accounts for roughly 1,040,595 nonzero weights (docs). The vocabulary grows by 230,324 trace tokens to 478,656.
Why it matters
The interesting claim is architectural, not a benchmark number. In the standard agent recipe the model calls out to an interpreter or a sandbox; here the tool is the model's own forward pass. The "tool call" is orchestration over trace tokens, and the runtime is the recurrence itself. ainaews' write-up flags exactly the open question that decides how important this is: how much of the execution is really done by the model's weights versus by surrounding executor machinery. What is unambiguous is the mechanism — one-hot-addressed Gated DeltaNet state as byte-exact memory — a new way to give a recurrent model a persistent, inspectable, byte-addressable scratch space.
For people building stateful agents, the filesystem variant is the most immediately suggestive result: memory that survives sessions and is addressable by the model itself, without vector indexes. The author also argues in the write-up that RNN-hidden computation of this kind sidesteps chain-of-thought monitoring — a claim security teams will want to scrutinize rather than dismiss.
Caveats
The arithmetic gains are by construction — the model now delegates to an exact processor embedded in its own weights, so higher accuracy is not evidence the model got better at math (mlllm.io). The checkpoint is ~9B parameters despite the 4B branding. Every correctness and performance number is author-reported; mlllm.io notes there are no independent third-party reproductions, and riscv-tests is not a complete verification standard (Startup Fortune).
It is also slow and not drop-in. Each instruction costs a few generated tokens (4.1 on average for DIV), a full calc call runs 1.3k–3k chip tokens (~0.5–1 s), and the median mul_div problem takes 585 s on the plain HF path or 242 s with the Triton executor (~3,200 trace tokens/s on an L4, per the README). It does not run with a plain generate() call yet — it needs the RvChat driver. The tool-call capture window is 80 tokens, and batched decode is not bit-identical to batch-1 generation because Qwen's GEMMs round differently at batch size 1 versus B (design doc). Nobody is going to replace a CPU with this.
The open question is whether "runtime inside the weights" becomes useful as a niche — exact arithmetic, auditable persistent memory, or a reasoning scheme that lives outside the monitored text — or stays a demo. The open checkpoint and harness mean the field can decide by rerunning, not by trusting the README.