Papers
Topics
Authors
Recent
Search
2000 character limit reached

How to Allocate Your Tokens? Scaling Laws with Training Steps and Batch Size

Published 1 Jul 2026 in cs.LG and stat.ML | (2607.01487v1)

Abstract: We propose a scaling law that takes into account model size and training data while explicitly splitting the latter into training steps and batch size (called three-term law). Fitting the proposed law on a large set of training runs, we find that it correctly recovers the scaling of the optimal batch size. Moreover, because it makes use of training runs with suboptimal batch size, our proposed law can be robustly fit with a significantly smaller amount of training runs. We further show that the three-term law can be used to derive scaling laws for suboptimal batch sizes, and that it matches previous empirical findings related to the critical batch size.

Authors (1)

Summary

  • The paper introduces a three-term scaling law that models LLM loss as a function of model size, batch size, and training steps.
  • It demonstrates that optimal batch size scales with dataset size and drastically reduces the need for exhaustive hyperparameter tuning.
  • Empirical validation shows improved predictive accuracy even under suboptimal hardware constraints, offering practical guidance for compute allocation.

A Unified Scaling Law for Model Size, Training Steps, and Batch Size in LLM Training

Introduction

The extensive empirical investigation “How to Allocate Your Tokens? Scaling Laws with Training Steps and Batch Size” (2607.01487) proposes a unified power-law scaling framework for LLM pretraining that decomposes dataset size into training steps and batch size, effectively interpolating between classical Chinchilla-style scaling and batch size scaling analyses. This work substantially broadens the operational applicability of scaling laws, enabling robust loss prediction and compute allocation not only for optimal but also suboptimal hyperparameter choices, and reducing the empirical burden for scaling law estimation.

Three-Term Power Law and Its Theoretical Rationale

The principal contribution is the introduction of a three-term scaling law for the final loss L\mathcal{L} as a function of model size NN (parameter count), batch size MM (in tokens), and number of training steps KK:

L(N,M,K)=E+ANα+BMβ+CKγ\mathcal{L}(N, M, K) = E + \frac{A}{N^\alpha} + \frac{B}{M^\beta} + \frac{C}{K^\gamma}

This approach decouples training data size DD as D=MKD = MK and differentiates between sample efficiency (controlled by MM and KK) and model efficiency (NN) in loss reduction. The formulation is tightly linked with convergence results from stochastic optimization, where loss typically exhibits power-law decrease with NN0 and NN1 under optimal schedules.

The law naturally subsumes the canonical Chinchilla law when NN2 is optimized, and plug-in optimal batch size NN3 (with corresponding NN4) yields a two-term law in NN5 with reparametrized data scaling, aligning with Chinchilla functional form. The law thereby bridges empirical scaling analyses and theoretically-grounded optimization limits.

Empirical Validation and Comparison with Alternative Laws

A comprehensive study on two large-scale LLM training datasets (the Li dataset [Li2025] and OpenEuroLLM) establishes several empirical findings:

  • The three-term law recapitulates the scaling of the optimal batch size NN6 observed in prior work, demonstrating that NN7 scales roughly as NN8 and is independent of NN9 in the regimes tested, in agreement with state-of-the-art hyperparameter scaling analyses.
  • Fitting the three-term law is highly data-efficient: with only two batch size values per MM0, the resulting estimate of the optimal batch size scaling is robust, significantly reducing the compute requirements compared to exhaustive batch size sweeps. Figure 1

Figure 1

Figure 1: Estimates for MM1-scaling coefficient MM2 and implied scaling law for MM3 compared against the empirical best.

The mean absolute deviation (MAD) analysis (Figure 2) shows that the three-term law achieves better out-of-sample error than model-size-specific two-term laws, even as the number of parameters grows. Figure 2

Figure 2

Figure 2: MAD comparison of three-term and two-term laws on train (left) and validation (right) splits.

Even on datasets with incomplete batch size sweeps, the law retains its predictive power. Reducing the Li dataset to 42% and 28% of its runs does not substantially alter the scaling exponent of MM4 (see Figure 3), in stark contrast to direct fitting of MM5 which becomes highly unstable. Figure 3

Figure 3

Figure 3: Scaling law fits for MM6 with reduced dataset size (42% of batch size values per sweep).

Modeling Suboptimal and Critical Batch Size Regimes

A significant practical concern is characterization of loss behavior at suboptimal batch sizes induced by hardware constraints. The three-term law models loss for arbitrary MM7 allocations, not just the optimum, enabling derivation of loss envelopes and the range of batch sizes that incur at most an MM8-fraction compute regret.

Where higher accuracy is required, a two-stage fitting procedure is introduced:

  1. For fixed MM9, fit the cross-section loss as a function of KK0 via a two-parameter power law.
  2. Model the interval KK1 where loss remains within a small excess of the minimum, showing this interval remains stable and scalable (see Figure 4). This provides a practical prescription for batch size selection when hardware is limiting. Figure 5

Figure 5

