Tensormesh lanserar plattform för att sänka kostnaderna för inferens med LLM:er genom återanvändning av KV-cache

Varje gång en AI-assistent får ett långt dokument måste den bearbeta innehållet innan den kan börja svara. När samma dokument, instruktioner eller samtalshistorik dyker upp igen kan en stor del av bearbetningen behöva upprepas. I stor skala på företagsnivå kan den upprepningen ta dyr GPU-kapacitet i anspråk utan att tillföra något användbart arbete.

Tensormesh tar sig an problemet med Tensormesh Platform, som tillkännagavs den 14 oktober 2026. Företaget, vars team skapade LMCache-projektet med öppen källkod, tillför ett lager för företagsstyrning av nyckel-värde-cachelagring, eller KV-cachelagring, för organisationer som kör stora språkmodeller på sin egen infrastruktur.

Plattformen hanterar återanvändbart inferenstillstånd i GPU-minne, CPU-minne och lagring. Den avsedda nyttan är enkel: att minska mängden promptbearbetning som en GPU-flotta måste upprepa, samtidigt som operatörerna får kontroll över hur det cachade tillståndet bevaras, delas och övervakas.

Därför är KV-cachen viktig

Inferens med LLM:er har två viktiga steg. Under förifyllning bearbetar modellen prompten. Under avkodning genererar den svaret token för token. KV-cachen lagrar mellanliggande tillstånd kopplat till uppmärksamhetsmekanismen, så att modellen kan gå tillbaka till redan bearbetade token utan att räkna om allt från grunden.

Genom att återanvända det tillståndet mellan förfrågningar kan förifyllningsarbetet minska när samma inmatningskontext återkommer. En supportassistent kan till exempel använda samma produktmanual för hundratals olika frågor. En agent kan upprepade gånger ta med samma instruktioner eller verktyg tillsammans med en uppgift som ändras.

Det här skiljer sig från att cacha ett färdigt svar. Systemet kan återanvända beräkningar som hör till den gemensamma kontexten och ändå generera ett nytt svar på en ny fråga.

Dokumentationen för vLLM:s automatiska prefixcachelagring beskriver nyttan vid upprepade frågor om dokument och konversationer med flera turer. Den tydliggör också en viktig begränsning: prefixcachelagring snabbar upp promptbearbetningen, inte genereringen av nya utdata-token. Arbetsbelastningar som domineras av långa svar eller till stor del unika indata kan ha mindre nytta av funktionen.

För företagskunder är den relevanta frågan hur stor del av deras faktiska arbetsbelastning som innehåller återanvändbar kontext – och om den kontexten går att återskapa snabbare och billigare än att beräkna den på nytt.

Att göra cache till hanterad infrastruktur

I sin presentation lyfter Tensormesh fram fem operativa prioriteringar: säkerhet, observerbarhet, motståndskraft, policyhantering och stöd för flera klienter. De handlar om det praktiska arbetet med att skydda cachade data, följa prestanda, återhämta sig från fel, styra lagringstid och utkastning samt hålla team eller kunder åtskilda i en delad infrastruktur.

Företaget beskriver också styr-API:er för att låsa, hitta, flytta, komprimera och rensa cacheposter. Det gör hanteringen av cachelivscykeln till en uttrycklig operativ fråga, i stället för något som helt överlåts åt enskilda inferensprocesser.

Det underliggande LMCache-projektet skiljer cachehanteringen från serveringsmotorn och stöder avlastning och hämtning mellan flera lagringsnivåer. Dokumentationen beskriver återanvändning mellan förfrågningar, sessioner och motorinstanser, med utbytbara lagrings- och transportbackendar.

Företagsplattformen bygger vidare på den grunden. Enligt dess installationsguide hanterar en Kubernetes-operator cachemotorns komponenter, med cacheservrar på GPU-noder och en samordnare för samordning på flottnivå. Helm används för driftsättningen, medan ett webbgränssnitt och kommandoradsverktyg stöder driften.

Den här arkitekturen är viktig eftersom GPU-minnet är en begränsad resurs. Om varje prompt som potentiellt kan återanvändas behålls där konkurrerar den med andra inferensbehov. Genom att flytta tillstånd som inte behövs lika omedelbart till värdminne eller lagring kan mer bevaras, även om hämtningen medför egna kostnader i form av bandbredd och latens.

Bortom identiska promptprefix

Prefixcachelagring fungerar bra när två promptar börjar med samma token. Retrieval-Augmented Generation, eller RAG, kan vara svårare: en applikation hämtar relevanta dokument, men dokumenten kan förekomma i olika ordning eller efter olika inledande text.

Tänk dig två hypotetiska förfrågningar som använder samma dokument. Den ena innehåller dokument A följt av B, den andra B följt av A. Båda innehåller material som går att återanvända, men den gemensamma inledningen kan vara kort.

Tensormesh använder CacheBlend för att utöka återanvändningen bortom början av en prompt. Dokumentationen för LMCache förklarar att en andel av tokenen räknas om selektivt medan cachade segment återanvänds. Omberäkningen behövs eftersom den omgivande kontexten för ett segment kan påverka modellens interna tillstånd.

