Google Cloud lança TPU Sync, biblioteca open-source para transferir KV cache e pesos em inference e RL na TPU

O argumento do Google Cloud é que o gargalo deixou de ser compute bruto e virou a gestão do estado vivo do modelo: o KV cache na inference e os pesos que saem dos trainers para os samplers no RL. O TPU Sync, biblioteca open-source em C++ nativo, trata HBM, DRAM do host, armazenamento compartilhado e a rede do data center (DCN) como uma hierarquia de memória única. Os tensores se movem no layout nativo da TPU, por DMA assíncrono que se sobrepõe à computação, sem serialização em Python, sem conversão de layout e sem compilação XLA no caminho de dados.

Os números vêm de testes internos de julho de 2026 em TPU v7x (topologia 2x2x1). A transferência de KV cai mais de 90% (no Qwen3 235B, a mediana passou de vários segundos para cerca de 230 ms). O TTFT cai em média 60% no Qwen3 235B e 90% no modelo de 480B, ambos com baixa concorrência. Em prefix caching com contexto de 64K, o TTFT cai até 90%, com mais de 50% de throughput e 30% a menos de latência P99 entre tokens. O Google ressalva que o desempenho real varia conforme cache hit e carga. O módulo de RL é experimental, assim como o tiering para armazenamento secundário (POSIX, SSD local e Managed Lustre). A integração cobre vLLM, SGLang e llm-d 1.0 no GKE, com wheels para PyTorch e JAX.

Há uma conexão direta com o ecossistema PyTorch em TPU. Em 21 de outubro de 2026, o CEVIU noticiou "Google abre o código do TorchTPU e leva PyTorch nativo para as TPUs", com o TorchTPU virando open source. O TPU Sync usa essa base: é integrado via TorchTPU e serve de conector de KV cache para vLLM e SGLang nessa stack. Em 20 de outubro de 2026, o CEVIU também registrou "VLLM Inova com Transferência KV Push-Based para Otimizar Inferência de IA", sobre transferência de KV em serving desagregado. O TPU Sync leva um problema parecido para a TPU, com o vLLM acessando a biblioteca pela interface KVConnector.

Para quem opera serving de modelos MoE grandes em TPU, a leitura é que o ganho não vem de mais chip, e sim de não recomputar prefill e de não deixar o acelerador esperando rede. Quem roda agentes de contexto longo ou system prompts extensos tem aqui uma camada pronta, sem escrever o próprio offload. Vale comparar com a sua carga, já que os resultados são de laboratório e o RL ainda é experimental.