Tensormesh lancia una piattaforma per ridurre i costi di inferenza degli LLM riutilizzando la cache KV

Ogni volta che un assistente IA riceve un documento lungo, deve elaborarlo prima di poter iniziare a rispondere. Se gli stessi documenti, le stesse istruzioni o la stessa cronologia della conversazione ricompaiono, gran parte di questa elaborazione potrebbe dover essere ripetuta. Su scala aziendale, questa ripetizione può assorbire costose risorse GPU senza aggiungere lavoro utile.

Tensormesh punta a risolvere questo problema con Tensormesh Platform, annunciata il 14 ottobre 2026. L’azienda, il cui team ha creato il progetto open source LMCache, mette a disposizione delle organizzazioni che eseguono modelli linguistici di grandi dimensioni sulla propria infrastruttura un livello di gestione aziendale per la memorizzazione nella cache delle coppie chiave-valore, o cache KV.

La piattaforma gestisce lo stato di inferenza riutilizzabile tra memoria GPU, memoria CPU e archiviazione. Il vantaggio previsto è semplice: ridurre la quantità di elaborazione dei prompt che un parco di GPU deve ripetere, offrendo al contempo agli operatori controlli su come mantenere, condividere e monitorare lo stato memorizzato nella cache.

Perché la cache KV è importante

L’inferenza degli LLM si articola in due fasi importanti. Durante la fase di precompilazione, il modello elabora il prompt di input. Durante la fase di decodifica, genera la risposta token per token. La cache KV conserva uno stato intermedio legato all’attenzione, che consente al modello di fare riferimento ai token già elaborati senza ricalcolare tutto da zero.

Riutilizzare questo stato tra le richieste può ridurre il lavoro di precompilazione quando il contesto di input si ripete. Per esempio, un assistente del servizio clienti può consultare lo stesso manuale del prodotto per centinaia di domande diverse. Un agente può includere ripetutamente le stesse istruzioni o gli stessi strumenti insieme a un’attività che cambia.

Questo è diverso dal memorizzare nella cache una risposta già pronta. Il sistema può riutilizzare i calcoli associati al contesto condiviso continuando a generare una nuova risposta a una nuova domanda.

La documentazione di vLLM sulla memorizzazione automatica dei prefissi nella cache descrive questo vantaggio nel caso di interrogazioni ripetute su documenti e conversazioni con più turni. Indica anche un limite fondamentale: la memorizzazione dei prefissi nella cache accelera l’elaborazione dei prompt, non la generazione di nuovi token di output. I carichi di lavoro caratterizzati soprattutto da risposte lunghe o da input perlopiù unici potrebbero trarne meno vantaggio.

Per chi acquista soluzioni aziendali, la domanda utile è quanta parte del carico di lavoro effettivo contenga contesto riutilizzabile e se sia possibile recuperare tale contesto più rapidamente e a costi inferiori rispetto a ricalcolarlo.

Trasformare una cache in un’infrastruttura gestita

Nel presentare la propria soluzione, Tensormesh individua cinque priorità operative: sicurezza, osservabilità, resilienza, gestione delle policy e multi-tenancy. Queste priorità riguardano gli aspetti pratici della protezione dei dati memorizzati nella cache, del monitoraggio delle prestazioni, del ripristino in caso di guasti, del controllo dei tempi di conservazione e dell’eliminazione, nonché della separazione di team o clienti su un’infrastruttura condivisa.

L’azienda descrive inoltre API dei controller per bloccare, individuare, spostare, comprimere e cancellare le voci della cache. In questo modo, la gestione del ciclo di vita della cache diventa una responsabilità operativa esplicita, anziché essere lasciata interamente ai singoli processi di inferenza.

Il progetto alla base, LMCache, separa la gestione della cache dal motore di inferenza e supporta lo spostamento e il recupero dei dati tra più livelli di archiviazione. La relativa documentazione descrive il riutilizzo tra richieste, sessioni e istanze del motore, con backend di archiviazione e trasporto intercambiabili.

La piattaforma aziendale si basa su queste fondamenta. Secondo la guida all’installazione, un operatore Kubernetes gestisce i componenti del motore della cache, con server della cache sui nodi GPU e un coordinatore per il coordinamento a livello di parco macchine. Helm fornisce la procedura di distribuzione, mentre un’interfaccia web e strumenti a riga di comando supportano le operazioni.

Questa architettura è importante perché la memoria GPU è una risorsa limitata. Conservare ogni prompt potenzialmente riutilizzabile in memoria entrerebbe in competizione con le altre esigenze dell’inferenza. Spostare lo stato meno immediatamente utile nella memoria host o nell’archiviazione può aumentare la quantità di dati conservati, anche se il recupero comporta costi propri in termini di larghezza di banda e latenza.

Oltre i prefissi di prompt identici

La memorizzazione dei prefissi nella cache funziona bene quando due prompt iniziano con gli stessi token. La generazione aumentata dal recupero, o RAG, può essere più complessa: un’applicazione recupera documenti pertinenti, ma questi possono comparire in ordini diversi o dopo testi introduttivi diversi.

Consideriamo due richieste ipotetiche che utilizzano gli stessi documenti. Una include prima il documento A e poi il B; l’altra include prima il B e poi l’A. Entrambe contengono materiale riutilizzabile, ma la parte iniziale condivisa potrebbe essere breve.

Tensormesh utilizza CacheBlend per estendere il riutilizzo oltre l’inizio di un prompt. La documentazione di LMCache spiega che il sistema ricalcola selettivamente una parte dei token e riutilizza al contempo i blocchi memorizzati nella cache. Il ricalcolo è importante perché il contesto circostante un blocco può influire sullo stato interno del modello.

