GraySoft
Projects Models Compare Cloud benchmarks FAQ Download guIDE →
Model Intelligence Sheet

Joakimpalm-Zen/Qwen3-30B-A3B-selective-attnQ8_0-expQ4_0-GGUF overview

Qwen3 30B A3B selective precision, attention Q8 0 / experts Q4 0 GGUF < BEGIN runner toolcalling Serve with xyntetik runner &mdash; tool calls that still parse…

ggufmoeqwen3moeselective-precisionstructural-derivativexyntetik-runnertext-generationbase_model:Qwen/Qwen3-30B-A3Bbase_model:quantized:Qwen/Qwen3-30B-A3Blicense:apache-2.0endpoints_compatibleregion:usconversational

Runs locally from ~16.75 GB disk (24 GB VRAM class GPUs with llama.cpp / guIDE).

Downloads
257
Likes
0
Pipeline
text-generation

Repository Files & Downloads

1 GGUF files detected
Direct downloads for local inference
FileTypeQuantizationSizeLink
Qwen3-30B-A3B-expq4_0-attnq8_0.ggufGGUFGGUF16.75 GBDownload

Model Details

Model IDJoakimpalm-Zen/Qwen3-30B-A3B-selective-attnQ8_0-expQ4_0-GGUF
AuthorJoakimpalm-Zen
Pipelinetext-generation
Licenseapache-2.0
Base modelQwen/Qwen3-30B-A3B
Last modified2026-08-20T17:36:16.000Z

Model README

---

license: apache-2.0

base_model: Qwen/Qwen3-30B-A3B

tags:

  • gguf
  • moe
  • qwen3moe
  • selective-precision
  • structural-derivative
  • xyntetik-runner

pipeline_tag: text-generation

---

Qwen3-30B-A3B selective precision, attention Q8_0 / experts Q4_0 (GGUF)

<!-- BEGIN runner-toolcalling -->

Serve with xyntetik-runner &mdash; tool calls that still parse when the budget runs out

This GGUF is built to be served with xyntetik-runner, a single-binary, dependency-free C11 inference engine (CPU / CUDA / Metal, OpenAI-compatible server). Its one differentiator you cannot get from another engine:

> When a tool call runs past its token budget, Runner closes it to the smallest schema-legal document, so the arguments still parse.

Most OpenAI-compatible engines return finish_reason: "length" with an empty or malformed tool_calls the caller has to repair or retry. Runner does forced-truncation recovery: once a JSON document starts, it emits a legal ending when the budget expires. On local models &mdash; tight context, slow generation &mdash; that is the difference between an agent loop that finishes and one that retries from scratch.

Measured &mdash; what each engine hands the caller when the token budget cuts a tool call short (same box, same tool schema, same prompt, tool_choice:"required", temperature 0, budgets 1&rarr;64):

| engine | budget too small (1&ndash;16 tokens) | enough budget (64, control) |

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

| Runner | executable tool_calls, arguments parse | completes |

| vLLM 0.27.1 | no call; protocol framing leaks into content | completes |

| llama.cpp b10488 | no call; leak, then tool_calls with unparseable args | completes |

| Ollama 0.32.14 | no call; empty content, then HTTP 500 | completes |

| TensorRT-LLM 1.2.1 &dagger; | no call; <tool_call> leak, then empty content | completes |

| SGLang 0.5.17 &dagger; | no call; <tool_call> leak, then empty content | completes |

Every engine completes at 64 tokens &mdash; the failure is truncation, not misconfiguration. Below that, only Runner returns an executable call. This is the behaviour across every OpenAI-compatible engine measured, not a claim about engines not measured. &dagger; TensorRT-LLM and SGLang were measured on a Qwen3-1.7B substitute; truncation recovery is a property of the runtime, not the model.

Constrained decoding also holds the shape of a tool call under quantization: on a full quant ladder, schema conformance and tool selection stayed 100% down to Q4_0 (argument agreement decayed to 50%) &mdash; it guarantees the shape of a call at any quantization, not its contents.

Quickstart

# build the single binary (no deps), then serve this GGUF:
runner -m Qwen3-30B-A3B-expq4_0-attnq8_0.gguf --serve
# point any OpenAI-compatible client at http://localhost:8080/v1

Full recipe, raw responses, and the per-release regression gate: the truncation benchmark.

<!-- END runner-toolcalling -->

Run it

This file is 18.0 GB, so it wants a machine with roughly 20 GB of usable

memory or more.

# Apple Silicon Mac
curl -L https://github.com/Joakimpalm-Zen/xyntetik-runner/releases/latest/download/runner-macos-arm64.tar.gz | tar xz
curl -L -o Qwen3-30B-A3B-expq4_0-attnq8_0.gguf \
  https://huggingface.co/Joakimpalm-Zen/Qwen3-30B-A3B-selective-attnQ8_0-expQ4_0-GGUF/resolve/main/Qwen3-30B-A3B-expq4_0-attnq8_0.gguf
./runner-macos-arm64 -m Qwen3-30B-A3B-expq4_0-attnq8_0.gguf -i

Linux and Windows builds are on the

same release page.

Any GGUF runtime with qwen3moe support should load it: every tensor is an

ordinary GGUF type, only the per-tensor assignment is unusual.

This is not a uniform quantization. It is a precision PLAN: the expert

