Qwen3.8-27B GSQ-RCO IQ3_S · file← Qwen3.8-27B GSQ-RCO IQ3_S
Qwen3.8-27B GSQ-RCO IQ3_S with MTP head
The only file we held: ISTA-DASLab's 3-bit build, with the model's draft head kept in. Five tests and some speed runs, then deleted in October. ISTA-DASLab GGUF.
- Size
- 12.1 GB
- Status
- Deleted 11 Oct 2026
- Scored runs
- 5
- Smallest Mac
- 24 GB estimate, 8K context
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| nullschemaqwen38-gsqrco-iq3s | 62.5% | 51.0–72.8 | Passed 45/72 | llama.cppextraction | 2026-09-10 |
| synthesisqwen38-gsqrco-iq3s | 83.3% | 72.0–90.7 | Passed 50/60 | llama.cppextraction | 2026-09-10 |
| toolcallqwen38-gsqrco-iq3s | 100.0% | 94.0–100.0 | Passed 60/60 | llama.cppextraction | 2026-09-10 |
| toolscaleqwen38-gsqrco-iq3s | 100.0% | 91.2–100.0 | Passed 40/40 | llama.cppextraction | 2026-09-10 |
| worldviewqwen38-gsqrco-iq3s | 77.5% | 62.5–87.7 | Passed 31/40 | llama.cppextraction | 2026-09-10 |
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-GSQ-RCO-IQ3_S-mtp.gguf |
| Format | IQ3_S (GSQ-RCO) with embedded MTP head, 12,120,016,960 B |
| Where from | downloaded 2026-09-10 from ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF |
| Status | deleted 2026-10-11 (Tier B sweep) |
| Hugging Face | https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF |
Where it came from
- Repo / file:
ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF,Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf, URLhttps://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF/resolve/main/.... - Local path:
models/qwen38-gsq-rco/Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf. - Size: 12,120,016,960 B (the Content-Length printed as 11.29 GiB). A local
dulisting shows 12.12 GB on 2026-09-12, the same file. - sha256: not on record. The script checked nothing after concatenating the ranges.
- Revision: not pinned.
- How: 6 parallel
curl -sL -r <start>-<end>range requests intopart.0..part.5, joined withcat part.* >..., started 2026-09-10 07:50:37Z. - Who asked: Alan; the assistant picked the file.
- The file is the vendor's, not made here. A byte-for-byte size match with the HF file is evidence only because the download came from that repo.
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
qwen38-gsqrco-iq3s | 2026-09-10; suites finished 08:54:32Z (toolcall) to 09:23:53Z (synthesis); run-log ts 09:54:32 to 10:23:53 BST | llama.cpp/build/bin/llama-server, b10618 (eb25b7263) | -c 131072 -np 1 -fa on -ctk q8_0 -ctv q8_0 -ngl 999 --jinja --reasoning-format deepseek, --alias qwen38-gsqrco | extraction (temperature 0, thinking off, 2048 max tokens), --no-resume; suites toolcall, toolscale, worldview, nullschema, synthesis | the only benchmark label: the lossless-or-not test against the Q4_K_M build, Alan's request |
Script: a one-off script generated by sed from the Spark benchmark script, itself made from the Bonsai one; it waits for earlier jobs (while pgrep -f "ab_qwen.sh|bench_bonsai.sh|bench_spark.sh|runner.py --suite"), starts the server with the flags above, runs a speed probe, then harness/runner.py --suite <s> --model <server> --model-id qwen38-gsqrco --label <label> --profile extraction --no-resume for the five suites. The server flags are those of the Bonsai script, which sed only renamed.
Other servings of this file that left no run-log label:
| use | date (UTC) | binary | flags |
|---|---|---|---|
| speculation test, MTP versus a 4B draft model | 2026-09-11 14:50Z | llama.cpp/build/bin/llama-server (version not stamped in the script) | -c 16384 -np 1 -fa on -ctk q8_0 -ctv q8_0 -ngl 99, --spec-type draft-mtp |
| MTP tuning (n-max, p-min) and the clean same-file comparison | 2026-09-11 15:00Z | same | --spec-draft-n-max {2,3}, --spec-draft-p-min 0.7; clean run --spec-type none against draft-mtp --spec-draft-n-max 3 --spec-draft-p-min 0.7 |
| acceptance sweep | 2026-09-11 20:08Z | .local/bin/llama-cli | --spec-type draft-mtp --spec-draft-n-max {2,3,5} -c 4096 -ngl 99 -n 160 --temp 0 |
| speed against a uniform Q4_0 | 2026-09-13 20:03Z | build c32d1dabe (10893) | -p 512 -n 128 -r 3, three seats stopped first |
Seats held: none.
Decisions
- Downloaded on Alan's request; the
-mtpfile was the assistant's choice. - Kept after the benchmark only as an MTP/drafter source: Alan's "keep any q4_0 and drafters" and the sweep script's
keepline. - Not seated. The nullschema loss and the codebook speed penalty (27% slower than Q4_0) left Q4_0 as the better build of the same weights.
- Deleted 2026-10-11 in the Tier B sweep (see Lifecycle).
What went wrong
- Wrong label on the first results. The
sedchainbonsai-27b-ternaryto spark-x25-4b-ternary to qwen38-gsqrco-ternary made the harness write*gsqrco-ternary*files, which would have read as a ternary quant. Eight files (toolcall, toolscale, worldview and the just-started nullschema, each a JSONL file and a manifest) were renamed at 09:14Z; the assistant said the running job would keep writing the old label and that it would rename nullschema and synthesis afterwards. That is consistent with the result files now carryingiq3sand no manifest containing the old label (grep, 2026-10-23); the second rename itself is not shown in the lines read (reconstructed). The run log was backfilled later (backfilled: true), so the label that the run log shows is the corrected one. - Stale build stamp (standing check). All five run-log entries carry
llama_build"0.4.0-dev (build 10893, commit c32d1dabe)" butruntime_versionb10618 (eb25b7263) (runtime_source: evidence). The runs finished 08:54Z to 09:23Z on 2026-09-10; the upgrade to c32d1dabe started at 12:17Z and the binary was rebuilt at 13:17 BST. The evidence-derived b10618 is right; thellama_buildstamp is a mis-stamp. - Lossless claim withdrawn the same morning. The assistant first reported "genuinely lossless on your work" after worldview, toolcall and toolscale matched case-for-case, then nullschema returned 62.5. It cost nothing beyond the retraction.
- "The fork supports draft-mtp" is a misnomer. The assistant wrote that "the fork" supports MTP, but the speculation scripts call
llama.cpp/build/bin/llama-server, the upstream binary. No fork was involved. - Missing flags:
--jinjaand--reasoning-format deepseekpresent for the benchmark runs. The speculation servers had neither (not on the line); they were speed probes, not scored. - Partial runs: none (row counts above).
What happened to it
Downloaded 2026-09-10 07:50Z → benched 08:54Z–09:23Z (b10618) → MTP tests 2026-09-11 → llama-bench against Q4_0 2026-09-13 (b10893) → never seated → deleted 2026-10-11 (qwen38-gsq-rco, 11 GB, Tier B; models/qwen38-gsq-rco no longer exists, 2026-10-23) → RESTORE-deleted-20261011-tiersAB.sh has an entry for qwen38-gsq-rco that is only a comment, with no hf download line (the neighbouring entries for muse-glimmer and glm-4.7-flash have one) → re-downloadable from ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF, file Qwen3.8-27B-GSQ-RCO-IQ3_S-mtp.gguf (revision never pinned). The run-log results survive.