La compressione della KV cache è una decisione infrastrutturale, non un dibattito sul modello
La compressione della KV cache non è più un dibattito sulla qualità del modello. È una decisione di acquisto infrastrutturale con un problema matematico annesso.
Lo dico chiaramente perché troppi team continuano a trattare la memoria degli LLM a contesto lungo come un derby di benchmark: TurboQuant contro OSCAR contro EpiCache, scegli un vincitore e vai avanti. In pratica, non è così che i deployment falliscono. Falliscono perché un team ottimizza per la larghezza di bit, un altro per la portabilità e un terzo scopre troppo tardi che la cronologia di una chat multi-turno è un problema diverso da un singolo prompt da 128K. Secondo il riassunto del 18 giugno di MarkTechPost, i tre approcci stanno risolvendo colli di bottiglia adiacenti, non lo stesso.
La compressione della KV cache diventa dolorosa quando il limite è l'HBM, non i FLOP
La matematica della memoria è la parte che gli operatori non possono ignorare. L'esempio di riferimento utilizza Llama-3.1-70B in BF16: circa 0,31 MB di KV cache per token, circa 40 GB a 128K token e oltre 300 GB a 1M di token. Questo è il punto in cui la cache può superare i pesi del modello stesso. Se si servono richieste a contesto lungo con concorrenza, ogni token decodificato trascina quella cache attraverso la memoria a larghezza di banda elevata.
Questo spostamento conta più di un altro punto in classifica. Una volta che la decodifica diventa limitata dalla larghezza di banda, la curva dei costi cambia. Non ci si chiede più: "Questo modello risponde bene?", ma "Quante sessioni posso mantenere attive prima che il traffico di memoria distrugga la latenza?".
In un test di carico su un cliente che ho eseguito il mese scorso, la scelta del modello non era il vincolo principale. Il riutilizzo del prefisso sembrava ottimo isolatamente, ma una volta aumentato il numero di sessioni simultanee, la latenza di coda è aumentata perché il movimento della memoria, non il calcolo, era il limitatore. Ecco perché il lavoro di base a 2 bit di KIVI conta ancora nel 2026: ha inquadrato la quantizzazione della KV cache come un problema di sistemi di inferenza, non solo come un trucco di compressione.
TurboQuant è la mossa per la portabilità, non il vincitore universale
TurboQuant è impressionante per un motivo. Google Research e NYU hanno creato un approccio data-oblivious che attacca i canali outlier senza calibrazione. Per prima cosa ruota casualmente i vettori in modo che le coordinate si comportino più come variabili gaussiane indipendenti. Quindi applica un quantizzatore scalare precalcolato e una trasformazione QJL a 1 bit al residuo. La tesi teorica è solida: la distorsione rimane entro un piccolo fattore costante del limite inferiore.
È lo strumento giusto quando ti interessa la portabilità del modello e non puoi permetterti una calibrazione personalizzata per ogni target di servizio. Il punto ottimale riportato è l'intervallo da 3 a 4 bit, dove la qualità rimane quasi lossless sui carichi di lavoro enfatizzati dal documento. Ciò rende TurboQuant attraente per i team che gestiscono flotte miste o sperimentano su più architetture.
Ma ecco la parte provocatoria: le persone continuano a ripetere la promessa sbagliata. L'affermazione più forte su TurboQuant è la linea "attenzione 8 volte più veloce su H100" dal blog post di Google Research su TurboQuant, eppure l'articolo originale nota correttamente che questo si riferisce a un microbenchmark ristretto, non al serving end-to-end. Ho già visto questo schema con i kernel di inferenza: una vittoria in una fase diventa un argomento di approvvigionamento per l'intero stack. È così che i team si comprano delusioni.
OSCAR conta perché qualcuno ha effettivamente rilasciato le parti complesse
Se il tuo obiettivo è la compressione della KV cache INT2 distribuibile, OSCAR è la storia pratica in questo momento. Il sistema di Together AI non propone solo una rotazione consapevole dell'attenzione; racchiude al suo interno paging a precisione mista, kernel Triton e integrazione SGLang. È un grosso problema perché i guadagni di produzione solitamente derivano dal pacchetto, non dal documento.
I dettagli contano. OSCAR mantiene i token sink e recenti in BF16 mentre comprime i token storici in INT2, lasciando solo circa lo 0,24% dei token non compressi a 128K di contesto secondo il riassunto. Include anche rotazioni precalcolate per i modelli supportati, il che rimuove un brutto passaggio di deployment. Il vantaggio riportato è sostanziale: fino a 7,83 volte il throughput a livello di lavoro, circa 8 volte la riduzione della memoria KV-cache a 100K di contesto e fino a 3 volte una decodifica più veloce sulle configurazioni testate.
Ecco perché penso che OSCAR vinca attualmente l'argomento della distribuibilità all'estremo dei bit bassi. Non perché l'idea sia più bella. Perché qualcuno ha colmato il divario tra la teoria della quantizzazione e la realtà del serving.
Il caso estremo per un vincitore testa a testa continua a crollare
Un equo controargomento è che le aziende hanno bisogno di una risposta semplice. Se un metodo ne batte un altro sulla qualità del benchmark e sul throughput, scegliere il leader riduce la complessità. C'è logica in questo. Ogni percorso di inferenza extra aggiunge overhead di test, logica di rollback, lavoro di osservabilità e onere di supporto. Standardizzare su un metodo è spesso la scelta operativa più sensata.
Sono d'accordo con questo istinto. Semplicemente non credo che le prove attuali supportino un vincitore universale.
Il confronto riportato da OSCAR suggerisce che TurboQuant cala drasticamente con budget simili, ma quella lettura arriva con avvertenze che l'articolo originale ha fatto bene a segnalare: il confronto viene eseguito all'interno del framework di OSCAR, quantizza tutti i livelli, utilizza un singolo seed casuale e valuta TurboQuant al di sotto del suo regime previsto da 3 a 4 bit. Non è abbastanza per un verdetto radicale. Al contrario, la storia della portabilità di TurboQuant non risponde alla domanda se sia possibile ottenere un comportamento di produzione INT2 stabile sul proprio stack esatto la prossima settimana.
Quindi la decisione reale è più ristretta e noiosa:
- Scegli TurboQuant quando il deployment agnostico rispetto al modello e un comportamento quasi lossless da 3 a 4 bit contano più della compressione assoluta.
- Scegli OSCAR quando hai bisogno di INT2 per modelli supportati, integrazione in produzione e risparmi immediati di memoria a contesto lungo.
- Non costringere nessuno dei due a risolvere la gestione della memoria multi-turno, perché non è il loro lavoro.
EpiCache è il promemoria che i prompt lunghi e le lunghe conversazioni sono problemi di sistema diversi
Questa è la parte che molti team perdono. Un singolo prompt da 128K e una conversazione di due ore non sono lo stesso carico di lavoro, anche se entrambi sembrano "contesto lungo" su una slide.
EpiCache di Apple affronta direttamente il caso conversazionale. Invece di chiedere solo quanto precisamente memorizzare i token, chiede quale cronologia mantenere attiva, come segmentarla in episodi coerenti e come recuperare l'episodio giusto durante l'inferenza. Il framework aggiunge prefill a blocchi, clustering episodico, recupero su episodi e budget di memoria a livello di layer.
Operativamente, questo è un asse diverso dalla quantizzazione della KV cache. È gestione della cache, non solo restringimento della cache. I guadagni riportati nel materiale di riferimento sono esattamente il motivo per cui quella distinzione conta: fino al 40% di precisione in più rispetto alle baseline di eviction, precisione quasi a cache piena con compressione da 4 a 6 volte, memoria di picco fino a 3,5 volte inferiore e latenza circa 2,4 volte inferiore sui benchmark di conversazione valutati.
La mia confutazione alla mentalità "scegli solo un vincitore" è semplice: EpiCache si compone con TurboQuant o OSCAR. Quindi, se il tuo carico di lavoro è un copilot di supporto, un assistente alla ricerca o un agente interno con una profonda cronologia di chat, lo stack migliore potrebbe essere un metodo per la conservazione più un altro per la precisione di archiviazione. Non è indecisione. È progettazione di sistemi.
La domanda giusta è quale vincolo ti sta costando denaro per primo
Quando entro in una revisione dell'inferenza, non inizio con i nomi dei documenti. Inizio con tre domande.
Primo, la flotta di serving è limitata dalla memoria al momento della decodifica o siamo ancora limitati dal calcolo? Secondo, abbiamo bisogno di portabilità tra i modelli o possiamo ottimizzare duramente per uno stack supportato? Terzo, il carico di lavoro è dominato da un singolo prompt lungo o da molti turni conversazionali?
Quelle domande solitamente restringono rapidamente il campo. Se la portabilità domina, TurboQuant ha l'argomento più pulito. Se il tuo team è già su uno stack supportato da OSCAR e hai bisogno di risparmi INT2 aggressivi ora, OSCAR sembra più forte. Se le sessioni di supporto o la memoria dell'agente sono il punto dolente, EpiCache appartiene al design anche se effettui la quantizzazione.
Ecco perché continuo a tornare alla stessa tesi contrarian: la compressione della KV cache non è davvero una gara. È un problema di progettazione dello stack che è stato commercializzato come un incontro in gabbia.
Letture correlate
Martin Kuvandzhiev
CEO and Founder of Encorp.io with expertise in AI and business transformation