Llama 4 Scout and Maverick VRAM Requirements

Llama 4 Scout and Maverick are mixture-of-experts models, so the “17B active” label does not describe how much memory is needed to store the full model. Scout has 109B total parameters and Maverick has 400B total parameters. Every expert’s weights must remain available even though each token activates only part of the network.

Use the LLM VRAM calculator and hardware recommender for smaller dense models. For Llama 4, start from the complete official artifact and a documented distributed-runtime plan rather than multiplying 17B active parameters by a bytes-per-weight shortcut.

Official model and checkpoint facts

Meta describes Scout as 17B active parameters across 16 experts and 109B total parameters. Maverick has 17B active parameters across 128 experts and 400B total parameters. Meta says Scout supports a 10-million-token context and Maverick a 1-million-token context.[1][2] Those maximum context claims do not mean the full window is practical on the minimum hardware: KV-cache format, sequence length, batch, concurrency and runtime implementation determine the additional memory and compute cost.

File-only capacity boundaries

Why 17B active does not mean a 17B memory footprint

Mixture-of-experts routing reduces how many expert parameters participate in each token’s computation. It does not let a standard deployment discard the inactive experts. Scout’s 109B total parameters and Maverick’s 400B total parameters still have to be stored somewhere—accelerator memory, host memory, storage-backed offload or a distributed combination. Offload can make a model load on a smaller accelerator configuration, but it changes placement and usually changes performance. Report it explicitly rather than calling the result a resident fit.

Meta’s statement that Scout fits on a single NVIDIA H100 refers to Int4 quantization.[1] It must not be applied to the official 217.284GB BF16 artifact in the table. Likewise, Meta says Maverick can run on a single H100 DGX host; that describes a multi-accelerator host class, not one 80GB GPU.[1]

Context and multimodal memory are separate

The published context limit is a capability ceiling, not a promise that the maximum window fits beside the weights on a minimum configuration. Long context adds KV-cache and attention-state costs. Image inputs add preprocessing and vision-token work. Batch and concurrency multiply live state. Before buying hardware, record the real prompt length, output budget, modality, cache precision, batch and concurrent-user target.

The KV-cache guide explains why weight fit is only the first boundary. The multi-GPU guide covers placement, interconnect and why aggregate capacity is not automatic pooling.

A reproducible deployment checklist

1. Name the exact artifact: repository, revision and precision—not only “Llama 4.”
2. Record every device: exact accelerator, exposed memory, interconnect and topology.
3. Record placement: tensor, pipeline or expert parallelism and the layers or experts assigned per device.
4. Separate memory categories: peak per-device accelerator memory, host or unified memory, and any storage or CPU offload.
5. Describe the workload: text or image inputs, actual context, input/output token counts, batch and concurrency.
6. Pin the software: runtime, version, kernels, driver, operating system and launch flags.
7. Define the measurement: prompt processing, generation, time to first token and memory peaks are different observations.

Sources

1. Meta: The Llama 4 herd
2. Meta Llama 4 Maverick official model card
3. Official Scout repository API with blob sizes
4. Official Maverick BF16 repository API with blob sizes
5. Official Maverick FP8 repository API with blob sizes

Reviewed October 25, 2026. File-size arithmetic is not an independent benchmark. Vendor capability and fit statements are labeled as Meta claims.