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" depends on where your runtime keeps that table.
What It Needs
Updated 28 September. Every size on this page is recomputed from our current catalogue. The low tiers moved most, Q2_K from 57.7 to 76.6 GiB at 32K, because the catalogue now reads them from Unsloth's published files, which keep the 51B n-gram table at about 4.5 bits in every build instead of shrinking it with the rest. llama.cpp's own per-token bookkeeping is now counted too.
Our calculator, llama.cpp, and these are totals including cache and overhead:
| Tier | 8K context | 32K context | 256K context |
|---|---|---|---|
| FP16 | 337.4 GiB | 338.0 GiB | 343.5 GiB |
| Q8_0 | 179.9 GiB | 180.4 GiB | 186.0 GiB |
| Q4_K_M | 106.8 GiB | 107.4 GiB | 113.0 GiB |
| Q3_K_M | 86.5 GiB | 87.1 GiB | 92.7 GiB |
| Q2_K | 76.0 GiB | 76.6 GiB | 82.2 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 6.2 GiB. The same trip on dense Qwen3.8 27B costs 16.1 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: 107.4 GiB.
That does not fit a single card. Four 32 GB cards hold it, just: 64K of context with an F16 cache, 128K with a Q8_0 cache. A Mac Studio with 256 GB of unified memory holds it with room.
Now split it the way the architecture intends. In the published Q4_K_M files the n-gram table is 26.8 GiB of that total, which leaves 80.6 GiB for the model that does the thinking.
80.6 GiB fits on a single 96 GB workstation GPU. With room for the cache, which as we established barely grows.
Runtimes can already do this. llama.cpp merged lazy table reads on 27 August (pull requests #27794 and #27742, --tensor-read-lazy, on by default for a table this size): the n-gram table stays in the model file and rows are read from it as they are needed, with the operating system keeping the busy ones cached in RAM. Since 30 August (#27837) that table stays on the CPU side whatever your GPU offload settings. @0xBakeer measured the cost on a DGX Spark with the table mapped off an NVMe drive, on a pre-merge build with speculation off: 21.05 tok/s with the table cold against 22.40 with it warmed into memory, about 6%. On a later build he re-measured and reports that warming the table makes no measurable difference. @geldeki keeps the table in system RAM on two RTX 3090s with ExLlamaV3 at 2.05 bits per weight and reports about 85 tok/s in a short chat, with MTP speculation on.
In our arithmetic that makes a 180B model a single-workstation model at Q4_K_M, and the 51B stops costing GPU memory.
How much system RAM the table takes depends on the file. unsloth's UD-Q4_K_XL carries it at 26.8 GiB. A default Q4_K_M keeps the table at q8_0, 51.9 GiB of a 113.5 GiB file, per llama.cpp #27742. Either way, by our subtraction, the rest fits a 96 GB card.
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.
A 3-Bit Build Now Prices the Table Separately, and It Fits One Spark
Everything above treats the n-gram table as a thing you move. A quant published this month treats it as a thing you price.
turboderp’s EXL3 conversion ships the model in two pieces, and the file listing is the whole argument of this page written out as bytes. The network weights come to 52.35 GB across seven shards. The n-gram embedding sits beside them in its own file at 32.64 GB. Total on disk: 84.99 GB, or 79.15 GiB.
The revision is labelled 3.05bpw_h5_ng5, and the sizes agree with the label. 52.35 GB across roughly 129B of network and MTP parameters works out near 3.05 bits each. 32.64 GB across the 51B table works out near 5. The table is kept at a higher precision than the network it feeds. That is the opposite of how a quantizer usually treats the biggest file in a repository, and it follows from what the table is: not weights the model multiplies, but answers it looks up. Rounding a lookup harder is rounding the answer.
Against the Q4_K_M figure in the table above, 79.15 GiB against 113.0 at 256K, this is roughly 34 GiB cheaper for the whole model. It is the first build of this model where the two halves carry separate price tags.
What it measures at, on one box
@yume_arasaki ran the full grid on a single DGX Spark on 20 September, on @ViC305’s ExLlamaV3 fork, and published the report with the jobs, the prompt sizes the server reported, and the runs he threw away. Decode, thinking off, temperature 0, better of two repetitions:
| Job | Empty cache | At ~32K | At ~128K |
|---|---|---|---|
| Fifty identical Python clamps | 102.6 tok/s | 111.1 | 69.0 |
| Count from 1 to 200 | 107.1 | 112.9 | 82.0 |
| Explain a hash map, 600 tokens | 71.7 | 52.2 | 49.0 |
| A JSON catalogue | 66.2 |
One of these numbers is a reproduction, and that is rarer than any of the figures. @ViC305 published 79 tok/s on a 400-token greedy code job. The same job on yume’s Spark, same fork at the same commit, measures 79.5 with 74% of drafts accepted against his 73%. Two people, two machines, one recipe, half a token apart. Almost nothing in local inference reporting clears that bar.
The spread between 102.6 and 66.2 is not noise either, and it is not the card. Repetitive Python accepts nearly every drafted token. A JSON catalogue does not. Speculative decoding pays out in proportion to how predictable your text is, which means the honest answer to “how fast is it” is a question about your workload rather than your hardware.
Mainline llama.cpp got faster at depth on 1 October, and we measured it. A fix to this model’s attention path (#29751) lifted decode at 131K tokens on a DGX Spark from 14.1 to 21.8 tok/s on Unsloth’s UD-IQ4_XS, in the table posted with the change. We ran the same long prompts on the same card before and after it: an RTX PRO 6000 Blackwell Server Edition with 96 GB, Linux, Unsloth’s UD-Q3_K_XL, flash attention on, one slot, a prompt filling 90% of the window followed by a 64-token answer. On build b11062 of 20 September that request took 65.8 seconds at 128K and 184.9 at 256K; on b11377 of 3 October it took 47.5 and 107.9, 1.39 and 1.71 times faster. At 64K the gain was small, 23.6 against 22.1 seconds. Writing on b11377 ran at 82.9 tok/s at 128K and 73.5 at 256K. On 5 October, llama.cpp’s first versioned release, v0.6.0, added this model’s own multi-token prediction as a draft for speculative decoding, which its notes put at about 1.5 times faster writing on a DGX Spark. Our runs above did not use it, so writing speed on a current build with drafting on should come out higher.
What raising -ub costs, measured. The same fix grew the indexer’s working memory, which was halved again in build b11372 (#29825), and that buffer grows with the batch size. On the same card and build, -ub 2048 instead of the default 512 raised the peak by 1.17 GiB at 64K, 1.74 GiB at 128K and 3.11 GiB at 256K with an F16 cache (2.63 GiB with Q4_0), and read prompts 33 to 36% faster: 3,415 against 2,529 tok/s at 128K. Our calculator sizes the default batch, so add that on top if you raise it, and update to b11372 or later first.
The number that actually governs a long session
Decode holds up at depth. It reads 51.5 tok/s at 8K, rises to 67.4 at 64K, and is still 55.8 at 240K. There is no cliff.
Prefill is where the time goes. It sits between 851 and 1,069 tok/s across that whole range, which sounds healthy until you multiply it out: a 240K prompt takes 233.7 seconds before the first token appears. At 35K, a realistic agent context, it is about 35 seconds. His own summary of the agent lane is the sentence to keep: the engine decodes at 86.8 tok/s and the wall clock lands near 35, because the prefill is already spent. Decode was never the bottleneck on that box.
Two limits he states himself, both easy to lose in a repost. The engine serves one job at a time, so two and four streams measure 73.2 and 72.3 against a single-stream 71.7: they serialize, and none of this is a concurrency number. And a 3.05-bit build is a 3.05-bit build. He reports it as feeling at least on par with FP4 on his own harness, and labels that as subjective, which it is.
Smaller Builds and Faster Drafting, 1 and 2 October
Four new builds take the model below the standard tiers in the table above. Each needs its own runtime or a patched llama.cpp, because stock llama.cpp cannot load their formats, and every figure below is the publisher’s own measurement:
| Build | Publisher | What changed | Memory | Speed they measured |
|---|---|---|---|---|
| Mooney | Daniel Lougen (@DJLougen) | Experts at 2.125 bits, recovered with distillation; n-gram table at 8 bits, read from the SSD | 92.0 GB download; about 39 GiB in use on a DGX Spark, 35 of it weights | 31.5 tok/s on a short prompt, 27.8 at 4K, one Spark, no drafting |
| Gyro-S | agentionai (@laurent_zw) | Experts at 1.71 bits on average in its own rotor format | 28.8 GiB on the GPU at 64K of context | 58 tok/s on one Radeon AI PRO R9700 32 GB; 71 on code and 86 editing code with MTP drafting |
| Victoria | rmonsurate | 44% of the experts cut, 512 to 288 per layer, then retrained at 4 bits | GGUF Q4_K_M: 49.17 GiB of weights, 107.2 GB download | 34.3 to 38.0 tok/s on a 128 GB M3 Max with its draft head, 26.8 to 27.8 without |
| Sushi-2bpw | Beamsters (@Beamsters1) | A 2-bit pack for Apple Silicon, experts streamed from the SSD on 32 GB Macs | 35.0 GiB of weights | about 18 tok/s, prompts at about 200 tok/s, on an M1 Max at about 66K of context |
Read the quality claims as carefully as the sizes. Mooney scores 88.71% on 536 automatically checked tasks against 92.91% for BF16, 95.5% of it, and finds every needle at 32K, 64K and 128K. Its card also corrects its own launch claim: on the same engine Unsloth’s 4-bit UD-Q4_K_XL decodes at about the same speed without drafting, 30.4 and 27.3 tok/s, so what Mooney buys is memory, most of a Spark left free, not speed. Gyro-S is labelled experimental, with a format that may still change. Victoria is a different model rather than a smaller file: pruned and retrained, it reports 70.0% on Terminal-Bench 2.1 for its NVFP4 build, and its GGUF build is an earlier checkpoint that needs the team’s patched llama.cpp.
How much the smaller files lose, measured. Benjamin Marie of The Kaitchup tested 11 standard GGUF builds of this model on single-turn evaluations: Unsloth’s six from UD-Q4_K_XL (111.3 GB) down to UD-IQ1_S (72.5 GB), AtomicChat’s two 4-bit builds (84.9 and 94.5 GB) and the three GSQ-RCO files that Strata runs (66.4 to 75.8 GB). Every one kept more than 95% of the 16-bit model’s accuracy, the 1-bit files included (post).
The cost showed somewhere else. The quantized builds wrote 14% to 157% more output tokens than the 16-bit model for the same work, so a smaller file can take longer to finish a task than its tok/s suggests, and fill more of its context doing it. He calls these single-turn, non-agentic results and not a ranking, and has said agentic tests will follow. His per-file scores are for paid subscribers; the file list and sizes above are from the public part of his report. Note also how little the smallest builds save: the 1-bit file is still 72.5 GB, because the 51B n-gram table stays at higher precision in every Unsloth build.
Faster drafting on one RTX 3090. On 1 October @quimedesu reported that their cafe-llama.cpp fork doubles decoding with the model’s MTP draft: Flash Next from 25 to over 50 tok/s (post). The repository gives the setup: an RTX 3090 24 GB with 64 GB of RAM, Unsloth’s UD-IQ3_XXS, the experts in pinned RAM with the busiest cached on the card, a Q4_K_M draft with --spec-draft-n-max 4, about 60 to 80 tok/s. The README calls 4 the sweet spot and warns that 7 or more halves decode on CUDA. Like Strata, this keeps the experts off the card, which our calculator does not model: it sizes the model fully resident.
Gyro-M, an 8-Bit Mac Run, and a Price for Eight Machines, 12 October
Gyro-M, an update to agentionai’s rotor format, puts the 125B network of Qwen3.8 Flash Next in 35 GiB, enough for one 48 GB card, two 24 GB cards, or a 64 GB unified machine. Its card reports a KLD of 0.291, ahead of ISTA-DASLab’s IQ3_XXS (0.311) with 20% less memory and Unsloth’s UD-Q2_K_XL (0.334) with 25% less. Those are the publisher’s own measurements, and the format is labelled experimental.
An 8-bit Mac run, early. @lotar_vk measured MLXFW v0.3.0, which he describes as a TensorFold fork that streams experts from the SSD, on an M5 Max with 128 GB: an uncensored 8-bit build, 181 GiB, with 68 GiB of weights in RAM (a 60 GiB expert pool) and the rest on disk, about an 80 GB process. Prefilling a layer at a time cut a 24,000-token cold prompt’s time to first token from about 280 seconds to 60, and fixing a page-cache leak cut it from about 300 to 185, with output still bit-identical. He calls the build unconfirmed and these early measurements.
Eight machines, priced. @tjm8874 ran the model at 16K in and 2K out, one request, thinking off, the median of five runs, and put a purchase price beside each; the task-time column is a separate 25-question test, the median, thinking on, lower better (his table).
| Machine | Engine and quant | Price | Prefill | Decode | Task, seconds |
|---|---|---|---|---|---|
| 5060 Ti 16 GB | Strata / IQ3_XXS | $1,800 | 1,607 | 66.3 | 130.8 |
| PRO 4500 32 GB | Strata / IQ3_XXS | $5,700 | 3,683 | 120.7 | 42.1 |
| PRO 4500 + 5060 Ti | Strata / IQ3_XXS | $6,500 | 3,157 | 101.0 | 42.3 |
| MS-S1 Max 128 GB | Halogen / W4B + overlay | $3,879 | 1,789 | 47.0 | 135.2 |
| MacBook Pro M5 Max 128 GB | MLX-Serve / iQ-MLX 4.7 bpw | $6,699 | 2,204 | 76.6 | 74.7 |
| DGX Spark 128 GB | vLLM 0.30.0 / INT4 top-5 | $6,950 | 3,435 | 57.1 | 103.6 |
| Mac Studio M5 Ultra 256 GB | MLX-Serve / iQ-MLX 4.7 bpw | $9,999 | 4,636 | 119.8 | 47.1 |
| GX10 + DGX Spark | vLLM 0.30.0 / INT4 top-5 | $14,100 | 4,356 | 80.3 | 70.3 |
The PC prices are his reference budgets, each including $1,000 for the base machine; the two Macs are Apple’s prices, and the DGX Spark was not in stock. On the same vLLM build a second unit took prefill to 1.27x and decode to 1.41x. He notes the model, quantization and engine differ down the rows, so read it as a price map rather than a like-for-like race.
Who Can Actually Run It
- A 24 GB card: no, at any tier we would recommend. Q2_K is 76.6 GiB and quality at 2-bit on a model this sparse is unproven. Engines that keep the experts in system RAM, such as Strata and cafe-llama.cpp above, are the way in; the Strata calculator sizes that path for your card and your RAM.
- A 96 GB workstation card: Q3_K_M fits whole, 87.1 GiB at 32K and up to 128K of context. Q4_K_M fits once the n-gram table stays in system RAM or on disk, which leaves roughly 80.6 GiB on the card.
- Four 32 GB cards: Q4_K_M fits, with little to spare: 64K of context with an F16 cache, 128K with Q8_0.
- 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, who announced llama.cpp work on keeping the table in system RAM; llama.cpp pull requests #27794 (lazy table reads) and #27742 (the Flash-Next support that marks its table for them), both merged 2026-08-27, and #27837, merged 2026-08-30, which keeps lazily read tables on the CPU whatever the GPU offload settings; @0xBakeer and @geldeki for measured runs with the table off the GPU, and unsloth's file listing and #28136 for the UD-Q4_K_XL table size
- turboderp's EXL3 conversion, revision
3.05bpw_h5_ng5, for the two-file split and every size in that section, read from the repository tree on 21 September 2026; @yume_arasaki's published report for the measured grid, the depth curve and the prefill figures, with @ViC305's ExLlamaV3 fork as the runtime - Memory figures are our own calculator at llama.cpp, and we have not run this model ourselves. Measured runs from named testers are 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 107.4 GiB in total. Q3_K_M brings that to 87.1 GiB and Q8_0 raises it to 180.4 GiB. Those totals include the 51B n-gram table. Keep the table in system RAM or on disk and the part on the GPU drops to roughly 80.6 GiB at Q4_K_M, since the published files carry the table at 26.8 GiB.
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 6.2 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, yes too, if the runtime keeps the n-gram table in system RAM or reads it from disk: the resident part drops to roughly 80.6 GiB, which a single 96 GB card holds. llama.cpp has read the table from disk since 27 August. Purpose-built builds go lower: agentionai’s Gyro-S needs 28.8 GiB at 64K of context on a 32 GB card, through its own llama.cpp build.
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, and how much context depends on how much of the 128 GB the Spark leaves the model. At 112 GiB, the low end reported hands-on, it holds 128K with an F16 cache or the full 256K with a Q8_0 cache. At about 119 GiB, once the system is tuned, it holds the full 256K with an F16 cache, which needs 113.0 GiB. 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.
Since September there is a second way, and it is cheaper in memory. turboderp's EXL3 build is 79.15 GiB of weights against Q4_K_M's 113.0 GiB total at 256K, and @yume_arasaki measured it on one Spark at 102.6 tok/s on repetitive code and 71.7 on prose, with decode still at 55.8 at 240K of context. The catch is prefill: a 240K prompt waits 233.7 seconds for its first token, and the engine serves one request at a time.
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.