Google publica o TPU Sync para mover a cache KV entre TPU

Uma cache KV (cache chave-valor) é a memória de trabalho que um modelo de linguagem constrói ao ler um pedido: por cada token já processado, guarda valores intermédios para não os recalcular de cada vez que produz uma nova palavra. Quanto mais longa a conversa ou o documento, maior fica esta cache, e normalmente reside na memória de elevada largura de banda (HBM), escassa e cara, do chip acelerador.

A Google acaba de lançar o TPU Sync, uma biblioteca nativa em C++ de código aberto criada para mover e gerir essa cache entre os seus processadores de IA TPU (tensor processing units). Segundo o TechBytes, que resume um artigo do blogue da Google Cloud assinado pelos engenheiros Fenghui Zhang e Weiren Yu, a biblioteca também sincroniza os parâmetros dos modelos em fluxos de aprendizagem por reforço. A SemiAnalysis indica 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.

Porque é que a cache KV tem de 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 estas duas fases em conjuntos de hardware separados, pelo que, depois do prefill, a cache KV tem de ser enviada para os 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 a 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 a cache de todos os utilizadores, explica a SemiAnalysis, os dados têm de ir da HBM para a DRAM do anfitrião e regressar. Mark Lohmeyer, vice-presidente e diretor-geral de infraestrutura de IA e computação da Google, disse numa teleconferência, segundo o The Next Platform a 9 de novembro de 2026, que as TPU em cargas agênticas ficam muitas vezes inativas durante boa parte do tempo. O TPU Sync, afirmou, retira a memória de trabalho do chip quando um agente faz uma pausa e restaura-a quando este retoma, o que liberta 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 pela Google para gerações anteriores de TPU.

Que desempenho anuncia a Google?

Os números abaixo vêm do TechBytes, de 9 de novembro de 2026, que os atribui ao blogue da Google Cloud. Não conseguimos ler o artigo da Google em si, pelo que são números comunicados pelo fornecedor e retransmitidos por um meio secundário.

• A latência de transferência chave-valor desce mais de 90% em modelos abertos Mixture of Experts de 235 a 480 mil milhões de parâmetros, segundo o TechBytes.
• O Time to First Token (TTFT), o atraso até surgir a primeira palavra de uma resposta, 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 débito agregado entre dispositivo e anfitrião, nos dois sentidos, em anfitriões TPU Ironwood v7x, contra um limite físico PCIe Gen5 de 256 GB/s, segundo o TechBytes.
• Na rede do centro de dados, o software sustenta cerca de 192 Gbit/s numa placa de rede de 200 Gbit/s e 350 Gbit/s em duas placas com distribuição NUMA, segundo o TechBytes.

Como funciona o TPU Sync por dentro?

Segundo o TechBytes, o TPU Sync assenta em transferências por acesso direto à memória (DMA, um mecanismo de hardware que copia memória sem envolver o processador) que preservam a disposição dos dados, combinadas com aliasing de buffers no local. A biblioteca evita a serialização em Python e as cópias intermédias 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 organiza-se em três módulos. Um repositório chave-valor global funciona como registo que associa hashes de prompts a blocos físicos de armazenamento e conduz as remoções dos menos usados recentemente. Um controlador de cluster trata do planeamento e das concessões. Um gestor de cache local acompanha o estado dos blocos do dispositivo, administra a memória fixada do anfitrião e mantém uma cópia de arranque rápido em memória partilhada em /dev/shm. A hierarquia de memória abrange a HBM, a DRAM fixada do anfitrião, os SSD locais e o Google Cloud Managed Lustre.

Em integrações, o TechBytes cita ligações 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 anfitrião estão prontas para produção, enquanto o armazenamento em camadas para sistemas partilhados como o Managed Lustre ou backends POSIX externos continua em validação experimental. O módulo de sincronização de pesos para aprendizagem por reforço também é experimental, e atingir o débito máximo 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 mais longe e chama ao projeto ainda em desenvolvimento ativo e ainda não destinado a uso geral em produção, pelo que o quadro de maturidade difere entre as fontes.

A SemiAnalysis traz um ângulo competitivo. A sua pré-visualização 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á prevista 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 portuguesa que execute ou alugue assistentes e agentes de contexto longo na Google Cloud, mover a 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é ao primeiro token antes e depois, e verificar que camadas de memória continuam marcadas como experimentais antes de depender delas. As equipas que treinam com aprendizagem 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.