twitter-thread.com
GPU Memory Math for LLMs (2026 Edition) by @TheAhmadOsman(Ahmad) | Twitter Thread Reader
GPU Memory Math for LLMs (2026 Edition) If you’re running models locally, thinking “model → VRAM” falls apart once you account for how the weights were trained and quantized in the first place. There’s a better way to think about it: > VRAM (in GB) ≈ Parameters (in billions) x (effective bits per weight ÷ 8) That’s it. This one formula explains everything across: - FP16 / BF16 - FP8 / INT8 - GPTQ / AWQ / NF4 - GGUF variants - basically every format you’ll use The Only Conversion You Actually Need Here’s the core intuition: - FP16 / BF16 → 16 bits → ~2 GB per 1B params - FP8 / INT8 → 8 bits → ~1 GB per 1B params - 4-bit quants → ~4 bits → ~0.5 GB per 1B params GGUF formats sit in between depending on the exact scheme: - Q6_K → ~0.82 GB per 1B - Q5_K → ~0.69 GB per 1B - Q4_K → ~0.56 GB per 1B - Q3_K → ~0.43 GB per 1B - Q2_K → ~0.33 GB per 1B Ultra-aggressive quants go even lower, but at a cost. If you remember nothing else, remember this: - FP16 = 2x model size - FP8 = 1x model size - 4-bit = 0.5x model size Everything else is just variations on that theme. Side Note: The VRAM Tax Nobody Talks About XIMGPH_1 Before you even think about weights, understand this: the model itself is only part of your VRAM bill. The real killer is everything around it. KV cache grows with context length and will quietly eat your memory alive at 32K, 128K, or higher. Activations vary by runtime and optimization level but can spike under certain execution paths. Batching and concurrency multiply memory usage fast, especially in agent-style workloads. Framework overhead adds its own tax depending on whether you’re using Transformers, vLLM, TensorRT-LLM, or llama.cpp. And then there’s CUDA Graphs, which trade extra reserved memory for much better latency and throughput stability. Bottom line: if you only budget for weights, you’re already out of memory. What This Looks Like in Practice Let’s translate that into real model sizes. A 7B model: - FP16 → ~14 GB - FP8 → ~7 GB - 4-bit → ~3.5–4 GB A 13B model: - FP16 → ~26 GB - FP8 → ~13 GB - 4-bit → ~6–7 GB A 70B model: - FP16 → ~140 GB - FP8 → ~70 GB - 4-bit → ~35–40 GB A 405B model: - FP16 → ~810 GB - FP8 → ~405 GB - 4-bit → ~200+ GB Now you understand why people either: - quantize aggressively - shard across GPUs (e.g. Tensor Parallelism) - or just give up and say “cloud it is” GPU Reality: What Actually Fits Here’s the practical translation into GPUs people actually own. 8 GB VRAM: - ~3B in FP16 - ~6–7B in FP8 - ~12–13B in 4-bit 12 GB VRAM: - ~5B FP16 - ~10B FP8 - ~18–20B 4-bit 16 GB VRAM: - ~7B FP16 - ~13B FP8 - ~25B 4-bit 24 GB VRAM: - ~10–12B FP16 - ~20B FP8 - ~35–40B 4-bit 48 GB VRAM: - ~20–24B FP16 - ~40B FP8 - ~70–80B 4-bit 80 GB VRAM: - ~35–40B FP16 - ~70B FP8 - ~140B-class 4-bit This is the “what actually fits” version for model weights. Why Your Model Still Crashes As we said earlier, even if the math says it fits, you can still run out of memory. Because weights are only part of the story. You also need memory for: - KV cache (this explodes with long context) - activations (depending on runtime) - batching / concurrency - framework overhead Rule of thumb: Add 10–30% extra VRAM for a safe run. If you’re doing: - long context (32K, 128K, etc) - high concurrency - agent workflows …you’ll need even more. The MoE Trap Mixture-of-Experts models confuse people. Example: - “8x7B” sounds like 56B - but only a subset of experts run per token So compute cost ≠ memory cost. What matters: - total parameters → affects memory footprint - active parameters → affects speed Depending on how the model is loaded: - you may still need memory for all experts - or you can shard them across GPUs If you treat MoE like dense, you’ll either overestimate or underestimate badly. GGUF Is Not Magic GGUF gets treated like a cheat code. It’s not. It’s a container + quantization strategy optimized for: - llama.cpp-style inference - CPU + GPU hybrid setups - ultra-efficient memory usage But: Those memory numbers only apply in that runtime. The moment you move into other frameworks: - weights may be dequantized - memory usage can jump dramatically So “it fits in 6 GB” is not universal truth. It’s runtime-specific truth. The Only Mental Model That Matters There isn’t a giant compatibility matrix you need to memorize. There’s just this: VRAM ≈ B x (bits ÷ 8) Then adjust for: - runtime overhead - KV cache - concurrency That’s it. Once you internalize this, you stop guessing. You start designing systems. And more importantly, you stop asking: “Can I run this?” You start asking: “How do I want to run this?” That’s when things get interesting. Until next time.
