Training Time and Cost Calculator
Inputs
| Total training FLOPs | 5.88e23 |
|---|---|
| Model FLOPs utilization | 40 % |
| Number of GPUs | 1,024 |
| Peak throughput per GPU | 989 |
| GPU hourly price | 2.5 $ |
Training Time and Cost Calculator
Estimate how long an LLM training run takes and what it costs, from total training FLOPs, GPU count, per-GPU peak TFLOP/s, model FLOPs utilization, and the hourly GPU price.
Inputs
Workload
Cluster
Results
Enter a value to see results.
Training Time and Cost
Training a large language model is a fixed amount of arithmetic spread across a cluster of accelerators, so its duration and its bill are both predictable once the work and the hardware are known. This calculator estimates the wall-clock time and the GPU-hour cost of a run from the total training FLOPs, the number of GPUs, each GPU's peak throughput, the model FLOPs utilization, and the hourly rental price.
What the estimate covers
The total floating-point work of a training run is well approximated by a single quantity, often written as six times the parameter count times the number of training tokens. Once that total is fixed, the only thing that changes the schedule is how fast the cluster can grind through it. A cluster's sustained rate is the sum of its accelerators' peak rates scaled down by the fraction they actually use, the model FLOPs utilization. Dividing the work by that rate gives the time, and multiplying the time by the GPU count and the hourly price gives the cost.
The formula
With total work in FLOPs, accelerators each rated at TFLOP/s, a utilization , and an hourly price per GPU, the run time and total cost are
tT=n⋅P⋅1012⋅UC=3600t⋅n⋅cThe factor converts TFLOP/s to FLOP/s, so is expressed in units of seconds; dividing by 3600 turns it into GPU-hours before pricing. Doubling the number of GPUs halves the time but leaves the GPU-hour cost unchanged, because the same total work is simply finished sooner.
Worked example
Take a run of FLOPs on 1,024 accelerators rated at 989 TFLOP/s each, sustaining 40% utilization, rented at 2.50 per GPU per hour:
tT=1024×989×1012×0.45.88×1023≈1.45×106 s≈16.8 days=36001.45×106×1024×2.50≈1,032,000The run takes roughly seventeen days and costs a little over a million in GPU rental. Raising utilization from 40% to 50% would cut both the time and the cost by a fifth, which is why squeezing more out of the same hardware is the cheapest optimization available.
Limits
The estimate assumes the run is compute bound and that the utilization figure already averages over the whole job. It excludes checkpoint writes, data-loading stalls, restarts after hardware failures, validation passes, and the idle time of a reservation held but not computing. Networking, storage, and the difference between spot and reserved pricing also move the real total. Treat the result as a planning baseline and add a margin for overhead. The total work that feeds this calculation is derived in the Training FLOPs Calculator, and the pure rental side of the bill in the GPU Cloud Cost Calculator.
Frequently Asked Questions (FAQ)
How is the training time estimated?
The total floating-point work of the run is divided by the rate the cluster can sustain. That rate is the number of GPUs times each GPU’s peak TFLOP/s times the model FLOPs utilization, converted to operations per second. Dividing the total operations by this sustained rate gives the wall-clock seconds, which the calculator reports in days, hours, or minutes.
The estimate assumes the run is compute bound and that the utilization figure already captures the average efficiency across the whole job.
What utilization value should be used?
Model FLOPs utilization is the share of theoretical peak throughput a run actually achieves. For large-model training on well-tuned systems it commonly falls between 35% and 55%, with 40% a reasonable default. Smaller models, short sequences, heavy communication, or unoptimized kernels push it lower.
Because time scales inversely with utilization, halving it doubles the projected schedule, so a measured value from a short profiling run gives a far better estimate than a guess.
Why might the real bill differ from this estimate?
The estimate counts only steady-state compute at the chosen utilization. Real runs add checkpoint writes, data-loading stalls, restarts after failures, validation passes, and idle time while a reservation is held but not computing.
Spot or reserved pricing, networking and storage charges, and a utilization that drifts over the run also move the total. Treat the figure as a planning baseline and add a margin for overhead rather than reading it as a precise invoice.
Disclaimer
This estimate assumes a compute-bound run at a constant model FLOPs utilization and excludes checkpointing, data-loading stalls, restarts, networking, and storage. Actual time and cost vary with hardware, software stack, and pricing model; treat the result as a planning baseline.