How to Loop Your Transformer: Loop Scaling, Specialization, and Parallel Inference
Organizations: FAIR at Meta · MIT
Abstract
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 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.
Figures & tables
Appendix figures & tables128 assets
Supplementary material from the paper’s appendix.
Appendix
| Architecture | Parameter count (M) | |||||
| Model label | Transformer layers | Model width | MLP width | Attention heads (Q/KV) | Excluding input embedding | Including input embedding |
| 70M | 4 | 512 | 1,536 | 4/1 | 77.726 | 143.397 |
| 100M | 6 | 768 | 2,048 | 6/1 | 135.070 | 233.580 |
| 200M | 8 | 1,024 | 2,816 | 8/1 | 219.415 | 350.766 |
| 300M | 10 | 1,280 | 3,584 | 10/1 | 337.838 | 502.033 |
| 500M | 12 | 1,536 | 4,096 | 12/2 | 489.554 | 686.594 |
Recurrent Transformers
Recurrent Transformers reuse layers or state across steps to extend context, reasoning depth, and sequence modeling with less parameter growth.
See all 183 papers