L’articolo di ricerca su CacheBlend, presentato a EuroSys 2025, riporta tempi di generazione del primo token da 2,2 a 3,3 volte più rapidi e un throughput da 2,8 a 5 volte superiore rispetto al ricalcolo completo della cache KV nei carichi di lavoro valutati. Gli autori hanno valutato tre modelli open source e quattro set di dati di benchmark.

Si tratta di risultati di ricerca ottenuti in condizioni specifiche, non di un risparmio garantito per ogni implementazione di Tensormesh. Dimostrano però perché il riuso oltre un prefisso condiviso sia tecnicamente interessante: può recuperare calcoli utili che il tradizionale confronto dei prefissi non rileverebbe.

Riuso tra nodi e importanza del supporto specifico per versione

L’annuncio del lancio descrive trasferimenti peer-to-peer di KV, che consentono a un nodo di recuperare lo stato memorizzato nella cache da un altro, mentre i materiali di prodotto dell’azienda descrivono la disaggregazione tra prefill e decode. La disaggregazione separa l’elaborazione del prompt dalla generazione dell’output, così che le due fasi possano essere eseguite su worker diversi.

Sono approcci complementari all’organizzazione dell’inferenza. Condividere stati compatibili può evitare di ricalcolarli su un altro nodo; separare le fasi può consentire ai team infrastrutturali di allocare le risorse in modo diverso, in base alle esigenze di elaborazione.

Tuttavia, i materiali pubblici non sono del tutto concordi sullo stato del rilascio. La presentazione del lancio descrive la condivisione tra nodi e la disaggregazione, mentre la matrice di compatibilità per versione, datata 17 settembre, indica il trasferimento peer-to-peer e la disaggregazione nella roadmap. Anche la documentazione delle funzionalità include pagine di anteprima.

La stessa matrice distingue le funzionalità verificate nei test di Tensormesh da quelle supportate a monte, ma che richiedono ulteriori test prima dell’uso in produzione. Indica vLLM e NVIDIA Dynamo come motori di serving verificati, mentre SGLang e TensorRT-LLM figurano nella roadmap.

Questo significa che l’ampia dichiarazione di compatibilità relativa al rilascio esprime una direzione progettuale, non dimostra che ogni combinazione di modelli e infrastrutture sia stata convalidata. I team dovrebbero verificare l’esatta versione, il motore di serving, il modello e la modalità di cache che intendono distribuire.

La presentazione del lancio descrive in particolare vLLM su Kubernetes con GPU NVIDIA o AMD Instinct supportate tramite ROCm e l’uso di uno spazio di archiviazione basato su file system. Indica come imminenti la memorizzazione nella cache non basata sui prefissi per i modelli densi e il supporto a SGLang. Chiarisce inoltre che la cache opera insieme ai modelli ospitati autonomamente: non è un componente aggiuntivo che si possa collegare a una qualsiasi API di modelli ospitati.

Dove il modello economico potrebbe funzionare

I casi più promettenti sono le applicazioni che elaborano ripetutamente grandi quantità di contesto condiviso: assistenti per la conoscenza interna, servizi di analisi dei documenti e agenti che consultano più volte un insieme stabile di istruzioni o materiali di riferimento.

Una valutazione utile confronterebbe il comportamento con cache fredda e cache calda usando traffico rappresentativo. Gli operatori dovrebbero misurare il tempo al primo token, la produttività, il tempo di recupero dalla cache, l’utilizzo delle GPU e i costi di memoria, archiviazione e rete necessari per conservare lo stato.

Il solo tasso di cache hit non basta. Un tasso elevato è utile soltanto se il lavoro recuperato genera un beneficio netto una volta considerati i costi aggiuntivi di trasferimento e gestione. Allo stesso modo, ottenere più rapidamente il primo token non significa necessariamente che l’intera risposta venga completata in proporzione più velocemente.

La qualità delle risposte va verificata a parte, soprattutto quando blocchi memorizzati nella cache vengono combinati in contesti modificati. Il ricalcolo selettivo di CacheBlend è progettato per affrontare questo problema, ma i test in produzione dovrebbero includere i documenti, i formati dei prompt e le configurazioni dei modelli propri dell’organizzazione.

La conservazione dei dati e l’isolamento tra tenant diventano inoltre più importanti quando la cache supera i confini di un singolo processo. Tra le questioni operative da considerare vi sono chi può riutilizzare una voce, per quanto tempo resta disponibile e in che modo le modifiche alle policy o le richieste di cancellazione incidono sullo stato salvato. Le funzionalità di gestione annunciate da Tensormesh sono pensate per permettere di controllare queste decisioni.

Una scommessa pragmatica sulla riduzione del lavoro ripetuto

Secondo l’annuncio dell’azienda, Tensormesh Platform è disponibile con il lancio. La sua importanza sta nel trattare lo stato dell’inferenza come una risorsa gestibile su un’intera flotta, conservando i calcoli riutilizzabili oltre la durata immediata di una richiesta.

Per le aziende che gestiscono la propria infrastruttura LLM, questo offre una leva concreta per migliorare l’efficienza: riutilizzare una porzione maggiore del lavoro di elaborazione dei prompt già svolto. Il risultato dipenderà dalla ripetitività dei carichi di lavoro, dalla compatibilità della cache e dal costo del trasferimento dei dati; si tratta però di aspetti ingegneristici misurabili che i team possono verificare sul proprio traffico.