GPU sizing for Llama depends on which model you mean: dense Llama 3 models (8B, 70B, 405B) scale VRAM directly with parameter count, while Llama 4's Scout and Maverick use a mixture-of-experts design where total parameters, not the smaller active count, determine what fits in memory.
Key takeaways
Every Llama GPU sizing question runs into the same trap: parameter count alone doesn't tell you what you need. It depends on precision, and for Llama 4 specifically, it depends on understanding that "17B active parameters" is not the same number as "17B parameters in memory." This guide covers real VRAM figures across the current Llama lineup, from the smallest 8B model to the largest 405B, plus what changes with Llama 4's architecture.
Llama 3.1 and 3.3 are dense models: every parameter activates on every token, so VRAM scales directly and predictably with parameter count and precision. This is the simpler half of the sizing question.
These figures cover model weights only. Context length adds on top, and it adds more than people expect: KV cache scales with context window size, so a long-context session on a 70B model can add tens of gigabytes beyond what the base weights need. Budget headroom above the weights-only figure, not right up to the edge of your GPU's VRAM.
Llama 4 Scout and Maverick use a mixture-of-experts architecture, a real departure from Llama 3's dense design. Both models route each token through only 17B active parameters out of a much larger total pool, Scout has 109B total parameters, Maverick has 400B, but every single parameter, active or not, has to be loaded into VRAM before inference starts.
⚡ Note
"17B active parameters" describes inference speed, not memory footprint. Scout generates tokens at roughly the speed of a dense 17B model, but still needs enough VRAM to hold all 109B parameters. This is the single most common mistake in Llama 4 hardware planning: assuming the active parameter count determines what GPU you need.
The practical result: Scout, despite sounding lightweight at "17B active," needs more VRAM than a dense Llama 3.1 8B or even most of the way to a 70B model. Maverick needs roughly the same VRAM range as a dense 405B model at Q4, despite having far fewer active parameters doing the actual computation. Scout's standout feature is a 10 million token context window, the largest of any current open model, though a context window that large adds substantial KV cache on top of the base weights.
Combining both tables above into the decision that actually matters: which card fits which model, at a quantization level you're comfortable with.
The B200 deserves a direct callout for the largest tier: at 192GB of HBM3e, packet.ai's own B200 documentation confirms it's enough to run Llama 3.1 405B at FP16 on a single card, no multi-GPU splitting required, which is a meaningful simplification over the 4-8 card setups 405B has traditionally needed.
⚠ Watch out
The H200 (141GB HBM3e) is confirmed sufficient for Llama 3.1 70B at FP16 with no quantization needed, according to packet.ai's own H200 documentation. As of this writing, H200 is listed as coming soon on packet.ai, available by waitlist rather than on-demand. For 70B today, the RTX 6000 Pro or A100 80GB are the currently bookable options.
Before picking a card, work through these in order.
Once you've matched a model to a GPU, packet.ai's Hugging Face TGI app template is a one-click way to get a production-ready inference server running without configuring the serving stack by hand. It's built for exactly this: loading a Hugging Face model, including any current Llama model, and serving it through a standard API.
Pick your GPU based on the sizing above
RTX 4090 for 8B, RTX 6000 Pro for 70B (Q4) or Scout, A100 80GB or B200 for the largest tiers.
Deploy the Hugging Face TGI template
A one-click app in packet.ai's catalog, built for production-ready text generation inference. Minimum 16GB VRAM, 48GB recommended, roughly 10 minutes to deploy.
Point it at the model you sized for
The template handles the serving stack. You supply the Hugging Face model identifier for whichever Llama variant your GPU choice supports.
Choose Dedicated for a standing inference service where predictable latency matters, or Dynamic if you're still testing which model size and quantization level actually meets your quality bar before committing. Current rates for every GPU covered here are on the packet.ai pricing page.
If you're deploying Llama through oobabooga or Ollama instead of a dedicated inference server, the same VRAM figures above apply directly, since both tools load and run the same underlying Llama model weights.
Last reviewed: July 20, 2026. VRAM figures cross-referenced across multiple independent sources and, where available, packet.ai's own GPU documentation. Quantization method and context length both affect actual memory use; treat the figures above as planning ranges rather than exact guarantees.
Same models. Same API. Fraction of the cost. Start free — no credit card required.
Start Building →