Skip to content
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

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.