Google gibt TPU Sync frei: KV-Cache schneller zwischen TPUs

Ein KV-Cache (Schlüssel-Wert-Cache) ist das Arbeitsgedächtnis, das ein Sprachmodell beim Lesen einer Eingabe aufbaut: Für jedes bereits verarbeitete Token speichert es Zwischenwerte, damit es sie nicht bei jedem neuen Wort erneut berechnen muss. Je länger das Gespräch oder das Dokument, desto größer wird dieser Cache, und er liegt normalerweise im knappen und teuren Hochgeschwindigkeitsspeicher (HBM) des Beschleunigerchips.

Google hat nun TPU Sync veröffentlicht, eine quelloffene native C++-Bibliothek, die diesen Cache zwischen den KI-Prozessoren TPU (Tensor Processing Units) verschieben und verwalten soll. Laut TechBytes, das einen Blogbeitrag von Google Cloud der Ingenieure Fenghui Zhang und Weiren Yu zusammenfasst, synchronisiert die Bibliothek außerdem Modellparameter in Reinforcement-Learning-Abläufen. SemiAnalysis zufolge hieß TPU Sync früher TPU-raiden, und Open Source For You beschreibt das Projekt als TPU Raiden unter der Apache-2.0-Lizenz.

Warum muss der KV-Cache überhaupt wandern?

Die Inferenz eines Sprachmodells hat zwei Phasen, erklärt Open Source For You: Prefill, in dem das Modell den gesamten Prompt liest, und Decode, in dem es die Antwort Token für Token erzeugt. Disaggregiertes Serving führt beide Phasen auf getrennten Hardware-Pools aus, sodass der KV-Cache nach dem Prefill an die Chips für den Decode geschickt werden muss. Ohne Transferbibliothek, so SemiAnalysis, ist externes TPU-Serving auf den aggregierten Modus beschränkt, obwohl Google die Disaggregation intern für Gemini seit Jahren betreibt.

Ein zweiter Bedarf ist das Auslagern. Wenn der HBM eines Chips nicht den Cache aller Nutzer fassen kann, erklärt SemiAnalysis, müssen die Daten vom HBM in den DRAM des Hosts und zurück wandern. Mark Lohmeyer, Vizepräsident und Generaldirektor für KI- und Recheninfrastruktur bei Google, sagte laut The Next Platform vom 9. November 2026 in einer Telefonkonferenz, dass TPUs bei agentischen Lasten oft einen großen Teil der Zeit ungenutzt sind. TPU Sync, so Lohmeyer, lagere das Arbeitsgedächtnis aus dem Chip aus, wenn ein Agent pausiert, und stelle es bei der Wiederaufnahme wieder her; das gebe den Beschleuniger für andere Aufgaben frei und senke die Kosten pro agentischer Last. The Next Platform ergänzt, dass Google TPU Sync als Software auf frühere TPU-Generationen zurückportieren kann.

Welche Leistung verspricht Google?

Die folgenden Zahlen stammen von TechBytes, datiert auf den 9. November 2026, das sie dem Google-Cloud-Blog zuschreibt. Den Google-Beitrag selbst konnten wir nicht lesen; es handelt sich also um Herstellerangaben, die ein Sekundärmedium weitergibt.

• Die Schlüssel-Wert-Transferlatenz sinkt laut TechBytes um mehr als 90 % bei offenen Mixture-of-Experts-Modellen mit 235 bis 480 Milliarden Parametern.
• Die Time to First Token (TTFT), die Wartezeit bis zum ersten Wort einer Antwort, sinkt laut TechBytes im Schnitt um 90 % in Benchmarks zu Prefix-Caching und disaggregiertem Serving gegenüber Standardaufbauten.
• Die Komponente raw_transfer erreicht laut TechBytes bis zu 223 GB/s aggregierten Durchsatz zwischen Gerät und Host in beide Richtungen auf Ironwood-TPU-v7x-Hosts, bei einer physischen PCIe-Gen5-Grenze von 256 GB/s.
• Im Rechenzentrumsnetz hält die Software laut TechBytes etwa 192 Gbit/s auf einer 200-Gbit/s-Netzwerkkarte und 350 Gbit/s über zwei Karten mit NUMA-bewusstem Striping.

