TurboQuant di Google: da 31GB a 4GB di memoria AI: cosa significa davvero

31GB ridotti a 4GB. È questo il numero che a giugno 2026 ha fatto perdere qualche punto percentuale alle azioni Micron e ha mandato mezza dev Twitter nel panico, chiedendosi se le bollette RAG fossero appena crollate. La matematica alla base è reale: TurboQuant di Google (arXiv 2504.19874, accettato a ICLR 2026) comprime la memoria di un LLM di circa 6x, scendendo a circa 3 bit per valore con perdita di accuratezza quasi nulla. Ma la maggior parte degli articoli ha sbagliato una cosa fondamentale, e questo cambia il modo in cui dovresti leggere tutta la storia.

La storia della compressione della memoria AI di TurboQuant è in realtà due storie che indossano la stessa felpa. Proviamo a districarle.

Punti chiave

• TurboQuant è l'algoritmo di compressione di Google, senza addestramento: riduzione del KV cache di circa 6x a ~3 bit, perdita di accuratezza quasi nulla (ICLR 2026).
• TurboVec è una libreria Rust di terze parti separata che implementa TurboQuant. Google non l'ha rilasciata.
• La demo virale "31GB → 4GB, batte FAISS" appartiene a TurboVec, non a TurboQuant puro.
• Il vantaggio reale per gli sviluppatori è un'inferenza long-context più economica e indici RAG più piccoli, ma il rilascio ufficiale di Google è un paper, non un prodotto.

Cos'è TurboQuant di Google, in parole semplici?

TurboQuant è l'algoritmo di quantizzazione vettoriale di Google Research: funziona senza addestramento ed è indipendente dai dati. Comprime il KV cache di un LLM di circa 6x, scendendo a circa 3 bit per valore, con perdita di accuratezza quasi nulla. È pubblicato in arXiv 2504.19874 e accettato a ICLR 2026. "Senza addestramento" significa che funziona sui modelli esistenti senza richiedere alcun fine-tuning.

Cosa si comprime, esattamente? Due cose, principalmente.

Prima, la KV cache. Quando un modello legge la tua conversazione, memorizza un riassunto dinamico di tutto ciò che è stato detto finora, chiamato key-value cache. Pensala come la memoria a breve termine del modello. Più è ampia la finestra di contesto, più questa memoria cresce e più RAM della GPU consuma. Una chat con 128.000 token può far gonfiare la KV cache fino a diversi gigabyte. Ecco perché il serving long-context diventa costoso rapidamente, ed è per questo che il prompt caching per ridurre i costi API è diventato una cosa concreta.

Seconda, gli indici vettoriali. Gli embedding che alimentano la ricerca semantica e il RAG sono grandi array di numeri in virgola mobile. Salvarne milioni alla massima precisione significa decine di gigabyte di RAM.

TurboQuant riduce entrambi. La parte interessante: non ha bisogno di nessuno dei tuoi dati per farlo. La maggior parte dei metodi di quantizzazione analizza un campione dei tuoi vettori, poi costruisce un codebook ottimizzato su di essi. TurboQuant salta questo passaggio. È indipendente dai dati, il che significa che raggiunge il suo rapporto di compressione senza mai guardare la tua distribuzione.

Il vero trucco di TurboQuant non è il rapporto di compressione. È che ha bisogno di zero dati di addestramento per raggiungerlo.

Questo è il vero sblocco. Puoi puntarlo su un modello che già esegui e ottenere i risparmi immediatamente.

TurboQuant vs TurboVec: la confusione che tutti stanno facendo

TurboQuant è l'algoritmo di compressione di Google (arXiv 2504.19874, ICLR 2026). TurboVec è una libreria Rust e Python separata di terze parti (RyanCodrai/turbovec) che implementa TurboQuant per la ricerca vettoriale. Google non ha rilasciato TurboVec. Il risultato virale "31GB → 4GB, batte FAISS" appartiene a TurboVec, non a TurboQuant puro. Se ricordi una sola cosa da questo articolo, che sia questa.

