Qwen3.5-9B · file← Qwen3.5-9B
MLX mxfp4
MLX's mxfp4 4-bit format, made here for the format experiment. Converted here.
- Size
- not recorded
- Status
- Deleted 12 Sep 2026
- Scored runs
- 1
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| nullschemaqwen35-9b-mlx-mxfp4 | 34.7% | 24.8–46.2 | Passed 25/72 | rapid-mlxextraction | 2026-09-11 |
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 | _mlxfmt/qwen35-9b-mxfp4 |
| Format | MLX mxfp4, 4.251 bpw |
| Where from | made here 2026-09-11 |
| Status | deleted 2026-09-12 |
How it was made
- Input:
Qwen/Qwen3.5-9BBF16 safetensors, revisionc2022362(Qwen3.5-9B BF16 safetensors (Qwen, HF cache)). - Command (first success with full output):
.local/share/uv/tools/rapid-mlx/bin/python -m mlx_lm convert --hf-path Qwen/Qwen3.5-9B --mlx-path models/_mlxfmt/qwen35-9b-mxfp4 -q --q-bits 4 --q-mode mxfp4.mlx_lmversion: not on record (the venv is rapid-mlx's uv tool environment, python 3.12; rapid-mlx 0.13.4). - Result: "Quantized model with 4.251 bits per weight";
du -sh4.5 GiB (weights_map: 4.78 GB for the directory); exact weight-file bytes not recorded. - Date / who asked: 2026-09-11 15:26Z; the assistant, to test whether the GGUF symmetric-versus-asymmetric format finding carries to MLX. Alan's steer that afternoon: "sure and then I'd like to take a look at rapid, then draw conclusions on which models and runtimes for them I should plug into hermes".
- The first attempt (15:25Z) failed at save on every format because the HF snapshot was missing three metadata files; the output directory only appeared after they were fetched.
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
qwen35-9b-mlx-mxfp4 (run log) | 2026-09-11 15:39 (BST 16:39:53) | rapid-mlx 0.13.4: rapid-mlx serve <dir> --served-model-name m | MLX server, no ctx/-np/KV/-fa flags; no --jinja (llama.cpp-only) | extraction, --no-resume, nullschema only | symmetric-equivalent arm |
| (mlx_lm in-process, no label) | 2026-09-11 15:26-15:27 | mlx_lm generate | 200 tokens, best of 2 | n/a | throughput: 42.40 tok/s (mlx_lm) |
Seats held: none.
Decisions
- Made to test the format hypothesis stated before the numbers: "The prediction, stated before the numbers". Role in the experiment: symmetric-equivalent arm.
- Deleted 2026-09-12 07:45:56Z. Not published.
What went wrong
- Conversion looked failed but had quantised fine (missing snapshot files).
- The score is confounded by decline phrasing: MLX builds wrote empty strings where GGUF wrote "not mentioned", so the cross-runtime gap is mostly convention. Within MLX the comparison is fair.
- Floor effect: the assistant noted the 9B is a weak abstainer, so differences may be small in absolute terms.
- Standing checks: partial runs none (72/72); the manifest has no server block (
server: unavailable HTTPError,nullschema__qwen35-9b-mlx-*__extraction.manifest.json), so the run-log build is "evidence" not "props"; no llama.cpp flags apply.
What happened to it
Made 2026-09-11 15:26Z -> nullschema-scored same day -> deleted 2026-09-12 07:45:56Z. No RESTORE-deleted-*.sh entry exists for it. Re-creatable with the command above from Qwen/Qwen3.5-9B.