LoopCoder-v2: Nur einmal loopen für effiziente Testzeit-Berechnungsskalierung

Zusammenfassung

Geschleifte Transformatoren skalieren latente Berechnung durch wiederholte Anwendung gemeinsamer Blöcke, aber sequentielles Schleifen erhöht die Latenz und den KV-Cache-Speicher mit der Anzahl der Schleifen. Parallel-Schleifen-Transformatoren (PLT) mildern diese Kosten durch schleifenübergreifende Positionsversätze (CLP) und eine gemeinsame KV-gesteuerte gleitende Fensteraufmerksamkeit, wodurch die Schleifenanzahl zu einer praktischen Designentscheidung wird. Daher untersuchen wir die Auswahl der PLT-Schleifenanzahl aus einer Nutzen-Kosten-Perspektive: Eine zusätzliche Schleife kann Darstellungen verfeinern, aber CLP führt auch an jeder Schleifengrenze zu einer Positionsinkonsistenz. Wir setzen diese Untersuchung um, indem wir LoopCoder-v2, eine Familie von 7B-PLT-Codierern mit unterschiedlichen Schleifenanzahlen, von Grund auf auf 18 Billionen Tokens trainieren, gefolgt von abgestimmter Instruktionsoptimierung und Evaluierung. Empirisch erzielt die Variante mit zwei Schleifen breite Verbesserungen gegenüber der nicht-geschleiften Baseline bei Codegenerierung, Codeverständnis, agentischer Softwareentwicklung und Tool-Nutzungs-Benchmarks, wobei SWE-bench Verified von 43,0 auf 64,4 Punkte und Multi-SWE von 14,0 auf 31,0 Punkte steigt. Im Gegensatz dazu fallen Varianten mit drei oder mehr Schleifen zurück, was einen stark nicht-monotonen Schleifenanzahl-Effekt offenbart. Unsere Diagnosen zeigen, dass Schleife 2 die wesentliche produktive Verfeinerung liefert, während spätere Schleifen abnehmende, oszillierende Aktualisierungen und reduzierte Darstellungsvielfalt erzeugen. Da die durch CLP verursachte Positionsinkonsistenz nahezu konstant bleibt, während die Verfeinerungsgewinne schrumpfen, dominieren zunehmend die Versatzkosten. Dieser Nutzen-Kosten-Ausgleich erklärt die Sättigung von PLT bei zwei Schleifen und liefert Diagnosen für die Auswahl der Schleifenanzahl.

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.