O sistema Tunix do Google elimina o gargalo que impedia o aprendizado por reforço (RL) agêntico em larga escala de utilizar TPUs de forma eficiente. Ao separar o trabalho de geração de dados de interação do trabalho de atualização da política, o Tunix eleva a utilização da TPU de percentuais de um dígito para quase a capacidade total, reduzindo drasticamente o desperdício de computação.

O gargalo no RL agêntico

O RL agêntico difere do mais familiar treinamento de modelos de linguagem de "próximo token". Um agente deve enviar chamadas de API, executar código ou percorrer um ambiente simulado e, em seguida, reagir ao resultado. O loop de treinamento é, portanto, síncrono: o modelo produz uma ação, o ambiente é executado, o resultado retorna e só então o modelo recebe uma atualização de gradiente. Quando uma única etapa do ambiente leva vários segundos, o caro hardware TPU fica ocioso, e a utilização relatada pode cair abaixo de 10%. Essa ineficiência se traduz diretamente em contas de nuvem mais altas e ciclos de pesquisa mais lentos.

A arquitetura desacoplada do Tunix

O Tunix aborda o problema movendo os dois estágios — geração de trajetórias e otimização de política — para pools de hardware separados.

  • Atores assíncronos rodam em CPUs ou GPUs de baixo custo. Cada ator interage continuamente com seu ambiente atribuído, registra ações e observações e transmite as trajetórias resultantes para um armazenamento compartilhado.
  • Learners contínuos ocupam Pods de TPU dedicados. O learner busca lotes (batches) do buffer central e realiza atualizações de gradiente sem esperar que qualquer ator individual termine um rollout.
  • Buffer de alta vazão fica no meio, atuando como uma área de staging para trajetórias. Como o learner pode ler tão rápido quanto o buffer pode fornecer dados, a TPU nunca para.

O efeito líquido é um pipeline de treinamento onde as TPUs permanecem ocupadas quase o tempo todo, elevando a utilização para perto de 100%.

Obstáculos técnicos e como o Tunix os supera

Episódios de comprimento variável e recompilação XLA

O compilador XLA do JAX otimiza para formatos de tensor fixos. Tarefas agênticas, no entanto, produzem sequências de comprimentos diferentes, o que normalmente acionaria recompilações dispendiosas. O Tunix agrupa sequências mais curtas e organiza episódios de comprimento semelhante em buckets, mantendo os formatos estáveis o suficiente para que o XLA reutilize os kernels compilados. O resultado é uma vazão constante sem o overhead do compilador que, de outra forma, prejudicaria o desempenho.

Escalando modelos massivos em vários chips TPU

Treinar agentes com mais de 70 bilhões de parâmetros requer a distribuição de pesos e dados em vários nós de TPU. O Tunix usa a primitiva ShardMap do JAX para fragmentar (shard) tanto os parâmetros do modelo quanto as ativações, permitindo que o learner mantenha todo o modelo na memória enquanto continua alimentando-o com dados em alta velocidade. Essa estratégia de sharding torna possível treinar modelos que antes estavam fora do alcance de um único pod de TPU.

Gradientes obsoletos (stale gradients) de pipelines desacoplados

Quando os atores correm à frente do learner, os dados que eles fornecem podem se tornar "obsoletos" (stale) em relação à política atual. O Tunix mitiga esse desvio com dois mecanismos: a reponderação por amostragem de importância (importance-sampling) ajusta amostras antigas para refletir sua relevância, e um limite de obsolescência configurável descarta trajetórias que excedem uma idade predefinida. Juntos, eles mantêm o aprendizado estável mesmo quando o pipeline funciona de forma assíncrona.

O que os adotantes precisam observar

  • Auditoria de latência – O benefício do desacoplamento depende do tempo de resposta do ambiente. As equipes devem medir a latência de ponta a ponta e garantir que os pools de atores sejam dimensionados para manter o buffer bem preenchido.
  • Design do pool de workers – CPUs ou GPUs baratas podem hospedar muitos atores, mas a sobreassinatura (oversubscribing) pode causar contenção na rede ou no armazenamento. Um pool equilibrado que corresponda à taxa de ingestão do buffer é essencial.
  • Robustez do buffer – O armazenamento central deve lidar com altas taxas de escrita e leitura sem se tornar um novo gargalo. Escolher um sistema de armazenamento com baixa latência de cauda (tail latency) e largura de banda suficiente é uma parte inegociável da arquitetura.

Possíveis desvantagens

A arquitetura dividida introduz mais partes móveis: frotas de hardware separadas, um buffer persistente e lógica de coordenação para aplicar os limites de obsolescência.

Conclusão

O Tunix mostra que o custo dominante no RL agêntico não é o modelo em si, mas o tempo de inatividade causado pelos loops de interação síncronos. Ao transferir o trabalho de rollout para hardware barato e alimentar um pod de TPU de aprendizado contínuo a partir de um buffer de alta vazão, o Google transformou um problema de utilização inferior a 10% em um fluxo de trabalho de capacidade quase total.