Source-linked AI summary

How to Loop Your Transformer: Loop Scaling, Specialization, and Parallel Inference

Chanakya Ekbote, Artidoro Pagnoni, Devendra Singh Sachan, Shruti Bhosale, Mike Lewis, Maryam Fazel-Zarandi, Shashank Rajput, Sujan Kumar Gonugondla

arXiv:2610.40325v1cs.LGcs.AI

TL;DR

Looping offers parameter-efficient depth, but its value depends on training-compute and autoregressive-inference constraints, and prior work leaves open how design choices interact. The paper compares loop configurations and introduces loop-specific adapters and modified parallel-loop designs. Its findings show that the best looping design depends on the resource constraint, while modifications can recover strong quality with parallel decoding.

  • Problem

    How looping designs interact across model-size, training-compute, and autoregressive-inference constraints remains unclear across scales and training budgets.

    Source: §1 · p. 1
  • Method

    The paper studies dense decoder-only transformers trained from scratch, varying looped components, loop-specific low-rank adapters, and inter-loop information flow.

    Source: §1 · pp. 1–3
  • Results

    Full-transformer looping gives the strongest quality at a fixed parameter budget, middle-stack looping returns more under constrained training FLOPs, and modified PLTs can retain strong quality with parallel decoding.

    Source: §1 · pp. 2–3
  • Takeaways & Limitations

    Effective looping is a multidimensional design problem involving stored parameters, training FLOPs, data efficiency, and inference efficiency.

    Source: §5 · p. 10

    The study covers dense models up to 1B parameters and focuses primarily on likelihood-based evaluation, leaving larger, MoE, post-trained, and free-form-generation settings unevaluated.

    Source: J Limitations · p. 146

Abstract

from arXiv · show

Looping in transformer models reuses weights by repeatedly applying the same transformer, or parts of it, making the model deeper without increasing its parameter count. Whether looping is useful depends on which constraint dominates: model size, training compute, or autoregressive inference efficiency. We study these trade-offs jointly in dense decoder-only transformers trained from scratch, varying which parts of the model are looped, how many loops are applied, and how information is passed between loops. Our experiments span models with up to 1B parameters, trained on up to 155B tokens with up to $1.07\times10^{21}$ FLOPs and 32 loops. We find that looping the full transformer generally gives the strongest quality at a fixed parameter budget, whereas looping a middle block of layers gives a better return when training FLOPs are constrained. Adding loops is not uniformly beneficial: gains eventually saturate, reverse, or become unstable. This motivates asking whether forcing every loop to use the same weights limits the benefit of deeper looping. We address this by adding small loop-specific low-rank adapters that improve quality, with larger gains as more loops are added. Looped transformers also suffer a decoding slowdown proportional to the number of loops. Parallel Loop Transformers address this by passing hidden states between loops across adjacent token positions, allowing loop stages to run concurrently. However, in our experiments the original formulation does not consistently retain the quality gains of ordinary looping. We find that preserving the current-token embedding and separately normalizing it and the previous-token hidden state before combining them recovers strong performance across model scales and training budgets. Together, these results show that effective looping requires matching the design to the resource constraint and inference setting.

1 Introduction

Looping trades parameter efficiency against training-compute and autoregressive-inference costs, and prior work leaves open how these choices interact across scales and budgets. This study compares looping designs and develops loop-specific adapters and parallel-loop modifications to address those trade-offs.

Main Contributions

  • Figure 1 reports fewer training tokens and FLOPs to reach a given DCLM BPB for looping methods, while retaining or improving downstream accuracy.Modified PLT variants provide the largest relative data-efficiency gains; modified PLT and Looped variants are more FLOP-efficient than Standard Looping.Source: Figure 1 · p. 2

Study scope

  • The controlled study trains dense decoder-only transformers from scratch across models up to 1B parameters, 155B tokens, 1.07 × 10^21 FLOPs, and 32 loops.The paper examines model-size, training-compute, and autoregressive-inference constraints jointly.Source: §1 · p. 2

Main Contributions

  • Looping the full transformer gives the strongest quality at a fixed parameter budget, while middle-stack looping gives a better return when training FLOPs are constrained.Adding loops is not uniformly beneficial: gains can saturate, reverse, or become unstable.Source: §1 · p. 2
  • Small loop-specific low-rank adapters improve quality, with their gains becoming more consistent as shared weights are reused across more loops.They allow each loop to learn a slightly different transformation while retaining shared main weights.Source: §1 · p. 3
  • Modified PLTs preserve parallelizable decoding while improving quality by retaining the current-token representation, separately normalizing inputs, and controlling their combination.Similar changes also improve standard full-transformer looping.Source: §1 · p. 3

2 Background and Methods

The methods vary which transformer components are looped, allow limited loop-specific adaptation, and alter inter-loop dependencies to support parallel inference. Together, these designs distinguish parameter sharing, loop specialization, and cross-token parallelism.

2.1 Different Ways to Loop a Transformer

  • Full-stack looping repeats the entire transformer stack; per-layer looping repeats each block before proceeding, while middle-stack and middle-layer designs loop only a contiguous middle region.The study also loops full blocks, attention only, the MLP only, or attention and MLP independently.Source: §2.1 · p. 3

2.2 Loop-Specific Specialization

  • Loop-specific specialization adds small loop-specific LoRA adapters while keeping the main transformer weights shared.For a shared matrix W, each loop uses W plus a learned low-rank update.Source: §2.2 · p. 3

