---
license: apache-2.0
base_model: EschaLabs/Qwen3.6-35B-A3B-Escha-W2
base_model_relation: quantized
tags:
  - hipfire
  - hfq
  - escha
  - escha-w2
  - qwen3.6
  - moe
  - rocm
  - gfx1151
library_name: hipfire
---

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

[EschaLabs' Escha-W2](https://huggingface.co/EschaLabs/Qwen3.6-35B-A3B-Escha-W2)
2-bit trellis quantization of Qwen3.6-35B-A3B, packaged for
[hipfire](https://github.com/warpfront/hipfire) on AMD RDNA3/RDNA4.

Dense sibling: [`qwen3.8-27b-escha`](https://huggingface.co/hipfire-models/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

| file | size | resident | prefill | decode | PPL | KLD vs `-pro` |
|---|---|---|---|---|---|---|
| `qwen3.6-35b-a3b.escha-xt` | 11.39 GB | 12.78 GB | 1067 tok/s | 64 tok/s | 8.0643 | 0.058963 |
| **`qwen3.6-35b-a3b.escha`** | **11.84 GB** | **13.19 GB** | **848 tok/s** | **56 tok/s** | **7.6940** | **0.007907** |
| `qwen3.6-35b-a3b.escha-pro` | 12.34 GB | 13.70 GB | 830 tok/s | 48 tok/s | 7.6864 | 0.000000 |

**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

```bash
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](https://huggingface.co/Qwen/Qwen3.6-35B-A3B)
- Quantization: [EschaLabs/Qwen3.6-35B-A3B-Escha-W2](https://huggingface.co/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.