/ Модель

Характеристики

Лицензия
Apache 2.0
Базовая модель
Qwen3-30B-A3B
Опубликована
12 авг 2026

Qwen3-30B-A3B-selective-attnQ8_0-expQ4_0-GGUF

Генерация текстаТекст → текст5 профессий

Квантованная сборка Qwen3-30B-A3B в GGUF для диалогов и генерации текста с повышенной точностью внимания и сниженной точностью MoE-экспертов.

421скачиваний за 30 дней0лайковвеса обновлены6 окт 2026

Бенчмарки

Как модель справилась с задачами пользователей ailist и что о ней публикуют открытые лидерборды

Тесты пользователейпока нет

Никто ещё не опубликовал тест этой модели. Соберите бенчмарк из своих задач — результат появится здесь.

  1. Добавьте модель в бенчмарк

    Вместе с другими моделями категории «Текст» — сравнение идёт внутри одной категории.

  2. Опишите свои задачи

    Напишите запросы, при необходимости приложите файлы и эталонные ответы.

  3. Запустите и опубликуйте

    Модели ответят на каждую задачу, судья оценит ответы. Опубликованный результат появится на этой странице.

Публичные оценки

Из открытых лидербордов. Сравнивайте результаты одного теста при одинаковых условиях — отсутствие оценки не значит, что модель хуже.

В подключённых источниках результатов для этой модели пока нет.

Что умеет модель

Описание составлено по карточке модели и метаданным Hugging Face

Это GGUF-сборка Qwen3-30B-A3B от Joakimpalm, подготовленная для запуска с Xyntetik Runner. В модели сохранены веса внимания, эмбеддингов и общие тензоры в Q8_0, а банки экспертов MoE переведены в Q4_0; исходные 128 экспертов и маршрутизация top-8 сохранены. Файл занимает около 18 ГБ и требует примерно 20 ГБ доступной памяти.

Модель предназначена для диалогов и генерации текста. Карточка проверяет близость распределения выходов к исходной версии Q8_0 на 400 позициях: указаны margin-qualified top-1 99,50% и средний KLD 0,034. Это сравнение с исходной моделью, а не оценка качества на прикладных задачах; отдельных тестов способностей в карточке нет. Для запуска карточка рекомендует Xyntetik Runner.

Лицензия — Apache-2.0. Указанная выборочная точность уменьшает размер относительно приведённой в карточке равномерной Q4_K_M-сборки, но модель не помещается в 16 ГБ памяти.

Сценарии применения

  • диалоговые ответы и чат
  • генерация связного текста
  • запуск Qwen3-30B-A3B в GGUF через Xyntetik Runner

Ограничения

Карточка оценивает совпадение с исходной моделью, но не приводит бенчмарков прикладных задач. Файл занимает около 18 ГБ и не помещается в 16 ГБ памяти.

Для каких профессий подходит5

Разделы каталога профессий, в задачах которых используется эта модель

Все профессии

Также подходит для

Карточка модели

README от автора на Hugging Face, как он его опубликовал

Открыть на Hugging Face

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.

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

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):

enginebudget too small (1–16 tokens)enough budget (64, control)
Runnerexecutable tool_calls, arguments parsecompletes
vLLM 0.27.1no call; protocol framing leaks into contentcompletes
llama.cpp b10488no call; leak, then tool_calls with unparseable argscompletes
Ollama 0.32.14no call; empty content, then HTTP 500completes
TensorRT-LLM 1.2.1 †no call; <tool_call> leak, then empty contentcompletes
SGLang 0.5.17 †no call; <tool_call> leak, then empty contentcompletes

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:

ModelExpert tensorsAttention/sharedSizeCategory
Qwen3-30B-A3B Q8_0 (Qwen)Q8_0Q8_032.48 GBofficial, the source
Qwen3-30B-A3B Q4_K_M (Qwen)Q4_K/Q6_KQ4_K class18.56 GBofficial uniform quant
this fileQ4_0Q8_017.99 GBselective-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. 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.

artifactsizeplain top-1margin-qualified top-1mean KLDverdict
this file17.99 GB90.75%99.50%0.034PASS
official uniform Q4_K_M18.56 GB79.00%94.75%0.114FAIL

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 sha256df02efa815a74e6207f9e01f2d38272c1e2718bb23aec544709a02a2c7d5b206
what changedselective precision via --type-plan: attention+embeddings Q8_0, expert banks Q4_0
reference (Q8_0 source) sha2564ad960d180b16f56024f5b704697e5dd5b0837167c2e515ef0569abfc599743c
fidelity vs parentPASSES the bar — margin-qualified top-1 99.50%, mean KLD 0.034 (table above)
tool callinggeneric constrained envelope (truncation-safe; see the tool-calling section above)
measured2026-08-19
verdictexperimental — loads with a banner; never a standing certification

Как запустить

На своей GPU в ailist. Цена — по текущим предложениям провайдеров

GPU в ailist

llama.cpp

Можно запустить

Подбираем GPU…

Ревизия весов
c998e32

0 моделей