Qwen 3.6 35B A3B vs Qwen 3.8 27B: 3B Active or 27B Dense?

Two numbers decide this pairing, and they pull in opposite directions. Qwen3.6-35B-A3B carries 35 billion parameters but only switches on about 3 billion of them for any single token. Qwen3.8-27B is dense: every one of its 27 billion parameters is used for every token you generate. That means the mixture of experts is the lighter model to run and the heavier model to hold — 71.9 GB of BF16 weights against 55.6 GB, according to each vendor's own repository — while the dense model asks roughly nine times as much arithmetic per token and fits in less memory. Neither of those is a defect. They are two different answers to "how much machine do I have", and which answer is yours is the whole of the decision.

There is a second reason this page is worth your time. This comparison is the shape readers search for around the 35B A3B — every query in that model's small family is a version of it — and Qwen3.6-35B-A3B has never had a page here to describe it at all. So this page carries one honest paragraph on each side and then gets to the comparison.

What the 35B A3B build actually is

Qwen3.6-35B-A3B is the sparse member of A​libaba's April 2026 Qwen3.6 generation, published under Apache-2.0 in the vendor's own Hugging Face repository, which was created on 15 April 2026. The vendor's model card describes it as a mixture of experts with "35B in total and 3B activated", built from 256 experts of which eight routed experts plus one shared expert fire per token. It is not text-only: the card calls it a "Causal Language Model with Vision Encoder", and the repository carries an image-text-to-text pipeline tag, so it takes text, images and video and returns text. Context is 262,144 tokens natively, extensible to about 1,010,000 with YaRN scaling. Its layout is a hybrid — ten repeats of three Gated DeltaNet linear-attention blocks followed by one gated full-attention block, hidden dimension 2,048, 40 layers — and the card separates the sales pitch from the architecture by naming two things it emphasises: agentic coding, and a "thinking preservation" option that keeps reasoning context from earlier turns. The vendor's own tables on that card put it at SWE-bench Verified 73.4, Terminal-Bench 2.0 51.5, MMLU-Pro 85.2, GPQA 86.0 and LiveCodeBench v6 80.4 — all vendor-reported and unaudited, which is the label they carry wherever they appear below.

What Qwen3.8-27B is

Qwen3.8-27B is A​libaba's dense 27B open-weight model from the Qwen3.8 generation, released under Apache-2.0; the vendor repository was created on 5 August 2026 and last modified on 14 August. Qwen's own card calls it "a compact, deployment-friendly dense model" and positions it as the most capable open Qwen generation so far, with the stated gains in coding, professional work, research and long-horizon agentic tasks. It is likewise a vision-language model — "Causal Language Model with Vision Encoder" — accepting images and video as well as text, at 262,144 tokens of native context and 1,000,000 with extension. It is architecturally conventional by comparison: 64 layers, hidden dimension 5,120, a regular feed-forward network at intermediate dimension 17,408 rather than a bank of experts, and the same three-linear-to-one-full attention rhythm as its sibling. Where the 35B A3B card talks about thinking preservation, the Qwen3.8-27B card talks about flexible thinking control — a reasoning_effort setting defaulting to xhigh, with medium and low available, and preserve_thinking on by default. Its card reports LiveCodeBench v6 90.3, GPQA Diamond 89.2, OSWorld-Verified 84.3, QwenSWEBench 79.0, Terminal Bench 2.1 73.0 and SWE-bench Pro 61.7 — again vendor-reported and unaudited. Its weight total is 55.6 GB across eighteen safetensors shards, and its parameter count is 27.8 billion once the vision tower is counted, which is why the model is called 27B and measures 27.8B.

The one number that most often decides it: active parameters

Files track total parameters. Speed tracks active ones. Those are two different columns on the spec sheet and readers routinely collapse them into one, which is how people end up downloading a 22 GB mixture of experts expecting it to fit where a 16.5 GB dense model would.

The mechanism is worth stating plainly, because it is the whole trade. A dense model has to read all of its weights to produce each token; a sparse mixture reads only the experts its router selects. Qwen3.6-35B-A3B reads roughly three billion parameters' worth per token and Qwen3.8-27B reads twenty-seven billion — so the mixture has a structural advantage on per-token compute and on decode throughput, and that advantage is real. But the other experts are not free: they have to be resident somewhere, in VRAM or in system memory, or the router ends up fetching them, and a fetch can cost more than the arithmetic it saved. So the advantage is conditional on holding the whole 35B. This is how mixture-of-experts decoding works, not a measurement of these two specific models, and it is the reason the fitting question comes before the speed question rather than after it.

