Skip to main content
Modules / Tools / AI model memory and bandwidth sizer

AI model memory and bandwidth sizer

Size the memory and bandwidth an AI model needs for training or inference: weights, activations, optimiser state, KV cache, precision and batch.

AI, systems and startupFree to useHow it worksSourcesWhere it helps

Fills the inputs below with typical figures. Replace any of them with your own.

Model size

The cache always follows the architecture. Enter a figure when you know the exact count.

Used when counting from the figure entered. For a mixture of experts, the total.

Mixture of experts with a figure entered: the parameters one token uses.

1 for a dense model.

Architecture

From the model card or paper. The layers, KV heads and head size set the cache; the rest set the parameter count and the activations.

Equal to the heads for multi-head attention; fewer for grouped-query attention; 1 for multi-query.

The inner width of one feed-forward block (one expert).

Mode and precision
Batch and context

Sequences decoded together on one serving replica.

Prompt tokens processed at once; sets the activation workspace.

Parallelism

The devices needed are tensor x pipeline x data parallel.

Accelerator

Memory is entered as printed on the data sheet; results can be shown in a different unit.

Fills the memory and bandwidth below from the vendor's public page.

Editorial allowance. Replace with a measurement.

Decode speed

Each decoded token reads the weights and the cache from memory, so bandwidth sets the speed.

Decode kernels commonly reach 70 to 90% of the peak.

Memory on one device
28.36 GB
Fits in 80 GB: 51.64 GB to spare (35% used)
Parameters
8.028 billion
All used by every token
Weights, whole model
16.06 GB
1 devices in the layout
KV cache, whole batch
8.59 GB
131,072 bytes a token (128 KiB)
Bandwidth for the target rate
0.7394 TB/s
On each of 1 tensor parallel devices at 30 tokens/s a sequence
Fastest decode per sequence
108.7 tokens/s
869.9 tokens/s over the whole batch and replicas
Smallest serving layout
1 device
Most sequences that fit on this layout: 51
Memory on one device by component (GB)
  • Weights16.0657%
  • KV cache8.5930%
  • Activation workspace0.2191%
  • Output logits0.0040960%
  • Overhead and runtime3.48712%
Show the data as a table
Memory on one device by component (GB)
ItemMemory
Weights16.06
KV cache8.59
Activation workspace0.219
Output logits0.004096
Overhead and runtime3.487

Sign in to save your inputs and come back to them later.

Memory by component: the whole model and one device
ComponentWhole model, no shardingOne device after shardingShare of one device
Weights16.06 GB16.06 GB56.6%
KV cache8.59 GB8.59 GB30.3%
Activation workspace0.219 GB0.219 GB0.8%
Output logits0.004096 GB0.004096 GB0.0%
Gradients0 GB0 GB0.0%
Optimiser state0 GB0 GB0.0%
Overhead and runtime3.487 GB3.487 GB12.3%
Total28.36 GB28.36 GB100.0%
Memory on one device against the context length, by number of sequences
Line chart of Memory on one device (GB) against Context length per sequence (tokens, doubling at each step), 4 lines: Batch 1, Batch 8, Batch 32, Device memory. The same numbers are in the table under the chart.01,0002,0003,0004,0001k4k16k64k256k1MContext length per sequence (tokens, doubling at each step)Memory on one device (GB)
  • Batch 1 (solid line, circles)
  • Batch 8 (dashed line, squares)
  • Batch 32 (dotted line, triangles)
  • Device memory (dash-dot line, diamonds)
