LLM VRAM Sizing: Your Context Limit Is a Pricing Decision

Key takeaways

• Llama 4 Scout has 109B total parameters with 17B active: roughly 218 GB of weights at FP16, 109 GB at INT8, and 55 GB at INT4, which fits on a single 80GB H100.
• Llama 4 Maverick has 400B total parameters, also 17B active: roughly 800 GB at FP16, 400 GB at INT8, and 200 GB at INT4, which needs at least 4x H100.
• Independent estimates put Scout's total VRAM at roughly 230.75 GB at a 1,024-token context, climbing to roughly 3,671 GB at the full 10M-token window, about a 16x increase driven almost entirely by KV cache.
• Running Scout at INT4 on a single H100 costs roughly $2,000 a month at 24/7 on-demand rates. Maverick at INT4 on 4x H100 runs roughly $7,900, and 8x H100 roughly $15,800.
• The practical rule: set your max context to what your application actually uses, because that setting is a cost of goods sold decision.

Why does parameter count understate the VRAM bill?

For a dense model, the math is simple: parameters times bytes per parameter. Llama 4 is a Mixture-of-Experts model, which changes compute but not memory. Every expert's weights have to sit in VRAM whether or not a given token routes to them, so Scout's 109B total parameters occupy memory like a 109B model even though only 17B run per forward pass.

That is actually good news for cost, because inference speed looks closer to a 17B dense model while the memory bill looks like a 109B one. It also makes quantization unusually valuable here: compressing to INT4 shaves Scout from roughly 218 GB to roughly 55 GB, and you are compressing every parked expert, not just the ones doing work.

| Precision | Bytes per parameter | Scout weights | Maverick weights | | --- | --- | --- | --- | | FP16 / BF16 | 2 | ~218 GB | ~800 GB | | INT8 | 1 | ~109 GB | ~400 GB | | INT4 | 0.5 | ~55 GB | ~200 GB |

Where does the KV cache actually blow up?

Weights are the number everyone quotes. KV cache is the number that decides your instance size.

Using Scout's published architecture config, 48 layers, 8 KV heads, head dimension 128, in the standard formula:

KV cache per token = 2 x layers x KV heads x head dimension x bytes per element

That is 2 x 48 x 8 x 128 x 2 bytes, or roughly 0.19 MB per token at BF16 in the worst case. At a realistic 128K-token context, a single request's KV cache comes out to roughly 24 GB, sitting on top of about 55 GB of INT4 weights.

Scale that to the advertised maximum and it stops being a rounding error. Independent estimates put Scout's total VRAM at roughly 230.75 GB at a 1,024-token context and roughly 3,671 GB at the full 10M-token window, a 16x jump that is almost entirely cache. Maverick shows the same pattern more mildly: roughly 842 GB at a short context, roughly 1,357.6 GB at its full 1M-token window.

Scout can even claim 10M tokens because it uses grouped-query attention, which shrinks KV cache roughly 8x versus standard multi-head attention, plus an iRoPE design that alternates chunked local-attention layers with periodic global ones. That makes the window architecturally plausible. It does not make it affordable.

What does that mean for your pricing page?

Here is the observation worth carrying out of this piece.

Max context is usually treated as a technical ceiling, something you set once in a config file and forget. It is really a pricing lever. The difference between a 32K-context deployment and a 10M-context deployment is the difference between one GPU and a cluster, which is the difference between roughly $2,000 a month and a number no early-stage product can fund.

So do not set --max-model-len to the model's advertised maximum just because the model supports it. Decide what context your product genuinely needs, price the tier around that, and treat longer context as a paid upgrade with its own cost basis rather than a free spec-sheet feature.

If you offer a long-context tier, size it deliberately. Every additional 128K of context is roughly another 24 GB of VRAM per concurrent request on Scout, which is capacity you either provision or queue for.

What should you actually rent?

Current on-demand rates, per GPU:

| GPU | VRAM | On-demand rate | Best fit | | --- | --- | --- | --- | | A100 80GB | 80 GB | from $1.43/hr | Budget multi-GPU builds for Maverick INT4 | | H100 | 80 GB | from $2.75/hr | Scout INT4, single card | | H200 | 141 GB | from $4.79/hr | Scout at longer context, production headroom | | B300 | 288 GB | from $9.08/hr | Scout FP16 on one card, or a smaller Maverick cluster |

For Scout at INT4, a single H100 is where most teams land: about 55 GB of weights, roughly 25 GB left for cache and overhead, which covers moderate context at moderate batch size, at roughly $2,000 a month running continuously. Need more headroom for concurrency or context, and a single H200's 141 GB avoids managing tensor parallelism across two H100s.

For Maverick, 4x H100 at INT4 runs roughly $7,900 a month on-demand, and Meta's recommended 8x H100 production configuration roughly doubles that. Spot instances cut all of these 30 to 50%, with the tradeoff that the instance can be reclaimed without notice, which is fine for development and wrong for a production SLA.

The short version: quantization decides which GPU you need, context length decides how many, and only one of those is on your pricing page today.

You can turn these VRAM and hourly figures into a cost per user at calcaas.com.