2.3 Parallelizing Loops During Inference

  • Cross-Loop Parallelism passes the previous loop’s state from the preceding token position, allowing current-token loop computations to run simultaneously during autoregressive decoding.The first loop receives the current-token embedding.Source: §2.3 · pp. 3–4
  • The original PLT additionally uses KV sharing and gated sliding-window attention to reduce KV-cache memory, and the experiments separate these mechanisms to study their effects.Later loops reuse the first loop’s full KV cache and maintain a small local sliding-window cache.Source: §2.3 · p. 4

3 Experiments

The experiments compare looping designs across resource budgets, test loop-specific adapters, and examine modifications that recover quality in parallel loop inference. Full-stack looping favors fixed parameter and data budgets, while middle-stack looping is more effective under tight training-compute constraints.

3.1 Experimental Setup

  • Models span 70M to 1B parameters, with training budgets from 10 to 160 tokens per parameter; DCLM validation BPB is the primary quality measure.The data mixture and training setup are held fixed across architectures.Source: §3.1 · p. 4

3.2 Which Forms of Looping Work, and When?

  • Moderate looping improves DCLM BPB across evaluated designs, scales, and TPP settings, but gains diminish and can saturate, reverse, or become unstable at larger loop counts.Higher TPP supports more consistent gains; independently looping attention and the MLP degrades sharply as loops increase.Source: §3.2 · p. 4
  • Full-Stack Looping can attain lower BPB when compute is available, while Middle-Stack Looping gives the best return at lower training-FLOP budgets.The study also compares which components are looped and their order; the first and last ⌊B/3⌋ blocks run once in middle-stack and middle-layer designs.Source: §3.2 · p. 5, Figure 2 · p. 5, Figure 3 · p. 6

3.3 When Should Loops Specialize?

  • Loop-specific specialization yields clearer gains at L = 4 or 8 than at L = 2, with Loop Matrix performing best among the tested options.At 300M, specialization adds 1.1–4.3% non-embedding parameters, versus 51.4% for doubling model depth, but is less compute-efficient than the doubled-depth reference at comparable FLOPs.Source: §3.3 · p. 6

3.4 Stabilizing PLT and Looping

  • Raw shifted PLT and its reconstructed variants do not recover Full-Stack Looping quality, while normalized and gated shifted variants approach it across evaluated configurations.Separate normalization addresses mismatched input magnitudes, and controlling the mixture also matters; separate per-loop KV caches give the best quality, while KV sharing with normalized G-SWA approaches it with less cache storage.Source: §3.4 · pp. 7–8
  • At 1B and L = 2, Normalized Shifted PLT beats Full-Stack Looping at every displayed training budget and closely tracks Normalized Unshifted PLT; at L = 4, its gap to the unshifted control widens.Both normalized PLT variants separately normalize the current-token embedding and hidden state and combine them with a rank-8 linear gate.Source: §3.4 · pp. 8–9, Figure 8 · p. 9
  • In the evaluated over-trained regime, two-loop models at TPP 80 reach a given BPB with fewer training FLOPs than Vanilla models at TPP 160 across model sizes from 100M to 1B.Four-loop models can achieve lower absolute BPB but provide a weaker improvement per training FLOP.Source: §3.4 · p. 9

4 Related Work

Prior looping studies vary in design and resource constraints, making it difficult to separate design effects from budget effects. This work connects design, loop-specific weights, and parallel inference within a common setting.

4 Related Work

  • Earlier scaling studies compare recurrence with added physical depth under differing resource constraints, while other work examines where and how recurrence enters transformers.The authors argue that differences in designs and budgets make their effects difficult to separate.Source: §4 · p. 9
  • Unlike work that adapts pretrained transformers, this study trains loop-specific adapters with the looped transformer from scratch and tests their usefulness as loop count rises.Relaxed Recursive Transformers (Bae et al., 2025) add parameters when converting a pretrained transformer into a looped model.Source: §4 · p. 9
  • Prior PLT work parallelizes decoding by shifting information across token positions, but reported gains can diminish as parallel loops increase; this study tests what the transition must preserve.The paper links this question to preserving the current-token embedding and separately normalizing it and the previous-token state.Source: §4 · pp. 9–10

5 Conclusion and Future Directions

Effective looping is a multidimensional design problem spanning stored parameters, training FLOPs, data efficiency, and inference efficiency. Future work could combine PLT with speculative decoding and develop a theory of recurrence stability and favorable regimes.

5 Conclusion and Future Directions

  • Looping must be evaluated jointly across stored parameters, training FLOPs, data efficiency, and inference efficiency.Source: §5 · p. 10
  • Combining PLT with speculative decoding is proposed as a direction for further reducing inference latency.Source: §5 · p. 10
  • A theory could explain how normalization and current-token embedding reinjection affect recurrence stability and which regimes favor standard looping or PLT.Source: §5 · p. 10

6 AI Use Statement

This section examines transformer looping across parameter, training-compute, and inference-efficiency constraints, including loop-specific LoRA and Parallel Loop Transformers. It also discloses how generative AI was used.

6 AI Use Statement

  • Generative AI tools assisted with writing, coding, editing, debugging, and sanity checks, but not with core methodology, hypotheses, experiment design, or result interpretation.Authors reviewed generated text and code, validated AI-assisted code, independently verified analyses and results, and take responsibility for the final work.Source: §6 · p. 10

