TokenTinkerer/Cyber-Tiel-Coder-35B-A3B-MTP-TTQ-GGUF

Cyber-Tiel-Coder-35B-A3B-MTP — TTQ quant set

TTQ (TokenTinkerer Quant) is a ten-rung GGUF ladder built from peculiar-ragdoll/Cyber-Tiel-Coder-35B-A3B-GGUF-MTP, from 3.34 bpw to 6.64 bpw. Every rung is tensor-for-tensor the same shape as our published Qwen3.6-35B-A3B TTQ ladder — the same ten ftypes in the same places on 733 body tensors — with the model's grafted MTP head carried at the precision upstream ships it. Every claim below is a measurement, not an estimate.

⚠️ This is a quant of an abliterated (uncensored) model. It inherits CyberTiel's behaviour and its usage warnings: it will not refuse, and with tool access it can do real harm. Read the base model card before running it, and sandbox it at the OS level.

Source caveat — there is no full-precision release of this model. The ladder is built from upstream's highest rung, UD-Q8_K_XL (~8.6 bpw), which is therefore both the requantization source for every file here and the reference against which all KLD figures are measured. Two consequences: every quality number is relative to that file rather than to true full precision, and an unknown fraction of each divergence is inherited from it. Comparisons between files remain valid — they share one reference — and the same caveat applies to our Qwen TTQ ladder.

The point of the set is efficiency at a given size, and it holds against the author's own quant ladder. Interpolating their measured KLD curve in size and comparing at equal GiB, these rungs win on the code corpus at all seven matched sizes and on wikitext at six of seven — by 6–13% on code and up to 20% on prose. Three of the ten rungs sit below the upstream ladder's floor, and the top rung is 2.55 GiB smaller than their Q6_K_XL.

---

The ladder

KLD is KL divergence against the source's logits, measured over 40 fixed chunks of 512 tokens (lower is better; ± is the standard error over chunks). top-1 is same-top-token agreement. Two corpora, both fixed and identical for every row: code (70% code, 10% diff, 10% terminal, 10% config, from a frozen agentic eval split) and wikitext-2 test — the same prose protocol our Qwen TTQ ladder used. Rows in bold are this set; the others are the author's Unsloth-Dynamic tiers, measured by the same protocol on the same machine so the columns are directly comparable.

file	declared type	GiB	bpw	code KLD ±	code top-1	wiki KLD ±	wiki top-1
TTQ-3.34bpw-IQ3_XXS	IQ3_XXS (23)	13.82	3.34	0.135265 ± 0.006145	89.33%	0.121933 ± 0.002664	85.25%
TTQ-3.51bpw-IQ3_XS	IQ3_XS (22)	14.53	3.51	0.121448 ± 0.005077	90.22%	0.112744 ± 0.002547	85.84%
TTQ-3.67bpw-Q3_K_S	Q3_K_S (11)	15.20	3.67	0.107063 ± 0.004688	90.56%	0.091221 ± 0.002044	87.28%
UD-Q3_K_XL	—	16.05	~3.5	0.107430 ± 0.005629	91.09%	0.090358 ± 0.002192	87.19%
TTQ-3.92bpw-Q3_K_M	Q3_K_M (12)	16.22	3.92	0.091761 ± 0.004791	91.51%	0.073367 ± 0.001828	88.62%
UD-IQ4_XS	—	16.88	~4.0	0.095291 ± 0.004836	91.38%	0.077731 ± 0.001830	88.09%
TTQ-4.17bpw-IQ4_XS	IQ4_XS (30)	17.26	4.17	0.078644 ± 0.003888	91.86%	0.069188 ± 0.001705	89.17%
TTQ-4.49bpw-IQ4_NL	IQ4_NL (25)	18.56	4.49	0.066057 ± 0.004271	92.82%	0.045736 ± 0.001274	91.06%
TTQ-4.87bpw-Q4_K_M	Q4_K_M (15)	20.12	4.87	0.060243 ± 0.004486	93.53%	0.038743 ± 0.001042	91.41%
UD-Q4_K_XL	—	21.19	~4.7	0.051905 ± 0.003829	93.64%	0.035064 ± 0.001049	92.04%
TTQ-5.54bpw-Q5_K_S	Q5_K_S (16)	22.90	5.54	0.043374 ± 0.002857	94.37%	0.031178 ± 0.000901	92.77%
TTQ-6.00bpw-Q5_K_M	Q5_K_M (17)	24.81	6.00	0.039146 ± 0.003595	95.10%	0.023410 ± 0.000729	93.44%
UD-Q5_K_XL	—	25.13	~5.5	0.043198 ± 0.004229	95.00%	0.022749 ± 0.000627	93.75%
TTQ-6.64bpw-Q6_K	Q6_K (18)	27.47	6.64	0.036423 ± 0.003411	95.17%	0.020246 ± 0.000713	94.14%
UD-Q6_K_XL	—	30.02	~6.6	0.034978 ± 0.003757	95.36%	0.020072 ± 0.000794	94.20%

