CanItRun Logocanitrun.

Qwen3.8-Flash-Next

Qwen3.8-Flash-Next needs roughly 123.0 GB VRAM at Q4_K_M quantization (403.4 GB at FP16). 22 GPUs we track can run it fully in VRAM at 8k context.

22 GPUs run this natively · 2 with CPU offload

Alibaba180B params6B active (MoE)256k contextQwen Community 1.0Commercial use ok
Q4_K_M total
123.0 GB
at 8k context
Smallest GPU
141 GB
NVIDIA H200 141GB, at Q4_K_M
KV cache, full context
6.4 GB
12 of 48 layers cache
Inputs
Text · Image · Video
Qwen Community 1.0, released August 2026
Real weight total
180B
125B backbone + 51B n-gram + 4B MTP, not the 125B headline

Qwen3.8-Flash-Next is a Mixture of Experts (MoE) model with 180B total parameters but only 6B active per token developed by Alibaba. Released 26 August 2026 as an experimental preview of the architecture Alibaba says will underpin Qwen4, not a finished flagship. Headlined as "125B parameters, 6B activated," but the checkpoint also ships a 51B-parameter n-gram embedding table and a 4B multi-token-prediction module, for a real on-disk total of 180B confirmed against the repo's own safetensors index. The 48 layers are a hybrid stack, 12 repeats of three Gated DeltaNet layers followed by one Qwen Sparse Attention (QSA) layer, so only 12 of 48 layers keep a per-token KV cache. QSA replaces the plain full-attention layers used in Qwen 3.6/3.8 27B with a lightweight indexer that scores context at micro-block granularity and attends only to a 2048-token budget per query, cutting long-context compute; per Qwen's own technical report, that selection still draws from the same full per-token cache a dense layer would need, so it saves compute and memory bandwidth rather than cache size. Context is 262,144 tokens natively and up to 1,000,000 with extended settings; the checkpoint accepts text, image, and video input.

To run Qwen3.8-Flash-Next locally: The 6B active parameters keep decode fast once loaded, but the weights themselves are the hurdle: Q4_K_M on this site's generic ladder needs about 109.6GB, and even with hybrid attention keeping KV cache to only about 6.4GB at the full 262k native context (just 12 of 48 layers caching at a narrow 2-KV-head, 256-dim width), the combined total lands around 123GB, more than any 24-128GB consumer, workstation, or unified-memory card (DGX Spark, Strix Halo, a 128GB Mac Studio) can hold. On this site's naive one-VRAM-pool math, the practical floor is a 141GB H200 or bigger datacenter card, or a 192GB-plus Mac/AMD unified-memory box. That's a worst case, though: Qwen's own technical report says the 51B-parameter n-gram embedding table is designed to be prefetched from host RAM instead of held in VRAM, and both vLLM (VLLM_PLE_CPU_OFFLOAD=1) and SGLang (--ple-offload-embedding) shipped that offload path on release day, so a real deployment only needs the 129B backbone-plus-MTP resident on the GPU while the n-gram table streams from host RAM; vLLM's own recipe puts that at roughly 172.78 GiB of GPU memory for an FP8 checkpoint with offload enabled, or about 335.28 GiB for BF16, plus at least 51GB of host RAM for the offloaded table. Once it fits, decode is fast because so little is active per token: roughly 252 tok/s on a single H200 at Q4_K_M, 420 tok/s on a B200 or B300, 278 tok/s on an MI300X, and 52-78 tok/s on unified-memory boxes (M2/M3/M5 Ultra) that are more bandwidth-limited. As a MoE model, inference speed depends on active parameters (6B) rather than total size.

Qwen's own README reports GPQA Diamond 91.7, LiveCodeBench v6 91.9, and SWE-bench Pro 62.5, each ahead of the dense Qwen3.8-27B on the same metrics despite activating a fraction of the parameters per token. It's positioned as a preview, not a finished release: Qwen frames the fourteen-benchmark pretraining comparison against its own 397B-A17B predecessor as a rough wash (ahead on eight, behind on six by at most 2.6 points) at roughly a ninth of the training compute, rather than claiming a clean win. These are Alibaba's own launch figures; independent third-party reproduction was still thin in the first days after release.

