LoopCoder-v2 : Une seule boucle pour un passage à l'échelle efficace des calculs en phase de test

Résumé

Les Transformers en boucle étendent le calcul latent en appliquant de manière répétée des blocs partagés, mais l'itération séquentielle augmente la latence et la mémoire du cache KV proportionnellement au nombre de boucles. Les Transformers en boucle parallèle (PLT) atténuent ce coût grâce à des décalages de position inter-boucles (CLP) et à une attention à fenêtre glissante avec KV partagé et portail, faisant du nombre de boucles un choix pratique de conception. Nous étudions donc la sélection du nombre de boucles des PLT sous un angle coût-bénéfice : une boucle supplémentaire peut affiner les représentations, mais le CLP introduit également un décalage positionnel à chaque frontière de boucle. Nous concrétisons cette étude en entraînant LoopCoder-v2, une famille de codeurs PLT de 7B avec différents nombres de boucles, à partir de zéro sur 18T tokens, suivis d'un ajustement instructionnel et d'une évaluation appariés. Empiriquement, la variante à deux boucles offre des gains étendus par rapport à la référence sans boucle sur des bancs de génération de code, de raisonnement sur le code, de génie logiciel agentique et d'utilisation d'outils, améliorant SWE-bench Verified de 43,0 à 64,4 points et Multi-SWE de 14,0 à 31,0 points. En revanche, les variantes avec trois boucles ou plus régressent, révélant un effet fortement non monotone du nombre de boucles. Nos diagnostics montrent que la deuxième boucle fournit le principal raffinement productif, tandis que les boucles ultérieures produisent des mises à jour décroissantes et oscillatoires ainsi qu'une diversité représentationnelle réduite. Comme le décalage induit par le CLP reste à peu près fixe alors que les gains de raffinement diminuent, le coût du décalage devient de plus en plus dominant. Ce compromis coût-bénéfice explique la saturation du PLT à deux boucles et fournit des diagnostics pour la sélection du nombre de boucles.

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.