A title card reading Qwen3.8-Flash-Next — the standing page, with four cards showing status open weights released 24 Aug 2026, architecture 125B MoE plus a 51B n-gram table with 6B activated, GGUF downloads from 72.5 GB to 354 GB, and licence Qwen Community License 1.0.
Guides & Insights

Qwen3.8-Flash-Next: What's Confirmed, What You Can Actually Download, and What to Run Instead

Author

Gideon Frost

Date Published

Latest models · 20View all models →
Benchmarks: Artificial Analysis · updated daily
Back to all posts

If you are looking for Qwen3.8-Flash-Next because you expect it to arrive, the most useful sentence here is the one that stops you wasting a session: it already arrived. The weights have been downloadable since late August 2026, and the model is an open-weight, vision-capable mixture-of-experts preview of the architecture A​libaba says will underpin Qwen4. What does not exist — and this is the part most searches for "flash next" quietly assume — is any announced next iteration beyond it. There is no second preview, no dated successor, and no vendor statement promising one. This page is the standing answer to the question people are still typing: what Qwen3.8-Flash-Next is, what is confirmed about it, which files exist for it, what its licence permits, and what to run today if you want a callable model rather than a download — the production sibling Qwen3.8-Flash, or the Apache-2.0 dense Qwen3.8-27B.

Confirmed, expected, and inferred — keep the three apart

The distinction matters here more than usual, because this model's name invites people to read a roadmap into it. Three grades of statement follow, and each is labelled.

Confirmed, from the vendor's own material. Qwen3.8-Flash-Next is a causal language model with a vision encoder, published as post-trained weights and configuration files in Hugging Face Transformers format. Its repository under the Qwen organisation was created on 24 August 2026 and last modified on 27 August 2026; the formal ModelScope release landed on 26 August. A​libaba's own card calls it "this experimental preview of the architecture that will underpin Qwen4," and states that the first open-weight release under that architecture is this model. Stored parameters break down as a 125B mixture-of-experts body, a separate 51B n-gram embedding table, and roughly 4B of multi-token-prediction layers, with 6B activated per token. Context is 262,144 tokens natively, extensible to 1,000,000. Thinking mode is on by default. The card reports compatibility with Hugging Face Transformers, vLLM, SGLang and TokenSpeed, and the repository itself holds 131 safetensors shards in BF16.

Confirmed, and easy to miss. The served production model is a different artefact with a similar name. Qwen3.8-Flash is the API build derived from these weights; the FP8 checkpoint's own card describes it as "the official version based on Qwen3.8-Flash-Next with more production features." If your question is "can I call this from an API," that is the name you want, not the preview's.

Expected, and therefore not stated here. A model called "Next" implies a following iteration. Nothing published supports a date, a parameter count, a licence, or a capability for one. Any article that gives you a release window for a successor is inferring, and you can check that by looking for the source. There is none in A​libaba's own material.

A two-column scoreboard separating vendor-confirmed facts about Qwen3.8-Flash-Next from claims that are only inferred, listing repository dates of 24 August 2026 created and 27 August 2026 last modified, a 125B MoE body with a 51B n-gram embedding table and about 4B MTP layers at 6B active, 262,144 native context extensible to 1,000,000, 131 BF16 safetensors shards, and no published successor date or parameter count.

The two questions with real demand behind them: GGUF and nvfp4

Searches for this model cluster hard on two things — "flash next gguf" and "flash next nvfp4" — and both have concrete, checkable answers rather than speculative ones. Neither is answered by guessing a size table, so here is what is actually published.

GGUF exists, from several independent converters. The main sources are ggml-org/Qwen3.8-Flash-Next-GGUF, unsloth/Qwen3.8-Flash-Next-GGUF, bartowski/Qwen3.8-Flash-Next-GGUF and AtomicChat/Qwen3.8-Flash-Next-GGUF, alongside a long tail of smaller repos. They are not the same product, and the difference matters more than usual at this size.

