qwen3.6-35b-a3b-escha

Qwen3.6-35B-A3B-Escha-W2 — hipfire builds

EschaLabs' Escha-W2 2-bit trellis quantization of Qwen3.6-35B-A3B, packaged for hipfire on AMD RDNA3/RDNA4.

Dense sibling: qwen3.8-27b-escha.

The trellis codes are stored verbatim and decoded inside the GEMV — there is no decode-at-load step and no re-quantisation of the experts. All three builds below contain byte-identical expert weights; they differ only in how the dense tensors (embeddings, lm_head, attention, GatedDeltaNet) are stored.

All three also carry a partial multi-token-prediction head — 17 mtp.* tensors, 78.7 MB at F16, byte-identical across the builds. hipfire does not use it: upstream ships the head's router and shared expert but none of its 256 routed experts, so the MoE FFN cannot be built and speculative decode stays off. The tensors are inert weight you are carrying; the dense sibling's head is complete and is used.

Builds

The unsuffixed build is the default. Its dense tensors are MQ6: +17% decode over -pro for +0.10% perplexity, which is the best of the three trades.

-pro keeps the dense tensors at Q8_0, a bit-exact repack of Escha's own per-row int8 into hipfire's per-32-block form, replicating the row scale into every block. That costs 6.25% on those tensors and nothing on the experts, which is the whole of the 0.04 GB difference from the upstream checkpoint's 12.30 GB. It is the KLD reference; the 0.000000 is a negative control, not a rounding.

-xt is the fast/loose option and the only one with a quality cost you can see in the numbers: +4.9% PPL, roughly 7x the divergence of the default.

-xt/base/-pro describe the DENSE tensors only. All three builds carry byte-identical 2-bit trellis experts and a byte-identical (unused) F16 MTP head; they differ solely in how embeddings, lm_head, attention and GatedDeltaNet are stored. Do not read these as bit-widths.

Usage

hipfire run qwen3.6-35b-a3b.escha "What is the capital of France?"

Needs a hipfire build with escha support; the codes are decoded inside the GEMV, so there is no conversion step and no dequantised second copy in memory. The registry tags (qwen3.6:35b-a3b-escha, -pro, -xt) resolve once escha support reaches a release — until then, point it at the file.

Decode speed, and why it is what it is

Escha decodes the trellis inside the GEMV, so decode does arithmetic that a scale-and-multiply quant does not: 7 ops per weight. Removing that arithmetic entirely is 1.83x on the GEMV kernel — measured on the dense sibling's gate_proj, which runs the same kernel at different shapes, so treat it as the order of the effect rather than a figure for this model. It is also a kernel figure, not an end-to-end one: the escha GEMVs are roughly a third of a decode step, so the model-level headroom is a good deal smaller. In exchange the experts sit at 2 bits.

If tokens/sec matters more than bytes, a plain MQ quant of the same base model will decode faster at a larger file size. If VRAM or quality-per-byte is the constraint, this is the point of the format.

How these were measured

Everything above is measured, not estimated, on a single Strix Halo (gfx1151, Radeon 8060S, 128 GB unified) under ROCm 7.2.

• Speed: a 2k-token prompt then sustained greedy decode, at stock settings, each build warmed with a discarded run first and reported as the median of repeated runs. Expect ±3% run to run; a cold page cache costs considerably more on the first run after loading another model, and a single sample immediately after another model's run can be far worse than that.
• Resident is a measured GTT delta against an idle baseline (~3.4 GB), taken with an 8192-token q8 KV cache — it includes the KV, not just the weights, and a smaller KV lowers it by roughly 0.7 GB. Measure one build at a time: GTT is not released between processes, so back-to-back runs make the second and third look like they need 0.5 GB.
• PPL and KLD: teacher-forced on a fixed 384-token x 6-chunk slice of wikitext-2, --kv-mode f32, top-k 256. KLD is against the -pro build's own logits, so -pro is 0.000000 by construction. That self-control reproduces to six decimal places across repeated runs, which is what makes the other two numbers attributable to the dense format rather than to run-to-run noise.

PPL on a 6-chunk slice is a relative measure for comparing these three builds. Do not compare it to a perplexity computed on a different corpus, context length, or KV precision.

Provenance and licence

• Base model: Qwen/Qwen3.6-35B-A3B
• Quantization: EschaLabs/Qwen3.6-35B-A3B-Escha-W2 (quant_method: eschamoe, format 2.0). The W2 trellis codes here are EschaLabs' work, redistributed unmodified.
• Apache-2.0, following upstream.

The container is hipfire's .hfq under an .escha extension. The -xt / -pro variant suffix names the dense recipe, which is the only thing that differs between the three.