TensorCast: nová vrstva pro správu vah modelů, KV cache a dalších tenzorů

TensorCast je navrhovaná vrstva Tensor-as-a-Service (TaaS) – distribuovaný a programovatelný systém, který spravuje identitu, umístění, přesuny, transformace, sdílení a zpřístupnění tenzorových dat nezávisle na výpočtu, který je vytváří nebo využívá. Jeho význam spočívá především v architektuře: místo oddělených řešení pro načítání vah, KV cache, síťové přenosy a úložiště nabízí společné rozhraní pro správu stavu při dynamickém provozu AI. 1

Proč TensorCast vznikl

Velké jazykové modely nepracují pouze s trvale uloženými vahami. Během inference vzniká také velmi proměnlivá KV cache – mezipaměť klíčů a hodnot, která uchovává informace z předchozí části konverzace – a další mezistavy. Tyto typy tenzorů dnes často spravují oddělené inference enginy, plánovače, síťové vrstvy a úložné systémy. Jejich pravidla se proto obtížně kombinují a při každé nové optimalizaci je nutné zasahovat do více částí infrastruktury. 1

TensorCast chápe správu životního cyklu tenzorů jako chybějící systémovou vrstvu. Aplikace pouze popíše, co se má s tenzorovým stavem stát, zatímco runtime následně zvolí a provede jeho umístění, přesun, transformaci nebo materializaci v rámci clusteru. 1

Přístup se liší od běžných objektových úložišť, která data většinou vnímají jako neprůhledné bloky, i od výpočetně orientovaných frameworků, jež se soustředí hlavně na plánování úloh, nikoli na celý životní cyklus tenzorového stavu. 1

Jak je TensorCast navržen

• Tenzory jako objekty první třídy: Každý tenzor má vlastní identitu, vlastníka, umístění a pravidla životního cyklu. Engine tak může odkazovat na konkrétní váhy, blok KV cache nebo mezistav, aniž by musel řešit, na kterém uzlu či GPU se data právě nacházejí nebo v jaké podobě jsou uložena. 1
• Skládatelné operace: Vývojáři mohou kombinovat operace pro přesun, transformaci, přednačítání, replikaci a materializaci do politik přizpůsobených konkrétní zátěži. Nemusí kvůli každé nové optimalizaci měnit nízkoúrovňovou infrastrukturu. 1
• Oddělení politiky od mechanismu: Pravidla lze zapsat pomocí API TensorCastu, zatímco runtime obstará distribuované provedení a přenos dat bez nutnosti upravovat samotný výpočetní engine. 1
• Rozdělení řídicí a datové roviny: Global Store (GS) udržuje metadata o stavech workerů a uzlů, umístění tenzorů, vlastnictví a plánování. Samotné přenosy dat provádějí Workers. Global Store tak koordinuje provoz, ale nepřenáší objemná tenzorová data a nestává se úzkým hrdlem. 1
• Dvě strategie pro metadata: Relativně statické objekty s malým počtem záznamů, například váhy modelu, lze sledovat centrálně v Global Store. Dynamická a početná data, jako jsou bloky KV cache, se shardují; vlastnictví a konzistenci jednotlivých částí zajišťuje určený Worker pomocí leasingu a fencing tokenů. 1
• Efektivní materializace: Repliky na straně workerů mohou zpřístupnit GPU paměť přes CUDA IPC a CPU paměť prostřednictvím lokálních memfd handle. U vzdálených zdrojů TensorCast podporuje přímý zápis přes RDMA, tedy vysokorychlostní síťový přenos s omezením zbytečného kopírování dat. 6

Proč je přesun KV cache jednodušší

V tradiční infrastruktuře může přesun vícekolové konverzace vyžadovat současné úpravy směrovače požadavků, implementace KV cache v inference enginu i síťového nebo cacheového backendu. V TensorCastu může politika jednoduše identifikovat tenzorové objekty dané relace, požádat o jejich umístění či materializaci u cílového Workeru a následné požadavky směrovat tam. Vyhledání dat, jejich přenos a napojení do paměti zajistí runtime pro životní cyklus tenzorů. 1

Neznamená to, že přesun je bez nákladů. Výhoda spočívá v tom, že se pravidlo pro migraci zapisuje jednou na úrovni správy tenzorů, místo aby se znovu implementovalo v několika těsně propojených komponentách. Snadněji tak lze testovat a nasazovat strategie, které kombinují lokalitu cache, opakované využití vah nebo umístění souvisejících stavů na stejném místě. 1

Co ukázaly experimenty

Autoři TensorCast integrovali s frameworky vLLM a SGLang a testovali materializaci a synchronizaci vah, správu KV cache i programovatelné směrování požadavků. 1

Podle výsledků byl výkon při práci s KV cache srovnatelný se systémem Mooncake, který je na správu KV cache specializovaný. TensorCast si přitom zachovává možnost vytvářet politiky zasahující přes více komponent infrastruktury. 1

Při spouštění instance modelu Qwen3-235B-A22B, který má celkem 235 miliard parametrů a 22 miliard aktivovaných parametrů, studie uvádí až 228,6× rychlejší start než u běžných distribuovaných souborových systémů. 12

V silně konkurenčních scénářích s vícekolovými úlohami agentů vedla programovatelná politika TensorCastu podle autorů až k 93,2% snížení mediánu času do prvního tokenu (TTFT). 1

Co to znamená pro infrastrukturu AI

TensorCast naznačuje, že správa stavu velkých modelů by nemusela být souborem izolovaných optimalizací zabudovaných do jednotlivých frameworků. Rychlé spouštění modelů, směrování podle lokalizace cache, migrace konverzací i opakované využívání tenzorů by mohly být řízeny jako programovatelná systémová politika.

Výsledky podporují potenciál TensorCastu pro elastickou a stavovou AI infrastrukturu, ale je třeba je interpretovat s rezervou. Uvedená čísla pocházejí z experimentů autorů ve výzkumném preprintu; před širším produkčním nasazením bude nutné jejich nezávislé zopakování a ověření v reálných provozních podmínkách. 1