The ggml-org repository is the minimal one: an IQ4_NL build, a Q8_0 build, a separate multimodal projector file (mmproj-Qwen3.8-Flash-Next-Q8_0.gguf, about 0.6 GB) that you need if you want the vision path, and three multi-token-prediction draft files in BF16, Q4_0 and Q8_0. If you only want to run text, that repository is enough.

The unsloth repository is the wide ladder, and it is where the size question actually gets answered. Its published files run from 72.5 GB (UD-IQ1_S) and 74.5 GB (UD-IQ1_M) at the bottom, through 78.9 GB (UD-Q2_K_XL), 82 GB (UD-IQ3_XXS) and 90 GB (UD-Q3_K_XL), to 93.7 GB (UD-IQ4_XS), 111 GB (UD-Q4_K_XL), 158 GB (UD-Q5_K_XL), 169 GB (UD-Q6_K_XL), 188 GB (Q8_0) and about 354 GB at BF16. It also ships its own MTP draft files and two mmproj files.

Read that ladder for what it is. The smallest quantisation anyone publishes for this model is still larger than 70 GB on disk. There is no build that fits a single consumer card the way a dense 27B does, and the repository gives no per-quantisation VRAM guidance at all — its hardware section is an empty "log in to add your hardware" prompt. So the honest answer to "will this fit on my machine" is that you should size against the published file sizes above and against the architecture's own trick: the 51B n-gram embedding table is addressed by lookup keys known in advance, which is precisely what lets a checkpoint this size run with the embedding table resident in host memory rather than pinned in VRAM. That is a design feature, not a claim about your specific box, and it is the reason the practical floor here is a machine with a lot of system RAM and a smaller amount of accelerator memory, not the other way round.

nvfp4 exists too, and it carries a different licence. nvidia/Qwen3.8-Flash-Next-NVFP4 was published on 2 September 2026, produced with N​VIDIA's Model Optimizer toolchain, and totals roughly 133 GB across ten shards plus a 53.7 GB FP8 multi-token-prediction and per-layer-embedding file. Its card lists the N​VIDIA Open Model License, not the Qwen licence — a point worth reading twice if you plan to redistribute. Other NVFP4 builds exist from Red Hat AI, RadixArk and local-inference-lab; Intel publishes a W4A16 AutoRound build; MLX builds for Apple silicon exist from several community publishers.

One more format is worth naming because it is the vendor's own: Qwen/Qwen3.8-Flash-Next-FP8. It is a fine-grained FP8 quantisation with a block size of 128, and its card claims performance metrics "nearly identical to those of the original model." It carries the same community licence as the base weights, and it is the checkpoint A​libaba's own benchmark pipeline uses.

A scoreboard of published artefact formats for Qwen3.8-Flash-Next, listing the unsloth GGUF ladder from 72.5 GB at UD-IQ1_S to about 354 GB at BF16, the NVIDIA NVFP4 build at roughly 133 GB across ten shards under the NVIDIA Open Model License, the vendor FP8 build with block size 128 under the Qwen Community License 1.0, and the licence's 100 million monthly active user and US$20 million monthly revenue naming threshold.

What the licence permits — and why that answers the uncensored question

The largest single cluster of queries around this model is not about benchmarks. It is about uncensored and abliterated builds, and the right way to answer it is to read the licence and look at what has been published, because those two things determine what a reader can actually obtain.

Qwen3.8-Flash-Next ships under the Qwen Community License 1.0. The licence text grants, free of charge, the right to use, copy, modify, merge, publish, distribute, sublicense, sell, deploy, host, fine-tune and create derivative works from the weights, parameters, configuration files and inference code. It requires that the copyright and permission notice travel with copies or substantial portions. It sets a naming threshold: if you use the software or derivatives in a commercial product or service with more than 100 million monthly active users or US$20 million in monthly revenue, the model name must be displayed prominently in that product's interface. And it separates out service businesses — a "Model as a Service" or "AI Work Assistant" business requires a separate licence from Qwen before commercial use, with an internal-use carve-out for deployments that do not expose the model, its outputs or its capabilities to third parties.

Three consequences follow directly, and they are the whole answer to the uncensored queries:

