induwara.lk
induwara.lkAI · Inference

LLM KV Cache Memory Calculator

Work out how much GPU memory an LLM's key–value cache uses — per token, per sequence, and in total — from the model's layers, KV heads, head dimension, context length, batch size, and precision. Add a GPU's VRAM to see how many concurrent requests fit. Formula cited, runs in your browser.

By Induwara AshinsanaUpdated Jul 1, 2026
KV cache memory
Formula cited · Pope 2022 + vLLM
Popular setups
Per token
128.0 KiB
Per sequence (8,192 tok)
1.00 GiB
Total (batch 1)
1.00 GiB
GQA saving vs MHA
4.0×
8↔32 heads

KV cache grows linearly with context and batch: double either and the total doubles. Cross-checked against vLLM's paged block accounting (16-token blocks, ideal packing): identical.

Same config at FP16 / FP8 / INT4

FP16 · 2 B/elem
1.00 GiB
per sequence
FP8 · 1 B/elem
512.0 MiB
per sequence
INT4 · 0.5 B/elem
256.0 MiB
per sequence
Quick GPUs:

KV-cache formula from Pope et al. 2022 and the Hugging Face KV-cache docs; concurrency framing from vLLM / PagedAttention. Architecture constants are from each model's published config.json. The GPU overhead reserve — max(10%, 2 GiB) for activations, CUDA context, and fragmentation — is the only estimate; everything else is exact arithmetic.

How it works

During generation a transformer keeps the Key and Value vectors of every past token so it does not recompute them each step. That store is the KV cache, and it is usually the memory that decides how long a context you can run and how many requests a GPU can serve at once. The size is exact arithmetic over the model's attention architecture — no training data or benchmarking needed.

The per-token size, summed across all layers and counting both the Key and the Value tensor, is:

per_token_bytes = 2 × num_layers × num_kv_heads × head_dim × bytes_per_element

The leading 2is one tensor for Keys and one for Values. This is the formula given by Pope et al. (2022) in “Efficiently Scaling Transformer Inference” and mirrored in the Hugging Face Transformers KV-cache documentation. num_kv_headsis the grouped Key/Value head count from the model's config.json — for a grouped-query-attention model it is smaller than the number of attention heads, and that gap is exactly the memory it saves (Ainslie et al., 2023).

Two more multiplications finish the job, and the cache scales linearly in each:

  • Per sequence = per-token bytes × context length. Doubling the context doubles the cache.
  • Total = per-sequence bytes × batch size (concurrent sequences).

bytes_per_element is set by the cache precision: FP16/BF16 = 2, FP8 = 1, INT4 = 0.5. Halving the precision halves the cache, which is why FP8 KV cache is a common lever for longer context. All results use binary units (1 KiB = 2¹⁰, 1 GiB = 2³⁰ bytes) to match how allocators and nvidia-smireport memory. As a cross-check the tool also computes the cache the way vLLM's PagedAttention does — rounding each sequence up to whole 16-token blocks — which matches the closed-form figure exactly at block-aligned contexts.

When you enter a GPU's VRAM the tool switches on a capacity check. It converts the card's decimal GB to bytes, removes an overhead reserve of max(10%, 2 GiB) for activations, the CUDA context, and allocator fragmentation, then subtracts the model weights (parameter count × weight precision). Whatever is left is the KV budget: dividing it by the per-sequence cache gives the maximum concurrent requests, and dividing by the per-token cache gives the longest single-sequence context. The reserve is the one estimate here and is shown alongside the result; the vLLM PagedAttention paper (Kwon et al., 2023) documents why this cache budget, not raw compute, is what caps real serving concurrency. Sliding-window models are computed as a full-context upper bound, and DeepSeek-V3's multi-head latent attention uses its compressed-latent formula rather than the standard one.

Worked examples

Llama 3 8B · 8,192 tokens · FP16 · batch 1

  1. Config: layers 32, num_kv_heads 8, head_dim 128, 2 B/element.
  2. Per token: 2 × 32 × 8 × 128 × 2 = 131,072 B = 128.00 KiB
  3. Per sequence: 131,072 × 8,192 = 1,073,741,824 B = 1.00 GiB
  4. GQA vs MHA: as 32 KV heads it would be 512 KiB/token → 4.00× more.
  5. Verdict: one 8K chat session costs ~1 GiB of cache.

Llama 3 8B serving on an RTX 4090 (24 GB) · FP16 weights · 8K

  1. Total VRAM: 24 × 10⁹ = 2.4e10 B
  2. Overhead reserve: max(10% × 2.4e10, 2 GiB) = 2.24 GiB
  3. Usable: 2.4e10 − 2.4e9 = 20.12 GiB
  4. Weights (8.03B × 2 B): 14.96 GiB → KV budget = 5.16 GiB
  5. Concurrent 8K sequences: ⌊5.16 ÷ 1.00⌋ = 5
  6. Or one sequence up to ⌊5.16 GiB ÷ 128 KiB⌋ ≈ 42,266 tokens.

Edge — DeepSeek-V3 (MLA) · 128,000 tokens · FP16 · batch 1

  1. MLA caches one latent per layer, not 2 × heads × head_dim.
  2. Config: layers 61, kv_lora_rank 512, qk_rope_head_dim 64.
  3. Per token: 61 × (512 + 64) × 2 = 70,272 B = 68.63 KiB
  4. Per sequence: 70,272 × 128,000 = 8.38 GiB
  5. A naive multi-head read of the same model is ~57× larger — the MLA point.

Frequently asked questions

Sources & references

Related tools

Rate this tool
Be the first to rate

Comments & feedback

Spotted a bug or want an improvement? Tell us — our team reviews every comment, and good ideas get built. Comments are public and anonymous.

Found a bug, edge case, or want another model preset added?

Email me at [email protected] — most fixes ship within 24 hours.