Show the data as a table
Memory on one device against the context length, by number of sequences
Context length per sequence (tokens, doubling at each step)Batch 1Batch 8Batch 32Device memory
1k19.120.123.680
2k19.221.328.480
4k19.523.637.880
8k20.128.456.780
16k21.337.894.580
32k23.656.717080
64k28.494.532180
128k37.817062480
256k56.73211,23080
512k94.56242,44080
1M1701,2304,86080
What if the weights were stored at another precision
Weight precisionWeights per deviceMemory on one deviceFitsSmallest serving layout
FP32 (4 bytes)32.11 GB46.02 GBYes1
BF16 or FP16 (2 bytes)16.06 GB28.36 GBYes1
FP8 (1 byte)8.028 GB19.53 GBYes1
INT8 (1 byte)8.028 GB19.53 GBYes1
INT4 (0.5 byte)4.014 GB15.11 GBYes1
Decode bandwidth needed at a range of token rates
Tokens/s for each sequencePer tensor parallel deviceAll devices togetherWithin the device bandwidth
50.1232 TB/s0.1232 TB/sYes
100.2465 TB/s0.2465 TB/sYes
200.4929 TB/s0.4929 TB/sYes
501.232 TB/s1.232 TB/sYes
1002.465 TB/s2.465 TB/sYes
2004.929 TB/s4.929 TB/sNo

How it works

Whether a model fits, and how fast it can run, is mostly a memory question. This tool adds up the weights, the KV cache, the activations, the gradients and the optimiser state, splits them across tensor, pipeline and data parallel devices with ZeRO sharding, and compares the result with the memory of one accelerator. For serving it also finds the memory bandwidth a target token rate needs, because each decoded token reads the weights and the cache.

  1. Count the parameters. Enter the parameters in billions, or let the tool count them from the architecture: embeddings (twice if the output head is not tied), then for every layer the attention projections (queries use all heads, keys and values use the KV heads), the feed-forward block (three matrices when gated, two when plain) and the norms. For a mixture of experts the feed-forward block is repeated for every expert and a router is added.attention per layer = hidden x heads x head size + 2 x hidden x KV heads x head size + heads x head size x hidden; MLP per expert = 3 (or 2) x hidden x FFN size; total = embeddings + layers x (attention + norms + experts x MLP)
  2. Treat a mixture of experts. All experts must stay in memory, so memory follows the total parameters. Each token uses only the shared parameters plus its chosen experts, so compute follows the active parameters. When you enter totals instead of an architecture, the tool separates the expert and shared parts from the total and the active figures.per-expert parameters = (total − active) / (experts − active experts); shared = total − experts x per-expert
  3. Size the weights. Weights are the parameter count times the bytes of the chosen precision: 4 for FP32, 2 for BF16, 1 for FP8 or INT8, and 0.5 for INT4. Scales for quantised formats are not counted.weights = parameters x bytes per parameter
  4. Size the KV cache. Every token of every sequence stores a key and a value in every layer. Grouped-query attention stores only the KV heads, which is why the cache is smaller than with one KV head per query head.KV cache = 2 x layers x KV heads x head size x context tokens x sequences x bytes
  5. Size the training activations. For a standard transformer layer with 16-bit activations, Korthikanti et al. count 34 sbh bytes plus 5 a s^2 b bytes stored per layer, where s is the sequence length, b the micro-batch, h the hidden size and a the heads. Of the 34, layer norms take 4, attention 11 and a feed-forward block of width 4h takes 19. Here the attention share is reduced for grouped-query attention and the feed-forward share follows the real width, with a gated block storing about 8 times its width. Selective recomputation drops the s^2 term, full recomputation keeps only each layer's input (2 sbh), and sequence parallelism splits what tensor parallelism leaves whole. The first pipeline stage holds one micro-batch per stage, so it stores the activations of all layers.per layer = s x b x h x (4 + (7 + 4 x KV heads / heads) + MLP share + 5 x a x s / h) x width / 2, divided by tensor parallel degree with sequence parallelism; selective: without the 5 a s / h term; full: 2 s b h
  6. Add gradients and optimiser state. Gradients take the weight width (never below 16 bits). Adam with FP32 master weights keeps a master copy and two moments, 12 bytes a parameter, which with 2-byte weights and gradients makes the 16 bytes a parameter that Rajbhandari et al. use. SGD with momentum keeps a master copy and one moment; plain SGD keeps only the master copy. A trainable share below 100% (an adapter) limits gradients and state to that share. The output logits and their gradient are held in FP32.gradients = trainable parameters x bytes; optimiser state = trainable parameters x (4 master + 8 Adam moments); logits = 8 x s x b x vocabulary / tensor parallel
  7. Shard across devices. Tensor and pipeline parallelism split the weights, gradients and optimiser state by their product. ZeRO then splits across the data parallel ranks: stage 1 the optimiser state, stage 2 also the gradients, stage 3 also the weights. When serving, the cache splits across the KV heads and pipeline stages, so tensor parallel degrees above the KV head count copy it.per device = weights / (tp x pp x [dp if ZeRO 3]) + gradients / (tp x pp x [dp if ZeRO 2 or 3]) + state / (tp x pp x [dp if ZeRO 1 to 3]) + activations + logits
  8. Add overhead and compare with the device. A share for fragmentation and framework buffers, and a fixed amount for the runtime, are added to the sum. The tool then reports the headroom, the smallest layout that fits, and for serving the largest number of sequences that fit at the context length.device total = sum x (1 + overhead share) + reserved memory; headroom = device memory − device total
  9. Find the decode bandwidth. One decode step produces one token for every sequence in the batch. It reads the weights it uses once, and every sequence's cache. For a mixture of experts the weights read are the shared part plus the experts the batch touches, taking routing as uniform. Pipeline stages run one after another on a token, so only tensor parallelism cuts what each device reads.bytes per step = weights used x bytes + KV cache bytes; bandwidth per device = (weights / tp + cache / min(tp, KV heads)) x tokens per second; experts touched = E x (1 − (1 − k / E)^batch)

