Nová knihovna TPU Sync od Googlu srazila zpoždění o více než 90 %

Google zveřejnil TPU Sync

TPU Sync vznikl jako nástupce interního projektu TPU Raiden. Google ho nyní zveřejnil na GitHubu pod licencí Apache 2.0 jako knihovnu pro provoz velkých jazykových modelů na Cloud TPU. Projekt je určený hlavně pro týmy, které provozují modely s dlouhým kontextem, velkým počtem souběžných uživatelů nebo odděleným zpracováním vstupu a generováním odpovědi.

Nejde o nový jazykový model. TPU Sync nemění schopnosti modelu při psaní, uvažování ani práci s obrázky. Řeší jinou část systému – jak rychle přesouvat data, která model potřebuje během výpočtu.

Google popisuje TPU Sync jako vrstvu pro práci se stavem modelu. Knihovna propojuje vysokorychlostní paměť HBM přímo na akcelerátoru, systémovou DRAM, lokální SSD, sdílená úložiště, například Google Cloud Managed Lustre, a síť datového centra. Pro vývojáře to znamená, že s těmito zdroji nemusí zacházet jako s několika zcela oddělenými úložišti.

Zdrojový kód je dostupný v repozitáři TPU Sync na GitHubu. Google zároveň upozorňuje, že hlavní větev může obsahovat nestabilní změny. Pro nasazení doporučuje použít hodnotu zboru lkg.version, která odkazuje na poslední ověřenou revizi. ([github.com](https://github.com/google/tpu-sync?utm_source=openai))

KV cache brzdí práci s dlouhým kontextem

KV cache je pracovní paměť jazykového modelu. Při čtení promptu si model ukládá mezivýsledky, aby nemusel stejnou část textu zpracovávat znovu při každém dalším tokenu. U krátké konverzace si toho uživatel většinou nevšimne. U dlouhých dokumentů, agentů s více kroky nebo tisíců požadavků se z KV cache stává velká datová struktura.

Nejdřív se ukládá do HBM přímo na TPU. Ta nabízí vysokou rychlost, její kapacita je však omezená. Když se zaplní, systém musí část cache odložit jinam, nebo zpracovat prefix znovu. Obojí může prodloužit čekání na první token. U odděleného provozu se navíc KV cache přesouvá mezi uzly, které nejprve zpracují vstup a potom generují odpověď.

TPU Sync využívá asynchronní DMA přenosy. Data se mohou přesouvat na pozadí během výpočtu. Knihovna pracuje také s takzvaným zero-copy PJRT aliasingem, takže tensor nemusí nejprve putovat přes dodatečnou kopii v procesoru. Zjednodušeně řečeno, systém se snaží přesunout existující data přímo mezi vhodnými paměťovými vrstvami a nezastavovat kvůli tomu výpočet.

Google v technickém popisu TPU Sync přirovnává tento princip k přesunu připravených surovin mezi pracovní plochou, skladem a dalšími stanovišti. Přirovnání je tentokrát docela přesné. TPU pracuje rychle, ale nemá nekonečnou pracovní paměť. Pokud musí pro každý požadavek znovu připravovat stejné mezivýsledky, část výkonu se ztratí čekáním na data. ([cloud.google.com](https://cloud.google.com/blog/topics/ai-infrastructure/introducing-tpu-sync-fast-kv-cache-and-weight-transfer-on-tpu?utm_source=openai))

Výsledky testů Googlu

Google uvádí, že TPU Sync snížil latenci přenosu KV cache o více než 90 procent ve srovnání s provozem bez této knihovny. Výsledek pochází z testů velkých Mixture-of-Experts modelů s velikostí od 235 do 480 miliard parametrů při prefix cachingu a takzvaném disaggregated servingu.

U modelu Qwen3 235B klesla mediánová latence přesunu KV cache z několika sekund na přibližně 230 milisekund. Test probíhal při kontextu dlouhém 64 000 tokenů na systémech TPU v7x a v6e. Jde o měření Googlu, nikoli o nezávislý srovnávací test mezi různými výrobci akcelerátorů.

Google v širších výsledcích uvádí také zkrácení času do prvního tokenu, tedy TTFT. U některých velkých MoE modelů dosáhlo průměrné zkrácení 90 procent. V samostatně popsaném testu s Qwen3 235B při nízké konkurenční zátěži činilo zkrácení TTFT 60 procent. Rozdíl připomíná důležitou věc u podobných čísel: výsledek závisí na modelu, typu provozu, počtu požadavků i použité konfiguraci.

Naměřená propustnost dosáhla až 223 GB/s přes PCIe Gen5 na hostitelích Ironwood a až 350 Gb/s přes síť datového centra při použití dvojice síťových karet. Tato čísla popisují infrastrukturu určenou pro cloudové TPU, nikoli výkon běžného počítače nebo domácí grafické karty.

Napojení na JAX, PyTorch a inferenční nástroje

TPU Sync se integruje do prostředí JAX i PyTorch. U PyTorche využívá TorchTPU, který Google vyvíjí společně s Metou jako nativní backend pro TPU. Knihovna je dále napojená na inferenční frameworky vLLM a SGLang a na Kubernetes orchestrátor llm-d v Google Kubernetes Engine.

Prakticky to umožňuje několik způsobů nasazení. Při prefix cachingu lze opakovaně používané části promptu držet mimo HBM a podle potřeby je načítat z hostitelské paměti. U disaggregated servingu může jeden pool TPU zpracovat dlouhý vstup a jiný pool následně generovat odpověď. TPU Sync mezi nimi přesouvá potřebné bloky cache.

Google uvádí také přenos vah mezi trénovacími a inferenčními uzly pro reinforcement learning. Tato část je ale v repozitáři označená jako experimentální. Provozovatelé by proto neměli zaměňovat podporu v kódu za hotovou a stabilní produkční funkci.

Dokumentace Google Cloud potvrzuje podporu překryvu přenosů KV cache s výpočtem v PyTorchi a použití pro oddělené zpracování promptu a generování odpovědi. TPU Sync je podle ní validovaný zejména pro generace TPU v7x a v6e. ([docs.cloud.google.com](https://docs.cloud.google.com/tpu/docs/pytorch-on-tpu?hl=en&utm_source=openai))

Bezplatná knihovna, placená infrastruktura

Samotný TPU Sync je open-source a za jeho použití se neplatí licenční poplatek. To ovšem neznamená, že je provoz zdarma. Organizace potřebuje Cloud TPU, hostitelské servery, síťové přenosy a případně sdílené úložiště. Tyto služby se účtují podle standardního ceníku Google Cloud.

Pro českého uživatele je důležité hlavně to, že TPU Sync není aplikace ke stažení do Windows ani nástroj pro běžný notebook. Je určený pro vývojáře a firmy, které provozují vlastní AI infrastrukturu v cloudu. Dostupnost konkrétních TPU konfigurací a navazujících služeb se řídí nabídkou Google Cloud v daném regionu. Google pro tuto knihovnu neuvádí samostatnou českou lokalizaci.

Alternativy existují také mimo TPU. InfoQ zmiňuje například NVIDIA Dynamo a NIXL, LMCache, Mooncake nebo vlastní konektory ve vLLM pro GPU infrastrukturu. Tyto projekty řeší podobný problém s přesunem a ukládáním KV cache, ale nejsou přímou cenovou ani výkonovou konkurencí v jednom společném testu. Výběr závisí na použitém hardwaru a frameworku. ([infoq.com](https://www.infoq.com/news/2026/11/google-tpu-sync/?utm_source=openai))

Omezení současné verze

TPU Sync má jasný přínos pro provozovatele velkých modelů, současně je však ve fázi rychlého vývoje. GitHub repozitář přímo varuje před nasazením bez ověření kompatibility. API se mohou měnit a dostupné balíčky pro Python nemusí odpovídat stabilnímu veřejnému vydání.

Výsledky Googlu je proto potřeba číst jako výsledky konkrétních testovacích konfigurací. Zkrácení latence o 90 procent neznamená, že každá AI aplikace poběží desetkrát rychleji. Pokud systém netrpí přenosem KV cache nebo pracuje s krátkými prompty, TPU Sync podobný efekt přinést nemusí.

Největší smysl má knihovna tam, kde se opakovaně pracuje s rozsáhlým kontextem, vysokou souběžností požadavků nebo oddělenými skupinami TPU pro zpracování vstupu a generování. Pro domácího uživatele se tím nemění používání chatbotu. Pro provozovatele cloudového AI systému však může být rozdíl mezi čekáním na data a souběžným výpočtem podstatnou částí celkové odezvy.

FAQ