clm-0013
communityhigh ●●●
citable URL: https://halobench.com/records/clm-0013/ — this address never moves; the anchor /records/#clm-0013 keeps resolving
Qwen3.6-35B-A3B — our chosen reflex model — is published in FastFlowLM's .q4nx NPU format (23.2 GB, plus a 1.0 GB vision encoder), making a genuinely capable MoE, not a 1-2B classifier, runnable on the XDNA2 NPU.
verified 2026-08-05 · volatility medium
Note — the record's own working
FastFlowLM/Qwen3.6-35B-A3B-NPU2, created 2026-07-08, ~2,000 downloads.
WHY A 35B IS SUDDENLY PLAUSIBLE ON AN NPU: decode bandwidth is proportional to ACTIVE parameters, not total. At A3B the model reads roughly 2 GB per token at 4-bit, where a dense 35B would read ~20 GB. Low-active-parameter MoE is the ideal shape for a bandwidth-poor accelerator — which is exactly why the NPU catalogue was previously 1-8B dense models.
WHAT IT CHANGES: the second-lane argument in npu-fastflowlm-2026-08-02 assumed the NPU could host a small classifier. If it can host our actual reflex model, the sentinel tier in clm-0008 could be a capable council member rather than a change-detector. It also ships a vision encoder, which could relieve the Mac mini.
⚑ CORRECTED 2026-08-05 with measured Strix Halo data (Framework Desktop, gfx1151, LMDE 7 / xanmod 7.1.3). I had framed the NPU as "slower at decode but wins prefill, so the value is concurrency". **On a 35B, the NPU loses BOTH phases decisively.**
| ctx | NPU decode | NPU prefill | NPU TTFT | |-----|-----------|-------------|----------| | 1k | 12.11 t/s | 90.7 t/s | 10.8 s | | 8k | 10.94 | 209.9 | 36.9 s | | 32k | 8.11 | 245.2 | **126.3 s** |
Same box, same model at a HIGHER quant (Q8_0, 35.21 GiB) on the iGPU: **pp4096 709-840 t/s on ROCm, 964-1039 on Vulkan; tg128 43 t/s ROCm, 53 t/s Vulkan.**
So the iGPU is roughly **4x faster at decode AND 4-6x faster at prefill**, while running a heavier quantisation. My earlier "NPU wins prefill 2.3x" came from an ~8-9B dense comparison; that advantage does not survive at 35B on this silicon.
And TTFT of **126 seconds at 32k** rules the NPU out of anything interactive or escalation-shaped outright.
WHAT SURVIVES: the NPU lane is only defensible as genuinely CONCURRENT background work where latency is irrelevant — Phase A/D in model-phases.md — and even then it costs the iGPU about 14% of its own decode. The "capable second council member" framing is much weaker than it looked an hour ago: a member that answers in two minutes is not a peer.
ALSO STILL TRUE: mutually exclusive with amd_iommu=off (+5-12%), and aibeast's NPU logged SMU init errors on the 21 July wedged boot, so NPU health is unverified.
Cited by — computed at build time, never stored
model pages qwen36-35b