• The weights are open and the licence expressly permits derivative works. Community abliterations are therefore lawful, not grey-market, and they exist in quantity — huihui-ai publishes several, and OrcaRouter's own Qwen3.8-Flash-Next-Uncensored family is published under Apache 2.0 with GGUF, FP8, NVFP4 and MLX builds derived from it.

• A derivative does not always inherit the original licence. The N​VIDIA NVFP4 build carries the N​VIDIA Open Model License; a quantisation of a community abliteration can carry Apache 2.0. If licence terms are why you are choosing one file over another, read the card of the specific repository you are about to download rather than the card of the base model.

• The commercial threshold scales with your business, not with the model. For a team building an internal tool, the practical constraint is the notice requirement. For a team selling model access, the separate-licence clause for Model-as-a-Service businesses is a line item to price before you build on these weights, and the Apache-2.0 Qwen3.8-27B avoids that conversation entirely.

What this page will not do is characterise how any hosted service or any particular build responds to any particular prompt. That is not what the licence governs and not what we measured. The licence and the published weight files are what determine availability, and both are things you can verify yourself in a couple of clicks.

What to run today

This is the part a standing page owes a reader who arrived wanting to build something this afternoon rather than to download 90 GB.

Qwen3.8-Flash-Next is not a model we route, and no amount of wishing makes it one — there is no model id matching qwen3.8-flash-next in our catalogue today, and this page is not going to hint that there will be. Its serving story is a download-and-host story: pull the weights from Hugging Face or ModelScope, choose between the safetensors, FP8, NVFP4 and GGUF paths above, and run it on hardware you provision.

What we do route is the production build of the same architecture. Qwen3.8-Flash is live as qwen/qwen3.8-flash at $0.15 per million input tokens and $0.47 per million output tokens, with cached input at roughly $0.018 per million and a 1M-token context that takes text, image and video in and returns text. That pricing is the provider's published list passed through with no markup, so a change on A​libaba's side reaches your endpoint the same day rather than at the next billing cycle. If what you wanted from the preview was the architecture in production rather than the checkpoint on disk, that is the closest callable thing to it and it is one key away.

The OrcaRouter model page for qwen/qwen3.8-flash, showing the model id, its input and output pricing per million tokens, cached input pricing, its context window and its text, image and video input modalities.

If your constraint is licence rather than latency, the other answer is Qwen3.8-27B. It is a dense 27-billion-parameter model under Apache 2.0 — no naming threshold, no separate agreement for service businesses — and it is routed as qwen/qwen3.8-27b, so you can benchmark the two shapes against your own traffic before committing to either. Both sit behind the same key and the same OpenAI-compatible endpoint, which means trying one and then the other costs a model-id change rather than an integration. That is the cheap way to answer "do I need the 6B-active architecture at all," because it measures your workload instead of someone else's benchmark.

What is not settled

Whether the "Next" in this model's name is a one-off preview or the first of a numbered line is unresolved, and nothing published lets you answer it. The one thing a reader can rely on is that the preview's production sibling already exists and is priced, which is unusual — most architecture previews do not ship with a commercial counterpart on the same day. Treat this model as a preview of a family that is partially here, not as a leak of something that is not.

The other open question is tooling rather than the model. llama.cpp, vLLM and SGLang all reach it, the FP8 build is the vendor's own evaluation checkpoint, and the GGUF ecosystem has already produced everything from 1-bit to full-precision builds — but quantisation quality at 1 to 3 bits on a 176B-stored mixture-of-experts model is not a settled matter, and no one has published a controlled comparison of the low-bit builds on matched hardware. If you are choosing between UD-IQ1_S and UD-Q2_K_XL to save 6 GB, you are making that call on your own evaluation, which is the correct way to make it and also the reason a speculative size table on a page like this would be worse than useless.

Two sibling pages carry the angles this one deliberately does not: the leak coverage, which reported what the pre-release signals said and is dated to that moment, and the head-to-head against the Apache-2.0 dense model, which owns the comparison. Read those if you want the story of how this model appeared or an argument about which of the two to choose. This page will still be here, unchanged, when both of those have gone stale.