Figure 5: For KK2M, the three-term law predicts optimal batch size, but is less accurate in loss value at boundaries of token budget.

Figure 4

Figure 4

Figure 4: Batch size range KK3 with KK4-suboptimal loss derived for KK5M.

An important theoretical consequence is the recovery of critical batch size phenomena: under the three-term law, the number of steps to achieve a fixed target loss is invariant to KK6 but increases with KK7, precisely mirroring empirical investigations of critical batch size scaling, and offering an explanation why earlier critical batch size theories which predict optimal batch size of one are inadequate for practical LLM training. Figure 6

Figure 6

Figure 6

Figure 6: Function KK8 at Chinchilla-optimal scaling, showing critical batch size varies with KK9 but not with L(N,M,K)=E+ANα+BMβ+CKγ\mathcal{L}(N, M, K) = E + \frac{A}{N^\alpha} + \frac{B}{M^\beta} + \frac{C}{K^\gamma}0.

Optimal Compute Allocation and Limitations

While the three-term law reduces to a Chinchilla-style prediction for loss vs. L(N,M,K)=E+ANα+BMβ+CKγ\mathcal{L}(N, M, K) = E + \frac{A}{N^\alpha} + \frac{B}{M^\beta} + \frac{C}{K^\gamma}1 when L(N,M,K)=E+ANα+BMβ+CKγ\mathcal{L}(N, M, K) = E + \frac{A}{N^\alpha} + \frac{B}{M^\beta} + \frac{C}{K^\gamma}2 is optimal, inferred optimal model size scaling can differ from direct Chinchilla law fitting, especially in terms of data scaling exponents, highlighting that the choice of scaling law formulation affects optimal compute allocation. Consequently, accurate prediction of compute-optimal L(N,M,K)=E+ANα+BMβ+CKγ\mathcal{L}(N, M, K) = E + \frac{A}{N^\alpha} + \frac{B}{M^\beta} + \frac{C}{K^\gamma}3 pairs remains sensitive to model design.

Implications, Limitations and Future Work

The three-term law offers a practical tool for:

  • Predicting LLM loss for arbitrary (even suboptimal) allocations of dataset into batch size and training duration, informing training under hardware constraints.
  • Drastically reducing empirical effort needed for estimating hyperparameter scaling laws, making such estimation tractable for new model classes or architectures.
  • Providing a unified framework for theory-grounded scaling laws that incorporate both model size and optimizer hyperparameters.

Limitations include:

  • Quantitative discrepancies between datasets can arise due to varying training protocols; generalization to all architectures or regimes requires further study.
  • The law does not explicitly model learning rate, which may modulate scaling in certain regimes.
  • While optimal batch size is well-predicted, suboptimal performance envelopes require careful two-stage fitting, especially for high accuracy.

Extensions could incorporate learning rate scaling (as in [Shulgin2026], [Bjorck2024]) or modifications for different optimizer families (e.g., Muon [EssentialAI2025]), and analyze impacts in other modalities and tasks.

Conclusion

This work presents a three-term scaling law that subsumes and extends both the Chinchilla law and batch size scaling analyses, offering a unified, robust, and compute-efficient approach to managing data allocation in LLM training. It provides strong empirical support, theoretical justification, and actionable prescriptive guidance for practitioners and scaling law theorists alike, while highlighting the importance of law formulation in calculating truly compute-optimal training regimes.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

How to Allocate Your Tokens? Scaling Laws with Training Steps and Batch Size — A Simple Guide

What is this paper about?

This paper is about finding a smart way to train large AI LLMs (like chatbots) using a fixed amount of text, called “tokens.” It asks: if you have a certain number of tokens to train with, how should you split them between:

  • how many examples you show the model at once (the batch size), and
  • how many times you update the model (the number of training steps), so that you get the best results?

The authors propose a simple formula—called a “scaling law”—that predicts how performance changes as you vary model size, batch size, and training steps. Then they test whether this formula matches real training behavior.


What questions are the authors trying to answer?

In easy terms, the paper tackles four main questions:

  1. Can we build a single, simple rule that explains how model performance depends on:
    • model size (NN = how big the model is),
    • batch size (MM = how many tokens per step), and
    • training steps (KK = how many updates)?
  2. If we only know our total token budget (DD), what is the best batch size to use?
  3. Can we learn this rule without running lots of expensive training experiments (saving time, money, and energy)?
  4. If we can’t use the best batch size (because of hardware limits), how much performance do we lose—and what range of “pretty good” batch sizes still wastes little compute?

How did they study this? (Methods in everyday language)

Think of training a model like baking lots of cookies:

  • Model size NN = how big your oven is.
  • Total tokens DD = how much dough you have (total ingredients).
  • Batch size MM = how many cookies you bake at once (trays in the oven).
  • Steps KK = how many rounds you bake.

You can split your dough into larger batches (big MM, fewer rounds KK) or smaller batches (small MM, more rounds KK), as long as D=M×KD = M \times K (total cookies baked stays the same).

