Google zet TPU Sync open source om KV-cache te verplaatsen

Een KV-cache (sleutel-waardecache) is het werkgeheugen dat een taalmodel opbouwt terwijl het een prompt leest: voor elk token dat al is verwerkt, bewaart het tussenwaarden zodat het die niet bij elk nieuw woord opnieuw hoeft te berekenen. Hoe langer het gesprek of document, hoe groter deze cache wordt, en hij staat normaal in het schaarse en dure geheugen met hoge bandbreedte (HBM) van de versnellerchip.

Google heeft nu TPU Sync uitgebracht, een open-source native C++-bibliotheek die deze cache moet verplaatsen en beheren tussen zijn TPU’s (tensor processing units). Volgens TechBytes, dat een blogpost van Google Cloud van de ingenieurs Fenghui Zhang en Weiren Yu samenvat, synchroniseert de bibliotheek ook modelparameters in reinforcement-learningworkflows. SemiAnalysis meldt dat TPU Sync eerder TPU-raiden heette, en Open Source For You beschrijft het project als TPU Raiden onder de Apache 2.0-licentie.

Waarom moet de KV-cache eigenlijk verhuizen?

Inferentie met een taalmodel kent twee fasen, legt Open Source For You uit: prefill, waarin het model de hele prompt leest, en decode, waarin het het antwoord token voor token genereert. Gedisaggregeerd serveren draait die twee fasen op gescheiden hardwarepools, zodat de KV-cache na de prefill naar de chips voor de decode moet worden gestuurd. Zonder transferbibliotheek, merkt SemiAnalysis op, is extern TPU-serveren beperkt tot de geaggregeerde modus, hoewel Google disaggregatie intern al jaren voor Gemini gebruikt.

Een tweede behoefte is het uitladen. Wanneer de HBM van een chip niet de cache van alle gebruikers kan bevatten, legt SemiAnalysis uit, moeten de gegevens van HBM naar het DRAM van de host en terug. Mark Lohmeyer, vicepresident en algemeen directeur AI- en computerinfrastructuur bij Google, zei volgens The Next Platform op 9 november 2026 in een telefonische persbijeenkomst dat TPU’s bij agentische workloads vaak een groot deel van de tijd stilstaan. TPU Sync haalt volgens hem het werkgeheugen van de chip wanneer een agent pauzeert en zet het terug wanneer de agent hervat, waardoor de versneller vrijkomt voor andere taken en de kosten per agentische workload dalen. The Next Platform voegt toe dat Google TPU Sync, omdat het software is, kan terugporteren naar eerdere TPU-generaties.

Welke prestaties claimt Google?

De onderstaande cijfers komen van TechBytes, gedateerd 9 november 2026, dat ze toeschrijft aan de Google Cloud-blog. We konden de Google-post zelf niet lezen; het zijn dus door de leverancier opgegeven cijfers die een secundair medium doorgeeft.

• De sleutel-waardetransferlatentie daalt volgens TechBytes met meer dan 90% bij open Mixture-of-Experts-modellen van 235 tot 480 miljard parameters.
• De Time to First Token (TTFT), de wachttijd tot het eerste woord van een antwoord verschijnt, daalt volgens TechBytes gemiddeld met 90% in benchmarks voor prefix caching en gedisaggregeerd serveren, vergeleken met standaardopstellingen.
• Het onderdeel raw_transfer haalt volgens TechBytes tot 223 GB/s aan geaggregeerde doorvoer tussen apparaat en host in beide richtingen op Ironwood TPU v7x-hosts, bij een fysieke PCIe Gen5-grens van 256 GB/s.
• Over het netwerk van het datacenter houdt de software volgens TechBytes ongeveer 192 Gbit/s vol op één netwerkkaart van 200 Gbit/s en 350 Gbit/s over twee kaarten met NUMA-bewuste striping.

Hoe werkt TPU Sync onder de motorkap?

Volgens TechBytes steunt TPU Sync op indelingsbehoudende directe geheugentoegang (DMA, een hardwaremechanisme dat geheugen kopieert zonder de processor te belasten), gecombineerd met in-place buffer-aliasing. De bibliotheek vermijdt Python-serialisatie en tussenkopieën door rechtstreeks met JAX PJRT-buffers en PyTorch-tensoren te werken, en de transfers vinden plaats buiten de XLA-compilatiegraaf. SemiAnalysis beschrijft hetzelfde idee als zero-copy-transfers, verkregen door de native hardwaredescriptors van PJRT-buffers uit te lezen.

Volgens TechBytes is de runtime opgebouwd uit drie modules. Een globale sleutel-waardestore fungeert als register dat prompt-hashes koppelt aan fysieke opslagblokken en de verwijdering van het minst recent gebruikte stuurt. Een clustercontroller verzorgt uitvoeringsplanning en leasebeheer. Een lokale cachemanager volgt de status van de apparaatblokken, beheert vastgepind hostgeheugen en houdt een warmstartkopie in gedeeld geheugen onder /dev/shm bij. De geheugenhiërarchie omvat HBM, vastgepind host-DRAM, lokale SSD’s en Google Cloud Managed Lustre.

Wat integraties betreft noemt TechBytes officiële bindings voor PyTorch via TorchTPU en voor JAX, een connector voor de serving-stacks vLLM, SGLang en llm-d, en laagniveauprimitieven voor Pathways en multi-controller-JAX-pijplijnen.

Wat zijn de grenzen en hoe volwassen is het?

TechBytes stelt dat transfers tussen HBM en host-DRAM klaar zijn voor productie, terwijl gelaagde opslag naar gedeelde systemen zoals Managed Lustre en externe POSIX-backends nog experimenteel wordt gevalideerd. Ook de module voor gewichtssynchronisatie bij reinforcement learning is experimenteel, en voor de maximale netwerkdoorvoer zijn twee netwerkkaarten van 200 Gbit/s met NUMA-bewuste striping nodig. Open Source For You, waarvan het artikel geen datum draagt, gaat verder en noemt het project nog in actieve ontwikkeling en nog niet bedoeld voor algemeen productiegebruik, dus het beeld van de volwassenheid verschilt per bron.

SemiAnalysis voegt een concurrentiehoek toe. De InferenceX-preview vergelijkt geaggregeerde TPU v7 met geaggregeerde Nvidia B200 en B300, en volgens SemiAnalysis lopen de systemen GB200 en GB300 NVL72 van Nvidia bij gedisaggregeerd serveren momenteel voor op een deel van de curve. Een vergelijking met gedisaggregeerde TPU v7 is gepland zodra disaggregatie op basis van TPU-Sync in de externe stack is geoptimaliseerd, en SemiAnalysis verwacht dat Mooncake Store-ondersteuning op TPU op TPU-Sync-primitieven wordt gebouwd.

Wat verandert er voor een bedrijf?

Voor een Nederlands bedrijf dat assistenten en agents met lange context op Google Cloud draait of huurt, wordt het verplaatsen van de KV-cache iets wat je configureert in plaats van zelf bouwt. Praktisch betekent dat: de connector met vLLM of SGLang testen op eigen prompts, de tijd tot het eerste token voor en na meten, en nagaan welke geheugenlagen nog als experimenteel gelden voordat je erop vertrouwt. Teams die met reinforcement learning trainen, moeten de module voor gewichtssynchronisatie valideren op hun eigen trainer- en samplertopologieën. Geen van de gepubliceerde cijfers vervangt een benchmark op de eigen workload.