turintech/Qwen3.5-0.8B-weight-space-programming-Artemis

TurinTech models, built with Artemis

ML-Intern-lab's edited Qwen3.5 0.8B for step-by-step maths, text only, compressed with Artemis

Download	MATH-500, thinking on	BFCL simple Python
0.532 GB	45.20% (edited BF16 46.95%)	260 of 400 (edited BF16 261)

Run it

llama-server -hf turintech/Qwen3.5-0.8B-weight-space-programming-Artemis:Q4_K_M --port 8080 -ngl 99 -c 34816 \
  -np 1 --no-context-shift --jinja

Ollama: ollama run turintech/qwen3.5-0.8b-weight-space-programming-artemis --think=true

Needs llama.cpp with Qwen3.5 support and HTTPS for -hf; the numbers below were measured with builds labelled b11617. The maths numbers were measured with thinking on and up to 32,768 generated tokens, and -c 34816 leaves room for that; with --no-context-shift a reply that fills the context stops instead of dropping its start. Send thinking on in the request, as below, so the setting does not depend on llama-server's default.

A maths request, a local download and Ollama

Leave the server running and send a request from a second terminal. It carries the sampling settings of the MATH-500 run:

curl http://localhost:8080/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "messages": [{"role": "user", "content": "What is the sum of the first 20 positive odd numbers?\nReason step by step and put the final answer within \\boxed{}."}],
  "chat_template_kwargs": {"enable_thinking": true},
  "max_tokens": 32768, "temperature": 0.6, "top_p": 0.95, "top_k": 20, "min_p": 0,
  "presence_penalty": 1.5, "frequency_penalty": 0, "repeat_penalty": 1, "repeat_last_n": 34816,
  "samplers": ["penalties", "top_k", "top_p", "temperature"]
}'

The MATH-500 run sent the same settings to /completion with prompts it rendered from the chat template. In our check on 11 November 2026, the downloaded-file command below and this request, on an AMD Ryzen 9 5900X CPU with the llama.cpp b11617 release, returned \boxed{400}, the right answer, after 23,855 generated tokens, most of them thinking that went over the same sums several times; it took 14 minutes on that CPU. Long maths answers can use the whole budget: 40.55% of the MATH-500 generations stopped at the 32,768-token limit. To run a downloaded file:

hf download turintech/Qwen3.5-0.8B-weight-space-programming-Artemis \
  Qwen3.5-0.8B-weight-space-programming-Artemis-Q4_K_M.gguf --local-dir .
llama-server -m Qwen3.5-0.8B-weight-space-programming-Artemis-Q4_K_M.gguf --port 8080 -ngl 99 -c 34816 -np 1 \
  --no-context-shift --jinja

With Ollama, --think=true keeps thinking on, as in the apps line above; in API requests send "think": true. The Ollama package holds the same file and was checked with Ollama 0.40.14 on short requests, not benchmarked.

Results

File	Size	MATH-500 right	Reached the token limit	BFCL simple Python (of 400)
TurinTech Q4_K_M	0.532 GB	45.20%	40.55%	260
ML-Intern-lab edited BF16	1.517 GB	46.95%	40.55%	261

The original here is ML-Intern-lab's edited checkpoint as a BF16 GGUF, not Qwen's Qwen3.5 0.8B. MATH-500 is all 500 problems with four samples each, thinking on and up to 32,768 generated tokens; the records of how this file was made and checked do not mention its problems. Ours was 1.75 points below the edited BF16, and a paired bootstrap chosen after the run gives -3.75 to 0.25 points, which is not a test of equivalence. The 400 BFCL cases ran with thinking off and were used in earlier model selection. Bold marks the best in each column. Full results, memory and method.

Files

File	Size	Use it for
Qwen3.5-0.8B-weight-space-programming-Artemis-Q4_K_M.gguf	532 MB	Default, Ollama tag q4_k_m (latest)

Text only: no vision projector and no MTP layer. Memory was not measured for the card's command.

Pick this model

