The 27B model is dense. Releasing a dense model first would be terrible marketing, whereas 35A3B is a lot smarter and more quick-witted by comparison!

▲

arxell 2 days ago | parent | next [-]

Each has it's pros and cons. Dense models of equivalent total size obviously do run slower if all else is equal, however, the fact is that 35A3B is absolutely not 'a lot smarter'... in fact, if you set aside the slower inference rates, Qwen3.5 27B is arguably more intelligent and reliable. I use both regularly on a Strix Halo system... the Just see the comparison table here: https://huggingface.co/unsloth/Qwen3.6-35B-A3B-GGUF . The problem that you have to acknowledge if running locally (especially for coding tasks) is that your primary bottleneck quickly becomes prompt processing (NOT token generation) and here the differences between dense and MOE are variable and usually negligible.

▲

nunodonato 2 days ago | parent | next [-]

I was hoping this would be the model to replace our Qwen3.5-27B, but the difference is marginally small. Too risky, I'll pass and wait for the release of a dense version.

▲

Mikealcl 2 days ago | parent | prev [-]

Could you explain why prompt processing is the bottle neck please? I've seen this behavior but I don't understand why.

▲

zozbot234 2 days ago | parent [-]

You should be able to save a lot on prefill by stashing KV-cache shared prefixes (since KV-cache for plain transformers is an append-only structure) to near-line bulk storage and fetching them in as needed. Not sure why local AI engines don't do this already since it's a natural extension of session save/restore and what's usually called prompt caching.

▲

FuckButtons a day ago | parent [-]

if I understand you correctly, this is essentially what vllm does with their paged cache, if I’ve misunderstood I apologize.

	▲	zozbot234 a day ago \| parent [-]
		Paged Attention is more of a low-level building block, aimed initially at avoiding duplication of shared KV-cache prefixes in large-batch inference. But you're right that it's quite related. The llama.cpp folks are still thinking about it, per a recent discussion from that project: https://github.com/ggml-org/llama.cpp/discussions/21961

▲

JKCalhoun 2 days ago | parent | prev | next [-]

"…whereas 35A3B is a lot smarter…"

Must. Parse. Is this a 35 billion parameter model that needs only 3 billion parameters to be active? (Trying to keep up with this stuff.)

EDIT: A later comment seems to clarify:

"It's a MoE model and the A3B stands for 3 Billion active parameters…"

▲

halJordan 2 days ago | parent | prev | next [-]

That makes no sense. If you were just going to release the "more hype-able because it's quicker" model then why have a a poll.

▲

Miraste 2 days ago | parent | prev [-]

What? 35B-A3B is not nearly as smart as 27B.

▲

stratos123 2 days ago | parent | next [-]

One interesting thing about Qwen3 is that looking at the benchmarks, the 35B-A3B models seem to be only a bit worse than the dense 27B ones. This is very different from Gemma 4, where the 26B-A4B model is much worse on several benchmarks (e.g. Codeforces, HLE) than 31B.

▲

zozbot234 2 days ago | parent [-]

> This is very different from Gemma 4, where the 26B-A4B model is much worse on several benchmarks (e.g. Codeforces, HLE) than 31B.

Wouldn't you totally expect that, since 26A4B is lower on both total and active params? The more sensible comparison would pit Qwen 27B against Gemma 31B and Gemma 26A4B against Qwen 35A3B.

▲

Hugsun a day ago | parent [-]

They're comparing Qwen's moe vs dense (smaller difference) against Gemma's moe vs dense (bigger difference). Your proposed alternative misses the point.

	▲	zozbot234 21 hours ago \| parent [-]
		Gemma's dense is bigger than its moe's total parameters. You could totally expect the moe to do terribly by comparison.

▲

ekianjo 2 days ago | parent | prev | next [-]

yeah the 27B feels like something completely different. If you use it on long context tasks it performs WAY better than 35b-a3b

▲

Der_Einzige 2 days ago | parent [-]

I've been telling analysts/investors for a long time that dense architectures aren't "worse" than sparse MoEs and to continue to anticipate the see-saw of releases on those two sub-architectures. Glad to continuously be vindicated on this one.

For those who don't believe me. Go take a look at the logprobs of a MoE model and a dense model and let me know if you can notice anything. Researchers sure did.

▲

reissbaker a day ago | parent | next [-]

Dense is (much) worse in terms of training budget. At inference time, dense is somewhat more intelligent per bit of VRAM, but much slower, so for a given compute budget it's still usually worse in terms of intelligence-per-dollar even ignoring training cost. If you're willing to spend more you're typically better off training and running a larger sparse model rather than training and running a dense one.

Dense is nice for local model users because they only need to serve a single user and VRAM is expensive. For the people training and serving the models, though, dense is really tough to justify. You'll see small dense models released to capitalize on marketing hype from local model fans but that's about it. No one will ever train another big dense model: Llama 3.1 405B was the last of its kind.

	▲	Der_Einzige 19 hours ago \| parent [-]
		You want to take bets on this? I'm willing to bet 500USD that an open access dense model of at least 300B is released by some lab within 3 years.

▲

naasking a day ago | parent | prev [-]

MoE isn't inherently better, but I do think it's still an under explored space. When your sparse model can do 5 runs on the same prompt in the same time as a dense model takes to generate one, there opens up all sorts of interesting possibilities.

▲

zkmon 2 days ago | parent | prev [-]

Yes.