10 Looped Transformer Papers: The potential of Reusing Layers

TL;DR: Use Ollama or llama.cpp for local and edge deployment, vLLM or SGLang for high-throughput GPU inference, BentoML for model APIs, and Kubeflow or Seldon Core when Kubernetes is already the operating layer. TGI and TorchServe should be treated as legacy choices for existing installations.

The main difference is what happens to the hidden representation as it moves through the model. In a standard Transformer, information passes through a sequence of layers, each typically with its own parameters. In a looped Transformer, some layers are reused to make the representation repeatedly updated by the same computation.

However, one very important thing to understand is that looping doesn't mean free computation. Reusing weights can save parameter memory, but each additional pass still costs time and compute. And the core idea is to make those extra passes genuinely useful and efficient. So let’s see how it is done today →

It is a Transformer architecture proposed by Princeton and the University of Pennsylvania that carries forward a running state, updating it after each token. It splits the work between two parts: 1) a causal encoder that processes known prompt tokens in parallel and builds a shared input memory, and 2) a recurrent decoder combines each token’s information with its previous state.

Main idea: RLT lets computation build on itself. Longer sequences create longer chains of computation without adding more layers per token.

Best for: tasks like tracking changing states or working through arithmetic, where each step depends on what happened before.

The paper from Cornell University and IBM Research introduces two models: the Looped Prediction Transformer (LPT), which uses full attention, and a hybrid version that combines full attention with gated DeltaNet layers. Both let later passes reuse the attention memory built during the first pass. The researchers found that shared and local memory develop different representations, later passes rely heavily on shared memory, and sharing gives training gradients a more direct route back to the first pass.

Main idea: Reusing memory lets Looped Transformers do more computation without keeping a separate full context cache for every pass and improve prediction quality.

Best for: language modeling where memory is limited, but extra computation per token is affordable.

Maybe it is one of the post notable paper now, because it was accepted at NeurIPS 2026. Stanford, UIUC, NVIDIA, and MIT’s researchers extends the idea behind looped Transformers to multi-agent collaboration. Their RecursiveMAS loops through a team of LLM agents, passing hidden states between them to refine the result.

Lightweight RecursiveLink modules connect hidden representations within and between agents. Only the links are trained, while the base models stay frozen. The final agent generates the answer after the last round, saving intermediate text generation.

Main idea: Take the looping principle beyond a Looped Transformer to use it in multi-agent systems to Improve how agents solve problems together through repeated exchanges of hidden states.

Best for: Multi-agent reasoning where repeated collaboration is useful, but text-based exchanges add too much latency and token overhead.

It is a family of image-generation models that repeatedly applies a shared Diffusion Transformer core. LiFT gives each loop an intermediate target along a straight path from its initial estimate to the flow-matching target. These targets use a continuous depth coordinate, letting the model run more loops than it saw during training without retraining. More loops refine the prediction within each generation step, separately from the steps that turn noise into an image.

Main idea: “Loop in depth, flow in time” – generate better images by running the same Transformer core more times, even beyond its training loop count, while flow matching moves the image from noise to a finished sample.

Best for: image generation where parameter efficiency matters and you want to adjust computation at inference time to improve quality.

This version of Looped Transformer from SenseTime, Tsinghua University, and NTU reuses Transformer blocks within each denoising step to refine image generation without adding layers. It trains intermediate loops with a flow-matching loss and uses self-modulating attention to keep repeated updates from washing out local details.

Main idea: Give each denoising step more internal processing, while teaching the loops to make useful updates without erasing image details - all to improve image quality and prompt alignment.

Best for: text-to-image generation where you want more refinement per denoising step without increasing model size.

It is a Looped Transformer for audio classification. After one full spectrogram pass, it freezes the audio features and reuses the same blocks to update only the class token, attending to cached keys and values.

Main idea: Add depth where it matters, integrating sound features into a decision, while keeping extra computation low.

Best for: clip-level audio classification where you want deeper processing without repeatedly updating every audio token.

The paper from Apple introduces LoopCD, a training-free way to improve decoding in looped Transformers. These models refine a token’s representation over several passes, but standard decoding uses only the final state. LoopCD puts an earlier pass to work as a weaker reference, highlighting what changed with more computation.

It comes in two versions. LoopCD-Logits contrasts the earlier and final token scores, requiring one extra pass through the output layers. LoopCD-Hidden applies the same idea directly to hidden states before the output layers, avoiding that extra pass.

Main idea: Use earlier loops to guide the final prediction, getting more value from computation the model already performs.

Best for: cases when you need to reduce the number of loops, or to improve generation quality in existing looped Transformers without retraining.

