Qwen3.5-122B-A10B · file← Qwen3.5-122B-A10B
Qwen3.5-122B-A10B UD-IQ3_XXS
Unsloth's 3-bit build, the largest that left memory to spare on 64 GB. Three scored tests and a tool test, then deleted in September. Unsloth GGUF.
- Size
- 44.7 GB
- Status
- Deleted 7 Sep 2026
- Scored runs
- 3
- Smallest Mac
- 96 GB estimate, 8K context
| Suite | Score | 95% interval | Passed | Runtime · profile | Recorded |
|---|---|---|---|---|---|
| groundingqwen3.5-122b-a10b-iq3 | 80.8% | 73.0–86.7 | Passed 101/125 | llama.cppextraction | 2026-08-26 |
| nullschemaqwen3.5-122b-a10b-iq3 | 45.8% | 34.8–57.3 | Passed 33/72 | llama.cppextraction | 2026-08-26 |
| screeningqwen3.5-122b-a10b-iq3 | 88.3% | 77.8–94.2 | Passed 53/60 | llama.cppextraction | 2026-08-26 |
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.5-122B-A10B-UD-IQ3_XXS.gguf (one file) |
| Format | UD-IQ3_XXS (unsloth dynamic), 44,745,020,608 B |
| Where from | downloaded 2026-08-26 from unsloth/Qwen3.5-122B-A10B-GGUF |
| Status | deleted 2026-09-07 17:36Z; no RESTORE entry |
| Hugging Face | https://huggingface.co/unsloth/Qwen3.5-122B-A10B-GGUF |
Where it came from
- Repo / file:
unsloth/Qwen3.5-122B-A10B-GGUF,Qwen3.5-122B-A10B-UD-IQ3_XXS.gguf, one file. - Local path:
models/qwen3.5-122b-a10b/Qwen3.5-122B-A10B-UD-IQ3_XXS.gguf. - Size: 44,745,020,608 B in the HF blob listing; shown locally as 41.67G / 41.7 GB (GiB).
- sha256: not verified. The script compares the file to the listing's LFS oid only when one is present, and the listing line for this file carried no oid. Each of the six byte ranges was length-checked before concatenation.
- How: a one-off script, 6 parallel
curl -rrange requests with--speed-limit 51200 --speed-time 45 --retry 5, started 2026-08-26 09:31Z (10:31:36 local), ~230 Mbps. Complete by 10:46Z. - Revision: not pinned.
- Who asked: Alan, "Curious if there’s a bigger one out there that may work 70b with 10ba would be cool as fuck".
How it was served
| label | dates (UTC) | binary and version | ctx / -np / KV / -fa / --jinja / --reasoning-format | harness profile | why this label exists |
|---|---|---|---|---|---|
qwen3.5-122b-a10b-iq3 | 2026-08-26 10:03Z ready; suites to ~10:13Z; Toolery to ~11:02Z | llama.cpp/build/bin/llama-server, b10618 (eb25b7263) | -ngl 99 -c 32768 -np 4 -cb --jinja; KV default; -fa not set; no --reasoning-format | extraction (thinking off, max_tokens 2048) | the only label: grounding, screening, nullschema, then Toolery and (cut) AgentDojo |
Command: a one-off script, which waits for the download marker and a GPU lock file, starts the server, measures decode speed, gates on one valid tool call, then runs uv run --python 3.12 python -m harness.runner --suite {grounding,screening,nullschema} --model <server> --model-id qwen3.5-122b-a10b-iq3 --profile extraction --no-resume and uv run toolery run --model qwen3.5-122b-a10b-iq3 --adapter raw --tier all --trials 1 --base-url <server>/v1 --concurrency 4 --no-tui. The run log's runtime comes from this evidence (runtime_source "evidence").
-np 4 with -c 32768 gives 8,192 tokens per slot. The assistant's draft of the big-MoE report, which said "All models at 32,768 context, single slot", does not match this launch (see Incidents).
Seats held: none. It never had a fleet-models.ini preset ("no preset").
Decisions
- Downloaded as the closest fit to "70b with 10ba".
- Not seated: "Worse than a 7 GB model on every quality axis".
- AgentDojo cut after Toolery by a one-off script.
- Deleted 2026-09-07 17:36Z as "superseded by everything", after Alan's "Go for it" to a plan that did not list it for the first pass (see the family doc's decision log).
- Not published (third-party file).
What went wrong
- Slot count misreported. The run used
-np 4 -cb(8,192 tokens per slot) and Toolery ran at concurrency 4. The big-MoE report says "single slot". The published lab report says only "32,768 context", so it is not wrong. (reconstructed) The 53 Toolery timeouts were measured with four requests sharing one 21.7 tok/s decode, so they overstate a single-stream user's wait. - Wrong size and "cannot fit" claim, 2026-09-13. The assistant told Alan the model was "~52 GB at IQ3 against a ~48 GB ceiling, so it never fits even alone" and that it was deleted "presumably in the 231 GB cleanup". The record shows a 44,745,020,608 B file that loaded in 20 s and served the suites on this box, deleted in the 220.5 GB sweep of 2026-09-07. The same 52.0 GB figure appears in a 2026-09-13 coverage table. It did not change a decision: the scores argued against re-fetching anyway.
- Watcher kill spilled onto the next job. The watcher script also killed whatever was listening after releasing the lock, which killed GLM-4.7-Flash's freshly started server. The 122B's own results were complete by then.
- Deleted beyond the stated plan. The 122B was not in the "first pass" the assistant proposed immediately before Alan's "Go for it", but was in the delete command. The weights were re-creatable and the scores survive; no RESTORE entry was written.
- No sha256 check (see Provenance).
- Missing flags:
--jinjapresent; no reasoning format, by design (thinking disabled per request). - Partial runs: none.
- No RESTORE entry for the 2026-09-07 sweep (grep of
RESTORE-deleted-*.sh, 2026-10-23).
What happened to it
Downloaded 2026-08-26 09:31Z–~10:46Z → benched 10:03Z–~11:02Z (Toolery last, AgentDojo cut) → never seated → deleted 2026-09-07 17:36Z → no RESTORE entry → re-downloadable from unsloth/Qwen3.5-122B-A10B-GGUF, file Qwen3.5-122B-A10B-UD-IQ3_XXS.gguf (any HF client; a revision was never pinned, so a re-download may be a different upload).