The authors propose a simple performance formula:

  • Loss (lower is better) = E + A/Nα + B/Mβ + C/Kγ

In symbols:

  • L(N,M,K)=E+ANα+BMβ+CKγL(N, M, K) = E + \frac{A}{N^\alpha} + \frac{B}{M^\beta} + \frac{C}{K^\gamma}
  • With D=M×KD = M \times K (your fixed token budget)

What this means:

  • Bigger models help (NN up ⇒ loss down).
  • Larger batch size helps—but only to a point (MM up ⇒ loss down).
  • More training steps help—but also with diminishing returns (KK up ⇒ loss down).

They tested this formula using two large collections of real training runs (“Li” and “OpenEuroLLM”), where many models were trained with different sizes, token budgets, and batch sizes. They compared two approaches:

  • A “three-term law” (one shared formula across all model sizes: depends on NN, MM, KK).
  • A “two-term law” (one formula per model size: depends on MM, KK only).

They also tried training with only a few batch sizes per setup to see if they could still discover the right rule—this simulates saving compute in practice.

Finally, they studied a real-world idea called the “critical batch size”: the point beyond which increasing batch size no longer speeds up training much.


What did they find, and why does it matter?

Here are the main takeaways:

  • The new three-term formula works and gives a clear rule for the best batch size.
    • If total tokens are DD, the best batch size grows roughly like D0.550.60D^{0.55\text{–}0.60}.
    • Importantly, the best batch size does not depend on model size NN—it mainly depends on how many total tokens you plan to use.
    • This matches earlier studies, but here it naturally falls out of a single formula that also predicts the final loss.
  • You don’t need tons of expensive experiments to learn this rule.
    • Using the three-term formula, the authors could get almost the same best-batch-size rule using only two batch sizes per setup.
    • That cut the number of required training runs to about 28% of the full set. That’s a big compute and energy savings.
  • The formula also helps when you can’t use the best batch size.
    • Hardware might force you to use smaller or larger batches.
    • The authors show a two-stage method to estimate a “good enough” range of batch sizes that wastes at most about 5% extra compute.
    • As a rough rule of thumb, the acceptable range is fairly wide—often spanning about a 4× range in batch size—so you have flexibility.
  • It matches how “critical batch size” behaves in practice.
    • The number of steps needed to reach a target quality flattens out after some batch size (increasing batch size stops helping much).
    • Their formula reproduces a key pattern observed in practice: this flattening depends mostly on the total token budget DD, not on the model size NN.
    • This is helpful guidance: using the biggest possible batch size is not always a good idea.
  • A caution when reducing back to the classic two-term law (model size + data only).
    • If you convert their three-term law back to the classic form L(N,D)=E+A/Nα+B/DβL(N,D) = E + A/N^\alpha + B/D^\beta, the implied “compute-optimal” model size and data split can differ from what you’d get if you fit that classic form directly.
    • Translation: if you’re planning billion-token, billion-parameter runs, the exact formula you choose can change your recommended plan. So, pick carefully.

Why is this important?

  • It gives practical, easy-to-use rules for planning large model training:
    • How big should your batches be?
    • How many steps should you run?
    • What happens if you can’t use the ideal batch size?
  • It can save a lot of compute, time, money, and energy by reducing the number of training runs needed to discover good settings.
  • It aligns with real-world behavior (like critical batch size), so it’s more trustworthy in practice.

Final thoughts and future impact

This work helps teams train big LLMs more efficiently by:

  • Providing a simple, unified rule that links model size, batch size, and steps.
  • Showing how to choose near-optimal batch sizes even under hardware constraints.
  • Reducing the cost of finding good settings.

There are still open questions. The formula assumes the learning rate is already well tuned, and results may vary with different optimizers or training tricks. Future work could extend the formula to include the learning rate or account for different optimizers.

Still, if you’re planning a big training run, this paper gives you a clearer, cheaper roadmap for how to split your token budget between batch size and steps—and that can make a real difference.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

