Google abre o TPU Sync para mover o cache KV entre TPUs

Um cache KV (cache chave-valor) é a memória de trabalho que um modelo de linguagem constrói ao ler uma consulta: para cada token já processado, ele guarda valores intermediários para não recalculá-los a cada nova palavra produzida. Quanto mais longa a conversa ou o documento, maior esse cache fica, e ele normalmente reside na memória de alta largura de banda (HBM), escassa e cara, do chip acelerador.

O Google acaba de lançar o TPU Sync, uma biblioteca nativa em C++ de código aberto criada para mover e gerenciar esse cache entre seus processadores de IA TPU (tensor processing units). Segundo o TechBytes, que resume um post do blog do Google Cloud assinado pelos engenheiros Fenghui Zhang e Weiren Yu, a biblioteca também sincroniza os parâmetros dos modelos em fluxos de aprendizado por reforço. A SemiAnalysis diz que o TPU Sync se chamava antes TPU-raiden, e o Open Source For You apresenta o projeto como TPU Raiden, publicado sob a licença Apache 2.0.

Por que o cache KV precisa se mover?

A inferência de um modelo de linguagem tem duas fases, explica o Open Source For You: o prefill, em que o modelo lê todo o prompt, e o decode, em que gera a resposta token a token. O serviço desagregado executa essas duas fases em conjuntos de hardware separados, de modo que, após o prefill, o cache KV precisa ser enviado aos chips responsáveis pelo decode. Sem uma biblioteca de transferência, observa a SemiAnalysis, o serviço externo em TPU fica limitado ao modo agregado, embora o Google pratique a desagregação internamente para o Gemini há anos.

Uma segunda necessidade é o descarregamento. Quando a HBM de um chip não consegue guardar o cache de todos os usuários, explica a SemiAnalysis, os dados precisam ir da HBM para a DRAM do host e voltar. Mark Lohmeyer, vice-presidente e gerente geral de infraestrutura de IA e computação do Google, disse em uma teleconferência, segundo o The Next Platform em 9 de novembro de 2026, que as TPUs em cargas agênticas ficam muitas vezes ociosas por boa parte do tempo. O TPU Sync, afirmou, tira a memória de trabalho do chip quando um agente faz uma pausa e a restaura quando ele retoma, o que libera o acelerador para outras tarefas e reduz o custo por carga agêntica. O The Next Platform acrescenta que, por ser software, o TPU Sync pode ser portado pelo Google para gerações anteriores de TPU.

Que desempenho o Google anuncia?

Os números abaixo vêm do TechBytes, de 9 de novembro de 2026, que os atribui ao blog do Google Cloud. Não conseguimos ler o post do Google em si, então são números informados pelo fornecedor e repassados por um veículo secundário.

• A latência de transferência chave-valor cai mais de 90% em modelos abertos Mixture of Experts de 235 a 480 bilhões de parâmetros, segundo o TechBytes.
• O Time to First Token (TTFT), o atraso até a primeira palavra de uma resposta aparecer, cai 90% em média em testes de prefix caching e de serviço desagregado, em comparação com configurações padrão, segundo o TechBytes.
• O componente raw_transfer chega a 223 GB/s de vazão agregada entre dispositivo e host, nos dois sentidos, em hosts TPU Ironwood v7x, contra um limite físico PCIe Gen5 de 256 GB/s, segundo o TechBytes.
• Na rede do data center, o software sustenta cerca de 192 Gbit/s em uma placa de rede de 200 Gbit/s e 350 Gbit/s em duas placas com distribuição NUMA, segundo o TechBytes.

Como o TPU Sync funciona por dentro?

Segundo o TechBytes, o TPU Sync se apoia em transferências por acesso direto à memória (DMA, um mecanismo de hardware que copia memória sem envolver o processador) que preservam o layout dos dados, combinadas com aliasing de buffers no local. A biblioteca evita a serialização em Python e as cópias intermediárias ao trabalhar diretamente com os buffers PJRT do JAX e os tensores do PyTorch, e as transferências ocorrem fora do grafo de compilação do XLA. A SemiAnalysis descreve a mesma ideia como transferências sem cópia, obtidas extraindo os descritores de hardware nativos dos buffers PJRT.

De acordo com o TechBytes, o ambiente de execução se organiza em três módulos. Um repositório chave-valor global funciona como registro que associa hashes de prompts a blocos físicos de armazenamento e conduz as remoções dos menos usados recentemente. Um controlador de cluster cuida do planejamento e das concessões. Um gerenciador de cache local acompanha o estado dos blocos do dispositivo, administra a memória fixada do host e mantém uma cópia de inicialização rápida em memória compartilhada em /dev/shm. A hierarquia de memória abrange a HBM, a DRAM fixada do host, os SSDs locais e o Google Cloud Managed Lustre.

Em integrações, o TechBytes cita bindings oficiais para PyTorch via TorchTPU e para JAX, um conector para os motores de serviço vLLM, SGLang e llm-d, e primitivas de baixo nível para Pathways e fluxos JAX multicontrolador.

Quais são os limites e a maturidade?

O TechBytes afirma que as transferências entre HBM e DRAM do host estão prontas para produção, enquanto o armazenamento em camadas para sistemas compartilhados como o Managed Lustre ou backends POSIX externos segue em validação experimental. O módulo de sincronização de pesos para aprendizado por reforço também é experimental, e atingir a vazão máxima de rede exige duas placas de rede de 200 Gbit/s configuradas com distribuição NUMA. O Open Source For You, cujo artigo não tem data, vai além e chama o projeto de ainda em desenvolvimento ativo e ainda não destinado ao uso geral em produção, então o quadro de maturidade difere entre as fontes.

A SemiAnalysis traz um ângulo competitivo. Sua prévia do InferenceX compara a TPU v7 agregada com as Nvidia B200 e B300 agregadas, e diz que os sistemas GB200 e GB300 NVL72 da Nvidia lideram atualmente parte da curva em serviço desagregado. Uma comparação com a TPU v7 desagregada está planejada para quando a desagregação baseada no TPU-Sync estiver otimizada na pilha externa, e a SemiAnalysis espera que o suporte ao Mooncake Store em TPU seja construído sobre as primitivas do TPU-Sync.

O que muda para uma empresa?

Para uma empresa brasileira que executa ou aluga assistentes e agentes de contexto longo no Google Cloud, mover o cache KV passa a ser algo que se configura, não algo que se constrói. Os passos práticos são testar o conector com vLLM ou SGLang nos próprios prompts, medir o tempo até o primeiro token antes e depois, e verificar quais camadas de memória ainda estão marcadas como experimentais antes de depender delas. Equipes que treinam com aprendizado por reforço devem validar o módulo de sincronização de pesos nas próprias topologias de treinadores e amostradores. Nenhum dos números publicados substitui um teste na sua carga de trabalho.