GGUF Discovery

Blog & Guides

Back to All Articles

Qwen3.8-Flash-Next: A Deep-Dive into Alibaba Qwen4 Architecture Preview

August 27, 2026 By Hussain Nazary Technical Analysis 📖 30 min read
TECHNICAL ANALYSIS
Qwen3.8-Flash-Next
A Deep-Dive into Alibaba's Qwen4 Architecture Preview
Hybrid Gated DeltaNet + Sparse Attention + 51B N-gram Embedding, 6B active, 1M context, $0.16/$0.47 per M tokens
Released: August 26, 2026
Model: Qwen/Qwen3.8-Flash-Next (arch: qwen4_exp)
Class: 125B main + 51B N-gram + 4B MTP | 6B active per token
Reading time: ~30 min | Length: ~7,200 words
Open-weight technical analysis | Prepared: August 27, 2026

TL;DR — What you need to know in 90 seconds

Qwen3.8-Flash-Next is the second-generation "Next" architecture preview from Alibaba's Qwen team, released August 26, 2026 as the open-weight counterpart to the production API SKU qwen3.8-flash. It is, by some distance, the most architecturally ambitious open-weight model released this year — and almost every choice in it points in the same direction: drive down the cost of a token without giving up capability. The headline numbers below are the ones a technical reader should walk away with even if they read nothing else.

If you only remember three things: (1) the QSA + Gated Residual + N-gram combo is the most credible open-weight preview of Qwen4 to date; (2) on agentic-coding and office-task benchmarks it is meaningfully ahead of everything in its price tier; (3) on frontier reasoning (HLE) and full computer-use (OSWorld binary) it still sits clearly below Claude Opus 4.6 Max and the Qwen3.8-Max flagship. The rest of this post unpacks why.

Introduction: Why Flash-Next matters

Alibaba's Qwen team has been shipping at a pace that makes most Western labs look deliberate. In the four weeks before this post, they released Qwen3.8-Max (August 3, 2026 — the 2.4T-total / 95B-active flagship, priced at $2.00 / $6.00 per M tokens), Qwen3.8-27B (August 14 — a dense, hybrid-thinking, Apache-2.0 model that runs in ~17 GB of VRAM and turned out to be surprisingly good at single-file app generation), and now Qwen3.8-Flash-Next (August 26) — the model this post is about. Flash-Next is the cheapest SKU in the Qwen3.8 family and the architectural preview for the upcoming Qwen4 generation.

Before going further, a naming clarification that has tripped up a lot of early coverage. The user-requested "Qwen3-Next Flash" does not exist as a single named model. What was actually released — and what almost certainly matches the intent — is Qwen3.8-Flash-Next, an open-weight multimodal MoE shipped under the HuggingFace org Qwen/Qwen3.8-Flash-Next and served in production as the API SKU qwen3.8-flash. There is also an older related release called Qwen3-Next-80B-A3B (Sep 10–11, 2025), which first introduced the "Next" architectural line — the Gated DeltaNet + Gated Attention hybrid. Flash-Next is the second-generation "Next" model and the direct successor to Qwen3-Next-80B-A3B, with substantial architectural additions on top of the original Next skeleton.

The Qwen3.8 family timeline

The three Qwen3.8 releases slot into clearly defined roles:

Table 1 — Qwen3.8 family release timeline

Model Release Type Headline API price (in/out per M)
Qwen3.8-Max Aug 3, 2026 2.4T / 95B active MoE Frontier flagship, 1M ctx $2.00 / $6.00
Qwen3.8-27B Aug 14, 2026 27B dense hybrid-thinking ~17 GB VRAM, Apache-2.0 (self-hosted)
Qwen3.8-Flash-Next Aug 26, 2026 125B+51B+4B / 6B active MoE Qwen4 arch preview, cost tier $0.16 / $0.47

Why the "Next" branding?

The Qwen team is explicit about the role Flash-Next plays. In their own words from the launch blog: "It plays the same role that Qwen3-Next played for Qwen3.5 — the hybrid Gated DeltaNet + Gated Attention design introduced at that time has since been used across the Qwen3.5, Qwen3.6, Qwen3.7 and Qwen3.8 series. We are again releasing the architectural changes early, so that the community can examine them before the full Qwen4 model family is built on top of them."

In other words, "Next" is Qwen's research-preview branding. The GDN + Gated-Attention design from Qwen3-Next (Sep 2025) was the architecture that powered every Qwen release for the next year. The GDN + QSA + Gated Residual + N-gram Embedding + Muon design from Flash-Next is intended to underpin Qwen4. The "Flash" suffix is the cost-class branding — Qwen3.5-Flash was the hosted name for Qwen3.5-35B-A3B, Qwen3.6-Flash was Qwen3.6-35B-A3B, and Qwen3.8-Flash (the production API SKU behind Flash-Next) continues the pattern. The open weights and the API SKU are not literally the same checkpoint — the API version adds production-only features like 1M context by default and built-in tools — but they share the same architecture.

The strategic significance is hard to overstate. Qwen is shipping real research as production weights, on a one-year cadence, before committing it to a mainline family. By the time Qwen4 arrives, the community will have already stress-tested QSA, Gated Residual, N-gram Embedding, and Muon at scale for months. That is a fundamentally different release philosophy from the "paper ships months after weights" pattern that still dominates most labs.

Architecture Deep Dive

This is the technical core of the post. We will work through the model layer by layer, then look at how training and deployment fit around it. All numerical specs in this section are taken from the official HuggingFace model card for Qwen/Qwen3.8-Flash-Next and cross-checked against the Alibaba Cloud launch blog. Where the public artifacts are silent on a parameter, that is called out explicitly.

5.1 Headline parameters

Flash-Next is best understood as three loosely-coupled parameter pools, only one of which actually does per-token matrix-multiplies:

Table 2 — Headline parameter budget

Pool Params Role In per-token FLOPs?
Main backbone (MoE) 125B GDN + QSA + MoE layers + LM head Yes — but only 6B activated per token (≈4.8% sparsity)
N-gram Embedding table 51B 20M bigram+trigram entries at layer 2 No — deterministic lookup, not a matmul
Multi-Token Prediction head 4B 1 extra layer + LM head for speculative decoding Only during training / spec-decode inference
Total stored ("on disk") ≈180B Sum of the three pools —
Active per token 6B What actually gets computed for a forward pass Yes

The 6B-active number is the one that matters for cost. At 6B activated parameters per token, Flash-Next is in the same compute band as a 6B dense model — but with the knowledge capacity of a 180B store. The 51B N-gram table is the architectural sleight-of-hand that makes this work: it stores an enormous amount of phrase-level knowledge in a form that costs essentially zero compute to query, because the lookup keys are deterministic (current token + preceding tokens) and the result is asynchronously prefetched into GPU memory in parallel with the main forward pass.

5.2 Layer layout — the heart of the architecture

The 48 layers are arranged as 12 macro-blocks of four layers each. Within each macro-block, the structure is:

12 × ( 3 × (Gated DeltaNet → MoE) → 1 × (Qwen Sparse Attention → MoE) )

Across all 48 layers that is 36 GDN layers and 12 QSA layers — a 3:1 GDN-to-attention ratio. Every layer, regardless of type, is followed by a Sparse MoE with identical configuration, and is wrapped by the Gated Residual structure described in section 5.6. The previous Qwen3-Next-80B-A3B (Sep 2025) used the identical macro-block skeleton, but with full Gated Attention in the attention slot instead of QSA, hidden dim 2048 (vs 2560 here), and no N-gram embedding, no Gated Residual, and no Muon. So the macro-block layout is the lineage; the contents of the attention slot and the residual stream are the novelty.

5.3 Gated DeltaNet — linear attention

Gated DeltaNet (GDN) is a linear-attention layer originally introduced in the paper "Gated Delta Networks: Improving Mamba2 with Delta Rule" (arXiv:2502.05246). It compresses the entire history of a sequence into a fixed-size recurrent state and updates that state with a learned gate, so the KV cost does not grow with sequence length. For Flash-Next, which targets 1M-token context, this is the mechanism that keeps prefill tractable on the 36 of every 48 layers that are not QSA.

Table 3 — Gated DeltaNet configuration

Spec Flash-Next Qwen3-Next-80B-A3B (predecessor)
Linear-attention V heads 48 32
Linear-attention QK heads 16 16
Head dimension 128 128
Total GDN layers 36 36

Flash-Next widens the V-head count from 32 to 48 — a 50% increase that roughly tracks the increase in hidden dim (2048 → 2560). The QK head count and head dim are unchanged, which suggests Qwen is scaling the value-projection width without scaling the key/query projection, a pattern that empirically improves expressiveness at modest compute cost.

5.4 Qwen Sparse Attention (QSA) — the headline novelty

This is the single most important architectural change in Flash-Next. The "Gated Attention" of Qwen3-Next was full attention — every query attends to every key, with the standard O(N²) cost. Flash-Next replaces it with Qwen Sparse Attention (QSA), which performs block-level sparse attention with a learned indexer.

