Running a RISC-V CPU Inside Qwen3.5: The Deterministic Experiment of Qwenputer

When a Large Model No Longer Just Generates Text, but "Runs" a CPU

On Hacker News, a project called Qwenputer has drawn attention: it claims to implement a runnable, deterministic RISC-V CPU inside the Qwen3.5 model. This means the model doesn't just answer "how a RISC-V instruction executes" — it can simulate the behavior of a processor during inference, with consistent results on every run.

At first glance, this idea seems counterintuitive. Large models typically generate text probabilistically, with randomness arising from sampling strategies and hardware nondeterminism. CPU emulation, on the other hand, demands strict state transitions and reproducible output. Qwenputer puts these two contradictions together, attempting to prove that under sufficiently structured constraints, a language model can take on the role of deterministic computation.

What Qwenputer Actually Does

Carrying Processor State in Model Weights

According to the project description, Qwenputer does not attach an external RISC-V emulator and have the model call it; instead, it "internalizes" the CPU's instruction-set behavior into Qwen3.5's inference process. As the model generates each token, it is effectively advancing processor state: register values, the program counter, and memory read/write results all flow through the context in text form.

The key to this approach is not performance but verifiability. When a conventional large model outputs a snippet of assembly code, you can't guarantee it's correct every time; Qwenputer's goal is to make the execution trace under a given input stably reproducible, so that "the model as emulator" has a basis for engineering discussion.

RISC-V is an open-source instruction set architecture (ISA). Unlike x86 and ARM, it uses a modular design: the base integer instruction set (RV32I/RV64I) is tiny — only about 40 instructions — and the rest of the functionality is composed on demand through optional extensions (such as M for multiply/divide, A for atomics, and F/D for floating point). This regularity and limited state space (32 general-purpose registers plus a program counter) make it an ideal testbed for probing a language model's state-tracking ability. The "runnable CPU" that Qwenputer claims is technically closer to a complete implementation of the RV32I base instruction subset, rather than the full privileged architecture and interrupt mechanisms needed to support an operating system.

Where Determinism Comes From

Determinism is Qwenputer's core selling point. In conventional LLM inference, temperature, top-p sampling, and floating-point operation order all introduce variation. Qwenputer constrains the decoding space and fixes the execution path to converge the model's output onto a unique trajectory. In other words, it sacrifices the language model's open-ended generation capability in exchange for reproducible behavior akin to a hardware emulator.

This trade-off has clear boundaries of applicability: it suits teaching demonstrations, instruction-set behavior verification, and research into the model's internal computational representations, but it is not suited to replacing a real RISC-V emulator for running operating systems or high-performance workloads.

Constrained decoding is a key technique for making language model output deterministic. In normal generation, the model samples from the entire vocabulary (tens of thousands of tokens) according to probabilities; constrained decoding, at each step, filters candidate tokens with a finite state machine or grammar rules, keeping only the options that match the target format. If only one legal token remains after filtering, the sampling strategy has no effect, and the output path is uniquely determined. In Qwenputer's context, constrained decoding restricts each step's output to a legal instruction format or state-update format, making the execution trace reproducible. The cost is that the candidate space is greatly compressed, and the model's general generation capability is "switched off" within the inference loop, retaining only the parts needed for structured state transitions.

Why This Is Worth Discussing

Another Measure of Model Capability

The industry commonly evaluates large models with benchmark scores, inference latency, and context length. Qwenputer offers a different perspective: whether the model can maintain a consistent state machine internally. The RISC-V instruction set is relatively regular, and the number of registers is limited, making it a natural testbed for probing state-tracking ability. If a model can stably execute a RISC-V program, it shows that its internal representations have a strong ability to hold discrete states.

According to the project introduction on Hacker News, Qwenputer is already "functioning" — that is, it completes the execution loop of basic instructions, rather than merely doing static code generation. This distinguishes it from earlier demonstrations that "have an LLM write assembly."

A state machine refers to a computational model in which a system transitions among a finite number of states according to deterministic rules. A CPU is essentially a state machine: the current state is defined by register values and the program counter, and after each instruction executes, the state transitions to the next one according to the instruction's semantics. Requiring a language model to maintain a consistent state machine internally means the model must losslessly track and update a set of discrete variables across multiple reasoning steps. This is fundamentally different from the pattern completion that language models excel at — the latter allows fuzziness and approximation, while the former demands step-by-step precision. The token sequence within the context window serves as "external state storage," while the attention mechanism is responsible for retrieving and updating the relevant state bits at each step.

Inspiration for AI Programming Tools

The mainstream approach for today's AI programming assistants is to generate code, have an external toolchain execute it, and feed the results back to the model. Qwenputer suggests another path: putting a lightweight execution environment directly inside the model's inference loop. For tasks that require multi-step state reasoning (such as register allocation and instruction scheduling), this internalized emulation may reduce dependence on external interpreters.

Of course, the cost of this path is model scale and specialization. Qwen3.5 needs targeted constraints for such tasks; a general-purpose chat model will not spontaneously form a stable CPU state machine.

Limitations and Controversies

Qwenputer's disclosure of information is currently limited. Discussion on Hacker News is not particularly active, there are no third-party reproduction reports, and no public performance comparison data. Several key questions remain unanswered: how complex a RISC-V subset can the model execute? Does state drift over long programs? How does the error compare with a standard emulator?

In principle, a language model emulating a CPU faces dual constraints of context length and state precision. The longer the program, the more register and memory state must be maintained, and whether the model's attention mechanism can losslessly carry this discrete information is key to the method's practicality. Qwenputer's "deterministic" design mitigates random error but cannot eliminate the model's capacity ceiling for state representation.

Another point of controversy is naming and positioning. Calling the in-model emulation a "CPU" easily leads people to assume it has hardware-level fidelity. A more accurate description might be "a deterministic instruction interpreter based on a language model." The project chose a more striking phrasing in its presentation, which is effective for dissemination, but readers need to calibrate their expectations themselves.

State drift refers to the phenomenon in which a model gradually deviates from the correct state during multi-step execution due to attention decay or representational capacity limits. The longer the program, the more register values and memory contents must be held simultaneously, and the less reliable the model's "memory" of earlier states becomes when generating subsequent tokens. Even if constrained decoding guarantees that each step's output format is legal, it cannot guarantee semantic correctness — the model may generate register values that are correctly formatted but semantically wrong. This is the key distinction between "determinism" and "correctness": determinism only promises that every run produces the same result, not that the result matches real CPU behavior. What third-party reproduction needs to verify is precisely the latter.

Experimental Directions Worth Watching

Qwenputer's value lies not in replacing the RISC-V toolchain, but in turning "internal state consistency of a model" into something demonstrable and discussable. If independent reproductions and more complete instruction-set coverage follow, this kind of work could offer new design ideas for the state-reasoning capabilities of AI programming tools. For developers interested in AI applications and open-source tools, this is a small experiment worth tracking.