• Total parameters on disk, BF16 — Qwen3.6-35B-A3B: 35.95B in 26 safetensors files, 71.9 GB. Qwen3.8-27B: 27.78B in 18 shards, 55.6 GB. Per the vendors' own Hugging Face repositories, read 2026-10-13.

• Active parameters per token — Qwen3.6-35B-A3B: about 3B. Qwen3.8-27B: all 27B, because dense means dense.

• Architecture — Qwen3.6-35B-A3B: 256 experts, 8 routed plus 1 shared per token, 40 layers, hidden 2,048. Qwen3.8-27B: single feed-forward at intermediate dimension 17,408, 64 layers, hidden 5,120.

• Native context — 262,144 tokens on both. Qwen3.6-35B-A3B extends to about 1,010,000 with YaRN; Qwen3.8-27B's card states 1,000,000 with extension.

• Licence — Apache-2.0 on both. Both are downloadable from the vendor, both are open weights, and there is no per-seat or per-call term attached to either.

What each one costs you per token

Both models are served on OrcaRouter, so you can settle this without downloading anything. Read from our live catalogue on 2026-10-13, qwen/qwen3.6-35b-a3b is $0.248 per million input tokens and $1.485 per million output, with a 262,144-token window and 65,536 maximum output tokens. qwen/qwen3.8-27b is $0.330 per million input and $2.400 per million output at the same 262,144-token window. Both are also listed on our catalogue under a second host id at a higher price, so check which identifier you are actually calling before you compare invoices.

On a workload of one million input tokens and a quarter of a million output tokens — a plausible month for a small coding-agent deployment — the arithmetic lands like this. Qwen3.6-35B-A3B: 1.00 × $0.248 plus 0.25 × $1.485, or about $0.62. Qwen3.8-27B: 1.00 × $0.330 plus 0.25 × $2.400, or about $0.93. The newer dense model costs roughly half again as much on that shape of traffic, and the gap is widest on output tokens, where it is about 62%.

Two things follow that matter more than the numbers. First, these are our catalogue prices, and we add no markup to a provider's published list price — so a vendor price change reaches this page the same day it reaches the vendor, with no lag and no second contract. Second, the reason to compare them on one key rather than two is switching cost: the two ids sit behind one endpoint, so moving from one to the other is a string change rather than a migration, and automatic failover means you can run the less familiar of the two on part of your traffic without betting a production path on it. If you are evaluating a mixture of experts for the first time because of the compute argument above, that is the cheap way to test whether the argument holds for your workload.

What fits on your machine

This is the question the two models actually differ on, and it turns on the same total-versus-active split. Comparing the community GGUF builds that both models have — these are third-party repositories, not vendor releases, and their filenames are their own — the same quantisation label buys you materially different file sizes:

• Q3-class, smallest sane option — Qwen3.6-35B-A3B: 16.60 GB at UD-Q3_K_M. Qwen3.8-27B: 13.15 GB at UD-Q3_K_XL.

• Around IQ4 — Qwen3.6-35B-A3B: 17.73 GB at UD-IQ4_XS, 18.04 GB at UD-IQ4_NL. Qwen3.8-27B: 14.25 GB at UD-IQ4_XS.

• Q4_K_S — Qwen3.6-35B-A3B: 20.89 GB. Qwen3.8-27B: 15.36 GB.

• Q4_K_M, the usual default — Qwen3.6-35B-A3B: 22.13 GB. Qwen3.8-27B: 16.46 GB.

• Q4_K_XL — Qwen3.6-35B-A3B: 22.36 GB. Qwen3.8-27B: 17.56 GB.

• Q5_K_M — Qwen3.6-35B-A3B: 26.46 GB. Qwen3.8-27B: 19.77 GB.

• Q8_0 — Qwen3.6-35B-A3B: 36.90 GB. Qwen3.8-27B: 29.05 GB.

• BF16, as shipped — Qwen3.6-35B-A3B: 71.9 GB. Qwen3.8-27B: 55.6 GB.

