TensorCast: ett programmerbart lager för hela tensorernas livscykel

TensorCast är ett föreslaget lager enligt modellen Tensor-as-a-Service (TaaS): ett distribuerat system som programmerbart hanterar tensorers identitet, placering, förflyttning, omvandling, delning och materialisering – utan att vara bundet till den beräkning som skapar eller använder dem. 1

Det centrala är alltså inte en ny modell, utan en ny arkitektur för AI-drift. TensorCast försöker ersätta separata lösningar för exempelvis laddning av modellvikter, KV-cache, nätverksöverföring och lagring med ett gemensamt gränssnitt för hantering av tillstånd i dynamiska AI-tjänster. 1

Varför behövs TensorCast?

Stora språkmodeller arbetar inte bara med permanenta modellvikter. De behöver också hantera mycket dynamiska tensorer, bland annat KV-cache – mellanlagrade nyckel- och värderepresentationer som gör att en modell kan fortsätta en flerturnsdialog utan att räkna om hela samtalet – samt andra mellanresultat.

I traditionella system är ansvaret ofta uppdelat mellan inferensmotorer, schemaläggare, nätverkslager och lagringsbackend. Det kan göra optimeringar svåra att kombinera: en förändring av hur cache ska flyttas kan kräva ändringar i flera tätt kopplade komponenter. 1

TensorCast behandlar därför tensorernas livscykel som ett eget systemlager. Applikationen beskriver vad som ska hända med ett tensorobjekt, medan körmiljön hanterar var det ska placeras, hur det ska flyttas och när det ska göras tillgängligt i klustret. 1

Det skiljer sig från ett vanligt objektlager, där data i regel behandlas som ogenomskinliga block, och från beräkningsorienterade ramverk som främst planerar uppgifter snarare än tensorernas livscykel. 1

Så är systemet uppbyggt

• Tensorer som förstaklassobjekt: Varje tensor får en uttrycklig identitet, ägare, placering och livscykel. En inferensmotor kan därmed referera till en modellvikt, ett KV-cache-block eller ett mellanresultat utan att själv behöva hålla reda på vilken nod, GPU eller lagringsform som används. 1
• Kombinerbara livscykeloperationer: Utvecklare kan sätta ihop operationer för flytt, omvandling, förladdning, replikering och materialisering till policies för en viss arbetsbelastning. Det minskar behovet av att bygga om infrastrukturen för varje ny optimering. 1
• Åtskillnad mellan policy och mekanism: Policyn skrivs via TensorCast-API:er, medan körmiljön genomför den distribuerade exekveringen och dataflytten. Den underliggande inferensmotorn behöver därför inte ändras för varje ny strategi. 1
• Separat kontroll- och dataplan: Global Store, eller GS, håller reda på klustrets metadata – exempelvis arbetarnas status, tensorernas placering, ägarskap och schemaläggning. Själva tensorerna flyttas däremot av Workers. GS samordnar alltså trafiken utan att själv bära nyttolasten, vilket minskar risken att kontrollagret blir en flaskhals. 1
• Olika strategier för metadata: Relativt få och stabila objekt, som modellvikter, kan följas centralt i GS. Mer omfattande och snabbt föränderligt tillstånd, som KV-cache, delas upp mellan Workers. En särskild Worker ansvarar då för sitt shard och upprätthåller ägarskap och konsistens med hjälp av leases och fencing tokens. 1
• Effektiv materialisering: Lokala repliker kan exponera GPU-minne via CUDA IPC och CPU-minne via lokala memfd-handtag. För fjärrkällor stöder TensorCast direktskrivning med RDMA. På så sätt kan onödiga kopieringar undvikas och lokala delningsvägar mellan GPU:er användas där de finns tillgängliga. 6

Därför blir flytt av KV-cache enklare

Anta att en flerturnssession behöver flyttas från en överbelastad inferensinstans till en annan. I en traditionell serveringsstack kan det kräva samordnade ändringar i frågeroutern, inferensmotorns KV-cache-logik och cache- eller nätverksbackend.

Med TensorCast kan en policy i stället identifiera sessionens tensorobjekt för KV-cache, begära att de placeras och materialiseras hos en annan Worker och därefter styra nya förfrågningar dit. TensorCast ansvarar för uppslagning, överföring och koppling till minnet. 1

Det betyder inte att själva flytten blir kostnadsfri. Vinsten är att policyn uttrycks en gång på tensorlivscykelnivå, i stället för att implementeras på nytt i flera komponenter. Det gör det enklare att testa strategier som tar hänsyn till cache-lokalitet, återanvändning av modellvikter eller att relaterade tillstånd placeras nära varandra. 1

Vad visar experimenten?

Forskarna integrerade TensorCast med både vLLM och SGLang och utvärderade bland annat materialisering och synkronisering av modellvikter, KV-cache-hantering samt programmerbar routning av förfrågningar. 1

De rapporterar att prestandan för KV-cache är jämförbar med Mooncake, ett specialiserat system för just KV-cache, samtidigt som TensorCast kan uttrycka policies som sträcker sig över flera systemkomponenter. 1

För att starta en instans av Qwen3-235B-A22B – en modell med totalt 235 miljarder parametrar, varav 22 miljarder aktiveras – uppges TensorCast ge upp till 228,6 gånger snabbare uppstart än vanliga distribuerade filsystem. 12

I arbetsbelastningar med många samtidiga flerturnsinteraktioner mellan agenter rapporteras en programmerbar TensorCast-policy dessutom ha sänkt medianen för TTFT, alltså tiden från förfrågan tills den första tokenen visas, med upp till 93,2 procent. 1

Ett möjligt nytt lager i AI-infrastrukturen

Resultaten pekar på att TensorCast kan vara användbart i elastisk och tillståndsfull AI-infrastruktur: modeller kan startas snabbare, routning kan ta hänsyn till var cachen finns och tensorer kan återanvändas mellan tjänster. I stället för att varje ramverk bygger sin egen speciallösning kan sådana funktioner uttryckas som programmerbara systempolicies. 1

Samtidigt är siffrorna forskarnas egna resultat från ett forskningsförtryck. Oberoende reproduktion och tester i produktionsmiljö återstår därför innan det går att avgöra hur väl fördelarna håller i praktisk drift. 1