Three linear layers, then one sparse-attention layer

Qwen3.8-Flash-Next is a mixture of experts, so only 6 of its 180 billion parameters compute on any given token, but its 48 layers are also a hybrid stack, the same idea behind Qwen's dense hybrid releases. One block repeats twelve times: three Gated DeltaNet layers, then one Qwen Sparse Attention (QSA) layer, each wrapped in its own MoE feed-forward.

Gated DeltaNetlinear attention, fixed-size stateQwen Sparse Attention2 KV heads × 256 dim, 2048-token budget
layer 13:1 pattern × 12layer 48

12 of 48 layers keep a KV cache that grows with the full context. The other 36 hold a fixed-size recurrent state, so their memory cost does not move as the context window grows.

DeltaNet's memory is a fixed-size recurrent state that costs the same at 2,000 tokens or 262,144, so those 36 layers add nothing to the KV bill regardless of context length. Only the 12 QSA layers store per-token keys and values. QSA's own indexer narrows what each query actually attends to, but per Qwen's technical report that selection is still made from the same full per-token cache a standard full-attention layer would need, so the sparsity buys compute and memory bandwidth, not a smaller cache.

What the QSA swap actually buys at long context

QSA is pitched as a compute and latency win, not a memory one, so the honest comparison is against the same hybrid ratio without it: what if every fourth layer still did full attention, but the plain kind Qwen 3.6/3.8 27B use, instead of QSA's indexed version.

0816243232k64k128k192k256k6.4 GBFlash-Next25.8 GBall-caching 48L
Qwen3.8-Flash-Next: 12 of 48 layers cacheThe same checkpoint if all 48 layers cached like a full-attention layer

KV cache only, at FP16. Weights and activation overhead sit on top of these figures.

Filling the full 262,144-token native window costs 6.4 GB of KV cache with the real 12-of-48 hybrid ratio, versus 25.8 GB if every layer cached. At the recommended Q4_K_M weights (109.6 GB), that's a 130.0 GB full-context total against a hypothetical 151.6 GB: a real saving, but a modest one next to the 109.6 GB of weights that dominate either total.

VRAM at each quantization

Numbers here are computed at 8k context. This model's hybrid attention stack means KV cache grows much more slowly than context length, unlike a conventional full-attention model.

QuantWeightsKV cacheTotal
FP32720.0 GB0.20 GB806.6 GB
BF16360.0 GB0.20 GB403.4 GB
FP16360.0 GB0.20 GB403.4 GB
Q8_0191.3 GB0.20 GB214.5 GB
Q6_K147.8 GB0.20 GB165.7 GB
Q5_K_M128.2 GB0.20 GB143.8 GB
Q4_K_Mrec109.6 GB0.20 GB123.0 GB
Q3_K_M86.6 GB0.20 GB97.2 GB
Q2_K68.6 GB0.20 GB77.0 GB
NVFP4cuda90.0 GB0.20 GB101.0 GB

Shown at 8k context with FP16 KV cache. NVFP4 needs a CUDA GPU to run. Toggle TurboQuant in the calculator to view compressed KV cache numbers.

Benchmarks

GPQA Diamond
91.7
LiveCodeBench
91.9
SWE-bench Pro
62.5

GPUs that run Qwen3.8-Flash-Next natively (22)

Show 17 more
Plus 2 GPUs that run it with CPU offload (slower)

Notes

