Il numero KLD è diventato una specie di punteggio sacro in alcune discussioni sui modelli quantizzati. Su Reddit, molti lo trattano come un parametro capace di ordinare ogni LLM quantizzato in una classifica di qualità. Ma la sigla misura qualcosa di molto più stretto: la divergenza tra le distribuzioni di probabilità prodotte dai logit del modello base e di quello quantizzato, calcolata token per token e poi mediata. Non è una valutazione della bontà del modello sui compiti reali.

La prima crepa è il dataset. Se si calcola la KLD su testi casuali, per esempio articoli di Wikipedia, si ottiene un numero che non rappresenta ciò che accade davvero durante l'inference. Quando un modello genera, una parte crescente del contesto è fatta di token prodotti dal modello stesso, non di testo esterno. Per avere un valore più sensato bisognerebbe generare un dataset con il modello base e calcolare la divergenza solo sui token generati, azzerando il peso dei token del prompt. Questo ribalta la prassi più diffusa.

La seconda crepa è ancora più rilevante per chi valuta modelli quantizzati on-premise. I metodi di quantization usano spesso dati di calibrazione. Se la KLD viene calcolata sugli stessi dati usati per calibrare, i numeri risultano artificialmente migliori. Anche un dataset dichiarato separato non basta: se calibrazione e valutazione provengono dalla stessa sorgente o hanno distribuzioni simili, la divergenza resta gonfiata. Alcuni team spingono il fine-tuning dei parametri di scala della quantization proprio su quei dati, ottenendo KLD molto basse su modelli che poi faticano a generalizzare.

Qui sta il nodo strutturale. Gonfiare i benchmark richiede hardware, tempo e compute; manipolare la KLD può essere molto più economico. Questo cambia gli incentivi per chi pubblica modelli quantizzati: un numero basso di KLD si ottiene con pochi accorgimenti, mentre un benchmark robusto costa caro. Il risultato è che la KLD dichiarata dai vendor sta perdendo valore segnaletico. Per chi fa deployment self-hosted, dove la quantization serve a ridurre la VRAM necessaria e a contenere il costo complessivo, il rischio è di selezionare un modello su una metrica che non predice il comportamento reale.

Questo non rende la KLD inutile: resta uno strumento diagnostico per capire quanto la quantization ha alterato le distribuzioni del modello base su un dataset limitato. Ma non è una classifica universale. Un valore più alto non implica che il modello fallirà nei compiti dell'utente, così come un valore basso non garantisce qualità. La valutazione on-premise deve confrontare la KLD con test su task reali e verificare la separazione effettiva tra dati di calibrazione e dati di valutazione. Senza questa igiene, il numero che circola su Reddit è più rumore che segnale.