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

Release: built to be downloaded and served with Xyntetik Runner.

• Measured status against the parent: passes the adopted bar (margin-qualified top-1 >= 97% and mean KLD <= 0.05) where the official uniform Q4_K_M fails it; the plan is on this card.
• Parent model: Qwen/Qwen3-30B-A3B, from a byte-verified first-party Q8_0
• Collection: Runner Releases, also in Pruning and Quantization Frontiers
• Evidence: the fidelity tables on this card, measured at 400 teacher-forced positions
• Runner compatibility: any Runner release; built with --type-plan.

• Validation status (Runner support tiers): each file's row in the Runner roster says which tier it is in, what is re-checked on a release and the date and version of the last run.
  • Qwen3-30B-A3B-expq4_0-attnq8_0.gguf: roster row

Want this for another model? The tools behind these files are open: requantization, expert pruning and sublayer removal in Xyntetik Runner, and the method for this file is on this card or in its evidence dataset.

Request a model · Report your result · Community results · All files

If this file is useful to you, a contribution funds the hardware time behind the next one.

Serve with xyntetik-runner — 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 — tight context, slow generation — that is the difference between an agent loop that finishes and one that retries from scratch.

Measured — 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→64):

Every engine completes at 64 tokens — 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. † 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%) — 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.

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:

• 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. 2. 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. 3. 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.

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.

About Xyntetik

This repository is published by Xyntetik, the Zenova AB program for running capable language models on hardware you own and proving what they did. Its released engine is Xyntetik Runner: a free, single-binary GGUF engine in C for CPU, CUDA and Metal that serves, scores and trains through the quantized file it deploys and records every run as a receipt. The measurements behind the program's claims are collected at xyntetik.com/evidence. The program's organization on Hugging Face is Xyntetik.