Table 4 — Qwen Sparse Attention configuration

Spec Value
Number of Q heads 24
Number of KV heads 2 (grouped-query)
Head dimension 256
RoPE dim (partial rotary) 64 (partial_rotary_factor = 0.25)
Indexer structure MQA with 4 query heads + 1 shared key head
Indexer head dim 128
Budget (per layer) 512 blocks OR 2,048 tokens
Total QSA layers 12 (one per macro-block)

How QSA differs from prior sparse attention

Most modern sparse-attention schemes (DeepSeek's DSA, NSMA-style learned sparse attention, MoBA) operate at the token level — the indexer picks which individual token positions to attend to. As context grows, the indexer itself becomes a non-negligible source of compute. QSA takes a different approach: it first aggregates the sequence into "micro-blocks," estimates importance at the block level (not the token level), then selects the most relevant blocks for full attention within that layer. The result is that attention cost grows with the budget (a fixed 512 blocks per layer), not with sequence length.

Crucially, QSA compresses independently within each layer rather than sharing indices across layers (as in IndexCache-style cross-layer reuse). The Qwen team's stated reason is that this makes QSA well-suited to hybrid architectures where GDN and attention layers are interleaved — because GDN's recurrent state does not produce a usable index for the next attention layer, cross-layer index reuse breaks down in a hybrid layout. Per-layer compression is the price you pay for a hybrid that actually works.

Design intent "GDN efficiently 'remembers,' while QSA precisely 'retrieves.'" — Alibaba Cloud launch blog. The two-layer-type split is not accidental: GDN handles the long-tail history compression, QSA handles targeted retrieval of the parts that matter for the current token. This division of labor is the central design thesis of the architecture.

Reported speedups

The QSA attention kernel is the headline throughput story. Qwen reports up to 7.6× prefill and 4.9× decode speedup versus full attention at 1M-token context (kernel-level micro-benchmark, vendor-reported). In a high-cache-reuse online-serving scenario at 90% prefix-cache hit rate, Flash-Next hits 8.6× the prefill throughput of Qwen3.7-Plus at 1M context. The SGLang cookbook cites 10.2× and the vLLM recipe cites 6.6× — but these measure different things (kernel vs end-to-end, different frameworks, different baselines), so the numbers are not directly comparable across bars. Treat all of them as preliminary until independent measurement exists.

5.5 Sparse Mixture-of-Experts

Every layer — whether GDN or QSA — is followed by a Sparse MoE with identical configuration:

Table 5 — Sparse MoE configuration

Spec Value
Total experts 512
Routed experts per token 10
Shared experts 1
Expert intermediate dim 640
Activation ratio ≈2% of experts per token (10/512)
Load balancing Global (not per-batch)

Qwen3-Next-80B-A3B used the same 512-expert / 10-routed + 1-shared topology, but with a narrower expert_intermediate dim of 512. Flash-Next widens each expert's FFN to 640, which combined with the wider hidden dim (2560 vs 2048) gives each expert materially more capacity per activation. The blog explicitly attributes the choice to global load balancing: "With global load balancing, increasing total expert parameters while keeping the number of activated experts fixed steadily reduces training loss." The implication is that Qwen sees expert-count scaling as a more efficient axis than per-token active-param scaling — a stance that aligns with the broader industry trend toward ultra-fine-grained MoE.

5.6 Gated Residual — the second novel component

Traditional Transformers read and write to a single residual stream. Flash-Next widens that stream into 4 parallel branches with an element-wise, data-dependent read gate (per-token, per-channel) and a per-branch scalar write gate. The configuration:

Table 6 — Gated Residual configuration

Spec Value
Number of branches 4
Bottleneck rank 320
Read gate Element-wise, data-dependent (per-token, per-channel)
Write gate Per-branch scalar
Residual state dtype FP8 (cuts memory traffic)

Qwen describes Gated Residual as a combination of two prior ideas: Hyper-Connection (Sun et al., arXiv:2409.19606) — multi-branch residual widening — and GatedNorm (arXiv:2504.16086) — element-wise dynamic gating in the residual read. Empirically, Qwen reports that one of the four branches spontaneously becomes a long-range pathway linking the first attention layer to most middle and later layers. The Gate also "effectively suppresses activation outliers and improves training stability" — a non-trivial claim, because activation outliers are the dominant reason FP8 training of large MoE models is hard. Storing the residual state in FP8 cuts memory traffic proportionally, which matters more for memory-bound decode than for compute-bound prefill.

Gated Residual simplifies Hyper-Connection by dropping the extra branch-mixing operations once the read/write gates are expressive enough to do that mixing implicitly. The result is a wider, more stable residual stream at lower implementation complexity than the original Hyper-Connection design.

5.7 N-gram Embedding — the third novel component

This is the architectural choice that has drawn the most community attention, because it is the most obviously local-friendly. The configuration:

Table 7 — N-gram Embedding configuration

Spec Value
Table size 20,000,000 entries (bigrams + trigrams)
Insertion point Layer 2 (near the start of the network)
Total params in table 51B
Compute per token Effectively zero (deterministic lookup, no matmul)
Offload target Host system RAM, asynchronously prefetched
Offload platform support NVIDIA-only (as of release)

A standard token embedding looks up a vector based on a single token. An N-gram embedding looks up a vector based on the current token plus several preceding tokens (bigrams and trigrams in this case), providing ready-made representations for common phrases and local patterns. The 51B parameters are deterministically addressed — the lookup location is fully known in advance from the token sequence — so they do not enter the per-token matrix-multiply FLOPs budget. Because the lookup is deterministic, the table can be stored in host RAM (not GPU memory) and asynchronously prefetched in parallel with model compute. This is a parameter scaling axis that is far cheaper than adding MoE experts, because it does not require a single additional FLOP of GPU compute.

Reddit user pmv143 estimated that an ideal 4-bit quant of Flash-Next lands around 82 GB total (58 GB main weights + 24 GB N-gram tables), with real-world quants in the 80–90 GB range. This is the "local-friendly" angle: the bulk of the model (the N-gram table) is sparsely accessed and ideal for system-RAM offload. The concept is not new — it is inspired by Per-Layer Embedding in Gemma 3n and by DeepSeek's "Engram" work (arXiv:2507.13028, Conditional Memory via Scalable Lookup). DeepSeek's contribution was the demonstration that this idea works at scale; Qwen's contribution is productionizing it at 51B params and making it the centerpiece of a cost-tier model.

Community framing The 51B N-gram table is the architectural decision that lets a 6B-active model punch like a much larger one. It is essentially a giant cheat sheet for common short patterns, freeing the sparse 6B-active backbone to focus on harder reasoning. — synthesized from r/LocalLLaMA coverage

5.8 Multi-Token Prediction (MTP)

Flash-Next ships a 4B MTP head — one extra layer plus a duplicate LM head — that predicts multiple future tokens in a single forward pass. The configuration:

Table 8 — MTP configuration

Spec Value
MTP layers 1
MTP params 4B
Attention type in MTP QSA (replaces full attention used in Qwen3-Next)
Training mode Multi-step (training and inference consistent)
vLLM flag --speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}'
SGLang flag --speculative-algo NEXTN --speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4

