Tensormesh lanceert platform om inferentiekosten van LLM’s te verlagen met hergebruik van de KV-cache

Elke keer dat een AI-assistent een lang document ontvangt, moet die de inhoud verwerken voordat hij antwoord kan geven. Wanneer dezelfde documenten, instructies of gespreksgeschiedenis opnieuw worden aangeboden, moet een groot deel van die verwerking mogelijk worden herhaald. Op ondernemingsschaal kan die herhaling kostbare GPU-capaciteit opslokken zonder nuttig werk toe te voegen.

Tensormesh richt zich op dit probleem met Tensormesh Platform, dat op 14 oktober 2026 werd aangekondigd. Het bedrijf, waarvan het team het opensourceproject LMCache heeft ontwikkeld, voegt een beheerlaag voor ondernemingen toe aan caching van sleutel-waardeparen, oftewel KV-caching, voor organisaties die grote taalmodellen op hun eigen infrastructuur aanbieden.

Het platform beheert herbruikbare inferentiestatus in GPU-geheugen, CPU-geheugen en opslag. Het beoogde voordeel is eenvoudig: minder promptverwerking herhalen op een GPU-cluster, terwijl beheerders controle krijgen over hoe die gecachte status wordt bewaard, gedeeld en bewaakt.

Waarom de KV-cache belangrijk is

LLM-inferentie bestaat uit twee belangrijke fasen. Tijdens de prefillfase verwerkt het model de invoerprompt. Tijdens de decodefase genereert het model het antwoord token voor token. De KV-cache bevat tussentijdse statusgegevens voor de aandachtmechanismen, zodat het model eerder verwerkte tokens kan raadplegen zonder alles vanaf nul opnieuw te berekenen.

Door die status bij verschillende verzoeken te hergebruiken, kan de prefillverwerking worden beperkt wanneer de invoercontext terugkomt. Een supportassistent kan bijvoorbeeld voor honderden verschillende vragen dezelfde producthandleiding raadplegen. Een agent kan telkens dezelfde instructies of tools toevoegen aan een taak die steeds verandert.

Dit is iets anders dan een kant-en-klaar antwoord cachen. Het systeem kan berekeningen rond de gedeelde context hergebruiken en toch een nieuw antwoord op een nieuwe vraag genereren.

In de documentatie over automatische prefixcaching van vLLM wordt dit voordeel beschreven voor herhaalde documentvragen en gesprekken met meerdere beurten. De documentatie maakt ook een belangrijke beperking duidelijk: prefixcaching versnelt de verwerking van prompts, maar niet het genereren van nieuwe outputtokens. Workloads met voornamelijk lange antwoorden of grotendeels unieke invoer kunnen minder voordeel opleveren.

Voor zakelijke klanten is de relevante vraag welk deel van hun daadwerkelijke workload herbruikbare context bevat — en of die context sneller en goedkoper kan worden teruggehaald dan opnieuw berekend.

Van cache naar beheerde infrastructuur

In de aankondiging noemt Tensormesh vijf operationele prioriteiten: beveiliging, waarneembaarheid, veerkracht, beleidsbeheer en multitenancy. Deze prioriteiten hebben betrekking op praktische taken: gecachte gegevens beveiligen, prestaties volgen, storingen opvangen, bewaartermijnen en verwijdering beheren en teams of klanten van elkaar scheiden op gedeelde infrastructuur.

Het bedrijf beschrijft ook controller-API’s om cache-items vast te zetten, te lokaliseren, te verplaatsen, te comprimeren en te wissen. Daarmee wordt het beheer van de levenscyclus van de cache een expliciet operationeel aandachtspunt, in plaats van iets dat volledig aan afzonderlijke inferentieprocessen wordt overgelaten.

Het onderliggende LMCache-project scheidt cachebeheer van de serving-engine en ondersteunt het wegschrijven en ophalen van gegevens uit verschillende opslaglagen. De documentatie beschrijft hergebruik over meerdere verzoeken, sessies en engine-instanties, met inplugbare backends voor opslag en gegevensoverdracht.

Het enterpriseplatform bouwt voort op die basis. Volgens de installatiehandleiding beheert een Kubernetes-operator de componenten van de cache-engine, met cacheservers op GPU-nodes en een coördinator voor coördinatie op clusterniveau. Helm biedt de implementatiemethode, terwijl een webinterface en opdrachtregelprogramma’s het beheer ondersteunen.

Deze architectuur is belangrijk omdat GPU-geheugen een beperkte hulpbron is. Elke prompt bewaren die mogelijk herbruikbaar is, zou concurreren met andere inferentiebehoeften. Door status die niet direct nodig is naar hostgeheugen of opslag te verplaatsen, kan er meer worden bewaard, al brengt het ophalen ervan eigen bandbreedte- en latentiekosten met zich mee.

Verder dan identieke promptprefixen

Prefixcaching werkt goed wanneer twee prompts met dezelfde tokens beginnen. Retrieval-augmented generation (RAG) kan lastiger zijn: een toepassing haalt relevante documenten op, maar die documenten kunnen in een andere volgorde staan of volgen op andere voorafgaande tekst.

Neem twee hypothetische verzoeken met dezelfde documenten. Het ene bevat document A, gevolgd door B; het andere bevat B, gevolgd door A. Beide bevatten herbruikbare inhoud, maar het begin dat ze gemeen hebben, kan kort zijn.

Tensormesh gebruikt CacheBlend om hergebruik uit te breiden tot voorbij het begin van een prompt. In de LMCache-documentatie staat dat het systeem selectief een deel van de tokens opnieuw berekent en tegelijk gecachete chunks hergebruikt. Die herberekening is belangrijk, omdat de omringende context van een chunk invloed kan hebben op de interne status van het model.

