Qwenputer: A RISC-V CPU Inside an AI Model
Qwenputer embeds a deterministic RISC-V CPU in Qwen 3.5. See how Gated DeltaNet becomes RAM, what the benchmarks show, and where the design falls short.
Qwenputer Puts a Deterministic RISC-V CPU Inside an AI Model
Language models are good at explaining arithmetic and unreliable at doing it exactly. They can walk you through a long multiplication problem and still mess up the final digits. The usual fix is to call a calculator or run code in an external tool. Qwenputer takes a different approach: it builds a working RISC-V CPU into the model itself.
Built on Qwen 3.5 4B, Qwenputer uses the model's Gated DeltaNet state as addressable memory and adds compiled computer layers to run instructions during the model's forward passes. It can do exact arithmetic and run C and MicroPython without handing the job to an external tool server. That's impressive in its own right - and it also makes a good case study in what happens when you mix learned behavior with deterministic machinery.
This article covers how the design works, what the reported tests show, and what they don't. It also digs into the trade-offs: more model size, slower execution, a required driver, and the gap between "in-model capability" and "production-ready computing."
What is Qwenputer, and what runs inside the model?
Qwenputer is an experimental version of Qwen 3.5 4B with a RISC-V computer compiled into additional model layers and weights. The original Qwen weights stay the same. The added computer isn't a traditional plugin, a hosted tool, or a sandbox the model calls through an API. The CPU runs as part of the model's decoding process.
That setup is different from typical tool use. In a standard workflow, the model writes a request, an external program runs it, and the result comes back for the model to consume. With Qwenputer, CPU operations are represented through generated tokens, and the model's added layers process those tokens. There's still a small driver involved to initialize and manage execution, but the arithmetic doesn't depend on a separate Python runtime or a tool server.
A computer added to a pretrained model
The system has two core pieces: the compiled layers that implement the CPU operations, and the Gated DeltaNet layers that provide mutable state for memory. A driver called RvChat loads the firmware into that state and keeps the CPU's execution trace separate from the normal text path.
No additional training is required to create the CPU component. A compiler turns the CPU design into model weights. At a high level, it converts circuit steps - like reading a register, adding values, or branching - into operations carried out by attention heads, feed-forward units, and DeltaNet state.
The CPU is an RV32IM core, with the Zba extension and a small bignum unit for larger-number arithmetic. It takes up 11 layers before Qwen's 32. It can execute C and MicroPython programs, though it's slow compared with running code on a conventional processor.
Why this is more than a calculator demo
This isn't only about outputting the right product of two integers. The key point is that a deterministic CPU can be represented inside the inference path of a language model. The model provides the "how to route the task" part, and the CPU provides the "do the operations exactly" part.
That division matters beyond arithmetic. Language models can stumble on repetitive state updates and exact calculations. A CPU is exact inside its instruction set, but it doesn't understand intent. Put together, you keep the natural-language interaction while routing specific steps through deterministic execution.
How does Gated DeltaNet work as exact RAM?
Qwen 3.5 uses a hybrid architecture. Three out of every four attention layers use Gated DeltaNet, a linear recurrent mechanism that maintains a state matrix as tokens are processed. Normally, that state helps with sequence processing; Qwenputer configures it to act as computer memory.
A Gated DeltaNet head updates its state using a gate and a write strength. The gate controls how much of the existing state is kept. With a gate of 0.9, stored information decays gradually; with a gate of 1, it doesn't decay. The write strength, often called beta, controls how strongly a new value replaces information along a selected direction.
Turning state updates into memory operations
Qwenputer sets the gate and write strength to 1 for its memory operations, and it uses one-hot keys. A one-hot key activates one position, which selects a specific row in the state matrix. Writing with that key replaces the selected row; querying with a matching one-hot vector retrieves the stored value.
In practice, that gives the model a simple addressable memory scheme. The CPU can keep registers, program state, and other values in known rows. Compared to relying on "fuzzy" context in attention, the DeltaNet state behaves more like actual RAM.
It also has a useful scaling property. A conventional attention key-value cache grows as the conversation grows, because it keeps information for processed tokens. A DeltaNet head's state stays fixed-size as the conversation continues. That doesn't remove all memory limits - the state still has finite capacity, and the extra layers and checkpoint still cost - but it avoids the "token by token KV cache expansion" pattern.
What is new about the approach
Using the delta rule for associative memory isn't new. Researchers including Imanol Schlag, Kazuki Irie, and Jürgen Schmidhuber have discussed linear transformers as fast-weight programmers. Qwenputer's contribution is making that memory exact and addressable enough to support a full CPU inside a model architecture.
There's an important caveat: a stock Qwen 3.5 model doesn't automatically give you exact RAM just because it has Gated DeltaNet layers. Qwenputer relies on deliberate changes to weights and execution setup. So what's demonstrated is what the architecture can support when configured that way - not a "free" capability in every similar model.
Can an LLM use an embedded CPU reliably?
Qwenputer uses a tool-like interface because language models are already trained to work with structured tool calls. The model sends instructions to the internal CPU and receives results in a format it already knows how to parse. Even so, the arithmetic doesn't happen via an external tool call. The compiled computer layers handle execution inside the model's forward passes.
Each instruction is carried through a short sequence of generated tokens. The sequence identifies which memory row to write, provides the value, and includes a step token to mark the end of the instruction. Together, these tokens form an execution trace as the model decodes. RvChat initializes the firmware and manages the trace so it doesn't flow into the ordinary Qwen text-processing layers.
Tests of the CPU and its outputs
The CPU passes the official RISC-V tests, and its program results match QEMU. In a free-running test, it executed 18 million instructions without an error. Free-running is a meaningful metric here because the CPU keeps using its own outputs rather than being corrected step-by-step against a reference.
The reported comparison replayed about 230,000 output positions against a reference machine and reported no mismatches. These results support a specific claim: the compiled CPU can execute the tested operations deterministically and accurately. They don't, by themselves, prove that every application - or every program a model might generate - will be safe and bug-free.
Arithmetic results versus a base model
On the reported DeepMind arithmetic sets, Qwenputer scored 97.5% on large-number division, compared with 95% for base Qwen 3.5 4B when a Python tool is available and 72.5% for the base model. On large-number multiplication, it scored 97.5% versus 100% with Python and 55% for the base model. It reached 100% on a longer multiplication-and-division set, and 97.5% on large addition or subtraction.
On NUPA long-integer arithmetic, Qwenputer went from 48.6% for the base model to 100%, matching the reported Python-tool result. These are benchmarks, not a guarantee that every answer in an open-ended conversation will be correct. The model still has to decide when calculation is needed, choose the right operation, and interpret the result.
The authors also report that ordinary text behavior stays close to the base model: measured KL divergence was 6e-4, compared with a noise floor of 5e-4. That suggests the additions didn't dramatically change normal text outputs in the reported comparison, but it doesn't guarantee identical behavior across prompts or deployments.
What does in-model storage change?
Qwenputer extends the same memory mechanism into an experimental filesystem. The internal operations support putting, appending, getting, listing, and deleting files. As with the CPU, these operations are implemented in the model's compiled layers rather than through an external file-management tool.
For storage, the system hashes a file name into one of 1,024 directory slots held in DeltaNet state. If two names collide in the same slot, it checks the next slot. File text is stored in other heads, using eight tokens per row and chaining rows together. The design supports up to 512 files, or roughly 53,000 tokens of text.
Persistence across conversations
The notable feature is that the state can be saved after a conversation and loaded into a new one. That means the files can carry over, acting like persistent memory. This is different from simply pasting an earlier conversation into a new prompt, because the stored information stays structured inside the model's state.
In the reported test involving facts that changed between chats, the filesystem setup answered correctly 90% of the time, compared with 30% when old conversations were pasted back in. The authors also report that this was comparable to running memory tools with Python, with scores of 83.3% versus 78.9% in that comparison.
Still, it's experimental. The fixed directory, collision handling, capacity limits, and - crucially - the model's own decisions about what to save all shape whether it's actually useful. Persistent memory also raises product and governance questions: what should be retained, how users can inspect or delete it, and whether stored information could become stale.
A useful separation of responsibilities
The overall product idea is simple: let the model interpret the request and choose an operation, then use a deterministic component for storage or exact calculation. In principle, that can reduce how much you rely on the model to reproduce arithmetic correctly or remember long histories purely from context.
But the model is still in the control path. If it chooses the wrong operation or saves the wrong thing, the deterministic component will do exactly that wrong task. Reliable systems need validation at the interface, not just correct arithmetic inside the CPU. For business use, that means thinking through permissions, data retention, auditability, and failure handling as part of the design - not as an afterthought.
What are the limits and practical implications?
Qwenputer is a research experiment, not a drop-in replacement for a calculator service, code interpreter, or a general-purpose computer. The most obvious limitation is speed. Each CPU instruction maps to several decoded tokens, so larger calculations take seconds rather than milliseconds. The reported batched executor ran at about 3,200 CPU tokens per second on an NVIDIA L4, but throughput isn't the same thing as the latency you'd expect from conventional hardware.
The checkpoint is also large. The added layers and wider hidden size bring it to 18.8 GB, roughly twice the size of the base Qwen model. Much of the extra weight is zero padding, but it still affects deployment and loading. The reported setup runs on a single 24 GB GPU, which is available to some researchers but isn't the same as lightweight inference on a typical laptop or production server.
Integration and operational trade-offs
Qwenputer needs RvChat to boot the firmware and manage the execution trace. It doesn't currently work as a plain model-generation call. So the execution path is more specialized than hitting a standard inference endpoint and sending a request to an external calculator tool.
For a product team, this isn't just "internal compute vs external tools." It's a trade-off between integration complexity, latency, isolation, observability, and control. External tools can be easier to monitor and update independently. An in-model computer can give a tightly integrated execution path and avoid spinning up a separate runtime for supported operations, but it also couples the capability to a specific model checkpoint and driver.
The current performance profile also narrows the use cases. Exact arithmetic and short programs are the obvious demonstrations. Workloads that need high throughput, low latency, broad software compatibility, or mature security boundaries still belong on conventional compute infrastructure.
Why safety researchers should pay attention
The same control over recurrent state that enables exact RAM also raises questions for AI monitoring. Internal state can contain information that never shows up in generated text. The project's authors point to follow-up work on models hiding reasoning in RNN state and on compiled monitors embedded in weights.
This is still a research direction, not a settled safety result. A monitor embedded into weights could be harder for a model to switch off if it's implemented as fixed compiled machinery, but its value depends on what it watches, how it's tested, and whether surrounding systems can bypass it. Hidden state may also increase observability challenges rather than automatically making a model safer.
The practical lesson is to treat state as part of the system's behavior. If a model can store data outside the visible conversation, safety reviews and debugging tools need ways to inspect, test, and govern that state. This matters for privacy as well as monitoring: persistent information needs clear retention and deletion rules.
Conclusion
Qwenputer shows one concrete way to combine a language model with deterministic computation: compile a RISC-V CPU into added model layers, use Gated DeltaNet state as addressable RAM, and let the model interact with the computer through an internal structured interface. Its arithmetic benchmarks and instruction tests make the idea more than a conceptual sketch.
The trade-offs are real, though. The checkpoint is larger, execution is slower than conventional computing, and you need a dedicated driver. The filesystem and safety-related applications look promising, but they're still research directions rather than finished production capabilities.
For teams evaluating AI systems, the takeaway isn't that every model should contain a CPU. It's that you can integrate exact operations more deeply into an inference architecture - if the system is designed with clear limits, observable state, and a reliable boundary between model judgment and deterministic execution.