Looped Transformers.

  • The paper jointly examines loop placement, depth, specialization, and autoregressive state propagation in dense models trained from scratch, rather than identifying one universally optimal looping design.Its comparisons consider fixed parameter, data, and training-FLOP budgets; the preferred design changes with the resource constraint.Source: Looped Transformers · p. 15

B.2 Low-Rank Adaptation and Relaxed Weight Sharing

  • The paper tests whether loop-specific low-rank corrections let repeated shared transformations specialize, instead of giving every loop separate weights or using routing.Unlike prior work converting pretrained untied models, it trains a dense looped model from initialization and uses small corrections to diagnose the value of depth-specific capacity.Source: Looped Transformers · p. 15, §B.2 · p. 22

Looped Transformers.

  • Conventional loops add sequential work to autoregressive decoding; cross-token parallelization can pipeline loop stages, but naïve PLT can lose looping’s quality gains.The paper attributes the main PLT limitation to shifted state reinjection and identifies preserving the current-token path and separately normalizing it and the shifted state as the repair.Source: Looped Transformers · pp. 15–16

B.1 Looped Transformers

  • Looping repeatedly applies the same parameterized transformation, which may be a block, a group of blocks, or the full stack; different reuse orders and sublayers create distinct designs.The paper distinguishes full-stack from per-layer ordering, attention, MLP, and joint-block looping, as well as middle-layer from middle-stack looping.Source: §B.1 · pp. 17–19
  • Full-stack looping spends extra compute across the network when parameters are scarce, while middle looping concentrates it in a recurrent core when training FLOPs are constrained.Looping increases effective depth without proportionally increasing stored parameters, but every repeated application still incurs compute.Source: §B.1 · pp. 18, 20

B.2 Low-Rank Adaptation and Relaxed Weight Sharing

  • Loop-specific LoRA adds r(din + dout) parameters per loop, placing it between fully shared weights and separate full weights for every loop.Its correction is a learned low-rank update, allowing loops to specialize while most parameters remain shared.Source: §B.2 · p. 22
  • Unlike RRTs (Bae et al., 2025), which adapt a pretrained model during conversion, this study jointly trains shared weights and loop-specific adapters from initialization.The study asks whether specialization helps during looped pretraining and whether its value grows with more weight reuse.Source: §B.2 · p. 22

B.3 Parallel Loop Transformers

  • PLT uses preceding-token states to make loop inputs available together during decoding, enabling concurrent execution without reducing total FLOPs (Wu et al., 2025).The shared Transformer still performs L evaluations, but batches their inputs so parallel hardware can execute them concurrently.Source: §B.3 · pp. 22–24
  • PLT shares the first loop’s global KV cache and gives later loops private recent-context windows, reducing cache memory from O(LND) to O(ND + (L −1)wD).Gated sliding-window attention combines the shared global context with each loop’s private local context.Source: §B.3 · pp. 24–25
  • The study isolates whether PLT’s cross-loop transition affects quality by varying current-token access, normalization, and combination mechanisms separately from cache components.The authors distinguish limitations of the transition itself from those of the transition and cache mechanisms used to implement it.Source: §B.3 · p. 25

C Model Sizes and Training Budgets

The study spans six model scales and training budgets, with model labels and token allocations based on non-embedding parameter counts. Its efficiency analysis finds that, in the evaluated over-trained regime, two-loop models can require fewer tokens and FLOPs than a fitted non-looping baseline to reach the same BPB.

C Model Sizes and Training Budgets

  • The six model scales range from 70M to 1B, and the reported model labels round non-embedding parameter counts to the nearest scale.Total parameter counts include input embeddings, whose contribution is largest for smaller models.Source: C Model Sizes and Training Budgets · p. 26, Table 1 · p. 26
  • Training-token budgets range from 0.777 billion to 154.770 billion tokens, with D = TPP × non-embedding parameter count.TPP values are 10, 20, 40, 80, and 160; loop-reused parameters are counted once, while added loops increase training FLOPs.Source: C Model Sizes and Training Budgets · p. 26
  • The evaluation uses DCLM validation BPB as its primary language-modeling metric and also tests other text, math, code, and multiple-choice datasets.The eight-task headline downstream result is the unweighted mean of NLL-ranked accuracy; MMLU and MMLU-Pro are reported separately as knowledge diagnostics.Source: C Model Sizes and Training Budgets · p. 27

D.1 Relative Data and Compute Efficiency

  • The relative-efficiency analysis compares the tokens or FLOPs needed to reach a given BPB against fitted Vanilla scaling curves.The curves are fitted to non-looping models, separately for training tokens and total training FLOPs.Source: D Details Behind the Headline Figure · p. 28, §D.1 · p. 28
  • Looping models trained at TPP 80 reach a given BPB using fewer FLOPs than non-looping models trained at TPP 160 in the evaluated over-trained regime.Looping models also reach a given BPB using fewer tokens; this benefit weakens as the number of loops increases.Source: Figure 9 · p. 28, §D.1 · p. 28

D.2 Task-Level Results Behind the Headline Comparison

The task-level evaluation compares four 1B model families across eight multiple-choice benchmarks and reports MMLU diagnostics separately. At TPP 160, looping methods outperform Vanilla on six of eight tasks, but MMLU and MMLU-Pro remain near chance; the additional experiments also document the scope and stability of the broader sweeps.

