TensorCast: et nytt lag for smartere håndtering av modellvekter og KV-cache

TensorCast er et foreslått «Tensor-as-a-Service»-lag (TaaS): et distribuert og programmerbart system som håndterer identitet, plassering, flytting, transformasjon, deling og klargjøring av tensor-data – uavhengig av beregningene som produserer eller bruker dataene. 1

Poenget er først og fremst arkitektonisk. I stedet for separate løsninger for innlasting av modellvekter, håndtering av KV-cache, nettverksoverføring og lagring, vil TensorCast tilby ett felles kontrollag for dynamiske AI-tjenester.

Hvorfor trengs et slikt lag?

Store språkmodeller håndterer ikke bare permanente modellvekter. De må også holde styr på svært dynamiske data, blant annet KV-cache-blokker og ulike mellomtilstander. I tradisjonelle systemer er denne håndteringen ofte bygget inn i hver sin inferensmotor, planlegger, nettverksløsning eller lagringsbackend. Det gjør det vanskeligere å kombinere og endre optimaliseringer på tvers av systemet. 1

TensorCast behandler derfor tensorenes livssyklus som et eget manglende infrastrukturlag. Applikasjonen beskriver hva som skal skje med tensor-dataene, mens kjøretidsmiljøet velger og utfører plassering, flytting, transformasjon og klargjøring på tvers av ressursene i klyngen. 1

Dette skiller seg fra vanlige objektlagre, som som regel behandler data som ugjennomsiktige filer eller objekter, og fra beregningsorienterte rammeverk, som først og fremst planlegger oppgaver – ikke hele livsløpet til tensor-tilstanden. 1

Slik er TensorCast bygget opp

• Tensorer som førsteklasses objekter: Hver tensor får en tydelig identitet, eier, plassering og livssyklus. En motor kan dermed referere til en modellvekt, en KV-cache-blokk eller en mellomtilstand uten selv å måtte vite hvilken node, GPU eller lagringstype den ligger på. 1
• Sammensettbare livssyklusfunksjoner: Utviklere kan kombinere operasjoner for flytting, transformasjon, forhåndshenting, replikering og klargjøring til regler tilpasset den aktuelle arbeidsbelastningen. Dermed slipper man å endre lavnivåinfrastrukturen for hver ny optimalisering. 1
• Skille mellom policy og mekanisme: En policy kan skrives gjennom TensorCast-API-ene, mens kjøretidsmiljøet utfører distribuert kjøring og dataflytting. Det skal kunne skje uten endringer i den underliggende beregningsmotoren. 1
• Skille mellom kontrollplan og dataplan: Global Store (GS) holder oversikt over blant annet noder, arbeidere, tensorplassering, eierskap og planleggingsinformasjon. Worker-prosessene utfører selve dataflyttingen. GS koordinerer altså trafikken, men frakter ikke tensorenes nyttelast – noe som skal hindre at kontrollaget blir en flaskehals. 1
• To strategier for metadata: Relativt statiske objekter med få forekomster, som modellvekter, kan spores sentralt i GS. Mer omfattende og dynamisk tilstand, som KV-cache, deles opp i shards. En Worker fungerer som hjem for hvert shard og håndterer eierskap og konsistens ved hjelp av leases og «fencing tokens». 1
• Effektiv klargjøring i minnet: Replikaer på Worker-siden kan eksponere GPU-minne gjennom CUDA IPC og CPU-minne gjennom lokale memfd-håndtak. For eksterne kilder støtter TensorCast direkte RDMA-skriving. Det reduserer unødvendige kopier og åpner for deling direkte mellom GPU-er eller lokalt der dette er mulig. 6

KV-cache-flytting kan bli langt enklere

KV-cache inneholder mellomtilstanden fra en pågående samtale med en språkmodell. I en flertrinnsdialog kan denne tilstanden bli stor, og hvis en økt må flyttes til en annen inferensinstans på grunn av skjev belastning, må tradisjonelle systemer ofte koordinere endringer i forespørselsruteren, inferensmotoren og cache- eller nettverksløsningen.

Med TensorCast kan en policy i stedet identifisere tensorobjektene som tilhører øktens KV-cache, be om at de klargjøres på en bestemt Worker og sende fremtidige forespørsler dit. Kjøretidsmiljøet håndterer oppslag, overføring og kobling mot minnet. 1

Det betyr ikke at selve flyttingen er kostnadsfri. Gevinsten er at regelen uttrykkes én gang på tensor-livssyklusenivå, i stedet for å måtte bygges på nytt i flere tett koblede komponenter. Det gjør det mer praktisk å teste strategier som tar hensyn til cache-lokalitet, gjenbruk av modellvekter eller samlokalisering av relaterte data. 1

Hva viste forsøkene?

Forskerne integrerte TensorCast med både vLLM og SGLang. De evaluerte blant annet klargjøring og synkronisering av modellvekter, KV-cache-håndtering og programmerbar ruting av forespørsler. 1

Resultatene som rapporteres i forskningsarbeidet, inkluderer:

• KV-cache-ytelse på nivå med eller konkurransedyktig med Mooncake, et spesialisert KV-cache-system, samtidig som TensorCast kan uttrykke regler som går på tvers av flere komponenter. 1
• Opptil 228,6 ganger raskere oppstart av en instans av Qwen3-235B-A22B enn med vanlige distribuerte filsystemer. Modellen har totalt 235 milliarder parametere, hvorav 22 milliarder er aktive i beregningen. 12
• Opptil 93,2 prosent lavere median tid til første token (TTFT) i arbeidsbelastninger med mange samtidige, flertrinns agent-samtaler. TTFT er tiden fra en forespørsel sendes til modellen begynner å levere det første svaretokenet. 1

Et lovende forskningsforslag – ikke en ferdig fasit

Resultatene peker mot en mulig retning for mer elastisk og tilstandsbasert AI-infrastruktur. Rask oppstart av modeller, ruting basert på cache-lokalitet, flytting av aktive samtaler og gjenbruk av tensor-data kan håndteres som programmerbare systemregler – i stedet for som separate, rammeverksspesifikke optimaliseringer.

Samtidig er tallene forskernes egne resultater fra et forskningspreprint. Uavhengig reproduksjon og validering i produksjonsmiljøer vil derfor være nødvendig før man kan konkludere med hvor bredt TensorCast kan tas i bruk. 1