MTP improves speculative-decoding acceptance rate in real serving scenarios and also improves backbone performance during training (the multi-token objective acts as a regularizer on the main trunk's hidden states). The MTP module is opt-in at inference time — if you do not pass the speculative-config flags, it simply is not invoked. Note that the MTP head uses QSA, the same sparse attention as the main backbone, which keeps the spec-decode path cheap.

5.9 Positional encoding, vocab, and vision encoder

Positional encoding is RoPE with rope_theta = 10,000,000, partial rotary factor 0.25 (RoPE dim 64 in the QSA heads). For vision/text fusion the model uses mrope_interleaved = true with mrope_section = [11, 11, 10] — multimodal RoPE sections for time / height / width. Native context is 262,144 tokens; YaRN extension to 1,000,000 with factor = 4.0 and original_max_position_embeddings = 262144. The blog warns that users should pick a smaller factor (e.g., 2.0 for 524K) when possible, because static YaRN can hurt short-prompt quality.

The padded vocabulary is 248,320 — both the LM head and the token embedding are padded to this size. The tokenizer is the same BPE family as Qwen3 / Qwen3.5 (~151k base tokens), with padding to 248,320 done for alignment reasons that the public artifacts do not fully explain. Flash-Next does not document a brand-new tokenizer; it inherits the Qwen3 tokenizer's coverage of 100+ languages.

The model is multimodal — text + image + video in, text out — and the HF card lists the architecture string as qwen4_exp. The vision encoder and multimodal fusion details are not fully spelled out in the public artifacts, but the recommended video_preprocessor_config.json longest_edge of 469,762,048 (corresponding to 224k video tokens) suggests heavy video-frame sampling for hour-scale video understanding. The processor is loaded as AutoProcessor returning multimodal inputs.

5.10 Architecture diagram

Figure 1 — Qwen3.8-Flash-Next architecture schematic. Macro-block layout (12 × [3×GDN+MoE → 1×QSA+MoE]), with N-gram embedding at layer 2 and Gated Residual wrapping every layer. Training-side annotations on the right.

5.11 Stability optimizations — carried over from Qwen3-Next

Three stability techniques first introduced in Qwen3-Next-80B-A3B are reused here without modification:

These are not new, but they are non-obvious — most production MoE training recipes do not use all three together. The fact that Qwen carries them forward from Qwen3-Next suggests they are doing real work.

What Changed vs Previous Qwen Models

Flash-Next is best understood as a delta on top of Qwen3-Next-80B-A3B (September 2025), with a secondary comparison to Qwen3.7-Plus — the direct cost competitor Qwen is benchmarking against. This section walks through those deltas explicitly. The original Qwen3 (April–May 2025) and Qwen2.5 are mentioned only briefly because they are now sufficiently far behind that the comparison is mostly historical.

6.1 Delta vs Qwen3-Next-80B-A3B (Sep 2025) — the direct predecessor

This is the comparison that matters. Flash-Next is the second-generation "Next" model and the direct successor to Qwen3-Next-80B-A3B. The macro-block layout is identical; everything inside the macro-blocks has been redesigned.

Table 9 — Component-by-component delta vs Qwen3-Next-80B-A3B

Component Qwen3-Next-80B-A3B (Sep 2025) Qwen3.8-Flash-Next (Aug 2026)
Total main params 80B 125B
Active params 3B 6B
Hidden dim 2,048 2,560
Expert intermediate dim 512 640
Layer count 48 48 (same)
Attention type Gated Attention (full) Qwen Sparse Attention (block-level, budget 512 blocks / 2048 tokens)
GDN V heads 32 48
N-gram Embedding None 51B params, 20M-entry bigram/trigram table at layer 2
Residual structure Standard residual stream Gated Residual — 4 branches, bottleneck rank 320, FP8 state
MTP attention Full attention QSA (same as backbone)
Optimizer AdamW (assumed) Muon for 2D linear maps + AdamW for embeddings/router/low-rank GR
Batch-size warmup Standard practice Eliminated (saves 18.8% optimizer steps)
Scaling law Standard Refitted for new arch + Muon
Modality Text-only Multimodal (text + image + video)
Context (native) 262,144 262,144 (same)
Context (YaRN-extended) 1,010,000 1,000,000
Vocab (padded) ~151k 248,320
Architecture string qwen3_next qwen4_exp
License Apache-2.0 qwen-community-1.0

Six changes stand out as architecturally meaningful. First, the swap from full Gated Attention to QSA is the single largest compute win — it is what makes 1M-token context actually servable. Second, the addition of the 51B N-gram embedding table adds enormous knowledge capacity at near-zero compute cost. Third, the Gated Residual widens the residual stream and (per Qwen) suppresses the activation outliers that make FP8 training hard. Fourth, the Muon + AdamW split optimizer roughly doubles FLOPs efficiency per step on the 2D-linear-map parameters. Fifth, the elimination of batch-size warmup is a direct 18.8% optimizer-step reduction. Sixth, the multimodal extension is a meaningful product-surface expansion — Qwen3-Next was text-only.

6.2 Delta vs Qwen3.7-Plus — the direct cost competitor

Qwen's marketing positions Flash-Next as comparable to Qwen3.7-Plus at roughly 1/9 the training cost, with stronger coding and office-task performance. The numbers bear this out for the agentic-coding and office-task suites, though Flash-Next does still lose on a couple of benchmarks.

Table 10 — Capability delta vs Qwen3.7-Plus

Metric Qwen3.7-Plus Qwen3.8-Flash-Next Direction
Total params 397B 125B Flash-Next smaller (3.2×)
Active params 17B 6B Flash-Next smaller (2.8×)
N-gram params — 51B Flash-Next adds new axis
Training cost 1× ~1/9× Flash-Next cheaper (vendor-reported)
CoWorkBench 65.1 73.9 Flash-Next wins (+8.8)
JobBench 27.6 55.7 Flash-Next wins (+28.1, ~2×)
SWE-bench Pro 55.8 62.5 Flash-Next wins (+6.7)
GPQA Diamond 90.3 91.7 Flash-Next wins (+1.4, near saturated)
HLE 34.7 35.9 Flash-Next wins (+1.2, near saturated)
LiveCodeBench v6 89.6 91.9 Flash-Next wins (+2.3)
DeepSWE 1.1 16.5 58.7 Flash-Next wins (+42.2, ~3.6×)

The DeepSWE 1.1 jump from 16.5 to 58.7 is the single most striking number on this table — it suggests that the architectural improvements compound particularly strongly on agentic-coding harnesses that require long-horizon tool use. JobBench doubling (27.6 → 55.7) is the second-most striking. The near-saturated deltas on GPQA, HLE, and LiveCodeBench v6 (all <3 points) are real but small enough that they may be within run-to-run variance.

6.3 Delta vs original Qwen3 and Qwen2.5

Qwen3 (April–May 2025, tech report arXiv:2505.09388) used standard full attention throughout, no GDN, no QSA, no Gated Attention, standard residual stream, and AdamW throughout. Its 36T-token pretraining corpus was the basis for Qwen3-Next's 15T-token subset. Versus Flash-Next: hybrid GDN+QSA, Gated Residual, N-gram Embedding, Muon optimizer, refitted scaling law, no batch warmup — a wholesale architectural overhaul.

Qwen2.5 was a standard dense/MoE Transformer with none of the Next-line components. Versus Flash-Next the gap is even larger. The interesting historical note is that the Qwen3-Next release in September 2025 was the inflection point — that is when Qwen committed to the hybrid linear-attention + sparse-attention direction that Flash-Next now refines.

6.4 Removed or redesigned components (summary)

For the reader who wants a quick checklist of what was deleted or replaced in the move from Qwen3-Next to Flash-Next:

Figure 2 — Architectural delta: Qwen3-Next-80B-A3B → Qwen3.8-Flash-Next. Bars are normalized within each pair so all categories share a 0–100 axis; raw values are shown at bar ends.

Benchmarks: Where Flash-Next Wins, Ties, and Loses

Every number in this section is vendor self-reported, taken from the official HuggingFace model card and the Ollama library page that mirrors it. Independent verification by third-party benchmarking hubs is still in progress — BenchLM classifies the Flash-Next profile as "not yet verified" at the time of writing. The model is one day old. Treat every number as provisional.

7.1 Language and agentic benchmarks

The benchmark suite Qwen chose to report is heavily weighted toward agentic coding and office tasks — areas where Flash-Next clearly wins. Less coverage is given to traditional language-understanding benchmarks (MMLU, MMLU-Pro, AIME, IFEval, BFCL), which the predecessor Qwen3-Next-80B-A3B reported but Flash-Next does not. That omission is itself a data point: Qwen is positioning Flash-Next as an agentic model, not a general-knowledge model.

Table 11 — Language & agentic benchmarks (self-reported)

Benchmark Flash-Next Qwen3.8-27B Qwen3.7-Plus DeepSeek-V4-Flash Claude Opus 4.6
Total params 125B 27B 397B 284B —
Active params 6B 27B 17B 13B —
Agentic coding [Please fill in] [Please fill in] [Please fill in] [Please fill in] [Please fill in]
DeepSWE 1.1 58.7 42.2 16.5 54.4 —
SWE-bench Pro 62.5 61.7 55.8 56.0 53.4
SWE-bench Multilingual 81.0 73.8 75.8 — 77.5
NL2Repo-Bench 48.1 42.3 41.1 54.2 47.6
Agentic tasks [Please fill in] [Please fill in] [Please fill in] [Please fill in] [Please fill in]
CoWorkBench 73.9 70.7 65.1 45.1 68.2
JobBench 55.7 33.4 27.6 41.3 36.6
Agents' Last Exam (Pass@1) 24.3 20.4 13.2 25.2 —
Agents' Last Exam (Score) 51.2 42.9 33.6 — —
Toolathlon Verified (Pass@1) 73.5 67.1 50.6 70.3 —
General [Please fill in] [Please fill in] [Please fill in] [Please fill in] [Please fill in]
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

Figure 3 — Agentic coding, office tasks, and reasoning benchmarks. Flash-Next wins on agentic and office suites, ties on near-saturated ceilings (GPQA, LiveCodeBench v6), and loses on HLE and NL2Repo-Bench. Missing bars = no published score for that model/benchmark combination.

Wins worth calling out

DeepSWE 1.1 at 58.7 is the headline win — that is +42.2 over Qwen3.7-Plus and +4.3 over DeepSeek-V4-Flash-0731, on a benchmark that requires real multi-step agentic coding with tool use. SWE-bench Pro at 62.5 beats Claude Opus 4.6 Max (53.4) by nearly 10 points, which is a notable upset for a model in this price tier. CoWorkBench 73.9 and JobBench 55.7 are both roughly 2× the Qwen3.7-Plus baseline. Toolathlon Verified 73.5 is a strong tool-use score.

Losses worth calling out

NL2Repo-Bench 48.1 vs DeepSeek-V4-Flash-0731's 54.2 is a -6.1 regression on repo-level code generation — llm-stats calls this out explicitly: "NL2Repo 48.1 vs 54.2 is the miss; say it out loud." HLE 35.9 vs Claude Opus 4.6 Max's 40.0 is the frontier-reasoning gap, and Agents' Last Exam Pass@1 24.3 vs DeepSeek's 25.2 is a wash but technically a loss. The near-saturated coding and math ceilings (GPQA Diamond 91.7 vs 90.8 / 91.3, LiveCodeBench v6 91.9 vs 90.6 / 88.8) are real but small enough that llm-stats calls them "noise on a crowded ceiling."

7.2 Vision and multimodal benchmarks

This is the area where the gaps between Flash-Next and its competitors are widest. On AndroidWorld, RealWorldQA, MathVision (with code interpreter), and CharXiv RQ (with code interpreter), Flash-Next is 10–20 points ahead of every alternative Qwen reports against. Claude Opus 4.6 Max trails particularly badly on embodied and document tasks.

Table 12 — Vision & multimodal benchmarks (self-reported)

Benchmark Flash-Next Qwen3.8-27B Qwen3.7-Plus Claude Opus 4.6
ClawEval-MM (Pass@3) 64.4 57.4 57.4 52.5
ClawEval-MM (Average) 60.4 56.9 60.1 54.7
RecreationBench 49.9 47.1 30.2 —
AndroidWorld 84.5 81.9 81.0 62.0
OSWorld 2.0 (Binary) 19.4 19.4 2.8 —
OSWorld 2.0 (Partial) 52.3 48.0 21.5 —
Vision2Web 64.0 62.9 42.1 —
ERQA (embodied) 72.3 65.5 69.8 40.8
LVBench (long video) 76.6 72.4 76.2 63.0
RealWorldQA 88.5 85.9 86.9 73.9
MathVision (without CI) 90.6 90.0 90.3 65.5
MathVision (with CI) 95.7 94.6 88.7 —
CharXiv RQ (without CI) 84.6 83.7 85.8 66.0
CharXiv RQ (with CI) 90.6 90.2 85.9 —

Figure 4 — Multimodal and embodied benchmarks. Flash-Next dominates AndroidWorld, MathVision (with CI), CharXiv RQ (with CI), RecreationBench, and ERQA. OSWorld 2.0 binary is the obvious weak spot (19.4%).

The OSWorld 2.0 binary score of 19.4 deserves explicit attention. "Binary" means the percentage of tasks where the model achieved full reward — partial credit is tracked separately (Flash-Next scores 52.3 on partial). 19.4% binary success on full computer-use is essentially a coin flip; the model can make progress on most tasks but rarely completes them perfectly. Claude Opus 4.6 Max does not publish a comparable number, but the absolute level is the honest framing: Flash-Next is not yet a drop-in computer-use agent.

7.3 Base-model benchmarks

Per the Alibaba Cloud blog, Flash-Next-Base (the pre-instruction-tuned checkpoint) with 6B activated tops 8 of 14 base-model benchmarks, including MMLU-Pro, SuperGPQA, BBH, GSM8K, EvalPlus, SWEBench-Pretrain, MGSM, and MMMLU. It remains close to Qwen3.7-Plus-Base on MMLU, MMLU-Redux, GPQA, MATH, and MultiPL-E. The blog does not enumerate the full 14-benchmark list publicly, so the 8-of-14 claim cannot be independently verified beyond those eight names — a transparency gap worth flagging.

7.4 Speed, throughput, and cost

The throughput story is what justifies the "Flash" branding. The QSA attention kernel is reported to deliver up to 7.6× prefill and 4.9× decode speedup versus full attention at 1M-token context (kernel-level micro-benchmark). In a high-cache-reuse online-serving scenario at 90% prefix-cache hit rate, Flash-Next is reported to hit 8.6× the prefill throughput of Qwen3.7-Plus at 1M context. The SGLang cookbook cites 10.2× end-to-end and the vLLM recipe cites 6.6× — but as noted in section 5.4, these measure different things and are not directly comparable.

Table 13 — Speed, throughput, and cost (vendor-reported)

Metric Value Source
QSA attention kernel prefill speedup @ 1M ctx up to 7.6× vs full attn Alibaba blog
QSA attention kernel decode speedup @ 1M ctx up to 4.9× vs full attn Alibaba blog
Prefill throughput vs Qwen3.7-Plus @ 1M ctx 8.6× (at 90% cache hit) Alibaba blog
SGLang cookbook speedup 10.2× marktechpost
vLLM recipe speedup 6.6× marktechpost
API input price (qwen3.8-flash) $0.16 / M tokens Qwen tweet
API output price $0.47 / M tokens Qwen tweet
Price gap vs Qwen3.8-Max ($2.00 / $6.00) ~12× cheaper both axes The Decoder

Figure 5 — Left: speedup claims, with the caveat that different bars use different baselines and workloads. Right: API pricing on a log scale — Flash-Next is roughly 12× cheaper than Qwen3.8-Max and 30–50× cheaper than Claude Opus 4.6 Max on output tokens.

The Decoder summarizes the strategic implication: "Flash-Next performs just below the flagship but costs about one-twelfth as much, with a roughly 12× price gap on both input and output tokens." On a pure $/M basis, this is unmatched in the open-weight MoE market at the time of writing. On a $/task basis the comparison is messier, because DeepSeek-V4-Flash-0731 has a different active-param count and may be competitive on workloads where it is close to Flash-Next on quality (e.g., NL2Repo-Bench).

7.5 Independent rankings (limited)

BenchLM ranks Flash-Next at #25 of 226 overall (67.5 / 100 composite). Category ranks (verified): Agentic #13 of 138 (91st percentile), Coding #32 of 144 (78th percentile), Instruction Following #10 of 42 (78th percentile). Knowledge, Math, Multilingual, and Multimodal categories have published rows but are "not ranked" due to insufficient coverage (24 source-displayable rows). OpenRouter, LiveBench, lmarena, and artificialanalysis.ai do not yet have Flash-Next-specific entries at the time of writing — the model is too new. The predecessor Qwen3-Next-80B-A3B-Instruct on OpenRouter shows a weighted average price of $0.097 / $1.079 per M tokens across providers, with throughput of 73 tok/s P50 and latency of 0.48s P50 — but those numbers are for the older model, not Flash-Next.

Training Recipe: Muon, Scaling-Law Refit, No Warmup

The training-side changes are as architecturally significant as the model-side ones. Three things in particular deserve attention: the Muon + AdamW optimizer split, the refitted scaling law, and the elimination of batch-size warmup. Together they account for a large fraction of the claimed ~9× cost reduction versus Qwen3.7-Plus.

8.1 The Muon + AdamW optimizer split

Muon (Jordan et al., kellerjordan.github.io/posts/muon) is an optimizer designed specifically for parameters that "genuinely act as two-dimensional linear maps" — i.e., weight matrices that multiply a vector. It performs orthogonalization on the gradient update before applying it, which empirically gives roughly 2× FLOPs efficiency over AdamW on the parameters it applies to (per independent benchmarks). Flash-Next uses Muon for:

AdamW is retained for the parameters that do not fit the 2D-linear-map assumption:

For fused parameter matrices — QKV, SwiGLU, and the GDN projections — Qwen splits them along the independent linear transformations they represent, then performs Muon orthogonalization separately on each piece. This is a non-trivial implementation detail: a naive application of Muon to a fused QKV matrix would orthogonalize across all three sub-projections at once, which is mathematically wrong. Splitting first ensures each sub-projection gets its own correct orthogonalization.

Qwen reports three specific Muon refinements in Flash-Next: (1) orthogonalization accuracy improvements, (2) the parameter-assignment split above, and (3) the fused-parameter splitting. None of these are earth-shattering individually, but together they represent the first production-quality Muon deployment at this scale.

8.2 Refitted scaling law

Scaling laws are not universal — they depend on the architecture and the optimizer. When you change both (GDN + QSA + GR + N-gram + Muon is a substantial change from standard Transformer + AdamW), the old scaling law no longer predicts loss accurately. Qwen refit the scaling law for the new architecture. The result, per the blog, is that the model can stably use larger learning rates and batch sizes — improving both convergence efficiency and large-scale parallel training throughput. The exact functional form of the refitted law is not published, which is a transparency gap, but the empirical claim (stable training at larger LR and batch) is verifiable from the model's existence.

8.3 Batch-size warmup eliminated

This is the most surprising single claim in the training recipe. Batch-size warmup — gradually increasing from a small batch to the target batch over the first portion of training — is standard practice in large-model training, on the theory that it stabilizes early optimization. Qwen's finding inverts that:

Direct quote "We also find that Batch Size Warmup, a common practice in large-scale model training, is no longer necessary: gradually increasing from a small Batch to the target Batch does not improve the final result, but instead requires 18.8% more optimizer steps. In the final training Recipe, we therefore start directly with the target Batch Size." — Alibaba Cloud launch blog

An 18.8% optimizer-step reduction is a significant cost saving on a training run of this size. The mechanism is not fully explained in the public artifacts — the most plausible hypothesis is that the Muon optimizer's orthogonalization step makes early-training stability less sensitive to batch size than AdamW does. If true, this would be a meaningful secondary benefit of Muon that has not been widely appreciated. Independent reproduction by other large-model training teams would settle the question.

8.4 Pretraining data

For Flash-Next specifically, Qwen does not publish an exact pretraining-token count in the public artifacts. For the predecessor Qwen3-Next-80B-A3B, the HF card states "Pretraining (15T tokens)" — a subset of Qwen3's 36-trillion-token pretraining corpus. Flash-Next's pretraining is presumably similar in spirit (a refitted-scaling-law-sized subset of the Qwen3.5 / Qwen3.7 / Qwen3.8 corpus) but the exact number is not in the public card. This is a transparency gap relative to the predecessor.

What is disclosed:

8.5 Post-training

Flash-Next is described in the card as a post-trained model with both thinking and instruct modes. Thinking is on by default; it can be disabled per request. Reasoning depth is tunable via the reasoning_effort parameter, which takes the values xhigh (default), medium, or low. The card also describes a preserve_thinking toggle that retains thinking content across conversation history — useful for agentic consistency.

For the predecessor Qwen3-Next-80B-A3B, post-training used GSPO (Group Sequence Policy Optimization) for the Thinking variant, specifically cited as solving the stability challenges of RL with hybrid attention + high-sparsity MoE. Flash-Next does not specify which RL algorithm is used in its post-training — GSPO is the Qwen house standard, so it is presumably reused or refined. This is another transparency gap.

8.6 Tokenizer training data

Not separately documented for Flash-Next. The Qwen3 tokenizer is BPE-based with ~151k base tokens (extended to a padded 248,320 in Flash-Next's config for alignment reasons that are not publicly explained). Qwen3 covers 100+ languages natively; Qwen3.5 expanded to 201 languages and dialects. Flash-Next inherits this coverage without documented changes.

8.7 Stability optimizations (retained)

Three techniques first introduced in Qwen3-Next are carried forward unchanged — see section 5.11 for the list. The fact that these are retained across a major architectural overhaul is meaningful evidence that they are doing real work, because the easier path would have been to drop them along with everything else that changed.

Deployment & Engineering

This section covers everything you need to actually run Flash-Next in production or locally: on-disk sizes, VRAM requirements, quantization options, supported frameworks, API endpoints, and recommended sampling parameters. The short version: FP8 wants a multi-GPU node, 4-bit GGUF is the local-friendly path on 128 GB-class unified memory, and day-0 ecosystem support is unusually broad.

9.1 On-disk sizes

Table 14 — On-disk size by precision

Precision Size Source / notes
BF16 335.28 GiB Official Qwen BF16 checkpoint
FP8 172.78 GiB Official Qwen FP8 checkpoint; production precision on Hopper / Blackwell
4-bit GGUF (Unsloth Dynamic) ~82 GB (58 GB main + 24 GB n-gram) Unsloth UD-Q4_K_XL
Real-world 4-bit quants 80–90 GB range Reddit pmv143 estimate

9.2 VRAM and hardware requirements

The FP8 path is the production-grade one. The minimum validated configuration is TP2 on GB300, with TP4 recommended for throughput. On an 8×H200 node, you must use TEP8 — TP8 is incompatible with the checkpoint's 128-wide quantization blocks. This is a non-obvious gotcha that has bitten early adopters; if you naively launch with --tensor-parallel-size 8 on H200s, you will get a quantization-block-alignment error rather than a graceful fallback.

The 4-bit path is the local-friendly one. At ~82 GB total memory, Flash-Next fits on 128 GB-class unified-memory systems with the N-gram table offloaded to system RAM. Community-validated targets include Mac Studio 128 GB, DGX Spark, Strix Halo 128 GB, RTX 5090 + 96 GB DDR5, and RTX 3090 + 96 GB DDR5. The 51B N-gram table is the "offload-friendly" angle — it can sit in system RAM and be asynchronously prefetched (currently NVIDIA-only, per the marktechpost write-up). A user on r/LocalLLaMA reports running it on "8 gig VRAM and 48 gig RAM" — clearly heavily offloaded, and not a speed claim, but a sign that the offload path works at the extreme end.

Deployment gotcha TP8 is incompatible with Flash-Next's 128-wide quantization blocks on 8×H200. Use TEP8 (tensor-expert parallel) instead. This is the most common deployment gotcha in the first 24 hours of release.

9.3 Quantization options

The quantization ecosystem is broad at launch, reflecting heavy day-0 collaboration with Unsloth and the broader open-source inference community:

9.4 Supported frameworks

Day-0 framework support is unusually broad — most major inference stacks had Flash-Next support within hours of weight release:

Table 15 — Framework support

Framework Status Notes
HuggingFace Transformers Supported (main branch) arch string qwen4_exp; pip install git+https://github.com/huggingface/transformers.git@main
vLLM Supported --tensor-parallel-size 4 --max-model-len 262144 --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder
SGLang Supported --tp-size 4 --context-length 262144 --reasoning-parser qwen3 --tool-call-parser qwen3_coder
TokenSpeed Supported Same flags as vLLM / SGLang; newer engine
llama.cpp Supported (with PR) Specific PR needed for gated DeltaNet; Unsloth's bundled fork is the easiest path
MLX (Apple Silicon) Supported via mlx-vlm Original checkpoints compatible
Ollama Supported ollama run qwen3.8-flash-next
Unsloth Supported (Studio + GGUFs + NVFP4) Day-0 support; Daniel Han confirmed
LM Studio Supported GGUF format
Docker Model Runner Supported docker model run hf.co/Qwen/Qwen3.8-Flash-Next
KTransformers Mentioned in HF card For high-throughput production
Transformers serve CLI Supported transformers serve Qwen/Qwen3.8-Flash-Next --port 8000 --continuous-batching

For comparison, Qwen3-Next (Sep 2025) needed sglang >= 0.5.2 or vllm >= 0.10.2. Flash-Next presumably needs newer versions — the recipe commands above are from the GitHub repo and reflect current main-branch behavior of each framework.

9.5 API endpoints

QwenCloud (production) serves Flash-Next under the SKU name qwen3.8-flash. Three regional endpoints:

The endpoints support OpenAI Chat Completions, OpenAI Responses API, and an Anthropic-compatible interface — which means it works with Claude Code directly. Pricing is $0.16 / $0.47 per M tokens. Context is 1M by default in the production API. Tool calling uses native built-in tools. Integration partners at launch include Claude Code (via Anthropic protocol), OpenAI Codex (via Responses protocol), Qoder CLI, Qwen Code, OpenClaw, and QwenWork (which powers the new "Standard" mode).

9.6 Recommended sampling parameters

The HF card distinguishes two sampling regimes: thinking mode (default) and instruct (non-thinking) mode. Both use temperature = 1.0 and top_p = 0.95 as starting points, but they diverge on presence_penalty and reasoning_effort.

Thinking mode (default)

temperature = 1.0

top_p = 0.95

top_k = 20

min_p = 0.0

presence_penalty = 0.0

repetition_penalty = 1.0

reasoning_effort = "xhigh" # default; also: medium, low

Instruct (non-thinking) mode

temperature = 1.0 -> 0.7

top_p = 0.95 -> 0.80

top_k = 20

min_p = 0.0

presence_penalty = 1.5

repetition_penalty = 1.0

enable_thinking = False

Recommended max output: 262,144 tokens for reasoning content + 131,072 for final response, within the 1M context. The card also notes that presence_penalty between 0 and 2 reduces endless repetition, but high values can cause "language mixing" and a slight performance drop. For long-horizon agentic tasks: "lower reasoning effort does not always reduce overall task completion time. Although it may produce faster per-turn responses, it can also lead to insufficient analysis, more failures, and repeated retries, which may increase total latency and token consumption."

Hands-on Code

This section is a runnable reference. All snippets are taken from or patterned on the official HuggingFace model card, the Qwen3.8-Flash-Next GitHub repo, and the Unsloth documentation. Where a snippet has been adapted for clarity, that is noted.

10.1 HuggingFace Transformers — multimodal inference

The simplest path. The pipeline API handles the multimodal preprocessor for you:

from transformers import pipeline

pipe = pipeline("image-text-to-text", model="Qwen/Qwen3.8-Flash-Next")

messages = [

{

"role": "user",

"content": [

{"type": "image",

"url": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/p-blog/candy.JPG"},

{"type": "text", "text": "What animal is on the candy?"}

]

},

]

print(pipe(text=messages))

Direct load — gives you more control over generation:

from transformers import AutoProcessor, AutoModelForMultimodalLM

processor = AutoProcessor.from_pretrained("Qwen/Qwen3.8-Flash-Next")

model = AutoModelForMultimodalLM.from_pretrained(

"Qwen/Qwen3.8-Flash-Next", device_map="auto"

)

messages = [

{"role": "user", "content": [

{"type": "image", "url": "https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/p-blog/candy.JPG"},

{"type": "text", "text": "What animal is on the candy?"}

]}

]

inputs = processor.apply_chat_template(

messages, add_generation_prompt=True, tokenize=True,

return_dict=True, return_tensors="pt",

).to(model.device)

outputs = model.generate(**inputs, max_new_tokens=40)

print(processor.decode(outputs[0][inputs["input_ids"].shape[-1]:]))

Or use the new transformers serve CLI for an OpenAI-compatible server:

transformers serve Qwen/Qwen3.8-Flash-Next --port 8000 --continuous-batching

10.2 vLLM serving

Production serving with vLLM. The flags below are the recommended baseline:

vllm serve Qwen/Qwen3.8-Flash-Next \

--port 8000 \

--tensor-parallel-size 4 \

--max-model-len 262144 \

--reasoning-parser qwen3 \

--enable-auto-tool-choice \

--tool-call-parser qwen3_coder

With MTP speculative decoding — the recommended config for latency-sensitive workloads:

vllm serve Qwen/Qwen3.8-Flash-Next \

--port 8000 \

--tensor-parallel-size 4 \

--max-model-len 262144 \

--reasoning-parser qwen3 \

--enable-auto-tool-choice \

--tool-call-parser qwen3_coder \

--speculative-config '{"method":"qwen3_next_mtp","num_speculative_tokens":2}'

10.3 SGLang serving

SGLang is the recommended framework for the highest throughput numbers in the launch blog. Baseline:

sglang serve \

--model-path Qwen/Qwen3.8-Flash-Next \

--port 8000 \

--tp-size 4 \

--context-length 262144 \

--reasoning-parser qwen3 \

--tool-call-parser qwen3_coder

With MTP speculative decoding:

python -m sglang.launch_server \

--model-path Qwen/Qwen3.8-Flash-Next \

--port 30000 --tp-size 4 --context-length 262144 \

--reasoning-parser qwen3 --tool-call-parser qwen3_coder \

--speculative-algo NEXTN \

--speculative-num-steps 3 \

--speculative-eagle-topk 1 \

--speculative-num-draft-tokens 4

10.4 Tool / function calling (OpenAI-compatible)

This snippet shows streaming with the reasoning_effort parameter and preserve_thinking toggle. It works against any OpenAI-compatible endpoint (vLLM, SGLang, QwenCloud):

from openai import OpenAI

client = OpenAI() # OPENAI_BASE_URL and OPENAI_API_KEY set via env

messages = [

{"role": "user", "content": "Write a Python function to merge two sorted linked lists."},

]

completion = client.chat.completions.create(

model="Qwen/Qwen3.8-Flash-Next",

messages=messages,

extra_body={

"chat_template_kwargs": {

"enable_thinking": True, # on by default

"preserve_thinking": True, # on by default

},

},

reasoning_effort="xhigh", # xhigh | medium | low

stream=True,

stream_options={"include_usage": True},

)

reasoning_content = ""

answer_content = ""

is_answering = False

print("\n" + "=" * 20 + "Reasoning" + "=" * 20 + "\n")

for chunk in completion:

if not chunk.choices:

print("\nUsage:", chunk.usage)

continue

delta = chunk.choices[0].delta

if hasattr(delta, "reasoning_content") and delta.reasoning_content is not None:

if not is_answering:

print(delta.reasoning_content, end="", flush=True)

reasoning_content += delta.reasoning_content

elif hasattr(delta, "reasoning") and delta.reasoning is not None:

if not is_answering:

print(delta.reasoning, end="", flush=True)

reasoning_content += delta.reasoning

if hasattr(delta, "content") and delta.content:

if not is_answering:

print("\n" + "=" * 20 + "Answer" + "=" * 20 + "\n")

is_answering = True

print(delta.content, end="", flush=True)

answer_content += delta.content

For richer agentic use, the predecessor's Qwen-Agent + MCP pattern carries over:

from qwen_agent.agents import Assistant

llm_cfg = {

'model': 'Qwen3.8-Flash-Next',

'model_type': 'qwen_dashscope',

}

tools = [

{'mcpServers': {

'time': {'command': 'uvx', 'args': ['mcp-server-time', '--local-timezone=Asia/Shanghai']},

'fetch': {'command': 'uvx', 'args': ['mcp-server-fetch']},

}},

'code_interpreter',

]

bot = Assistant(llm=llm_cfg, function_list=tools)

messages = [{'role': 'user', 'content': 'https://qwenlm.github.io/blog/ Introduce the latest developments of Qwen'}]

for responses in bot.run(messages=messages):

pass

print(responses)

10.5 Long-context — 1M tokens with YaRN

Static YaRN can hurt short prompts, so only enable it when you actually need long context. For vLLM:

VLLM_ALLOW_LONG_MAX_MODEL_LEN=1 vllm serve Qwen/Qwen3.8-Flash-Next \

--hf-overrides '{"text_config": {"rope_parameters": {

"mrope_interleaved": true,

"mrope_section": [11, 11, 10],

"rope_type": "yarn",

"rope_theta": 10000000,

"partial_rotary_factor": 0.25,

"factor": 4.0,

"original_max_position_embeddings": 262144

}}}' \