Full filenames are Cyber-Tiel-Coder-35B-A3B-MTP-TTQ-<bpw>bpw-<type>.gguf. Total 190.9 GiB.

Read that table by size, not by row order. Seven pairs are close enough to compare directly, and the pattern is consistent: at equal size, this set is cleaner than the author's tier at all seven on code and six on prose. The one exception is 5.54 on wikitext (+7.3%), where their Q5_K_XL is 0.6 GiB larger and still ahead; on code the same pair goes the other way by 9.5%.

At each size where both ladders exist, this set's KLD is lower: 7 of 7 on code (mean −9.3%) and 6 of 7 on prose. Bars run left from their file's value. Their curve is interpolated log-linearly between the five published tiers, so this is equal GiB, not equal row count — and their smallest tier is 16.05 GiB, below which three of these rungs sit.

The same two curves read the other way: for a given KLD this ladder needs 0.9 to 2.13 GiB fewer weight bytes. When serving, that headroom is expert-cache slots or extra context rather than a smaller download.

Two things genuinely not measured here: speed (no tg/pp column — the box these were built on has no GPU worth benchmarking on) and task benchmarks (see below; they are queued, not skipped).

How to read the names

Two independent fields, and they mean different things:

• <bpw>bpw is the true measured rate of the finished file, computed from its byte count.
• The trailing token is the file's declared general.file_type, chosen to understate the true rate and to be distinct across the whole set — the same ten tokens, in the same order, as the Qwen TTQ ladder. If two files in one repository declare the same general.file_type, the Hub's download selector collapses them and one becomes effectively invisible.

One wrinkle specific to this repo: the MTP head adds a flat 0.36 GiB to every rung, so the whole-file bpw reads slightly below the body's true rate. The body bpw is the number that matches the ftype token: e.g. TTQ-5.54bpw-Q5_K_S is 5.55 bpw as a file and 5.59 bpw across the body, which is exactly where the Qwen ladder's 5.59 rung sits.

---

Which rung should I use?

if you want	use	why
a small file that still codes	3.92 bpw Q3_K_M (16.22 GiB)	12.5% cleaner than the author's Q3_K_XL on code and 16% on prose, at 0.2 GiB more
the best quality per byte	4.49 bpw IQ4_NL (18.56 GiB)	the steepest drop in the ladder — 0.066 → 0.046 code KLD for 1.3 GiB, and 20% ahead of upstream at that size
the best balance	4.87 bpw Q4_K_M (20.12 GiB)	93.5% top-1 on code, within 0.2% of upstream's Q4_K_XL KLD at 1.1 GiB smaller
the fastest-feeling small rung	3.67 bpw Q3_K_S (15.20 GiB)	linear K-quant, no codebook tables — the codebook rungs (IQ3_*) are the slow ones on CPU
near-ceiling, smallest	6.00 bpw Q5_K_M (24.81 GiB)	95.1% top-1; 6.64 costs 2.7 GiB for a gap under 1σ on code
maximum quality here	6.64 bpw Q6_K (27.47 GiB)	best on both corpora, still 2.55 GiB under upstream's top rung
maximum quality, no cost limit	UD-Q8_K_XL from the base repo	the reference this ladder is measured against

