Qwen3-Next-80B-A3B-Instruct REAP · file← Qwen3-Next-80B-A3B-Instruct REAP

Q4_K_M

mradermacher's Q4_K_M, to test on llama.cpp again. Alan liked it in use; deleted at the end. Mradermacher GGUF.

Size: 36.7 GB
Status: Deleted 11 Sep 2026
Scored runs: 5
Smallest Mac: 64 GB estimate, 8K context

Results5 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
synthesisreap-60b-gguf-q4km	81.7%	70.1–89.4	Passed 49/60	llama.cppextraction	2026-09-10
toolcallreap-60b-gguf-q4km	41.7%	30.1–54.3	Passed 25/60	llama.cppextraction	2026-09-10
toolscalereap-60b-gguf-q4km	87.5%	73.9–94.5	Passed 35/40	llama.cppextraction	2026-09-10
worldviewreap-60b-gguf-q4km	80.0%	65.2–89.5	Passed 32/40	llama.cppextraction	2026-09-10
VOID-degenerate-nullschemareap-60b-gguf-q4kmflaggedvoid	100.0%	94.9–100.0	Passed 72/72	llama.cppextraction	2026-09-10

Runs marked unenforced were measured on a suite that requires constrained decoding, on a server shown not to apply the schema: mlx_lm accepts it and ignores it, and a few other servers and models break it. Those numbers do not measure what the suite is designed to measure. They are kept and labelled rather than deleted.

Corrections1 to the record published 21 October 2026

On the VOID-degenerate-nullschema run of 10 September 2026: voided. A degenerate run: every response was empty and was graded as a decline, so 72/72 is not a score.
Corrected 24 October 2026 · a mechanical fix

The recordHow it was made · how it was served · what went wrong · what happened to it

Rebuilt from the lab's records by Claude, an AI model. The results above come straight from the automated runs. How these pages are made.

File	`Qwen3-Next-80B-A3B-Instruct-REAP.Q4_K_M.gguf` (36,734,589,760 B)
Format	GGUF Q4_K_M
Where from	downloaded 2026-09-10 from `mradermacher/...-REAP-GGUF`
Status	deleted 2026-09-11 19:36Z
Hugging Face	same repo

Where it came from

