L'importanza del cache KV
L'inferenza dei grandi modelli linguistici comporta due fasi cruciali: il pre-riempimento e il decodaggio. Durante il pre-riempimento, il modello elabora la richiesta in ingresso, mentre durante il decodaggio genera la risposta token per token. Il cache KV memorizza uno stato intermedio legato all'attenzione, permettendo al modello di riferirsi ai token già elaborati senza ricominciare tutto da capo.
La riutilizzazione di questo stato tra diverse richieste può ridurre il lavoro di pre-riempimento quando il contesto di ingresso si ripete. Ad esempio, un assistente di supporto può consultare lo stesso manuale del prodotto per rispondere a centinaia di domande diverse. Un agente può includere ripetutamente le stesse istruzioni o strumenti, pur trattando compiti diversi.
Questo metodo differisce dalla memorizzazione nella cache di una risposta finale. Il sistema può riutilizzare i calcoli associati al contesto condiviso, generando al contempo una nuova risposta a una nuova domanda.
Vantaggi e limiti
La documentazione di vLLM sulla memorizzazione automatica dei prefissi descrive i vantaggi per le richieste ripetute su documenti e conversazioni multi-turn. Tuttavia, sottolinea anche un limite importante: la memorizzazione nella cache dei prefissi accelera l'elaborazione delle richieste, non la generazione di nuovi token di output. Carichi di lavoro composti principalmente da risposte lunghe o da ingressi ampiamente diversi possono trarre meno benefici.
Per gli acquirenti aziendali, la domanda utile è capire quale parte del loro carico di lavoro reale comporta un contesto riutilizzabile e se questo può essere recuperato più rapidamente e a costi inferiori rispetto al ricominciare da capo.
Gestione del cache come infrastruttura
Tensormesh ha identificato cinque priorità operative: sicurezza, osservabilità, resilienza, gestione delle politiche e supporto multi-tenant. Queste priorità rispondono alle esigenze pratiche di protezione dei dati memorizzati nella cache, monitoraggio delle prestazioni, ripristino dopo un guasto, controllo della conservazione e dell'evizione, nonché separazione delle squadre o dei clienti su un'infrastruttura condivisa.
L'azienda descrive anche API di controllo che permettono di fissare, localizzare, spostare, comprimere ed eliminare le voci della cache. La gestione del ciclo di vita della cache diventa così una responsabilità operativa esplicita, piuttosto che essere lasciata interamente ai processi di inferenza individuali.
Architettura e funzionalità
Il progetto sottostante LMCache separa la gestione della cache dal motore di servizio e permette il caricamento e il recupero dei dati tra diversi livelli di storage. La documentazione descrive la riutilizzazione tra richieste, sessioni e istanze del motore, con sistemi di storage e trasporto modulari.
La piattaforma aziendale si basa su queste fondamenta. Secondo la sua guida all'installazione, un operatore Kubernetes gestisce i componenti del motore di cache, con server di cache sui nodi GPU e un coordinatore incaricato di coordinare l'intero cluster. Helm viene utilizzato per il deployment, mentre un'interfaccia web e strumenti a riga di comando facilitano l'esercizio.
Questa architettura è importante perché la memoria GPU è una risorsa limitata. Conservare tutte le richieste potenzialmente riutilizzabili in memoria GPU entrerebbe in conflitto con altre esigenze legate all'inferenza. Il trasferimento degli stati meno utili a breve termine alla memoria host o allo storage può aumentare il volume di dati conservati, anche se il loro recupero comporta i propri costi in termini di larghezza di banda e latenza.
Oltre i prefissi di richiesta identici
La memorizzazione nella cache dei prefissi funziona bene quando due richieste iniziano con gli stessi token. Tuttavia, la generazione aumentata da recupero (RAG) può presentare maggiori difficoltà: un'applicazione recupera documenti pertinenti, ma questi possono apparire in un ordine diverso o dopo testi preliminari diversi.
Immaginiamo due richieste ipotetiche che utilizzano gli stessi documenti. La prima contiene il documento A, seguito dal documento B; la seconda contiene il documento B, seguito dal documento A. Entrambe contengono elementi riutilizzabili, ma il loro inizio comune può essere breve.
Tensormesh utilizza CacheBlend per estendere la riutilizzazione oltre l'inizio di una richiesta. La documentazione di LMCache spiega che questo metodo ricalcola selettivamente una frazione di token, riutilizzando al contempo blocchi memorizzati nella cache. Questo ricalcolo è importante perché il contesto che circonda un blocco può influenzare lo stato interno del modello.
Risultati di ricerca
L'articolo di ricerca su CacheBlend, presentato a EuroSys 2025, riporta un tempo di attesa prima del primo token 2,2 a 3,3 volte più veloce e un throughput 2,8 a 5 volte superiore rispetto al ricalcolo completo del cache KV per i carichi di lavoro valutati. Gli autori hanno valutato tre modelli open source e quattro set di dati di riferimento.
Si tratta di risultati di ricerca ottenuti in condizioni specifiche, non di risparmi garantiti per ogni deployment di Tensormesh. Tuttavia, dimostrano perché la riutilizzazione oltre un prefisso condiviso è interessante dal punto di vista tecnico: può permettere di recuperare calcoli utili che la corrispondenza convenzionale dei prefissi non rileverebbe.
Riutilizzazione tra nodi e supporto specifico per versione
L'annuncio di lancio descrive i trasferimenti KV tra pari, che permettono a un nodo di recuperare lo stato memorizzato nella cache su un altro. La documentazione del prodotto dell'azienda descrive anche la separazione delle fasi di pre-riempimento e decodaggio. Questa separazione dissocia l'elaborazione dei prompt dalla generazione delle uscite, in modo che entrambe le fasi possano essere eseguite su processi di lavoro diversi.
Questi approcci complementari permettono di organizzare l'inferenza. Il sharing di uno stato compatibile può evitare di ricominciare da capo su un altro nodo; la separazione delle fasi può permettere alle squadre di infrastruttura di allocare le risorse in modo diverso in base alle loro esigenze di elaborazione.
Tuttavia, le informazioni pubbliche non concordano completamente sullo stato di disponibilità. La presentazione del lancio descrive il sharing tra nodi e la separazione delle fasi, mentre la matrice di compatibilità per versione, datata 17 settembre, indica che i trasferimenti tra pari e la separazione delle fasi sono sulla roadmap. La documentazione delle funzionalità include anche pagine di anteprima.
La stessa matrice distingue le funzionalità verificate durante i test di Tensormesh da quelle supportate a monte, ma che richiedono ulteriori test prima di una messa in produzione. Indica che vLLM e NVIDIA Dynamo sono motori supportati.