Summary of "Depth-Adaptive Inference of Looped Language Models via Continuous Depth Batching"
Summary (Overview)
- First end-to-end implementation of Continuous Depth Batching (CDB) for looped language models, enabling efficient depth-adaptive inference where tokens exit the recurrent core at different depths.
- CDB achieves up to 99% of the estimated maximum speedup on fully looped architectures (Ouro 1.4B) and 83–96% on models with costly boundary stages (Huginn 3.5B), compared to standard continuous batching at full depth.
- Key technical contributions: stage-wise scheduling with refill/no-refill modes, depth-aware KV cache designs, and asynchronous lookahead scheduling that reduces GPU idle time to nearly zero.
- Architectural insights: fully looped models (minimal non-looped layers) are best suited for depth-adaptive inference; boundary-stage cost, KV cache design, and loop count are the primary determinants of inference efficiency.
- Theoretical framework: FLOP-based speedup bounds and hardware-aware latency models that predict when refill is beneficial (memory-bound vs. compute-bound regimes).
Introduction and Theoretical Foundation
Background and Motivation
Looped language models repeatedly apply a block of shared layers (the recurrent core) to refine latent representations before predicting a token. This architecture offers two key advantages:
- Parameter efficiency: Sharing layers reduces parameter memory relative to an equally deep standard transformer.
- Depth-adaptive decoding: Tokens can exit the recurrent core after different numbers of loops, spending less compute on "easy" tokens and more on "hard" ones.
However, the compute savings from depth-adaptive decoding do not automatically translate into faster inference. The central challenge: tokens with different loop counts cannot share a uniform forward pass and therefore cannot be handled by standard batching systems like vLLM.
Architecture Definition
The looped-LM architecture is split into three stages:
- Prelude : processes each token before entering the loop (runs once)
- Recurrent core : shared layers applied times per token
- Coda : predicts the next token after exit (runs once)
The architecture is denoted as prelude-core-coda layer counts. For example, a 2-4-2 model executes layers, giving effective depth 20 at loops. A fully looped 0-4-0 model has only embedding and LM head outside the core.
Three Main Challenges for CDB
- Stage heterogeneity: CDB must schedule prefill, prelude, recurrent core, and coda separately, each at different batch sizes and frequencies.
- Missing KV states: When a token exits at depth , it writes no KV states for deeper loop steps, leaving later tokens without states to attend to.
- Critical-path exits: Exit decisions are available only after a loop step finishes, but determine which tokens enter the next step, potentially leaving the GPU idle.
Methodology
Stage-Wise Scheduling
The scheduler maintains four queues corresponding to inference stages: inactive requests (prefill), decode tokens (prelude), recurrent items (loop steps), and exited tokens (coda). Two execution modes are implemented:
No-refill mode: Fixed order (prelude → recurrent steps → coda). Exited tokens are removed, reducing batch size on subsequent loop steps.
Refill mode: Dynamic ordering where freed slots are filled by new tokens. Priority rules:
- Prelude runs directly after prefill or coda (no routing decision needed)
- Coda has highest priority (predicts next tokens for refill)
- Prefill comes next (admitting prompts early enables larger decode batches)
- Recurrent core runs otherwise
A minimum coda batch size K controls the trade-off: larger K makes coda/prelude batches more efficient but delays refill and temporarily reduces recurrent batch size.
Depth-Aware KV Cache
Two designs for handling missing KV states from early exits:
- Last-exited cache: Copies a token's final KV state into skipped slots upon exit. Preserves accuracy, avoids recomputation, but retains slots per token and adds copying overhead.
- Shared cache: Gives each recurrent layer a single KV slot per token (reduces memory by factor ). Each loop step overwrites the slot; later tokens attend to the most recent state. May require specialized training.
Asynchronous Scheduling with Lookahead Gate
To avoid GPU idle time between stages, batches are prepared and transferred asynchronously while the GPU processes the current batch. The lookahead gate solves the critical-path problem: the exit signal at step determines whether a token participates in step instead of , giving the CPU a full loop step to prepare the next batch. This constrains minimum exit depth to but does not reduce accuracy (verified empirically).
Empirical Validation / Results
Efficiency Limits: Theoretical Bounds
The FLOP-based upper bound on decode speedup is:
where = FLOPs of one recurrent-core application, = boundary-stage FLOPs, and = mean exit depth.
Accounting for prefill (fraction of time):
The recurrent step latency model:
where = fixed weight-reload cost, = core computation cost, and = KV cache streaming cost.
Offline Throughput Results
| Model | Mode | Throughput vs. CB | % of realized |
|---|---|---|---|
| Ouro 1.4B | Refill | 1.32–1.53× | 96–99% |
| Huginn 3.5B | No-refill | 1.30–1.37× | 83–96% |
Key findings:
- Refill is most effective in the memory-bound regime (around/below saturation batch size ), where shrinking batches saves little time.
- At full depth, CDB retains 95–99% of CB throughput, showing minimal scheduling overhead.
- Prefill accounts for 3.7–36% of GPU time, reducing end-to-end speedup below decode-only estimates.
Online Serving
CDB sustains higher request rates before latency rises sharply, translating offline throughput gains into greater serving capacity. For Ouro, refill provides the largest capacity gain; for Huginn, refill and no-refill perform similarly.
Ablations: Minimum Coda Batch Size K
- Huginn: best balances coda efficiency vs. refill delay.
- Ouro: (immediate coda execution) performs best due to cheap boundary stages.
- Removing transformer layers from Huginn's boundary stages (making it fully looped) makes near-optimal, confirming boundary-stage cost is a central efficiency constraint.
Theoretical and Practical Implications
When Does Depth-Adaptive Inference Help?
Three conditions must hold for meaningful speedup:
- Sufficient early exits at acceptable accuracy (model must be trained appropriately)
- Recurrent computation must dominate total inference time (expensive prefill limits gains)
- The inference system must convert skipped FLOPs into wall-clock savings (requires refill in memory-bound regimes and asynchronous scheduling)
Architecture Co-Design Guidance
- Keep boundary stages small: Costly non-looped layers (prelude/coda) reduce refill opportunities and complicate scheduling. Fully looped architectures (0-4-0) are best suited for depth-adaptive inference.
- Consider loop count trade-offs: More loops offer finer-grained exit control but each skipped loop saves a smaller fraction of total recurrent compute.
- KV cache design matters: Shared caches reduce memory footprint and implementation complexity but may require specialized training.
Design of Exit Gates
The lookahead gate constrains minimum exit depth to . For models that produce useful outputs after a single loop, a promising alternative is to predict only the first loop-exit before the recurrent core, then use lookahead decisions for later loops.
Conclusion
The paper introduces the first efficient inference method for depth-adaptive looped LMs, demonstrating that:
- CDB realizes most of the available speedup from early exits (up to 99%), making depth-adaptive decoding practically viable.
- Fully looped architectures with minimal boundary stages are best suited for this paradigm.
- Co-designing looped architectures and serving systems can lead to substantially faster inference.
Future directions:
- Models that allow more frequent exits at high accuracy
- Reliable prediction of complete exit depth before entering the recurrent core
- Understanding when shared KV caches work without specialized training
- Extension to production features: multi-GPU execution, preemption, prefix caching, speculative decoding
Limitations: Evaluation covers only two looped architectures on a single H100 GPU, without production serving features like multi-GPU execution or speculative decoding.
Related papers
- Towards Looped Models Done Right, Part I: Topology, Input Injection, Recurrent-State Design
Controlled ablations isolate the sandwich envelope as the primary driver of looped language model gains, with input injection helping context tasks but hurting math.
- Where to Spend Test-Time Compute in Recursive Reasoning
Gated Answer Resampling, a tuning-free test-time method that resamples only the decoded answer state, boosts TRM accuracy from 85.9% to 99.4% on Sudoku and 68.8% to 85.6% on PPBench at minimal compute cost.
- Auditing the Product, Not the Recursion: The Evaluation Evidence Behind Recursive Self-Improvement Claims
Only 22% of recursive self-improvement studies audit repeated runs, and just 15% of improver-gain claims use identifying same-start comparisons, revealing a systematic product-versus-process evaluation gap.