Find a concept

Search Notes and Discovery

Enter a term to search published Notes and Discovery.

    Field note

    Looped Transformers versus traditional depth

    How repeatedly applying a shared Transformer block differs from stacking separately parameterized layers.

    Transformersarchitecturelooped transformersparameter sharing

    What is worth noticing

    A traditional deep Transformer usually gives each layer its own parameters. A looped Transformer repeatedly applies one shared block—or a small shared group—to an evolving hidden state. The computation can run for several iterations without allocating a completely new parameter set for each step.

    That makes looped depth a form of iterative refinement, not simply a conventional stack drawn with a circular arrow.

    Traditional and looped updates

    With distinct layers, depth step (t) uses its own parameters:

    ht+1=Fθt(ht)h^{t+1}=F_{\theta_t}(h^t)

    With a shared loop, the same parameters are reused:

    ht+1=Fθ(ht,t)h^{t+1}=F_{\theta}(h^t, t)

    The optional step signal (t) matters: without some representation of iteration or state, a shared block may have difficulty knowing whether it is starting, refining, or finishing. Specific papers implement the recurrence differently, so “looped Transformer” describes a family of designs rather than one universal layer.

    PropertyUntied stackLooped/shared block
    Parameters across depthUsually different per layerReused across iterations
    ComputeSet by layer countSet by loop count or stopping rule
    Model sizeGrows with separately parameterized depthCan stay smaller as iterations increase
    Main riskParameter costOptimization and repeated-state dynamics

    Why researchers study loops

    Parameter sharing asks a useful question: can a model spend more computation refining a representation without increasing parameter count at the same rate? Universal Transformers introduced recurrence over depth with a dynamic halting mechanism. Later looped-Transformer work studied repeated blocks as a way to learn iterative algorithms.

    This is conceptually attractive for tasks whose solution resembles repeated application of a rule. However, success on algorithm-learning experiments does not establish that every language task or production model benefits.

    What changes in practice

    The hidden state must remain usable across repeated applications. Training sends gradients through every unrolled iteration, so memory and stability still matter. Reusing parameters reduces parameter storage, but it does not make repeated computation free. Ten applications of one block still perform ten rounds of its attention and feed-forward operations.

    If the loop count varies, batching and latency become more complicated. If the count is fixed, deployment is simpler but the model loses adaptive compute. Systems also need to decide whether normalization statistics, positional signals, or routing decisions depend on the iteration.

    What remains uncertain

    The cited research provides evidence for particular architectures and evaluation settings. It does not prove a blanket replacement for ordinary Transformers. Comparisons should control total compute, data, optimizer settings, model width, and inference constraints. A looped design may be more parameter-efficient while still being slower at a chosen latency target.

    Connection to the Notes

    The encoder-decoder architecture Note describes the ordinary block structure. A looped design changes how those blocks are parameterized and revisited; it does not remove attention, residual paths, or positional information by definition.

    Sources

    1. Universal Transformers
    2. Looped Transformers are Better at Learning Learning Algorithms