An experimental preview of the architecture Alibaba says will underpin Qwen4, not a finished flagship: the production Qwen3.8-Flash ships separately via Qwen Cloud's API with 1M-token context by default and built-in tools. Replaces the 'Gated Attention' full-attention layers used in Qwen 3.6/3.8 27B with Qwen Sparse Attention (QSA), a lightweight indexer that scores context at micro-block granularity so attention cost stops growing quadratically at long context, while the KV cache itself still scales exactly like a normal full-attention layer. On disk this is 125B backbone parameters (6B active per token, MoE with 512 experts) plus a 51B-parameter n-gram embedding table and a 4B multi-token-prediction module reused for speculative decoding, for 180B total. Qwen's tech report says the n-gram table is designed to be prefetched from host RAM rather than held in VRAM, and vLLM and SGLang both shipped that offload path on release day (vLLM's VLLM_PLE_CPU_OFFLOAD=1 flag, SGLang's --ple-offload-embedding flag), so a real deployment can keep only the 129B backbone-plus-MTP resident on the GPU while the n-gram table streams from host RAM; this site's generic quant ladder still prices the full 180B as one VRAM pool, since it has no field for a component designed to live in host RAM instead. Thinking mode is on by default with tunable reasoning_effort. Licensed under Qwen's own Community 1.0 terms: free commercial use, but model attribution must be displayed above 100M monthly active users or $20M/month revenue, and a separate license is required for any Model-as-a-Service or 'AI Work Assistant' business built on it.

Hugging Face ↗Released 2026-08-26

Compare Qwen3.8-Flash-Next with other models

How to run Qwen3.8-Flash-Next locally

816244880160320

Q4_K_M needs 123.0 GB: needs multiple datacenter-class GPUs (80 GB+ each).

vLLM or SGLang (BF16 safetensors only; no GGUF/llama.cpp build exists at launch)

VLLM_PLE_CPU_OFFLOAD=1 vllm serve Qwen/Qwen3.8-Flash-Next \
  --dtype bfloat16 \
  --max-model-len 262144 \
  --tensor-parallel-size 4

LM Studio: Not available in LM Studio at launch: it needs a GGUF build, and unsloth's Qwen3.8-Flash-Next-GGUF repo was still marked 'WIP - uploading!' in the hours after release. Treat any quant estimate on this page as a size projection, not a confirmed downloadable file, until that lands.

Why this quantization? There is no quantized community build to point at yet, so this site's own Q4_K_M projection (roughly 109.6 GB) is a ladder-position estimate, not a real download. It's also a worst case: Qwen's technical report designs the 51B-parameter n-gram embedding table to be prefetched from host RAM rather than held in VRAM, and both vLLM (the VLLM_PLE_CPU_OFFLOAD=1 flag above) and SGLang (--ple-offload-embedding) shipped that offload path on release day. vLLM's own recipe puts the real GPU-memory need with offload enabled at roughly 172.78 GiB for an FP8 checkpoint or about 335.28 GiB for BF16 (TP2 minimum on GB300, TP4 recommended), plus at least 51 GB of host RAM for the offloaded table, well short of the naive one-VRAM-pool math this site's generic ladder assumes.

Who is Qwen3.8-Flash-Next for?

Researchers and infrastructure teams evaluating what Qwen4's architecture will look like, with access to a datacenter-class card (141 GB or more, or several smaller GPUs plus vLLM/SGLang's n-gram offload) or a multi-GPU cluster, not a model to download on a home GPU while it is this new.

Best for

  • Evaluating Qwen Sparse Attention (QSA) and the n-gram-embedding idea ahead of Qwen4's full release
  • Long-context agentic and multimodal workloads once quantized builds and engine support mature
  • Research into hybrid linear-attention/MoE architectures

Not ideal for

  • Any single consumer GPU (24-48 GB): even with the n-gram table offloaded to host RAM, the 129B backbone-plus-MTP alone doesn't come close to fitting
  • Ollama or LM Studio users, since neither a GGUF build nor an Ollama tag exists at launch
  • Production use: Qwen itself frames this as an experimental preview, with the finished Qwen3.8-Flash shipping separately via Qwen Cloud's API

So who is this actually for?

