🤖 machine learning

XFP: Quality-Targeted Adaptive Codebook Quantization with Sparse Outlier Separation for LLM Inference

XFP è un metodo dinamico e privo di calibrazione per la quantizzazione dei pesi nell'inferenza di LLM che determina automaticamente i parametri del codebook in base a soglie di qualità specificate dall'utente, separando efficacemente gli outlier sparsi per ottenere elevata velocità di elaborazione e accuratezza, consentendo al contempo a modelli massicci di rientrare in memoria limitata grazie alla sua iterazione "H-Process" guidata dalla qualità.

Autori originali: Thomas Witt

Pubblicato 2026-05-15

📖 4 min di lettura☕ Lettura da pausa caffè

CC BY 4.0

Autori originali: Thomas Witt

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di dover inserire un enorme castello di Lego con 397 miliardi di pezzi (un gigantesco modello di intelligenza artificiale) in uno zaino piccolo (un computer workstation standard).

Normalmente, per far entrare il castello, si cerca di frantumare i mattoncini in polvere minuscola e uniforme (compressione standard). Ma questo rovina il castello; i dettagli diventano sfocati e l'IA inizia a commettere errori.

XFP è un nuovo modo più intelligente per impacchettare quel castello. Invece di frantumare tutto, utilizza un approccio "Qualità Prima". Ecco come funziona, usando analogie semplici:

1. Il "Pavimento di Qualità" invece della "Larghezza in Bit"

Nel vecchio metodo, dici al computer: "Impacchetta questo in 4 bit per mattone." Il computer fa del suo meglio, ma se i mattoni hanno forme strane, il risultato è scadente.

XFP inverte la logica. Dici al computer: "Ho bisogno che il castello assomigli almeno al 96% all'originale."
Il computer poi risolve il resto da solo. Si chiede: "Ok, per mantenere il 96% di qualità, quanti bit mi servono effettivamente per questa parte specifica?"

Per alcune parti, potrebbe aver bisogno solo di 2 bit.
Per altre parti, potrebbe aver bisogno di 4 bit.
Non impone una regola unica per tutti.

2. Il problema degli "Outlier" (I Mattoni Giganti)

Immagina che nel tuo castello di Lego, il 99% dei mattoni sia piccolo e normale, ma l'1% sia formato da mattoni giganti, pesanti e dalla forma strana.