Forskningsartikeln om CacheBlend, som presenterades på EuroSys 2025, rapporterar 2,2–3,3 gånger kortare tid till första token och 2,8–5 gånger högre genomströmning jämfört med fullständig omberäkning av KV-cachen i de arbetsbelastningar som utvärderades. Författarna utvärderade tre modeller med öppen källkod och fyra benchmarkdatauppsättningar.

Det här är forskningsresultat under specifika förhållanden, inte en garanterad besparing för varje Tensormesh-installation. De visar dock varför återanvändning utöver ett gemensamt prefix är tekniskt intressant: den kan ta till vara beräkningar som annars skulle gå förlorade vid konventionell prefixmatchning.

Återanvändning mellan noder och vikten av versionsspecifikt stöd

I lanseringsmeddelandet beskrivs peer-to-peer-överföring av KV-cache, vilket gör att en nod kan hämta cachat tillstånd från en annan. Företagets produktmaterial beskriver också uppdelning mellan prefill och decode. Uppdelningen skiljer promptbearbetning från generering av utdata, så att de två stegen kan köras på olika arbetarnoder.

Det här är kompletterande sätt att organisera inferens. Genom att dela kompatibelt tillstånd kan man undvika att beräkna om det på en annan nod. Genom att separera stegen kan infrastrukturteam fördela resurser på olika sätt utifrån bearbetningsbehoven.

De offentliga materialen ger dock inte en helt samstämmig bild av lanseringsstatusen. I introduktionen vid lanseringen beskrivs delning mellan noder och uppdelning mellan prefill och decode, medan den versionsspecifika kompatibilitetsmatrisen, daterad den 17 september, anger peer-to-peer-överföring och uppdelning mellan prefill och decode som planerade funktioner. Dokumentationen innehåller också förhandsversioner av funktionssidor.

Samma matris skiljer mellan funktioner som har verifierats i Tensormeshs tester och sådana som stöds uppströms men kräver ytterligare tester innan produktionssättning. Där anges vLLM och NVIDIA Dynamo som verifierade inferensmotorer, medan SGLang och TensorRT-LLM finns med i planeringen.

Det innebär att lanseringens breda formuleringar om kompatibilitet beskriver en önskad inriktning, inte visar att alla kombinationer av modeller och infrastruktur har validerats. Team bör kontrollera den exakta versionen, inferensmotorn, modellen och cacheläget som de planerar att driftsätta.

I introduktionen vid lanseringen beskrivs specifikt vLLM på Kubernetes med NVIDIA- eller AMD Instinct-GPU:er som stöds via ROCm samt lagring med stöd för filsystem. Där anges att cachelagring som inte är prefixbaserad för täta modeller och stöd för SGLang är på gång. Det klargörs också att cachen körs tillsammans med modeller som driftas själv; den är inte ett tillägg som kan kopplas till ett godtyckligt API för driftade modeller.

Där kalkylen kan gå ihop

De mest lovande användningsområdena är program som återkommande bearbetar omfattande, delvis gemensamt sammanhang: interna kunskapsassistenter, tjänster för dokumentanalys och agenter som gång på gång använder en stabil uppsättning instruktioner eller referensmaterial.

En användbar utvärdering skulle jämföra beteendet med tom respektive uppvärmd cache med hjälp av representativ trafik. Operatörer bör mäta tiden till den första tokenen, genomströmningen, tiden för att hämta cachedata, GPU-utnyttjandet samt minnes-, lagrings- och nätverkskostnaderna för att behålla tillstånd.

Enbart träffrekvensen i cachen räcker inte. En hög träffrekvens är bara värdefull om de beräkningar som återanvänds ger en nettovinst efter kostnaderna för överföring och hantering. På samma sätt innebär en snabbare första token inte nödvändigtvis att hela svaret blir klart proportionellt mycket snabbare.

Svarskvaliteten bör kontrolleras separat, särskilt när cachade delar kombineras i förändrade sammanhang. CacheBlends selektiva omberäkning är utformad för att hantera det problemet, men tester i produktion bör omfatta organisationens egna dokument, promptformat och modellkonfigurationer.

Datalagringstid och isolering mellan klienter blir också viktigare när cachen används utanför en enskild process. Viktiga driftfrågor är bland annat vem som får återanvända en post, hur länge den är tillgänglig och hur policyändringar eller begäranden om radering påverkar sparat tillstånd. Tensormeshs aviserade hanteringsfunktioner är avsedda att göra det möjligt att styra dessa beslut.

En praktisk satsning på att slippa upprepa arbete

Enligt företagets tillkännagivande är Tensormesh Platform tillgänglig i samband med lanseringen. Betydelsen ligger i att inferenstillstånd behandlas som en resurs som kan hanteras i ett helt kluster, där beräkningar kan återanvändas även efter att en enskild begäran har avslutats.

För företag som driver sin egen LLM-infrastruktur ger det här ett konkret sätt att öka effektiviteten: återanvänd mer av det promptbearbetningsarbete som redan har utförts. Resultatet beror på hur ofta arbetslasterna upprepar sig, cachekompatibiliteten och kostnaden för att flytta data – men det är mätbara tekniska frågor som team kan testa med sin egen trafik.