---

license: apache-2.0

license_link: https://huggingface.co/Qwen/Qwen3.5-0.8B/blob/main/LICENSE

base_model: Qwen/Qwen3.5-0.8B

base_model_relation: quantized

library_name: gguf

pipeline_tag: text-generation

tags:

• qwen
• qwen3.5
• gguf
• llama.cpp
• function-calling

---

Qwen3.5 0.8B Artemis GGUF

Text-only GGUF versions of Qwen3.5 0.8B for llama.cpp. The vision encoder and multi-token prediction (MTP) layer are not included.

Start with Qwen3.5-0.8B-Artemis-Q5_K_M.gguf (0.569 GB). Use llama.cpp with Qwen3.5 and HTTPS support:

llama-server -hf turintech/Qwen3.5-0.8B-Artemis-GGUF:Q5_K_M --port 8080 -c 8192 --jinja

Keep the :Q5_K_M tag: untagged llama.cpp downloads and Hugging Face's generated Ollama import select Q4_K_M instead.

<div>

<a href="https://turintech.ai"><img src="https://huggingface.co/turintech/Qwen3.5-0.8B-Artemis-GGUF/resolve/main/assets/turintech-logo.png" width="180" alt="TurinTech"></a>

<p style="margin: 4px 0;"><em>TurinTech models, built with Artemis</em></p>

</div>

Why use this file

• Run locally so inputs can stay on the same machine.
• Work offline after downloading the model and runtime.
• Use for local chat and tool-calling applications, within the tested limits below.
• Choose a compact GGUF download; file size is not a measurement of runtime memory.

Files

| File | Size | Choose for |

| --- | --- | --- |

| Qwen3.5-0.8B-Artemis-Q5_K_M.gguf | 0.569 GB | Default. |

| Qwen3.5-0.8B-Artemis-Q4_K_M.gguf | 0.532 GB | Smaller download. |

GB means decimal download size, not RAM or VRAM. Labels are size classes; tensor types and checksums are below.

Before choosing

On the RTX 5090 GSM8K sample, Q5_K_M answered 132/250 correctly and Q4_K_M 137/250, versus 145/250 for BF16. The large tool-calling gains on the earlier panel used tasks that also influenced file selection; the fresh CPU probe did not establish a general tool-use advantage.

The results do not establish overall superiority or lossless compression. See the measured trade-offs and test conditions in How it was tested.

Run it

llama-server -m Qwen3.5-0.8B-Artemis-Q5_K_M.gguf --port 8080 -c 8192 --jinja

-c 8192 sets an 8,192-token context; --jinja uses the chat template stored in the file, which is Qwen's original. The raw template defaults to thinking off when enable_thinking is absent. llama-server can supply its own default; in our b11617 runtime check, an omitted flag enabled thinking. Set the flag explicitly for reproducible behavior. In our test, a short question with thinking on used all 1,500 output tokens thinking and returned no answer, so turn thinking off in the request for short answers and tool calls, as below. The tool-calling results on this card were measured with thinking off.