Het onderzoeksartikel over CacheBlend, gepresenteerd op EuroSys 2025, rapporteert in de onderzochte workloads een 2,2–3,3 keer kortere tijd tot het eerste token en een 2,8–5 keer hogere doorvoer dan bij volledige herberekening van de KV-cache. De auteurs hebben drie opensourcemodellen en vier benchmarkdatasets geëvalueerd.

Dat zijn onderzoeksresultaten onder specifieke omstandigheden, geen gegarandeerde besparing voor elke implementatie van Tensormesh. Ze laten echter wel zien waarom hergebruik buiten een gedeelde prefix technisch interessant is: zo kan berekening worden bespaard die bij conventionele prefixmatching verloren zou gaan.

Hergebruik tussen nodes en het belang van ondersteuning per versie

In de aankondiging van de lancering worden peer-to-peer KV-overdrachten beschreven, waarmee een node gecachte status van een andere node kan ophalen. In het productmateriaal van het bedrijf wordt ook de scheiding tussen prefill en decode beschreven. Daarbij wordt de verwerking van prompts gescheiden van het genereren van uitvoer, zodat de twee fasen op verschillende workers kunnen draaien.

Dit zijn aanvullende manieren om inferentie te organiseren. Het delen van compatibele status kan voorkomen dat die op een andere node opnieuw moet worden berekend; door de fasen te scheiden kunnen infrastructuurteams middelen anders toewijzen aan de behoeften van hun verwerkingsprocessen.

De openbare informatie geeft echter geen eenduidig beeld van de beschikbaarheid. De introductie bij de lancering beschrijft het delen van gegevens tussen nodes en de scheiding van verwerkingsfasen, terwijl de compatibiliteitsmatrix per versie, gedateerd op 17 september, peer-to-peeroverdracht en scheiding van verwerkingsfasen op de routekaart vermeldt. Ook bevat de documentatie over functies pagina’s met previewversies.

Dezelfde matrix maakt onderscheid tussen functies die in de tests van Tensormesh zijn geverifieerd en functies die upstream worden ondersteund, maar vóór productiegebruik nog verder moeten worden getest. vLLM en NVIDIA Dynamo staan vermeld als geverifieerde inferentie-engines; SGLang en TensorRT-LLM staan op de routekaart.

Daarom moet de brede compatibiliteitsclaim van de release worden gezien als een ontwerpdoel, niet als bewijs dat elke combinatie van modellen en infrastructuur is gevalideerd. Teams moeten nagaan welke exacte release, inferentie-engine, welk model en welke cachemodus ze willen inzetten.

In de introductie bij de lancering wordt specifiek vLLM op Kubernetes beschreven, met NVIDIA- of ondersteunde AMD Instinct-GPU’s via ROCm en opslag op basis van een bestandssysteem. Caching zonder prefix voor dense modellen en ondersteuning voor SGLang worden als toekomstige mogelijkheden beschreven. Ook wordt verduidelijkt dat de cache naast zelfgehoste modellen draait; het is geen add-on die aan een willekeurige API voor gehoste modellen kan worden gekoppeld.

Waar het economisch voordeel kan opleveren

De meest kansrijke toepassingen zijn toepassingen die herhaaldelijk omvangrijke, gedeelde context verwerken: interne kennisassistenten, diensten voor documentanalyse en agents die telkens teruggrijpen op een stabiele set instructies of referentiemateriaal.

Een nuttige evaluatie vergelijkt het gedrag bij een lege cache met dat bij een gevulde cache, aan de hand van representatief verkeer. Beheerders moeten de tijd tot het eerste token, de doorvoer, de ophaaltijd van de cache, het GPU-gebruik en de geheugen-, opslag- en netwerkkosten voor het bewaren van status meten.

Het cachehitpercentage alleen volstaat niet. Een hoog hitpercentage is alleen nuttig als het hergebruikte werk per saldo voordeel oplevert nadat de overhead van overdracht en beheer is meegerekend. Een sneller eerste token betekent evenmin noodzakelijkerwijs dat de volledige reactie naar verhouding sneller klaar is.

Ook de kwaliteit van antwoorden moet afzonderlijk worden gecontroleerd, vooral wanneer gecachte fragmenten in gewijzigde contexten worden gecombineerd. De selectieve herberekening van CacheBlend is bedoeld om dat probleem aan te pakken, maar tests in productie moeten betrekking hebben op de eigen documenten, promptindelingen en modelconfiguraties van de organisatie.

Bewaartermijnen en tenantisolatie worden ook belangrijker wanneer de cache buiten één proces wordt gebruikt. De relevante operationele vragen zijn onder meer wie een item opnieuw mag gebruiken, hoelang het beschikbaar blijft en wat de gevolgen van beleidswijzigingen of verwijderverzoeken zijn voor opgeslagen status. De aangekondigde beheerfuncties van Tensormesh zijn bedoeld om die keuzes beheersbaar te maken.

Een praktische gok op minder dubbel werk

Volgens de aankondiging van het bedrijf is Tensormesh Platform sinds de lancering beschikbaar. Het belang ervan ligt in de benadering van inferentiestatus als een hulpbron die over een hele vloot kan worden beheerd, waarbij herbruikbare berekeningen bewaard blijven nadat een verzoek is afgehandeld.

Voor bedrijven die hun eigen LLM-infrastructuur beheren, biedt dit een concrete manier om efficiënter te werken: meer hergebruiken van het promptverwerkingswerk dat al is uitgevoerd. Het resultaat hangt af van de herhaling in de werklast, de compatibiliteit van de cache en de kosten van gegevensoverdracht. Dat zijn echter meetbare technische vraagstukken die teams met hun eigen verkeer kunnen testen.