HighVRAM Hardware Watch

MoE LLM VRAM requirements: total vs active parameters

Current MoE boundary: Kimi-K2.5 stores a 1T-parameter MoE checkpoint in 595.178GB even though 32B parameters activate per token.

Current MoE example: MiniMax-M2.5 stores 230.134GB of official FP8 files even though its publisher labels only 10B parameters active per token.

Short answer: size a mixture-of-experts (MoE) LLM from its total stored parameters and exact artifact, not only the parameters activated for each token. Active parameters help explain compute per token; they do not mean the inactive experts disappear from memory. Qwen3-30B-A3B activates 3.3B of 30.5B parameters, but Qwen’s official GGUF files still range from 18.6GB at Q4_K_M to 32.5GB at Q8_0. OpenAI documents about 16GB of VRAM for gpt-oss-20b in MXFP4 and at least 60GB for gpt-oss-120b.

The rule that prevents most buying mistakes: use the exact file size or the runtime’s own weight-memory estimate as the floor, then add KV cache, runtime buffers, context, concurrency and other GPU users. “A3B” is not a 3B memory requirement.

Total parameters versus active parameters

NumberWhat it describesWhat it tells you about memory
Total parametersAll model weights, including every expertPrimary input to stored-weight size
Active parametersThe subset used for a token after routingUseful for understanding compute, not a standalone VRAM figure
Artifact sizeThe exact downloaded weights and format overheadA concrete floor for this file, still below complete runtime memory
Resident memoryWeights plus cache, buffers, workspaces and other allocationsThe number that must fit in the available device or placement plan
MoE routing reduces how many experts compute each token. It does not normally remove the other experts from the loaded model.

Official example: Qwen3-30B-A3B

Qwen’s official model card describes Qwen3-30B-A3B as 30.5B total parameters with 3.3B activated, 48 layers, 128 experts and eight experts selected per token. The “A3B” label describes activated parameters—not an artifact that occupies the same space as a dense 3B model.

Official Qwen artifactDisplayed sizeCapacity implication before overhead
Q4_K_M GGUF18.6GBAlready exceeds a 16GB pool; 24GB is the first common single-GPU tier with working margin
Q5_0 GGUF21.1GBCan target 24GB only with carefully controlled cache and runtime allocations
Q5_K_M GGUF21.7GBTight on 24GB after the rest of the workload is counted
Q6_K GGUF25.1GBPoints toward 32GB or a deliberate split/offload plan
Q8_0 GGUF32.5GBAlready exceeds 32GB before cache and runtime allocations
Official repository display values. File size is not peak resident memory, and quantization labels do not establish quality or speed.

Official example: gpt-oss-20b and gpt-oss-120b

OpenAI describes gpt-oss-20b as 21B total parameters with 3.6B active parameters and gpt-oss-120b as 117B total with 5.1B active. Its official Transformers guide gives approximately 16GB of VRAM for gpt-oss-20b with the default MXFP4 weights, approximately 48GB when loading the 20B model in bfloat16, and at least 60GB for gpt-oss-120b in MXFP4.

Those figures show why active count is not a capacity shortcut: 3.6B active does not turn gpt-oss-20b into a 3.6B-memory workload, and 5.1B active does not make gpt-oss-120b fit like a dense 5B model. OpenAI also notes that its documented MXFP4 Transformers path requires supported hardware and kernels; confirm the exact GPU architecture and runtime rather than assuming every nominally large-enough card supports the same path.

How much VRAM should you plan?

Memory tierReasonable MoE starting pointMain limitation
16GBOfficial gpt-oss-20b MXFP4 target on a supported stackLittle room for assumptions; Qwen3-30B-A3B Q4_K_M already exceeds the label
24GBQwen3-30B-A3B Q4_K_M and selected Q5 files with workload-specific validationLong context, concurrency and runtime buffers can erase the remaining margin
32GBQwen Q6_K with more working room; broader 30B-A3B choicesThe official 32.5GB Q8_0 file still does not fit before overhead
48GBSubstantial headroom for Qwen3-30B-A3B; OpenAI’s approximate bfloat16 figure for gpt-oss-20b is still tightCapacity does not establish hardware support or speed
64GB+Official gpt-oss-120b MXFP4 territory begins at ≥60GBExact accelerator, kernels, cache, context and multi-GPU placement still matter
Starting points tied to the cited artifacts and runtime guidance—not universal guarantees for every MoE model.

Why the exact runtime matters more for MoE

  • Expert placement: a runtime may keep all experts on one GPU, split experts across GPUs or offload some weights to CPU memory.
  • Kernel support: a compressed format is useful only when the hardware and software stack can execute it correctly.
  • KV cache: cache depends on attention geometry, context, cache precision and concurrent sequences—not on active expert count alone.
  • Routing and batching: active-expert compute and communication can affect speed even after the model fits.
  • Multi-GPU: expert or tensor parallelism is deliberate placement; installed memory is not one automatic pool.

A safe MoE sizing workflow

  1. Record the exact model revision, artifact, quantization and license.
  2. Use total parameters or the displayed file size for weight capacity; do not substitute the active count.
  3. Confirm that the runtime supports the model architecture, format, GPU and required kernels.
  4. Add the runtime’s KV-cache estimate at the intended context and concurrency.
  5. Add buffers, display use and other device allocations.
  6. If using offload or multiple GPUs, verify the placement mode and per-device peak memory.
  7. Run the longest representative request and record both peak memory and throughput.

Multimodal MoE example: the Qwen3-VL 30B-A3B guide shows why active routed parameters do not replace full weight and projector storage.

Flagship multimodal MoE example: the Qwen3-VL 235B-A22B guide shows why active routed parameters do not replace 142.906GB Q4 or 471.340GB BF16 storage.

Current multimodal MoE family: the Qwen3-VL MoE VRAM hub compares official 30B-A3B and 235B-A22B artifacts and active-versus-stored rules.

Sources and limits

Reviewed October 25, 2026. Official repository display values and vendor runtime guidance are linked. HighVRAM has not independently benchmarked every configuration. Capacity does not establish speed, output quality or value.

Need the exact OpenAI model decision? Compare the official ~16GB, ~48GB and ≥60GB figures in the gpt-oss-20b vs 120b VRAM guide.

Need the exact Qwen decision? Compare official files, cache arithmetic and 16GB–48GB tiers in the Qwen3-30B-A3B VRAM guide.

Moving from MoE sizing to hardware? Compare 24GB, 32GB and 48GB paths for Qwen3-30B-A3B and dense 32B models.

Classic MoE example: the Mixtral 8x7B VRAM guide shows why two active experts do not turn a 93.4GB official BF16 checkpoint into 13B-class weight memory.

Current hybrid MoE example: Qwen3.5-122B-A10B shows why A10B active computation still requires 122B-class weight storage and explicit expert placement.

Qwen3.5-397B-A17B: plan 256GB through 1TB MoE deployments from exact official files without mistaking A17B active parameters for stored-weight memory.