Qwen3's Dense and MoE Variants: What the Model Name Tells You

Qwen3 model names are systematic enough to be parsed. Given Qwen3-235B-A22B-Instruct-2507-FP8 you can state the architecture, the compute cost, the training variant, the release and the numeric format without opening anything — and that is the fastest way to work out whether a checkpoint will fit on your hardware.

The name is a grammar

Qwen3 - <capability?> - <total>B [ -A<active>B ] - <variant?> - <date?> - <quant?>

Qwen3-8B                          dense, 8B
Qwen3-30B-A3B                     sparse, 30B total / 3B active
Qwen3-Coder-480B-A35B             sparse, code-specialised
Qwen3-235B-A22B-Instruct-2507     sparse, instruct variant, 2507 release
Qwen3-30B-A3B-FP8                 sparse, FP8 quantised

Only two of these segments are always present: the family and the size. Everything else is optional, and each optional segment answers a different question. The -A segment answers “how much compute per token”. The size before it answers “how much memory”. Those are the two questions that decide whether you can run it.

The capability segment, where present, sits immediately after the family and names a specialisation rather than a size — Coder, and the embedding and reranking lines that follow the same convention. Its absence means a general-purpose model. It is the only segment that changes what the model is for, which is why it comes first: a coder checkpoint at a given size is not a drop-in replacement for the general model at that size, and the benchmark tables that matter for it are different ones.

The dense line

The April 2025 Qwen3 release, announced by the Qwen team at qwenlm.github.io/blog/qwen3, included six dense checkpoints:

model         params   active   native ctx   YaRN-extended
Qwen3-0.6B      0.6B     0.6B      32,768      —
Qwen3-1.7B      1.7B     1.7B      32,768      —
Qwen3-4B          4B       4B      32,768      131,072
Qwen3-8B          8B       8B      32,768      131,072
Qwen3-14B        14B      14B      32,768      131,072
Qwen3-32B        32B      32B      32,768      131,072

For a dense model the two parameter columns are the same number, which is why the name carries only one. Memory for the weights is roughly two bytes per parameter at BF16 — so Qwen3-14B is about 28 GB before KV cache — and that arithmetic is reliable enough to plan with.

The context figures are the ones from the original cards, and the distinction between the two columns matters: 32,768 is what the model was trained to, and the longer figure requires YaRN scaling to be enabled in the configuration or on the serving command line. It is not on by default, and enabling it has a quality cost on short prompts, which is why Qwen recommend turning it on only when you need it.

The dense line is also where the useful small models are, and the spread between its ends is larger than the numbers suggest. Qwen3-0.6B runs on a laptop CPU; Qwen3-32B needs a serious accelerator. Between them the models are not interchangeable for the same task at different speeds — the smaller ones lose instruction-following and tool-calling reliability well before they lose fluency, which is the failure that is hardest to see in a demo and most obvious in production.

The sparse line

model                  total   active   experts   active experts
Qwen3-30B-A3B          30.5B     3.3B       128         8
Qwen3-235B-A22B         235B      22B       128         8

Both April 2025 MoE checkpoints use the same routing configuration and differ in depth and width. The mechanism behind the active count — where it comes from, which config.json fields produce it, and what it does and does not predict — is the subject of the Qwen3 MoE active parameters page. For name-reading purposes the rule is simply: the first number is the memory bill, the A number is the speed.

Later additions follow the same convention, and because the numbers are in the name you can classify them on sight: Qwen3-Coder-480B-A35B is a very large sparse model with a mid-sized active count, and Qwen3-Next-80B-A3B is an unusually sparse design — 80 billion parameters resident to do roughly three billion parameters of work per token.

What the suffixes mean

• -Base — pretrained only, no instruction tuning and no chat template worth using. For fine-tuning, not for calling.
• No variant suffix on the April 2025 Qwen3 models — these are the hybrid instruct checkpoints, which switch between reasoning and direct answering via the enable_thinking flag.
• -Instruct and -Thinking — later single-mode checkpoints, where the behaviour is fixed by the weights rather than selected per request. On these, the thinking flag is not meaningful.
• A four-digit date such as -2507 — year and month of the release, in YYMM form. Qwen publish revised models under a new name rather than overwriting an old one, so this segment is the version.
• -FP8, -AWQ, -GPTQ, -GGUF — numeric format. Roughly halves or quarters the memory relative to BF16 at some quality cost. Official Qwen quantisations sit in the Qwen organisation; community re-uploads are separate repositories with their own maintainers and their own drifting chat templates, which is one of the reasons to pin a revision.

The trap the names set

Two checkpoints with similar active counts read as comparable and are not. Qwen3-4B and Qwen3-30B-A3B do a similar amount of arithmetic per token — a few billion parameters’ worth — and will generate at broadly similar speeds on hardware that can hold them. But one needs about 8 GB for weights and the other needs about 61 GB. A benchmark table that lists them side by side because their active counts match is comparing two models that do not belong in the same hardware conversation at all.

The inverse trap is reading the large number and assuming the cost follows it. A hosted Qwen3-235B-A22B is priced against its active count, so it can be cheaper per token than a dense 32B model despite the headline being seven times larger.

A third trap is quieter and catches people once each: taking a -Base checkpoint because the name looked like the plain model. A base model has no instruction tuning, so it continues text rather than answering it, and its chat template — if it has a usable one at all — was never trained against. The symptom is a model that responds to a question by writing three more questions, which reads as a broken deployment rather than as the wrong repository.

The reliable habit is to read both numbers every time and assign them to the right question: the total to “can I host this”, the active to “what will it cost and how fast is it”. A name with no A segment is answering both questions with the same number, and that is the only case where one figure is enough. Then read the suffixes, in this order — variant first, because it decides whether the model answers at all; then the date, because it decides which behaviour you are getting; then the quantisation, because it decides whether the memory sum you just did was right.