Il post è un rant, ma fotografa una tensione precisa. Ogni giorno spunta una configurazione ottimizzata o un nuovo motore di inference che promette prestazioni eccellenti. Il problema arriva in fondo: funziona solo con NVFP4 o MXFP4. L'autore, su r/ROCm, lo sintetizza senza giri di parole: hai reso l'opzione più veloce ancora un po' più veloce, ma probabilmente l'output è compromesso e le allucinazioni arrivano da tutte le parti.

La distinzione che l'autore traccia è tra modelli grandi e modelli piccoli. Su un Large Language Model con miliardi di parametri, il 4-bit può ancora funzionare: la ridondanza interna assorbe parte del rumore introdotto dalla quantization. Dimenticare una ricetta di spaghetti alla bolognese non è un disastro operativo. Ma un modello denso e piccolo, quello che spesso gira su una singola GPU in un armadio o in un ambiente air-gapped, non ha lo stesso margine. Quando la precisione scende a FP4, il modello può produrre errori logici gravi: l'esempio del post è 1+1=3. In quel momento non stai più ottimizzando, stai sostituendo il modello con qualcosa che produce risposte veloci ma inaffidabili.

Questo dettaglio è importante per chi sceglie lo stack on-premise. ROCm, la piattaforma software aperta di AMD per il calcolo GPU su hardware locale, è diventata un terreno di sperimentazione per motori di inference alternativi. Molti progetti nascono per spremere più token al secondo da GPU con poca VRAM. La tentazione è comprensibile: se un formato a bassa precisione permette di caricare un modello più grande o di ridurre i costi energetici, il TCO sembra migliorare. Ma il TCO reale include anche il costo degli errori. Se il modello sbaglia un calcolo, estrae un dato in modo incoerente o genera codice con bug sottili, qualcuno dovrà verificare, correggere o rilanciare il lavoro. Quel costo operativo non compare nei benchmark di throughput.

C'è un effetto di secondo ordine meno visibile. La proliferazione di motori ottimizzati per FP4 sposta l'attenzione dalla qualità dell'output alla velocità pura. I numeri che circolano su forum e repository diventano il criterio di selezione, mentre l'accuratezza su compiti specifici resta in secondo piano. Chi perde sono i team che usano modelli piccoli per automazioni deterministiche, estrazione di dati o assistenza alla scrittura di codice: lì un errore non è un'allucinazione creativa, è un dato sbagliato che entra in una pipeline. Chi guadagna sono i progetti che riescono a mostrare incrementi marginali su schede consumer o datacenter e a farli sembrare progressi generali.

La lezione strutturale non è che FP4 sia da buttare. Su modelli grandi e task tolleranti, la compressione resta uno strumento utile per ridurre la VRAM necessaria e i consumi. Il punto è che la precisione numerica non è un dettaglio neutro: interagisce con la dimensione del modello e con la natura del compito. Per chi valuta deployment on-premise, questo significa che i benchmark di velocità vanno affiancati a test di affidabilità sul proprio caso d'uso. AI-RADAR dedica framework analitici su /llm-onpremise per valutare questi trade-off. La prossima volta che leggete di un motore di inference miracoloso, controllate prima il formato di quantization. Il diavolo sta nei bit.