Qwen3-Next-80B-A3B-Instruct · file← Qwen3-Next-80B-A3B-Instruct
MLX 4-bit
The same model in Apple's MLX format, to compare runtimes. Downloaded twice, deleted twice. Mlx-community.
- Size
- 44.8 GB
- Status
- Deleted 5 Oct 2026
- Scored runs
- 3
- Smallest Mac
- 96 GB estimate, 8K context
Results3 scored · 95% intervals
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| groundingqwen3-next-80b-mlx-4bitunenforced | 87.2% | 80.2–92.0 | Passed 109/125 | mlx_lmextraction | 2026-09-07 |
| nullschemaqwen3-next-80b-mlx-4bitunenforced | 95.8% | 88.5–98.6 | Passed 69/72 | mlx_lmextraction | 2026-09-07 |
| screeningqwen3-next-80b-mlx-4bit | 96.7% | 88.6–99.1 | Passed 58/60 | mlx_lmextraction | 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-mlx-4bit/ (9 safetensors) |
| Format | MLX affine 4-bit g64, 44,844,286,500 B (HF sum) |
| Where from | downloaded twice from mlx-community/Qwen3-Next-80B-A3B-Instruct-4bit: 2026-09-07 (deleted 09-08) and 2026-09-11 (deleted 2026-10-05) |
| Status | deleted 2026-10-05 10:06Z |
| Hugging Face | https://huggingface.co/mlx-community/Qwen3-Next-80B-A3B-Instruct-4bit |
Where it came from
- Repo:
mlx-community/Qwen3-Next-80B-A3B-Instruct-4bit. 9 safetensors, affine 4-bit, group 64. 44,844,286,500 B summed from HF; the repo has been unchanged since 2025-09-12, so both pulls were current main. Revision and sha256 are not on record. - First holding: downloaded 2026-09-07 19:47Z → 20:32Z with
huggingface_hub.snapshot_downloadfromlora/.venv/bin/pythonintomodels/qwen3-next-80b-mlx-4bit. The completeness check passed ("42G (9 safetensors)"). It was made after Alan's "Is there a qwen 3 next mlx?". Deleted 2026-09-08 16:18Z. - Second holding: re-downloaded 2026-09-11 19:35Z by range requests over the HF file list, into the same path. Complete by 20:31Z: 9 shards, config, index and tokenizer present.
config.jsonchecked on 2026-09-12. Deleted 2026-10-05 10:06Z. - Not made here, and not REAP. It is the unpruned 80B. On 2026-09-10 Alan said "we made our own 4bit from the guff". Before that, the assistant had accepted that "Both are REAP — the 4bit one just wasn't named for it". The download command above contradicts both claims (Incidents).
How it was served
| label | dates (UTC) | runtime | flags | profile | why this label exists |
|---|---|---|---|---|---|
qwen3-next-80b-mlx-4bit (results files use the path id qwen3-next-80b-mlx-4bit) | 2026-09-07 20:49–20:55Z | mlx_lm server from lora/.venv. Version 0.31.3 per the run log (runtime_source: note); not printed at the time | --model <dir>; no schema enforcement exists in mlx_lm | extraction, --model-id = the directory path | same model, different stack: "does the same model score the same through a different stack?" |
| — (no label; runtime bench) | 2026-09-12 08:48Z | mlx-venv: mlx 0.32.2, mlx_lm 0.31.3 (stamped in output) | three ~60-token workloads | — | Alan: "I definitely want to test the 80b guff vs mlx" |
No seat was held.
Decisions
- Downloaded for runtime parity. The 2026-09-07 result was read as "Your GGUF baselines hold". The grounding and nullschema half of that conclusion fell the next morning (mlx_lm silently ignores response_format).
- First copy deleted 2026-09-08 on Alan's "we can lose the next 80b guff and the mlx right?". The assistant: "The MLX one yes". Its grounding/nullschema were unenforced.
- Re-downloaded 2026-09-11 "so we get both formats of the full model". On 2026-09-12 the assistant judged that "the 44.8 GB MLX copy has no case" and offered deletion. It was not deleted then.
- Second copy deleted 2026-10-05 with the Q4_0, to stage the Kolibri quantisation. Alan approved.
- Not published.
What went wrong
- Misattributed to REAP, which inverted a finding (2026-09-10). Reconstructing REAP history, the assistant first read this file's 95.8% nullschema as the full 80B (correct). After Alan's "I thought we'd done reap and it held but the mixed precision one dropped" and "yeah we did this and the mixed failed the 4bit won", it switched to "Both are REAP". It then wrote "REAP-60B mlx-4bit 69/72 95.8% uniform ← prune is free". That framing seeded the first version of Badly-chosen mixed precision costs abstention; sensitivity-aware mixing protects it (uniform vs mixed36 on the "same prune"). It was revised on 2026-09-11 for a different reason: mixed36 was mostly 3-bit. The revision does not record that the 95.8% comparator was the unpruned model. The download record is unambiguous.
- Prefill artefact (2026-09-12): reported as a 16× MLX hole, then withdrawn after Alan's challenge.
- Mislabelled at deletion: the 10-05 deletion question called this "MLX copy of the same model" as an "IQ4_XS" re-pull. That was harmless to this file, but it shows the stale-runbook problem (family doc).
What happened to it
Downloaded 2026-09-07 → benched 09-07 (3 suites; 2 of them unconstrained) → deleted 09-08 → re-downloaded 2026-09-11 → runtime bench 09-12 → deleted 2026-10-05 10:06Z (no RESTORE entry; a later working session says "the MLX re-pull script is kept", path not given). Re-downloadable from mlx-community/Qwen3-Next-80B-A3B-Instruct-4bit.