🖥️ GPU Memory Calculator
Wondering if your model will fit on your GPU? Enter the parameter count, batch size, precision, and optimizer to estimate the VRAM training needs — with each part broken out.
🧮 Estimate Training VRAM
What is a GPU Memory Calculator?
Training a neural network needs far more GPU memory than just storing the model. This calculator breaks the demand into its four pieces — parameters, gradients, optimizer state, and activations — so you can see where the memory goes and why a model that looks small can still overflow a card.
It's a hands-on way to learn the levers that make models fit: lowering precision, choosing a lighter optimizer, or shrinking the batch size. Adjust an input and watch the total move to build real intuition for training on limited hardware.
❓ Frequently Asked Questions
How is GPU memory for training estimated?
The tool adds up four contributions. The parameters themselves take (params × bytes-per-param); their gradients take the same again; the optimizer state adds a multiple of that (0× for plain SGD, 1× for momentum, 2× for Adam, which stores two running averages); and activations add roughly 0.1 × the parameter bytes per sample in the batch. Summing these gives a planning estimate of the VRAM a training step needs.
Why does the optimizer change the memory so much?
Optimizers keep extra copies of information for every parameter. Plain SGD keeps none, momentum keeps one velocity buffer, and Adam keeps two — a running mean and variance — so on top of the parameters and their gradients, Adam roughly doubles the per-parameter memory. That's why switching optimizer, or using memory-saving variants, is one of the first levers engineers pull when a model won't fit on a GPU.
How does precision (bytes per parameter) affect it?
Precision is a straight multiplier. Training in fp32 uses 4 bytes per parameter; fp16 or bf16 uses 2, halving the parameter, gradient, and activation memory; fp8 uses 1. Mixed-precision training is popular precisely because it can roughly halve memory and speed things up with little loss in quality. Change the bytes-per-parameter dropdown to see the effect instantly.
Will my model actually fit in this much memory?
Treat the result as a lower-bound planning figure, not a guarantee. Real frameworks add overhead for memory fragmentation, cached kernels, temporary buffers, and the CUDA context itself, and techniques like gradient checkpointing or activation offloading change the picture. Leave healthy headroom above the estimate — if the number is close to your card's capacity, assume you'll need optimisations to fit.