I’ve been testing this model since yesterday through the Qwen API in opencode and deepseek harness. I actually prefer it over GLM-5.3-Flash! it’s super good at agentic coding and comfortably fast, now my goal is to be able to one day run it locally 😳 I think a Strix Halo with 128GB and a fast nvme should be able to run it well at near loseless quant
I heard an MoE was coming but its a bummer to see it so large. 64gb ram and 32vram, but I’m stuck with a shitbag Intel card that needs mirrored vram to ram so I can’t have enough of this offloaded. Hopefully the supposed stealth model announced today is the qwen4 MoE in the 35b range :/
I’m pretty excited about this one, is it supported by llama.cpp main yet?
Not on main yet I think (as of ~2:50PM UTC on 2026-08-26) – there’s a link to the PR for it in my other comment though. Unsloth’s fork has that integrated (they submitted the PR). I wouldn’t be surprised if something lands quickly in main, but this is a new architecture so may take a bit for people to figure out how to get the most out of it – bunch of discussion about e.g. SSD offloading for the ngrams and stuff like that in the github thread.
llama.cpp support for it got merged a few hours ago 🏆
Nice! Hopefully I can figure out how to actually get it to load tomorrow… (It keeps getting OOM-killed when I try.)
Number of Parameters: 125B with 6B activated, plus 51B n-gram embedding and 4B MTP
I bet you could run this in Q4 on 96GB RAM and 16GB VRAM, maybe even less. The benchmark scores seem good, beating 27b and DeepSeek Flash
The n-gram embeddings sound very similar to Gemma 4 e4b embeddings.
GGUFs are starting to be available now
I’ve gotten 35B-A3B running on a 4GB GPU with 16GB of RAM, the 6B actives should easily fit onto an 8GB card, but yeah, you might could get away with just 64GB of memory, maybe even just 32 if quantized small enough
the 6B actives should easily fit into an 8GB card
That’s not how MoE models work. There are many “expert’ models and there is a static router model (dense) which determines which “expert” models to route the tokens through. What you want at a minimum is the dense portion of the model to be on VRAM and all of the weights to be in RAM/VRAM for best performance.
I’m downloading the full weights currently. Will give it a try on my Framework Desktop when I can. I expect that I will need a newer version of llama.cpp given the new architecture – there are already pull requests pending though… (e.g. https://github.com/ggml-org/llama.cpp/pull/27742)
Wouldn’t the whole 125B non-n-gram parameters still have to fit into VRAM, though?
It’s MoE so you can use --n-cpu-moe
https://lemmus.org/post/24235317
Low number of active parameters (6B) means you don’t need much VRAM to get decent speeds