D.2 Task-Level Results Behind the Headline Comparison

  • At TPP 160, all three looping methods outperform Vanilla on six of eight tasks in both NLL-ranked accuracy and choice-normalized target NLL.The six tasks are ARC Challenge, HellaSwag, ARC Easy, PIQA, WinoGrande, and OpenBookQA; CommonsenseQA and Social IQA do not show consistent improvement.Source: Figure 10 · p. 29, §D.2 · p. 29, Figure 11 · p. 30
  • NLL-ranked accuracy selects the answer option with the lowest average token-level NLL, while choice-normalized target NLL captures relative preference even when the top-ranked answer is unchanged.Both metrics assess discrimination among provided answer choices rather than free-form generation.Source: §D.2 · p. 29
  • MMLU accuracy remains near chance, and MMLU-Pro target NLL remains at or above its random-choice reference, with no consistent accuracy advantage across the TPP sweep.These diagnostics do not show that looping improves MMLU-style performance at this scale.Source: §D.2 · p. 30, Figure 12 · p. 31

E Additional Results on Looping Designs and Regimes

  • The additional experiments cover loop factors 1–32 for 70M and 100M models and 1–8 for 200M, 300M, and 500M models, with some configurations unstable.The 1B experiments use a smaller set of loop factors and are described separately.Source: E Additional Results on Looping… · p. 32, §E.1 · p. 32

E.1 Experimental Setup for the Additional Results

  • Full-Stack Looping repeats the full block sequence, while Per-Layer Looping repeats each block individually; middle variants repeat only a contiguous middle region.All designs use exact parameter sharing; middle variants therefore require less training compute at the same loop factor.Source: §E.1 · p. 32
  • The BPB comparisons use teacher-forced evaluation and account for training compute, not communication overhead or realized hardware throughput.Lower BPB indicates better likelihood; unstable runs are marked separately from configurations with missing evaluations.Source: §E.1 · p. 32

E.2 BPB Results on DCLM

Across model scales and training budgets, the preferred looping design depends on both loop factor and available training compute. Middle-Stack Looping often gives larger gains for modest added compute, while Full-Stack Looping can reach lower BPB with more compute; increasing loop count brings diminishing returns and can saturate or reverse.

E.2 BPB Results on DCLM

  • As loop factor increases, BPB reductions typically shrink and may saturate or reverse; the effect is clearest in 70M and 100M sweeps extending to L = 32.The 200M–500M sweeps extend only to L = 8, so they do not directly establish where gains eventually saturate or reverse.Source: §E.2 · pp. 32–33
  • At 70M and 100M, competitive designs vary with TPP; at 200M, Middle-Stack can match or outperform Full-Stack at lower TPP, while Full-Stack strengthens as TPP rises.At 300M and 500M, Full-Stack more consistently reaches the lowest BPB among evaluated designs.Source: §E.2 · p. 32, Figure 13 · p. 33, Figure 14 · p. 34
  • With modest additional training compute, Middle-Stack Looping often improves BPB more per added FLOP, while Full-Stack Looping can reach lower BPB with larger budgets, especially at 300M and 500M.The 70M and 100M results also show diminishing returns as loop factor rises, with BPB reductions eventually saturating or reversing.Source: §E.2 · p. 33, Figure 15 · p. 34, Figure 16 · p. 35

E.3 Do the Looping Trends Hold Across Other Datasets?

This section examines looping trends and loop-specific specialization across additional pretraining corpora, math and code datasets, model sizes, training budgets, looping schedules, and evaluation datasets.

E.3 Do the Looping Trends Hold Across Other Datasets?

  • Across pretraining and math/code datasets, Full-Stack Looping generally becomes more favorable at larger scales and higher TPP, while gains from increasing L tend to diminish.Shallow Middle-Stack Looping remains an attractive option when training FLOPs are constrained.Source: §E.3 · p. 36

E.3.1 C4 English; E.3.2 WikiText-103

  • On C4 and WikiText-103, designs are more competitive at smaller scales and lower TPP; Full-Stack Looping is more favorable at larger scales, while shallow Middle-Stack Looping offers gains with fewer FLOPs.Increasing L also tends to yield diminishing returns.Source: §E.3.1 · p. 37, Figure 18 · p. 38, §E.3.2 · p. 40

E.3.3 Dolma v1.5; E.3.4 RedPajama

  • Dolma v1.5 and RedPajama show the same pattern: Full-Stack Looping is more favorable at larger scales and TPP, while shallow Middle-Stack Looping remains attractive under compute constraints.The benefit of increasing L diminishes at larger loop factors.Source: §E.3.3 · p. 43, Figure 26 · p. 44, §E.3.4 · p. 46

E.3.5 Dolma Programming Languages

  • On Dolma programming-language data, Middle-Stack Looping is often especially competitive at smaller scales and lower TPP, while Full-Stack Looping is more favorable at larger scales, particularly at 500M.Shallow Middle-Stack Looping offers strong quality gains for a smaller FLOP increase, and returns diminish as L grows.Source: §E.3.5 · p. 49, Figure 34 · p. 50, Figure 35 · p. 50

