Qwen3.8-Flash-Next · file← Qwen3.8-Flash-Next

AD-4.27bpw Q4_K_M M64

A more precise build, to see whether the bigger model was worth waiting for. It only ran with part of it on the CPU, slowly, and lost every test. Deleted. AtomicChat GGUF.

Size: 94.5 GB
Status: Deleted 9 Sep 2026
Scored runs: 4
Smallest Mac: Over 128 GB estimate, 8K context

Results4 scored · 95% intervals

Suite	Score	95% interval	Passed	Runtime · profile	Recorded
chainwalkflashnext-4.27bpw-m64	0.0%	0.0–65.8	Passed 0/2	llama.cppagentic-fast	2026-09-08
groundingflashnext-4.27bpw-m64	81.6%	73.9–87.4	Passed 102/125	llama.cppextraction	2026-09-08
nullschemaflashnext-4.27bpw-m64	58.3%	46.8–69.0	Passed 42/72	llama.cppextraction	2026-09-08
screeningflashnext-4.27bpw-m64	95.0%	86.3–98.3	Passed 57/60	llama.cppextraction	2026-09-08

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.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64/…-000{01..33}-of-00033.gguf` (33 shards)
Format	AD 4.27bpw, Q4_K_M-based mix, M64 layout; 94,525,394,976 B (HF listing)
Where from	downloaded 2026-09-08
Status	deleted 2026-09-09 ~14:28Z; `RESTORE-deleted-20260909.sh`
Hugging Face	https://huggingface.co/AtomicChat/Qwen3.8-Flash-Next-GGUF/tree/main/Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64

Where it came from

Repo / path: AtomicChat/Qwen3.8-Flash-Next-GGUF, folder Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64/, 33 shards; the n-gram shard is 36G.
Local path: models/qwen38-flash-next-m64/Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64/.
Size: 94,525,394,976 B (HF listing); du 88G, "90158 MB of 88000". Byte-verified: "ALL SHARDS MATCH", 33 on disk. sha256 not on record. Revision not pinned.
How: a one-off script, written 2026-09-08 14:20Z for the 3.84 build and rewritten in place at 14:45Z (s.replace("AD-3.84bpw-IQ4_XS-M64","AD-4.27bpw-Q4_K_M-M64")), then requeued behind the REAP download. It runs hf download AtomicChat/Qwen3.8-Flash-Next-GGUF --include "Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64/*" --local-dir qwen38-flash-next-m64 with HF_HUB_ENABLE_HF_TRANSFER=1 HF_HUB_DISABLE_XET=1 and three retries. Done by 17:39Z.
The script's trailing mmproj-Qwen3.8-Flash-Next-F16.gguf line did not leave an mmproj in the directory (no match on 2026-09-09).
Who asked: Alan, "nah let's go bleeding edge grab 3.8 flash next" and "are we grabbing another quant too?"; the switch to 4.27bpw followed Alan's queued "using the various ssd offloading tools available we could go bigger and not use that quant?" and the assistant's recommendation, before any bytes landed.

How it was served

label	dates (UTC)	binary and version	ctx / -np / KV / -fa / --jinja / --reasoning-format	harness profile	why this label exists
`flashnext-4.27bpw-m64` (quality run)	2026-09-08 18:16Z–18:59Z	`llama.cpp-next/build/bin/llama-server`, `0.4.0-dev (build 30, commit 6a1a922)`	`--jinja -c 16384 -b 512 --n-cpu-moe 24 -ngl 999 --alias flashnext`; `-np` not set (slot count not on record for this launch); KV default; `-fa` not set; no `--reasoning-format`	`extraction` (grounding, nullschema, screening); `agentic-fast` (chainwalk)	the only label for this build; grounding and chainwalk first because they had headroom
`flashnext-4.27bpw-m64` (contract/2)	2026-09-08 ~20:49Z–20:51Z	same binary	`--jinja -c 8192 -ngl 999 --n-cpu-moe 24 --alias flashnext`	`extraction`	third arm of a contract/2 head-to-head with REAP; measured nothing (503 × 48)

Both runs were launched by one-off scripts.

Before the quality run the build was tried at -ngl 999 without offload (loads at 52.5 GB, n_slots = 4, n_ctx_slot = 8192, then Compute error on every decode), --cpu-moe (44.1 GB) and --n-cpu-moe 24 (49.0 GB). An earlier queued run at 17:53 BST had tried the stock llama.cpp against incomplete shards and failed.

Seats held: none. Not in fleet-models.ini, fleetview or any launchd plist.

Run-log build stamp: 0.2.0-dev (build 10618, commit eb25b7263) on all five runs; the evidence shows llama.cpp-next @ 6a1a922.

Decisions

Downloaded to test frontier-on-SSD against resident models on suites with headroom.
Measured, not seated. "The 180B model loses on three of four, is catastrophic on abstention". Bar: REAP 87.2 / 97.2 / 98.3 / 50.0 on grounding / nullschema / screening / chainwalk.
Result audited on Alan's "what’s wrong with the bigger models, it doesn’t add up"; failures judged real.
No further levers worth pulling: 5.00bpw unlikely to move it; requantising or pruning needs the ~360 GB bf16 source.
Deleted 2026-09-09 ~14:28Z, after the restore note was written, on Alan's "let's get stable remove flash next for now but keep a note of its removal". Reason in RESTORE-deleted-20260909.sh: "it lost to REAP-60b on every suite where both were measured, at three times the disk and a fraction of the speed".
2026-10-07: still named as a deletion candidate in a disk-hold message. It had already been deleted on 2026-09-09; that message is stale.
Not published to HF (third-party file).

What went wrong

Benchmark fired before the download finished (17:53 BST): the queue waited on REAP_BENCH_DONE instead of the download, and it used the stock binary. No scores were recorded; fixed by requeueing on llama.cpp-next behind the download.
Metal Compute error at -ngl 999: llama.cpp hands Metal the whole mmap'd region of GPU-tensor shards; fixed with --n-cpu-moe 24.
Memory-guard false negative: the assistant's guard counted free + inactive (19.2 GB) and would have refused a load that succeeded, because 55.5 GB of file-backed pages were evictable.
Missing flags: -np was not set although the PR/AtomicChat notes call -np 1 mandatory; no crash occurred. The chainwalk contexts peaked at 783 and 1,476 tokens, under any plausible per-slot share of 16,384, so truncation is not the explanation for 0/2.
Mis-sized in the 2026-09-09 restore note: RESTORE-deleted-20260909.sh says "~43 GB in memory" for this build. 43.49 GB was the 3.84 build; this one measured 48.5–49.5 GB with --n-cpu-moe 24.
Partial runs: none.

What happened to it

Queued 2026-09-08 14:45Z → downloaded by 17:39Z (byte-verified) → failed premature bench 17:53 BST → load tests 17:56Z–18:09Z → quality run 18:16Z–18:59Z → contract/2 attempt (503) ~20:49Z–20:51Z → deleted 2026-09-09 ~14:28Z (88G) → RESTORE-deleted-20260909.sh (its restore line is an echo pointing at eval/tools/pardl.sh, not a runnable download) → re-downloadable from AtomicChat/Qwen3.8-Flash-Next-GGUF folder Qwen3.8-Flash-Next-AD-4.27bpw-Q4_K_M-M64. Needs llama.cpp with qwen4exp and, on 64 GB, --n-cpu-moe.