LoopCoder-v2: Apenas um Loop para Escala Eficiente de Computação em Tempo de Teste

Resumo

Transformadores em loop escalam a computação latente ao aplicar repetidamente blocos compartilhados, mas o encadeamento sequencial aumenta a latência e a memória do cache-KV com o número de loops. Os Transformadores em Loop Paralelo (PLT) reduzem esse custo por meio de deslocamentos de posição entre loops (CLP) e atenção de janela deslizante com portão e KV compartilhado, tornando a contagem de loops uma escolha prática de projeto. Portanto, estudamos a seleção da contagem de loops em PLT através de uma visão de ganho-custo: um loop extra pode refinar representações, mas o CLP também introduz uma incompatibilidade posicional em cada fronteira de loop. Operacionalizamos este estudo treinando LoopCoder-v2, uma família de codificadores PLT de 7B com diferentes contagens de loops, desde o início em 18T tokens, seguido por ajuste de instruções e avaliação pareados. Empiricamente, a variante com dois loops apresenta ganhos amplos sobre a linha de base sem loops em benchmarks de geração de código, raciocínio de código, engenharia de software agentiva e uso de ferramentas, melhorando o SWE-bench Verified de 43,0 para 64,4 pontos e o Multi-SWE de 14,0 para 31,0 pontos. Em contraste, variantes com três ou mais loops regridem, revelando um efeito fortemente não monotônico da contagem de loops. Nossas análises diagnósticas mostram que o loop 2 fornece o principal refinamento produtivo, enquanto loops posteriores produzem atualizações decrescentes e oscilatórias, além de menor diversidade representacional. Como a incompatibilidade induzida pelo CLP permanece aproximadamente fixa enquanto os ganhos de refinamento diminuem, o custo do deslocamento torna-se cada vez mais dominante. Esse trade-off ganho-custo explica a saturação do PLT em dois loops e fornece diagnósticos para a seleção da contagem de loops.

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.