induwara.lk
induwara.lkAI · Scaling Laws

AI Compute-Optimal (Chinchilla) Calculator

Turn a training-compute budget into the compute-optimal model size and token count using Chinchilla's 20-tokens-per-parameter rule and the C = 6ND relation. Or check a planned model for its estimated loss and whether it is under- or over-tokened. Free, no signup, sources cited.

By Induwara AshinsanaUpdated Jul 10, 2026
Compute-Optimal Calculator

Accepts scientific notation, e.g. 1e21.

Presets
Optimal parameters (N)
2.89B
2.89e9 params
Optimal tokens (D)
57.7B
5.77e10 tokens
Tokens per parameter
20:1
Chinchilla target ≈ 20:1
Compute budget
1.00e21
11.6 PFLOP-days

A 1.00e21 FLOPs budget is compute-optimal at 2.89B parameters trained on 57.7B tokens.

Cross-check: 6 · N · D = 1.00e21 FLOPs — matches your 1.00e21 budget.

Reference budgets

Compute (FLOPs)Optimal NOptimal D
1.00e19289M5.77B
1.00e20913M18.3B
1.00e212.89B57.7B
1.00e229.13B183B
1.00e2328.9B577B
1.00e2491.3B1.83T

For dense transformers. Sources: Hoffmann et al. 2022 (arXiv:2203.15556) and Kaplan et al. 2020 (arXiv:2001.08361), cited in full below. Estimates for planning only — real runs vary with architecture, data quality, and optimizer.

How it works

For a dense transformer, training compute in FLOPs is well approximated by C ≈ 6·N·D — where N is the parameter count and D is the number of training tokens. The factor 6 comes from Kaplan et al. (2020): about 2 FLOPs per parameter per token on the forward pass and 4 on the backward pass. Attention and embedding costs are small at scale and folded into the approximation.

Hoffmann et al. (2022) — the “Chinchilla” paper — trained hundreds of models across compute budgets and found that loss is minimised, for a fixed budget, when the token count is roughly 20 times the parameter count. Substituting D = 20·N into the compute relation gives C = 120·N², so the calculator solves:

  • N_opt = √(C / 120)
  • D_opt = 20 × N_opt

Budgets given in PFLOP-days are converted with 1 PFLOP-day = 10¹⁵ × 86,400 = 8.64×10¹⁹ FLOPs. GPU-hours are converted from the cluster spec: C = peak_FLOP/s × GPUs × hours × 3600 × (MFU / 100), where MFU (Model FLOPs Utilization) discounts peak throughput to the fraction a real training loop sustains — typically 35–55%.

Check mode estimates the loss of a planned model with Chinchilla's parametric fit L(N,D) = 1.69 + 406.4/N^0.34 + 410.7/D^0.28. The first term is the irreducible entropy of natural text; the second penalises too few parameters; the third penalises too little data. It then classifies the token-to-parameter ratio: below ~15 is under-tokened, ~15–25 is compute-optimal, and above ~25 is over-tokened (common and often deliberate for inference-cheap models). Every result is cross-checked by recomputing 6·N·D and confirming it matches the input budget.

Worked examples

Budget of 10²¹ FLOPs

≈ 11.6 PFLOP-days

  1. N_opt = √(1e21 / 120) = √(8.333e18) = 2.887e9 → 2.89B params
  2. D_opt = 20 × 2.887e9 = 5.774e10 → 57.7B tokens
  3. Cross-check C = 6 × 2.887e9 × 5.774e10 = 1.00e21 ✓
  4. Tokens per parameter = 20:1 → compute-optimal

8×H100 cluster, 30 days, 40% MFU

GPU-hours → FLOPs

  1. Effective FLOP/s = 8 × 9.89e14 × 0.40 = 3.165e15
  2. Seconds = 30 days × 86,400 = 2.592e6
  3. C = 3.165e15 × 2.592e6 = 8.20e21 FLOPs
  4. N_opt = √(8.20e21 / 120) = 8.27e9 → 8.27B params
  5. D_opt = 20 × 8.27e9 = 1.65e11 → 165B tokens

Check a Llama-style plan: 7B on 1.4T tokens

Edge case — deliberately over-tokened

  1. Ratio = 1.4e12 / 7e9 = 200 tokens per parameter
  2. 200 ≫ 25 → verdict: over-tokened
  3. Loss ≈ 1.69 + 406.4/(7e9)^0.34 + 410.7/(1.4e12)^0.28 ≈ 2.04 nats
  4. Past the training-compute optimum, but cheaper to serve — a valid inference-first choice

Frequently asked questions

Sources & references

Constants (the 20:1 ratio, the 6ND factor, and the loss-fit parameters E, A, α, B, β) were last cross-checked against the Chinchilla and Kaplan papers on 2026-07-10. This tool covers dense transformer pre-training only.

Related tools

Rate this tool
Be the first to rate

Comments & feedback

Spotted a bug or want an improvement? Tell us — our team reviews every comment, and good ideas get built. Comments are public and anonymous.

Found a bug, edge case, or want to suggest an improvement?

Email me at [email protected] — most fixes ship within 24 hours.