--max-model-len 1000000

For SGLang:

SGLANG_ALLOW_OVERWRITE_LONGER_CONTEXT_LEN=1 python -m sglang.launch_server \

--model-path Qwen/Qwen3.8-Flash-Next \

--json-model-override-args '{"text_config": {"rope_parameters": {

"mrope_interleaved": true, "mrope_section": [11, 11, 10],

"rope_type": "yarn", "rope_theta": 10000000,

"partial_rotary_factor": 0.25, "factor": 4.0,

"original_max_position_embeddings": 262144

}}}' \

--context-length 1000000

Tip from the card: if typical context is around 524K, use factor: 2.0 instead of 4.0 — the smaller YaRN factor preserves short-prompt quality better.

10.6 Fine-tuning with PEFT / LoRA

The GitHub repo directs users to Unsloth, Swift, and LLaMA-Factory for SFT / DPO / GRPO fine-tuning. Qwen-Agent is the in-house agentic harness. A typical Unsloth dynamic 4-bit fine-tune looks like:

from unsloth import FastLanguageModel

model, tokenizer = FastLanguageModel.from_pretrained(

model_name = "unsloth/Qwen3.8-Flash-Next",

max_seq_length = 262144,

dtype = None, # auto

load_in_4bit = True,

)

model = FastLanguageModel.get_peft_adapter(

model,

r = 16,

target_modules = ["q_proj", "k_proj", "v_proj", "o_proj",

"gate_proj", "up_proj", "down_proj"],

lora_alpha = 16,

lora_dropout = 0,

bias = "none",

use_gradient_checkpointing = "unsloth",

random_state = 3407,

)