Ecco come è nata la confusione. Quando il benchmark 31GB→4GB è diventato virale all'inizio di giugno 2026, alcune testate (inclusa Tech Startups) hanno titolato che Google aveva "rilasciato TurboVec". Non è andata così. Controlla la fonte: TurboVec si trova su RyanCodrai/turbovec su GitHub e PyPI. È una libreria open source costruita da uno sviluppatore di nome Ryan Codrai. MarkTechPost ha inquadrato la cosa correttamente, descrivendola come "un indice vettoriale Rust con binding Python, costruito sull'algoritmo TurboQuant di Google."

Il rapporto è semplice: Google ha pubblicato la matematica, e la community ha costruito strumenti su di essa. TurboVec è il più visibile di questi strumenti.

Google ha costruito l'algoritmo. Uno sviluppatore di nome Ryan Codrai ha costruito la libreria che tutti stanno screenshottando. Non sono la stessa cosa.

Se stai valutando dove un indice basato su TurboQuant si inserisce rispetto alla tua configurazione attuale, la nostra rassegna dei migliori database vettoriali nel 2026 mette FAISS, Qdrant e i nuovi indici compressi fianco a fianco.

Come fa TurboQuant a comprimere la memoria senza distruggere l'accuratezza?

TurboQuant usa una rotazione casuale più uno schema di quantizzazione in coordinate polari (PolarQuant) e una proiezione in stile Johnson-Lindenstrauss (QJL, Quantized Johnson-Lindenstrauss) per distribuire i valori uniformemente prima della quantizzazione. Questa distorsione quasi ottimale è ciò che gli permette di scendere a circa 3 bit per valore mantenendo l'accuratezza quasi intatta, senza richiedere alcun riaddestramiento del modello.

Proviamo a scomporlo, perché il gergo nasconde un'idea abbastanza intuitiva.

Quando quantizzi, stai arrotondando i numeri a meno bit. Il pericolo è che alcune dimensioni di un vettore portino molto più peso delle altre, quindi arrotondarle in modo approssimativo distrugge il risultato. La soluzione di TurboQuant è ruotare il vettore casualmente prima. Immagina di mescolare un mazzo di carte uniformemente prima di distribuirle, in modo che nessuna mano risulti sbilanciata. Dopo la rotazione, i valori sono distribuiti in modo che nessuna dimensione domini, e l'arrotondamento fa molto meno male.

