MLX 4-bit

mlx-community's 4-bit MLX copy. No version of mlx_lm we had could load it; deleted the next day. Mlx-community.

Size: 18.8 GB
Status: Deleted 8 Sep 2026
Scored runs: 0
Smallest Mac: 32 GB estimate, 8K context

ResultsNever scored

This file never completed a scored run. Its record below says why.

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	`laguna-xs2-mlx-q4/` (safetensors dir)
Format	MLX 4-bit, 18,822,157,707 B (HF API sum)
Where from	downloaded 2026-09-07 from `mlx-community/Laguna-XS.2-4bit`
Status	deleted 2026-09-08 07:46Z
Hugging Face	https://huggingface.co/mlx-community/Laguna-XS.2-4bit

Where it came from

Repo / file: mlx-community/Laguna-XS.2-4bit (whole repo), hf download mlx-community/Laguna-XS.2-4bit --local-dir laguna-xs2-mlx-q4 in the overnight downloader.
Size: 18,822,157,707 B summed from the HF API (17.5 GiB). Local stat not on record; du 18G. sha256 not on record.
Date: 2026-09-07, landed before 23:54Z (the chain reached it at 00:54 local).
Contents: the repo ships configuration_laguna.py and modeling_laguna.py custom code beside the safetensors.
Who asked: Alan's "laguna-xs.2 is another worth looking at?". The assistant picked this build.

How it was served

label	dates (UTC)	binary and version	ctx / -np / KV / -fa / --jinja / --reasoning-format	profile	why this label exists
`laguna-xs2-mlx-q4`	2026-09-07 23:54Z → 2026-09-08 05:39Z (killed 05:54Z)	`mlx-venv` mlx_lm 0.31.3 `-m mlx_lm server --model <dir>`	mlx_lm defaults; n/a	extraction	the overnight chain's `bench_mlx` (screening → grounding → nullschema); `--model-id` was the directory path, which became the label

A second attempt on mlx-main-venv mlx_lm 0.32.0 (7fb4be44) at ~05:55Z failed the new readiness probe and left no run-log row. Never seated. Run-log runtime mlx_lm 0.31.3, runtime_source "note", which matches the script.

Decisions

Downloaded as the MLX route to a fast sparse coder.
Deleted 2026-09-08 07:46Z. The assistant: "genuinely dead weight; it cannot load in any mlx-lm version because the router is quantised wrong". Alan: "Delete laguna, what else is potential for killing off"; rm -rf models/laguna-xs2-mlx-q4.
Not published (a third-party conversion that does not load).

What went wrong

Wrong runtime pinned. bench_mlx used mlx_lm 0.31.3 for comparability, but laguna exists only in 0.32.0. It cost about six hours of the overnight chain, and blocked Muse-Glimmer and the DFlash test behind it.
Readiness probe passed a dead server. /v1/models returned 200. Fixed with a generation-based probe (HTTP 200 does not mean a model is loaded). The first version of that guard itself crashed Muse-Glimmer's nullschema run.
Unloadable checkpoint. The MoE router was quantised into a nested Linear (mlp.gate.proj.*), which mlx_lm's MoEGate cannot load. There was no newer mlx_lm commit to try.
Local path as label. raw_model was published as laguna-xs2-mlx-q4 until the 2026-10-21 fix.
Mis-attributed in the RESTORE record. RESTORE-deleted-20261011-tiersAB.sh attributes this row to the GGUF ("Benched: screening (1 row, partial)"). Flagged on 2026-10-11 but still in the script.

What happened to it

Downloaded 2026-09-07 → failed on mlx_lm 0.31.3 and 0.32.0, 2026-09-08 → deleted 2026-09-08 07:46Z. No RESTORE-deleted-*.sh entry (not in RESTORE-deleted-20260908.sh). An empty models--mlx-community--Laguna-XS.2-4bit stub (4 KB) remained in the HF cache on 2026-10-11. Re-downloadable from mlx-community/Laguna-XS.2-4bit. It would not load on the mlx_lm of 2026-09-08.