Qwenx86-4B (GGUF, llama.cpp)

▶️ See it in action: Qwenx86 Debugger Space. Walk through actual recorded tool calls: the conversation, x86 registers and flags, code at the program counter, RAM and machine output, with all verified blocks on a timeline.

This is the GGUF (llama.cpp) build of Qwenx86. Qwenx86 is Qwen3.5-4B with a 64-bit x86 computer compiled into its weights: Qwen calls its tools, and the computer inside the model runs them. Everything about the model itself (how it was built, the tools, the memory, every test) is on the original repo: Quazim0t0/Qwenx86-4B-compact.

Tested on: Windows with an NVIDIA RTX 5060 Ti 16 GB. On that PC, the six standalone tool commands under Run it complete in a clean Python 3.12 venv set up as described below. The every-tool chat and the server are supported and their recorded results are listed below, but they have not been rerun in a clean environment. Other GPUs and PCs are untested; if something fails, please open a discussion.

What you get

Setup (Windows, NVIDIA GPU)

1. Download the whole repo, not just the two .gguf files: the run also needs qwenx86/, chipformer/, machines/, model/, gguf/qx86shim.dll, gguf/text_dims.json and requirements.txt. The two model files are about 13.7 GB together. The simplest way, in Command Prompt (it downloads into a new Qwenx86-4B-GGUF folder; resume by running it again):

   python -m pip install -U huggingface_hub
   hf download Quazim0t0/Qwenx86-4B-GGUF --local-dir Qwenx86-4B-GGUF
   

   With git clone instead, install Git LFS first, or the .gguf files arrive as small placeholder files.

2. llama.cpp b12017, Windows CUDA build, from its release page. Download both:

   • llama-b12017-bin-win-cuda-13.4-x64.zip
   • cudart-llama-bin-win-cuda-13.4-x64.zip

   Unzip both directly into gguf/llama/, so the DLLs sit in that folder itself, not in a sub-folder such as gguf/llama/llama-b12017-bin-win-cuda-13.4-x64/. Afterwards gguf/llama/ should contain llama.dll, ggml.dll, ggml-base.dll, ggml-cuda.dll, the ggml-cpu-*.dll files and libomp.dll, alongside cudart64_13.dll, cublas64_13.dll and cublasLt64_13.dll. It must be exactly b12017: the bridge DLL is built against that version.

   This build uses CUDA 13.4, which needs a recent NVIDIA driver: update yours to the latest from NVIDIA (or the NVIDIA app) before the first run. An older driver makes the model fail to load with a CUDA error.

3. The current Microsoft Visual C++ Redistributable (x64), from Microsoft. llama.cpp b12017 needs msvcp140.dll 14.40 or newer in C:\Windows\System32; older PCs may not have it. To see your version (PowerShell):

   (Get-Item C:\Windows\System32\msvcp140.dll).VersionInfo.FileVersion
   