The non-obvious trap: 5.54 is a prose weak point. It is the only rung on either corpus that loses to upstream at matched size, and the loss is 7% — worth knowing if you intend to use it for writing rather than code.

---

Serving

Stock llama.cpp

llama-server -m Cyber-Tiel-Coder-35B-A3B-MTP-TTQ-4.87bpw-Q4_K_M.gguf \
  -ngl 99 --jinja --ctx-size 65536 --spec-type draft-mtp --spec-draft-n-max 2

• --spec-type draft-mtp is what makes the MTP head do anything. Without it the head is dead weight — ~0.4 GiB you paid for and are not using.
• --spec-draft-n-max N is how many tokens the head drafts ahead — keep it at 2–3. The default is 3; aliases are --draft-max, --draft-n and --draft. Deeper is not better: a sweep of 1→4 on our sibling ladder dropped acceptance monotonically (89% → 82% → 74% → 68%), because each extra token is verified against the target and the later ones are mostly rejected. 2 was the pick there, 3 is a fine default; above 3 it is a net loss.
• --n-cpu-moe N is the VRAM dial, and its direction is counter-intuitive: it counts the layers whose experts stay on the CPU. 40 puts every expert on the CPU — what an 8 GB card needs, with -ngl 99 keeping the attention path on the GPU. 16 leaves 24 layers' experts on the GPU, which is the base model's recommendation for 24 GB cards. Lower N means more VRAM, not less — start high on a small card and walk it down until it fits. Measured on an 8 GB card for our sibling ladder: 36 ran ~20% faster than 40, and 34 bought another ~5% for ~800 MiB of VRAM — keep 0.5-1 GiB free, because WDDM does not fail cleanly, it collapses prefill.
• Never pass --n-cpu-moe 41. The MTP head is block 40, so 40 is the ceiling; 41 pulls the drafter off the GPU.
• The vision projector is not in this repo. Take mmproj-BF16.gguf from the base repo to use images.

Sampling

Use the presets the base model publishes, which are its own agentic-coding recommendations:

when	settings
Agentic coding (the default)	--temp 0.6 --top-p 0.95 --top-k 20 --min-p 0
Cybersecurity / CTF	same, but --top-k 40 --min-p 0.05 — looser, more divergent thinking; tested on Q4 and may cause non-convergence on lower quants

The base card also recommends leaving the reasoning budget and output limit unrestricted (--reasoning-budget -1 --predict -1); if you must cap them, --predict 32768 --reasoning-budget 16384 with --reasoning-budget-message "Proceed to final answer".

All KLD, PPL and top-1 figures here are sampler-independent — deterministic passes, not generations.

---

How these were made

