Llama 4 Scout VRAM requirements
The doors arrive early for a 109B: a 48GB-class card runs Q3-class builds (unsloth's UD-Q3_K_XL at 46.1 GiB, tight), a 128GB appliance reaches UD-Q8_K_XL at 119.9 GiB, and a single B200 covers everything through Q8_0, with BF16 the first build that needs two. The headline build is unsloth's UD-TQ1_0 true-1-bit — the smallest file tracked here; the other cliffs sit multiples from the 24GB line (DeepSeek-V4-Flash 3.2×, Kimi K3 ~18×). The KV line rides a config-derived stacked bound (6.0 GiB @32K) — noted here, not counted; at the full 32K it would close all three tight doors, and it scales with context (break-evens in the KV FAQ below).
Updated · data status: MEASURED WEIGHTS — totals = measured weights + measured overhead (KV rides a config-derived stacked bound, 6.0 GiB @32K, noted in sources); every weight is a pinned file-size sum (unsloth / ggml-org / meta-llama)
Rent it: minimal cloud configs (clouds rent no consumer cards — the RTX 5090 door above is smaller)
| Quantization | Total VRAM | Minimal single-node config | Verdict |
|---|---|---|---|
| UD-TQ1_0 (measured) | 27.7 GiB | 1× B200 / 1× MI300X | true-1-bit · the closest build in the database · its smallest door is the local 5090 (tight, ≤~12K ctx — the KV bound breaks 32K) |
| UD-IQ2_XXS (measured) | 35.3 GiB | 1× B200 / 1× MI300X | single-node door · 2-bit dynamic |
| IQ4_NL (measured) | 57.3 GiB | 1× B200 / 1× MI300X | single-node door · Q4-named |
| Q4_K_M (measured) | 61.4 GiB | 1× B200 / 1× MI300X | single-node door · the community default name |
| Q8_0 (measured) | 107.2 GiB | 1× B200 / 1× MI300X | single B200 · last single-GPU build |
| BF16 (official meta-llama) | 202.9 GiB | 2× B200 / 2× MI300X | the first 2× B200 build |
Card counts are plain division (rounded up) against published per-GPU memory (B200 192GB, MI300X 192GB) on measured totals — weights + measured overhead; the KV line is a config-derived stacked bound (6.0 GiB @32K, noted in sources) that no door verdict here depends on. For this model the rent door is unusually gentle: even BF16 needs only 2× B200.
Appliance / unified-memory form factors
| Appliance | Unified memory | Best fit | Verdict |
|---|---|---|---|
| Mac Studio M3 Ultra | 512 GB | every build through BF16 (202.9 GiB) fits — 17.58× of smallest (usable), the whole ladder | FITS · entire ladder incl. BF16 |
| Mac Studio M4 Max | 128 GB | builds through UD-Q8_K_XL (119.9 GiB) fit — 4.40× of smallest | FITS · through the Q8 door |
| NVIDIA DGX Spark | 128 GB | builds through UD-Q8_K_XL (119.9 GiB) fit — 4.40× of smallest | FITS · through the Q8 door |
| 48GB-class workstation | 48 GB | UD-Q3_K_XL (46.1 GiB) fits, tight — 1.70× of smallest; the first real 48GB door in the cliff family | FITS · Q3-class, tight |
The appliance column is the headline exit for this model. The 512GB Mac Studio (480 GiB usable) holds the entire ladder including BF16 — 17.58× of the smallest build; the 128GB boxes (M4 Max / DGX Spark, ~120 GiB usable, 4.40×) run every build through the 119.9 GiB UD-Q8_K_XL door; and a 48GB-class workstation card (2× 3090 combo / 6000 Ada, 46.5 GiB usable) is a real door for the first time in the cliff family — UD-Q3_K_XL at 46.1 GiB fits, tight. Ratios compare usable memory to the smallest build's file size, both figures in GiB (binary) — the division is computed and checked in a single unit end to end, so decimal-GB rereadings of these numbers do not apply; unified-memory bandwidth trails datacenter GPUs, so these are "it runs" verdicts.
Can't run it? The distill / step-down ladder
No Llama-4-Scout-specific official distill is tracked in our sources yet. The family's consumer entry would be a smaller Scout sibling (none tracked on this site yet). When an official Scout distill or a tracked Maverick page ships, this section links the full ladder.
Step-down options that exist: the Llama 3.x 8B/70B generation — not yet tracked on this site. The 24GB-class answer for the Llama family lives in that generation, not in Llama 4.
Private deployment (enterprises, labs, providers)
A separate query family from everything above: vLLM / SGLang tensor-parallel reference configs for the 16-expert MoE stack, compliance and air-gapped deployments, TCO modeling against the API. A single B200 covers every build through Q8_0, so the deploy question is governance and throughput, not RAM — and the 17B-active shape is exactly what API fleets optimize.
Or just use the API
Honest take: Scout's 17B-active MoE is the shape where hosted APIs are cheapest to run and hardest to beat on cost. Self-hosting makes sense when private deployment is the requirement — and this model's unusually gentle hardware floor (one B200 through Q8_0, a 128GB appliance through UD-Q8_K_XL) makes private deployment more plausible than the 284B cliffs above. Prices are linked, not pinned.
Where every number comes from (every figure carries its tag)
| Tag | Slot | What it is | What the verdict can claim |
|---|---|---|---|
| measured | Build file sizes | Community + official quant files, sizes summed at pinned revisions (unsloth / ggml-org GGUF, meta-llama official safetensors — linked below). | Determinate at each door — a platform above or below a measured file size is a fact, not an estimate. |
| provisional | Totals (weights + overhead) | Simple addition: measured weights + a measured overhead anchor (llama.cpp discussion #9936). The KV line rides a config-derived stacked bound (6.0 GiB @32K: 48 layers × 8 KV heads × 128 dim — iRoPE/chunking do not change KV allocation) and is noted here, not counted in the totals. | Not a rounding term on this page: at the full 32K it would close all three near doors (each tight — 2.3 / 0.4 / 0.1 GiB spare); it scales down with context, and totals stay weights + overhead. |
| provisional | Cloud card counts | Simple division against published per-GPU memory (B200 192GB, MI300X 192GB — linked below). | Card counts follow arithmetically once totals are set. |
| reported | Architecture facts | 48 GQA layers with iRoPE (no_rope every 4th layer), 16 experts, 10M context — config.json at the pinned revision (read via the unsloth mirror; the meta-llama blob is gated but the file listing is public). | Tracks the pinned config; parameter counts cross-checked against Meta's naming (109B total / 17B active). |
| reported | API prices | Referenced from OpenRouter, linked, not re-verified by us. | Tracks the linked page — prices move, we don't pin them. |
| unsloth/Llama-4-Scout-17B-16E-Instruct-GGUF (UD-TQ1_0 27.3GiB / UD-IQ2_XXS 34.8GiB / IQ4_NL 56.8GiB / Q4_K_M 60.9GiB / Q8_0 106.7GiB; config.json mirror-read) | pinned tree | accessed 2026-09-14 |
| meta-llama/Llama-4-Scout-17B-16E-Instruct (official BF16 safetensors 202.4GiB; file listing public, blob gated) | pinned tree | accessed 2026-09-14 |
| ggml-org/llama.cpp discussion #9936 (runtime overhead anchor) | measured | accessed 2026-09-05 |
| KV bound @32K = 6.0 GiB (48 layers × 8 KV heads × 128 dim × 2 × 2 B, config-derived stacked; iRoPE/chunking do not change KV allocation) | config-derived | accessed 2026-09-14 |
| NVIDIA B200 spec (192GB) | product page | accessed 2026-09-14 |
| AMD MI300X spec (192GB) | product page | accessed 2026-09-14 |
| OpenRouter — Llama-4-Scout prices | live | accessed 2026-09-14 |
FAQ
Can Llama 4 Scout run on a 24GB GPU?
No — but by the closest margin in the database. The smallest measured build (unsloth UD-TQ1_0, true 1-bit) totals 27.7 GiB against 22.5 GiB usable on a 24GB card: 5.2 GiB over, 1.2× — every other cliff on this site sits multiples away. The realistic in-VRAM doors are a 32GB RTX 5090 (the smallest build fits, tight), a 48GB-class card (Q3-class builds, tight), a 128GB appliance, or the API.
What is the closest GPU that runs Llama 4 Scout?
A 32GB card — the RTX 5090: the smallest measured build (unsloth UD-TQ1_0, 27.7 GiB) fits its 30 GiB usable with 2.3 GiB to spare, tight — the closest consumer door in the database. The next rung is a 48GB-class card: UD-Q3_K_XL totals 46.1 GiB against 46.5 GiB usable on the 2× 3090 / 6000 Ada tier, tight — the first time the 48GB-class door is real in the cliff family. A 96GB workstation card (RTX PRO 6000 Blackwell) loads the smallest build at 0.3× of its memory, and a 128GB box reaches the 119.9 GiB UD-Q8_K_XL door. At the model's 10M context the KV bound grows far past these totals — the 32K figures on this page are the practical planning caliber.
How many GPUs do you need to run Llama 4 Scout?
One B200 covers every tracked build through Q8_0 (107.2 GiB); BF16 (202.9 GiB) is the first build that needs 2×. A 5× B200 node is a throughput choice, not a capacity requirement.
Can a Mac Studio run Llama 4 Scout?
Yes — and wider than any other cliff in the family. The 512GB M3 Ultra (480 GiB usable) runs the entire ladder including BF16 (202.9 GiB); the 128GB boxes (M4 Max / DGX Spark, ~120 GiB usable) run everything through the 119.9 GiB UD-Q8_K_XL door. Unified-memory bandwidth caps throughput, so treat these as "it runs" verdicts.
Is Llama 4 Scout the same as Llama 4 Maverick?
No — Scout is the 109B-total / 17B-active 16-expert model priced on this page; Maverick is its larger sibling. The 24GB-class Llama answer is neither — it is the older dense 8B/70B generation (netted in our wordbank, pages pending), and this page links them when they land.
Why is Scout's KV cache called a bound and not counted in the totals?
Scout's 48 GQA layers with iRoPE (no-rope every fourth layer) and attention chunking are not a classic sizing form, so the page shows a config-derived stacked bound (6.0 GiB @32K: 48 × 8 KV heads × 128 dim × 2 × 2 B) as a noted bound, not a measured add-on — iRoPE and chunking change rope and compute, not KV allocation. On this page the bound is decisive at long context, not a rounding term: at the full 32K, counting it would close all three near doors — the RTX 5090 door (2.3 GiB spare) breaks even near 12K context, the 48GB-class Q3 door (0.4 spare) near 2K, and the 128GB Q8 door (0.1 spare) well under 1K. The bound scales linearly with context, so shorter contexts hold, and a measured KV figure lands as a tag upgrade, same as every other model here.