This is a research preview of Qwen4's likely architecture, not a model to reach for on a home GPU. At Q4_K_M, this site's own one-VRAM-pool math needs a single 141 GB or larger card (H200, B200, MI300X) or a 192 GB-plus unified-memory box just to load, and today's real download is the full ~180B checkpoint rather than the 125B/6B-active headline. That worst case is softer in practice: Qwen's technical report designs the 51B n-gram table to stream from host RAM instead, and both vLLM and SGLang shipped that offload path on release day, so a real deployment only needs the 129B backbone and MTP module resident on the GPU. Either way, if you have the hardware the payoff is real: GPQA Diamond and SWE-bench Pro both beat the dense Qwen3.8-27B while only 6B parameters compute per token, so decode stays fast (roughly 252 tok/s on a single H200 at Q4_K_M) once it's loaded. Everyone else is better off waiting, either for a smaller distillation of this architecture or for local tooling to catch up with it.

Explore

Browse all guides →Browse all models →Browse all GPUs →

Frequently asked questions

What are the VRAM requirements for Qwen3.8-Flash-Next?
Qwen3.8-Flash-Next requires approximately 123.0 GB of VRAM at Q4_K_M quantization, 214.5 GB at Q8, and 403.4 GB at FP16. These numbers assume 8k context window; its hybrid attention stack caches far fewer than all layers, so VRAM grows much slower than linearly with context.
How many parameters does Qwen3.8-Flash-Next have?
Qwen3.8-Flash-Next has 180 billion total parameters, but only 6 billion are active per token thanks to its Mixture of Experts (MoE) architecture. This makes inference significantly faster than the total parameter count suggests.
Is Qwen3.8-Flash-Next good for coding?
Yes. Qwen3.8-Flash-Next scores 91.9 on LiveCodeBench, demonstrating strong code generation and completion capabilities.
Can Qwen3.8-Flash-Next run on a 16 GB GPU?
No. At Q4_K_M, Qwen3.8-Flash-Next needs 123.0 GB of VRAM, more than 16 GB. You will need a multi-GPU server.
Can Qwen3.8-Flash-Next run on a 24 GB GPU?
No. Even at Q4_K_M, Qwen3.8-Flash-Next needs 123.0 GB. Consider a multi-GPU server with 123 GB+ of combined VRAM.
What is the smallest quantization for Qwen3.8-Flash-Next that fits in 24 GB of VRAM?
Qwen3.8-Flash-Next cannot fit in 24 GB of VRAM at any standard quantization level. The minimum needed is 77.0 GB at Q2_K.
What GPU do I need to run Qwen3.8-Flash-Next locally?
You need a multi-GPU server. At Q4_K_M, Qwen3.8-Flash-Next needs 123.0 GB VRAM, more than any single consumer GPU. That's roughly 2x 80 GB datacenter GPUs (H100, A100, or similar) pooled together.
Why does this page say Qwen3.8-Flash-Next needs about 180 GB, when Qwen calls it a 125B, 6B-active model?
Qwen's own numbers are accurate as far as they go, 125B backbone parameters with 6B active per token, but the checkpoint also ships a separate 51B-parameter n-gram embedding table and a 4B multi-token-prediction module, for 180B total on disk, confirmed against the repository's own safetensors index. Qwen's technical report says the n-gram table is designed to be prefetched from host RAM rather than held in VRAM, and vLLM and SGLang both shipped that offload path on release day (vLLM's VLLM_PLE_CPU_OFFLOAD=1 flag, SGLang's --ple-offload-embedding flag), so a real deployment can keep the n-gram table off the GPU entirely. This site's generic quant ladder still prices the full 180B as one VRAM-resident pool, since it has no field for a component designed to live in host RAM instead, so treat the figures on this page as a worst-case upper bound, not what a real vLLM or SGLang deployment with offload enabled actually needs.
What is Qwen Sparse Attention (QSA), and does it shrink the KV cache?
QSA replaces the plain full-attention layers used in Qwen 3.6/3.8 27B with a lightweight indexer that scores 4-token micro-blocks and lets each query attend to only a 2,048-token budget, which cuts attention compute and memory bandwidth at long context. It doesn't shrink the KV cache itself: Qwen's own technical report describes the indexer selecting from the same full per-token cache a standard full-attention layer would need, so the saving is in compute, not storage.