Weight Teleportation acelerado por GPU reduz pausas na sincronização de pesos em treinamento de RL

O problema de partida é específico de RL em larga escala: os pesos do trainer e dos samplers precisam ficar o mais próximos possível, o que obriga a enviar atualizações a cada passo. Mover terabytes de pesos exige rede intra-cluster rápida ou aceitar atrasos, além de bloquear os samplers. A Humans& (blog humansand.ai) propõe um paradigma de atualização que, na maioria dos casos, supera até a velocidade intra-cluster, estejam trainers e samplers no mesmo cluster ou não.

A base é o delta weight sync. O trainer faz um XOR bit a bit entre weights_old e weights_new e gera uma máscara com o mesmo formato dos pesos. Como o sinal de RL é esparso, a máscara é quase toda de zeros e comprime bem sem perdas. No proxy do texto (GLM-5.3 em NVFP4, 445 GB, com 0,085% do checkpoint alterado, trainer com 64 GPUs B300), o payload com Zstd em CPU fica em 0,876 GB. Só que a versão ingênua, com checkpoint em disco como ponto de troca, perde esse ganho em compressão no trainer, ida e volta ao disco e recarga completa do checkpoint.

O baseline forte usa LZ4 com o Decompression Engine (DE) da Blackwell, um bloco de função fixa. A compressão é distribuída pelas GPUs do treino, e um único kernel Triton aplica o XOR in place na HBM. Resultado: 0,834 s de preparação e compressão no trainer e 6,041 s no receptor. Os defeitos eram o payload de 5,36 GB (6,1x o do Zstd em CPU) e a necessidade de expulsar o KV cache para caber as máscaras descomprimidas.

A saída foi a dupla compressão: uma camada Zstd sobre codecs amigáveis à GPU como Snappy e LZ4. A descompressão Zstd roda na CPU, sem tirar o decoding do rollout, e o payload Snappy fica em RAM pinned para o DE consumir direto. Um pipeline com buffer duplo sobrepõe DE e SMs, camada por camada, e leva a pausa do sampler abaixo de 0,23 s e o sync de ponta a ponta abaixo de 4 s na configuração de produção Ampersand. Segundo a fonte, o gargalo passa a ser o próprio ASIC de descompressão. É resultado do ambiente descrito (Blackwell, NVFP4), não uma garantia para outros setups.

O delta weight sync já tinha aparecido na cobertura. Em 28 de maio de 2026, o CEVIU noticiou "Distribuindo Trilhões de Parâmetros com um Hub Bucket: Sincronização Delta de Pesos no TRL", sobre transmitir só os parâmetros alterados entre passos de RL assíncrona para reduzir o payload. A notícia de agora parte da mesma ideia, mas move o foco do tamanho do payload para o custo de comprimir, descomprimir e aplicar o delta, com hardware dedicado de descompressão e pausa de sampler medida em frações de segundo.

Para quem opera RL em escala, a leitura é que reduzir bytes na rede deixou de bastar. O tempo de pausa dos samplers e a pressão sobre HBM e KV cache passam a ditar o custo real. Se os números se repetirem fora do ambiente da Humans&, sincronizar entre clusters distintos deixa de ser penalidade tão grande. Convém lembrar que a técnica depende de Blackwell e do DE.