Developed at MIT, Hyperloop splits a Transformer into beginning, middle, and end blocks, then loops only the middle block. It carries multiple parallel residual streams, using hyper-connections to combine them into each loop’s input and distribute its output back across the streams. These connections operate between loops, adding little parameter or compute overhead.

Main idea: Add hyper-connections to a looped Transformer so shared layers can work with richer information across loops, with little extra parameter or compute cost.

Best for: Language models that need to fit within tight memory budgets, especially on-device deployment.

It is a looped Transformer design that treats each pass as an optimization step on its hidden state. The shared blocks predict an update direction, a delta objective defines the correction, an adaptive step size controls its strength, and state decay regulates how much previous information carries forward.

Main idea: Make looping more systematic and “thoughtful” – learn what to change, how much to change, and what to retain, rather than simply running the same blocks again.

Best for: building compact language models that spend extra computation revising their internal state, with control over what each loop keeps, changes, or forgets.

Peking University and Houmo AI researchers explored the field of post-training quantization for looped Transformers. Since layers’ activations change from one pass to the next, quantization errors can carry forward through the loops. LoopQuant method handles this in three steps: 1) it learns shared scaling and rotations to make activations easier to quantize; 2) then it assigns 4-bit or 8-bit activation precision based on loop sensitivity and error interactions; and 3) finally it tunes clipping, scaling, and bias along the quantized computation path, keeping model weights frozen.

Main idea: Quantize weights and activations with the whole looped computation in mind. Shared layers encounter different states on each pass, so precision and calibration need to account for how errors build up across loops.

Best for: deploying pretrained looped language models with lower memory use and faster inference

A looped Transformer can get the answer right and still need more time to make its internal state useful. Researchers from CAS, UCAS, and HKUST (Guangzhou) show this on state-tracking tasks. Models that answer correctly at 32 loops keep only 22% of those answers at loop 64. Supervising a randomly chosen sequence position raises retention to 99.8%.

However, freezing hidden states when their answers first become correct crashes accuracy to 4–6%. Waiting four more loops avoids the collapse.

Main idea: Computing an answer, keeping it correct, and making its hidden state usable by later computation are separate skills for looped Transformers. A correct answer can appear before the internal state is ready to be reused.

Useful for: understanding overthinking in looped transformers and designing training or stopping rules that look beyond whether an answer is already correct

The profiles above explain how each project works. This table is the short version: where each tool fits and whether it is still a sensible choice for a new deployment.

The original model-serving world was mostly about taking a trained model and exposing it through a production endpoint. That is still important, but foundation models changed the deployment problem.

Modern teams now need to think about:

That is why vLLM, Ollama, and TGI are in this list. They reflect where foundation model deployment has moved: away from generic model serving alone and toward LLM-specific inference, local model running, and high-throughput production serving. For a deeper look at how to approach these trade-offs — model selection, infrastructure, and monitoring — see our guide to LLM deployment best practices.

For a local pilot, start with Ollama or llama.cpp. For a shared GPU server, vLLM or SGLang usually gives you better throughput and API compatibility. The model size, precision, context length, and number of simultaneous users determine the hardware you need.

As a practical starting point:

These are planning ranges, not guarantees. Long contexts, larger batches, and the KV cache add memory pressure. Mixture-of-experts models still require storage and memory for all loaded weights, not only the parameters active for each token. CPU offload and unified memory can make larger models run, but usually reduce throughput.

If you're just getting started with ML and AI, check out our curated list of Top 10 GitHub repos for AI & ML practitioners— collections of courses, guides, and projects to build your foundations.

Foundation model deployment is the process of running, serving, scaling, and managing large AI models in real applications. It can include local model execution, cloud inference, API packaging, Kubernetes deployment, monitoring, and lifecycle management.

Ollama is usually the simplest choice for local LLM deployment. It is built for running models on a laptop, workstation, or private server without setting up a large production serving system.

vLLM is one of the strongest open-source choices for high-throughput LLM serving, especially for open-weight models running on GPUs. It focuses on serving efficiency, batching, memory management, and inference throughput.

vLLM is an actively developed server for high-throughput open-weight LLM inference. TGI served a similar role inside the Hugging Face ecosystem, but its repository was archived in March 2026 and is now maintained only for minor fixes. New deployments should normally choose vLLM or SGLang.

A 7–8B model quantized to 4-bit can often run within 8–12 GB of VRAM, while a 70B 4-bit model usually needs roughly 48–80 GB. Production capacity also depends on context length, concurrent requests, KV cache, and runtime overhead, so the model file size alone is not enough for hardware planning.

Thank you for reading! [Sign-off — e.g. “Share this list with a friend who is still deploying models by hand.”]