TurboQuant-MLX: quantizzare pesi e KV cache per LLM open-weight su Mac

Intelligenza Artificiale

Architetture AI on-premise, LLM locali, RAG, agenti autonomi. L’intelligenza che non si può permettere di vedere spenta va posseduta.

Scopri →

Servizi & Sistemi Linux

Progettazione, deploy e gestione di infrastrutture Linux on-premise: dai server all’hardware AI, con dati che restano tuoi.

Scopri →

Admina Enterprise

Governance AI Open Source: audit trail, PII redaction, policy bidirezionali ALLOW/BLOCK/REDACT su qualsiasi modello, locale o remoto.

Scopri Admina →

Ricerca & Sviluppo

Ricerca applicata e prototipazione, dall’AI all’infrastruttura, in collaborazione con università e centri di ricerca.

Scopri →

Far girare un modello linguistico di grandi dimensioni sul proprio hardware, senza mandarlo nel cloud, è quasi sempre un problema di memoria: i pesi del modello e la cache degli stati di attenzione (la KV cache) devono entrare nella RAM disponibile. turboquant-mlx è un progetto open source (licenza MIT, secondo il README) che affronta entrambi i fronti su Apple Silicon, portando su MLX (il framework di machine learning di Apple) il metodo di quantizzazione TurboQuant ed estendendolo.

È un progetto giovane, di un singolo sviluppatore indipendente (manjunathshiva, poche decine di stelle su GitHub al momento della scrittura). Vale la pena distinguere con cura ciò che viene dal metodo originale da ciò che aggiunge il repo e leggere i numeri per quello che sono: misure dell’autore, su hardware specifico, non ancora verificate in modo indipendente.

Il problema: la memoria

L’inferenza in locale è vincolata dalla memoria. Su Apple Silicon la RAM è unificata, condivisa tra CPU e GPU, il che aiuta, ma un modello da 120 miliardi di parametri in BF16 occupa comunque circa 240 GB solo di pesi. La quantizzazione serve a questo: memorizzare pesi (e stati) con meno bit per parametro. I modelli GPT-OSS di OpenAI, per esempio, sono addestrati nativamente in MXFP4, un formato a circa 4,25 bit per parametro, ed è ciò che permette al modello da 20B di stare in circa 16 GB. È la base di partenza rispetto a cui TurboQuant-MLX si misura.

C’è poi un secondo consumo, spesso sottovalutato: la KV cache cresce con la lunghezza del contesto e, sui contesti lunghi, può pesare quanto o più dei pesi. Comprimere la cache, quindi, conta tanto quanto comprimere il modello.

Il metodo TurboQuant, in breve

TurboQuant è descritto in “Online Vector Quantization with Near-optimal Distortion Rate”, un preprint su arXiv (aprile 2025) di Amir Zandieh, Majid Daliri, Majid Hadian e Vahab Mirrokni, ricercatori legati a Google Research (un coautore è alla NYU). È un preprint, non ancora una pubblicazione con revisione tra pari; il repo lo chiama “TurboQuant di Google”, ma sull’abstract arXiv le affiliazioni non compaiono, quindi è più corretto attribuirlo agli autori.

L’idea è elegante. Per quantizzare bene un vettore lo si ruota prima a caso: la rotazione rende le coordinate quasi indipendenti tra loro e le concentra in una distribuzione nota. A quel punto basta quantizzare ogni coordinata da sola, con un quantizzatore scalare ottimale, per avvicinarsi al limite teorico. Gli autori dimostrano che così la distorsione resta entro un piccolo fattore costante (circa 2,7 volte) dal minimo possibile in teoria dell’informazione.

Due proprietà contano. Il metodo è data-oblivious (non serve un passaggio di calibrazione su dati) ed online (funziona su vettori che arrivano in streaming). Per questo l’applicazione naturale è la KV cache, che si genera token dopo token. C’è anche un dettaglio importante per l’attenzione, che dipende dai prodotti scalari: i quantizzatori ottimali per l’errore quadratico introducono un bias, così il paper aggiunge un secondo stadio, uno sketch a 1 bit sul residuo (una trasformata di Johnson-Lindenstrauss quantizzata) che rende non distorta la stima del prodotto scalare.

Le due applicazioni mostrate nel paper sono la compressione della KV cache per contesti lunghi e la ricerca per similarità (in sostituzione della product quantization). Sulla KV cache gli autori riportano neutralità qualitativa a 3,5 bit per canale e degrado marginale a 2,5 bit per canale (una misura uniforme per canale, non divisa tra chiavi e valori). Un punto da tenere fermo: la quantizzazione dei pesi non è trattata nel paper.

Cosa aggiunge turboquant-mlx

Il repo fa due cose oltre al porting su MLX. Primo, implementa la ricetta del paper come rotazione di Hadamard più codebook di Lloyd-Max: la trasformata di Hadamard è un modo veloce ed economico di realizzare la “rotazione casuale”, e Lloyd-Max è il classico quantizzatore scalare ottimale per il passo per-coordinata. Secondo, e qui sta il contributo proprio dell’autore, estende l’idea ai pesi del modello, non solo alla KV cache. Questa estensione è del progetto, non del paper.

Nel dettaglio, per come lo descrive il repo:

• Pesi: quantizzati in fase di conversione (da modelli Hugging Face) a 2, 3 o 4 bit. Per i modelli Mixture of Experts (MoE) il repo aggiunge esperti ternari a 1,58 bit (codebook a tre valori) e schemi asimmetrici (esperti a precisione più bassa, proiezioni più delicate a bit più alti).
• KV cache: quantizzata a runtime e riportata a float16 solo quando l’attenzione la usa, passando per lo scaled dot-product attention standard di MLX. Il default consigliato è K8/V3 (chiavi a 8 bit, valori a 3 bit): una scelta del repo, distinta dai “bit per canale” del paper.
• Expert streaming: per i MoE, tenere in memoria solo gli esperti usati di recente e leggere gli altri dal disco su richiesta, così un modello che non entrerebbe in RAM può comunque girare, pagando in velocità.

