Hvad er TensorCast – og hvorfor kan det ændre infrastrukturen bag store sprogmodeller?

TensorCast er et foreslået Tensor-as-a-Service-lag (TaaS): et distribueret system, der gør det muligt at administrere tensorers identitet, placering, flytning, transformation, deling og materialisering uafhængigt af den beregning, som producerer eller bruger dem. 1

Den arkitektoniske idé er at erstatte en række særskilt udviklede løsninger til indlæsning af modelvægte, håndtering af KV-cache, netværksoverførsel og lagring med én fælles, programmerbar styringsflade til dynamisk AI-drift.

Hvorfor er TensorCast udviklet?

Store sprogmodeller arbejder ikke kun med permanente modelvægte. De skal også håndtere dynamiske KV-cache-blokke og andre mellemtilstande, som kan ligge fordelt på flere noder, GPU'er og lagermedier.

I traditionelle systemer er disse opgaver ofte indbygget i forskellige dele af stakken: inferensmotoren, request-routeren, scheduler'en, netværkslaget og backend-lageret. Det kan gøre det vanskeligt at kombinere eller ændre optimeringer på tværs af komponenterne. 1

TensorCast behandler derfor tensorernes livscyklus som et selvstændigt infrastrukturlag. En applikation kan beskrive, hvad der skal ske med en tensor, mens runtime-systemet vælger og udfører placering, flytning, transformation og materialisering på tværs af klyngens ressourcer. 1

Det adskiller sig fra et almindeligt objektlager, hvor data typisk behandles som uigennemsigtige blokke, og fra beregningscentrerede frameworks, der først og fremmest planlægger opgaver – ikke tensorernes samlede livscyklus. 1

Sådan er TensorCast bygget

• Tensorer som førsteklasses objekter: Hver tensor får en eksplicit identitet, ejer, placering og livscyklus. En inferensmotor kan dermed henvise til en modelvægt, en KV-cache-blok eller en mellemtilstand uden selv at skulle kende den præcise placering eller repræsentation. 1
• Sammensættelige livscyklusoperationer: Udviklere kan kombinere operationer til flytning, transformation, forudindlæsning, replikering og materialisering i politikker, der passer til den konkrete arbejdsbelastning. 1
• Adskillelse mellem politik og mekanisme: Politikken skrives via TensorCast-API'er, mens runtime-systemet håndterer den distribuerede udførelse og dataflytningen. Det skal kunne ske uden ændringer i den underliggende execution engine. 1
• Opdeling i kontrolplan og dataplan: Global Store (GS) holder styr på metadata som worker- og nodestatus, tensorplacering, ejerskab og planlægningsinformation. Selve tensorernes nyttelast flyttes af Workers. GS koordinerer altså dataflytningen uden selv at blive et trafikmæssigt flaskehals-punkt. 1
• To strategier for metadata: Relativt statiske objekter med lav kardinalitet, såsom modelvægte, kan registreres centralt i GS. Mere dynamisk og omfattende tilstand, såsom KV-cache, opdeles i shards, hvor en såkaldt shard-home Worker håndterer ejerskab og konsistens ved hjælp af leases og fencing tokens. 1
• Effektiv materialisering: Replikaer på en Worker kan eksponere GPU-hukommelse via CUDA IPC og CPU-hukommelse via lokale memfd-handles. Ved fjernkilder understøtter TensorCast direkte RDMA-skrivning. Det kan begrænse unødvendige kopier og udnytte GPU-til-GPU- eller lokale delingsveje, når de er tilgængelige. 6

Hvorfor bliver flytning af KV-cache enklere?

I en traditionel serving-stack kan flytningen af en flertrådet eller flerturn-baseret session kræve koordinerede ændringer i request-routeren, inferensmotorens KV-cache-implementering og cache- eller netværksbackenden.

Med TensorCast kan en politik i stedet identificere sessionens KV-tensorobjekter, bede om at få dem placeret eller materialiseret hos den ønskede Worker og derefter sende fremtidige forespørgsler dertil. Runtime-systemet håndterer opslag, overførsel og binding til hukommelsen. 1

Det betyder ikke, at selve flytningen er gratis. Fordelen er, at politikken kan udtrykkes én gang på tensorernes livscykluslag i stedet for at skulle implementeres igen i flere tæt koblede komponenter. Det gør det lettere at afprøve politikker, der for eksempel tager hensyn til cache-lokalitet, genbrug af modelvægte eller samplacering af relaterede tilstande. 1

Hvad viser forsøgene?

Forskerne har integreret TensorCast med både vLLM og SGLang og evalueret blandt andet materialisering og synkronisering af modelvægte, KV-cache-håndtering og programmerbar routing af forespørgsler. 1

De rapporterer, at TensorCast opnår KV-cache-resultater, der er konkurrencedygtige med Mooncake, et specialiseret KV-cache-system, samtidig med at TensorCast kan udtrykke politikker på tværs af flere systemkomponenter. 1

For opstart af en instans af Qwen3-235B-A22B – en model med 235 milliarder parametre, hvor 22 milliarder er aktiverede – rapporterer artiklen op til 228,6 gange hurtigere opstart end almindelige distribuerede filsystemer. 12

I arbejdsbelastninger med mange samtidige brugere og flertrins-agentdialoger reducerede en programmerbar TensorCast-politik ifølge forskerne medianen for time-to-first-token (TTFT) med op til 93,2 procent. TTFT er den tid, der går, før brugeren modtager modellens første token. 1

Hvorfor er det vigtigt?

Resultaterne peger på, at TensorCast kan få betydning for mere elastisk og tilstandsbevidst AI-infrastruktur. Hurtigere opstart af modeller, routing baseret på cache-lokalitet, flytning af aktive sessioner og genbrug af tensorer kan håndteres som programmerbare systempolitikker frem for som isolerede optimeringer i hvert enkelt framework. 1

Det er dog vigtigt at sætte resultaterne i perspektiv: Tallene stammer fra forfatternes egne eksperimenter i et forskningspreprint. Uafhængig reproduktion og validering i produktionsskala er derfor stadig nødvendig, før TensorCast kan vurderes som en moden standard for AI-infrastruktur. 1