E.3.6 GSM8K

  • On GSM8K, Full-Stack Looping becomes more favorable with scale and TPP, but design rankings are less uniform and increasing L can saturate or reverse BPB gains.The results measure teacher-forced likelihood, not generated-answer accuracy.Source: §E.3.6 · p. 52, Figure 38 · p. 53

E.3.7 MATH

  • On MATH, Full-Stack Looping is more clearly favored than on GSM8K, especially at larger scales and higher TPP, though deeper looping can cease to improve BPB.The results measure teacher-forced likelihood, not mathematical answer accuracy.Source: §E.3.7 · p. 54, Figure 40 · p. 55

E.3.8 HumanEval

  • On HumanEval, the preferred design varies by scale and TPP; Full-Stack Looping becomes more favorable at larger scales, but additional loops can stop reducing or reverse BPB gains.The results measure teacher-forced likelihood on reference code, not whether generated programs pass tests.Source: §E.3.8 · p. 56, Figure 42 · p. 57

E.3.9 MBPP

  • On MBPP, looping designs vary substantially at smaller scales and lower TPP; Full-Stack Looping becomes more favorable as scale and TPP rise, while deeper-loop gains diminish.BPB measures teacher-forced likelihood on code, not execution accuracy or pass@k.Source: §E.3.9 · p. 58, Figure 44 · p. 59

F Additional Results for Loop-Specific Specialization

  • The additional experiments examine how specialization varies with loop count, parameter cost, independently parameterized layers, training compute, looping design, and model scale.The overview covers 70M–300M sweeps, teacher-forced likelihood tasks, comparisons across four looping designs, and targeted 500M and 1B full-stack experiments.Source: F Additional Results for Loop-Specific… · p. 65

F.1 Experimental Setup

  • The main sweep spans 70M–300M models, TPP 10, 40, and 100, loop counts L = 2, 4, and 8, and four looping designs.It compares shared-weight baselines with Loop LoRA, Loop Matrix, and Loop Softmax; unstable runs are excluded when globally averaged training loss exceeds 5, affecting only three 300M per-layer specialization variants at L = 8 and TPP 100.Source: §F.1 · p. 65

Loop-specific specialization.

  • Loop-specific specialization retains shared weights and adds small loop-specific low-rank corrections, rather than assigning each loop a full independent weight matrix.The corrections use rank q = 8 and are applied to attention and SwiGLU MLP projections in every looped block; the variants include Loop LoRA, Loop Matrix, and Loop Softmax.Source: Loop-specific specialization · pp. 65–66

F.2 Results from 70M to 300M

  • Evaluation covers DCLM, C4 English, WikiText-103, Dolma v1.5, RedPajama, Dolma Programming Languages, GSM8K, MATH, HumanEval, and MBPP.The section overview specifies BPB for these results, with lower values better; the supplied passages do not provide comparative result values.Source: F Additional Results for Loop-Specific… · p. 65, §F.2 · p. 66

F.2.1 DCLM

Across DCLM, C4 English, WikiText-103, and Dolma v1.5, loop-specific specialization helps more at higher loop counts, while the preferred resource trade-off depends on whether parameter storage or training compute is constrained.

F.2.1 DCLM

  • Specialization gives clearer BPB gains at L = 4 and L = 8 than at L = 2 across all four corpora, with Loop Matrix often strongest.The precise specialization method matters less than allowing loops to specialize.Source: Figure 57 · p. 67, §F.2.1 · p. 68, Figure 61 · p. 71
  • At similar training FLOPs, doubled-depth Transformers can achieve lower BPB but require substantially more stored parameters across the evaluated corpora.When compute is constrained and storage is acceptable, a deeper Transformer can provide better quality for the same training compute.Source: §F.2.1 · pp. 67–68, Figure 60 · p. 70, §F.2.2 · pp. 71–72

F.2.2 C4 English

  • C4 English reproduces the DCLM pattern: specialization helps more at higher loop counts, while deeper Transformers can offer better quality when training compute is constrained and storage is acceptable.Specialization is most useful when stored parameters are constrained.Source: Figure 61 · p. 71, §F.2.2 · p. 72, Figure 62 · p. 72

F.2.3 WikiText-103

  • WikiText-103 broadly supports the DCLM findings, though loop-count differences are more variable; specialization is clearer at L = 4 and L = 8, and deeper models can favor compute-constrained training.Specialization is most useful when stored parameters are constrained.Source: Figure 65 · p. 75, §F.2.3 · pp. 75–76, Figure 68 · p. 78

F.2.4 Dolma v1.5

  • Dolma v1.5 shows the same main pattern: specialization is more useful at L = 4 and L = 8, while deeper Transformers can be a better use of training compute when more parameters can be stored.Specialization is most useful when stored parameters are constrained.Source: Figure 69 · p. 79, §F.2.4 · p. 80, Figure 72 · p. 82

F.2.5 RedPajama

On RedPajama, loop-specific specialization helps more at larger loop counts and offers a storage-efficient middle ground, but independently parameterized depth can be better when training FLOPs are constrained. The preferred design therefore depends on whether parameter storage or training compute is the tighter constraint.

Loop count

  • Specialization brings a small benefit at L = 2 and a clearer benefit at L = 4 and L = 8, while the precise specialization method matters less than allowing loops to differ.Loop Matrix is most often the strongest choice, and increasing TPP generally lowers BPB for both identical-weight and specialized models.Source: §F.2.5 · pp. 83–84, Figure 73 · p. 83

