Loop the Loopies!
Abstract: We present the Loopie series, consisting of two Mixture-of-Experts (MoE) models: a 20B-parameter model with 2B active parameters and a 6B-parameter model with 0.6B active parameters. Looped Transformers have long faced a challenge: given an N times increase in pre-training compute, increasing the parameter count by a factor of N usually outperforms looping a model N times. Loopie addresses this challenge. Extensive ablation studies, including comparisons with a vanilla 30B-A3B model, show that Loopie substantially outperforms vanilla Transformer baselines trained with the same compute budget. With a novel post-training method, Loopie develops strong reasoning abilities and achieves frontier-level reasoning performance.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
A simple explanation of “Loop the Loopies!”
What is this paper about?
This paper introduces Loopie, a new kind of AI LLM that “thinks in loops.” Instead of just stacking many different layers, Loopie reuses each layer more than once before moving on. The authors show how to do this in a way that’s fair when comparing training costs, and they build two big models that use this idea. They also show that Loopie is very good at reasoning, reportedly reaching gold‑medal level on hard math and physics competition problems.
What main questions are the researchers asking?
- Can a looped Transformer (a model that repeats its own steps) do better than a normal Transformer if both are trained with the same amount of total computing effort?
- What is the best way to loop: repeat each layer as you go, or repeat the whole model from start to finish?
- How do you make this work with Mixture‑of‑Experts (MoE) models, which are common in today’s top AI systems?
- How many loops is “enough” to get the benefits without wasting compute?
How did they approach the problem?
To make this clear, here are the key ideas explained in everyday terms.
- Transformers and loops:
- A Transformer is like a factory line with many stations (layers). Most models add more stations to get better.
- Loopie tries something different: at each station, it runs that station twice in a row before moving on. Think of it like a worker checking and refining their work before passing it to the next station. The authors call this “layer‑loop.”
- Earlier work often repeated the whole factory line from start to finish, then did it again (“model‑loop”). Loopie shows that looping inside each station works better for big models.
- Mixture‑of‑Experts (MoE):
- Imagine a team of specialists; for each word, only a few specialists are called in. That saves time and energy while still giving you expert help.
- Loopie uses MoE so it can be large overall but only uses a small part of the model for each token, which is more efficient.
- Fair comparisons (compute‑matched training):
- If you repeat steps during training, you spend more computing effort. To be fair, you must compare a looped model against a normal model that uses the same total training “budget.”
- The authors match models by actual measured training time per step and tokens seen, not just by theoretical formulas.
- The “Loopie Recipe” (how they build Loopie):
- Start from a strong normal MoE model.
- Cut the number of stored layers in half and run each stored layer twice (layer‑loop). This reduces memory pressure during training because you save fewer checkpoints between layers.
- Use the freed memory to process bigger mini‑batches of data at once (like carrying more boxes per trip). Bigger mini‑batches make the hardware run more efficiently.
- Reinvest the gained efficiency into slightly widening/deepening the model until the overall training time per step matches the original model. Now both models are using about the same training budget, so the comparison is fair.
- How they tested it:
- They trained Loopie on lots of text (trillions of tokens).
- They compared it to a carefully matched normal MoE model (based on the Qwen3 family).
- They checked performance on standard benchmarks (like ARC, MMLU, and others).
- They ran “ablation” tests (turning features on/off) to see which parts really matter.
- They climbed a “scaling ladder,” repeating the fair comparison at multiple model sizes to see if the advantage holds as models get bigger.
What did they find, and why does it matter?
- Layer‑loop beats model‑loop as training goes on:
- Early in training, repeating the whole model can look slightly better.
- But as you keep training on more data, repeating each layer before moving on pulls ahead and stays ahead.
- Under the same training budget, Loopie wins:
- The main model (Loopie-20B-A2B) eventually overtook a bigger normal baseline (Qwen3‑like 30B‑A3B) when both were trained under matched compute.
- In other words, “a bit of looping done right” gave more improvement than “just making the normal model bigger” for the same training cost.
- It scales across sizes:
- The advantage of Loopie showed up at multiple sizes, not just at one special size. This suggests the idea is robust and not a fluke.
- The way you loop matters:
- An ablation where they removed the layer‑loop pattern (but kept similar compute) performed worse. So it’s not just looping; it’s looping in the right place that helps.
- Two loops is the sweet spot:
- They tested adding more loops and saw diminishing returns—the extra boost was small compared to the extra cost in training compute.
- Using exactly two passes per layer gave the best trade‑off between “more thinking” and “not wasting compute.”
- Strong reasoning after post‑training:
- With a special post‑training process focused on reasoning and STEM content, Loopie showed very strong problem‑solving ability, reportedly reaching gold‑medal performance on tough math and physics Olympiad problems without external tools.
What could this change in the future?
- Smarter use of compute:
- The study shows that carefully designed looping can turn the same training budget into better results, especially when paired with MoE and hardware‑aware engineering.
- Better reasoning without just making models huge:
- Instead of endlessly stacking more layers, models can reuse what they have to refine their thinking on each step. That can lead to better reasoning, especially on complex, multi‑step problems.
- Practical for big systems:
- Layer‑loop is friendly for the way big training systems run, making it easier to scale and efficient to train.
- A new direction for building AI:
- Future LLMs may combine modest looping, MoE, and compute‑matched design to reach higher capability without always spending dramatically more compute.
In short, this paper argues—and shows with experiments—that repeating each layer a couple of times, done in a compute‑fair way, can beat simply making a normal model bigger. That makes “looping” a promising tool for building more capable and more efficient AI systems.
Knowledge Gaps
Knowledge gaps, limitations, and open questions
Below is a single, concrete list of what remains missing, uncertain, or unexplored in the paper, framed to guide future research.
- Compute accounting and fairness:
- The “compute-matched” protocol is based on measured optimizer-step wall-clock time in Megatron-LM rather than FLOP-equated training; this conflates architectural gains with implementation- and hardware-specific efficiencies (e.g., kernel fusion, communication overlap, microbatch scheduling). How do results change under strict FLOP matching and across different training stacks (e.g., DeepSpeed, JAX/TPU, FSDP/PyTorch2.x)?
- Matching by step time while altering per-device microbatch size and gradient-accumulation steps keeps tokens/step fixed but may change hardware utilization and optimizer noise scale in ways that affect final quality. How much of Loopie’s advantage comes purely from the doubled microbatch (and reduced accumulation) vs. recurrence?
- No accounting of energy usage, cost, or carbon footprint; wall-clock parity does not guarantee energy parity. Are the recurrence gains robust when normalized by joules or ?
- Generality and portability:
- Evidence is presented on Qwen3-like MoE backbones; it is unclear whether layer-loop advantages persist for dense Transformers, other MoE designs (e.g., expert capacity, gating, routing strategies), or different attention variants (e.g., multi-query, grouped-query, FlashAttention variants).
- The infrastructure benefits (e.g., locality, memory) rely on a specific activation checkpointing policy that encloses all recurrent applications inside one unit. Do the same gains materialize under alternative checkpointing or memory layouts used in other frameworks/hardware (A100 vs H100 vs TPU vs AMD GPUs)?
- Parallelism settings are tuned per model (e.g., EP=8, MBS changes), and results show best-throughput settings. How sensitive are the conclusions to TP/PP/EP configurations, network fabrics, and cluster topologies?
- Scaling behavior and limits:
- The ladder stops at a 20B-parameter (2B active) MoE; it remains unknown whether the layer-loop edge holds at 100B+, trillion-parameter, or frontier-scale MoE settings with larger expert counts and deeper networks.
- Only loops are used in large runs; the loop-count sweep supporting diminishing returns is done at smaller scales and under imperfect compute matching. What is the compute-matched trade-off curve for at large scales, and does adaptive or per-layer loop allocation change the conclusion?
- Training dynamics and theory:
- The claim that layer-loop reduces gradient conflict by sharing parameters at adjacent effective depths is plausible but untested; no gradient conflict metrics, representational diagnostics, or layer-wise loss/gradient analyses are provided. Can we quantify how layer-loop changes gradient alignment, curvature, or representation drift across effective depth?
- It is not shown whether the late-phase win (layer-loop overtakes model-loop after ~1.2T tokens) stems from improved optimization dynamics, regularization, or emergent representation structure. What mechanistic factors drive the phase transition in training curves?
- No formal scaling laws are provided for performance as a joint function of stored width (), stored depth (), and loops (). Can a predictive scaling model be established to guide // selection beyond empirical sweeps?
- Interaction with MoE routing:
- The effect of recurrence on expert routing is unexplored: Do token-to-expert assignments stabilize or oscillate across loop applications? Is load balancing improved or degraded across loops? How does gating calibration change with layer-loop?
- Communication costs and expert-activation sparsity under layer-loop are not quantified; do repeated applications of the same layer concentrate traffic in specific experts, increasing stragglers or variance in step time?
- Inference-time behavior and deployment:
- Inference latency/throughput and memory with layer-loop vs. baselines are not reported. How do repeated per-layer applications affect decoding speed, KV-cache size, batching efficiency, and server utilization?
- No results on long-context performance (e.g., KV-cache growth, attention computation) with layer-loop. Does recurrence interact beneficially or adversely with long-context attention mechanisms or compression?
- Alternative compute allocations:
- The work focuses on reallocating compute from stored parameters to recurrence; it does not compare against spending the same compute on more data, better curricula, or optimizer/hyperparameter improvements (e.g., LR schedules, EMA, gradient clipping strategies). Under a fixed budget, how do these alternatives compare to adding loops?
- The ladder uses “overtrained” regimes (e.g., 1000× active parameters tokens). Are the gains preserved under compute-optimal (Chinchilla-like) allocations balancing model size and data?
- Post-training contributions and evaluation scope:
- The “novel post-training pipeline” is asserted as critical to reasoning performance (e.g., IMO/IPhO gold) but not described in sufficient detail to isolate its impact vs. the Loopie architecture. Controlled ablations (architecture-only vs. post-training-only vs. both) are missing.
- The training data mix (3T + 1.26T tokens) is only coarsely described; without precise sources and decontamination procedures, the reported competition results (IMO/IPhO) risk data leakage. What are the contamination audits, scoring protocols, and replication details for these claims?
- Benchmark coverage is narrow in the pre-training section (eight LM Harness tasks). Missing are comprehensive evaluations on multilingual tasks, code benchmarks, safety, factuality, calibration, robustness, and tool-use—especially given the “no-tools” claim.
- Robustness and safety:
- No analyses on safety, harmful content generation, jailbreak resistance, or calibration under adversarial prompts, despite large-scale pre-training with web and synthetic data. How does layer-loop affect safety profiles and failure modes?
- Robustness to distribution shift, noisy inputs, or adversarially filtered datasets is not evaluated; does recurrence improve or harm robustness?
- Practical reproducibility:
- While repos are linked, key implementation details—activation checkpointing boundaries, pipeline schedules, memory trade-offs enabling 2× microbatch, and exact training configurations—are not fully specified. Can independent teams reproduce the measured step-time parity and gains?
- The generality of the Loopie Recipe hinges on measured microbatch efficiency improvements; without a standardized profiling protocol, results may not transfer to other clusters.
- Design extensions not explored:
- Adaptive or learned per-layer loop counts, early-exit policies, or token-conditional recurrence (e.g., allocate more loops to “hard” tokens) are not investigated; these could improve compute-accuracy trade-offs.
- Alternative recurrence schedulings (e.g., block-group loops, interleaved layer/model loops, cross-layer refinement steps) and their compute efficiencies are not evaluated.
- Interactions with training techniques (e.g., distillation from deeper stored models, curriculum learning across loops, or auxiliary losses encouraging cross-loop consistency) remain open.
- Open methodological questions:
- How does layer-loop interact with regularization (dropout, weight decay), normalization schemes, and optimizer states across loops (e.g., should moments be shared or specialized per loop application)?
- How do positional embeddings/encodings behave across loop steps? Are there benefits to loop-conditioned parameters or depth-aware modulation to better align with effective depth?
These gaps delineate a roadmap for validating, generalizing, and mechanistically understanding layer-looped MoE Transformers under genuine compute- and deployment-relevant constraints.
Practical Applications
Immediate Applications
Below are concrete, deployable use cases that leverage Loopie’s layer-loop recurrence, compute-matched scaling (“Loopie Recipe”), and MoE-compatible implementation.
- LLM training under fixed compute budgets with higher final quality — Sectors: AI labs, cloud providers, foundation-model teams. Tools/workflows: apply the Loopie Recipe to existing MoE baselines; measure optimizer-step wall-clock time to select (D, L, R=2); reuse megatron-loopie to halve stored depth, double per-device microbatch, and reallocate the efficiency into width/depth. Assumptions/dependencies: activation checkpointing that ties activation memory to stored depth; ability to increase microbatch and adjust gradient accumulation; Megatron-LM or similar infra; same token budget and optimizer settings for compute-matched comparisons.
- Throughput uplift and better GPU utilization via layer-local recurrence — Sectors: MLOps, HPC scheduling. Tools/workflows: refactor pipeline parallelism to keep repeated applications within the same stage, reducing bubbles and cross-stage loops; adopt megatron-loopie’s scheduling defaults; profile end-to-end step time, not FLOPs. Assumptions/dependencies: pipeline/tensor/expert parallel search to find the fastest configuration; adequate memory headroom after halving stored layers.
- Inference serving of looped MoE LLMs in vLLM — Sectors: AI SaaS, platform providers. Tools/workflows: deploy Loopie-20B-A2B/Loopie-6B-A0.6B via vllm-loopie; expose per-request knobs for R=2 execution; offer “reasoning tier” SKUs. Assumptions/dependencies: inference engine compatibility with layer-loop; latency budgeting for 2× layer applications; quantization/kv-cache policies validated for looped execution.
- Reasoning-centric tutoring and STEM assistance — Sectors: education, edtech. Tools/products: math/physics problem-solving tutor; auto-grading and feedback for stepwise reasoning; classroom assistants tuned on curriculum data. Assumptions/dependencies: safety alignment and content filtering; licensing and evaluation for educational settings; monitoring for hallucinations despite strong reasoning.
- Cost-aware model procurement and evaluation policy — Sectors: public agencies, funders, corporate governance. Tools/workflows: require compute-matched reporting (wall-clock per optimizer step, microbatch schedule, token budgets) in RFPs and grant reviews; benchmark quality vs. realized training cost. Assumptions/dependencies: adoption of standardized reporting templates; reproducible timing on disclosed hardware.
- Memory-efficient finetuning on modest hardware — Sectors: SMEs, applied research groups. Tools/workflows: LoRA/adapters on looped backbones with reduced stored depth to fit within fewer/cheaper GPUs; maintain R=2 at train and inference. Assumptions/dependencies: adapter libraries that support tied/shared weights across recurrent applications; careful LR/optimizer tuning due to altered gradient flow.
- Simplified large-scale pipeline engineering — Sectors: framework vendors, infra teams. Tools/workflows: integrate layer-loop as a first-class schedule in Megatron/DeepSpeed; reduce cyclic inter-stage traffic and activation transfers; consolidate activation checkpoint units per stored layer. Assumptions/dependencies: engineering bandwidth to merge scheduling changes; test coverage under diverse PP/TP/EP settings.
- Knowledge distillation from looped teachers for compact students — Sectors: software productivity, on-prem AI. Tools/workflows: use Loopie as a teacher for stepwise rationales and self-consistency signals; distill to smaller dense/MoE students; evaluate on reasoning-heavy suites (MMLU, GSM8K, STEM). Assumptions/dependencies: synthetic data pipelines; licensing for teacher use; careful prompt/rationale filtering.
- Domain copilots that need robust multi-step reasoning — Sectors: software engineering, data science, operations. Tools/products: code assistants that handle refactoring/bug triage; analytics conversational agents for multi-hop queries; operations runbooks with rationale. Assumptions/dependencies: domain-tuned post-training; guardrails/tools integration if external calls are added; monitoring for long-context stability.
- Research baselines for recurrence vs. depth trade-offs — Sectors: academia. Tools/workflows: reuse released checkpoints/code to study representation depth locality, gradient interference, and scaling laws; compute-matched ladders across sizes. Assumptions/dependencies: access to GPUs for controlled ablations; consistent dataset mixtures for fair comparisons.
Long-Term Applications
These opportunities likely require further research, scaling, or ecosystem changes before broad deployment.
- Frontier-scale looped MoE at trillion-parameter capacity under fixed compute — Sectors: AI labs, hyperscalers. Tools/workflows: extend the Loopie Recipe to multi-node, multi-cluster settings; co-optimize (D, L, R), routing, sequence length, and microbatch at scale; integrate advanced optimizer states offloading. Assumptions/dependencies: stable training with larger experts and deeper stored stacks; data curation and post-training pipelines at scale.
- Adaptive recurrence (per-token/per-sequence R) for controllable latency/quality — Sectors: AI platforms, consumer apps. Tools/products: “pay-for-quality” runtime that increases loops on hard queries; uncertainty estimators to gate extra iterations. Assumptions/dependencies: reliable difficulty estimators; scheduler that preserves cache locality; safeguards against degenerate looping.
- Hardware and compiler co-design for layer-local reuse — Sectors: GPU/accelerator vendors, systems research. Tools/workflows: cache hierarchies tuned to re-access the same layer weights and gradients; compiler passes for fused multi-application kernels; memory planners aware of stored vs. executed depth. Assumptions/dependencies: vendor engagement; ISA/runtime changes; robust kernel libraries.
- Multimodal and embodied agents with recurrent refinement — Sectors: robotics, autonomous systems, vision-language. Tools/products: VLMs that iteratively refine perception before reasoning; planners that use R=2 layer-loop inside decision stacks; tool-using agents with local refinement cycles. Assumptions/dependencies: adaptation of layer-loop to cross-attention and modality experts; latency budgets for control loops.
- Sustainable AI and carbon-aware training policy — Sectors: policy, sustainability. Tools/workflows: require compute-matched reporting and microbatch/throughput disclosures for lifecycle analyses; incentivize architectures that convert memory headroom into higher efficiency. Assumptions/dependencies: accepted LCA methodologies; third-party audits of reported step times.
- Robustness, verification, and safety research for shared-parameter depth — Sectors: AI safety, formal methods. Tools/workflows: analyze gradient conflict across adjacent effective depths; certify stability of recurrent steps; adversarial tests tailored to looped schedules. Assumptions/dependencies: new theory and tooling; benchmark suites for recurrent-specific failure modes.
- Domain optimization and planning copilots — Sectors: finance (portfolio/risk), energy (grid scheduling), logistics (routing), biotech (assay design). Tools/products: in-context iterative solvers embedded in LLMs, leveraging recurrence for local improvement steps. Assumptions/dependencies: domain data access, compliance and auditability; tool APIs for ground-truth checks.
- Auto-tuners for compute-matched architecture search — Sectors: MLOps tooling, platform engineering. Tools/products: services that pick (D, L, R), EP/TP/PP, and microbatch to match a target wall-clock budget with measured step-time loops; SLA-based configs. Assumptions/dependencies: reliable profilers; reproducible timing across fleets; integration with schedulers.
- Federated and bandwidth-constrained training with shared parameters — Sectors: healthcare, edge AI, privacy-preserving ML. Tools/workflows: exploit reduced stored depth to lower communication per step; perform local R steps before aggregation. Assumptions/dependencies: federated algorithms compatible with MoE routing; privacy constraints; convergence guarantees.
- Standardization of compute-matched benchmarking — Sectors: conferences, standards bodies. Tools/workflows: metadata schema to report per-step time, microbatch schedule, activation policy, token budget; leaderboards that rank quality vs. realized compute. Assumptions/dependencies: community consensus; reproducibility infrastructure across hardware.
- On-device and small-cluster reasoning models — Sectors: mobile/edge, SMEs. Tools/products: sub-1B active-parameter looped models with R=2 for offline reasoning assistants and vertical copilots. Assumptions/dependencies: further compression/quantization for memory and latency; adaptation of layer-loop to constrained accelerators; careful evaluation of quality vs. cost.
Glossary
- Ablation: A controlled experiment that removes or alters a component to isolate its effect on performance. "Extensive ablation studies, including comparisons with a vanilla 30B-A3B model, show that Loopie substantially outperforms vanilla Transformer baselines trained with the same compute budget."
- Activation checkpointing: A memory-saving training technique that re-computes certain intermediate activations during backpropagation instead of storing them. "shortens the reuse distance for parameters and gradient contributions and simplifies activation checkpointing and gradient accumulation, especially under parameter sharding or offloading."
- Activation memory: GPU memory consumed by stored intermediate activations during training. "Consequently, the dominant activation memory term scales with stored depth rather than executed depth."
- ARC-AGI: A challenging abstract reasoning benchmark (Abstraction and Reasoning Corpus). "These advantages are particularly visible on abstract reasoning tasks such as ARC-AGI, Sudoku, and Maze"
- ARC-Challenge: A standardized multiple-choice benchmark derived from grade-school science exams. "ARC-Challenge~\citep{clark2018think}"
- ARC-Easy: An easier subset of ARC designed for evaluation of basic science knowledge. "ARC-Easy~\citep{clark2018think}"
- BoolQ: A yes/no question-answering benchmark based on naturally occurring questions. "BoolQ~\citep{clark2019boolq}"
- Chinchilla-style compute-optimal prescriptions: Guidelines for balancing model size and data to optimize performance for a given compute budget. "placing the models in a heavily overtrained regime relative to standard Chinchilla-style compute-optimal prescriptions."
- CommonsenseQA: A multiple-choice QA benchmark focused on commonsense reasoning. "CommonsenseQA~\citep{talmor2019commonsenseqa}"
- Compute-matched: A comparison methodology that matches models by realized training compute (e.g., wall-clock per step) rather than parameter count or theoretical FLOPs. "a compute-matched scaling recipe for choosing stored width, stored depth, and recurrent depth."
- Data annealing: A curriculum-like post-training strategy that shifts toward higher-quality or targeted data over time. "we conduct high-quality data annealing using 1.26T tokens, with an emphasis on high-quality synthetic, STEM, code, mathematical reasoning, and web data."
- Decoder-only Mixture-of-Experts Transformer: A Transformer that generates outputs autoregressively (decoder-only) and uses expert routing to scale capacity. "its backbone is a decoder-only Mixture-of-Experts Transformer"
- Effective depth: The depth position within the computational graph after accounting for recurrent re-use of layers. "In contrast, layer-loop reuses a layer at adjacent effective depths, resulting in a more local and potentially more coherent parameter-sharing pattern."
- End-to-end optimizer-step time: The measured wall-clock time to complete one optimizer update (accounting for all training overheads). "select the Loopie configuration whose measured end-to-end optimizer-step time most closely matches the non-recurrent reference."
- Expert parallelism (EP): Parallelization strategy that distributes experts across devices for MoE layers. "Loopie-20B-A2B uses EP = 8 and MBS = 2, while Qwen3-30B-A3B uses EP = 8 and MBS = 1."
- FLOPs: Floating-point operations, a proxy for computational cost. "evaluate quality as a function of parameters, data, and total training FLOPs rather than parameter count alone"
- Gradient accumulation: Technique to simulate a larger batch by accumulating gradients over multiple microbatches before updating weights. "the number of gradient-accumulation steps is reduced proportionally"
- HellaSwag: A commonsense inference benchmark with adversarially filtered options. "HellaSwag~\citep{zellers2019hellaswag}"
- In-context learning: The ability of a model to learn tasks from examples provided in its input context without gradient updates. "Looped Transformers can outperform vanilla Transformers on in-context learning and data-fitting tasks"
- Inductive bias: Built-in assumptions that guide a model’s learning and generalization behavior. "recurrence provides a powerful inductive bias for compositional generalization, rule discovery, and inductive reasoning"
- Layer-loop: A recurrence schedule where each layer is iterated multiple times before passing to the next layer. "Loopie uses layer-loop, in which each layer is applied recurrently before the computation moves to the next layer."
- Leading-order Transformer block work proxy: An approximate metric proportional to the dominant computation in Transformer blocks, typically scaling with L·D2. "We report the normalized leading-order Transformer block work proxy"
- LM Evaluation Harness: A standardized toolkit for evaluating LLMs on many benchmarks. "We evaluate the pre-trained checkpoints using the LM Evaluation Harness framework"
- Microbatch size (MBS): The per-device batch size processed before gradient synchronization or accumulation; affects memory and throughput. "the per-device microbatch size to be doubled"
- Mixture-of-Experts (MoE): An architecture that routes tokens to a subset of expert networks, increasing capacity while keeping per-token compute lower. "Mixture-of-Experts (MoE) models expand total model capacity while keeping the number of active parameters per token relatively small"
- Model-loop: A recurrence schedule where the entire layer stack is repeatedly applied end-to-end. "Prior looped LLMs, such as Ouro and Huginn \citep{zhu2025scalinglatent,geiping2025scalinglatent}, mainly use what we call model-loop."
- MoE routing: The mechanism that selects which experts process each token. "up to MoE routing and implementation constants"
- MMLU: A benchmark suite measuring multitask language understanding across many subjects. "MMLU~\citep{hendrycks2021measuring}"
- OpenBookQA: A science QA benchmark requiring the use of a provided fact book plus additional knowledge. "OpenBookQA~\citep{mihaylov2018openbookqa}"
- Overtrained regime: A setting where training tokens far exceed compute-optimal prescriptions for the given model size. "placing the models in a heavily overtrained regime relative to standard Chinchilla-style compute-optimal prescriptions."
- Parameter sharding: Distributing model parameters across devices to fit large models into memory. "especially under parameter sharding or offloading."
- Pipeline bubbles: Periods where pipeline stages are idle due to dependencies or scheduling inefficiencies. "increase communication overhead and the number of pipeline bubbles, and reduce device utilization."
- Pipeline parallelism (PP): Splitting the model across devices by layers to increase parallelism. "This locality is particularly beneficial for pipeline parallelism"
- Pre-training compute budget: The total computational resources allocated for training a model before fine-tuning or inference. "under the same pre-training compute budget"
- Qwen3-MoE: A specific family/design of MoE Transformers used as a reference architecture. "Loopie largely follows the Qwen3-MoE architecture."
- Reuse distance: The span between consecutive uses of the same data or parameters, affecting cache/memory locality. "shortens the reuse distance for parameters and gradient contributions"
- Scaling ladder: A series of model sizes and matched counterparts used to study scaling behavior systematically. "Scaling ladder for Loopie."
- Scaling laws: Empirical relationships describing how performance scales with model size, data, and compute. "scaling laws for stable looped LLMs"
- Sequence length: The number of tokens in each input sequence processed by the model. "we fix the hardware allocation, sequence length, number of tokens per optimizer step, activation-checkpointing policy, optimizer, and training data."
- SmallInit: A specific initialization scheme with reduced variance for Transformer parameters. "we use SmallInit:"
- Stored layers: The non-recurrent layers physically present in the model (as opposed to effective depth due to looping). "constructing a recurrent seed model by halving the number of stored layers"
- Tensor parallelism (TP): Splitting tensor operations across devices to enable training larger models. "we jointly search over tensor parallelism, expert parallelism, and microbatch size."
- Throughput: The rate of tokens processed per unit time during training. "the highest average pre-training throughput achieved for each model during large-scale benchmarking."
- Universal Transformers: A Transformer variant that applies the same layer recurrently to achieve depth through iteration. "Looped Transformers, first introduced as Universal Transformers \citep{dehghani2018universal}"
- Wall-clock training cost: Real-world time spent training, encompassing all overheads and efficiencies. "this also approximately matches total wall-clock training cost."
- Weight tying: Sharing parameters between the input embedding and output softmax layers. "or the shared embedding/unembedding matrix when weight tying is used"
- WinoGrande: A large-scale dataset for evaluating pronoun resolution and commonsense reasoning. "WinoGrande~\citep{sakaguchi2020winogrande}"
- Xavier fan-in/fan-out initialization: A parameter initialization method that balances variance across layers. "This scale corresponds to Xavier fan-in/fan-out initialization for a Transformer FFN with an expansion ratio of $4$"
- Latent computation: Additional computation performed via recurrence or inner loops without increasing stored parameters. "Huginn scales to 3.5B parameters and uses 32 recurrent steps to trade parameters for latent computation"
- Leading-order pre-training compute: The dominant term in compute cost scaling for training, often proportional to L·D2·R. "The leading-order pre-training compute~\citep{hoffmann2022training} scales as"
- Loop steps: The number of recurrent applications of a layer or model within a forward pass. "each trained with two loop steps."
- LM pre-training throughput: The tokens-per-second achieved during LLM pre-training. "The left panel reports the average score across eight downstream benchmarks, while the right panel reports the highest average pre-training throughput achieved"
- Data mixture: The composition of datasets used during training. "with the same backbone, optimizer, data mixture, and token budget as Loopie-6B-A0.6B"
Collections
Sign up for free to add this paper to one or more collections.






