LLM VRAM Calculator: Llama 4 VRAM Requirements (2026)

An LLM VRAM calculator boils down to one question: how many bytes does the model need to sit in GPU memory at the precision you're running, plus how many more bytes the KV cache adds once real requests start hitting it. For Llama 4, that second part is the trap. Scout advertises a 10 million token context window, and if you take that number at face value when sizing a GPU, you'll blow past what any rentable instance offers by orders of magnitude.

This post walks through the exact FP16, INT8, and INT4 VRAM numbers for both Llama 4 Scout and Maverick, shows how much of that footprint is KV cache once you set a real context length, and lands on the GPU tier to actually rent for each precision. For the general formulas this post applies to Llama 4 specifically, see our GPU memory requirements for LLMs guide.

How VRAM Scales With Parameter Count and Quantization: The LLM VRAM Calculator Math

For a dense model, VRAM math is simple: parameters times bytes per parameter. A 70B dense model at FP16 (2 bytes/parameter) needs ~140 GB of weights, full stop. Every parameter loads into memory and every parameter runs on every forward pass.

Llama 4 breaks that rule because it's a Mixture-of-Experts (MoE) model. Scout has 109B total parameters but only 17B active per token, spread across 16 experts; Maverick has 400B total parameters, also 17B active, across 128 experts. The naive "params x 2 bytes" formula still applies to memory, because every expert's weights have to sit in VRAM whether or not that token routes to them. What changes is compute: only the active 17B run per forward pass, which is why Maverick's inference speed looks far closer to a 17B dense model than a 400B one, even though its GPU memory bill looks like a 400B model's. Our MoE inference guide covers expert parallelism and routing for exactly this mismatch between "what's loaded" and "what's computed."

Quantization cuts the bytes-per-parameter side of the equation:

This is where MoE math gets interesting for a model like Scout: quantizing 109B total parameters to INT4 shaves the memory bill from ~218 GB to ~55 GB, a reduction that matters far more on a 109B MoE model than it would on a 17B dense model, because you're compressing every parked expert, not just the ones doing work on a given token.

Llama 4 Scout and Maverick VRAM Requirements Table

Here's the direct comparison, weights-only first, since that's the number most GPU-shopping decisions start from.

Weights-only numbers understate what you'll actually provision, though. Add framework overhead, activations, and even a short KV cache and the real total climbs. Independent benchmarking from apxml.com puts Scout's total VRAM at a modest 1,024-token context at ~230.75 GB (FP16), and Maverick's at ~842.03 GB (FP16) for the same short context. Those numbers already run higher than the weights-only figures above, which is the gap between "what fits on paper" and "what you'll actually need to provision."

Llama 4 Scout (109B total, 17B active, 16 experts)

Scout is the model Meta specifically built for single-GPU accessibility. The Llama 4 launch post states plainly that Scout "fits on a single NVIDIA H100 GPU" with Int4 quantization, and the math backs that up: ~55 GB of INT4 weights leaves real headroom on an 80GB card. At FP16, the same model needs ~218 GB, which pushes you to 4x H100 80GB or a single high-memory card like the B300.

Scout's headline feature, the 10 million token context window, is also its biggest VRAM liability. More on that below.

Llama 4 Maverick (400B total, 17B active, 128 experts)

Maverick trades Scout's efficiency for raw capability, matching proprietary models on reasoning benchmarks at the cost of a much bigger memory footprint. Meta's own guidance is that Maverick "can be run on a single NVIDIA H100 DGX host," which is 8x H100 80GB (640 GB combined) for easy production deployment, not a single card. At INT4, Maverick's ~200 GB of weights fits on 4x H100 with some room to spare; at FP16, its ~800 GB pushes you toward that full 8-GPU DGX configuration or an 8x H200 node.

For a broader comparison of Llama 4 against other large open models on cost and VRAM tradeoffs, see DeepSeek V3.2 vs Llama 4 vs Qwen 3. And if you need the full requirements picture across 18 other models at a glance, the GPU requirements cheat sheet has Scout and Maverick alongside everything from 7B dense models to 685B MoE.

Context Length and KV Cache: The Hidden VRAM Cost

Scout's 10M token context window is the number Meta puts in the headline. It's also the number that will blow up a naive VRAM estimate if you plan around it literally. apxml.com's estimates show Scout's total VRAM jumping from ~230.75 GB at a 1,024-token context to ~3,671.04 GB at the full 10M-token window, roughly a 16x increase, almost entirely from KV cache. Maverick shows the same pattern at a smaller scale: ~842.03 GB at 1,024 tokens climbing to ~1,357.6 GB at its full 1M-token context.

Here's why Scout can even claim 10M tokens without an outright memory wall. Its config uses grouped-query attention with 8 KV heads and a head dimension of 128, the same GQA pattern that shrinks KV cache roughly 8x versus standard multi-head attention. On top of that, Scout uses an iRoPE architecture: layers alternate between chunked local attention (capped to a fixed window regardless of total context) and periodic global attention layers that do see the full sequence, plus inference-time temperature scaling that helps the model generalize to lengths beyond what it was trained on. That interleaving is what makes a 10M window architecturally plausible instead of a marketing number nobody could ever serve.