Stored parameters

  • Loop-specific corrections improve BPB across TPP values while adding relatively few stored parameters.Most weights remain shared, with each loop receiving a small correction.Source: §F.2.5 · p. 83, Figure 74 · p. 84

Loop-specific specialization or additional Transformer layers

  • The doubled-depth Transformer can achieve lower BPB than specialization, but requires substantially more stored parameters.The reference uses twice as many independently parameterized blocks and covers 100M–500M models, rather than the full grid used in other comparisons.Source: §F.2.5 · p. 83, Figure 75 · p. 85

Training FLOPs

  • At similar training FLOPs, the doubled-depth Transformer can often achieve lower BPB, making it a better compute-constrained choice when its additional parameters can be stored.The FLOP comparison includes repeated loop execution and loop-specific corrections.Source: §F.2.5 · pp. 83–84, Figure 76 · p. 86

RedPajama summary

  • Specialization is most useful when stored parameters are constrained, whereas a deeper Transformer can provide better quality at comparable training FLOPs when more parameters can be stored.Across the RedPajama comparisons, the resource-dependent conclusion holds alongside generally lower BPB at higher TPP.Source: §F.2.5 · pp. 83–84, Figure 76 · p. 86

F.2.6 Dolma Programming Languages

This section examines loop-specific specialization in looped transformers across teacher-forced math and code likelihood evaluations and multiple corpora, including Dolma Programming Languages. It also covers how specialization relates to identical-weight looping and independently parameterized depth, alongside diagnostics and design for Parallel Loop Transformers.

F.2.6 Dolma Programming Languages

  • On Dolma Programming Languages, specialization is more often useful at L = 4 or L = 8 than at L = 2, but gains vary and no method wins uniformly.Higher TPP generally lowers BPB; the comparison covers 70M–300M full-stack models at TPP 10, 40, and 100.Source: §F.2.6 · p. 87, Figure 77 · p. 87
  • On Dolma Programming Languages, specialization can improve BPB with few added parameters, while doubled-depth Transformers can be stronger at comparable training FLOPs but require substantially more storage.The doubled-depth references cover 100M–500M models; they use twice as many independently parameterized blocks.Source: §F.2.6 · pp. 87–88, Figure 79 · p. 89, Figure 80 · p. 90

F.3.1 GSM8K

  • On GSM8K, specialization often helps at higher loop counts but is configuration-dependent; doubled-depth Transformers attain lower BPB, including at comparable training FLOPs.These are teacher-forced reference-solution likelihood results, not final-answer accuracy; specialization offers a storage-efficient middle ground.Source: §F.3.1 · p. 91, Figure 81 · p. 92, Figure 83 · p. 94

F.3.2 MATH

  • On MATH, specialization more consistently improves BPB at L = 4 or L = 8 beyond 70M, but doubled-depth Transformers remain stronger at comparable training FLOPs.Higher TPP and larger model size are the most reliable sources of absolute improvement; specialization uses much less storage than doubled depth.Source: §F.3.2 · p. 95, Figure 84 · p. 96, Figure 86 · p. 98

F.3.3 HumanEval

  • On HumanEval, specialization usually improves teacher-forced code BPB, especially at larger loop counts, while doubled-depth Transformers achieve lower BPB at comparable FLOPs.These likelihood results do not measure execution accuracy or pass@k; the preferred specialization method varies by model size and TPP.Source: §F.3.3 · p. 99, Figure 89 · p. 102

F.3.4 MBPP

  • On MBPP, specialization improves BPB in most settings, but doubled depth is usually stronger from 100M–300M and remains mixed at 70M.The results are teacher-forced code likelihood, not execution accuracy or pass@k; specialization uses substantially less storage.Source: §F.3.4 · p. 103, Figure 92 · p. 106

F.4 Where Is Loop-Specific Specialization Useful?

  • Full-Stack Looping achieves the strongest quality and largest specialization gains; middle-stack and Middle-Layer Looping benefit less, while Per-Layer Looping improves inconsistently.The study compares 300M models at TPP 40 across six language-modeling corpora; loop placement matters more than the choice among Loop LoRA, Loop Matrix, and Loop Softmax.Source: §F.4 · pp. 107–108, Figure 93 · p. 107, Figure 94 · p. 107

F.5 Does Specialization Persist at 500M and 1B?

  • At 500M and 1B, specialization still generally improves identical-weight full-stack looping, especially at larger loop counts, though absolute gains shrink.The scale conclusion is limited to six language-modeling corpora; no 500M or 1B results are available for GSM8K, MATH, HumanEval, or MBPP.Source: §F.5 · p. 109, §F.5.1 · p. 109

F.5.1 DCLM

  • On DCLM, loop-specific specialization generally improves Full-Stack Looping at 500M and 1B, with clearest gains at larger loop counts.The reported gains require relatively few additional stored non-embedding parameters and persist after accounting for training FLOPs.Source: §F.5.1 · p. 109, Figure 96 · p. 110, Figure 97 · p. 111

F.5.2 C4 English

  • On C4 English, specialization generally improves larger Full-Stack Looping models, particularly when weights are looped more times.The reported gains require relatively few additional stored non-embedding parameters and persist after accounting for training FLOPs.Source: Figure 99 · p. 112, §F.5.2 · p. 112, Figure 100 · p. 113