Below is a concise, concrete list of unresolved issues that the paper identifies or implies, phrased to guide follow‑up research.

  • External validity across setups
    • Validate the three-term law on additional domains (e.g., vision, speech, protein modeling), architectures (e.g., MoE, recurrent, transformer variants), and training regimes (instruction tuning, RLHF, multi-task) to assess generality beyond dense LLM pretraining.
    • Systematically test robustness across tokenizers, vocabulary sizes, and data distributions (quality/mixture/curriculum/duplication), given the law depends only on token count DD and not data quality.
  • Sensitivity to optimizer and schedule
    • Extend the law to explicitly include optimizer and schedule parameters (e.g., learning rate magnitude and schedule, AdamW β1/β2\beta_1/\beta_2, weight decay, EMA, gradient clipping, Muon), and re‑fit on controlled ablations to quantify how (B,C,β,γ)(B,C,\beta,\gamma) shift with optimizer choices.
    • Determine whether the independence of MM^\star from NN persists with different optimizers or schedules (cosine, constant, linear, one-cycle) and across noise‑scale regimes.
  • Learning rate modeling
    • Incorporate learning rate as an explicit variable into the law (including schedule shape), leveraging theoretical bounds (e.g., links to noise scale and KL conditions) to jointly model (N,M,K,η)(N,M,K,\eta) and reduce the need for separate LR sweeps.
    • Quantify the minimal LR sweep required to fit the extended law within specified error bars.
  • Suboptimal batch-size prediction limits
    • The three-term law underfits loss at suboptimal bb; the two‑stage fix assumes γβ\gamma \approx \beta. Test and report when this assumption breaks, and develop a principled single‑stage model that predicts suboptimal performance without relying on γβ\gamma \approx \beta.
    • Determine the minimum sweep density in bb (and placement strategy) needed to estimate the ϵ\epsilon‑suboptimal interval [bmin,bmax][b_{\min}, b_{\max}] to a target error.
  • Additive separability assumption
    • The law assumes additive separability in MM and KK terms (B/Mβ+C/KγB/M^\beta + C/K^\gamma). Probe for interaction effects (e.g., cross‑terms like bpKqb^{-p}K^{-q} or multiplicative couplings) by fitting alternative forms and conducting likelihood‑ratio/model‑selection tests.
  • Critical batch size validation
    • Empirically measure KLˉ(b)K_{\bar{\mathcal{L}}}(b) (steps to reach a fixed target loss) under controlled settings and compare directly to the law’s predictions rather than deriving from fitted parameters, to validate claimed invariances to NN and dependencies on DD.
    • Clarify the relationship between the law’s MM^\star and the empirically observed “critical batch size” across optimizers, schedules, and weight decay settings.
  • Chinchilla reduction mismatch
    • The reduction of the three-term law to a Chinchilla‑type law yields different implied N(C)N^\star(\mathcal{C}) than a direct Chinchilla fit. Diagnose the source (e.g., underfitting, parameter identifiability, misspecification) and develop fitting procedures or priors that reconcile the two.
    • Provide uncertainty intervals for the implied compute‑optimal NN^\star to quantify decision risk in deployment.
  • Parameter identifiability and uncertainty
    • Analyze identifiability of (E,A,B,C,α,β,γ)(E,A,B,C,\alpha,\beta,\gamma) and establish conditions under which these parameters are recoverable from partial sweeps; report parameter confidence intervals and correlations.
    • Study the sample complexity of fitting: how many (N,D,b)(N,D,b) configurations are needed for stable recovery of (β,γ)(\beta,\gamma) and MM^\star within prescribed error tolerance?
  • Irreducible loss term EE
    • The fitted E0E \approx 0 on the Li dataset is inconsistent with nonzero entropy of language. Investigate regularization constraints, hierarchical priors, or multi-task calibration to obtain realistic EE and decouple it from finite‑compute effects.
  • Sequence length and effective batch
    • The law uses M=bsM = b \cdot s but does not model ss explicitly beyond this product. Test whether MM^\star and [bmin,bmax][b_{\min}, b_{\max}] scale consistently when varying ss (long‑context training, context packing), and determine if additional ss‑dependent terms are needed.
  • Data scaling beyond token count
    • Augment the model to incorporate data quality/novelty/duplication (e.g., effective tokens or diversity metrics) rather than raw DD alone, and quantify shifts in (β,γ)(\beta,\gamma) under such controls.
  • Breakdown regimes and piecewise behavior
    • Identify regimes where power‑law behavior in MM or KK breaks (very small KK, extremely large MM, severe gradient accumulation) and fit piecewise or saturating forms; specify thresholds where the current law ceases to hold.
  • Hardware and wall‑clock considerations
    • Translate “5% compute waste” into wall‑clock and throughput terms under realistic hardware constraints (communication, memory/activation offloading, kernel efficiency) to provide actionable batch‑size intervals for practitioners.
  • Reproducibility and dataset access
    • Some analyses rely on OpenEuroLLM (not public at writing). Release data and scripts, and re‑run fits to confirm conclusions and parameter stability post‑release.
  • Theoretical grounding
    • Provide rigorous conditions under which the exponents (β,γ)(\beta,\gamma) and additive structure arise from optimization theory (beyond relaxing $1/2$ to free exponents), and connect constants to measurable quantities (e.g., gradient noise scale, curvature, Lipschitz/PL/KŁ constants).
    • Derive when and why MM^\star should be independent of NN, and characterize counterexamples.
  • Metric choice and downstream validity
    • The law targets final test cross‑entropy/perplexity. Evaluate whether the same scaling holds for downstream task performance, calibration, and emergent abilities; if not, propose task‑conditioned extensions.
  • Compute model assumptions
    • The compute proxy C=6ND\mathcal{C}=6ND omits optimizer costs, activation recomputation, parallelization overhead, or memory‑bound effects. Calibrate the law with more realistic compute models and quantify the impact on NN^\star and MM^\star recommendations.
  • Smoothing and evaluation protocol
    • Assess how loss smoothing, early stopping, and evaluation frequency influence fits; standardize an evaluation protocol to reduce fit variance across datasets.
  • Extension to regularization effects
    • Incorporate weight decay and other regularizers (label smoothing, dropout) into the law, building on prior links between weight decay and batch size, to improve predictions of both MM^\star and KLˉ(b)K_{\bar{\mathcal{L}}}(b).

