Training Time Estimator

The training time estimator predicts how long it will take to train an AI model and how much that training run will cost on rented cloud GPUs. Training a large language model is one of the most expensive and time-consuming steps in the entire machine learning lifecycle, and the difference between a good plan and a bad one can be measured in weeks of wall-clock time and tens of thousands of dollars. This tool takes five numbers you already know about your project — model size in billions of parameters, dataset size in tokens, GPU type, the number of GPUs, and the training precision — and turns them into an estimated training duration, a cloud cost estimate, an effective throughput in tokens per second, and a multi-GPU scaling efficiency.

The headline output is the estimated training time, formatted automatically into minutes, hours, days, or weeks depending on scale, alongside an approximate cloud bill. Below that, the calculator reports the aggregate throughput your cluster achieves, the hourly cost of the GPU fleet, and a multi-GPU efficiency figure that captures the communication overhead of distributed training. It also flags whether your dataset size is near the Chinchilla-optimal token budget for your model, a research-backed guideline that helps you avoid both undertraining and wasteful overtraining.

Why estimate training time before you start? Because GPUs are billed by the hour and the largest single line item in most AI budgets is compute. A 7-billion-parameter model trained on a billion tokens might finish in a few hours on a handful of A100s, while a frontier-scale pretraining run can occupy thousands of accelerators for months. Knowing the ballpark up front lets you size your cluster, choose between an H100 and a cheaper RTX 4090, decide whether mixed precision is worth enabling, and forecast spend before you ever submit a job. The GPU training time and LLM training cost figures this estimator produces are exactly the inputs a team needs to plan a run, request a budget, or compare two hardware options side by side.

The estimator builds training time from throughput. It starts with a base per-GPU throughput in tokens per second that depends on the chosen GPU and precision, then scales it for model size, the number of GPUs, and a multi-GPU efficiency penalty. The core idea is simple: total training time equals total tokens divided by how many tokens per second the whole cluster can actually process.

First, a size multiplier adjusts the base throughput because larger models are slower per token. The tool uses the square root of the ratio of a 7B reference model to your model's parameter count, so a 28B model runs at half the per-token speed of a 7B model. Next, the per-GPU throughput is multiplied by the GPU count and by an efficiency factor that drops by three percentage points per additional GPU (floored at 70%) to reflect the communication overhead of data-parallel and tensor-parallel training. Dividing total tokens by this adjusted throughput yields seconds, which are converted to hours and days.

Throughput is the engine of every training-time estimate. The calculator stores a base tokens-per-second figure for each supported GPU at each precision, reflecting that newer accelerators and lower-precision arithmetic both deliver dramatically more work per second. BF16 and FP16 mixed precision roughly quadruple throughput over FP32 full precision on the same hardware, which is why almost every modern training pipeline uses mixed precision by default. The table below lists the per-GPU tokens-per-second assumptions used by this tool.

These are deliberately conservative, planning-grade numbers for a 7B reference model. The aggregate throughput shown in the result is the per-GPU figure scaled by your model size, your GPU count, and the efficiency factor. Because throughput sits in the denominator of the time formula, anything that raises it — a faster GPU, a lower precision, more GPUs, or a smaller model — cuts training time proportionally. Switching from FP32 to BF16 alone can shrink a multi-day run into a single day on the same hardware.

Adding GPUs speeds up training, but not perfectly. In an ideal world, doubling the number of accelerators would halve the training time, a property called linear scaling. In practice, distributed training spends time synchronizing gradients across devices, and that communication overhead grows as the cluster gets larger. The estimator models this with an efficiency factor that starts at 100% for a single GPU and falls by three percentage points for each additional GPU, never dropping below a 70% floor.

Concretely, a single GPU runs at 100% efficiency, 8 GPUs run at about 79%, and 16 or more GPUs are pinned to the 70% floor. This means the aggregate throughput from a large cluster is always somewhat less than the simple sum of its parts. The effect is visible in the result panel as the "Multi-GPU Efficiency" percentage, and it is why throwing more hardware at a problem yields diminishing returns past a certain point. Real-world scaling depends heavily on interconnect bandwidth — NVLink and InfiniBand clusters scale far better than commodity PCIe setups — so treat the efficiency figure as a reasonable middle-of-the-road estimate rather than a guarantee.

The practical takeaway for distributed training planning is to balance speed against cost. Because the hourly cost rises linearly with GPU count while the speedup is sublinear, the cost of a training run is fairly stable as you add GPUs — you mostly trade money-now for time-saved. If a deadline is the constraint, more GPUs finish the job sooner at a modest efficiency penalty. If the budget is the constraint and the schedule is flexible, a smaller, cheaper cluster of consumer cards can deliver nearly the same total cost over a longer wall-clock window.

How many tokens should you actually train on? The DeepMind Chinchilla study found that for compute-optimal training, the dataset should contain roughly 20 tokens per parameter. This estimator applies that rule directly: it computes a Chinchilla-optimal target of model parameters times 20 and tells you whether your configured dataset falls within 10% of that target. A 7B model, for example, is compute-optimal at around 140 billion tokens.

The Chinchilla flag is a guardrail against two common mistakes. Undertraining — using far fewer than 20 tokens per parameter — leaves model quality on the table because the network never sees enough data to fill its capacity. Overtraining beyond the optimum is not wrong, and many deployed models train past Chinchilla to squeeze out extra quality, but it costs proportionally more compute for diminishing gains. Seeing the optimal token count next to your own dataset size helps you decide whether to gather more data, prune your corpus, or proceed as configured.

On the cost side, the estimator multiplies an hourly per-GPU rental rate by the number of GPUs to get an hourly fleet cost, then multiplies by the estimated training hours for a total cloud cost estimate. These rates approximate on-demand cloud pricing and can be cut substantially with spot or reserved instances. Because cost equals hourly rate times hours, and hours fall as throughput rises, the cheapest configuration is often not the cheapest GPU — a fast H100 that finishes in a third of the time can undercut a slow card billed for three times as long. Run a few combinations through the LLM training cost estimate to find the sweet spot for your model size, dataset, and deadline before you commit real budget.