F.5.3 WikiText-103

  • On WikiText-103, specialization remains beneficial at 500M and 1B, with the clearest improvements at larger loop counts.The reported gains require relatively few additional stored non-embedding parameters and persist after accounting for training FLOPs.Source: Figure 102 · p. 114, §F.5.3 · p. 114, Figure 103 · p. 115

F.5.4 Dolma v1.5

  • On Dolma v1.5, loop-specific specialization continues to improve larger Full-Stack Looping models, with clearer gains at larger loop counts.The reported gains require relatively few additional stored non-embedding parameters and persist after accounting for training FLOPs.Source: Figure 105 · p. 116, §F.5.4 · p. 116, Figure 106 · p. 117

F.5.5 RedPajama

  • On RedPajama, specialization adds benefit over identical weights in every loop, including at larger model scales.The reported gains require relatively few additional stored non-embedding parameters and persist after accounting for training FLOPs.Source: Figure 108 · p. 118, §F.5.5 · p. 118, Figure 109 · p. 119

F.5.6 Dolma Programming Languages

  • On Dolma Programming Languages, small loop-specific corrections improve larger Full-Stack Looping models, especially at higher loop counts, though gains shrink with model scale.The gains require relatively few additional stored non-embedding parameters and persist after accounting for training FLOPs.Source: Figure 111 · p. 120, §F.5.6 · p. 120, Figure 112 · p. 121

G Additional Results for Parallel Looping

  • The PLT appendix evaluates shifted parallel looping while retaining all L training loops, and reports quality and training FLOPs rather than measured decoding latency or throughput.The selected shifted PLT separately normalizes current-token and shifted recurrent inputs, then combines them with a rank-8 linear gate; the diagnostics examine its shifted transition, normalization, gating, and context.Source: G Additional Results for Parallel… · p. 122

G.1 Which Part of PLT Causes the Quality Loss?

This section investigates the sources of shifted PLT’s quality loss and evaluates its re-injection interface, normalization, gate, and token inputs. It compares shifted PLT with sequential unshifted PLT and ordinary looping, examining quality across model sizes and loop counts while preserving concurrent decoding.

G.1 Which Part of PLT Causes the Quality Loss?

  • Raw Shifted CLP degrades as loops increase and can underperform Vanilla, while unshifted controls track Full-Stack; the comparisons identify the shifted re-injection interface, not cache construction alone, as the main problem.Separately normalizing the current-token embedding and shifted state, then controlling their mixture, substantially lowers BPB and brings shifted models closer to Full-Stack Looping.Source: §G.1 · pp. 123, 125
  • With a separate KV cache per loop, normalized shifted PLT generally matches and sometimes slightly outperforms Full-Stack Looping while enabling concurrent decoding; normalized unshifted looping can do better but remains sequential.The strongest shifted design uses a fixed 50/50 gate; lower DCLM BPB is better.Source: Figure 114 · p. 124, §G.1 · p. 125, Figure 115 · p. 126
  • Normalized shifted models generally improve or remain stable from L = 2 to L = 8, unlike the reported LoopCoder-v2 decline; separate per-loop caches are strongest, while G-SWA can approach Full-Stack at larger loop counts.The separate-cache design uses more memory as L grows; G-SWA combines a shared cache with a private window for later loops. The comparison with LoopCoder-v2 is not direct because model sizes, training data, and evaluations differ.Source: §G.1 · p. 125

G.2 Why Does Normalization Help PLT?

  • Hidden states are substantially larger than token embeddings, and their scale mismatch varies with training budget and loop depth and persists across model sizes and cache designs.These measurements support scale mismatch as an important, but not necessarily sole, contributor to raw-addition failure; normalization is applied immediately before combining the inputs.Source: §G.2 · p. 127

G.3 Does PLT Need a Learned Gate?

  • After separate normalization, learned gates provide only marginal gains over fixed 50/50 mixing; the rank-8 linear gate is generally favorable but not essential.The gate is shared across loops and adds less than 0.015% to non-embedding parameters at scales from 100M to 1B.Source: §G.3 · p. 130, Figure 118 · p. 130, Figure 119 · p. 131

G.4 Why Does Shifted Looping Need the Current-Token Embedding?

  • The next ablation separates the cross-token shift from current-token information by varying whether loops receive the previous- or current-token hidden state and whether they also receive the current-token embedding.When both inputs are present, they are separately normalized and combined with the rank-8 linear gate; the Full-Stack control omits both normalization and gate.Source: §G.3 · p. 131, §G.4 · p. 132
  • Adding the current-token embedding improves both shifted variants; without it, the previous-token variant underperforms Vanilla (No Looping) and several runs diverge.The current-token representation without the embedding closely matches the independent Full-Stack implementation. The authors hypothesize that the embedding identifies the observed token and anchors computation to the current position.Source: §G.4 · pp. 132–133, Figure 120 · p. 133

H.1 How Does PLT Perform Across Evaluation Datasets at 1B?

  • At 1B across six datasets, shifted PLT closely matches unshifted PLT and outperforms Full-Stack Looping, which outperforms Vanilla (No Looping).Shifted PLT retains concurrent decoding, unlike unshifted PLT and Full-Stack Looping.Source: §H.1 · p. 134, Figure 121 · p. 135

