Qwen3.8 Flash Next VRAM: 180B Total, 6B Active
Qwen shipped the architecture that Qwen4 will be built on, and it breaks the way you are used to sizing a model.
The card says: 125B parameters with 6B activated, plus 51B of n-gram embedding and 4B of MTP. That adds to 180B, and Hugging Face's own readout of the weights puts the model at 180B parameters.
Three numbers, and only one of them behaves the way you expect. 6B active is 3.3% of the model per token, about as sparse as anything shipped. 51B of it is not a neural network at all. And the memory it needs at long context is smaller than a 27B dense model's.
It is also multimodal, with a vision encoder, so running it with images needs a separate projector file on top of everything below.
Below: what it needs at every quantization tier, what the 51B actually is in plain terms, and why the answer to "will it fit" now depends on software that does not exist yet.
What It Needs
Our calculator, llama.cpp, and these are totals including cache and overhead:
| Tier | 8K context | 32K context | 256K context |
|---|---|---|---|
| FP16 | 343.0 GiB | 343.6 GiB | 349.0 GiB |
| Q8_0 | 182.7 GiB | 183.3 GiB | 188.7 GiB |
| Q4_K_M | 104.7 GiB | 105.3 GiB | 110.6 GiB |
| Q3_K_M | 72.7 GiB | 73.2 GiB | 78.6 GiB |
| Q2_K | 57.2 GiB | 57.7 GiB | 63.1 GiB |
Qwen's own FP8 release is about 185 GB on disk, which is the anchor for that Q8 row.
Look along the rows rather than down them. Going from 8K to 256K context costs this model 5.9 GiB. The same trip on dense Qwen3.8 27B costs 15.8 GiB. A 180B model has a smaller cache at full context than a 27B does, and that is not a rounding artefact, it is the architecture.
The reason is in the layer layout: 48 layers arranged as twelve repeats of three Gated DeltaNet layers followed by one Qwen Sparse Attention layer. Only 12 of the 48 layers keep a cache that grows, and those carry just 2 KV heads. The other 36 hold a fixed-size recurrent state that costs the same at 256K as at 8K.
The 51B That Is Not a Neural Network
This is the part worth understanding, because it is the whole reason the model is shaped like this.
An n-gram is just a short run of words. "New York" is two words, a bigram. "New York City" is three, a trigram. Qwen built a table of 20 million of them and put it in the model at layer 2.
Normally a language model has to work everything out from its weights. If it needs to know something, it computes its way there. A DeepSeek paper published earlier this year, on the same idea, puts the problem bluntly: transformers "lack a native primitive for knowledge lookup, forcing them to inefficiently simulate retrieval through computation". Qwen does not cite that paper and we are not claiming they used it. It is the clearest published description of what an n-gram embedding is for.
So Qwen gave it a lookup instead. Take the last two or three tokens, hash them into an address, fetch that row from the table, and add it into the layer. No reasoning, no matrix multiplication against 51 billion parameters. A dictionary, consulted one entry at a time.
The useful way to hold it: the 125B thinks, and the 51B remembers.
Why that changes where the memory has to live
Here is the part that matters for your hardware, and it is a genuine difference in kind rather than degree.
A mixture of experts decides what to read while it is running. The router looks at the token, picks 10 experts out of 512, and only then does anyone know which weights are needed. You cannot fetch them in advance because the decision has not been made yet.
An n-gram address is a hash of tokens you already have. You know which row you need before you need it. The DeepSeek paper states the consequence for its own module directly: deterministic addressing "enables runtime prefetching from host memory, incurring negligible overhead".
Qwen's own card puts it this way: embeddings are "more amenable to offloading than Mixture-of-Experts (MoE)". The 51B is designed from the start to sit somewhere that is not your GPU, and to be pulled across a bus one row at a time while the model runs.
The Arithmetic That Decides Everything
Take the Q4_K_M row at 32K context: 105.3 GiB.
That does not fit a single card. Four 32 GB cards get you there with headroom, or a Mac Studio with 256 GB of unified memory.
Now split it the way the architecture intends. The n-gram table is 51B of the 180B, so roughly 29.8 GiB of that total is lookup table and 75.5 GiB is the model that does the thinking.
75.5 GiB fits on a single 96 GB workstation GPU. With room for the cache, which as we established barely grows.
Nobody can do this today. No released runtime offloads the n-gram table separately, and the article you are reading is not going to pretend otherwise. But @superalesha said on 2026-08-26 that he has started work on llama.cpp to do exactly that, keeping the table in system RAM and having the GPU touch only the current token's rows, and he lists open problems around speed, quality and how the table gets quantized.
If that lands, a 180B model becomes a single-workstation model. If it does not, the 51B sits on your card doing very little per token.
How It Compares to What You Already Run
The benchmark table Qwen published with the model:
These are Qwen's own published figures, reproduced as they published them.
| Flash Next | Qwen3.8 27B | Qwen3.7-Plus | DeepSeek-V4-Flash-0731 | Claude-Opus-4.6 (Max) | |
|---|---|---|---|---|---|
| Params | 125B | 27B | 397B | 284B | not stated |
| Activated params | 6B | 27B | 17B | 13B | not stated |
| N-gram embedding params | 51B | not applicable | not applicable | not applicable | not stated |
| DeepSWE 1.1 | 58.7 | 42.2 | 16.5 | 54.4 | not stated |
| SWE-bench Pro | 62.5 | 61.7 | 55.8 | 56.0 | 53.4 |
| SWE-bench Multilingual | 81.0 | 73.8 | 75.8 | not stated | 77.5 |
| NL2Repo-Bench | 48.1 | 42.3 | 41.1 | 54.2 | 47.6 |
| CoWorkBench | 73.9 | 70.7 | 65.1 | 45.1 | 68.2 |
| JobBench | 55.7 | 33.4 | 27.6 | 41.3 | 36.6 |
| Toolathlon Verified | 73.5 | 67.1 | 50.6 | 70.3 | not stated |
| IFBench | 81.3 | 79.5 | 79.1 | 79.2 | 62.5 |
| GPQA Diamond | 91.7 | 89.2 | 90.3 | 90.8 | 91.3 |
| HLE | 35.9 | 30.8 | 34.7 | 33.8 | 40.0 |
| LiveCodeBench v6 | 91.9 | 90.3 | 89.6 | 90.6 | 88.8 |
It is a multimodal model, and Qwen publishes a second table for that:
| Flash Next | Qwen3.8 27B | Qwen3.7-Plus | Claude-Opus-4.6 (Max) | |
|---|---|---|---|---|
| RecreationBench | 49.9 | 47.1 | 30.2 | not stated |
| AndroidWorld | 84.5 | 81.9 | 81.0 | 62.0 |
| Vision2Web | 64.0 | 62.9 | 42.1 | not stated |
| ERQA | 72.3 | 65.5 | 69.8 | 40.8 |
| LVBench | 76.6 | 72.4 | 76.2 | 63.0 |
| RealWorldQA | 88.5 | 85.9 | 86.9 | 73.9 |
The comparison that matters here is against the 27B, because that is the model most people reading this already run. Flash Next activates 6B per token against the 27B's 27B, and Qwen has it above the 27B on every row of both tables. Roughly four times less compute per token, paid for with about six times the memory.
Who Can Actually Run It
- A 24 GB card: no, at any tier we would recommend. Q2_K is 57.7 GiB and quality at 2-bit on a model this sparse is unproven.
- A 96 GB workstation card: Q3_K_M at 73.2 GiB fits today. Q4_K_M does not, until somebody ships n-gram offloading.
- Four 32 GB cards: Q4_K_M fits with headroom, and this is the most realistic setup for it right now.
- Mac Studio, 256 GB: Q4_K_M fits comfortably. The M5 Ultra at 1.2 TB/s is the fastest way to hold it in one box.
- A PC with a lot of system RAM: this is the interesting one. Expert-offload engines already move MoE experts to host memory, and this model adds a second, larger, more offloadable thing to move. The two techniques point at the same machine.
Put your own card into the GPU checker and it will tell you which tier clears, using the same numbers as the table above.
Sources
- Qwen3.8-Flash-Next on Hugging Face and the FP8 release on ModelScope, read 2026-08-25 and 26. Architecture, parameter split, layer layout, context length and all benchmark figures are Qwen's own
- Xin Cheng et al., Conditional Memory via Scalable Lookup, arXiv 2601.07372, for the n-gram mechanism and the prefetching property
- @superalesha on X, 2026-08-26, for the llama.cpp offloading work, which is announced and not yet released
- Memory figures are our own calculator at llama.cpp, and we have not run this model ourselves. Corrected 2026-09-09: this line used to say nobody had published a measured tokens per second figure. That stopped being true and we did not notice. Our own corpus now carries 27 measured runs for it from 13 named testers, collected in tokens per second and discussed in Qwen3.8 27B speed
FAQ
How much VRAM does Qwen3.8 Flash Next need?
At Q4_K_M with 32K of context, about 105.3 GiB in total. Q3_K_M brings that to 73.2 GiB and Q8_0 raises it to 183.3 GiB. Those totals include the 51B n-gram table, which no current runtime lets you move off the GPU separately.
What is an n-gram embedding?
A lookup table of short word sequences. Qwen stores 20 million bigrams and trigrams, and at layer 2 the model hashes the last few tokens, fetches the matching row, and adds it to what it is computing. It replaces work the model would otherwise have to do from its weights.
Why does 180B need so little context memory?
Only 12 of its 48 layers keep a cache that grows with context, and each has just 2 KV heads. The other 36 hold a fixed-size state. Going from 8K to 256K costs 5.9 GiB, which is less than the same trip costs on dense Qwen3.8 27B.
Can it run on one GPU?
At Q3_K_M on a 96 GB card, yes. At Q4_K_M, not today. If a runtime ships that keeps the n-gram table in system RAM, the resident part drops to roughly 75.5 GiB and a single 96 GB card becomes enough.
Is 6B active really the whole story for speed?
It sets the compute per token, not the memory. All 180B still has to be somewhere the machine can reach. That is the same rule the Qwen3.8 27B MoE conversion demonstrated: total parameters buy the card, active parameters buy the speed.
Can a DGX Spark run Qwen3.8 Flash Next?
Yes, at Q4_K_M with the full 256K context. That configuration needs 110.6 GiB, against the Spark's 128 GB of unified memory, so it fits with room to spare. It is one of the few single boxes at that price that holds this model at full context, and the reason it works is the same one as everywhere else on this page: only 12 of the 48 layers keep a cache that grows, so 256K costs barely more than 8K. For the machine itself, see our guide to running DeepSeek V4 Flash on a DGX Spark, which measures the usable memory at roughly 119 GiB of the 128.
Is this Qwen4?
No. Qwen describes it as an experimental preview of the architecture that Qwen4 will be built on, released ahead of Qwen4 itself.