banks (the bulk of a MoE's bytes) are Q4_0 while attention, embeddings and

every shared tensor stay Q8_0. Category-wise:

| Model | Expert tensors | Attention/shared | Size | Category |

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

| Qwen3-30B-A3B Q8_0 (Qwen) | Q8_0 | Q8_0 | 32.48 GB | official, the source |

| Qwen3-30B-A3B Q4_K_M (Qwen) | Q4_K/Q6_K | Q4_K class | 18.56 GB | official uniform quant |

| this file | Q4_0 | Q8_0 | 17.99 GB | selective-precision derivative |

  • File: Qwen3-30B-A3B-expq4_0-attnq8_0.gguf (17,988,417,024 bytes)
  • SHA256: df02efa815a74e6207f9e01f2d38272c1e2718bb23aec544709a02a2c7d5b206
  • Source: Qwen/Qwen3-30B-A3B-GGUF -> Qwen3-30B-A3B-Q8_0.gguf

(SHA256 4ad960d180b16f56024f5b704697e5dd5b0837167c2e515ef0569abfc599743c,

verified byte for byte against the repo's LFS record before quantizing)

Why this split: the methodology

Produced with the open tooling in

Xyntetik Runner:

  1. Plan: --type-plan applies per-tensor precision rules while

rewriting; first matching rule wins. The exact plan for this file:

{"default": "keep", "rules": [{"match": "_exps.weight", "type": "q4_0"}]}

With a Q8_0 source, "keep" leaves attention, embeddings and shared

tensors at Q8_0; the single rule sends every stacked expert bank to

Q4_0.

  1. Build: `runner -m Qwen3-30B-A3B-Q8_0.gguf --quantize out.gguf

--type-plan plan.json`. The quantizer's integrity gate asserts every

tensor outside the rules is byte-for-byte identical to the source,

not merely that the file loads.

  1. Gate: zero-point self-check first (exact: 0.0 KLD / 100% top-1),

then 400 teacher-forced positions against the Q8_0 source

(scripts/kld-compare-raw.py, greedy, KLD over the union of both

sides' top-20 logprobs).

A note on granularity: per-EXPERT precision is not representable in GGUF.

Experts are stored stacked, one tensor per layer, and a GGUF tensor

carries exactly one type. Per tensor CLASS is the finest split the format

allows, and it turns out to be the effective one.

Validation: it passes where the uniform quant fails

Publication bar (this project's, adopted 2026-08-14): margin-qualified

top-1 at or above 97% AND mean KLD at or below 0.05 vs the source, over

400 positions. Plain top-1 is always reported beside it.

| artifact | size | plain top-1 | margin-qualified top-1 | mean KLD | verdict |

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

| this file | 17.99 GB | 90.75% | 99.50% | 0.034 | PASS |

| official uniform Q4_K_M | 18.56 GB | 79.00% | 94.75% | 0.114 | FAIL |

Same source, same protocol, same day, same machine. The selective plan is

smaller than the uniform k-quant and 3.3x closer to the source: for a MoE

model, precision should not be spent uniformly. The expert bulk tolerates

four bits; attention does not.

MoE KLD on this harness carries small cache-state variability in the

fourth decimal, so KLD is quoted to three decimals (raw gate JSONs, with

per-position records, are in the

Xyntetik suite evidence).

Scope and limits

  • The gate measures agreement with the source model's own distribution,

not downstream capability. This artifact has not been benchmarked on

tasks.

  • 17.99 GB does not fit a 16 GB machine. Getting under that envelope

needs the expert banks at three bits (Q3_K), which this quantizer does

not write yet; that is recorded as the open item, not implied.

  • Expert COUNT is untouched: all 128 experts, top-8 routing, exactly the

source's geometry. This is precision reallocation, not pruning (this

model measurably does not tolerate pruning; see the account's

Qwen3-Coder keep-120 card for the model that does).

Publication policy

This project publishes only artifacts that passed its quality gate, and

re-measures published claims under its current standard: one earlier

artifact (gpt-oss-20b keep-30) was re-gated under this bar, failed it,

and its card now says so plainly. This file passes the same bar that

superseded that one. An optimization does not pass because the file got

smaller; it has to preserve the model and produce a configuration worth

running.

Measured envelope

Every artifact this account publishes ships a measured-envelope sidecar

(Qwen3-30B-A3B-expq4_0-attnq8_0.gguf.envelope.json, in this repo) — the same file

xyntetik-runner reads at

load: download it next to the GGUF and the runner reports the measured state at

load. A measured envelope is a **dated observation, not a standing quality

claim** — it records exactly what this file is, where it came from, and what

was measured, so the claims above stay traceable.

| | |

|---|---|

| artifact sha256 | df02efa815a74e6207f9e01f2d38272c1e2718bb23aec544709a02a2c7d5b206 |

| what changed | selective precision via --type-plan: attention+embeddings Q8_0, expert banks Q4_0 |

| reference (Q8_0 source) sha256 | 4ad960d180b16f56024f5b704697e5dd5b0837167c2e515ef0569abfc599743c |

| fidelity vs parent | PASSES the bar — margin-qualified top-1 99.50%, mean KLD 0.034 (table above) |

| tool calling | generic constrained envelope (truncation-safe; see the tool-calling section above) |

| measured | 2026-08-19 |

| verdict | experimental — loads with a banner; never a standing certification |

Run Joakimpalm-Zen/Qwen3-30B-A3B-selective-attnQ8_0-expQ4_0-GGUF with guIDE

Download guIDE — the AI-native code editor with local LLM inference and 69 built-in tools.

Download guIDE → · Browse 524k+ models · Compare models

Source: Hugging Face · Compare models