# ... attach SFTTrainer / DPOTrainer / GRPOTrainer as usual

Note: the Unsloth team confirmed day-0 support, but the Flash-Next-specific fine-tune guide page is still being populated at research time. The snippet above is the standard Unsloth MoE pattern; expect minor adjustments for the GDN and QSA layers (which may need their own target_modules entries once the Unsloth team documents them).

10.7 Local: Ollama and llama.cpp

Ollama:

ollama run qwen3.8-flash-next

# or pull a specific Unsloth GGUF tag:

ollama run hf.co/unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL

llama.cpp:

# macOS / Linux install

curl -LsSf https://llama.app/install.sh | sh

# Start a local OpenAI-compatible server with web UI:

llama serve -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL

# Or run inference directly in the terminal:

llama cli -hf unsloth/Qwen3.8-Flash-Next-GGUF:UD-Q4_K_XL

llama.cpp caveat The gated DeltaNet linear-attention path required specific llama.cpp PRs (issue #15940) for Qwen3-Next. Flash-Next adds QSA on top — Unsloth's bundled llama.cpp fork is the easiest path to a working local install.

10.8 Claude Code and OpenAI Codex via QwenCloud

Because QwenCloud exposes both OpenAI Responses API and an Anthropic-compatible API, Flash-Next drops directly into existing agentic-coding tools. Claude Code:

npm install -g @anthropic-ai/claude-code

export ANTHROPIC_MODEL="qwen3.8-flash"

export ANTHROPIC_SMALL_FAST_MODEL="qwen3.8-flash"

export ANTHROPIC_BASE_URL=https://dashscope-intl.aliyuncs.com/apps/anthropic

export ANTHROPIC_AUTH_TOKEN=<your_api_key>

claude

OpenAI Codex (configure ~/.codex/model-catalog.local.json with a qwen3.8-flash entry, then ~/.codex/config.toml with model_provider = "QwenCloud" and wire_api = "responses"):

npm install -g @openai/codex

export OPENAI_API_KEY=<your_api_key>

codex

Both integrations are first-class — Qwen explicitly lists Claude Code, OpenAI Codex, Qoder CLI, Qwen Code, OpenClaw, and QwenWork as launch partners. For agentic-coding teams already on Claude Code, swapping the model to qwen3.8-flash is a single environment-variable change, and the cost delta versus Claude Opus 4.6 is roughly 30–50× on output tokens.

Balanced Analysis: Strengths, Weaknesses, and Honest Gaps

This section is the part most vendor launch blogs omit. The goal is to give a technical reader an honest picture of where Flash-Next genuinely leads, where it merely keeps up, and where it still trails the frontier. Every claim here is sourced from either the official model card (with caveat that the numbers are self-reported) or from independent community / press coverage in the first 24 hours of release.

11.1 Strengths

Cost efficiency vs capability

$0.16 / $0.47 per M tokens is roughly 12× cheaper than Qwen3.8-Max on both axes, and substantially cheaper than DeepSeek-V4-Flash and Claude Opus 4.6 Max. The Decoder calls this "ratcheting up the pressure on OpenAI and Anthropic." For agentic-coding workloads where Flash-Next is at or near the frontier on quality, the $/task economics are compelling — particularly for teams that have been running on Claude Opus 4.6 and can swap to qwen3.8-flash via the Anthropic-compatible API with a single env-var change.

Agentic coding performance

DeepSWE 1.1 at 58.7 (vs 54.4 for DeepSeek-V4-Flash, 16.5 for Qwen3.7-Plus) is a notable jump. SWE-bench Pro at 62.5 beats Claude Opus 4.6 Max (53.4). The model is explicitly optimized for agentic-coding benchmarks per The Decoder, and the optimization shows. SWE-bench Multilingual at 81.0 is also strong — the multilingual coding extension is not an afterthought.

Office / cowork tasks

CoWorkBench 73.9 (vs 45.1 for DeepSeek-V4-Flash, 65.1 for Qwen3.7-Plus); JobBench 55.7 nearly doubles Qwen3.7-Plus at 27.6. These are the benchmarks where Flash-Next's lead is largest in absolute terms, and they suggest the model is particularly well-suited to the kind of long-horizon office-task automation that has become a major enterprise use case.

Architecture as research contribution

Gated Residual, N-gram Embedding, QSA, and the Muon application are real research contributions being given away as open weights. NVIDIA developer forum members were impressed by the architecture preview, particularly the "memory cheap" N-gram offload angle. Reddit user 0rand notes that "the structure looks very similar to Ling 3.0 (Kimi K3 Flash)" — which is a meaningful comparison, because Kimi K3 Flash is the other recent open-weight model exploring similar ideas. The fact that Qwen is shipping this as open weights under (close to) Apache-2.0 terms is a real service to the research community.

Local-friendliness of the architecture

r/LocalLLaMA users were enthusiastic that the 51B N-gram table is sparsely accessed and an excellent candidate for system-RAM offload. A 4-bit quant in the 82 GB range makes it runnable on 128 GB Mac Studios, DGX Sparks, and Strix Halo. Sample community reactions: "Finally — a use for my 3060 and 128 GB RAM!" and "Ohhh my. Absolutely gorgeous for my 3090 + 96 GB DDR5." This is the first open-weight model in this capability class that is plausibly local-runnable on enthusiast hardware.

Day-0 ecosystem support

Unsloth (Daniel Han confirmed), vLLM, SGLang, TokenSpeed, llama.cpp (with PR), MLX, Ollama, LM Studio, Docker Model Runner, KTransformers — all supported at launch. This is unusually broad for a model with this many architectural novelties (GDN + QSA + GR + N-gram is not a small ask for inference frameworks). The fact that all of these shipped day-0 suggests Qwen did substantial pre-release collaboration work with the inference-stack community.

Hybrid thinking design

Thinking on by default with reasoning_effort = xhigh / medium / low and the preserve_thinking toggle (which retains thinking content across conversation history) is praised as good for agentic consistency. The ability to dial reasoning effort per-request is a meaningful product feature — it lets teams trade latency for quality at the call site rather than via model selection.

11.2 Known issues, complaints, and limitations

NL2Repo-Bench regression

Flash-Next scores 48.1 vs DeepSeek-V4-Flash-0731 at 54.2 — a -6.1 delta. llm-stats calls this out explicitly: "NL2Repo 48.1 vs 54.2 is the miss; say it out loud." This is a repo-level code generation benchmark, suggesting DeepSeek's model may be better at whole-repo synthesis. For teams whose primary use case is repo-level code generation rather than agentic coding, this is the benchmark to weight most heavily.

HLE gap

Humanity's Last Exam — Claude Opus 4.6 (Max) wins at 40.0 vs Flash-Next's 35.9. llm-stats: "Frontier reasoning remains the gap." This is the benchmark that most directly measures hard-reasoning depth, and it is the one where the gap to the true frontier is largest in relative terms.

OSWorld 2.0 binary is low

19.4% binary success on OSWorld 2.0 — tied with Qwen3.8-27B, still essentially a coin flip on full task success on computer-use. Partial score 52.3 is better but still well below the frontier. If your use case is fully-autonomous computer-use agents, Flash-Next is not yet the right model.

Agents' Last Exam Pass@1

24.3 — slightly behind DeepSeek-V4-Flash-0731 at 25.2. llm-stats calls this a wash, but technically a loss.

Near-saturated ceilings on coding and math

LiveCodeBench v6 91.9 vs 90.6 (DeepSeek) and 88.8 (Claude Opus 4.6); GPQA Diamond 91.7 vs 90.8 and 91.3. llm-stats: "the deltas are noise on a crowded ceiling." These benchmarks have become saturated to the point where single-point deltas are within run-to-run variance — they are no longer discriminating between frontier models.

Self-reported only

BenchLM notes "24 published rows leave some tracked benchmark slots empty. No comparable first-party API token rate is published." Categories like Reasoning, Math, Multilingual, and Multimodal have published rows but are "not ranked" due to insufficient coverage. Treat every number as vendor-reported until independent measurement exists. The model is one day old at research time.

License is NOT Apache 2.0

The Qwen3.8 main GitHub repo claims Apache-2.0 in its LICENSE file, but the Flash-Next checkpoint specifically ships under qwen-community-1.0. The Unsloth GGUF card and the Ollama page both list qwen-community-1.0. marktechpost explicitly warns: "Licensed under qwen-community-1.0, not Apache-2.0 — verify terms before commercial use." This is a recurring Qwen pattern — the Qwen Community License has had commercial-use restrictions for entities above 100M MAU in prior versions. For any commercial deployment, read the actual license text before committing.

Hardware reality check

The Decoder's "it just spat out a fully developed single-file HTML cloth simulator with perfect physics, no local model ever did this before on my single Mac Studio" quote is from the Qwen3.8-27B release, not Flash-Next. For Flash-Next, the more honest community sentiment is "80 GB is a lot more manageable than a 1.2 TB+ frontier model" (Reddit FabricationLife), but you still need 128 GB-class unified memory. Users with 64 GB RAM report regret: "regret building only 64 GB RAM instead of 128 GB now, but at the same time I'm $$$ constrained" (Reddit SensitiveVariety). The architecture is local-friendly; the absolute size is not.

VRAM quirk — TP8 incompatible

TP8 is incompatible with the checkpoint's 128-wide quantization blocks on 8×H200 — users must use TEP8 instead. This is a non-obvious gotcha that has already bitten early adopters. If you have an 8×H200 node, do not assume --tensor-parallel-size 8 will work.

Multimodal + local GGUF complexity

A community user on r/LocalLLaMA noted: "Which will be tricky for multimodal checkpoint" (re: grafting dspark for it). Multimodal local inference is possible but the toolchain is still settling.

No first-party hosted price on HF

As of research date, the Flash-Next open-weights checkpoint has no hosted $/M listing; the QwenCloud SKU qwen3.8-flash is a separate product with its own pricing. llm-stats: "If you came here for a list price, there is not one yet."

N-gram offload is NVIDIA-only

The 51B N-gram table offload to host RAM is NVIDIA-only for now, per marktechpost. Mac and AMD users cannot fully exploit the offload-friendly design yet — this is a meaningful limitation for the local-LLM community that Qwen is courting.

Size confusion pre-release

There was significant community confusion before launch about whether Flash-Next was 125B-A6B or 35B-A3B (the Japanese note.com article documents this in detail — some developers expected a smaller "Flash" based on the historical Qwen3.5-Flash = 35B-A3B pattern). The HF card settled it as 125B-A6B + 51B N-gram. The pre-release confusion is a transparency issue but is now resolved.

Thinking verbosity at default xhigh

From the Qwen3.8-27B review (which shares much of the architecture and tuning): "The most common complaint in the first week wasn't quality, it was verbosity. At default xhigh the thing meanders." The same default-xhigh reasoning behavior carries to Flash-Next. For latency-sensitive use cases, dial reasoning_effort down to medium or low.

11.3 Where it lags competitors

Table 16 — Where Flash-Next lags

Competitor Where Flash-Next lags
Claude Opus 4.6 (Max) HLE (35.9 vs 40.0); OSWorld; overall frontier reasoning depth
DeepSeek-V4-Flash-0731 NL2Repo-Bench (48.1 vs 54.2); Agents' Last Exam Pass@1 (24.3 vs 25.2)
Qwen3.8-Max (own flagship) Frontier capability across the board (CoWorkBench 73.9 vs 74.8; Agents' Last Exam 51.2 vs 52.4; AndroidWorld 84.5 vs 85.3) — Flash-Next is deliberately a tier below
GPT-5.6 Sol (per BenchLM) DeepSWE 58.7 vs 72.7 (best verified)
Claude Opus 5 / Mythos 5 SWE-bench Pro 62.5 vs 80.3 (best verified per BenchLM)

11.4 Hallucination, safety, and context window reality check

No specific hallucination studies have been published yet for Flash-Next. The card does not document refusal rates or safety red-teaming in the publicly available portions retrieved for this analysis. Sampling guidance: use presence_penalty between 0 and 2 to reduce endless repetition, but high values can cause "language mixing" and a slight performance drop.

For long-horizon agentic tasks, the card offers a non-obvious warning: "lower reasoning effort does not always reduce overall task completion time. Although it may produce faster per-turn responses, it can also lead to insufficient analysis, more failures, and repeated retries, which may increase total latency and token consumption." This is worth internalizing — naive reasoning_effort = low will not always be cheaper.

On context window: native 262K; YaRN-extended to 1M. The card explicitly warns: "All the notable open-source frameworks implement static YaRN, which means the scaling factor remains constant regardless of input length, potentially impacting performance on shorter texts." For high-cache-reuse online serving at 1M context with 90% prefix-cache hit rate, Qwen reports 8.6× prefill throughput vs Qwen3.7-Plus — but no independent end-to-end long-context quality evaluation (e.g., RULER, LongBench, Needle-in-Haystack) is published in the available artifacts. The predecessor Qwen3-Next-80B-A3B was validated up to 1M tokens on long-context tasks; Flash-Next presumably inherits this with QSA giving better latency, but independent validation is pending.

The Bottom Line

Flash-Next is the most architecturally ambitious open-weight MoE since DeepSeek-V3, and possibly the most cost-efficient open-weight model currently in production. The combination of Gated DeltaNet for history compression, Qwen Sparse Attention for targeted retrieval, Gated Residual for a wider and more stable residual stream, N-gram Embedding for compute-free knowledge capacity, and Muon for optimizer efficiency is a coherent answer to the question "how do you keep driving down cost-per-token without giving up capability?" The benchmark numbers — particularly on agentic coding and office tasks — bear that out, with the appropriate caveat that they are vendor self-reported and the model is one day old.

Who should use Flash-Next today

Agentic-coding teams already on Claude Code or OpenAI Codex. The Anthropic-compatible and OpenAI Responses API endpoints make the swap a single environment-variable change, and the cost delta versus Claude Opus 4.6 is roughly 30–50× on output tokens. For workloads where Flash-Next is at or near the frontier on quality (DeepSWE, SWE-bench Pro, CoWorkBench, JobBench), this is one of the highest-leverage cost reductions available in the API market right now.

Cost-sensitive production deployments that need 1M-token context. The QSA kernel's reported 7.6× / 4.9× prefill/decode speedup versus full attention at 1M context, combined with the $0.16 / $0.47 pricing, makes Flash-Next a strong candidate for long-context workloads that would be prohibitively expensive on frontier-model APIs.

Local-LLM enthusiasts with 128 GB-class unified memory. Mac Studio 128 GB, DGX Spark, Strix Halo 128 GB, RTX 5090 + 96 GB DDR5 — these are the configs that can actually run a 4-bit quant of Flash-Next with the N-gram table in system RAM. The architecture is unusually well-suited to this kind of split memory layout.

Qwen4 architecture watchers. If you want to understand where the Qwen4 mainline family is going, Flash-Next is the canonical reference. The GDN + QSA + GR + N-gram + Muon combo will almost certainly appear in Qwen4 with refinements; understanding it now is a head start on understanding Qwen4 when it ships.

Who should wait

Those needing frontier reasoning depth. HLE 35.9 vs Claude Opus 4.6's 40.0 is the gap. For tasks where maximum reasoning depth is the binding constraint — hard math, novel problem-solving, frontier research questions — the gap to Opus 4.6 / Qwen3.8-Max is real and the cost savings may not be worth the quality regression.

Apache-2.0-only shops. The qwen-community-1.0 license is not Apache-2.0, and the historical Qwen Community License has had commercial-use restrictions for entities above 100M MAU. Read the actual license text before committing to a commercial deployment. If Apache-2.0 is a hard requirement, Qwen3-Next-80B-A3B (Sep 2025) is the most recent "Next" model that ships under Apache-2.0.

Anyone needing independent benchmark verification. The model is one day old. BenchLM, LiveBench, lmarena, and artificialanalysis.ai do not yet have Flash-Next-specific entries. Every benchmark number in this post is vendor self-reported. If your procurement process requires independent verification, wait for the third-party benchmarking hubs to catch up — likely 2–4 weeks.

Those whose primary use case is repo-level code generation. NL2Repo-Bench 48.1 vs DeepSeek-V4-Flash-0731's 54.2 is the explicit regression. If your workload is dominated by whole-repo synthesis rather than agentic coding, DeepSeek-V4-Flash-0731 may be the better choice in this price tier.

Strategic significance

Qwen is using the "Next" line to ship research as production weights, on a one-year cadence, before committing it to a mainline family. The original Qwen3-Next (Sep 2025) introduced GDN + Gated Attention and that design then powered every Qwen release for the next year. Flash-Next (Aug 2026) introduces GDN + QSA + Gated Residual + N-gram Embedding + Muon, and that design is intended to underpin Qwen4. By the time Qwen4 ships, the community will have stress-tested these components at scale for months — through fine-tunes, alternative inference stacks, deployment edge cases, and adversarial probing. That is a fundamentally different release philosophy from the "paper ships months after weights" pattern that still dominates most labs, and it is one of the reasons Qwen has been able to maintain this release cadence without the quality regressions that typically accompany speed.

The GDN + QSA + GR + N-gram + Muon combo is also the most credible open-weight answer yet to the question of how you build a sub-10B-active model that punches like a 100B+ dense one. The 51B N-gram table is the architectural move that makes this work — it adds enormous knowledge capacity at near-zero compute cost, by exploiting the fact that deterministic lookups do not require GPU FLOPs. Whether this becomes the dominant pattern for cost-tier models in 2027 depends on how well it survives independent scrutiny, but the early evidence — particularly the agentic-coding and office-task benchmark leads — is strong.

If Flash-Next holds up under independent benchmarking, the implications for the API market are significant. A model that is within single-digit points of the frontier on agentic coding, at 30–50× lower cost than the frontier Anthropic model, changes the unit economics of every product built on top of LLMs. That is the bet Qwen is making. The next 30 days — as independent benchmarks arrive — will tell us whether the bet pays off.

References & Sources

Primary sources (Qwen / Alibaba official):

Predecessor (Qwen3-Next-80B-A3B, Sep 2025):

Secondary analysis / news:

Academic references:

Related Posts

DeepSeek V4 Flash

Deep-dive into DeepSeek's 284B/13B active MoE with MLA attention, 1M context, and $0.14/$0.28 per M tokens.

Read more →

OX Alpha (GLM-5.3-Flash)

Comprehensive analysis of the anonymous model that topped OpenRouter — revealed as GLM-5.3-Flash.

Read more →

GLM-5.3-Flash Deep Dive

Technical deep-dive into Z.ai's 320B/18B active MoE with hybrid KDA+MLA attention and 1M context.

Read more →

About the Author

Hussain Nazary is a software developer specializing in local AI deployment and the creator of GGUF Loader, an open-source tool for running GGUF models locally. This analysis is part of Local AI Zone's ongoing coverage of open-weight language models and practical deployment strategies.

Contact: GitHub | Consulting Services

Last Updated: August 27, 2026 | Version 1.0