Assumptions

  • Parameters are spread evenly across devices. Embeddings, uneven layer counts and padded dimensions make real splits a little worse.
  • The activation coefficients are Korthikanti et al.'s for a standard layer, adapted here for grouped-query attention and gated feed-forward blocks. They are an engineering estimate, not a measurement; frameworks that fuse operations store less.
  • Serving activations are a working-memory estimate (a prefill chunk plus the decode tokens, a few hidden-size and feed-forward-size buffers). Real servers allocate their own pools; measure yours.
  • Expert routing is uniform and independent between tokens, so batch decoding of a mixture of experts reads more of the model than one token does. Real routing is skewed and reads fewer experts.
  • Overhead is 10% plus 1 GB by default, an editorial allowance for fragmentation and the runtime. Replace it with a measurement from your own framework.
  • Quantised weights count their stored bits only. Scales, zero points and the layers kept at higher precision add a few percent.

Limits and warnings

  • Multi-head latent attention and other compressed caches store less than the standard formula; enter the effective KV heads and head size for those.
  • Offloading to host memory or disk, paged KV caches with shared prefixes, and speculative decoding change what is resident and what is read; none are modelled.
  • The decode bandwidth is a memory-bound estimate. Compute, communication between tensor parallel devices and kernel efficiency can set a lower token rate.
  • ZeRO-3 needs temporary full copies of a layer's weights while it runs; that buffer is inside the overhead allowance, not counted separately.
  • Training memory ignores communication buffers, data loading and checkpoint writing, which can add several gigabytes.
  • Expert parallelism, which places experts on separate devices, is not modelled; a mixture of experts is sharded like a dense model here.

Sources

The methods and default figures rest on these public sources. The wording here is our own; read the source for its full text.

Where it helps

The lifecycle stages this tool serves: 2 stages in 1 lifecycle.

Method notev1Formula, ranges, sources and limits

Sizes the weights, KV cache, activations, gradients and optimiser state of a transformer model for inference or training, shards them across tensor, pipeline and data parallel devices with ZeRO, and finds the decode bandwidth a token rate needs.

Formula

attention per layer = hidden x heads x head size + 2 x hidden x KV heads x head size + heads x head size x hidden; MLP per expert = 3 (or 2) x hidden x FFN size; total = embeddings + layers x (attention + norms + experts x MLP); per-expert parameters = (total − active) / (experts − active experts); shared = total − experts x per-expert; weights = parameters x bytes per parameter; KV cache = 2 x layers x KV heads x head size x context tokens x sequences x bytes; per layer = s x b x h x (4 + (7 + 4 x KV heads / heads) + MLP share + 5 x a x s / h) x width / 2, divided by tensor parallel degree with sequence parallelism; selective: without the 5 a s / h term; full: 2 s b h; gradients = trainable parameters x bytes; optimiser state = trainable parameters x (4 master + 8 Adam moments); logits = 8 x s x b x vocabulary / tensor parallel; per device = weights / (tp x pp x [dp if ZeRO 3]) + gradients / (tp x pp x [dp if ZeRO 2 or 3]) + state / (tp x pp x [dp if ZeRO 1 to 3]) + activations + logits; device total = sum x (1 + overhead share) + reserved memory; headroom = device memory − device total; bytes per step = weights used x bytes + KV cache bytes; bandwidth per device = (weights / tp + cache / min(tp, KV heads)) x tokens per second; experts touched = E x (1 − (1 − k / E)^batch)

