Training Time Estimator
Estimate training time, GPU hours, and cost for large language models. Calculate based on dataset size, model parameters, GPU type, and cluster size.
Training Time Estimator
Calculator
Adjust values & calculateEnter your values below. Every result is computed in your browser — no data is sent to any server.
Formula: Training Time = 6 × Parameters × Dataset Tokens / (GPU TFLOPS × Num GPUs × MFU)
Worked example — ~19 days | 29,491 GPU hours | ~$74K at an assumed $2.50/GPU-hr (before scaling overhead)
Formula
Training Time = 6 × Parameters × Dataset Tokens / (GPU TFLOPS × Num GPUs × MFU)
The factor 6 accounts for forward pass (2N FLOPs per token) and backward pass (4N FLOPs per token). MFU (Model FLOPs Utilization) is typically 30-50% of theoretical peak. Multi-GPU scaling efficiency decreases with GPU count due to communication overhead.
Worked Examples
Example 1: Training 7B Model on 1T Tokens
Problem:Estimate training time and cost for a 7B parameter model on 1 trillion tokens using 64× H100 GPUs.
Solution:Total FLOPs = 6 × 7×10⁹ × 1×10¹² = 4.2×10²² FLOPs H100 compute = 989 TFLOPS × 64 GPUs × 0.40 MFU = 25,319 TFLOPS Time = 4.2×10²² / (25,319×10¹²) = 1.66×10⁶ seconds ≈ 19.2 days GPU hours = 19.2 × 24 × 64 = 29,491 hours At an assumed rental rate of $2.50 per GPU-hour: 29,491 × $2.50 = $73,728
Result:~19 days | 29,491 GPU hours | ~$74K at an assumed $2.50/GPU-hr (before scaling overhead)
Example 2: Fine-tuning 13B Model
Problem:Fine-tune a 13B model on 10 billion tokens using 8× A100 80GB GPUs.
Solution:Total FLOPs = 6 × 13×10⁹ × 10×10⁹ = 7.8×10²⁰ FLOPs A100 compute = 312 TFLOPS × 8 × 0.40 = 998.4 TFLOPS Time = 7.8×10²⁰ / (998.4×10¹²) = 781,250 seconds ≈ 9 days At an assumed rental rate of $1.60 per GPU-hour: 9 × 24 × 8 × $1.60 = $2,765
Result:~9 days | ~$2,800 at an assumed $1.60/GPU-hr
Frequently Asked Questions
How is LLM training time estimated?
Training time is estimated using the formula: Time = 6NDP / (GPU_FLOPS × num_GPUs × MFU), where N is model parameters, D is dataset tokens, P is number of passes (epochs). The factor 6 accounts for forward and backward pass FLOPs. MFU (Model FLOPs Utilization) typically ranges from 30-50%, representing the fraction of theoretical GPU performance achieved in practice. Communication overhead between GPUs further reduces effective throughput at scale.
What is Model FLOPs Utilization (MFU)?
MFU measures how efficiently training uses the GPU's theoretical compute capacity. An MFU of 40% means the training uses 40% of the GPU's peak TFLOPS. Factors reducing MFU include: memory bandwidth bottlenecks, data loading, gradient synchronization between GPUs, attention computation overhead, and kernel launch latency. Well-optimized codebases (Megatron-LM, DeepSpeed) on modern GPUs achieve 40-55% MFU. Flash Attention and tensor parallelism help improve MFU.
How does multi-GPU scaling work?
Adding more GPUs reduces training time but with diminishing returns due to communication overhead. Data parallelism (splitting batches across GPUs) scales well to 8-64 GPUs with 85-95% efficiency. Beyond that, tensor parallelism (splitting layers) and pipeline parallelism (splitting model stages) are needed. At 1000+ GPUs, scaling efficiency may drop to 60-70%. The communication-to-computation ratio is the key bottleneck — faster interconnects (NVLink, InfiniBand) help maintain efficiency.
How much does it cost to train a large language model?
Cost is best derived from the same compute budget rather than quoted from headline figures, most of which are third-party estimates rather than published accounts. Multiply 6 times parameters times tokens to get total FLOPs, divide by the aggregate throughput of the cluster at your assumed MFU to get accelerator-hours, then multiply by the rental rate per accelerator-hour. Worked through on this page, a 7-billion-parameter model on 1 trillion tokens comes to roughly 29,000 H100-hours, so the answer moves with the hourly rate you can actually obtain. Add data preparation, failed runs, evaluation and engineering time, none of which appear in the arithmetic and all of which are real.
Why does the 6ND rule understate cost at long sequence lengths?
The 6 FLOPs per parameter per token approximation counts only the matrix multiplications whose cost scales with the parameter count. Self-attention adds a term that scales with the square of the sequence length rather than with parameters, because every token attends to every other token. At a context of 2,048 tokens that term is a small fraction of the total for a multi-billion-parameter model and the approximation holds well, but as context grows to tens of thousands of tokens the attention term stops being negligible and the estimate here reads low. Mixture-of-experts models break the rule in the opposite direction, since only a subset of parameters is active per token.
Why does training need far more VRAM per parameter than inference?
Inference holds only the weights, two bytes per parameter in half precision. Training also holds a gradient for every weight, another two bytes, plus the AdamW optimizer state: a first moment, a second moment and usually a full-precision master copy of the weights, four bytes each. That is roughly sixteen bytes per parameter before activations, or eighteen if gradients are also accumulated in full precision, which is the figure the VRAM estimate above uses. Either way a 7-billion-parameter model needs on the order of 100 GB of state and cannot train on one 80 GB accelerator without sharding or offload.
How many training tokens should a model of a given size see?
The Chinchilla result from Hoffmann and colleagues found that, for a fixed compute budget, parameters and training tokens should grow in roughly equal proportion, which works out near twenty tokens per parameter at the compute-optimal point. A 7-billion-parameter model therefore sits close to optimal around 140 billion tokens. Teams routinely train well past that ratio anyway, because a smaller model trained on more data is cheaper to serve for the rest of its life even though the training run costs more.
What does gradient checkpointing cost in extra training time?
Also called activation recomputation, it discards intermediate activations during the forward pass and regenerates them when the backward pass needs them. Memory for activations drops sharply, which is often what makes a long sequence length or a larger micro-batch fit at all. The price is one extra forward pass: instead of about 6 FLOPs per parameter per token the step costs around 8, so expect roughly a third more compute time in exchange for the memory headroom.
How does parameter-efficient fine-tuning such as LoRA change the estimate?
LoRA freezes the base weights and trains small low-rank adapter matrices. The forward pass still runs through the entire model and gradients still flow backward through every layer, so compute falls only from about 6 FLOPs per parameter per token to roughly 4, since gradients with respect to the frozen weights are never formed. The dramatic saving is memory: no optimizer moments or master copies for the frozen weights, which is what lets a large model fine-tune on a single accelerator.
Why do real training runs overshoot the calculated wall-clock time?
The formula prices arithmetic only. A production run also writes checkpoints periodically, and the larger the model the longer each write stalls the cluster. Nodes fail, and at thousand-accelerator scale failures are frequent enough that jobs regularly roll back to the last checkpoint and repeat work. Add evaluation passes, data pipeline stalls when loaders cannot keep the accelerators fed, and restarts after divergence, and the finished run commonly lands between 1.5 and 3 times the ideal figure.
References
Background & Theory
History
Reviewed for accuracy by Daniel Agrici, Founder & Lead Developer · Editorial policy
Related Calculators
🧮Bandwidth Time Transfer Calculator
Calculate bandwidth time transfer with inputs, formulas, and instant results.
🧮Download Time Calculator
Calculate download time with inputs, formulas, and instant results.
🧮Upload Time Calculator
Calculate upload time with interactive inputs and clear steps.
🧮Website Page Weight Load Time Calculator
Calculate website page weight load time with interactive inputs and clear steps.
🧮Page Load Time Calculator
Calculate page load time with inputs, formulas, and instant results.
🧮Ping Time Calculator
Calculate ping time with inputs, formulas, and instant results.
🧮CI/CD Pipeline Time Calculator
Estimate CI/CD pipeline execution time from build, test, and deploy stage durations.
🧮Fine Tuning Cost Calculator
Estimate the cost of fine-tuning an LLM based on training tokens, epochs, and model size.