Questa è la parte QJL: una proiezione casuale che mescola tutto insieme preservando le distanze. PolarQuant (presentato all'AISTATS 2026) quantizza poi i valori ruotati in coordinate polari, che si adattano meglio alla loro distribuzione rispetto al semplice arrotondamento a griglia.

Il risultato è ciò che il paper chiama distorsione quasi ottimale, ovvero si avvicina al limite di Shannon per quanta qualità si può perdere a un dato budget di bit. In parole semplici: per 3 bit per valore non si può fare molto meglio, e TurboQuant ci arriva senza studiare i tuoi dati.

Per il meccanismo completo, il Google Research blog e il paper arXiv sono le fonti primarie. InfoQ ha anche una analisi orientata agli sviluppatori sull'angolo KV cache se vuoi la prospettiva pratica.

Cosa significa davvero 31GB → 4GB per la tua bolletta RAM?

Un indice RAG da 10M vettori che richiede ~31GB di RAM alla massima precisione scende a circa ~4GB con la compressione basata su TurboQuant di TurboVec, abbastanza piccolo da entrare in un'istanza commodity invece di un tier memory-optimized. Per la KV cache, la riduzione di ~6x significa circa 6 volte più sessioni long-context concorrenti sulla stessa GPU. Questa è la parte che appare davvero in fattura.

Una nota di onestà prima: tutto ciò che segue è stimato e modellato (giugno 2026) a partire dai prezzi cloud pubblici e dai rapporti dichiarati nel paper. Non abbiamo eseguito TurboVec in produzione, quindi considerali la matematica, non un benchmark che abbiamo misurato fisicamente. I livelli di prezzo seguono la stessa base che usiamo nella nostra guida alla riduzione dei costi API LLM.

Ecco un indice di embedding da 10M documenti, massima precisione vs compresso con TurboVec, mappato al tier cloud di RAM che effettivamente servirebbe:

Il salto da una macchina memory-optimized a una piccola general-purpose è tutta la storia. Per un indice self-hosted, è spesso la differenza tra una bolletta che fa soffrire e una che si nota a malapena. Se stai costruendo la pipeline che ci lavora sopra, la nostra guida su come costruire un'applicazione RAG spiega dove si inserisce questo indice.

Ora il lato KV cache, modellato su una GPU da 24GB che serve sessioni con contesto da 128k token:

Una riduzione 6x della KV cache non fa solo risparmiare RAM. Può trasformare una GPU in sei per il serving long-context.

Ecco perché questo conta di più per i carichi di lavoro long-context che per qualsiasi altra cosa. Se servi molte chat brevi, la tua KV cache non era mai il collo di bottiglia. Se esegui agenti da 128k token o analisi di documenti, una riduzione 6x cambia la tua economia per-GPU dall'oggi al domani. Il reporting di VentureBeat indica un guadagno di throughput fino a 8x su un H100 con risparmio di costi superiore al 50%, in linea con la nostra matematica sulla concorrenza modellata.

Perché sono calate le azioni dei produttori di chip, e Wall Street ha esagerato?

Dopo la presentazione di TurboQuant, le azioni di Micron, Western Digital e Seagate sono calate per il timore che una memoria AI radicalmente più economica riduca la domanda futura di DRAM e HBM, il cosiddetto inquadramento del "momento DeepSeek". Analisti tra cui Wells Fargo hanno argomentato il contrario: una memoria più economica aumenta l'utilizzo totale, non lo riduce, tramite il paradosso di Jevons.

Il racconto si è scritto da solo. L'AI è il maggiore acquirente di memoria ad alta larghezza di banda in questo momento, quindi se un algoritmo di Google taglia i bisogni di memoria di 6x, la logica vuole che la domanda di chip cali e con essa i produttori. TechCrunch ha addirittura tirato fuori il paragone con "Pied Piper", la startup di compressione fittizia di HBO's Silicon Valley che prometteva di rimpicciolire i dati del mondo. Le azioni sono calate su quella paura.

Ecco la lettura più calma, quella che il ciclo di notizie per lo più ha saltato. Wells Fargo ha citato il paradosso di Jevons: quando qualcosa diventa più economico ed efficiente, di solito ne consumiamo di più in totale, non di meno. Una memoria AI più economica significa che più app lanciano funzionalità long-context, più team si auto-ospitano indici RAG più grandi, e avviene più inferenza, in assoluto. I guadagni di efficienza hanno una lunga storia di crescita della domanda totale piuttosto che di ucciderla.

Il mercato ha prezzato TurboQuant come un killer della domanda. La storia dice che un calcolo più economico di solito significa semplicemente che ne usiamo di più.

Il calo è stato dunque eccessivo? Probabilmente sì, almeno nel breve periodo. Un paper di ricerca non è un retrofit industriale immediato. Il mercato ha reagito a un titolo di giornale; il deployment reale richiederà trimestri, e l'effetto di induzione della domanda potrebbe ben superare i risparmi.

TurboQuant si può usare oggi?

Sì, in parte. Il rilascio ufficiale di Google di TurboQuant è il paper e l'algoritmo, non un prodotto plug-and-play. Ma le implementazioni della community esistono già: TurboVec (RyanCodrai/turbovec, su PyPI) per gli indici vettoriali, e AmesianX/TurboQuant per llama.cpp (circa 5.2x, con supporto per DeepSeek-V2/V3 e GLM-4.7-Flash tramite MLA). L'ecosistema è giovane ma utilizzabile.

Se vuoi provare il lato vector index, TurboVec è a un pip di distanza:

pip install turbovec
# Rust + Python bindings, implements Google's TurboQuant for vector search
# llama.cpp KV-cache impl (DeepSeek/MLA): github.com/AmesianX/TurboQuant
# Python reference impl: github.com/yashkc2025/turboquant

Per il lato KV cache sui modelli locali, l'implementazione AmesianX/TurboQuant per llama.cpp è quella da tenere d'occhio, soprattutto se esegui modelli DeepSeek o GLM con multi-head latent attention. Si abbina bene a una configurazione LLM locale, poiché una KV cache più piccola significa che puoi spingere un contesto più grande sulla stessa scheda. E se stai scegliendo su quale modello open applicarlo, i nostri benchmark dei migliori LLM open source coprono le famiglie DeepSeek e GLM direttamente.

La messa in guardia onesta: siamo nella fase paper-ora, ecosistema-in-maturazione. Il deliverable ufficiale di Google è ricerca, non un prodotto supportato con un SLA.

La risposta onesta: TurboQuant è matematica pronta per la produzione, non ancora un pulsante di download.

TurboQuant è hype o qualcosa di reale? Un verdetto onesto

TurboQuant è reale e genuinamente intelligente. Il suo design senza addestramento è il vero sblocco, e il guadagno sulla KV cache conta di più per i carichi di lavoro long-context. Ma non è magia: è un avanzamento nella quantizzazione tra molti, il numero da titolo 31GB→4GB appartiene a TurboVec e non a Google, e il panico azionario ha sovrastimato un risultato di ricerca.

Nella nostra esperienza di ottimizzazione di inferenza e costi RAM per i clienti, la cosa che decide se vale la pena adottare una tecnica del genere è la frizione. La modalità senza addestramento vince in grande qui, perché non c'è ciclo di fine-tuning, nessun codebook da mantenere, nessun intervento chirurgico sul modello. Puoi aggiungerlo a qualcosa che già esegui.

Cosa cambia:

• Inferenza long-context più economica, che è dove il costo della memoria fa davvero male.
• Indici RAG self-hosted più piccoli che si adattano a hardware più economico.
• Un'opzione di compressione adottabile senza riaddestrare nulla.

Cosa non cambia:

• Non servirà a molto per carichi di lavoro short-context su modelli piccoli, dove la KV cache non era mai il collo di bottiglia.
• Non rende obsoleta la tua quantizzazione attuale dall'oggi al domani; è un'aggiunta, non una sostituzione.
• Il rilascio ufficiale di Google è ancora un paper, quindi il tooling production-grade è per ora in mano alla community.

Se stai cercando di capire cosa significa per la tua inferenza o la tua bolletta RAM, è esattamente il tipo di modellazione dei costi che facciamo per i clienti in Techsy. Richiedi una consulenza gratuita se vuoi un secondo parere.

Chi sono

Mert Batur Gurbuz è co-fondatore di Techsy.io, dove il team costruisce agenti AI, sistemi di automazione e pipeline voice/SDR per clienti B2B. Studia all'Università di Birmingham e scrive dello stack di strumenti LLM che il team Techsy usa realmente in produzione. Connettiti su LinkedIn.

Domande frequenti

Cos'è Google TurboQuant?

TurboQuant è l'algoritmo di quantizzazione vettoriale di Google Research, senza addestramento, pubblicato in arXiv 2504.19874 e accettato a ICLR 2026. Comprime la KV cache di un LLM di circa 6x, scendendo a circa 3 bit per valore, con perdita di accuratezza quasi nulla. Poiché è indipendente dai dati, funziona su modelli esistenti senza alcun fine-tuning o riaddestramiento.

Google ha davvero rilasciato TurboVec?

No. TurboQuant è l'algoritmo di Google. TurboVec è una libreria Rust e Python separata di terze parti (RyanCodrai/turbovec) costruita su TurboQuant da uno sviluppatore indipendente. Alcune testate hanno erroneamente attribuito a Google il rilascio di TurboVec quando il benchmark virale 31GB→4GB è diventato virale, ma GitHub mostra che è un progetto della community.

TurboQuant e TurboVec sono la stessa cosa?

No. TurboQuant è l'algoritmo di compressione pubblicato da Google. TurboVec è una libreria che implementa quell'algoritmo per la ricerca vettoriale. Uno è la matematica; l'altro è uno strumento costruito con quella matematica. Il famoso risultato "31GB → 4GB, batte FAISS" è di TurboVec, non qualcosa che Google ha rilasciato direttamente.

TurboQuant perde accuratezza?

La perdita di accuratezza quasi nulla è l'affermazione principale del paper, anche a circa 3 bit per valore. L'algoritmo raggiunge una distorsione quasi ottimale (vicina al limite di Shannon) ruotando casualmente i vettori prima della quantizzazione, in modo che nessuna dimensione domini. In pratica, il calo di qualità è abbastanza piccolo da essere trascurabile per la maggior parte dei carichi di lavoro.

Quanta RAM risparmia TurboQuant?

Circa 6x sulla KV cache, riducendola a circa 3 bit per valore. Lato vector index, TurboVec ha dimostrato un indice da 10M documenti che si riduce da 31GB a circa 4GB, fino al 92% di riduzione della memoria. Il risparmio reale dipende dalla tua baseline di precisione e da ciò che stai comprimendo: KV cache, embedding, o entrambi.

È solo hype? Perché sono calate le azioni dei chip?

È un vero avanzamento, ma il panico ha sovrastimato un risultato di ricerca. Micron, Western Digital e Seagate sono calate per il timore che una memoria AI più economica riduca la domanda di chip. Wells Fargo ha risposto con il paradosso di Jevons: una memoria più economica ed efficiente di solito aumenta l'utilizzo totale. Tra l'altro un paper non è un retrofit industriale immediato, quindi la reazione a breve termine appare eccessiva.

Si può usare TurboQuant oggi?

In parte. Il rilascio ufficiale di Google è il paper e l'algoritmo, non un prodotto. Le implementazioni della community esistono già: TurboVec su PyPI per gli indici vettoriali, AmesianX/TurboQuant per llama.cpp (DeepSeek-V2/V3 e GLM-4.7-Flash tramite MLA), e yashkc2025/turboquant come riferimento Python. L'ecosistema è giovane ma già utilizzabile.

In cosa si differenzia TurboQuant dalla quantizzazione che già uso?

La maggior parte dei metodi di quantizzazione studia un campione dei tuoi dati per costruire un codebook ottimizzato. TurboQuant è senza addestramento e indipendente dai dati, quindi raggiunge il suo rapporto senza mai guardare la tua distribuzione. Prende di mira specificamente la KV cache e gli indici vettoriali con distorsione quasi ottimale, anziché limitarsi a comprimere i pesi del modello.

TurboQuant funziona con DeepSeek o llama.cpp?

Sì, tramite l'implementazione AmesianX/TurboQuant per llama.cpp, che riporta circa 5.2x di compressione e supporta DeepSeek-V2/V3 e GLM-4.7-Flash tramite multi-head latent attention (MLA). Questo lo rende un'opzione pratica se esegui quei modelli in self-hosting e vuoi una KV cache più piccola per contesti più lunghi sullo stesso hardware.

Quando TurboQuant aiuta di più?

Aiuta di più con l'inferenza long-context e i grandi indici RAG self-hosted, dove la memoria è il vero collo di bottiglia. Una riduzione 6x della KV cache significa più sessioni concorrenti con contesto da 128k token per GPU, e un indice di embedding compresso si adatta a istanze più economiche. Aiuta di meno per le chat short-context e i modelli piccoli, dove la KV cache non era mai il tuo driver di costo.