• Also published — Qwen3.6-35B-A3B has an FP8 checkpoint in the vendor's own repository and an MXFP4 mix at 21.71 GB in the community builds; Qwen3.8-27B has an FP8 checkpoint in the vendor's repository too.

Read the two columns against each other and the rule falls out. At every matched label the mixture is between four and eight gigabytes heavier for the same nominal compression, because the file has to hold all 35B and only uses 3B of it at a time. Concretely: a 24 GB card takes Qwen3.8-27B at Q4_K_M with room for context and takes Qwen3.6-35B-A3B at Q3 or IQ4 with the KV cache fighting for space, and a comfortable long-context session on the mixture wants nearer 48 GB. Add the vision tower's own file if you want image input on either.

Where the benchmarks stand, which is not where you would like them to be

Nobody has published a head-to-head run of these two models at matched settings on a named harness. We are not aware of one, and this page will not imply a ranking that the evidence does not carry.

What does exist is a partial overlap in benchmark names between the two vendor cards, and it is worth showing precisely because it is so easy to over-read. On the names that appear on both cards, the Qwen3.8-27B figure is the higher one every time. SWE-bench Pro: 49.5 for the 35B A3B against 61.7 for the 27B. LiveCodeBench v6: 80.4 against 90.3. HLE: 21.4 against 30.8. CharXiv reasoning questions: 78.0 against 83.7. OmniDocBench 1.5: 89.9 against 91.1. RealWorldQA: 85.3 against 85.9. And on Terminal-Bench the cards are not even comparable in the way the row suggests: the 35B A3B card reports Terminal-Bench 2.0 at 51.5, while the 27B card reports Terminal Bench 2.1 (Terminus) at 73.0 — different versions of the benchmark, so that particular pair should not be subtracted from each other at all.

Three caveats sit on all of that. The numbers come from two different model cards published roughly four months apart, by the same lab, without an audit. Several benchmarks each model reports appear only on its own card and have no counterpart — SWE-bench Verified 73.4 and MMLU-Pro 85.2 on the 35B A3B side; OSWorld-Verified 84.3 and QwenSWEBench 79.0 on the 27B side — so they cannot be lined up. And a newer model in the same line scoring higher than an older one is the expected result, not a finding: it tells you the generation moved, and nothing about whether the older model is the better fit for the tokens you are about to send.

If you need the comparison to be decisive, the honest path is to run both on your own traffic. They are on one key, on one endpoint, and failover makes a split test cheap.

Which one you should pick

Pick Qwen3.6-35B-A3B if your machine can hold 35B of weights and your workload is heavier on generation than on one-shot reasoning. The cases where it is the right answer:

• You have the memory — 48 GB or more for comfortable long-context local use, or a 24 GB card at a 3-bit-class quant if you can live with a shorter window — and you want the architecture that spends the least compute per token.

• Your traffic is high-concurrency or long-generation, where per-token cost dominates the bill and the mixture's sparse decode is structurally on your side.

• You want one Apache-2.0 artefact that takes text, images and video and returns text, and you want the smaller download in the pair only if you are hosting it rather than downloading it, where the per-token price is lower on both input and output.

• You are at 3B-active scale deliberately — you accept being one generation behind on the vendor's own tables in exchange for paying less per token and doing it behind a familiar tool-calling interface.

Pick Qwen3.8-27B if memory is the binding constraint, or if you want the newest generation in this pair. The cases where it is the right answer:

• A single 24 GB card and no plan to buy more. At Q4_K_M it is 16.5 GB, which leaves real room for context; the mixture does not.

• You want the strongest vendor-reported agentic and coding figures in this pairing, and you are aware that they come from an unaudited card and are not a matched comparison.

• Your workload is comparatively few, comparatively large requests — document and screenshot understanding, repository-level reasoning, computer-use style automation — where throughput per request matters less than what each request gets right.

• You want the smaller download, the faster cold start and the shorter shard list to manage.

What none of that makes is a winner. The two models are not competing for the same slot on your machine, and the numbers above do not establish which one is better at anything — they establish which one is asking for less from the machine you already have.

The fact that most often settles it is this: the file on disk is sized by total parameters and the work per token is sized by active ones. So Qwen3.6-35B-A3B can be the model that runs faster and still be the one that does not fit, and Qwen3.8-27B can be the one with the larger per-token bill and still be the one running at all. Decide which of those two problems you actually have, and the choice stops being a comparison.