Inputs
InputUnitRange it holds forComes from
Where the parameter count comes fromchoicearch, paramsYour figure
Parametersbillions0.001 to 20000Your figure
Active parameters per token, 0 for densebillions0 to 20000Your figure
Expertscount1 to 4096Your figure
Active experts per tokencount1 to 64Your figure
Layerscount1 to 400Your figure
Hidden sizevalues64 to 200000Your figure
Attention headscount1 to 1024Your figure
KV headscount1 to 1024Your figure
Head size, 0 for hidden over headsvalues0 to 1024Your figure
Feed-forward sizevalues1 to 1000000Your figure
Feed-forward blockchoicegated, plainYour figure
Vocabularytokens0 to 2000000Your figure
Output head shares the embeddingchoiceno, yesYour figure
Modechoiceinference, trainingYour figure
Weight precisionchoicefp32, bf16, fp8, int8, int4Your figure
Activation precisionchoicefp32, bf16, fp8Your figure
KV cache precisionchoicefp32, bf16, fp8, int8, int4Your figure
Sequences (inference) or micro-batch (training)sequences1 to 100000Your figure
Context or sequence lengthtokens1 to 10000000Your figure
Prefill chunk for serving workspacetokens0 to 1000000Your figure
Optimiserchoiceadam, sgd-momentum, sgdYour figure
FP32 master weightschoiceyes, noYour figure
Trainable share of parameters%0.001 to 100Your figure
Activation recomputationchoicenone, selective, fullYour figure
Sequence parallelismchoiceyes, noYour figure
Tensor parallel degreedevices1 to 4096Your figure
Pipeline parallel degreedevices1 to 1024Your figure
Data parallel degreedevices1 to 100000Your figure
ZeRO stagestage0 to 3Your figure
Accelerator presetchoicecustom, h100, b200, mi300x, tpu-v5p, gaudi3Your figure
Memory of one acceleratorentered unitfrom 1Your figure
Unit of device memorychoicegb, gib, tb, tibYour figure
Unit for resultschoicegb, gib, tb, tibYour figure
Overhead for fragmentation and buffers%0 to 100Your figure
Reserved runtime memoryGB0 to 64Your figure
Target tokens per second for each sequencetokens/s0 to 100000Your figure
Memory bandwidth of one acceleratorentered unitfrom 0Your figure
Unit of device bandwidthchoicegbs, tbsYour figure
Share of bandwidth reached%1 to 100Your figure

Outputs: Total parameters (billions); Weights, whole model (GB); KV cache, whole batch (inference) (GB); Memory on one device (GB); Devices in the layout (count); Smallest layout that fits (devices or data parallel ranks); Decode bandwidth needed on one device (TB/s); Most tokens a second for each sequence (tokens/s).

Assumptions

  • Parameters are spread evenly across devices. Embeddings, uneven layer counts and padded dimensions make real splits a little worse.
  • The activation coefficients are Korthikanti et al.'s for a standard layer, adapted here for grouped-query attention and gated feed-forward blocks. They are an engineering estimate, not a measurement; frameworks that fuse operations store less.
  • Serving activations are a working-memory estimate (a prefill chunk plus the decode tokens, a few hidden-size and feed-forward-size buffers). Real servers allocate their own pools; measure yours.
  • Expert routing is uniform and independent between tokens, so batch decoding of a mixture of experts reads more of the model than one token does. Real routing is skewed and reads fewer experts.
  • Overhead is 10% plus 1 GB by default, an editorial allowance for fragmentation and the runtime. Replace it with a measurement from your own framework.
  • Quantised weights count their stored bits only. Scales, zero points and the layers kept at higher precision add a few percent.

