Qwen3-Coder-30B-A3B activates about 3B parameters per token while retaining substantial total weight memory

What's this about?

People disagree about whether Qwen3-Coder-30B-A3B uses only 3 billion model parts for each word piece.

It uses about 3 billion parts at once, but it still keeps about 30 billion parts in total.

What supporters say

• The model sends each word piece to only some expert groups, instead of every group.
• Qwen says the model has about 30 billion total parts and 3 billion active parts per word piece.
• This setup can do less math for each word piece than a normal 30-billion-part model.
• The model may keep skills from many parts while using fewer parts during each step.

What critics say

• Using 3 billion active parts does not mean a computer stores only 3 billion parts.
• A system still needs room for all expert groups, shared parts, and other data it needs while running.
• Moving expert groups between memory and chips can create hard speed and storage problems.
• Lower-bit storage can shrink memory use, but a smaller-file 30B model still differs from a 3B model.

The bottom line

The claim is mostly true: about 3 billion parts work on each word piece.

But the full 30-billion-part model still needs a large amount of memory.

Qwen3-Coder-30B-A3B is designed to use only about 3 billion parameters for each token it processes, even though it contains roughly 30 billion parameters in total. That can cut some computing work, but it does not mean the model needs memory for only 3 billion parameters.

The case for

The model uses a “mixture of experts” design, or MoE. Instead of running every part of the network for every token, it routes each token to a selected subset of specialist components. Qwen’s own model materials describe Qwen3-Coder-30B-A3B as having about 30 billion total parameters and 3 billion active parameters per token (see Figure 1). 1

That architecture gives the model a credible route to a better balance between capacity and computation. It can hold the knowledge and capabilities associated with a much larger pool of parameters, while doing less expert-layer arithmetic on any single token than a dense model with a similar total parameter count. In principle, that can make sparse models more efficient for some workloads (see Figure 2). 2

But sparse activation and low memory use are different things. Even if only a share of experts is used for one token, a serving system still has to manage the wider set of expert weights, along with shared model components and other runtime data. Research on expert swapping and caching treats where those experts are stored and how they are moved as a central deployment challenge, underscoring that the full model remains a meaningful memory burden (see Figure 3). 3

Lower-precision formats can reduce that burden. Quantization can substantially cut the storage and video-memory requirements of a model by representing weights with fewer bits. Yet it changes the tradeoff rather than removing it: a quantized 30B-class MoE model is still not simply a 3B-parameter model to store. 4

The case against

The figure of 3 billion active parameters should not be read as a direct promise of lower latency, lower cost or faster real-world inference. It measures only part of the work: the expert parameters selected for a token. Routing decisions, shared layers, memory access, communications between devices, load balancing and software overhead also affect how quickly and cheaply the model can run. 5

Hardware and deployment choices can narrow, or sometimes erase, the theoretical advantage of sparse routing. Performance depends on batch size, sequence length, parallelism, routing patterns, how close experts are to the processor, and the serving framework. The need for specialist caching and scheduling systems is evidence that moving data and coordinating experts can become bottlenecks independent of the arithmetic saved by activating fewer parameters. 6

The exact 3B-active, 30B-total description also rests chiefly on vendor documentation. AWS documentation identifies the released model and supports its practical deployment relevance, but it does not independently prove the architecture’s efficiency claims. Outside measurements of quality, speed, throughput or price can be useful, but they vary with the provider, hardware, prompts and software stack rather than establishing a fixed property of the model itself. 7

Memory requirements are similarly dependent on the setup. Precision, quantization, offloading, context length, concurrent users and runtime overhead all influence how much hardware memory is actually needed. Without those details, no single VRAM or storage requirement can be stated with confidence.

The bottom line

The claim is well supported when stated carefully. Qwen3-Coder-30B-A3B is documented as a roughly 30B-total, approximately 3B-active MoE model: sparse routing can reduce the expert computation needed per token while the full expert pool still creates a substantial weight-memory requirement.

Confidence is high in that basic architectural distinction and in the general rationale for MoE models. But any claim that the model is automatically faster, cheaper or easier to deploy than dense alternatives is conditional. Its real-world advantage depends on the hardware and serving configuration, while the model-specific parameter count remains primarily vendor-reported.