4. A clean Python 3.12 venv and the packages. From the repo's top folder, in Command Prompt (cmd):

   py -3.12 -m venv .venv
   .venv\Scripts\activate.bat
   python -m pip install -r requirements.txt
   

   (Using cmd avoids PowerShell's script execution policy blocking Activate.ps1. Without activating, you can also call .venv\Scripts\python.exe directly in every command below.) If you don't have the py launcher, use the full path of a Python 3.12 python.exe instead.

   A plain pip install gets the CPU build of torch on Windows. That is fine: llama.cpp runs the model on the GPU, so you do not need a CUDA build of torch for the GGUF version.

Run it

From the repo's top folder, with the venv active. Run one GPU command at a time (each one loads about 14 GB onto the GPU):

python -m qwenx86.gguf_run --tool calc "What is (1200 - 350) / 5? Use the calc tool."
python -m qwenx86.gguf_run --tool c "Write a C program that prints 6 * 7 and run it with the c tool."
python -m qwenx86.gguf_run --tool python "What is 2 to the power 100 exactly? Use the python tool."
python -m qwenx86.gguf_run --tool science "What is the Avogadro constant? Use the science tool."
python -m qwenx86.gguf_run --tool pydoc "What is the signature of math.gcd? Use the python_doc tool."
python -m qwenx86.gguf_run --tool notes "Save a note called bike. The bike lock code is 7193."

Every tool and the memory in one chat (interactive):

python -m qwenx86.mixed --gguf

Each run prints the reply and a summary line, for example [56667 machine tokens in 240 verified blocks, 83 text tokens, 16 s; every machine token = the reference].

The time in the summary line is generation only. Loading the model comes on top and can take longer, especially the first time.

Use it from chat apps (Ollama / OpenAI API)

python -m qwenx86.serve --gguf runs Qwenx86 as a local server that speaks Ollama's API and OpenAI's API, so apps that work with Ollama or with an OpenAI endpoint can use it, every tool included:

python -m qwenx86.serve --gguf

It listens on http://127.0.0.1:11435 (Ollama's own port, 11434, stays free) with one model, qwenx86. Then point your app at it:

• Ollama-style apps (e.g. Open WebUI's Ollama connection): use http://127.0.0.1:11435 as the Ollama URL. Endpoints: /api/chat, /api/generate, /api/tags, /api/show, /api/version.
• OpenAI-style apps: base URL http://127.0.0.1:11435/v1, any API key. Endpoints: /v1/chat/completions, /v1/models.

Start the server, then send requests from a second terminal. In cmd or Git Bash:

curl http://127.0.0.1:11435/api/chat -H "Content-Type: application/json" -d "{\"model\": \"qwenx86\", \"stream\": false, \"messages\": [{\"role\": \"user\", \"content\": \"What is 1234 * 5678? Use the calc tool.\"}]}"

In PowerShell, curl is an alias for Invoke-WebRequest, so write the JSON to a file (UTF-8 without BOM) and send it with curl.exe:

$body = '{"model": "qwenx86", "stream": false, "messages": [{"role": "user", "content": "What is 1234 * 5678? Use the calc tool."}]}'
[System.IO.File]::WriteAllText("$PWD\chat.json", $body, (New-Object System.Text.UTF8Encoding $false))
curl.exe http://127.0.0.1:11435/api/chat -H "Content-Type: application/json" --data-binary "@chat.json"

Every chat is the every-tool chat (qwenx86.mixed): the computer in the weights runs the six tools, Python runs the memory tools, and each reply also carries the tool calls in an extra qwenx86 field. A request that continues the previous conversation continues it; anything else starts a new one. The memory and saved notes persist in ./qwenx86_mixed/. One request at a time. It is not ollama run: it is this repo's Python program, with Ollama's API on the outside. Recorded results on this repo's files: an Ollama-style calc chat (7006652), the same conversation continued with a memory save, a new OpenAI-style chat that found the saved note, and a streamed Ollama request (python, 1,048,576).

The GGUF tests

The computer is exact on llama.cpp. The six recorded tool calls of the PyTorch release (the same runs the Space replays) were fed through the llama.cpp machine model, and at every position the computer's next token was compared with the recording:

On a test prompt, the machine layers' output on llama.cpp equals PyTorch's bit for bit.

The full chat test (the one v3 uses), run from this repo's files: one chat with six tool calls of both kinds, then a separate process that only has the saved state finds both notes again.

All 8 right; 0 of 580,490 machine tokens differed from the reference.

How the GGUF build works

• Two models in one chat. Every token goes through the machine model; text tokens then also go through Qwen's layers in the text model, which takes the machine model's output as its input (llama.cpp's input-embedding path). Machine tokens never reach Qwen's layers, as in the original.
• Reading the computer's next token. The machine model has one extra layer of zeros at the end; llama.cpp can return a layer's input, so that layer's input is the computer's output, and the next machine token is read from its signs. (It is an attention layer: with only recurrent layers, llama.cpp's cache setup fails.)
• A narrower text model. Qwen's layers only touch 2,776 of the 3,968 hidden dims. The text model keeps those, folds all the others into one extra dim that holds their combined size (they pass through Qwen's layers unchanged, so every normalization sees the same total), and pads to 2,816 so the weights quantize in whole blocks. That brings Qwen's 48 layers from 8.33B to 5.91B weights (llama.cpp stores them densely, zeros included).
• Loading a tool. Each tool's starting state (its code, data and memory) is written straight into llama.cpp's saved state for the machine layers before the call runs.
• Checked blocks. As in the original, the reference machine already knows a run's next tokens, so up to 256 go through the machine model in one batch and every prediction is checked.
• One llama.cpp detail. llama.cpp computes a single token with a different routine than a batch, and the two can round differently; on one notes run that changed a prediction. So the chat never sends the machine model a token on its own: it re-runs it together with the previous batch.

Troubleshooting

• Crash on loading: OSError: exception: access violation reading 0x0000000000000000 at qx_open. Usually an old Visual C++ runtime is loaded, for example the msvcp140.dll that Anaconda keeps next to its python.exe. The package loads the system runtime first and stops with a clear message if it is older than 14.40, so make sure you have the current release of the repo, install the current Visual C++ Redistributable (setup step 3), or create the venv from a python.org Python 3.12.
• "incorrect regex pattern" warning from the tokenizer. It can appear on every run and does not stop the run.
• DLL not found / model won't open. Check that gguf/llama/ holds the DLLs directly (no nested folder from unzipping), that both zips are from b12017 with CUDA 13.4, and that qx86shim.dll is in gguf/.
• CUDA error on loading (for example "CUDA driver version is insufficient"). Update the NVIDIA driver to the latest (setup step 2).
• Out of GPU memory. Close other GPU programs and run one command at a time.

GGUF limits

• Windows and NVIDIA only, as shipped. The bridge DLL is built for Windows x64 with MSVC; its C source is in gguf/src/ (Linux would need a rebuild, which is untested).
• Exactly llama.cpp b12017.
• Qwen's text is 4-bit. The computer is exact; Qwen's own words come from a Q4_K_M model, so its replies can be worded a little differently from the PyTorch release.
• About 14 GB of GPU memory, plus about 5 GB of RAM (the machine model's unused output layer and the token table stay in CPU memory).
• Memory: the memory chat works here (python -m qwenx86.mixed --gguf). The other memory checks (python -m qwenx86.memory ...) need the PyTorch weights from the compact repo.

Files

Credits

• Qwenputer by Divyansh Agrawal (@divagr1925, github.com/divagr18/qwenputer, MIT) is the base of this model. From Qwenputer:
  • chipformer: the compiler that converts the circuit to Qwen3.5 layers (q35 IR, emitter, primitives). Included here unmodified, MIT license (chipformer/LICENSE).
  • The RV32 core (chipformer/rv/core.py), with delta-rule memory cells, ROM, DROM and the bignum unit. Qwenx86's x86 core is a fork of it (+ x86 flag uops, conditional jumps, 64 KB RAM).
  • The tool-call bridge (rv/bridge.py): captures <tool_call>, runs the machine, echoes the output to the chat. The reference Session for checking all tokens.
  • The chat loop (rv/chat.py, RvChat). HF emission/state injection (rv/hf.py). The merge layout (rv1). The circuit executor. The nonzero block compaction idea (q35/fast.py).
  • The MicroPython build (mpy-s1.elf, from Qwenputer's tests). We patch it word by word into the python tool.
  • v2 memory: the design of the file store follows Qwenputer's filesystem (divagr1925/Qwen3.5-4B-Qwenputer-Filesystem): how tokens are packed into memory slots, how names are found in the directory, the size limits, and keeping Qwen's own layers untouched while the memory is used. The code that runs it on Qwenx86, the printing and the tests are our own.
• From my previous work: the x86-64 reference and atoms from my Zen2 research, and lessons from neural-n64, neural-x86-doom and neural-riscv.
• Model weights: Qwen/Qwen3.5-4B (Apache-2.0). Qwen's own weights are unmodified. Data: NIST CODATA / scipy.constants (public domain), periodictable (public domain), CPython docstrings (PSF license). Unicorn was used as the x86 reference for tests.
• llama.cpp (MIT), its converter and its CUDA build, for this GGUF version.

Citation

If you use this model, please cite this model and Qwenputer, which it is based on:

@misc{quazim0t02026qwenx86,
  author       = {Quazim0t0},
  title        = {{Qwenx86}: 64-bit x86 computer compiled into weights of {Qwen3.5-4B}},
  year         = {2026},
  publisher    = {Hugging Face},
  howpublished = {\url{https://huggingface.co/Quazim0t0/Qwenx86-4B-compact}},
  note         = {x86 side from author's Zen2 research. CPU circuit forked from Qwenputer}
}

@software{agrawal2026qwenputer,
  author  = {Agrawal, Divyansh},
  title   = {{Qwenputer}: a computer compiled into the weights of a pretrained language model},
  year    = {2026},
  version = {0.1.0},
  url     = {https://github.com/divagr18/qwenputer},
  license = {MIT}
}

License

The weights are Apache-2.0 (a modified version of Qwen/Qwen3.5-4B, LICENSE-Qwen3.5). We widen the config and add the computer layers, but don't modify Qwen's own weights. chipformer/ is MIT, © 2026 Divyansh Agrawal (chipformer/LICENSE).