Tensormesh lanserer plattform for å redusere inferenskostnadene for LLM-er gjennom gjenbruk av KV-hurtigbuffer

Hver gang en AI-assistent mottar et langt dokument, må den behandle innholdet før den kan begynne å svare. Når de samme dokumentene, instruksjonene eller samtalehistorikken dukker opp igjen, kan mye av denne behandlingen måtte gjentas. I stor skala i en virksomhet kan denne gjentakelsen beslaglegge kostbar GPU-kapasitet uten å tilføre nyttig arbeid.

Tensormesh retter seg mot dette problemet med Tensormesh Platform, som ble lansert 14. oktober 2026. Selskapet, som har et team som utviklet åpen kildekode-prosjektet LMCache, tilbyr et administrasjonslag for virksomheter som bruker nøkkel-verdi-bufring, eller KV-bufring, for å betjene store språkmodeller på egen infrastruktur.

Plattformen håndterer gjenbrukbar inferenstilstand på tvers av GPU-minne, CPU-minne og lagring. Den tiltenkte gevinsten er enkel: å redusere hvor mye promptbehandling en GPU-flåte må gjenta, samtidig som operatørene får kontroll over hvordan den bufrede tilstanden beholdes, deles og overvåkes.

Hvorfor KV-hurtigbufferen er viktig

Inferens for LLM-er har to viktige trinn. Under prefylling behandler modellen inndataprompten. Under dekoding genererer den svaret token for token. KV-hurtigbufferen lagrer mellomliggende tilstand knyttet til oppmerksomhetsmekanismen, slik at modellen kan vise til allerede behandlede tokener uten å beregne alt på nytt fra grunnen av.

Gjenbruk av denne tilstanden på tvers av forespørsler kan redusere arbeidet med prefylling når konteksten i inndataene gjentas. En kundestøtteassistent kan for eksempel slå opp i den samme produktmanualen for hundrevis av ulike spørsmål. En agent kan gjentatte ganger ta med de samme instruksjonene eller verktøyene sammen med en oppgave som endres.

Dette er noe annet enn å bufre et ferdig svar. Systemet kan gjenbruke beregninger knyttet til den delte konteksten og samtidig generere et nytt svar på et nytt spørsmål.

Dokumentasjonen for vLLMs automatiske bufring av promptprefikser beskriver denne fordelen ved gjentatte dokumentspørringer og samtaler med flere meldingsrunder. Den fastslår også en viktig begrensning: Bufring av prefikser gjør promptbehandlingen raskere, men ikke genereringen av nye utdata­ tokener. Arbeidsbelastninger som domineres av lange svar eller i stor grad unike inndata, kan ha mindre nytte av dette.

For virksomheter som vurderer løsningen, er det nyttige spørsmålet hvor stor del av den faktiske arbeidsbelastningen deres som inneholder gjenbrukbar kontekst – og om denne konteksten kan hentes fram raskere og billigere enn den kan beregnes på nytt.

Fra hurtigbuffer til administrert infrastruktur

I lanseringen peker Tensormesh på fem driftsprioriteringer: sikkerhet, observerbarhet, robusthet, policyadministrasjon og støtte for flere leietakere. Dette handler om det praktiske arbeidet med å beskytte bufrede data, følge med på ytelsen, gjenopprette etter feil, styre hvor lenge data beholdes og når de fjernes, samt å skille team eller kunder på en delt infrastruktur.

Selskapet beskriver også API-er for kontrollere som kan feste, finne, flytte, komprimere og slette oppføringer i hurtigbufferen. Dermed blir håndtering av hurtigbufferens livssyklus et uttrykkelig driftsansvar, i stedet for noe som overlates helt til de enkelte inferensprosessene.

Det underliggende LMCache-prosjektet skiller håndteringen av hurtigbufferen fra betjeningsmotoren og støtter avlasting og henting på tvers av flere lagringsnivåer. Dokumentasjonen beskriver gjenbruk på tvers av forespørsler, økter og forekomster av motoren, med utskiftbare lagrings- og transportløsninger.

Bedriftsplattformen bygger videre på dette grunnlaget. Ifølge installasjonsveiledningen administrerer en Kubernetes-operatør komponentene i hurtigbuffermotoren, med hurtigbufferservere på GPU-noder og en koordinator som samordner hele GPU-flåten. Helm brukes til utrulling, mens et nettgrensesnitt og kommandolinjeverktøy støtter driften.

Denne arkitekturen er viktig fordi GPU-minne er en begrenset ressurs. Hvis alle potensielt gjenbrukbare prompt-er ble beholdt der, ville de konkurrere med andre inferensbehov. Ved å flytte tilstand som ikke trengs umiddelbart, til vertens minne eller lagring kan man beholde mer av den, men henting medfører egne kostnader i båndbredde og forsinkelse.

Utover identiske promptprefikser

Bufring av prefikser fungerer godt når to prompter begynner med de samme tokenene. Gjenfinningsforsterket generering, eller RAG, kan være mer krevende: Et program henter relevante dokumenter, men dokumentene kan komme i ulik rekkefølge eller etter ulik foregående tekst.

Tenk deg to hypotetiske forespørsler som bruker de samme dokumentene. Den ene inneholder dokument A etterfulgt av B, mens den andre inneholder B etterfulgt av A. Begge inneholder materiale som kan gjenbrukes, men den felles innledningen kan være kort.

Tensormesh bruker CacheBlend til å utvide gjenbruket utover begynnelsen av en prompt. Dokumentasjonen for LMCache forklarer at løsningen beregner en andel av tokenene på nytt selektivt, samtidig som den gjenbruker bufrede blokker. Denne nye beregningen er viktig fordi konteksten rundt en blokk kan påvirke modellens interne tilstand.