• Good for step-by-step maths with thinking on and a large token budget, from ML-Intern-lab's edited checkpoint in a 0.532 GB download: 45.20% on MATH-500 against 46.95% for the edited BF16.
• Pick another file when tool calls matter. On 400 BFCL simple Python cases, used in earlier model selection, our generic Qwen3.5 0.8B Q4_K_M got 313 against 260 for this file, and Qwen's unedited BF16 got 292 against 261 for the edited one. The maths results do not establish a general upgrade over Qwen's unedited model, which did not run MATH-500 here. prithivMLmods' Q4_K_M of the same checkpoint (0.529 GB) was not run on MATH-500 or BFCL; its KL from the edited BF16 on WikiText-2 was 0.064216 against our 0.011930, a comparison outside any planned test.

How it was made

ML-Intern-lab/Qwen3.5-0.8B-weight-space-programming is Qwen's Qwen3.5 0.8B with a direct edit of its weights, made without training; ML-Intern-lab's card describes the edit and its MATH-500 results with vLLM. TurinTech converted that checkpoint at f4a5dd4 to a text-only BF16 GGUF, without the vision encoder and the MTP layer, and built this file from it with Artemis, TurinTech's optimisation platform. The file is a per-tensor mix of standard llama.cpp quant types, quantized with calibration data, so its Q4_K_M label is a size class. Stock llama.cpp and Ollama run it.

How it was tested

MATH-500 ran on NVIDIA RTX 5090 GPUs for our file and the edited BF16: all 500 problems, four samples each, thinking on, the same llama.cpp binary and settings for both, and both files of each shard on the same GPU. The records of how this file was made and checked do not mention MATH-500's problems; its maths checks used GSM8K and MATH training problems filtered against them. These are our measurements with llama.cpp, not the vLLM results on ML-Intern-lab's card. BFCL simple Python ran on one RTX 5090 with thinking off for our file, the edited BF16, Qwen's unedited BF16 and our generic Qwen3.5 0.8B files; all 400 cases were used in earlier model selection. Closeness to the edited BF16 was measured on a CPU over two texts used when the file was checked before its release, for our file and prithivMLmods' Q4_K_M of the same checkpoint. No family of tests was named before these runs, so the card claims no difference between files. The results page has the method, the paired counts, the closeness tables and the check of the Run it command.

Closeness to the original

The closeness numbers from the tables on the results page, in one fixed layout with the protocol behind each table.

Protocols and standard tables

• Mean KLD: the mean KL divergence between the reference's and the file's next-token distributions, computed and averaged as each protocol's Tool line says. Lower is closer.
• 99th-percentile KLD: the 99th percentile of the per-token values. Lower is closer.
• Same top p: llama.cpp's name for top-1 agreement, the share of scored tokens where the file and the reference pick the same most likely token. Higher is closer.
• PPL and PPL ratio: the file's perplexity on the text, and that perplexity divided by the reference's (1 means the same). They measure prediction of the text, not closeness.

n/a means the card's tables or our run records do not have that value.

Protocol cpu-2026-11-03

CPU only, 3 November 2026.

• Reference: BF16 GGUF converted by TurinTech from ML-Intern-lab/Qwen3.5-0.8B-weight-space-programming revision f4a5dd43dae4a5e42b441a31d692570751b3d92c, text only, without the vision encoder and the MTP layer (1,516,744,576 bytes, SHA-256 153ff1bc56c8f6e9802b68cf3428b5b5a66968a544957662250b32fdd19ace46); its saved log-probabilities for each text are the reference for every file
• Text wiki: WikiText-2 test; dataset: Salesforce/wikitext at b08601e04326c79dfdd32d625aee71d232d685c3; config: wikitext-2-raw-v1; split: test; chunks: 60; context (tokens): 512; scored tokens: 15300; text SHA-256: bbf94c53a05abe9ee670d3b6343608095822c85e26de37c70b24fc571964574a
• Text chat: OpenAssistant validation conversations (English threads as User/Assistant text); dataset: OpenAssistant/oasst1 at fdf72ae0827c1cda404aff25b6603abec9e3399b; split: validation; chunks: 60; context (tokens): 512; scored tokens: 15300; text SHA-256: 0a3499a7eaead8f4a40655a868e7faee1ee664e258d09a77cd8f3d97216fc8b7
• Tool: llama-perplexity --kl-divergence against the reference's saved log-probabilities, chunks of 512 tokens; the values are llama.cpp's own summary lines (the run logs also hold PPL)
• llama.cpp build: a CPU build in a folder labelled b11617; the binary reports no build number or commit (SHA-256 99e4f1681a69e4e4567dee1827e730480c24bb81fb2265bd9027202fe79fc577)
• Command: llama-perplexity -c 512 -b 512 -ub 512 -t 8 -ngl 0 --chunks 60 -m <file.gguf> --kl-divergence-base <reference-text.kld> --kl-divergence; the reference logs were written with the same settings and -m <reference.gguf> -f <text> --kl-divergence-base <reference-text.kld>
• Hardware: CPU only
• Settings: 8 threads, no layers on a GPU, batch and micro-batch 512
• KL unit: nats (natural log)
• Measured by: TurinTech downloaded prithivMLmods' Q4_K_M at the revision below, checked it by SHA-256 and measured every file in this table with the same reference, binary and machine
• Selection: the two texts were used when this file was checked before its release, so these columns are not independent tests
• Source, on the results page: the table columns "Mean KLD, wiki / chat", "99th-percentile KLD, wiki / chat", "Same top p, wiki / chat"
• Notes: The run measured our file before two metadata strings that named local paths were removed from it (SHA-256 then d780870b04301b213d38c0151208047f2014393c30aafe23289a90bf14bc2c83); its tensors and all other metadata are the same as the published file's. prithivMLmods' own BF16 parent is not established, so its row compares the two files, not the methods.
• Comparison files: prithivMLmods: prithivMLmods/Qwen3.5-0.8B-weight-space-programming-GGUF at 238d95281065, Qwen3.5-0.8B-weight-space-programming.Q4_K_M.gguf, SHA-256 fb552fa730705398675f49b08c9b15cc38e39a23ee1242b2b213021280a54740

