Second public release from Crucible. Same model, same 8.78 GB, measurably closer to the unquantized weights than v1.

48% of the routed experts pruned with REAP, then quantized with a measured per-tensor bit allocation instead of a hand-written one. Against v1, at the identical file size:

Both files are 8.78 GiB. On everything measured — every divergence metric, prefill and decode throughput, and all three benchmarks — v2 is better than v1 or equal to it.

One caveat worth stating plainly: v2 uses i-quants (IQ3_S, IQ4_XS) where v1 used only k-quants. Measured on Metal and ROCm, those are faster here, for a structural reason explained below. They have not been timed on CUDA, Vulkan, or CPU-only builds, and i-quant kernel performance does vary by backend. If you are on an untested backend and throughput matters more than fidelity, benchmark before switching.

Three things, in order of how much they contributed.

1. Calibration now carries the chat template. v1's importance matrix was computed on conversations flattened to plain text — every <|im_start|>, role marker and thinking tag discarded. An imatrix measures activation statistics, so v1 measured them on text the model never actually receives. v2 renders calibration through the model's own chat template.

2. Bits are reallocated by measurement. v1 held attention and embeddings at Q8_0 and left the shared expert at Q3_K. Measured per-role KL-divergence says that is backwards: the shared expert is ~53× more sensitive per parameter than the routed experts, while attn_q is among the least sensitive attention tensors. v2 moves that budget accordingly.

3. Per-layer allocation. v1 used one type per tensor role across all 40 layers. v2 varies by layer using imatrix energy within each role.

Two of those findings contradict the obvious approach. Raw imatrix energy is not comparable across tensor roles — it clusters by position relative to the nearest RMSNorm, not by importance, so ssm_out measures as the least important tensor in the model while measured KL-divergence ranks it first. And weight scale does not rescue the comparison: σ_W spans only 2.4× across these tensors where energy spans 3,317×.

attn_v and attn_k sit at Q8_0 in v2: they are the most sensitive tensors per parameter in the whole model and, at 10.5M parameters each, nearly free to protect.

Both files measured on the same machine, same llama-bench invocation (-p 512 -n 128 -ngl 999 -fa 1 -r 3), same llama.cpp build:

v2 is faster despite using i-quants, and the reason is structural. Decode is bandwidth-bound and reads the dense path on every token while touching only 8 of 133 experts. v1 held attention, embeddings and the output projection at Q8_0 — 1.774 GiB re-read every token. v2 moves that budget down to Q6_K/Q4_K and spends it on the expert stacks, which are read sparsely. Fewer bytes per token on the hot path, more precision where the measurement says it matters.

Own-harness, temperature=0, one attempt per problem, generated code executed in a rootless-podman sandbox. Measured on gfx1151 / ROCm.

These are absolute figures for v2. They are deliberately not presented against v1: those were measured on different hardware and with a harness that has since had two scoring bugs fixed, so any delta would be an artefact as much as a result. The v1-vs-v2 quality claim rests on the KL-divergence table above — same machine, same corpus, same f16 reference, same day.

The z-lab DFlash drafter works against this pruned model. It is a dense 8-layer draft model (no experts), 0.328 GB at Q6_K, and its dimensional contract matches exactly (num_target_layers: 40, target_layer_ids: [1,10,19,28,37], hidden_size: 2048).

A 48% expert prune does not break it. Code-token draft acceptance measured 80.5% against this model — effectively the same as the unpruned base model's MTP acceptance (79%). The shared expert carries ~69% of layer output norm, so the residual stream stays close to base even with half the routed experts removed.

Do not raise n-max past 3. Prose regresses at 4 and loses 22% at 8 — acceptance falls faster than the extra drafted tokens pay for it.

Acceptance is identical to the ROCm run (80.7% on code), so this is not a quality problem — the drafter predicts this model just as well on both machines. Closing the books on one speculation round at n=2 shows where it goes:

On the 8060S the drafter costs a third of a forward pass; on the M4 it costs almost a whole one, which cancels the gain. Verification cost contributes too — a 4-row forward is 2.20x a 1-row forward on M4 versus 1.53x on the 8060S — but the drafter overhead is the larger term. Forcing the drafter fully onto Metal (-ngld 999) changes nothing, so this is not a placement issue.

Treat DFlash as a discrete-GPU feature. On Apple silicon, run the model without it.

-b and -ub must match. On quantized Qwen3.5/3.6 hybrids, splitting a batch across ubatches corrupts the GatedDeltaNet state — llama.cpp's default -b 2048 -ub 512 measures PPL 1402 where matched flags give 2.72. The model still generates coherent text when this happens, so it is easy to miss.

-ctk bf16 -ctv bf16 is not optional. The f16 KV default accumulates error on this architecture and corrupts tool-call output over long agent contexts.

Non-thinking / agent: --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0 --presence-penalty 1.5. Thinking: --temp 1.0 --top-p 0.95. Code: --temp 0.6 --top-p 0.95.

-b and -ub must match. On quantized Qwen3.5/3.6 hybrids, splitting a batch across ubatches corrupts the GatedDeltaNet state. llama.cpp's default -b 2048 -ub 512 measured PPL 1402.95 where matched flags gave 2.72 on identical input — while the model still generates coherent text, so it is easy to miss. f16 is unaffected. Reported upstream.

On a 16 GB Mac, watch the logits buffer, not just the weights. At this model's 248,320 vocab, -ub 2048 allocates 2048 x 248320 x 4B = 2.03 GiB of compute buffer. Weights (8.78 GiB) plus that buffer plus a draft model overflows the M4's 12 GiB Metal working set and OOMs. Use -b 512 -ub 512 there — it costs a little prefill and reclaims 1.5 GiB.

REAP-pruned checkpoints declare an MTP head they do not have. Convert with --no-mtp, or convert_hf_to_gguf.py writes 41 blocks of metadata over 40 blocks of tensors and the result loads nowhere.

Prose is more sensitive to speculation than code. Draft acceptance on prose is roughly half that of code at every setting, which is why n-max above 3 turns into a regression.

--no-mtp is required: REAP drops the multi-token-prediction head but the config still declares it, and current convert_hf_to_gguf.py would otherwise write 41 blocks of metadata over 40 blocks of tensors, producing a GGUF nothing can load.

Apache-2.0, inherited from Qwen3.6-35B-A3B.