Forskningsartikkelen om CacheBlend, som ble presentert på EuroSys 2025, rapporterer at tiden til første token var 2,2–3,3 ganger kortere, og at gjennomstrømningen var 2,8–5 ganger høyere enn ved full ny beregning av KV-hurtigbufferen i arbeidsbelastningene som ble evaluert. Forfatterne evaluerte tre modeller med åpen kildekode og fire referansedatasett.

Dette er forskningsresultater under bestemte forhold, ikke en garantert besparelse for enhver Tensormesh-implementering. De viser imidlertid hvorfor gjenbruk utover et delt prefiks er teknisk interessant: Det kan gjenskape nyttig beregningsarbeid som vanlig prefiksmatching ikke ville fanget opp.

Gjenbruk på tvers av noder og betydningen av versjonsspesifikk støtte

Lanseringskunngjøringen beskriver peer-to-peer-overføring av KV-tilstand, slik at én node kan hente bufret tilstand fra en annen. Selskapets produktmateriell beskriver også oppdeling av prefill- og decode-prosesseringen. Denne oppdelingen skiller behandling av forespørselen fra generering av utdata, slik at de to trinnene kan kjøres på forskjellige arbeidernoder.

Dette er komplementære måter å organisere inferens på. Deling av kompatibel tilstand kan gjøre det unødvendig å beregne den på nytt på en annen node, mens oppdeling av trinnene kan gjøre det mulig for infrastrukturteam å fordele ressursene annerledes ut fra behandlingsbehovene.

Det er imidlertid ikke fullt samsvar mellom de offentlig tilgjengelige opplysningene om lanseringsstatus. Introduksjonen ved lanseringen beskriver deling på tvers av noder og oppdeling, mens kompatibilitetsmatrisen for de ulike versjonene, datert 17. september, oppfører peer-to-peer-overføring og oppdeling som planlagte funksjoner. Dokumentasjonen inneholder også forhåndsvisningssider for funksjoner.

Den samme matrisen skiller mellom funksjoner som er verifisert i Tensormeshs tester, og funksjoner som støttes oppstrøms, men krever ytterligere testing før produksjonsbruk. Den oppfører vLLM og NVIDIA Dynamo som verifiserte inferensmotorer, mens SGLang og TensorRT-LLM står på veikartet.

Dermed er lanseringens brede formuleringer om kompatibilitet snarere en ønsket utviklingsretning enn dokumentasjon på at alle kombinasjoner av modeller og infrastruktur er validert. Team bør kontrollere den nøyaktige versjonen, inferensmotoren, modellen og hurtigbuffermodusen de har tenkt å ta i bruk.

Introduksjonen ved lanseringen beskriver konkret vLLM på Kubernetes med NVIDIA- eller støttede AMD Instinct-GPU-er via ROCm, samt filsystembasert lagring. Den beskriver hurtigbufring uten prefiksmatching for tette modeller og støtte for SGLang som kommende funksjoner. Den presiserer også at hurtigbufferen kjører sammen med modeller som driftes av brukeren selv; den er ikke et tillegg som kan kobles til et vilkårlig API for en vertsbasert modell.

Når kan det lønne seg økonomisk?

De mest aktuelle bruksområdene er applikasjoner som gjentatte ganger behandler store mengder delt kontekst: interne kunnskapsassistenter, tjenester for dokumentanalyse og agenter som stadig vender tilbake til et stabilt sett med instruksjoner eller referansemateriale.

En nyttig evaluering bør sammenligne ytelsen med kald og varm hurtigbuffer ved hjelp av representativ trafikk. De som drifter løsningene, bør måle tiden til første token, gjennomstrømning, tiden det tar å hente fra hurtigbufferen, GPU-utnyttelse og kostnadene for minne, lagring og nettverk ved å beholde tilstanden.

Treffraten i hurtigbufferen er ikke nok i seg selv. En høy treffrate er bare nyttig hvis arbeidet som spares, gir en netto gevinst etter kostnadene ved overføring og administrasjon. Tilsvarende betyr ikke et raskere første token nødvendigvis at hele svaret blir ferdig tilsvarende raskere.

Svarkvaliteten bør vurderes separat, særlig når bufrede tekstbiter settes sammen i endrede kontekster. Den selektive omberegningen i CacheBlend er laget for å håndtere dette problemet, men testing i produksjon bør omfatte organisasjonens egne dokumenter, promptformater og modellkonfigurasjoner.

Oppbevaring og isolering mellom leietakere blir også viktigere når hurtigbufferen går fra å være knyttet til én enkelt prosess til å brukes bredere. Relevante driftsmessige spørsmål er blant annet hvem som kan gjenbruke en oppføring, hvor lenge den er tilgjengelig, og hvordan endringer i retningslinjene eller forespørsler om sletting påvirker lagret tilstand. Administrasjonsfunksjonene Tensormesh har kunngjort, skal gjøre det mulig å styre disse valgene.

Et praktisk veddemål på å gjøre mindre av det samme arbeidet

Ifølge selskapets kunngjøring er Tensormesh Platform tilgjengelig fra lanseringen. Betydningen ligger i at inferenstilstand behandles som en ressurs som kan administreres på tvers av en hel maskinpark, slik at beregninger kan gjenbrukes også etter at den enkelte forespørselen er avsluttet.

For virksomheter som drifter sin egen LLM-infrastruktur, gir dette et konkret virkemiddel for å øke effektiviteten: å gjenbruke mer av arbeidet med å behandle forespørselen som allerede er utført. Resultatet avhenger av hvor ofte arbeidsbelastningen gjentar seg, hvor kompatibel hurtigbufferen er, og hva det koster å flytte dataene. Dette er imidlertid målbare tekniske spørsmål som team kan undersøke ved å teste løsningen på sin egen trafikk.