Protocol cpu-2026-11-03, text wiki (WikiText-2 test):

File	Repository	Measured by	Size (GB)	Size (bytes)	Mean KLD (nats)	99th-percentile KLD (nats)	Same top p (top-1 agreement, %)
parent-bf16-nomtp.gguf	ML-Intern-lab/Qwen3.5-0.8B-weight-space-programming at f4a5dd43dae4	reference	1.517	1516744576	reference	reference	reference
Qwen3.5-0.8B-weight-space-programming-Artemis-Q4_K_M.gguf	turintech/Qwen3.5-0.8B-weight-space-programming-Artemis at 7461666e09e2	TurinTech	0.532	532402336	0.011930	0.061059	93.614
Qwen3.5-0.8B-weight-space-programming.Q4_K_M.gguf	prithivMLmods/Qwen3.5-0.8B-weight-space-programming-GGUF at 238d95281065	TurinTech	0.529	529297504	0.064216	0.333496	87.176

Protocol cpu-2026-11-03, text chat (OpenAssistant validation conversations (English threads as User/Assistant text)):

File	Repository	Measured by	Size (GB)	Size (bytes)	Mean KLD (nats)	99th-percentile KLD (nats)	Same top p (top-1 agreement, %)
parent-bf16-nomtp.gguf	ML-Intern-lab/Qwen3.5-0.8B-weight-space-programming at f4a5dd43dae4	reference	1.517	1516744576	reference	reference	reference
Qwen3.5-0.8B-weight-space-programming-Artemis-Q4_K_M.gguf	turintech/Qwen3.5-0.8B-weight-space-programming-Artemis at 7461666e09e2	TurinTech	0.532	532402336	0.016376	0.099482	93.556
Qwen3.5-0.8B-weight-space-programming.Q4_K_M.gguf	prithivMLmods/Qwen3.5-0.8B-weight-space-programming-GGUF at 238d95281065	TurinTech	0.529	529297504	0.063876	0.367253	88.229

File checksums

File	Bytes	sha256
Qwen3.5-0.8B-weight-space-programming-Artemis-Q4_K_M.gguf	532,402,336	200fc0efc1c65bd01444076aac678d4ef3cbabac7eec9f95f0eba6f57528e4fe

---

Artemis is TurinTech's optimisation platform: teams use it to make their own models smaller and faster, or to optimise their code.

All our models · LinkedIn · Questions and requests

_{Apache-2.0, as released by ML-Intern-lab (licence); see LICENSE and NOTICE. An independent TurinTech release, not affiliated with or endorsed by ML-Intern-lab. Not affiliated with or endorsed by Qwen (Alibaba Cloud), whose Qwen3.5 0.8B the edited checkpoint comes from. When serving these files to others, for example through an API, an inference provider or OpenRouter, we'd appreciate a mention of TurinTech (turintech.ai) as the source of the quantization.}

These files keep improving.