Qwen3.8-27B · file← Qwen3.8-27B
MLX 4-bit affine g64
An MLX copy of unknown origin, for our first MLX tests. Deleted. Local folder, provenance unknown.
- Size
- 15.0 GB
- Status
- Deleted 9 Sep 2026
- Scored runs
- 4
- Smallest Mac
- 32 GB estimate, 8K context
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| contractqwen3.8-27b-mlx-4bit | 75.0% | 61.2–85.1 | Passed 36/48 | rapid-mlxextraction | 2026-09-08 |
| groundingqwen3.8-27b-mlx-4bitunenforced | 92.0% | 85.9–95.6 | Passed 115/125 | mlx_lmextraction | 2026-09-07 |
| screeningqwen3.8-27b-mlx-4bit | 93.3% | 84.1–97.4 | Passed 56/60 | rapid-mlxextraction | 2026-09-08 |
| toolcallqwen3.8-27b-mlx-4bit | 100.0% | 94.0–100.0 | Passed 60/60 | rapid-mlxextraction | 2026-09-09 |
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.
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-27b-mlx-4bit/ |
| Format | MLX affine 4-bit g64, about 15 GB |
| Where from | unknown (present by 2026-08-14) |
| Status | deleted 2026-09-09 |
| Hugging Face | unknown |
How it was made
- What is on record: a folder
models/qwen3.8-27b-mlx-4bitof three safetensors shards, 15 GB bydu, configquantization = {group_size 64, bits 4, mode affine},model_type qwen3_5,tie_word_embeddings False. It was already in the August inventory and the router preset comment dated 2026-08-14 says the weights were already on disk and measured 15.2 / 14.9 / 14.5 tok/s with no speculation (fleet-models.ini comment).
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
qwen3.8-27b-mlx-4bit (grounding) | 2026-09-07 19:48 | mlx_lm server 0.31.3 (lora venv) | defaults; model id sent as the folder path (mlx_lm resolves the field as an identifier) | extraction | the stack question: same model, same 125 cases, GGUF 80.0 against MLX |
qwen3.8-27b-mlx-4bit (contract, screening) | 2026-09-08 21:15, 21:21 | rapid-mlx 0.13.4 | rapid-mlx serve <folder> --no-spec-decode | extraction | the pair bench for the 'can rapid-mlx beat the 41 tok/s recipe' push; contract 36/48, screening 56/60 |
qwen3.8-27b-mlx-4bit (toolcall) | 2026-09-08 23:00 | rapid-mlx 0.13.4 | rapid-mlx serve <folder> --gc-control | extraction | the new frozen toolcall/1 suite, run on the folder because it was the Qwen3.8 weights on hand |
Unlabelled servings: rapid-mlx serve under --served-model-name qwen3.8-27b with --tool-call-parser qwen3_xml (2026-09-09 06:54Z; the right parser, qwen3_coder_xml, was found at 07:15Z). Seats held: the endpoint registered for opencode and pi at Alan's request on the night of 2026-09-08 ("can you register 3.8 and 3.6 just now?") and opened to the tailnet for his phone on 2026-09-09 06:51Z, until the curated build replaced it at 07:26Z.
Decisions
- Tested because Alan wanted MLX quants explored: "Sure, I'm interested in exploring qwen3.8 mlx quants too, folk are running it on really small cards am sure there's a way we can get good speeds out of it", and on 2026-09-08 "running qwen3.8 27b in rapid mlx to see if we get a decent speed bump"; then "Any other tricks we can employ to squeeze more tps from dense 27b".
- Superseded on 2026-09-09 by the curated
rapid-mlx/Qwen3.8-27B-4bit-MTP-MLXbuild (Qwen3.8-27B MLX 4-bit with MTP sidecar (rapid-mlx curated build; served as qwen3.8-27b-mtp-medium)), because the folder's template had noreasoning_effortand no parser registry applied to it. - Deleted 2026-09-09 about 14:08Z under Alan's "ok remove the granite extras and the superseded models"; the assistant checked the router for references first.
- Not published; the rows sit under the
qwen3.8-27b-mlx-4bitlabel.
What went wrong
- Model-id contract. The first MLX grounding run recorded 0 measured of 125: mlx_lm treated the request's
modelfield as a HuggingFace identifier, tried to download it, and 404'd. The harness caught it as 0/0 coverage, not a score. - Harness patched in place. The runner put the folder path into the results filename and broke; the assistant sanitised the tag in the runner during the session. The harness is locked against in-place edits without a version bump; the change and any version bump are not on record here.
- Constrained arms not applied. mlx_lm silently ignores
response_format(mlx_lm silently ignores response_format, 2026-09-08), so 16 of 25 constrained responses violated the schema. The 92.0% is therefore not the same experiment as the GGUF's 80.0%; the Runtime changes HOW a model phrases a refusal, and nullschema scores that as fabrication (2026-09-11) shows the same weights decline with different phrasing under the two runtimes. - Parser mis-set by hand.
qwen3_xmlinstead ofqwen3_coder_xmlmeant the overnight run put deliberation intocontentand stopped after one clean turn. - Build stamps: rapid-mlx 0.13.4 matches the evidence; the grounding row's runtime comes from a note, not a command.
What happened to it
Present by 2026-08-14 → grounding 2026-09-07 → rapid-mlx rows 2026-09-08 → the seat endpoint → deleted 2026-09-09 about 14:08Z. No RESTORE-deleted-*.sh entry for it (the 20260909 script covers the GGUF only). Not re-downloadable as the same bytes (origin unknown); the curated build below is the replacement.