H.2 How Does PLT Change with Model Size and Loop Count?

  • Unshifted PLT achieves the lowest BPB; the shifted-versus-unshifted gap is visible at L = 2 in smaller models and persists at L = 4 as models grow.At L = 2, shifted and unshifted PLT become closer with larger models; at L = 4, shifted PLT continues to trail. The paper hypothesizes that repeated cross-token information passing can accumulate errors.Source: §H.2 · p. 134, Figure 122 · p. 136, Figure 123 · p. 137

H.3 How Does PLT Change with Model Scale and Training Budget?

Across model scales and training budgets, unshifted PLT has the lowest BPB, while shifted PLT’s quality relative to unshifted PLT improves with scale at two loops and it usually matches or improves upon Full-Stack Looping.

H.3 How Does PLT Change with Model Scale and Training Budget?

  • Unshifted PLT achieves the lowest BPB across evaluated scales and TPP values; shifted PLT usually matches or improves upon Full-Stack Looping.Shifted PLT retains a parallel decoding schedule.Source: Figure 124 · p. 138, §H.3 · p. 138, Figure 125 · p. 140
  • As model size increases, shifted PLT more closely tracks unshifted PLT across TPP at L = 2, but a clearer gap remains at L = 4.The passages describe the gap as narrowing across training budgets at two loops, not disappearing at four.Source: §H.3 · p. 138, Figure 124 · p. 138, Figure 125 · p. 140
  • Shifted PLT usually matches or improves upon Full-Stack Looping while allowing loops to run concurrently during decoding.The result is consistent with preserving the current-token embedding and separately normalizing it and the shifted hidden representation.Source: §H.3 · pp. 138–139

H.4 Stored Parameters and Training FLOPs

Looping’s quality and efficiency trade-offs depend on whether stored parameters, training FLOPs, or decoding efficiency are constrained. In the specialization experiment, adding Loop Matrix leaves the ordering of the looping designs unchanged.

H.4 Stored Parameters and Training FLOPs

  • Reusing weights can lower BPB with nearly unchanged stored parameters, but each additional loop costs another Transformer evaluation during training.When training FLOPs are constrained and additional parameters can be stored, distinct Transformer layers generally give stronger quality for the compute used.Source: §H.4 · p. 141, Figure 126 · p. 141
  • At some measured operating points, two-loop shifted PLT trained on fewer tokens outperforms Vanilla trained on more tokens at comparable training FLOPs; this does not establish uniform data efficiency.With L = 4, additional loop computation generally moves the model farther from the best measured quality–compute trade-off.Source: §H.4 · pp. 141–142, Figure 127 · p. 142

H.4.1 Training-FLOP Results for Each Model Size

  • Shifted PLT with L = 2 is a strong choice when decoding efficiency matters, while L = 4 generally gives a weaker return per training FLOP.Shifted PLT allows concurrent decoding and often matches or improves upon Full-Stack Looping; the per-model results report the same broad pattern.Source: §H.4.1 · p. 143, Figure 130 · p. 143, Figure 131 · p. 144

I Parallel Looping with Loop-Specific Specialization

  • The specialization comparison uses Loop Matrix, whose loop-specific corrections are added to attention and MLP projections and trained jointly with the model.The same method is labeled Matrix LoRA in the figures.Source: I Parallel Looping with Loop-Specific… · p. 145

I.1 DCLM Results

  • Adding Loop Matrix leaves the design ordering unchanged: unshifted PLT has the lowest BPB, while shifted PLT is generally stronger than Full-Stack Looping and retains parallel decoding.Specialization’s benefit is small or mixed at L = 2 and clearer at L = 4.Source: §I.1 · p. 145

I.2 Results Across Six Language-Modeling Corpora

Across six language-modeling corpora, Loop Matrix specialization generally helps more at four loops, while shifted PLT retains parallel decoding and generally beats ordinary Full-Stack Looping.

I.2 Results Across Six Language-Modeling Corpora

  • Loop Matrix generally improves quality across six corpora, with clearer and more consistent gains at L = 4 than at L = 2.Source: §I.2 · p. 145
  • At L = 2, specialization effects are smaller and less uniform, particularly on the code-heavy Dolma programming-languages split.Source: §I.2 · p. 145
  • Across six corpora, shifted PLT with Loop Matrix generally outperforms ordinary Full-Stack Looping while preserving parallel decoding.This pattern transfers across the evaluated corpora.Source: §I.2 · p. 145
  • Unshifted PLT usually gives the strongest quality, but remains sequential during decoding.The same ordering is reported across the six corpora and in the DCLM comparison.Source: §I.2 · p. 145, Figure 132 · p. 146

J Limitations

The study's conclusions are scoped to dense decoder-only transformers trained from scratch at scales up to 1B parameters, and to the designs and likelihood-based evaluations tested.

J Limitations

  • The evidence covers dense decoder-only transformers trained from scratch only up to 1B parameters; MoE and post-trained models are untested.Source: J Limitations · p. 146
  • The study does not exhaust possible looping designs and focuses mainly on likelihood-based rather than free-form generation evaluation.Source: J Limitations · p. 146
  • Whether normalized shifted PLT's L = 2 behavior persists at substantially larger loop counts and model scales remains unestablished.Source: J Limitations · p. 146
  • Loop Matrix specialization benefits are clearer at L = 4; at L = 2, differences are smaller and less uniform, especially on the code-heavy split.Source: Figure 135 · p. 149
Loading 2610.40325v1…