Attorno c’è una toolchain a riga di comando: turboquant-plan per stimare la memoria prima ancora di scaricare, turboquant-convert per convertire i modelli, turboquant-generate per la generazione con i flag di compressione, turboquant-serve per un server API compatibile con OpenAI. Si installa con pip install turboquant-mlx-full e richiede macOS su Apple Silicon (da M1 in su), Python 3.10+, MLX e mlx-lm; per i modelli da 20B in su l’autore consiglia 64 GB di memoria unificata. Il repo dichiara supporto per architetture dense (LLaMA, Qwen, Mistral) e MoE (GPT-OSS, DeepSeek-V2/V3, Qwen-MoE, Nemotron-3), oltre a varianti ibride attenzione/Mamba: che ognuna funzioni davvero è, di nuovo, dichiarazione dell’autore. Va notato che il README descrive la parte “rotazione più codebook” ma non lo stadio dello sketch a 1 bit sul residuo, quindi quanto il progetto copra quella seconda metà del metodo non è esplicitato.

I numeri dichiarati

Tutti i numeri che seguono sono misure dell’autore, su hardware specifico e senza verifica indipendente. Vanno letti come ordini di grandezza. Le righe su macchine diverse non vanno sommate.

• Perplessità (più bassa è meglio): su Qwen2.5-7B l’autore riporta 8,92 con TurboQuant a 3 bit contro 13,37 con quantizzazione affine a 3 bit; su GPT-OSS-20B, 72,63 con TurboQuant a 4 bit contro 83,04 con MXFP4. Sono confronti singoli, un modello ciascuno, nel benchmark dell’autore.
• Memoria e velocità (su M4 Max): GPT-OSS-20B a 3 bit in 9,3 GB a 73 token/s; GPT-OSS-120B a 3 bit in 48 GB a 44 token/s, che secondo l’autore entra con il contesto pieno da 131K token in circa 50 GB su un MacBook da 64 GB; Qwen3.5-122B passa da circa 240 GB in BF16 a circa 50 GB a 3 bit, a 26,5 token/s.
• KV cache: su GPT-OSS-120B con pesi a 3 bit, l’autore misura la cache a 3 bit più veloce di quella a FP16 (8,7 contro 6,4 token/s) con circa 3,8 volte di risparmio di memoria della cache. Sulla qualità riferisce una similarità coseno di 0,983 a 3 bit e 0,995 a 4 bit rispetto a FP16. Su Qwen3.5-122B riporta un output che nel suo test descrive come indistinguibile da FP16.
• Expert streaming (Mac mini da 16 GB): su Qwen3.6-35B-A3B, con un budget di cache di 8 GB, l’autore riporta il 91% di esperti già in memoria e circa 4,5 token/s, girando in meno di 4 GB di RAM grazie allo streaming.

Danno l’idea di cosa sia oggi possibile su un Mac, ma restano una fonte sola: la qualità di un modello quantizzato in modo aggressivo va misurata sul proprio caso d’uso.

Soluzioni simili

turboquant-mlx non è l’unico modo di far girare modelli grandi in locale. Su Apple Silicon, mlx-lm ha già una sua quantizzazione; fuori dal mondo Apple ci sono llama.cpp con i formati GGUF e metodi di quantizzazione dei pesi come AWQ e GPTQ. Per i MoE che non entrano in una GPU, l’offloading degli esperti in RAM è la strada di KTransformers. Del metodo TurboQuant, inoltre, esistono anche altre implementazioni oltre a questa per MLX. La particolarità di turboquant-mlx è mettere insieme, in un pacchetto pensato per Apple Silicon, quantizzazione dei pesi molto spinta, esperti ternari e compressione della KV cache.

Cosa ne pensiamo

Il filo che ci interessa è quello di sempre: quando l’inferenza tocca dati o processi che non ci si può permettere di mandare fuori, conviene poterla eseguire in casa, su hardware proprio, con pesi che si possono ospitare. La quantizzazione è la leva che rende praticabile questa strada, perché decide se un modello open-weight entra o no nella memoria che si ha a disposizione. Un progetto come turboquant-mlx mostra due cose utili: che lo stack di inferenza locale su Apple Silicon (MLX, mlx-lm e gli strumenti attorno) sta maturando in fretta e che la ricerca sulla quantizzazione, KV cache inclusa, arriva in mani pratiche nel giro di poche settimane.

Serve però prudenza. I numeri sono di una sola fonte, su hardware specifico, e “indistinguibile da FP16” su un test non è “indistinguibile” sul vostro carico: la qualità a 2 o 3 bit, con esperti a 1,58 bit, va verificata sul caso d’uso reale prima di fidarsene. Ed è bene tenere separate due cose che il repo unisce: da un lato il metodo TurboQuant, pubblicato come preprint e pensato per KV cache e ricerca vettoriale; dall’altro la sua estensione ai pesi, che è un contributo del progetto e non del paper. Per chi valuta l’inferenza on-premise è un tassello interessante da provare e misurare, non una promessa da mettere in produzione al buio.

Riferimenti

• TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate (arXiv:2504.19874)
• TurboQuant su Hugging Face Papers
• turboquant-mlx (manjunathshiva) su GitHub
• MLX, il framework di Apple (open source)
• OpenAI: introducing GPT-OSS (modelli open-weight)
• Hugging Face: quantizzazione MXFP4

Collegato: KTransformers: far girare un MoE da 671B su una singola GPU.