LoopCoder-v2: Slechts één keer lussen voor efficiënte schaling van testtijdberekeningen

Samenvatting

Looped Transformers schalen latente berekening door herhaaldelijk gedeelde blokken toe te passen, maar sequentieel lussen verhoogt de latentie en het KV-cache geheugen met het aantal lussen. Parallel loop Transformers (PLT) verlichten deze kosten door cross-loop positie-offsets (CLP) en gedeelde-KV gated sliding-window aandacht, waardoor het aantal lussen een praktische ontwerpkeuze wordt. We bestuderen daarom de selectie van het aantal lussen in PLT vanuit een winst-kosten perspectief: een extra lus kan representaties verfijnen, maar CLP introduceert ook een positie-mismatch bij elke lusgrens. We concretiseren deze studie door LoopCoder-v2 te trainen, een familie van 7B PLT-codeermodellen met verschillende aantallen lussen, vanaf nul op 18T tokens, gevolgd door bijpassende instructie-afstemming en evaluatie. Empirisch gezien levert de variant met twee lussen brede winst op ten opzichte van de basislijn zonder lussen op het gebied van codegeneratie, coderedenering, agentische software-engineering en tool-gebruik benchmarks, waarbij SWE-bench Verified verbetert van 43,0 naar 64,4 punten en Multi-SWE van 14,0 naar 31,0 punten. Daarentegen vertonen varianten met drie of meer lussen regressie, wat een sterk niet-monotoon effect van het aantal lussen onthult. Onze diagnostiek toont aan dat lus 2 de belangrijkste productieve verfijning levert, terwijl latere lussen afnemende, oscillerende updates en verminderde representatiediversiteit opleveren. Omdat de door CLP veroorzaakte mismatch ruwweg vast blijft terwijl de verfijningswinst afneemt, domineren de offsetkosten steeds meer. Deze winst-kosten afweging verklaart de verzadiging van PLT bij twee lussen en biedt diagnostiek voor de selectie van het aantal lussen.

English

Looped Transformers scale latent computation by repeatedly applying shared blocks, but sequential looping increases latency and KV-cache memory with the loop count. Parallel loop Transformers (PLT) alleviate this cost through cross-loop position offsets (CLP) and shared-KV gated sliding-window attention, making loop count a practical design choice. We therefore study PLT loop-count selection through a gain--cost view: an extra loop may refine representations, but CLP also introduces a positional mismatch at each loop boundary. We instantiate this study by training LoopCoder-v2, a family of 7B PLT coders with different loop counts, from scratch on 18T tokens, followed by matched instruction tuning and evaluation. Empirically, the two-loop variant delivers broad gains over the non-looped baseline across code generation, code reasoning, agentic software engineering, and tool-use benchmarks, improving SWE-bench Verified from 43.0 to 64.4 points and Multi-SWE from 14.0 to 31.0 points. In contrast, variants with three or more loops regress, revealing a strongly non-monotonic loop-count effect. Our diagnostics show that loop 2 provides the main productive refinement, while later loops yield diminishing, oscillatory updates and reduced representational diversity. Because the CLP-induced mismatch remains roughly fixed as refinement gains shrink, the offset cost increasingly dominates. This gain--cost trade-off explains PLT's saturation at two loops and provides diagnostics for loop-count selection.