Practical Applications

Immediate Applications

The following items summarize practical, deployable uses of the paper’s three-term scaling law and associated procedures that can be adopted now across industry, academia, policy, and daily practice.

  • Training planning and cost reduction for LLMs and other deep models (software/AI, cloud)
    • Use the three-term law L(N, M, K) = E + A/N^α + B/M^β + C/K^γ to select near-optimal batch size and number of steps under a fixed token budget D=MKD = MK, without requiring full batch-size sweeps.
    • Workflow: For each (N,D)(N, D), run 2–3 batch sizes, fit the law, and infer MM^\star and KK^\star; this reduces runs to ~28% of a full sweep while matching prior optimal batch-size scaling.
    • Tools/products: A “Batch Size Advisor” plugin for PyTorch Lightning or HuggingFace Trainer that logs (N,M,K)(N, M, K), fits the three-term law on-the-fly, and recommends the next configuration; integration with Ray Tune for guided hyperparameter search.
    • Assumptions/dependencies: Uses AdamW-like training with stable LR schedules; requires small sets of runs per (N,D)(N, D); law parameters are dataset/setup dependent; sequence length affects constants.
  • Resource-aware MLOps scheduling and GPU utilization (cloud, enterprise ML)
    • Allocate GPU memory and throughput by selecting batch sizes within the ϵ\epsilon-suboptimal interval [bmin,bmax][b_{\min}, b_{\max}] that wastes ≤5% compute.
    • Workflow: Apply the paper’s two-stage fit (per (N,D)(N, D), fit a simplified L(b)L(b) curve, then generalize bmin/maxDνb_{\min/\max} \propto D^\nu) to set practical batch-size bounds respecting compute and memory limits.
    • Tools/products: ThreeTermFit library to estimate [bmin,bmax],exposeguidancedashboardstoopsteams.</li><li>Assumptions/dependencies:Needsamodestbatchsizesweepper[b_{\min}, b_{\max}]`, expose guidance dashboards to ops teams.</li> <li>Assumptions/dependencies: Needs a modest batch-size sweep per (N, D);reliesonconsistenttrainingsetupandlosssmoothing;accuracydegradesforextreme; relies on consistent training setup and loss smoothing; accuracy degrades for extreme Difunderparameterized.</li></ul></li><li>Criticalbatchsizediagnosticstoavoidinefficiencies(software/AI,cloud)<ul><li>Usethepredictedstepstotargetfunction if underparameterized.</li> </ul></li> <li>Critical batch size diagnostics to avoid inefficiencies (software/AI, cloud) <ul> <li>Use the predicted steps-to-target function K_{\bar{L}}(b)todetectwhenincreasingbatchsizebringsdiminishingreturns,preventingoversizedbatchregimes.</li><li>Workflow:Forgiventargetloss to detect when increasing batch size brings diminishing returns, preventing “oversized batch” regimes.</li> <li>Workflow: For given target loss \bar{L},compute, compute K_{\bar{L}}(b)acrossfeasible across feasible busingfittedparameters;setceilingson using fitted parameters; set ceilings on bintrainingpolicies.</li><li>Assumptions/dependencies:Requiresafittedthreetermlaw;targetlossselectionshouldbeconsistentwithevaluationsetups;optimizerandscheduleconsistencymatters.</li></ul></li><li>Budgetawareexperimentationinacademiclabs(academia,education)<ul><li>Reduceexperimentalcostinhyperparameterstudiesbyusingtwobatchsizesper in training policies.</li> <li>Assumptions/dependencies: Requires a fitted three-term law; target-loss selection should be consistent with evaluation setups; optimizer and schedule consistency matters.</li> </ul></li> <li>Budget-aware experimentation in academic labs (academia, education) <ul> <li>Reduce experimental cost in hyperparameter studies by using two batch sizes per (N, D)tofitthelawandrecoverthesame to fit the law and recover the same M^\starscalingasfullsweeps.</li><li>Workflow:AdoptHuberlossfitting,LBFGSBwithmultipleinitializationsandcrossvalidationasperthepaper;sharefittedcoefficientstosupportreproducibility.</li><li>Assumptions/dependencies:Resultsreflectthedatasetsandtrainingproceduresused;parameterinterpretations(e.g., scaling as full sweeps.</li> <li>Workflow: Adopt Huber-loss fitting, L-BFGS-B with multiple initializations and cross-validation as per the paper; share fitted coefficients to support reproducibility.</li> <li>Assumptions/dependencies: Results reflect the datasets and training procedures used; parameter interpretations (e.g., E)canvarywithsetupandmayneedregularization.</li></ul></li><li>EnergyandcostreportingframeworksforfundedAIprojects(policy,publicsector)<ul><li>Replacefullbatchsizesweepswithlawbasedfittingingrantrequirementstoreduceenergyuseandbudget;mandatereportingof) can vary with setup and may need regularization.</li> </ul></li> <li>Energy and cost reporting frameworks for funded AI projects (policy, public sector) <ul> <li>Replace full batch-size sweeps with law-based fitting in grant requirements to reduce energy use and budget; mandate reporting of (N, M, K)fitsand fits and \epsilonsuboptimalintervals.</li><li>Workflow:FundingcallsincludecomputeefficiencyKPIsusingthethreetermlaw;projectssubmitperiodicfitupdatesinsteadofexhaustivesweeps.</li><li>Assumptions/dependencies:Standardsforfitquality(crossvalidation,heldoutsplits)mustbespecified;comparabilitydependsonharmonizedtrainingprotocols.</li></ul></li><li>Practicalguidanceforteamsconstrainedbyhardware(SMEs,startups,dailypractice)<ul><li>Whenoptimalbatchsizeisinfeasible(e.g.,memorylimits),choose-suboptimal intervals.</li> <li>Workflow: Funding calls include compute-efficiency KPIs using the three-term law; projects submit periodic fit updates instead of exhaustive sweeps.</li> <li>Assumptions/dependencies: Standards for fit quality (cross-validation, held-out splits) must be specified; comparability depends on harmonized training protocols.</li> </ul></li> <li>Practical guidance for teams constrained by hardware (SMEs, startups, daily practice) <ul> <li>When optimal batch size is infeasible (e.g., memory limits), choose bwithinthepapersempiricallyderived within the paper’s empirically derived \epsilonsuboptimalbandtomaintainefficiency.</li><li>Workflow:Estimate-suboptimal band to maintain efficiency.</li> <li>Workflow: Estimate [b_{\min}, b_{\max}]forcurrent for current Dandsequencelength;pickthelargest and sequence length; pick the largest bwithinmemorythatstillfallsinsidetheband.</li><li>Assumptions/dependencies:Sequencelengthdifferencesshifttheband;lawiscalibratedperdataset/task;appliesbesttodenseLLMpretrainingwithAdamW.</li></ul></li></ul><h2class=paperheadingid=longtermapplications>LongTermApplications</h2><p>Theseapplicationsbuildonthepapersinsightsbutrequireadditionalresearch,scaling,orengineeringtorealizerobustdeploymentsacrossdiversesettingsandsectors.</p><ul><li>Autopilottrainingsystemswithcomprehensivehyperparameterscaling(software/AI,cloud)<ul><li>Extendthethreetermlawtoincludelearningrate,weightdecay,optimizerchoice(e.g.,Muon),sequencelength,anddatacurriculumtocreateanendtoendtrainingautopilot.</li><li>Potentialproduct:ScalingAIAutopilotthatcontinuouslyfitsmultitermlawsonlineandadjusts within memory that still falls inside the band.</li> <li>Assumptions/dependencies: Sequence length differences shift the band; law is calibrated per dataset/task; applies best to dense LLM pretraining with AdamW.</li> </ul></li> </ul> <h2 class='paper-heading' id='long-term-applications'>Long-Term Applications</h2> <p>These applications build on the paper’s insights but require additional research, scaling, or engineering to realize robust deployments across diverse settings and sectors.</p> <ul> <li>Autopilot training systems with comprehensive hyperparameter scaling (software/AI, cloud) <ul> <li>Extend the three-term law to include learning rate, weight decay, optimizer choice (e.g., Muon), sequence length, and data curriculum to create an end-to-end training autopilot.</li> <li>Potential product: “Scaling-AI Autopilot” that continuously fits multi-term laws online and adjusts M,, K,LR,andschedulestooptimizelossvs.computeandenergy.</li><li>Assumptions/dependencies:Requiresrichertheory(stochasticoptimizationbounds)andlargescalevalidationacrossarchitecturesandtasks;crossoptimizergeneralizationiscurrentlyuncertain.</li></ul></li><li>Cloudschedulersandcostcalculatorsthatdynamicallyadaptbatchsize(cloud,energy)<ul><li>Integratelawbasedpredictionsintoclusterschedulerstotradeoffthroughputvs.stepefficiency;minimizeenergyperachievedloss.</li><li>Potentialproduct:BatchsizeawareGPUallocationandcarbonawaretrainingplannersembeddedincloudplatforms.</li><li>Assumptions/dependencies:Accurate,realtimefits;standardizedtelemetry;stabilityacrossmixedworkloads.</li></ul></li><li>Sectorspecificpretrainingplanningwheredataisscarceorregulated(healthcare,finance,legal)<ul><li>Uselawdrivencomputeallocationtodecidewhethertoacquiremoretokens(, LR, and schedules to optimize loss vs. compute and energy.</li> <li>Assumptions/dependencies: Requires richer theory (stochastic optimization bounds) and large-scale validation across architectures and tasks; cross-optimizer generalization is currently uncertain.</li> </ul></li> <li>Cloud schedulers and cost calculators that dynamically adapt batch size (cloud, energy) <ul> <li>Integrate law-based predictions into cluster schedulers to trade off throughput vs. step efficiency; minimize energy per achieved loss.</li> <li>Potential product: Batch-size-aware GPU allocation and carbon-aware training planners embedded in cloud platforms.</li> <li>Assumptions/dependencies: Accurate, real-time fits; standardized telemetry; stability across mixed workloads.</li> </ul></li> <li>Sector-specific pretraining planning where data is scarce or regulated (healthcare, finance, legal) <ul> <li>Use law-driven compute allocation to decide whether to acquire more tokens (D)oradjuststeps() or adjust steps (K)andbatchsize() and batch size (M)forregulateddatasets(EHR,transactions,caselaw).</li><li>Workflow:Scenarioplanningtoolssimulatelossvs.computefordifferent) for regulated datasets (EHR, transactions, case law).</li> <li>Workflow: Scenario planning tools simulate loss vs. compute for different Dcollectionstrategiesandtrainingschedulesundercomplianceandprivacyconstraints.</li><li>Assumptions/dependencies:Domainspecificdatapropertiesmayalterfit;legal/ethicaldatauseimpactsfeasible collection strategies and training schedules under compliance and privacy constraints.</li> <li>Assumptions/dependencies: Domain-specific data properties may alter fit; legal/ethical data use impacts feasible D;resultsfromLLMpretrainingmaynotdirectlytransfertomultimodalorfinetuningtasks.</li></ul></li><li>Hardwaresoftwarecodesignforbatchsizeawareaccelerators(semiconductors,robotics,edgeAI)<ul><li>Informmemoryhierarchiesandfirmwaretosupporttheempiricallyuseful; results from LLM pretraining may not directly transfer to multimodal or fine-tuning tasks.</li> </ul></li> <li>Hardware–software co-design for batch-size-aware accelerators (semiconductors, robotics, edge AI) <ul> <li>Inform memory hierarchies and firmware to support the empirically useful \epsilonsuboptimalbatchsizeranges,improvingutilizationonconstraineddevices.</li><li>Potentialproduct:Acceleratorruntimethatautoselectsbatchsizewithinthenearoptimalbandgivenmemoryandlatencyconstraints.</li><li>Assumptions/dependencies:Requirescodevelopmentwithhardwarevendors;validationacrossdiversemodelfamiliesandsequencelengths.</li></ul></li><li>Standardsforreportingscalinglawfitsandcomputeefficiency(policy,consortia)<ul><li>Establishguidelinesforscalinglawmethodology(fitprocedures,crossvalidation,heldoutsplits,reportingofuncertainty)toimprovecomparabilityandreproducibility.</li><li>Outcome:Sectorwidebenchmarksanddisclosurestandardsthatreduceenergywasteandenablefaircost/performancecomparisons.</li><li>Assumptions/dependencies:Multistakeholderconsensus;alignmentwithprivacyandIPrestrictionsforsharingtraininglogs.</li></ul></li><li>FinancialplanningandROIforecastingforlargescaletraining(finance,enterprisestrategy)<ul><li>Uselawbasedprojections(lossvs.compute)toforecastcostcurves,breakevenpoints,andreturnonimprovedmodelperformance.</li><li>Tools:Financedashboardsthattie-suboptimal batch-size ranges, improving utilization on constrained devices.</li> <li>Potential product: Accelerator runtime that auto-selects batch size within the near-optimal band given memory and latency constraints.</li> <li>Assumptions/dependencies: Requires co-development with hardware vendors; validation across diverse model families and sequence lengths.</li> </ul></li> <li>Standards for reporting scaling-law fits and compute efficiency (policy, consortia) <ul> <li>Establish guidelines for scaling-law methodology (fit procedures, cross-validation, held-out splits, reporting of uncertainty) to improve comparability and reproducibility.</li> <li>Outcome: Sector-wide benchmarks and disclosure standards that reduce energy waste and enable fair cost/performance comparisons.</li> <li>Assumptions/dependencies: Multi-stakeholder consensus; alignment with privacy and IP restrictions for sharing training logs.</li> </ul></li> <li>Financial planning and ROI forecasting for large-scale training (finance, enterprise strategy) <ul> <li>Use law-based projections (loss vs. compute) to forecast cost curves, breakeven points, and return on improved model performance.</li> <li>Tools: Finance dashboards that tie M^\star(D)and and K_{\bar{L}}(b)toGPUhours,energycost,andexpectedperformancegains.</li><li>Assumptions/dependencies:Validityoffitsfortheintendedarchitecture/data;mappinglossreductionstobusinessvalueiscontextdependent.</li></ul></li><li>Onlineadaptivetrainingandcurriculum/datascheduling(software/AI,education)<ul><li>Fitthelawduringtrainingtoadjust to GPU hours, energy cost, and expected performance gains.</li> <li>Assumptions/dependencies: Validity of fits for the intended architecture/data; mapping loss reductions to business value is context-dependent.</li> </ul></li> <li>Online adaptive training and curriculum/data scheduling (software/AI, education) <ul> <li>Fit the law during training to adjust Mand and Kastokenbudgetaccrues,andcoordinatewithcurriculumstrategies(e.g.,progressivelyincreasing as token budget accrues, and coordinate with curriculum strategies (e.g., progressively increasing D$).
    • Potential product: Online trainer that keeps batch-size and step schedules near the law-optimal frontier while meeting wall-clock constraints.
    • Assumptions/dependencies: Stable online fitting; nonstationary data effects; interactions with regularization and optimizer dynamics.
  • Unifying theory and verified generalization across domains (academia)
    • Develop theoretical foundations that reconcile the law with convergence bounds and critical-batch-size models beyond least-squares and infinite-width limits.
    • Outcome: More general, provably reliable scaling laws that maintain predictive accuracy for compute-optimal allocation in real settings.
    • Assumptions/dependencies: Substantial analytical work and broad empirical validation; may require new benchmarks and shared datasets.

Each application’s feasibility depends on consistent training setups (optimizer, LR schedule, sequence length), availability of modestly sized training logs for fitting, and awareness that fitted parameters are sensitive to dataset and experimental choices. Adopting cross-validation, held-out splits, and regularization in fitting—as practiced in the paper—will improve robustness and generalization.

Glossary

  • AdamW: An optimizer that decouples weight decay from gradient updates to improve training stability. "using AdamW \citep{Loshchilov2019}"
  • bootstrap aggregation: A resampling-based ensembling technique (bagging) to reduce variance and stabilize estimates/fits. "thanks to multiple initializations and bootstrap aggregation."
  • Chinchilla Approach 3: A specific empirical method to fit a scaling law for loss as a sum of power-laws in model size and data. "known as Chinchilla Approach 3"
  • Chinchilla law: An empirical scaling law expressing test loss as a sum of power-law terms in model size and data. "Recall the Chinchilla law proposed by \citet{Hoffmann2022}:"
  • Chinchilla-optimal: The configuration that follows compute-optimal prescriptions from the Chinchilla scaling framework. "Chinchilla-optimal setting."
  • compute-optimal allocation: The distribution of available compute across model size and data that minimizes loss under a scaling law. "compute-optimal allocation of NN and DD"
  • cosine schedule: A learning-rate schedule that decays the rate following a cosine curve over training. "cosine schedule"
  • critical batch size: The batch size beyond which increasing the batch yields diminishing returns in reducing steps-to-target-loss. "the concept of the critical batch size"
  • cross-validation: A model evaluation technique that partitions data into folds to assess generalization. "five-fold cross-validation"
  • Huber loss: A robust loss function less sensitive to outliers, blending L1 and L2 behaviors. "minimizing the Huber loss"
  • L-BFGS-B: A limited-memory quasi-Newton optimization algorithm with bound constraints. "with L-BFGS-B from multiple initializations"
  • LLMs: Very large neural LLMs (often Transformers) trained on massive text corpora. "LLMs"
  • learning-rate schedule: A predefined plan for changing the learning rate during training. "learning-rate schedules"
  • mean absolute deviation (MAD): An error metric measuring the average absolute difference between predictions and observations. "mean absolute deviation (MAD)"
  • mu-KL condition (Kurdyka–Łojasiewicz): A geometric regularity condition on objectives that yields convergence rate guarantees for optimization. "μ-KL condition"
  • non-linear least squares: A curve-fitting method that minimizes the sum of squared residuals for non-linear models. "non-linear least squares"
  • power-law: A relationship of the form k·xα that often describes scaling behaviors in learning curves. "power-law function"
  • Step-Law: The paper’s shorthand for the previously reported empirical law relating optimal batch size to token budget. "which we refer to as Step-Law"
  • stochastic conditional gradient method: A stochastic variant of the Frank–Wolfe algorithm for constrained optimization. "the stochastic conditional gradient method"
  • three-term law: The paper’s proposed loss model that includes separate power-law terms for model size, batch size, and training steps. "three-term law"
  • token budget: The total number of training tokens available for a run. "token budget DD"
  • two-term law: A model-specific loss form with separate power-law terms for batch size and steps (holding model size fixed). "two-term law"
  • unimodal: A function with a single minimum/maximum; used to justify unique optimal batch size neighborhoods. "is unimodal in bb"
  • weight averaging: Averaging model weights across training checkpoints to improve generalization. "weight averaging"
  • weight decay: A regularization technique that penalizes large weights, often implemented via L2 penalty or decoupled decay. "weight decay"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 3 tweets with 177 likes about this paper.