curl http://localhost:8080/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "messages": [{"role": "user", "content": "What is the weather in Paris right now, in celsius?"}],
  "tools": [{"type": "function", "function": {"name": "get_weather", "description": "Current weather for a city",
    "parameters": {"type": "object", "properties": {"city": {"type": "string"},
      "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}}, "required": ["city"]}}}],
  "chat_template_kwargs": {"enable_thinking": false}
}'

In our test run the reply's tool_calls held get_weather with {"city":"Paris","unit":"celsius"}.

# the smaller file: download it, then the same command
hf download turintech/Qwen3.5-0.8B-Artemis-GGUF Qwen3.5-0.8B-Artemis-Q4_K_M.gguf --local-dir .
llama-server -m Qwen3.5-0.8B-Artemis-Q4_K_M.gguf --port 8080 -c 8192 --jinja

Questions, problems and requests for other small models are welcome in our feedback thread.

Ollama

Read-only registry checks on 16 October 2026 confirmed the tag aliases, model-layer SHA-256 hashes and package settings below against these HF files. This was not a fresh registry pull or inference test.

ollama run turintech/qwen3.5-0.8b-artemis:q5_k_m

latest and q5_k_m are the Q5_K_M file and q4_k_m is the Q4_K_M file, with the same SHA-256 as this repository. The packages use Ollama's Qwen3.5 renderer and tool-call parser, as Ollama's own qwen3.5 package does, and Qwen's recommended sampling for text in thinking mode (temperature 1, top_k 20, top_p 0.95, presence penalty 1.5). To import a file directly with the same settings:

hf download turintech/Qwen3.5-0.8B-Artemis-GGUF Qwen3.5-0.8B-Artemis-Q5_K_M.gguf --local-dir .
printf 'FROM ./Qwen3.5-0.8B-Artemis-Q5_K_M.gguf\nRENDERER qwen3.5\nPARSER qwen3.5\nPARAMETER temperature 1\nPARAMETER top_k 20\nPARAMETER top_p 0.95\nPARAMETER presence_penalty 1.5\n' > Modelfile
ollama create qwen3.5-0.8b-artemis -f Modelfile
ollama run qwen3.5-0.8b-artemis

The accuracy comparisons use llama.cpp.

A separate Ollama 0.40.4 local-import smoke test covered our audited files with one tool prompt, greedy decoding, seed 20261015 and a 256-token output cap. In this test, omitting think enabled reasoning; think:false disabled it. This checks import and parser behavior on one prompt, not task accuracy or a fresh registry pull. The accuracy comparisons use llama.cpp with thinking explicitly off.

Memory

The upstream architecture declares a 262,144-token context limit; this audit does not validate these GGUFs at that maximum. A separate Q4_K_M retrieval probe recovered three codes from repetitive filler at 12,067 and 24,067 input tokens, using a 32,768-token server context and seed 2026101504. This is not long-document reasoning evidence. YaRN extension and quantized KV caches were not evaluated. The benchmark comparisons used F16 K and V caches.

Not measured yet. The download size is not the memory a run needs; the context length and runtime settings add to it.

How it was tested

<details>

<summary>Measurements, comparisons and limitations</summary>

<!-- chart:start -->

!Qwen3.5 0.8B: Correct tool calls (of 200) versus file size. Each point shows a measured file. Exact values are in the comparison tables below.

Correct tool calls on the 200-task selection-exposed sample. This sample also informed file selection, so it is not an independent evaluation. Neither TurinTech file is statistically separated from BF16; the advantage does not extend to GSM8K maths. See How it was tested.

<!-- chart:end -->

Every file, ours and public, was compared with a BF16 conversion of the same original (Qwen/Qwen3.5-0.8B revision 2fc0636, converted without the MTP layer):

• KL divergence and next-token agreement over 60 chunks of 512 tokens from each of two human-written texts: the WikiText-2 test set (Wikipedia) and OpenAssistant OASST1 validation conversations.
• Native tool calling on BFCL simple (Python): 400 tasks, each a user request and one function to call. The first 200 were used to choose between candidate files and the other 200 were reserved initially from that search. Each request went through llama-server's OpenAI-style tools API with one slot, greedy decoding, thinking off and Qwen's original chat template for every file, and was scored with BFCL's own checker. A reply with no tool call counts as wrong.
• GSM8K maths, 250 problems (the first 250 of the test set on the RTX 5090).

The selection-exposed 200 are not fresh. On the Apple M3 Max they helped decide which files to publish. On the RTX 5090 they were run on four final candidates for the Q4_K_M file, and the file here is the one with the most tool calls right among them, so its count may be higher than it would be on new tasks. Every selection-panel count in the RTX 5090 table comes from that same harness.

The paired test compares two files on the same 200 selection-panel tasks. It counts the tasks only one of the two got right and gives the chance of a split at least that uneven if the files were equally good (exact McNemar test). A large p means the test found no difference, which is not proof that the files are equal.

NVIDIA RTX 5090, llama.cpp b11617 (CUDA)

| File | Size | KL wiki / chat | Same next token, wiki / chat | Tool calls right, selection-exposed 200 | No tool call at all | Tool calls right, first 200 | GSM8K (of 250) |

| --- | --- | --- | --- | --- | --- | --- | --- |

| BF16 original | 1.52 GB | reference | reference | 156 | 22 | 136 | 145 |

| Artemis Q5_K_M | 0.569 GB | .0098 / .0092 | 94.2% / 95.1% | 160 | 13 | 119 | 132 |

| bartowski Q4_K_M | 0.580 GB | .0297 / .0295 | 90.8% / 91.9% | 99 | 89 | 74 | 138 |

| Unsloth Q4_K_M | 0.533 GB | .0338 / .0333 | 90.1% / 91.4% | 92 | 95 | 70 | 131 |

| Artemis Q4_K_M | 0.532 GB | .0165 / .0163 | 92.7% / 93.6% | 164 | 12 | 149 | 137 |

| Comparison on the 200-task selection panel | Only the first right | Only the second right | p |

| --- | --- | --- | --- |

| Artemis Q5_K_M vs bartowski Q4_K_M | 64 | 3 | 7e-16 |

| Artemis Q4_K_M vs Unsloth Q4_K_M | 73 | 1 | 8e-21 |

| Artemis Q5_K_M vs BF16 original | 9 | 5 | 0.42 (not significant) |

| Artemis Q4_K_M vs BF16 original | 11 | 3 | 0.06 (not significant) |

| Artemis Q4_K_M vs Artemis Q5_K_M | 8 | 4 | 0.39 (not significant) |

The table reports selection-panel correct-call counts for Q4_K_M and the original. The paired test does not separate the two (p = 0.06), so the card does not claim that it beats the original. Tool-calling counts also move a lot between task sets: on the first 200 tasks the Q5_K_M file got 119 right against 136 for the original, with 58 replies that made no tool call, while on the selection-exposed 200 the paired test did not separate it from the original. The first 200 were the search set for the Q4_K_M file, so its 149 there is not a fair comparison either. All the RTX 5090 rows come from one harness on GPUs of the same model; re-run on a second GPU, the original and the Q4_K_M file scored the same on every selection-exposed task.

Apple M3 Max, llama.cpp b11617 (Metal)

| File | Size | KL wiki / chat | Tool calls right (of 200) | GSM8K (of 250) | MMLU-Pro (of 280) |

| --- | --- | --- | --- | --- | --- |

| BF16 original | 1.52 GB | reference | 142 | 134 | 39 |

| Artemis Q5_K_M (Mac build) | 0.569 GB | .0087 / .0086 | 140 | 122 | 32 |

| bartowski Q4_K_M | 0.580 GB | .0274 / .0279 | 65 | 129 | 33 |

| Unsloth Q4_K_M | 0.533 GB | .0309 / .0291 | 76 | 124 | 37 |

| Comparison on the 200-task selection panel | Only the first right | Only the second right | p |

| --- | --- | --- | --- |

| Artemis Q5_K_M (Mac build) vs bartowski Q4_K_M | 76 | 1 | 1e-21 |

| Artemis Q5_K_M (Mac build) vs BF16 original | 12 | 14 | 0.85 (not significant) |

The Q4_K_M file in this repository was chosen after the M3 Max run and has not been run on that machine.

Compare rows within one table. The two machines used separate harnesses for the same tests, so the prompts and the chat text sample may not match exactly. The M3 Max rows for our Q5_K_M are a separate build made on the Mac, with the same tensor types and its own importance matrix. It is not the Q5_K_M file published here, which was built on the RTX 5090 machine. The two machines give different absolute counts: the BF16 original got 142 selection-exposed tasks right on the M3 Max and 156 on the RTX 5090, and every file's KL is 6 to 14% higher on the RTX 5090. The tables report each machine's correct-call counts and paired tests for Q5_K_M, bartowski Q4_K_M and the original. Neither machine separated Q5_K_M from the original. The RTX 5090 runs scored tool calls with the answer key in bfcl_eval 2026.3.23 and the M3 Max run with the BFCL v3 key; the two keys differ on one selection-exposed task.

Most of the tool-calling losses in the public 4-bit files are replies with no tool call at all (89 and 95 of 200 on the RTX 5090, against 22 for the original).

Fresh CPU probe, 15 October 2026

This separate check used workstation CPU, eight inference threads, llama.cpp b11617, one 8,192-token server slot, greedy decoding (seed 20261015), thinking explicitly off and the pinned public Unsloth BF16 reference. KL is the mean of six document means: two recent Wikipedia extracts, two authored code samples and two authored chats, each evaluated as two 256-token chunks. These short, fixed probes measure next-token fidelity, including the reference's mistakes.

Tool scores use 60 BFCL live_simple cases selected with seed 2026101502, outside the reported selection categories; full historical tuning exposure is unknown. The table reports exact two-sided McNemar p-values. Download sizes use decimal GB; size differences are explicit.

| Comparison (ours / public GB) | Mean KL ours / public | Lower mean KL | Correct calls /60 | Only ours / public | McNemar p |

| --- | --- | --- | --- | --- | --- |

| Our Q4_K_M / Unsloth Q4_K_M (0.532 / 0.533) | 0.022265 / 0.039005 | 42.9% | 39 / 28 | 13 / 2 | 0.007385 |

| Our Q5_K_M / bartowski Q4_K_M (0.569 / 0.580) | 0.013993 / 0.034045 | 58.9% | 39 / 28 | 14 / 3 | 0.01273 |

| Our Q5_K_M / Unsloth UD-Q4_K_XL (0.569 / 0.559) | 0.013993 / 0.025893 | 46.0% | 39 / 39 | 7 / 7 | 1 |

| Our Q5_K_M / Unsloth Q5_K_S (0.569 / 0.569) | 0.013993 / 0.018341 | 23.7% | 39 / 43 | 4 / 8 | 0.3877 |

BF16 scored 34/60. In table order, six-document sign-flip p-values are 0.03125, 0.03125, 0.03125, 0.03125. BFCL clustered p-values are 0.019287, 0.011353, 1, 0.34375. The clusters are the 41 function groups defined by BFCL task IDs. After Bonferroni correction across 16 comparisons per endpoint, the KL p-values are 0.5, 0.5, 0.5, 0.5. None of these tool-call differences survives that correction. These are exploratory fixed-file comparisons, not evidence of general superiority or equivalence. The fourth comparator is a post-hoc coverage check added after inspecting download sizes, before inspecting its outputs.

Lower mean KL does not mean every token is closer: on prose-literature, our Q4 maximum token KL is 2.481113 versus Unsloth Q4 1.248548. The advantage over plain Q4 files does not extend to Unsloth’s dynamic Q4 on this tool slice: both scored 39/60. The similarly sized Unsloth Q5_K_S scored 43/60 against our Q5 at 39/60; the lower mean KL of our Q5 did not translate into a higher tool score.

<details>

<summary>Corrected authored tool diagnostic</summary>

A second tool set contains 24 authored prompts in six families, with explicit date/time, enum and exact-copy constraints. Its schemas were corrected after inspecting ambiguous v1 outputs, so this is not a blind benchmark. The rerun used greedy decoding, thinking off, a 1,024-token cap and seed 2026101506.

| File | Correct /24 |

|---|---:|

| Our Q4_K_M | 24 |

| Our Q5_K_M | 23 |

| Unsloth BF16 | 23 |

| Unsloth Q4_K_M | 20 |

| Unsloth UD-Q4_K_XL | 22 |

| Unsloth Q5_K_S | 24 |

| bartowski Q4_K_M | 18 |

In the four comparison rows above, exact six-family sign-flip p-values are 0.25, 0.125, 1, 1, and Bonferroni-adjusted values across 16 diagnostic comparisons are 1, 1, 1, 1. A high score on these few related prompts does not establish general tool accuracy or equivalence.

</details>

Separate CPU replay of the original panels

The released files were rerun on the workstation CPU with llama.cpp b11617, eight inference threads, one 8,192-token slot, greedy decoding, seed 20261015 and thinking off. BFCL uses the original 400 simple-Python tasks and official AST checker, with the development and selection-exposed halves kept separate. GSM8K uses the exact original first 250 questions, a 768-token output limit and the original boxed-answer/last-number parser. The public Unsloth BF16 file is the reference; the historical producer BF16 identity is unestablished. These results do not recreate the separate unpublished Mac Q5 build or establish CPU/GPU equivalence.

| File | BFCL development /200 | BFCL selection-exposed /200 | GSM8K /250 | Boxed-only /250 | Nontruncated /250 |

|---|---:|---:|---:|---:|---:|

| Our Q4_K_M | 148 | 161 | 136 | 135 | 135 |

| Our Q5_K_M | 119 | 153 | 138 | 136 | 137 |

| unsloth BF16 | 136 | 156 | 143 | 142 | 142 |

| unsloth Q4_K_M | 75 | 94 | 133 | 130 | 130 |

| unsloth UD-Q4_K_XL | 104 | 119 | not run | not run | not run |

| bartowski Q4_K_M | 74 | 97 | 137 | 136 | 136 |

Boxed-only and nontruncated sensitivities keep all 250 questions in the denominator and treat rejected outputs as failures. They were specified after inspecting truncation and parser behavior. The historical RTX BF16 result is 145/250; this CPU/public-reference result is 143/250, with 35 output-limit hits. Counts can change across artifact, hardware and runtime settings.

| GSM8K comparison | Only ours / other | Exact McNemar p | Bonferroni p (10 pairs) |

|---|---:|---:|---:|

| Our Q4_K_M / unsloth BF16 | 26 / 33 | 0.43499 | 1 |

| Our Q4_K_M / unsloth Q4_K_M | 32 / 29 | 0.79815 | 1 |

| Our Q4_K_M / bartowski Q4_K_M | 35 / 36 | 1 | 1 |

| Our Q5_K_M / unsloth BF16 | 23 / 28 | 0.57585 | 1 |

| Our Q5_K_M / unsloth Q4_K_M | 33 / 28 | 0.60892 | 1 |

| Our Q5_K_M / bartowski Q4_K_M | 33 / 32 | 1 | 1 |

These post-hoc paired tests concern this fixed panel and scorer, not general maths quality.

<details>

<summary>CPU BFCL paired tests</summary>

| Comparison | Panel | Only ours / other | Exact McNemar p | Bonferroni p (30 tests) |

|---|---|---:|---:|---:|

| Our Q4_K_M / unsloth BF16 | dev200 | 19 / 7 | 0.028959 | 0.86878 |

| Our Q4_K_M / unsloth BF16 | selection-exposed200 | 11 / 6 | 0.33231 | 1 |

| Our Q4_K_M / unsloth Q4_K_M | dev200 | 76 / 3 | 2.7211e-19 | 8.1633e-18 |

| Our Q4_K_M / unsloth Q4_K_M | selection-exposed200 | 70 / 3 | 1.3743e-17 | 4.1228e-16 |

| Our Q4_K_M / unsloth UD-Q4_K_XL | dev200 | 48 / 4 | 1.3065e-10 | 3.9196e-09 |

| Our Q4_K_M / unsloth UD-Q4_K_XL | selection-exposed200 | 45 / 3 | 1.3126e-10 | 3.9378e-09 |

| Our Q4_K_M / bartowski Q4_K_M | dev200 | 77 / 3 | 1.4128e-19 | 4.2385e-18 |

| Our Q4_K_M / bartowski Q4_K_M | selection-exposed200 | 66 / 2 | 1.5904e-17 | 4.7712e-16 |

| Our Q5_K_M / unsloth BF16 | dev200 | 4 / 21 | 0.00091052 | 0.027316 |

| Our Q5_K_M / unsloth BF16 | selection-exposed200 | 9 / 12 | 0.66362 | 1 |

| Our Q5_K_M / unsloth Q4_K_M | dev200 | 47 / 3 | 3.7083e-11 | 1.1125e-09 |

| Our Q5_K_M / unsloth Q4_K_M | selection-exposed200 | 62 / 3 | 2.4842e-15 | 7.4527e-14 |

| Our Q5_K_M / unsloth UD-Q4_K_XL | dev200 | 23 / 8 | 0.010674 | 0.32022 |

| Our Q5_K_M / unsloth UD-Q4_K_XL | selection-exposed200 | 37 / 3 | 1.9465e-08 | 5.8395e-07 |

| Our Q5_K_M / bartowski Q4_K_M | dev200 | 47 / 2 | 4.3556e-12 | 1.3067e-10 |

| Our Q5_K_M / bartowski Q4_K_M | selection-exposed200 | 59 / 3 | 1.7249e-14 | 5.1748e-13 |

The correction covers all 15 file pairs on both panels. Neither panel is new independent release-selection evidence.

</details>

The original WikiText/OASST texts were independently reconstructed to matching hashes and replayed over 60 chunks of 512 tokens each. These are new CPU measurements with the pinned public BF16 reference, separately from the historical hardware/build tables above.

| File | Wiki / chat mean KL | Wiki / chat top-1 agreement | Wiki / chat P99 token KL |

|---|---:|---:|---:|

| bartowski Q4_K_M | 0.029953 / 0.029502 | 90.791% / 91.843% | 0.154004 / 0.182833 |

| unsloth Q4_K_M | 0.033473 / 0.033248 | 90.366% / 91.542% | 0.166522 / 0.207902 |

| Our Q4_K_M | 0.017288 / 0.017126 | 92.523% / 93.353% | 0.083643 / 0.108646 |

| unsloth UD-Q4_K_XL | 0.023854 / 0.024001 | 91.614% / 92.660% | 0.115226 / 0.145981 |

| unsloth Q5_K_S | 0.015192 / 0.013366 | 93.340% / 94.222% | 0.072122 / 0.080464 |

| Our Q5_K_M | 0.012005 / 0.011123 | 93.667% / 94.719% | 0.058802 / 0.063854 |

Lower mean KL is not a claim that every token, task or tail metric improves.

What is not better

• Download size is not the same as active-weight size. The pinned bartowski Q4_K_M contains a 15-tensor MTP block with 21,747,712 payload bytes, unused by ordinary decoding. Subtracting that payload from its 579,615,840-byte download gives 557,868,128 bytes, below our Q5_K_M's 569,082,048 bytes. Our files and the tested Unsloth files contain no MTP block. The comparisons above match download sizes, not active-weight budgets.
• Maths: in the historical GSM8K runs every quantized file, ours and public, scored below the original. On the RTX 5090 the original got 145 of 250, our Q4_K_M 137 and Q5_K_M 132, bartowski's Q4_K_M 138 and Unsloth's 131. On the M3 Max the original got 134, our Q5_K_M Mac build 122, bartowski's 129 and Unsloth's 124. Those historical runs supplied no paired GSM8K test. The separate CPU replay above includes paired tests and scoring sensitivities; it does not establish a general maths gain.
• MMLU-Pro: every file, including the original, got 32 to 39 of 280, against about 28 expected from guessing among 10 choices. At this size the test says little about the files.
• Unsloth's UD-Q4_K_XL (0.559 GB) holds up much better on tool calling than the plain Q4_K_M files (104 of 200 selection-exposed on the M3 Max). Our unpublished file at that size recorded KL .0121 against .0215 and tool-calling counts of 112 against 104 (p = 0.23). The tool-calling difference was not significant, so we do not publish it. That decision used the selection-exposed run above.
• The historical tool benchmark covered single-function BFCL simple calls with thinking off. The fresh authored tool and runtime probes have narrower scope than a general task benchmark.
• The historical tables cover two machines and one llama.cpp release. MMLU-Pro was run on the M3 Max only.

Public files: unsloth/Qwen3.5-0.8B-GGUF revision 6ab4614 (Qwen3.5-0.8B-Q4_K_M.gguf) and bartowski/Qwen_Qwen3.5-0.8B-GGUF revision f36b1ea (Qwen_Qwen3.5-0.8B-Q4_K_M.gguf), each checked by SHA-256. Those historical runs used all layers on the GPU and F16 KV cache.

File-level fidelity summary

These values repeat the historical RTX 5090 measurements, not the separate CPU replay; agreement measures closeness to BF16, not task accuracy.

| File | Same next token as BF16, WikiText-2 test |

| --- | --- |

| Qwen3.5-0.8B-Artemis-Q5_K_M.gguf | 94.2% |

| Qwen3.5-0.8B-Artemis-Q4_K_M.gguf | 92.7% |

</details>

<details>

<summary>Conversion and calibration sources</summary>

Both files were quantized with llama.cpp release b11617 (commit 14310190c, llama-quantize) from a BF16 conversion of the original made without the MTP layer, using an importance matrix. The calibration text is human-written only:

• Q4_K_M: the first 256 chunks of 512 tokens of the WikiText-2 raw training text (Salesforce/wikitext revision b08601e, wikitext-2-raw-v1, train split). This importance matrix is in the repository as Qwen3.5-0.8B-Artemis-imatrix.gguf.
• Q5_K_M: the whole WikiText-2 raw training text (4,894 chunks of 512 tokens) from the wikitext-2-raw archive. This importance matrix is not published.

WikiText-2 is licensed CC BY-SA 3.0. No WikiText text is included in the files. Both files' headers name TurinTech in general.quantized_by and the calibration set in quantize.imatrix.dataset.

</details>

<details>

<summary>File names, sizes and SHA-256 checksums</summary>

File names

Bits per weight uses tensor payload bytes, excluding GGUF metadata.

File names end in a standard llama.cpp quant label, so llama.cpp, Ollama and LM Studio can pick a file by tag. Each file is a per-tensor mix of K-quants on a Q4_K base (the Q4_K_M file also has a few small tensors at Q8_0 and F16), with no type making up 90% of the bytes, so the labels are size classes: the smallest standard llama.cpp quant whose file, made from the same BF16 conversion, has at least as many bits per weight. A stock Q4_K_M of this model is 5.51 bits per weight, a stock Q5_K_S 5.88 and a stock Q5_K_M 6.03. The Q5_K_M file (5.93) follows that rule. The Q4_K_M file is an exception: by the rule it would be Q5_K_S, but at 5.54 bits per weight it is 0.6% above a stock Q4_K_M and below Unsloth's Q4_K_M (5.55), the size it was built to stay under, so it keeps the Q4_K_M label. The general.file_type field inside each file matches its label. Public files with the same label can have different tensor allocations. Bartowski's Q4_K_M download also includes an unused MTP block; see the active-weight comparison above.

| File | Bits per weight | Main tensor types (share of tensor payload bytes) |

| --- | --- | --- |

| Qwen3.5-0.8B-Artemis-Q5_K_M.gguf | 5.93 | Q5_K 56.1%, Q6_K 43.5% |

| Qwen3.5-0.8B-Artemis-Q4_K_M.gguf | 5.54 | Q5_K 72%, Q6_K 15%, Q4_K 11%, Q8_0 1% |

File checksums

| File | Bytes | sha256 |

| --- | --- | --- |

| Qwen3.5-0.8B-Artemis-Q5_K_M.gguf | 569,082,048 | 3b782856b66f61b4494b346ad8ff3e91a0d4c294ecedd1797f1855a078abbd05 |

| Qwen3.5-0.8B-Artemis-Q4_K_M.gguf | 532,402,496 | 01e0651f0fc5d0f9a3d1a68166fbdf12ab4d3bb135b3d725d694f42becfaa5a4 |

| Qwen3.5-0.8B-Artemis-imatrix.gguf (importance matrix, not a model) | 2,275,008 | e0ddf989466e5001798cc5ece4b8ed9f99852ed57e612c5993cb173b29123398 |

</details>

Artemis

Teams use Artemis to test and improve code against their own objectives. See Artemis.

Licence

Apache-2.0, the licence Qwen releases Qwen3.5 0.8B under (licence); see LICENSE and NOTICE. The importance matrices used for quantization were computed from the WikiText-2 training text (Wikipedia, CC BY-SA 3.0); no WikiText text is included in the files, including the importance-matrix file.

These files keep improving.