It doesn't make the VRAM cost disappear, though. Using Scout's published architecture config (48 layers, 8 KV heads, head_dim 128) in the standard KV cache formula:

KV Cache per Token = 2 × Layers × KV Heads × Head Dimension × Bytes per Element

That's 2 × 48 × 8 × 128 × 2 bytes ≈ 0.19 MB per token at BF16, if every layer scaled with full context (the worst-case, pre-chunking number). At a much more realistic 128K token context, a single request's KV cache comes out to roughly 24 GB, on top of the ~55 GB of INT4 weights. That's the number to plan around for production, not 10M. The working rule of thumb: don't set --max-model-len to the model's max advertised context just because you can. Set it to what your application actually uses. For the full set of techniques (FP8 KV cache, PagedAttention, NVFP4 on Blackwell) to shrink this further, see KV Cache Optimization: Serve 10x More Users on the Same GPU.

Single-GPU vs Multi-GPU Thresholds for Llama 4

Scout's single-GPU story is real, but it has edges:

• 1x H100 80GB, INT4 (~55 GB weights): Works for moderate context (roughly 32K-64K tokens) and modest batch sizes. This is Meta's own reference configuration.
• 2x H100 80GB or 1x H200 141GB: The tipping point for production traffic at 64K-128K context, where the extra VRAM pool goes straight to KV cache and concurrent requests instead of sitting idle.
• 4x H100 80GB, FP16 (~218 GB weights): Full precision, no quantization loss, with room for KV cache and batching on top.

Maverick's threshold sits higher because there's no realistic single-card path:

• 4x H100 80GB, INT4 (~200 GB weights): The minimum viable multi-GPU setup, with modest KV cache headroom in the remaining ~120 GB.
• 8x H100 80GB or 8x H200 141GB: Meta's own recommended production configuration (the "single DGX host" framing), needed once you're serving 100K+ token contexts or meaningful concurrency.

Vision inputs push both thresholds up slightly. Scout also functions as a vision-language model, and each image processed injects hundreds of additional visual tokens into the KV cache on top of whatever text context you're already carrying; see Deploy Vision Language Models on GPU Cloud if multimodal inputs are part of your workload.

Matching Llama 4 to a Rentable GPU Tier on Spheron

Once you know the VRAM number, the GPU choice mostly falls out of it. Current on-demand rates on Spheron, per GPU:

For Scout at INT4, a single H100 on Spheron is the sweet spot most teams land on: real 10M-context capability (right-sized down to what you'll actually use), ~55 GB of weights, and roughly $2,000/month running 24/7 at current rates. If you need more headroom for concurrent requests or longer context, a single H200 GPU pricing tier gets you 141 GB in one card instead of managing tensor parallelism across two H100s.

For Maverick, 4x H100 at INT4 runs roughly $7,900/month on-demand 24/7; scaling to Meta's recommended 8x H100 production configuration roughly doubles that to ~$15,800/month. Teams optimizing for total VRAM per dollar over raw interconnect bandwidth sometimes build out on A100 on Spheron instead, trading H100's faster memory bandwidth for a lower per-GPU rate. If you want Scout at full FP16 without touching tensor parallelism at all, Spheron's B300 instances pack enough VRAM in a single card to load the ~218 GB weights directly. Spot instances cut all of these rates 30-50%, with the tradeoff that the instance can be reclaimed without notice, fine for development and benchmarking, not for a production SLA.

Pricing fluctuates based on GPU availability. The prices above are based on 12 Aug 2026 and may have changed. Check current GPU pricing → for live rates.

Provisioning follows the same pattern regardless of tier: spin up the instance, SSH in, and deploy with vLLM. Our Llama 4 deployment guide covers the exact vLLM flags for both Scout and Maverick, tensor-parallel sizing, and step-by-step setup once you've picked a GPU configuration from this post. The Spheron docs cover provisioning and networking details if you're setting up a multi-GPU cluster for the first time. If your real goal is fine-tuning Llama 4 rather than serving it, the VRAM math is different and considerably higher; see GPU VRAM requirements to fine-tune LLMs for full fine-tuning, LoRA, and QLoRA sizing.

Run the Numbers Yourself With Spheron's LLM VRAM Calculator

Everything above is Llama 4-specific, but the same weights-plus-KV-cache math applies to any model on Hugging Face. Rather than redoing this arithmetic by hand for the next model you evaluate, plug it into our LLM VRAM calculator: it pulls a model's real config (parameter count, layer count, KV heads, head dimension) and returns FP16/INT8/INT4 memory estimates plus a matching GPU recommendation at live Spheron pricing, the same inputs and formulas walked through in this post, just automated.

We built it because we kept doing exactly the calculation above by hand for every new model release. If Llama 4 isn't the model you're sizing today, the calculator handles the same math for whatever is.

Sizing Llama 4 for your own workload? Spheron rents H100, H200, A100, and B300 GPUs by the minute, no contracts, so you can match the exact tier this post recommends.

H100 SXM5 on Spheron →