Repo and file: mradermacher/Qwen3-Next-80B-A3B-Instruct-REAP-GGUF / Qwen3-Next-80B-A3B-Instruct-REAP.Q4_K_M.gguf, 36,734,589,760 bytes (34.21 GiB; the download script's 34.2 GB). sha256 and revision: not on record.
Command: a zsh wrapper in a scratch folder that split the file into six curl -sL -H 'User-Agent: curl/8' -r START-END range requests into models/qwen3-next-reap-gguf/part.N and joined them with cat part*. Started 2026-09-10 13:55:57Z; the 11.3 of 34.2 GB mark at 14:12Z; 32.1 GB at 15:00Z; complete before the benchmark launched at 15:15Z.
Why this quant: the assistant wanted REAP "measured on the same binary, flags, profile and datasets as your entire board, for the first time" after the MLX rerun disagreed with the history; uniform Q4_K_M "either way, which is the variable under test".
Caveat recorded at the time: "this is mradermacher's prune of Qwen3-Next-80B-A3B-Instruct, not necessarily the same pruning run" as the MLX builds. Not resolved.
Who asked: Alan, 13:07Z: "so... we probably need to look at the non reap again then or see if there's a guff version? what about other mlx runtimes? we did see differences" and 13:53Z: "nah I want to get the 4bit ream back".

How it was served

label	dates (UTC)	binary and version	ctx / -np / KV / -fa / `--jinja` / `--reasoning-format`	harness profile	why this label exists
`reap-60b-gguf-q4km`	2026-09-10 15:18:08Z toolcall, 15:21:42Z toolscale, 15:23:13Z worldview, 15:24:01Z nullschema, 15:26:19Z synthesis (finish 16:18 to 16:26 BST)	`llama.cpp/build/bin/llama-server` b10893 `c32d1dabe` (upgrade from `eb25b7263` completed 2026-09-10 ~12:20Z)	`-c 32768 -np 1 -fa on --load-mode none -ctk q8_0 -ctv q8_0 -ngl 999 --jinja --reasoning-format deepseek --alias reap-gguf`	extraction	first REAP result on the same runtime as the rest of the 2026-09-10 board
(no label) Hermes use	2026-09-10 16:19Z to ~16:30Z and later	same	restarted with `-c 262144` (41.2 GB resident; Hermes demands at least 64K)	n/a	Alan took it for a spin in Hermes
(no label) llama-bench / speed probe	2026-09-10 15:17Z; 2026-09-11	same	decode 38.1 / 28.2 / 19.0 tok/s at short / ~5k / ~16k; 40.27 tok/s on 2026-09-11 (The 'MLX is 3x faster on MoE' claim benchmarks Ollama, not llama.cpp)	n/a	speed row for the board

Seats held: none formal. It briefly occupied the seat (the Hermes primary slot, formerly K2-36B) for Alan's interactive use.

Decisions

Why fetched: to separate runtime from quant from prune after the MLX build disagreed with history (family doc, 2026-09-10 12:53Z to 13:56Z).
Why used: Alan wanted to drive it. After the board row (toolcall 41.7), Alan: "ah so it's quite shit then"; then "yeah a bit disappointing though, if it's available I might take for a spin in hermes?"; after trying it: "it feels much better than the 36b" and "it's doing a better job on the tool calling experience".
Assistant's cautions at the time: REAP "accepts the framing you're given" (endorsed a site's claims without pushing back); its adversarial critique produced fabricated citations, "more dangerous than no citations". The suite worldview score grades copying a supplied slug, not retrieving a URL.
Why deleted: Alan, 2026-09-11 19:34:59Z, "Not reap, ditch reap". Deleted 19:36Z with the 4-bit MLX build; the assistant had called the pair "your cleanest runtime-vs-runtime pair" ten hours earlier and recommended keeping both, then proposed deleting them once their purpose was served.

What went wrong

Degenerate nullschema, scored 100%. All three arms scored 24/24 and the file holds responses like {"serial": ""} (12 of 72) and {"port": ""} (11): empty strings, which the grader accepted as a decline. The assistant: "any model that returns empty strings scores 100%". A second case was found the same day: granite-4.2-30b-mlx-q4, sitting at 100% on the board since it was first run, with five distinct responses in 72 cases. The detector was added to the harness. The grader fix itself is for the locked-harness version-bump process.
Wrong zero from a parser mismatch, avoided. The same morning a different model's 0/60 toolcall was recognised as REAP's 2026-09-09 parser false zero.
Prune provenance unresolved. The 41.7 / 80.0 vs 78.3 / 47.5 split between this file and mixed36 is not attributable, because the GGUF's source prune was never checked against Samsung's.
Standing checks. Partial runs: none (rows match case counts: 60 / 40 / 40 / 72 / 60). Stale build stamp: the run log's llama.cpp b10893 (c32d1dabe) matches the upgrade. Missing flags: none for the board (--jinja, --reasoning-format deepseek, -fa on); the Hermes restart changed ctx to 262,144 without a new label.

What happened to it

Downloaded 2026-09-10 13:55Z to ~15:10Z → benched 15:18Z to 15:26Z, Hermes 16:19Z → kept through 2026-09-11 (paired with the MLX 4-bit build; the reconversion's closest comparison) → deleted 2026-09-11 19:36Z with qwen3-next-reap-mlx-4bit-uniform (66 GB total, free 202 GB, 57 result files verified first). No RESTORE-deleted-*.sh entry (RESTORE-deleted-20260911.sh covers only the safetensors source). Re-downloadable from mradermacher/Qwen3-Next-80B-A3B-Instruct-REAP-GGUF. Run-log results survive.