• Requantized from upstream's UD-Q8_K_XL using the buun-llama-cpp fork, with the Tiel-Coder importance matrix supplied for this build — not an imatrix computed on CyberTiel. That matrix covers the 510 body weights that need one and none of blk.40, token_embd or output.
• The shape is copied, not re-derived. The ten published Qwen TTQ rungs were read straight from their GGUF headers and replayed onto this model by exact tensor name (733 body tensor names are identical between the two models). 432 anchored per-tensor overrides per rung — anchored because the quantizer matches with std::regex_search first-match-wins, and an unanchored output.weight would also capture blk.40.attn_output.weight.
• What that shape is: experts carry the rung's mixture per tensor; attention is Q6_K up to 4.87 then Q8_0; SSM/linear-attention Q6_K up to 4.17 then Q8_0; the shared expert Q8_0 at the bottom, Q6_K in the middle, Q8_0 above; token_embd+output Q6_K to 4.17 then Q8_0; norms, router and ssm_a/ssm_dt stay F32.
• The MTP head is untouched. All 20 blk.40 tensors are byte-identical to upstream in every rung — ffn_{gate,up,down}_exps at Q3_K, attention / shared-expert / nextn.eh_proj at Q8_0, the rest F32 — pinned by explicit overrides so no rung's mixture can reach them. Requantizing the head to Q4_K_M was considered and rejected: a Q3_K source cannot become a Q4_K_M one, and it would add ~0.1 GiB per rung for nothing.
• Chat template: inherited from the source, unchanged — the froggeric template (qwen3.8-froggeric-v22.5.0, 30,517 characters). No serving-side template is baked in.

Measurement protocol

Same harness for every row, on the same 8 GB VRAM / 32 GB RAM box.

• KLD / top-1 / PPL: divergence against a stored reference produced by the source file itself, 40 fixed chunks of 512 tokens, KV pinned to f16, a single greedy deterministic pass. ± is the standard error over chunks.
• KV pinned to f16 deliberately — the KV controller otherwise picks the cache format from free VRAM, which injects KLD from placement alone (measured at 0.0147 in a previous project before it was caught).
• Null test: the source against its own reference logits returns Mean KLD −0.000000 ± 0.000000, same-top-p 100.000%. The pipeline contributes nothing; every number above is quantization.
• The MTP block is inert in this measurement — the harness ignores blk.40 — so these numbers describe the body the assistant actually reads, not the drafter.
• The code corpus is 70% code / 10% diff / 10% terminal / 10% config taken from a frozen agentic evaluation split, with ChatML scaffolding and <think> blocks stripped; it is interleaved in 7:1:1:1 blocks so the 20,480 measured tokens carry the mix rather than being 100% code.
• The prose corpus is wikitext-2 test, 40 × 512 — the same protocol as the Qwen TTQ ladder, which makes these the one set of numbers directly comparable across the two repos.

---

Benchmark spot-checks

Measured with greedy sampling, on the same harness and benchmark set as the Qwen TTQ ladder's spot-checks. Like that card, every row is measured on the Q3_K_M rung — here 3.92bpw, 16.22 GiB. More rows will be filled in as runs finish; the repo gets a new commit, not a new model, and every TTQ card is updated together when a result lands.

3.92 Q3_K_M (16.22 GiB)	benchmark	Qwen TTQ 3.93 (15.85 GiB)	Groot 4.70 IQ4_NL (10.39 GiB)	reference: base model (full precision)	notes
98.2	HumanEval, 164 problems	97.0	98.2	no published figure for this model	pass@1, greedy — 161/164, ±1.0 SE
88	GPQA Diamond, 198 q	84.8	86	full-precision base 89.2 (temp 1.0)	accuracy, answer-match, greedy — ±2.3 SE
pending	MMLU-Redux, 5,330 q	92.6	pending	—	accuracy, answer-match, greedy
86.5	LiveCodeBench v6	79.9	pending	no published figure for this model	pass@1, greedy
pending	IFEval	93.05	pending	—	prompt-level accuracy (strict/loose), greedy

The Qwen TTQ 3.93 and Groot 4.70 IQ4_NL columns are context, not controls. Both are different models at a comparable ladder position, measured by the same harness on the same packs. They answer "does this rung land where a rung of this family should?", not "what did quantization cost" — there is no size- or quality-matched pairing here. Sizes are in the headers: 16.22 GiB here, 15.85 for Qwen, 10.39 for Groot.

GPQA Diamond 88 is the strongest row here, and the one that has somewhere to land. The full-precision base — Ornith-1.5-35B-A3B — publishes 89.2, so a 16.22 GiB Q3_K_M quant is 1.2 points under its own full-precision model. Two caveats keep that from being a like-for-like comparison:

• ±2.3 points of binomial noise. At n=198 and p≈0.88 the standard error is ±2.3, so the 1.2-point gap is about 0.4σ — indistinguishable, not "matching".
• Different sampling, and the difference favours the base. Their figure is temperature 1.0 over five passes; ours is one greedy pass. Five draws aggregated — pass@5 by construction, and a majority vote in practice — beat a single greedy pass, because the extra draws can recover from one bad sample. Greedy is therefore the stricter protocol here, not the flattering one: on a like-for-like basis the 1.2-point gap is more likely to shrink than to grow. It stays unquantifiable only because the base publishes no greedy figure.

Read it as no measurable collapse at 3.92 bpw on graduate-level science, not as parity with full precision.

LiveCodeBench v6 at 86.5 is the code number that actually resolves something. HumanEval sits at 98.2, close enough to ceiling that it can only say "not broken"; LiveCodeBench is unsaturated, so 86.5 is a real measurement of competitive-programming ability on a 16.22 GiB Q3_K_M file — 6.6 points above where our Qwen ladder's Q3_K_M rung lands on the same pack (79.9, a different fine-tune, so context rather than a control).

HumanEval 98.2 is an absolute result, not a comparison. No CyberTiel figure is published for it, and the right baseline would be the same benchmark on the full-precision source — that arm has not been run. What it establishes: 161 of 164 Python problems solved, so the rung is not visibly damaged on short function-completion tasks.

The one comparable number is our Qwen TTQ 3.93 rung — same ladder position, same pack, same harness — which scored 97.0. That is a different fine-tune, so the 1.2-point gap is a model difference and must not be read as a quantization effect; it is here only to show that the small Q3_K_M rung sits where a Q3_K_M rung normally sits.

One provenance item still open: whether this ran the plain humaneval-164 pack or the stricter humaneval-plus-164. The two score differently, so the row says only "164 problems" until that is confirmed.

What will make the rest readable: GPQA cannot resolve much — at n=198 and p ≈ 0.85 the binomial standard error is ±2.5 points, so only a large collapse would show. MMLU-Redux can (5,330 questions, ±0.35 points). LiveCodeBench is the harder code signal — HumanEval is close to saturation at 98.2, so it cannot rank rungs. The KLD table above remains the sharper instrument for quantization damage than any of these task benchmarks.

---

Limits and things that did not work

Recorded because negative results are results.

• This is a requantization of a quant. The Q8_K_XL source is ~8.6 bpw, so every rung inherits its noise, while the upstream tiers come straight from BF16 with a CyberTiel-specific imatrix. The matched-size win above stands despite that handicap — but a rebuild from BF16 would likely be better still.
• The imatrix is not model-specific. It is Tiel-Coder's, not one computed on CyberTiel. A CyberTiel-weighted matrix is the obvious next lever and is untested.
• 5.54 loses on prose (+7.3% vs upstream at matched size) while winning on code. Not every rung wins everywhere.
• 6.64 is not worth it over 6.00 on code. 0.039146 vs 0.036423 is a 0.0027 gap against ±0.0036 and ±0.0034 — under 1σ, for 2.7 GiB. On prose the ordering is real (0.0234 → 0.0202, 2.3σ).
• PPL is useless for ranking these files. Code PPL sits in 3.40–3.52 across all ten rungs including the 3.34; wikitext PPL moves only 7.25 → 6.97 while KLD moves 6×. Perplexity cannot see what KLD sees on high-probability (code) text.
• No speed numbers. The build box has no GPU release can use, so any tg/pp column here would be a number about the CPU, not about the files.

---

Credits and licence

Base model, importance matrix and grafted MTP head: peculiar-ragdoll. Ladder shape, quantization and measurements: TokenTinkerer. Licence inherited from the base: MIT. The abliteration that the base model carries is inherited here too — see the warning at the top.