Google ouvre TPU Sync pour déplacer le cache KV entre TPU

Un cache KV (cache clé-valeur) est la mémoire de travail qu’un modèle de langage construit en lisant une requête : pour chaque jeton déjà traité, il conserve des valeurs intermédiaires afin de ne pas les recalculer à chaque nouveau mot produit. Plus la conversation ou le document est long, plus ce cache grossit, et il réside normalement dans la mémoire à haute bande passante (HBM), rare et coûteuse, de la puce accélératrice.

Google vient de publier TPU Sync, une bibliothèque native en C++ en code ouvert, conçue pour déplacer et gérer ce cache entre ses processeurs d’IA TPU (tensor processing units). Selon TechBytes, qui résume un billet du blog Google Cloud signé des ingénieurs Fenghui Zhang et Weiren Yu, la bibliothèque synchronise aussi les paramètres des modèles dans les chaînes d’apprentissage par renforcement. SemiAnalysis indique que TPU Sync s’appelait auparavant TPU-raiden, et Open Source For You présente le projet sous le nom TPU Raiden, publié sous licence Apache 2.0.

Pourquoi faut-il déplacer le cache KV ?

L’inférence d’un modèle de langage comporte deux phases, explique Open Source For You : le prefill, où le modèle lit tout le prompt, et le decode, où il génère la réponse jeton par jeton. Le service désagrégé exécute ces deux phases sur des parcs de matériel distincts ; après le prefill, le cache KV doit donc être envoyé aux puces chargées du decode. Sans bibliothèque de transfert, note SemiAnalysis, le service externe sur TPU se limite au mode agrégé, alors que Google pratique la désagrégation en interne pour Gemini depuis des années.

Un second besoin est le délestage. Quand la HBM d’une puce ne peut pas contenir le cache de tous les utilisateurs, explique SemiAnalysis, les données doivent aller de la HBM vers la DRAM de l’hôte puis revenir. Mark Lohmeyer, vice-président et directeur général de l’infrastructure d’IA et de calcul chez Google, a déclaré lors d’une conférence téléphonique, selon The Next Platform le 9 novembre 2026, que les TPU sont souvent inactifs une large part du temps dans les charges agentiques. TPU Sync, a-t-il expliqué, sort la mémoire de travail de la puce quand un agent se met en pause et la restaure à sa reprise, ce qui libère l’accélérateur pour d’autres tâches et réduit le coût par charge agentique. The Next Platform ajoute que, TPU Sync étant un logiciel, Google peut le rétroporter sur les générations précédentes de TPU.

Quelles performances Google annonce-t-il ?

Les chiffres ci-dessous viennent de TechBytes, daté du 9 novembre 2026, qui les attribue au blog Google Cloud. Nous n’avons pas pu lire le billet de Google lui-même : ce sont donc des chiffres annoncés par le constructeur et relayés par un média secondaire.

• La latence de transfert clé-valeur baisse de plus de 90 % sur des modèles ouverts Mixture of Experts de 235 à 480 milliards de paramètres, selon TechBytes.
• Le Time to First Token (TTFT), le délai avant l’apparition du premier mot d’une réponse, recule de 90 % en moyenne sur des tests de prefix caching et de service désagrégé, par rapport à des configurations standard, selon TechBytes.
• Le composant raw_transfer atteint jusqu’à 223 Go/s de débit agrégé entre puce et hôte, dans les deux sens, sur les hôtes TPU Ironwood v7x, pour une limite physique PCIe Gen5 de 256 Go/s, selon TechBytes.
• Sur le réseau du centre de données, le logiciel soutient environ 192 Gbit/s sur une carte réseau de 200 Gbit/s et 350 Gbit/s sur deux cartes avec répartition NUMA, selon TechBytes.

Comment TPU Sync fonctionne-t-il ?

Selon TechBytes, TPU Sync s’appuie sur des transferts par accès direct à la mémoire (DMA, un mécanisme matériel qui copie la mémoire sans solliciter le processeur) qui préservent la disposition des données, associés à un aliasing de tampons sur place. La bibliothèque évite la sérialisation Python et les copies intermédiaires en travaillant directement avec les tampons PJRT de JAX et les tenseurs PyTorch, et les transferts ont lieu hors du graphe de compilation XLA. SemiAnalysis décrit la même idée comme des transferts sans copie, obtenus en extrayant les descripteurs matériels natifs des tampons PJRT.

D’après TechBytes, l’exécution s’organise en trois modules. Un magasin clé-valeur global sert de registre qui associe des empreintes de prompts à des blocs de stockage physiques et pilote les évictions de type moins récemment utilisé. Un contrôleur de cluster gère la planification et les baux. Un gestionnaire de cache local suit l’état des blocs sur la puce, gère la mémoire hôte verrouillée et conserve une copie de redémarrage rapide en mémoire partagée sous /dev/shm. La hiérarchie mémoire couvre la HBM, la DRAM hôte verrouillée, les SSD locaux et Google Cloud Managed Lustre.

Côté intégrations, TechBytes cite des liaisons officielles pour PyTorch via TorchTPU et pour JAX, un connecteur pour les moteurs de service vLLM, SGLang et llm-d, ainsi que des primitives de bas niveau pour Pathways et les chaînes JAX multi-contrôleurs.

Quelles limites, et quelle maturité ?

TechBytes affirme que les transferts entre HBM et DRAM hôte sont prêts pour la production, tandis que le stockage par paliers vers des systèmes partagés comme Managed Lustre ou des backends POSIX externes reste en validation expérimentale. Le module de synchronisation des poids pour l’apprentissage par renforcement est lui aussi expérimental, et atteindre le débit réseau maximal exige deux cartes réseau de 200 Gbit/s configurées avec répartition NUMA. Open Source For You, dont l’article n’est pas daté, va plus loin et qualifie le projet de toujours en développement actif et pas encore destiné à un usage général en production : le tableau de maturité diffère donc selon les sources.

SemiAnalysis apporte un angle concurrentiel. Son aperçu InferenceX compare le TPU v7 agrégé aux Nvidia B200 et B300 agrégés, et affirme que les systèmes GB200 et GB300 NVL72 de Nvidia mènent actuellement sur une partie de la courbe en service désagrégé. Une comparaison avec un TPU v7 désagrégé est prévue lorsque la désagrégation fondée sur TPU-Sync sera optimisée dans la pile externe, et SemiAnalysis s’attend à ce que la prise en charge de Mooncake Store sur TPU repose sur les primitives de TPU-Sync.

Qu’est-ce que ça change pour une entreprise ?

Pour une entreprise française qui exploite ou loue des assistants et des agents à long contexte sur Google Cloud, le déplacement du cache KV devient un réglage plutôt qu’un chantier à construire. Les étapes pratiques consistent à tester le connecteur avec vLLM ou SGLang sur ses propres prompts, à mesurer le temps avant le premier jeton avant et après, et à vérifier quels paliers mémoire restent marqués expérimentaux avant de s’y fier. Les équipes qui entraînent par apprentissage par renforcement devront valider le module de synchronisation des poids sur leurs propres topologies d’entraîneurs et d’échantillonneurs. Aucun des chiffres publiés ne remplace un test sur votre charge de travail.