Metodo Vecchio: Cerchi di schiacciare i mattoni giganti per farli entrare nella scatola piccola. Questo distorce l'intera scatola, rendendo brutti anche i mattoni piccoli.
Metodo XFP: Dice: "Prendiamo quei mattoni giganti e strani e mettili in una tasca speciale e separata."
- La Tasca Speciale contiene i mattoni giganti nella loro forma originale ad alta qualità (usando un po' più di spazio, ma solo per i pochi che ne hanno bisogno).
- La Scatola Principale contiene solo il 99% dei mattoni normali, che ora sono facili da comprimere perché sono tutti simili.

3. Il "Dizionario Personalizzato" (Il Codice)

Invece di usare un dizionario standard dove ogni parola ha la stessa lunghezza, XFP impara un dizionario personalizzato per ogni singolo strato dell'IA.

Esamina i mattoni in una stanza specifica del castello e impara esattamente quali forme appaiono più spesso.
Crea un piccolo elenco (un "codebook") contenente solo quelle forme.
Poi, invece di memorizzare l'intero mattone, memorizza solo un piccolo numero (un indice) che punta a quella forma nell'elenco.
Poiché l'elenco è creato su misura per quella stanza specifica, è incredibilmente efficiente.

4. Le Due Regole (Rigorose vs. Lasche)

L'IA ha diversi tipi di stanze:

Le Stanze "Rigorose": (Come il meccanismo di attenzione, che presta attenzione ai dettagli). XFP è molto attento qui. Usa un dizionario di alta qualità e mantiene più mattoni giganti nella tasca speciale.
Le Stanze "Lasche": (Come gli "esperti instradati", che sono lavoratori specializzati). Queste stanze sono più flessibili. XFP usa qui un dizionario più piccolo e grezzo perché queste parti dell'IA possono tollerare di essere schiacciate di più senza rompersi.

Questo permette a XFP di risparmiare enormi quantità di spazio senza rovinare il cervello dell'IA.

5. Il "Processo H" (La Stretta Stretta)

Il documento descrive una sfida specifica: adattare un modello con 397 miliardi di parametri su due schede grafiche standard (che solitamente non possono contenerlo).

Hanno utilizzato un processo chiamato Processo H.
Pensalo come un gioco di "Riccioli d'Oro". Hanno continuato a regolare le regole "Rigorose" e "Lasche".
- Se rendevano le regole troppo rigide, il modello non entrava nello zaino (Out of Memory).
- Se rendevano le regole troppo lasche, l'IA iniziava a dire sciocchezze (Garbage Output).
Hanno trovato l'impostazione "Giusta" (chiamata H1.5) dove il modello entra perfettamente, gira velocemente e fornisce ancora buone risposte.

I Risultati

Velocità: Su un computer workstation di fascia alta, XFP è più veloce del 49% rispetto al miglior metodo standard attuale (Marlin INT4) per un modello da 122 miliardi di parametri.
Qualità: Mantiene l'intelligenza dell'IA quasi esattamente uguale alla versione originale non compressa.
Accessibilità: Permette ai ricercatori di eseguire modelli di IA massicci su computer desktop standard e potenti, senza bisogno di supercomputer costosi per data center.

In sintesi: XFP è un sistema di imballaggio intelligente che non forza tutto in una scatola uniforme. Separa gli oggetti strani e pesanti, impara dizionari personalizzati per il resto e ti permette di decidere quanto qualità vuoi mantenere, calcolando automaticamente il modo più efficiente per farci stare tutto.

Riepilogo Tecnico: XFP – Quantizzazione Adattiva del Codice con Obiettivo di Qualità

1. Enunciato del Problema

Il documento affronta i limiti delle attuali strategie di quantizzazione per i Modelli Linguistici di Grandi Dimensioni (LLM) quando si distribuiscono modelli Mixture-of-Experts (MoE) massicci su hardware di classe workstation (ad esempio, NVIDIA RTX PRO 6000 Blackwell). Gli autori identificano tre problemi strutturali negli approcci esistenti:

Il Problema degli Outlier: Le matrici dei pesi dei Transformer presentano distribuzioni a coda pesante. La quantizzazione lineare uniforme (INT-N) o i codebook logaritmici fissi (come NVFP4) devono accommodare outlier estremi, costringendo a un singolo fattore di scala che degrada la risoluzione per il blocco centrale denso dei pesi.
Il Problema dell'Eterogeneità MoE: I diversi componenti all'interno dei modelli MoE (attenzione, esperti condivisi, esperti instradati) possiedono distribuzioni dei pesi distinte. Gli esperti instradati sono empiricamente più tolleranti alla quantizzazione grossolana rispetto ai livelli di attenzione. Un unico limite di qualità globale o larghezza in bit non riesce a sfruttare questa asimmetria.
Il Problema dello Storage del Codebook: I codebook appresi per canale consumano una memoria condivisa (SMEM) significativa sulle GPU. Sulle GPU di classe workstation (99 KB SMEM/CTA), ciò limita la dimensione della cache delle righe di attivazione, costringendo a operazioni "split-K" che aumentano la latenza e limitando la dimensione massima del modello distribuibile in un singolo flusso.

Inoltre, il documento nota che, sebbene il formato NVFP4 di NVIDIA offra throughput accelerato dall'hardware sui chip Blackwell dei data center (SM100+), questo percorso non è disponibile o è incompleto sull'hardware workstation (SM120/121), lasciando gli operatori con formati che ignorano le distribuzioni specifiche dei pesi.

2. Metodologia: Il Framework XFP

XFP inverte il flusso di lavoro di quantizzazione convenzionale. Invece che l'operatore selezioni una larghezza in bit target e accetti la conseguente perdita di qualità, l'operatore specifica limiti di qualità di ricostruzione basati sulla similarità coseno per canale. XFP determina quindi automaticamente la dimensione del codebook necessaria, il budget degli outlier e la strategia di packing per ogni livello.

Meccanismi Principali

Separazione Sparsa degli Outlier:
I pesi sono decomposti in un residuo ad alta precisione sparso e un blocco denso.
- Gli outlier sono definiti come pesi dove $|w - \mu| > k\sigma$ (default $k=4.0$ , limitato al 2% dei pesi).
- Questi outlier sono memorizzati come una matrice fp16 sparsa nelle loro posizioni originali.
- I restanti pesi del "blocco" sono sostituiti dalla loro media di gruppo e quantizzati.
Codebook Appresi Adattivi:
La distribuzione del blocco è quantizzata utilizzando un codebook appreso per gruppo tramite iterazione di Lloyd.
- Modalità V2 (Per Canale): Memorizza un codebook fp16 indipendente per canale di output. Supporta larghezze in bit $N \in \{2, 3, 4, 5, 6\}$ .
- Modalità V2a (Libreria Condivisa): Memorizza una piccola libreria di $L$ codebook (default $L=32$ ) per livello. Ogni gruppo di pesi viene assegnato alla voce della libreria che meglio si adatta. Ciò riduce l'uso di SMEM da $O(\text{output\_dim})$ a una costante di $\sim 1$ KB, abilitando finestre di contesto più ampie sulle GPU workstation.
Selezione Automatica con Obiettivo di Qualità (Due Soglie):
Il sistema utilizza due distinte soglie di similarità coseno per guidare la selezione della larghezza in bit:
- Soglia Rigida ( $\tau_{strict}$ ): Applicata alle proiezioni di attenzione e agli esperti condivisi.
- Soglia Lasca ( $\tau_{lazy}$ ): Applicata ai percorsi MoE degli esperti instradati.
- L'algoritmo itera attraverso le larghezze in bit candidate ( $N$ ) e seleziona il minimo $N$ che soddisfa la soglia rilevante. Ciò permette agli esperti instradati di utilizzare una quantizzazione più grossolana (ad esempio, $N=2$ ) mentre i livelli di attenzione utilizzano una quantizzazione più fine (ad esempio, $N=4$ ) senza intervento manuale.
Kernel di Decodifica Fuso:
Un kernel personalizzato fonde quattro operazioni: depacking degli indici, gathering dal codebook, scattering degli outlier sparsi ed esecuzione del GEMM. Opera nativamente in bf16 e memorizza nella cache le righe di attivazione in SMEM per minimizzare l'uso della banda di memoria globale.

3. Contributi Chiave

Il documento delinea tre contributi principali:

(C1) Il Quantizzatore XFP: Un quantizzatore dinamico e orientato alla qualità che converge a larghezze in bit efficaci di $\sim 3.97$ su Qwen3.5-122B e $\sim 3.4$ su Qwen3.5-397B sotto il "Processo H" (un'iterazione di compressione vincolata). Non richiede calcolo dell'Hessiano, dati di calibrazione o selezione manuale della larghezza in bit.
(C2) Modalità di Storage Duali con Motore Unificato: Due modalità di storage (V2 e V2a) condividono un unico frontend di selezione automatica e un kernel di decodifica fuso. Questo copre l'intervallo di parametri da 30B a 397B sulle GPU workstation senza fare affidamento sui Tensor Core NVFP4.
(C3) Il Processo H: Un'iterazione guidata dalla qualità sulle due soglie di coseno che adatta con successo il modello Qwen3.5-A17B da 397B (512 esperti instradati/layer) in 2×96 GB di VRAM. Raggiunge questo risultato a $\sim 3.4$ bit efficaci mantenendo l'intera popolazione di esperti, evitando la necessità di pruning degli esperti.

4. Risultati Sperimentali

Gli esperimenti sono stati condotti su hardware di classe workstation (RTX PRO 6000 Blackwell, DGX Spark) utilizzando i modelli Qwen3.5 e GLM-4.7-Flash.

Qwen3.5-122B-A10B (Modalità V2):
- Ha raggiunto 138 token/s di decodifica in singolo flusso su TP=2.
- 49% più veloce di Marlin INT4 (AutoRound) a TP=1.
- Ha mantenuto il 94.49% di corrispondenza esatta GSM8K (3 semi), comparabile ai baseline a 4 bit.
- Larghezza in bit efficace: $\sim 3.97$ .
Qwen3.5-397B-A17B (Processo H, Modalità V2):
- Distribuito con successo su 2×96 GB di GPU.
- Ha raggiunto 100.9 token/s su decodifica con output lunghi.
- Ha raggiunto il 66.72% di corrispondenza esatta GSM8K sull'intero set di 1.319 problemi (singolo seme).
- Larghezza in bit efficace: $\sim 3.4$ .
- Confronto con REAP (pruning degli esperti): XFP+H ha mantenuto tutti gli esperti e raggiunto una maggiore accuratezza (66.72% vs 33–44% per INT4 potati) con un footprint di memoria inferiore o comparabile.
Sonde Modalità V2a:
- Hanno dimostrato guadagni di throughput del +47% rispetto a Marlin INT4 su Qwen3.5-122B, validando l'approccio a libreria condivisa per scenari vincolati dalla memoria.

5. Significato e Affermazioni

Il documento posiziona XFP non semplicemente come un formato di quantizzazione, ma come un meccanismo per il deployment di classe appliance. Il suo significato risiede in:

Inversione del Flusso di Lavoro: Spostare il ruolo dell'operatore dalla selezione delle larghezze in bit alla definizione dei vincoli di qualità, permettendo al sistema di adattarsi automaticamente all'eterogeneità del modello.
Fattibilità Workstation: Abilitare il deployment di modelli MoE massicci (fino a 397B parametri) su hardware consumer/workstation (GPU da 96 GB) senza supporto specifico per Tensor Core dei data center (NVFP4) o pruning degli esperti.
Compressione Guidata dalla Qualità: Dimostrare che la "qualità" (similarità coseno) è una metrica di guida più efficace rispetto alle larghezze in bit fisse, in particolare per i modelli MoE dove i diversi componenti hanno tolleranze di quantizzazione molto diverse.
Agnosticismo Hardware: Fornire un vantaggio di throughput definito dal software su hardware dove i percorsi di quantizzazione dedicati (NVFP4) non sono disponibili o sono incompleti, superando i kernel INT4 più ottimizzati (Marlin) leggendo meno byte per token.

Gli autori affermano esplicitamente che il compromesso comporta un overhead del codebook per gruppo e iterazioni di Lloyd durante il tempo di codifica, che favoriscono XFP nel livello workstation per carichi di lavoro vincolati dalla memoria, sebbene la scelta rimanga una decisione di deployment piuttosto che una sentenza universale di benchmark.