How Model Growth, Recursion, and Boundary Operators Influence Scaling Exponents
Abstract: Scaling laws predict how loss decreases with increases in computation. We show, contrary to conventional wisdom, that architectural interventions can modify scaling exponents in pre-training, leading to exponential improvements in performance with increases in computation. As an anchoring point, we consider the architectural formulation of looped transformers. Although not typically used in this way, looping, also known as recursive depth, provides a mechanism for model growth, by increasing the number of loops during training. Model growth, with and without shared weights, provides the biggest changes to the scaling exponents. In particular, a 7.4B model growth architecture matches GPT-3 13B on CORE with roughly less compute, and has compute efficiency gains that increase with scale. Moreover, simply using a boundary operator in a vanilla transformer, which normalizes and injects an earlier block, also provides increasing compute-efficiency gains, although to a lesser extent. In the data-constrained, multi-epoch setting, standard looping has a useful regularizing effect, where we find it is compute-optimal to increase the number of loops with scale. These results can be understood through the lens of computational depth: for a given computational budget, we wish to increase the usable depth of the transformer, which can lead to efficiency gains that increase with scale.
Paper Prompts
Sign up for free to create and run prompts on this paper.
Top Community Prompts
Explain it Like I'm 14
1. What is this paper about?
This paper studies how the design of a neural network can affect the way its performance improves when we give it more computing power.
Scientists often use scaling laws to predict how much a model will improve when they increase:
- the number of model parameters,
- the amount of training data, or
- the amount of computing power used for training.
Usually, researchers expect a new architecture to make a model better by a fixed amount. This would be like making a car permanently 10% faster. The paper argues that some architectural changes can do something more powerful: they can improve the scaling exponent. In simple terms, the model can become increasingly more efficient as it gets larger.
The researchers focus especially on:
- looping, where the same group of transformer layers is used repeatedly;
- model growth, where more loops or layers are added during training; and
- a boundary operator, which helps information move safely between groups of layers.
2. What questions did the researchers ask?
The main research questions were:
- Can changing a model’s architecture change its scaling law? In other words, can an architectural improvement become more valuable as the amount of training computation increases?
- Does making a model deeper during training help? The researchers test whether starting with a smaller model and adding more processing steps later is better than using a fixed-size model from the beginning.
- Is it useful to reuse the same layers repeatedly? This is called weight sharing. It allows a model to perform more computation without storing as many different parameters.
- Does the boundary operator improve performance? This operator normalizes information and adds back an earlier representation so that later layers do not lose track of the original input.
- What happens when training data are limited and must be reused? The researchers investigate whether looping can reduce overfitting when the model sees the same data many times.
3. How did the researchers study these questions?
Comparing several transformer designs
All the models had a similar three-part structure:
- a prelude, which first processes the input;
- a core, which performs the main calculations; and
- a coda, which turns the final internal information into an output.
The core could be run one or more times. Each run is called a pass or loop.
The researchers compared several versions:
| Model type | Main idea |
|---|---|
| Vanilla transformer | A normal transformer with no special looping |
| Boundary-operator model | A transformer that normalizes information and re-injects an earlier representation |
| Looped transformer | The same core layers are used repeatedly |
| Untied model | Each loop has its own separate set of weights |
| Model-growth transformer | The model begins with fewer loops and gains more during training |
The difference between tied and untied weights is similar to this:
- With tied weights, one worker repeats the same instructions several times.
- With untied weights, each step has a different worker with different instructions.
Measuring computation and performance
The models were trained on text from the FineWeb dataset. The researchers measured:
- training loss, which shows how many mistakes the model makes;
- validation loss, which tests how well the model works on text it has not trained on;
- downstream test performance, including the CORE benchmark;
- the amount of computation used, measured in FLOPs.
A FLOP is one basic mathematical operation performed by a computer. Counting FLOPs is like counting how many individual steps are needed to train a model.
The researchers trained models at different computing budgets and fitted mathematical curves called scaling laws. These curves describe how loss decreases as computation increases.
They also used a compute multiplier. For example, a multiplier of means that a standard transformer needs 1.5 times as much computation to reach the same performance as the new model.
Testing repeated-data training
In another experiment, the researchers used a fixed collection of 100 million text tokens and trained models on it for ten passes. This tested what happens when the model must repeatedly study the same material.
This is important because the supply of high-quality training text may eventually become limited.
4. What did the researchers find?
Model growth improved scaling
The strongest result was that growing the model during training improved its scaling exponent.
The model started with fewer core passes and later gained more. This allowed it to use a smaller amount of computation early on, when it was still learning simple patterns, and more depth later, when it could benefit from more complicated processing.
The improvement became larger at bigger scales. For example, at about FLOPs:
- the untied growth model needed about 1.55 times less computation than a standard transformer to reach the same loss;
- the tied growth model achieved about a 1.36-times compute advantage.
The tied version used far fewer stored parameters, making it more memory-efficient.
The boundary operator also helped
Simply adding the boundary operator improved the scaling exponent, even though it changed the model only slightly.
At around FLOPs, this model had a compute advantage of about 1.25 times over the standard transformer.
The operator appears to help because it:
- keeps the internal information from becoming too large or unbalanced; and
- repeatedly reminds later layers about the original input.
Without this help, very deep transformers may suffer from the curse of depth. This means that after a while, extra layers may have less and less useful influence on the final answer.
Weight sharing saved parameters but had a cost
Using the same weights repeatedly was more parameter-efficient. However, untied models, where every loop had separate weights, performed somewhat better.
The important finding was that untying weights mainly gave a constant improvement. It did not create the growing advantage associated with model growth.
In simpler terms:
- Weight sharing is useful for saving memory.
- Model growth is what produced the larger improvement as scale increased.
A larger model matched GPT-3 13B with much less computation
The researchers trained a 7.4-billion-parameter model using the model-growth method.
It achieved a CORE benchmark score close to that of GPT-3 13B while using roughly 20 times less training computation. The authors warn that this comparison is only approximate because the models used different data and evaluation setups.
Still, the result suggests that carefully changing how a model grows can greatly improve training efficiency.
Looping helped when data were repeated
When the same 100 million tokens were reused for ten epochs, the best number of loops increased as the computation budget increased.
The researchers found that:
- adding more parameters caused more overfitting;
- adding loops increased computational depth without adding as many stored parameters;
- looped models could therefore use more computation while overfitting less.
At one tested point, scaling the number of loops reached the same performance as a larger, carefully regularized standard model while using about 2.2 times less computation.
This suggests that looping can act as a kind of regularizer. A regularizer is a method that prevents a model from simply memorizing its training data.
5. Why are these findings important?
The paper challenges the common belief that architecture changes can only provide a fixed improvement.
Instead, it suggests that some architectural choices can make models increasingly efficient at larger scales. This matters because modern AI training can require enormous amounts of computing power, electricity, time, and money.
The research suggests several practical lessons:
- Growing a model during training may be better than keeping its depth fixed.
- Looping can increase the amount of computation a model performs without requiring as many stored parameters.
- Boundary operators may help very deep transformers continue making useful updates.
- When training data are limited, increasing loops may be better than simply increasing model size.
- New architectures must be tuned separately. Using the exact training settings from a standard transformer can hide their advantages.
Overall, the paper presents a new way to think about building large AI models: rather than only making models wider or adding more parameters, researchers should also consider how much useful computational depth a model can use and how that depth should change during training.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
- Limited architectural scope: The experiments focus on a single prelude–core–coda transformer family, fixed width-to-depth ratio, RMSNorm-based boundary operators, and a specific looping design; it remains unclear whether the exponent improvements transfer to conventional transformers, alternative residual structures, MoE models, encoder–decoder architectures, or other sequence models.
- Limited dataset diversity: Most conclusions are based on FineWeb and FineWeb-Edu, with similar scaling behavior across these two corpora but no evidence from other languages, domains, modalities, tokenizers, or substantially different data-quality distributions.
- Unclear causal mechanism: The paper attributes exponent improvements to increased “computational depth” and mitigation of the curse of depth, but does not establish causality between effective depth, boundary normalization, input reinjection, model growth, and the observed scaling exponents.
- Computational depth is not fully operationalized: The proposed notion of computational depth—layers that meaningfully influence the predictive distribution—is not systematically measured or quantitatively linked to the fitted scaling-law parameters across all model variants.
- Boundary-operator effects are not fully disentangled: The operator combines residual normalization, prelude reinjection, and the coefficient ; the separate contribution and interaction of these components across model scales are not comprehensively analyzed.
- The role of the injection scale remains unresolved: The sensitivity of scaling exponents and compute efficiency to , including whether should scale with depth, width, loop count, or training progress, is not established.
- Growth schedules are narrowly explored: Growth generally doubles the number of core passes from two to four, with transition points concentrated late in training; the optimal initial and final loop counts, number of growth stages, growth ratios, and continuous versus discrete schedules remain unknown.
- Growth timing may depend on scale and data regime: The paper reports that growth occurs between roughly one-half and four-fifths of training, but does not determine whether the optimal transition changes systematically with model size, token budget, dataset difficulty, or the number of training epochs.
- Initialization effects during untied growth are underexplored: New untied blocks are initialized by copying existing cores, but alternatives such as random initialization, perturbation-based copying, function-preserving initialization, or learned interpolation are not compared.
- The effect of weight sharing is not fully understood: Untying appears to improve the scaling constant but not the exponent, while tying provides regularization under repeated data; the mechanisms governing this trade-off and its dependence on loop count, depth, and optimization are unresolved.
- Limited loop-count range: The single-epoch experiments mainly compare two and four core passes, while the multi-epoch study considers loop counts only up to 12; behavior at substantially larger executed depths is unknown.
- No systematic study of inference-time behavior: The paper evaluates training loss and selected downstream metrics but does not determine how the proposed architectures compare in latency, memory use, throughput, activation memory, or quality at fixed inference-time compute.
- Training FLOPs may not capture practical efficiency: Although some results are also presented in wall-clock time, the analysis does not fully account for communication, kernel efficiency, parallelization limits, optimizer-state memory, checkpointing, or hardware-specific costs of tied and untied recursion.
- Scaling-law fits cover a narrow compute range: Most exponents are fitted between approximately and FLOPs, so the claimed asymptotic exponent differences may still reflect finite-range curvature or regime-specific effects.
- Extrapolation evidence is limited: The principal extrapolation uses one Untied-Grow run at approximately eight times the largest fitted compute, leaving uncertainty about whether the advantage persists over several additional orders of magnitude or eventually saturates, reverses, or encounters optimization limits.
- Irreducible-loss assumptions are uncertain: Scaling-law comparisons rely on a shared or Vanilla-derived irreducible loss in several analyses; architecture-specific irreducible losses could alter the estimated exponents and compute multipliers.
- Statistical uncertainty is incompletely characterized: The reported regression errors are small, but uncertainty from random seeds, dataset subsampling, hyperparameter-search noise, finite evaluation sets, and model-to-model variability is not fully propagated into the exponent and multiplier estimates.
- Compute-optimal recipe comparisons may retain residual tuning bias: Each architecture receives separate tuning, but the search spaces, tuning budgets, and functional forms used for different variants could still favor some families or fail to identify their true global optima.
- Hyperparameter scaling beyond the tested range is unknown: The proposed learning-rate and token-allocation rules are validated over the studied ladder but are not demonstrated to remain optimal at much larger widths, depths, loop counts, or training budgets.
- Width–depth interactions remain unresolved: The experiments largely fix the width-to-depth ratio at 128 and find limited benefits from reducing it, but do not map the joint scaling surface over width, depth, loop count, and stored parameter count.
- The relationship between validation loss and capabilities is incomplete: The paper reports favorable CORE and answer-NLL results, but the transfer from pretraining loss to broader reasoning, memorization, instruction following, robustness, calibration, and safety behavior is not established.
- The GPT-3 comparison is not controlled: The approximately compute comparison uses different training data and an externally estimated GPT-3 evaluation pipeline, so the magnitude of the claimed practical advantage remains uncertain.
- Downstream scaling-law transfer is limited: The downstream prediction is developed around CORE and answer NLL; its validity for other benchmark families, task distributions, and capability thresholds is not tested.
- Data-constrained conclusions use one repetition regime: The multi-epoch analysis fixes 100M unique tokens and ten epochs, so the optimal relationship between stored parameters, loop count, weight decay, and compute for other dataset sizes and epoch counts remains unknown.
- The regularization interpretation is not isolated: Looping may reduce overfitting through several mechanisms—including parameter sharing, optimization dynamics, implicit depth regularization, and altered representations—but the experiments do not distinguish among them.
- Repeated-data results may depend on weight decay and optimizer choice: The data-constrained conclusions are drawn under a particular optimization and regularization setup; their robustness to AdamW settings, alternative optimizers, dropout, data mixing, and explicit regularizers is unresolved.
- Effects of data ordering and repeated-token sampling are unexplored: The paper does not assess whether looping’s apparent regularization benefit changes with reshuffling, curriculum ordering, duplicate placement, or nonuniform repetition of high- and low-quality examples.
- Training stability at larger recursive depths is unknown: The study does not establish whether normalization and reinjection remain sufficient to prevent exploding activations, vanishing updates, representation collapse, or optimization instability as the loop count grows substantially.
- The architecture’s context-length dependence is unclear: It is not shown whether the scaling advantages persist for longer contexts, different attention patterns, or tasks where long-range dependency modeling dominates the loss.
- No comparison with alternative efficient-depth methods: The proposed growth and boundary mechanisms are not systematically compared with stochastic depth, layer dropping, progressive stacking, reversible layers, adaptive computation, mixture-of-depth methods, or other compute-allocation strategies.
- The benefit of model growth versus checkpoint reuse remains unresolved: The study intentionally treats growth as a depth-allocation method rather than a way to reuse prior training, leaving open whether combining compute-optimal growth with checkpoint reuse could yield larger gains.
- Theoretical explanation is incomplete: The paper provides an intuitive computational-depth account but does not derive a formal scaling theory predicting when architectural interventions should change the exponent, how the exponent depends on effective depth, or why the observed improvements add approximately independently.
Practical Applications
Immediate Applications
- More compute-efficient language-model pretraining — AI infrastructure and software.
- add the boundary operator between core passes and before the coda;
- calibrate its injection scale and normalization method on a small model;
- fit architecture-specific learning-rate, token-allocation, and batch-size rules before scaling up.
- Dependencies: The reported gains were obtained on FineWeb and FineWeb-Edu with carefully tuned hyperparameters. Reusing a vanilla-transformer recipe may eliminate the benefit, and transfer to other modalities, tokenizers, optimizers, and objectives remains to be established.
- Parameter-efficient model scaling through tied looping — cloud AI and on-device inference.
- LLMs deployed under memory constraints;
- edge or mobile assistants;
- lower-cost model serving where memory bandwidth is more restrictive than arithmetic throughput;
- shared-weight checkpoints that support adjustable inference-time computation.
- Dependencies: Tied looping incurs a constant compute-efficiency penalty relative to untied growth in the paper’s single-epoch experiments. It is most attractive when parameter storage, checkpoint size, or memory capacity is the primary bottleneck.
- Architecture-aware training recipes for LLMs — AI laboratories and model vendors.
- automated sweeps for core-to-total-depth ratios;
- growth-transition schedulers;
- compute-multiplier dashboards;
- scaling-law fitters that compare loss and downstream performance at equal FLOPs and wall-clock time;
- configuration generators that extrapolate small-scale recipes to larger runs.
- Dependencies: The paper shows that architecture-specific tuning is essential. Small-scale scaling-law fits must be validated before being used for expensive extrapolation.
- Checkpoint-growing training pipelines — model training platforms.
The untied-growth procedure can be implemented by initially training a model with a small number of core passes, copying trained core blocks at a scheduled transition, and then allowing the copied blocks to specialize independently. This may reduce the amount of early training spent on a large model whose full depth is not yet useful. A training platform could expose a workflow such as:
- train a shallow or low-pass model;
- duplicate core blocks at a chosen fraction of training;
- activate the new blocks;
- continue training with architecture-specific learning-rate and token schedules. Dependencies: Copying parameters does not guarantee stable optimization after growth. The reported transition points were tuned experimentally, and the method adds optimizer-state, memory, checkpointing, and distributed-training complexity.
Compute-aware procurement and infrastructure planning — AI operations and finance.
- GPU-hours and energy consumption;
- training-cluster capacity;
- expected cost per target capability;
- whether memory or FLOPs is the binding resource.
- Dependencies: Cost projections depend on hardware utilization, communication overhead, inference requirements, data quality, and whether the measured validation-loss advantage transfers to the target application.
- Reduced energy and carbon intensity of model training — sustainability policy and operations.
- training data;
- target loss or benchmark score;
- hardware;
- wall-clock measurement;
- optimizer and numerical precision.
- Dependencies: FLOP reductions may not translate proportionally into energy reductions because untied models can require more memory, communication, and storage. Full life-cycle energy measurements are required.
- Regularized training on small or repeatedly reused datasets — domain-specific AI.
- legal, medical, scientific, or enterprise corpora with limited licensing access;
- domain adaptation where only a small text collection can be repeatedly sampled;
- synthetic-data training pipelines;
- continual pretraining on a fixed internal knowledge base.
- The reported results suggest increasing the loop count with compute can delay overfitting and outperform simply enlarging the parameter count.
- Dependencies: This finding was demonstrated on a 100M-token pool trained for multiple epochs. The appropriate loop count, number of epochs, and regularization strategy will depend on corpus size, duplication patterns, and downstream evaluation.
- Adaptive-compute inference for reasoning systems — software products and assistants.
- confidence-triggered additional loops;
- user-selectable “fast” and “deep” modes;
- token-level or sequence-level early exit;
- compute budgets for coding, mathematics, or planning tasks.
- Dependencies: The paper primarily evaluates pretraining efficiency rather than adaptive inference quality. Additional work is needed to determine whether extra loops reliably improve factuality, reasoning, calibration, and robustness rather than merely increasing latency.
- Educational and research tooling for scaling-law experimentation — academia and education.
- vanilla transformers;
- boundary-operator variants;
- tied and untied loops;
- growth schedules;
- width–depth ratios.
- Dependencies: Meaningful conclusions require multiple compute scales, architecture-specific tuning, held-out data, and careful separation of parameter count, executed depth, stored depth, FLOPs, and wall-clock time.
Long-Term Applications
- Lower-cost frontier-scale foundation models — AI industry and public-sector computing.
- higher-capability models within a fixed national or corporate compute budget;
- more frequent model refreshes;
- smaller training clusters for equivalent benchmark performance;
- broader access to foundation-model development.
- Dependencies: The largest claims rely on extrapolation from approximately – FLOPs and a limited larger-scale validation point. Independent replication at modern training scales, with matched datasets and evaluation pipelines, is necessary before making infrastructure or policy commitments.
- Multimodal and non-language foundation models — vision, audio, robotics, and scientific machine learning.
- recurrent-depth vision transformers;
- speech and audio encoders with adjustable loop counts;
- video models processing long temporal hierarchies;
- robotic policies that repeatedly refine state estimates or action plans;
- scientific models for iterative physical or chemical reasoning.
- Dependencies: The paper studies autoregressive text pretraining. Different modalities may have different depth requirements, data redundancy, memory patterns, and loss-to-capability relationships.
- Data-constrained foundation-model training strategies — AI policy and data governance.
- estimate the marginal value of collecting new data versus adding computational depth;
- compare licensing additional data with investing in training compute;
- use tied loops as a controlled response to data exhaustion;
- report capability per unique token rather than only total token count.
- Dependencies: Repetition can amplify memorization, privacy leakage, copyright exposure, and demographic bias. Any deployment on sensitive or proprietary data requires privacy, security, and memorization audits.
- Automated neural-architecture scaling systems — machine learning research and MLOps.
- stored parameter count;
- executed depth;
- loop count;
- weight sharing;
- growth timing;
- normalization and injection scales;
- token allocation and regularization.
- Such a system could fit architecture-specific scaling laws and select a configuration for a target loss, benchmark score, latency, memory budget, or energy limit.
- Dependencies: Reliable automation requires robust scaling-law estimation, uncertainty bounds, and safeguards against overfitting a small set of pilot runs. Search cost may offset the eventual training savings.
- Dynamic-depth and conditional-computation products — assistants, robotics, and autonomous systems.
- low-latency voice assistants for simple commands;
- deeper deliberation for medical or legal decision support;
- adaptive planning in robots;
- additional verification passes for code generation;
- compute-aware autonomous agents operating under battery constraints.
- Dependencies: Dynamic depth must be accompanied by calibrated confidence and safety guarantees. More passes do not necessarily imply more reliable outputs, and worst-case latency and predictable behavior are important in real-time systems.
- Energy-aware national and enterprise AI policy — climate, regulation, and procurement.
- equal-capability energy comparisons across architectures;
- disclosure of training FLOPs and wall-clock time;
- separate accounting for repeated and unique tokens;
- uncertainty intervals for extrapolated scaling claims.
- Dependencies: Such standards require standardized benchmarks, reproducible evaluation pipelines, and agreement on how to compare models trained on different data. Architecture changes alone cannot establish net environmental benefits.
- Specialized compact models for healthcare, finance, and enterprise analytics — regulated-domain AI.
- clinical-document summarizers;
- financial research assistants;
- private enterprise search models;
- scientific literature systems;
- compact models running inside regulated or air-gapped environments.
- Dependencies: Benchmark loss improvements must transfer to domain accuracy, calibration, interpretability, and safety. Deployment would require domain-specific validation, auditability, privacy protections, and human oversight; the paper does not establish suitability for high-stakes decisions.
- New theoretical understanding of effective computational depth — academia.
- identify layers that contribute little to predictions;
- determine when a model has reached a depth bottleneck;
- design normalization and skip-injection mechanisms;
- predict when growth will be beneficial;
- connect architecture, optimization, and scaling exponents.
- Dependencies: “Effective depth” is not yet a complete causal theory of scaling. Measurements based on intermediate predictions may correlate with, rather than fully explain, downstream capability and must be validated across tasks and architectures.
- Compute-efficient continual learning and model updating — enterprise software and robotics.
- adding untied blocks during successive domain updates;
- increasing tied loop counts as task complexity grows;
- retaining a stable prelude while specializing later core passes;
- using growth checkpoints for staged deployment.
- Dependencies: Continual learning introduces risks of catastrophic forgetting, distribution shift, optimizer-state mismatch, and security vulnerabilities. The paper does not directly test sequential task updates, so this application requires dedicated continual-learning experiments.
Glossary
- Affine relationship: A mathematical relationship of the form , often used after transforming variables logarithmically. “we fit an affine relationship in log--log space”
- Boundary operator: A transformation applied between computational blocks that normalizes a state and reinjects an earlier representation. “which normalizes and injects an earlier block”
- Compute multiplier: The ratio of the computational resources required by two architectures to achieve the same loss. “The compute multiplier of architecture over at loss is then .”
- Compute-optimal frontier: The set of model and data configurations that achieve the lowest loss for each available compute budget. “to be on the compute-optimal frontier”
- Compute-optimal scaling: Scaling model size and training data in the allocation that minimizes loss for a fixed amount of computation. “With increased computation, we scale each of these architectures in a compute-optimal fashion”
- Computational depth: The number of layers that meaningfully affect a model’s predictive output under a given compute budget. “we define the computational depth as the number of layers meaningfully influencing the predictive distribution”
- Computational graph: A graph representing computational operations and their dependencies in a model. “The untied model has the same computation graph and the same FLOPs as the tied one”
- Coda: The final group of transformer blocks that converts the internal representation into an output. “a coda of blocks produces the output”
- Core block: The repeatedly applied central block of a looped transformer. “A looped transformer applies the same core block of layers several times”
- Curse of depth: The degradation in the usefulness of deeper layers as residual representations grow and layer updates become relatively smaller. “One explanation for depth's limited returns is known as the curse of depth.”
- Data-constrained regime: A training setting in which the amount of unique training data is fixed while computation increases through repeated passes over the data. “in the data-constrained, multi-epoch setting”
- Dense transformer: A transformer architecture in which the model’s parameters are used for every input rather than selectively activated. “looped transformers achieve lower loss than dense transformers”
- Downstream metric: A performance measure evaluated on tasks or data outside the training-loss objective. “We do not see a discrepancy between downstream metrics and validation loss”
- Effective depth: The depth beyond which additional blocks no longer substantially change a model’s prediction. “The depth beyond which blocks stop changing the prediction is the effective depth”
- Executed depth: The total number of transformer blocks traversed during a forward pass, including repeated applications of shared blocks. “which we call the executed depth”
- Extrapolation: Prediction beyond the range of data used to fit a model or scaling law. “To test whether the exponent gap persists to larger scales through extrapolation”
- Feature learning: Learning representations or features that adapt to the data during training rather than using fixed features. “feature learning improves the exponent on hard tasks”
- FineWeb: A large-scale web-text dataset used for training and evaluating LLMs. “we train on FineWeb”
- FLOPs: Floating-point operations, a measure of computational work. “Each training token costs about $6N$ floating-point operations”
- Function-preserving operator: A network transformation intended to expand an architecture while initially preserving its input-output function. “staged training with function-preserving operators”
- Huber loss: A robust regression loss that combines squared-error and absolute-error behavior to reduce sensitivity to outliers. “We fit the irreducible loss in Equation~\ref{eq:compute-optimal} using a Huber loss”
- Inductive bias: A structural preference imposed by a model or learning method that influences which solutions it favors. “an inductive bias toward iterative computation”
- Irreducible loss: The limiting loss term that remains even as model size and training compute become arbitrarily large. “where and are fitted and is a chosen base compute”
- KL effective depth: Effective depth measured using the Kullback–Leibler divergence between intermediate and final output distributions. “We refer to this quantity as the KL effective depth for clarity in this work.”
- Learning-rate scaling rule: A prescribed relationship between model scale and the learning rate used during optimization. “Fourth, we fit a scaling rule for the learning rate”
- Logit lens: A method that decodes intermediate residual-stream representations into predicted output distributions. “The curse can be measured with the logit lens”
- Loop count: The number of times a core block is applied in a looped transformer. “ is the loop count”
- Looped transformer: A transformer that repeatedly applies the same core block during one forward pass. “A looped transformer applies the same block of layers several times in one forward pass”
- Mixture-of-Experts (MoE): A sparse architecture that routes each input through a subset of separately parameterized expert networks. “Mixture-of-Experts scaling laws predict a growing compute-efficiency advantage over dense transformers”
- Model growth: Increasing a model’s effective architecture during training, such as by activating additional layers or passes. “Model growth addresses this waste by reusing the trained weights of a smaller model”
- Multi-epoch training: Training in which the model processes the same dataset multiple times. “In the multi-epoch setting, looping has a helpful regularizing effect.”
- NLL: Negative log-likelihood, a loss measuring how poorly a probabilistic model assigns likelihood to observed outcomes. “Middle: answer NLL”
- Parameter tying: Reusing the same parameter values across multiple applications of a computational block. “Tying the weights, , gives a looped transformer”
- Pareto-better: Better on at least one objective without being worse on the others in a multi-objective comparison. “deep-narrow T5 models are Pareto-better on downstream tasks”
- Power law: A relationship in which one quantity varies as a constant times a power of another quantity. “Scaling laws follow a power law that depends on scaling constants and exponents.”
- Pre-norm transformer: A transformer architecture that applies normalization before each block rather than directly normalizing the residual stream afterward. “In pre-norm transformers, where normalization is applied to the input of each block”
- Prelude: The initial group of transformer blocks that embeds the input into an internal representation. “a prelude of transformer blocks embeds the input”
- Predictive distribution: The probability distribution over outputs produced by a model. “meaningfully influencing the predictive distribution”
- Recursive depth: Depth obtained by repeatedly applying a computational block, typically with shared parameters. “looping, also known as recursive depth”
- Recurrence: Repeated application of a transformation to an evolving internal state. “recursive reasoning models, a close relative of looped transformers”
- Regularization: A technique that discourages overfitting by constraining a model or its parameters. “Looping appears to act as a similar regularizer”
- Residual branch: The pathway in a residual network that computes an update added to the main representation stream. “scaling the pre-normalization output inside the residual branch”
- Residual stream: The representation pathway that carries and accumulates information across transformer blocks. “the residual stream grows with depth”
- Scaling exponent: The exponent governing how loss or performance changes as compute, parameters, or data increase. “architectural interventions can modify scaling exponents”
- Scaling law: An empirical or theoretical relationship describing how model performance changes with resources such as parameters, data, or computation. “A scaling law predicts how loss falls as training compute grows.”
- Sparse looped MoE: A mixture-of-experts model that combines sparse expert activation with repeated looped computation. “a sparse looped MoE has compute-efficiency gains that grow with scale”
- Weight decay: A regularization method that penalizes large parameter values during optimization. “Weight decay is the standard remedy.”
- Weight sharing: The use of identical parameters across multiple applications of a layer or block. “We isolate weight sharing”




