One hundred and eighty billion parameters on disk, six billion activated per token. It clears the 27B on every benchmark Alibaba published and beats Claude Opus on several, while costing roughly what a 6B model costs to run per token. The catch is the machine: sparse means cheap tokens and expensive memory, and the licence is community rather than Apache.
DeepSWE 1.1 goes 42.2 to 58.7, SWE-bench Pro 61.7 to 62.5, CoWorkBench 70.7 to 73.9, GPQA Diamond 89.2 to 91.7, and AndroidWorld 81.9 to 84.5. The DeepSWE jump of sixteen points is the one that stands out, and it is the benchmark closest to real agentic coding.
CoWorkBench 73.9 against 68.2, AndroidWorld 84.5 against 62.0, and GPQA Diamond 91.7 against 91.3. The AndroidWorld margin is twenty-two points. For anyone building device or GUI automation on open weights, that is the headline.
Six billion parameters activate per token, so compute per token is close to a 6B model. But all 180B must be resident, which is a multi-GPU deployment. You are trading a bigger machine for cheaper tokens, and whether that trade pays depends entirely on your utilisation.
The 27B is Apache. This one is not. That is a legal review rather than a blocker, but it is a real difference between two models in the same family released three weeks apart, and it is the kind of thing that gets assumed rather than checked.
180B breaks down as a 125B backbone with 6B activated, plus 51B of n-gram embedding and 4B of multi-token prediction. Nearly a third of the model is embedding table. That shapes your memory profile in ways a plain parameter count will not tell you.
From the Qwen model card. The comparison set is the 27B from three weeks earlier, DeepSeek-V4, and Claude Opus, which is a more useful set than most vendor cards publish because it shows both the within-family jump and the closed-model gap.
| Capability | Flash-Next | Qwen3.8-27B | Claude Opus | DeepSeek-V4 |
|---|---|---|---|---|
Agentic coding DeepSWE 1.1 +16.5 points within the family | 58.7 +16.5 vs 27B | 42.2 | not published | not published |
Agentic coding SWE-bench Pro | 62.5 +0.8 vs 27B | 61.7 | not published | 56.0 |
Knowledge work CoWorkBench ahead of the closed comparison | 73.9 +3.2 vs 27B | 70.7 | 68.2 | not published |
Graduate science GPQA Diamond | 91.7 +2.5 vs 27B | 89.2 | 91.3 | not published |
Device automation AndroidWorld +22.5 points on the closed comparison | 84.5 +2.6 vs 27B | 81.9 | 62.0 | not published |
Alibaba's numbers against a comparison set Alibaba chose, and the card does not pin which Claude Opus snapshot it ran. Treat the closed-model columns as directional. The within-family comparison is the more reliable signal here, because both sides were run by the same people on the same harness, and a sixteen-point DeepSWE jump in three weeks is the genuinely notable result.
The decision is rarely Flash-Next against a frontier API. It is Flash-Next against the 27B that shipped three weeks earlier, on hardware and on licence.
| Dimension | vs Qwen3.8-27B | vs a frontier API |
|---|---|---|
Hardware you need | 180B resident against 56GB of dense weights. That is a multi-GPU deployment with the interconnect and placement work that comes with it, against a model that fits on one card. This is the difference that decides most projects, and it decides them before anyone looks at a benchmark. | An API needs no hardware at all. Sparse open weights are the most operationally demanding option on this page, and the capability gain has to be worth a materially harder deployment. |
Cost per token | Six billion active against 27.8 billion, so compute per token drops sharply. On a well-utilised cluster Flash-Next is the cheaper token. On a lightly used one you are paying to keep 180B warm to serve very little. | Qwen's own hosted Flash tier is $0.14 / $0.42 per million. Beating that with your own multi-GPU deployment requires real sustained volume, and the sums should include the engineer maintaining it. |
Licence | qwen-community-1.0 against Apache 2.0. Same family, three weeks apart, materially different legal position. On client work we default to the Apache model and escalate to this one only when the capability gap is proven and legal has read the terms. | A commercial API has terms you have already accepted and a counterparty you can escalate to. A community licence has neither, which is a governance question rather than a technical one. |
Where it genuinely wins | Agentic coding and device automation. Sixteen points on DeepSWE and a twenty-two point lead over Claude Opus on AndroidWorld are not marginal, and if you are building GUI or device automation on open weights this is the model. | The frontier APIs still lead on general reasoning and on the long-horizon work they are tuned for. Flash-Next is a specialist that happens to be very good, not a general replacement. |
Behind a vendor-neutral abstraction these are configuration choices rather than architecture. We run the 27B as the open-weight default, route to Flash-Next where the agentic gap is proven on customer tasks, and keep the hosted tier available for everything that does not need to stay inside the boundary.
The architecture pairs linear-attention DeltaNet blocks with a sparse attention mechanism, plus gated residual connections. It is the same design direction as the 27B taken further, and it is what lets a 48-layer model with a 2,560 hidden dimension carry 180B of parameters usefully.
Nearly a third of the parameter count is n-gram embedding table. That is an unusual allocation and it changes your memory profile: a large, mostly-cold lookup structure rather than compute-heavy weights. Worth understanding before you plan sharding.
4B of the model is dedicated to predicting more than one token ahead, which is a throughput mechanism. It shows up as tokens per second rather than as a benchmark score, so it will not appear in the table above but you will feel it in production.
The unsloth GGUF has 868k downloads and NVIDIA published an NVFP4 build at 120B. For a model released in late August that ecosystem response is fast, and it is the practical difference between a research artefact and something you can deploy this quarter.
Same context envelope as the 27B, with the same explicit output guidance: 262,144 reasoning tokens and 131,072 for the final response. Consistency across the family makes routing between the two tiers much simpler.
qwen-community-1.0 rather than Apache 2.0. Not a blocker, but the single most important line on this page for anyone planning a commercial deployment, and the one most likely to be skipped.
The limits, the endpoints, and the lines that decide whether this model fits your transport and your budget. Kept here so nobody has to reconstruct it from three vendor pages.
| Hugging Face repo | Qwen/Qwen3.8-Flash-Next |
|---|---|
| Licence | qwen-community-1.0. Not Apache 2.0. Read the terms before commercial deployment |
| Parameters | 179,999,981,424 BF16 total |
| Composition | 125B backbone with 6B activated, plus 51B n-gram embedding and 4B multi-token prediction |
| Architecture | Qwen4ExpForConditionalGeneration. Gated DeltaNet with Qwen Sparse Attention, gated residual connections, n-gram embeddings |
| Layers | 48, hidden dimension 2,560 |
| Context window | 262,144 tokens native, extensible to 1,000,000 |
| Recommended output | Up to 262,144 reasoning tokens, 131,072 for the final response |
| Input | Text, images, and video |
| Serving | SGLang, vLLM, TokenSpeed |
| Hugging Face signal | 475k downloads and 4,971 likes |
| Quantised builds | unsloth GGUF at 868k downloads, an NVFP4 build from NVIDIA at 120B |
Weights are free and the machine is not. These are the numbers to price a sparse self-hosted deployment against.
| Flash-Next weights | Free | qwen-community-1.0. Legal review before commercial deployment. |
|---|---|---|
| Resident memory | 180B params | All resident even though 6B activate. Multi-GPU, or a quantised build. |
| Active per token | 6B | Compute per token close to a 6B dense model. |
| Qwen3.8-Flash hosted | $0.14 / $0.42 | The number your self-hosted cost per token has to beat. |
| Qwen3.8-Max hosted | $2 / $6 | Closed-weight hosted flagship, cached input $0.25. |
| For comparison | $10 / $50 | GPT-6 Astra and Claude Fable 5.1 on input and output. |
Sparse models invert the usual self-hosting maths. The per-token cost is genuinely low, and the fixed cost of keeping 180B resident is genuinely high, so the break-even sits at a much higher utilisation than a dense model of similar capability. In practice that means Flash-Next pays off for a busy shared cluster and is poor economics for a single team's intermittent workload. We model it against real traffic, not peak, because peak is what makes every sparse deployment look affordable on a slide.
qwen-community-1.0 is not Apache 2.0 and the two models sit side by side in the same family, which makes the difference very easy to miss. Whatever restrictions it carries attach to your product for as long as you ship it, so this belongs in front of legal before it goes into an architecture diagram.
No vendor classifier, no refusal path, no abuse monitoring. Input filtering, output review, rate limiting and audit logging all become yours to build. On a device-automation model with a twenty-two point lead on AndroidWorld, that matters more than usual: the thing it is unusually good at is taking actions on real interfaces.
A model that operates GUIs better than the closed frontier, with no vendor-side monitoring, is a genuinely powerful tool and a genuinely abusable one. Scope its permissions tightly, put a human gate on consequential actions, and log what it did rather than only what it was asked to do.
Our open-weight default is the Apache-licensed 27B, because one card and a settled licence beat a multi-GPU deployment and a legal review for most work. Flash-Next is where we send agentic coding and device automation once an eval on customer tasks shows the gap is real.
84.5 against 62.0 for Claude Opus is not a rounding difference. If you are building device or GUI automation and the weights need to be yours, there is currently no better answer, and that is a narrow but genuinely valuable position.
Every sparse deployment looks cheap at peak utilisation and expensive at real utilisation. We model against actual traffic including the quiet hours, and more than once that has turned a confident self-hosting plan back into a hosted-API plan.
That is worth naming as a pattern rather than an accident. Open-weight families increasingly mix permissive and community licences across tiers, so check per checkpoint. Assuming the family licence is how a compliance problem gets built into a product.
GGUF and NVFP4 builds appeared almost immediately, and they are what make a 180B model reachable for teams without a cluster. They are also different models from the one in the benchmark table, so evaluate the build you will actually run.
Every model we integrate runs through the same operating system. Three pillars, sixteen layers, one Compound Growth Loop. The methodology that keeps AI work from rotting after the first ship.
Read the K-FrameworkDirect API integration with the model. No LangChain, no orchestration vendor, no agent framework built on quicksand. Typed contracts, the same way we wire up Postgres.
An eval suite built from your real tasks gates every prompt and model change. Quality is measured before it ships, not vibed in a demo.
Governance, audit, and oversight wired in from day one. Who called what, with which prompt version, at what cost. Your auditors get answers, not screenshots.
A model in production without observability is roulette. We instrument every integration so engineering and finance can see the same numbers, and so a regression at 3am surfaces before a customer opens a ticket.
Tokens in, tokens out, dollars spent. Sliced by feature, tenant, and route. Budgets enforced where it matters.
Real distributions, not averages. We know which routes are slow, and why.
The same eval suite that gates a release runs continuously in production. A regression on real traffic surfaces fast.
PII scrubbed at the proxy, shipped to your SIEM. Retention controls match your compliance window.
Dashboards your team owns, not ours. At handoff you get the queries, the alerts, and the runbook. We are not in the path to read your metrics.
