Quando un modello gira in locale, la qualità percepita non dipende solo dai pesi principali. Un esperimento sul subreddit LocalLLaMA ha messo in luce un anello debole spesso ignorato: la tabella n-gram, chiamata PLE, che Qwen 3.8 Flash Next usa per l’inference e che nelle distribuzioni GGUF più comuni viene quantizzata in modo aggressivo.

L’utente sillynoobhorse, partendo da un’osservazione di MarkoMarjamaa e dal suggerimento di Eyelbee sull’uso del sidecar bf16, ha costruito un sidecar FP8 completo usando lo script ple_fp8_pack.py. Ha mantenuto il modello principale in IQ3_S ma ha sostituito il PLE incluso, quantizzato a IQ4_NL, con la versione completa in FP8. Il risultato, secondo il suo resoconto, è un miglioramento visibile: meno errori nei modelli 3D generati in HTML, meno facce mancanti e la possibilità di aggiungere funzionalità a un’app KDE tramite un agente Hermes. Nessun impatto sulla velocità di inference, solo una maggiore occupazione di spazio su disco.

Il punto non è che serva sempre il PLE completo. È che la quantization non è un interruttore unico: componenti diversi dello stesso modello tollerano livelli diversi di compressione. Il PLE è una tabella di n-gram residente su SSD, non occupa VRAM. Comprimerla aggressivamente riduce le dimensioni del file, ma può degradare l’accuratezza senza offrire benefici in termini di memoria o velocità. In uno scenario self-hosted il disco è spesso abbondante rispetto alla VRAM. L’asimmetria — modello principale compresso, sidecar ad alta precisione — sfrutta quindi il vincolo reale: la VRAM, non lo storage.

Questo ha implicazioni per chi scarica GGUF preconfezionati. I distributori tendono a ridurre le dimensioni dei file perché download più piccoli sono vantaggiosi per la distribuzione. Chi non scava nei dettagli tecnici ottiene un modello che potrebbe commettere più errori, mentre chi ricostruisce il sidecar ottiene qualità migliore a parità di VRAM. La barriera non è di calcolo, ma di competenza e banda: servono i file safetensors originali e circa 47 GB per il sidecar FP8 completo.

Strutturalmente, l’episodio segnala che i formati di distribuzione per LLM locali stanno diventando più complessi. Il modello non è più un singolo blob, ma un assemblaggio di componenti con profili di precisione differenti. Gli strumenti di packing e serving devono iniziare a trattare questi componenti separatamente, consentendo politiche di quantization differenziata. Per chi valuta deployment on-premise, il trade-off non è più solo tra modello grande e modello piccolo, ma tra quantization uniforme e quantization selettiva. AI-RADAR offre framework analitici su /llm-onpremise per chi vuole valutare questi trade-off senza semplificazioni.

Il post non fornisce benchmark rigorosi, ma i confronti visivi tra scene HTML e l’esperienza con l’agente sono sufficienti a giustificare un test. Alla fine, la domanda iniziale — perché non usare la tabella n-gram completa — ha una risposta pratica: si può, e in molti contesti locali conviene.