Qwen3-Next-80B-A3B-Instruct · file← Qwen3-Next-80B-A3B-Instruct
IQ4_XS
The main file. Most of the scores here are from it, and it was our shared server's main model for two weeks. Deleted in September. Unsloth.
- Size
- 42.6 GB
- Status
- Deleted 9 Sep 2026
- Scored runs
- 12
- Smallest Mac
- 64 GB estimate, 8K context
Results12 scored · 95% intervals
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| chainwalkqwen3-next-80b-ag | 50.0% | 9.5–90.5 | Passed 1/2 | llama.cppextraction | 2026-09-07 |
| groundingqwen3-next-80b | 88.8% | 82.1–93.2 | Passed 111/125 | llama.cppextraction | 2026-09-05 |
| groundingqwen3-next-80b-a3b-iq4xs | 88.8% | 82.1–93.2 | Passed 111/125 | llama.cppextraction | 2026-08-26 |
| groundingqwen3-next-80b-a3b-iq4xs-smoke92% coverage | 73.9% | 53.5–87.5 | Passed 17/23 | llama.cppextraction | 2026-08-26 |
| nullschemaqwen3-next-80b | 97.2% | 90.4–99.2 | Passed 70/72 | llama.cppextraction | 2026-09-05 |
| nullschemaqwen3-next-80b-a3b-iq4xs | 97.2% | 90.4–99.2 | Passed 70/72 | llama.cppextraction | 2026-08-26 |
| screeningqwen3-next-80b | 91.7% | 81.9–96.4 | Passed 55/60 | llama.cppextraction | 2026-09-05 |
| screeningqwen3-next-80b-a3b-iq4xs | 91.7% | 81.9–96.4 | Passed 55/60 | llama.cppextraction | 2026-08-26 |
| taggerqwen3-next-80b-tag | 93.3% | 89.4–95.9 | Passed 224/240 | llama.cppextraction | 2026-08-31 |
| tagger_nullableqwen3-next-80b-tag | 90.4% | 86.0–93.5 | Passed 217/240 | llama.cppextraction | 2026-08-31 |
| toolsqwen3-next-80b-ag | 93.3% | 70.2–98.8 | Passed 14/15 | llama.cppextraction | 2026-09-07 |
| toolscaleqwen3-next-80b-ag | 95.0% | 83.5–98.6 | Passed 38/40 | llama.cppextraction | 2026-09-07 |
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.
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-IQ4_XS.gguf |
| Format | GGUF IQ4_XS, 42,644,478,752 B |
| Where from | downloaded twice from unsloth/Qwen3-Next-80B-A3B-Instruct-GGUF: ~2026-08-12 (deleted 08-14) and 2026-08-26 (deleted 2026-09-09) |
| Status | deleted 2026-09-09 ~14:28Z |
| Hugging Face | https://huggingface.co/unsloth/Qwen3-Next-80B-A3B-Instruct-GGUF |
Where it came from
- Repo / file:
unsloth/Qwen3-Next-80B-A3B-Instruct-GGUF→Qwen3-Next-80B-A3B-Instruct-IQ4_XS.gguf. The HF listing gave 42,644,478,752 B. The local file was byte-exact at 42,644,478,752 B (stat). 39.7 GiB. - Revision / sha256: not on record. The listing command printed the LFS oid into a scratch file, but the oid is not on record.
- First holding: ~2026-08-12 → deleted 2026-08-14. It predates the working sessions on record, so its download command is not known (a lab note: "made twice … 12 and 26 August";
fleet-models.iniREMOVED 2026-08-14 block). - Second holding: 2026-08-26 11:42Z → 12:12:58Z (BST 13:12:58). A six-part range download is reconstructed from "concatenate the six parts", into
models/qwen3-next-80b-a3b/. It was made after Alan's "Did we test Qwen3-Next-80B-A3B". - GGUF metadata:
general.finetune: Instruct, Apache 2.0. Tokenizer warning on load: "control-looking token: 128247 '</s>' was not control-type". - Why this quant: "
Q4_K_Mis 48.5 GB and exceeds the ~48 GB default Metal working set. IQ4_XS chosen for KV headroom" (a lab note).
How it was served
| label | dates (UTC) | binary | ctx / -np / KV / load / --jinja | profile | why this label exists |
|---|---|---|---|---|---|
qwen3-next-80b-a3b-iq4xs-smoke | 2026-08-26 ~12:31–12:52Z | llama.cpp/build/bin/llama-server, b10618 eb25b7263 | from a one-off script, itself derived from the GLM runner. Flags in that file are not fully on record; 32k ctx, -np 1, --jinja per the sibling scripts | extraction, --limit 25 | 25-case grounding smoke: "does it load at all", then the speed gate |
qwen3-next-80b-a3b-iq4xs | 2026-08-26 12:55–12:58Z | same | -ngl 99 -c 32768 -np 1 -cb --load-mode none --jinja, f16 KV | extraction | the first full gauntlet: grounding/screening/nullschema, then Toolery and AgentDojo |
qwen3-next-80b | 2026-08-27 00:42–00:45Z and 2026-09-05 12:01–12:04Z | launchd com.freshcontext.llama-server → llama.cpp/build/bin/llama-server --models-preset fleet-models.ini --models-max 1 --context-shift, b10618 | preset c = 262144, np = 1, load-mode = none, global jinja = true (as in the file committed 2026-10-09; the August global section is not separately on record). f16 KV on 08-27; cache-type-k/v = q8_0 on 09-05 | extraction | 08-27: confirm the 08-26 baselines on the router build ("Instruct suites reproduce exactly"). 09-05: measure q8_0 KV |
qwen3-next-80b-tag | 2026-08-31 17:46–17:59Z | llama.cpp/build/bin/llama-server, b10618 | --ctx-size 16384 --n-gpu-layers 99 --jinja, default -np, default (mmap) load | extraction | tagger / tagger_nullable against gemma4-12b and qwen3.6-35b "with identical flags" |
qwen3-next-80b-ag | 2026-09-07 18:00–18:13Z | same, b10618 | --ctx-size 32768 --n-gpu-layers 99 --jinja, default -np, default load; gate required a real tool_calls | extraction | first agentic suites (tools/toolscale/chainwalk) on any current model |
Run-log llama_build reads "0.2.0-dev (build 10618, commit eb25b7263)" on every row, consistent with llama.cpp before its 2026-09-10 pull to c32d1dabe (reflog). No stale build stamp.
Seats held:
- The router, the only model loaded on startup: 2026-08-26 ~20:00Z → 2026-09-09 14:27Z (preset commented). Alan: "I only want qwen next on the router for now". With
--models-max 1any other request evicted it. On 08-27 dsh silently fell back to qwen3.8-27b and evicted it. - Workstation daily driver through dsh/opencode from 2026-08-26.
- Hermes on the M4 Mac mini: Alan set up his own profile pointing at the router. A 23,305-token Hermes prompt with 88 tools was served cold in 71.5 s and warm turns in 1.7 s.
Decisions
- Downloaded (twice), the second time without checking the lab's notes.
- Kept and seated on the router, and unblocked in
model-fitness. - KV quantised 2026-09-05 on Alan's "Go for it".
- Held on 2026-09-08 when the first MLX copy went, because the full model holds two seats and "REAP has only been tested on one of them".
- Deleted 2026-09-09 ~14:28Z on Alan's "the guff models can be removed for qwen3 next and 3.8 as we have mlx now". The
RESTORE-deleted-20260909.shjustification is not supported by the run log (family Decision log). - Not published to HF. It is a third-party quant.
What went wrong
- Repeat download without consulting the lab's notes (2026-08-26). This was the second 40 GB pull of the same file. The assistant had first answered "never downloaded, never benched".
- Silent load death (2026-08-26 ~12:13Z). 767 bytes of log and no error. GLM's Metal buffers had not been released when the lock was. Fixed by waiting on memory, not just the lock.
- mmap deadlock (2026-08-26 12:32–12:52Z), in
ggml_metal_rsets_init_block_invoke: 0.1% CPU, 0 MB/s disk. Fixed with--load-mode none. - Smoke row is an errored run. Two smoke files exist.
grounding__qwen3-next-80b-a3b-iq4xs-smoke__extraction.jsonl.superseded(mtime 12:32:09Z) has 25/25 measured, 19 passed, and 37 s total elapsed: the clean smoke, which is not in the run log. The live file (mtime 12:52:46Z) has 23/25 measured, 2ERRORand 1,267 s elapsed. It coincides with the kill of the hung server at 12:52Z. The run log carries the live one (73.9%). Reconstructed: which process wrote the 12:52Z file is not on record. - Two KV configurations under one label. The 08-27 (f16) and 09-05 (q8_0) runs share label
qwen3-next-80bandconfiguration_id(f34a40087b318cc6for grounding). The assistant flagged it at the time: "Identicalconfiguration_idfor materially different server configs". The scores happen to be case-for-case identical, so no number is wrong. The run log cannot tell the two apart, though. A first attempt with--model-id qwen3-next-80b-q8kvmeasured 0/0 because the router did not know the id. It was killed and is not in the run log. - Duplicate chainwalk row.
chainwalk qwen3-next-80b-ag 2026-09-07T20:19:37is the same run as…T19:12:53. It was re-scanned aftertouchto back-fill the new depth field. manifest.json counts 4 runs for this label; there were 3. - launchd KeepAlive respawn during the ladder (2026-08-26 20:08Z). The router reloaded the 42.6 GB model underneath the ladder and swap grew to 47 GB. The numbers were discarded and re-run after
launchctlstop. On 2026-09-08, loading on startup pinned 43 GB wired again and blocked other benches. Fixed withmodels/router-control.sh. - opencode "failed to parse grammar" (HTTP 400). An MCP tool schema with string
maxLengthwould not compile to GBNF. That is llama.cpp, not the model. - Deletion rationale misattributed (2026-09-09): see the family Decision log.
What happened to it
Downloaded ~2026-08-12 → Spumco battery 08-13 → deleted 08-14 (101 GB together with the Q6_K, no RESTORE entry) → re-downloaded 2026-08-26 → benched 08-26 to 09-07 → router seat 08-26 to 09-09 → deleted 2026-09-09 (RESTORE-deleted-20260909.sh lists qwen3-next-80b-a3b (GGUF, IQ4_XS) 40 GB, but its command leaves the repo as <repo>). Re-downloadable from unsloth/Qwen3-Next-80B-A3B-Instruct-GGUF. The [qwen3-next-80b] preset is still in fleet-models.ini, commented.