Uncertainty: The weight, cache, gradient and optimiser arithmetic is exact for the inputs given. Activations and serving workspace are engineering estimates and real frameworks differ by tens of percent; keep headroom of at least 10%.

Known limits

  • Multi-head latent attention and other compressed caches store less than the standard formula; enter the effective KV heads and head size for those.
  • Offloading to host memory or disk, paged KV caches with shared prefixes, and speculative decoding change what is resident and what is read; none are modelled.
  • The decode bandwidth is a memory-bound estimate. Compute, communication between tensor parallel devices and kernel efficiency can set a lower token rate.
  • ZeRO-3 needs temporary full copies of a layer's weights while it runs; that buffer is inside the overhead allowance, not counted separately.
  • Training memory ignores communication buffers, data loading and checkpoint writing, which can add several gigabytes.
  • Expert parallelism, which places experts on separate devices, is not modelled; a mixture of experts is sharded like a dense model here.

Where the method comes from

Follows Rajbhandari, Rasley, Ruwase and He, ZeRO: Memory Optimizations Toward Training Trillion Parameter Models (SC20, 2020), with Korthikanti et al., Reducing Activation Recomputation in Large Transformer Models (2022) (opens in a new tab). The platform's version departs from it as follows.

  • Adds serving: the KV cache, grouped-query attention, a workspace for activations and the decode bandwidth Why: Both papers address training memory; most sizing questions today are about serving a trained model.
  • Adapts the activation coefficients for grouped-query attention and gated feed-forward blocks, and adds the FP32 logits Why: The published coefficients are for a standard layer with a 4h feed-forward block; current models are gated and use grouped-query attention.

Reference example, checked by test: Worked example in this method note: Llama-class 8B inference (32 layers, hidden 4096, 8 KV heads of size 128, feed-forward 14,336, vocabulary 128,000) with 8 billion parameters entered, BF16 weights and cache, 8 sequences of 8,192 tokens on one 80 GB GPU. Weights are 8e9 x 2 = 16 GB; the cache is 2 x 32 x 8 x 128 x 2 = 131,072 bytes a token, times 65,536 tokens = 8.59 GB. The remaining terms are in the tool's unit test. Total parameters 8; Weights, whole model 16; KV cache, whole batch (inference) 8.58993; Memory on one device 28.2943; Devices in the layout 1; Smallest layout that fits 1; Decode bandwidth needed on one device 0.737698; Most tokens a second for each sequence 108.988.

Versions

  • v1 (2026-10-25): First version, built from the tool idea.

All models in the register

Terms on this page

Bandwidth
In meeting jargon, a person's or team's available working capacity rather than any data rate.
AI
Artificial intelligence (AI): software that learns patterns from data to classify, predict or generate, rather than following only hand-written rules.
Inference
Running a trained model on new inputs to produce outputs.
KV cache
The stored per-layer key and value tensors for tokens already processed, kept so each new token attends to the context without recomputing it.
Pipeline
In commercial jargon, the set of identified sales or design-in opportunities at various stages of maturity, weighted by probability.
Accelerator
Any specialised processor attached to a host system to run a class of work faster or more efficiently than a CPU can.
Memory bandwidth
The rate at which data can be moved between memory and a processor, quoted in GB/s or TB/s.
Cache
A small fast memory holding recently or likely used data close to the processor, normally SRAM arranged in levels L1, L2 and L3.
BF16
A 16-bit float with the same 8-bit exponent as FP32 but only 7 mantissa bits, so it covers the full FP32 dynamic range and can be converted by truncation.
FP8
An 8-bit float defined by OCP in two variants, E4M3 favouring precision and E5M2 favouring range, used with per-tensor scaling or, in the OCP MX formats, a shared scale per block of 32 values, for...
INT8
An 8-bit signed integer format used with per-tensor or per-channel scale factors for neural network inference.
INT4
A 4-bit integer format used for aggressive weight-only quantisation of large language models, typically with group-wise scales.

The full glossary

Need help acting on this?

Tell us what you're after and leave your email: we'll connect you with the right person on the Hub.