Qwen3.6-35B-A3B runs at Qwen3.5 speed on RTX 4070; +43% frontend gain reported

Same speed, different story

A hands-on comparison published on dev.to pits Qwen3.6-35B-A3B against its predecessor Qwen3.5-35B-A3B on a consumer GPU and finds no meaningful change in generation speed — paired with model card numbers that point to a large capability jump in agentic and frontend coding work instead.

According to the post, both models ran on a single RTX 4070 with 12 GB of VRAM, using llama.cpp with -ngl 99 --cpu-moe to offload mixture-of-experts layers to the CPU, GGUF quantizations from the lmstudio-community mirror, and llama-bench's tg128 metric for measurement. Averaged over three runs each, Qwen3.6 generated at 38.76 ± 0.82 tokens per second and Qwen3.5 at 36.7 ± 1.4, putting both inside roughly a 1.5 tok/s band.

The regression that wasn't

The author's first measurement told a very different story: 12 tok/s for Qwen3.6 against a 34.6 tok/s baseline for Qwen3.5, which looked like a severe slowdown. The culprit turned out to be another process holding 9–11 GB of VRAM, forcing layers that were supposed to live on the GPU to spill into system RAM. The tell was that a sanity-check run of Qwen3.5 slowed down too — when two independent models degrade together, the model itself is not the variable. After the offending process was killed and the test repeated, the speeds converged.

Where the gains actually are

If throughput did not move, the interesting numbers come from the benchmark table on the Qwen3.6-35B-A3B model card, as quoted in the post:

Benchmark	Qwen3.5	Qwen3.6	Lift
Terminal-Bench 2.0	40.5	51.5	+27%
QwenWebBench (frontend generation)	978	1,397	+43%
SWE-bench Pro	44.6	49.5	+11%
LiveCodeBench v6	74.6	80.4	+8%
SWE-bench Verified	70.0	73.4	+5%
AIME26	91.0	92.7	+2%
GPQA	84.2	86.0	+2%

The pattern, as the author frames it, is that every benchmark rewarding tool use, long-context reasoning and multi-turn execution moves by double digits, while single-question knowledge probes barely budge. The post attributes the AIME26 and GPQA plateau to saturation: at 91 and 84 points respectively there is little headroom left in those formats. Terminal-Bench 2.0 and QwenWebBench, by contrast, score long-horizon behavior — recovering from a shell error, wiring CSS classes to the right components, finishing a task rather than stopping at a plan — and that is where a real capability gap still has room to appear.

A sanity check that separated nothing

To test the claims on local hardware, the author ran a personal seven-question standard set against both models. Both scored 7/7, and in a side-by-side comparison Qwen3.5 was often the more thorough respondent, for example on a capital-cities question and a WebRTC explanation. The set is saturated in the same way AIME is: when both models answer everything correctly, run-to-run sampling noise swallows any generational gap. Tasks where both models can still fail — long agent traces, unfamiliar repositories, frontend layouts built to a spec — are where Qwen3.6's advantages would show up.

Practical read for local runners

Two takeaways from the post:

• Do not upgrade for the tokens. On the same 12 GB VRAM budget with the same MoE-offload configuration, tokens per second are unchanged, so a throughput bottleneck gains nothing.
• Do upgrade if you are about to hand the model a repository. The +43% on frontend generation and +27% on Terminal-Bench are the numbers that matter for coding-agent, IDE-plugin and CLI-agent workloads.

The post also notes the model shipped on 2026-04-15 under Apache 2.0, with the same architecture, the same 3B activated parameters out of 35B total, and the same MoE routing pattern as Qwen3.5.

Why it matters

Taken together, the results reframe Qwen3.6 as a capability release rather than a speed release: the hardware footprint local users care about is unchanged, while the model's improvements are concentrated in agent behavior — tool-call stability, long context and thinking control. If your workload is one-shot question answering, the post suggests you will not see the gap; if it is reading a repo and landing a PR, you will. There are caveats worth holding onto: this is a single author on a single GPU, the headline figures come from Qwen's own model card, and QwenWebBench is the vendor's own frontend benchmark. But the methodological lesson generalizes to anyone benchmarking local models — a number that is dramatically convenient for your narrative deserves a second measurement, and background processes eating VRAM are a quiet way to manufacture a fake regression.