Wie funktioniert TPU Sync intern?

Laut TechBytes setzt TPU Sync auf layoutwahrende Transfers per Direktspeicherzugriff (DMA, ein Hardwaremechanismus, der Speicher ohne Beteiligung des Prozessors kopiert) in Kombination mit direktem Puffer-Aliasing. Die Bibliothek vermeidet Python-Serialisierung und Zwischenkopien, indem sie direkt mit JAX-PJRT-Puffern und PyTorch-Tensoren arbeitet, und die Transfers laufen außerhalb des XLA-Kompilierungsgraphen. SemiAnalysis beschreibt dieselbe Idee als Zero-Copy-Transfers, die durch das Auslesen der nativen Hardware-Deskriptoren der PJRT-Puffer entstehen.

Nach TechBytes gliedert sich die Laufzeit in drei Module. Ein globaler Schlüssel-Wert-Speicher dient als Register, das Prompt-Hashes physischen Speicherblöcken zuordnet und die Verdrängung der am längsten ungenutzten Einträge steuert. Ein Cluster-Controller übernimmt Ausführungsplanung und Lease-Verwaltung. Ein lokaler Cache-Manager verfolgt den Zustand der Geräteblöcke, verwaltet angehefteten Hostspeicher und hält eine Warmstart-Kopie im Shared Memory unter /dev/shm. Die Speicherhierarchie umfasst HBM, angehefteten Host-DRAM, lokale SSDs und Google Cloud Managed Lustre.

Bei den Integrationen nennt TechBytes offizielle Anbindungen für PyTorch über TorchTPU und für JAX, einen Connector für die Serving-Stacks vLLM, SGLang und llm-d sowie Low-Level-Primitive für Pathways und Multi-Controller-JAX-Pipelines.

Wo liegen die Grenzen, und wie ausgereift ist es?

TechBytes zufolge sind Transfers zwischen HBM und Host-DRAM produktionsreif, während die gestufte Auslagerung in geteilte Speicher wie Managed Lustre und externe POSIX-Backends noch experimentell validiert wird. Auch das Modul zur Gewichtssynchronisation für Reinforcement Learning ist experimentell, und für den maximalen Netzwerkdurchsatz sind zwei 200-Gbit/s-Netzwerkkarten mit NUMA-bewusstem Striping nötig. Open Source For You, dessen Artikel kein Datum trägt, geht weiter und nennt das Projekt weiter in aktiver Entwicklung und noch nicht für den allgemeinen Produktionseinsatz gedacht; das Reifebild unterscheidet sich also je nach Quelle.

SemiAnalysis liefert eine Wettbewerbsperspektive. Die InferenceX-Vorschau vergleicht aggregierte TPU v7 mit aggregierten Nvidia B200 und B300, und laut SemiAnalysis führen Nvidias Systeme GB200 und GB300 NVL72 beim disaggregierten Serving derzeit auf einem Teil der Kurve. Ein Vergleich mit disaggregierter TPU v7 ist geplant, sobald die auf TPU-Sync basierende Disaggregation im externen Stack optimiert ist, und SemiAnalysis erwartet, dass die Mooncake-Store-Unterstützung auf TPU auf TPU-Sync-Primitiven aufbaut.

Was ändert sich für ein Unternehmen?

Für ein Unternehmen in Deutschland, das Assistenten und Agenten mit langem Kontext in der Google Cloud betreibt oder mietet, wird die Verschiebung des KV-Caches zu etwas, das man konfiguriert, statt es selbst zu bauen. Praktisch heißt das: den Connector mit vLLM oder SGLang an den eigenen Prompts testen, die Zeit bis zum ersten Token vorher und nachher messen und prüfen, welche Speicherstufen noch als experimentell gelten, bevor man sich darauf verlässt. Teams, die mit Reinforcement Learning trainieren, sollten das Gewichtssynchronisationsmodul auf ihren eigenen Trainer- und Sampler-Topologien validieren. Keine der veröffentlichten Zahlen ersetzt einen Benchmark mit der eigenen Last.