Per anni, i calcoli silenziosamente sbagliati in llama.cpp hanno fatto sì che le GPU Tesla P100, acquistabili oggi per circa 80 dollari, restituissero risultati peggiori del dovuto. La buona notizia: bastano tre righe di patch per riportare la fedeltà matematica a livelli quasi perfetti, senza alcun costo prestazionale.

Il problema, scovato da un ricercatore durante il confronto di benchmark tra una macchina quad-P100 e una RTX 3090, risiedeva in una scelta di ottimizzazione mai corretta per l'architettura sm_60. In pratica, il codice CUDA di llama.cpp conteneva un flag che attiva il calcolo in FP16 per le GPU dichiarate veloci in quella modalità. Le GTX serie 10 e le P40 (sm_61) ne erano esentate da tempo perché sprovviste di unità FP16 dedicate. La P100, ironia della sorte, ne è dotata — Nvidia l'aveva progettata per il calcolo scientifico — ma il flag la includeva, facendole eseguire matematica a precisione degradata che produceva una divergenza di Kullback-Leibler mediana di 0.0023 rispetto al riferimento FP32. Dopo la patch, lo stesso valore precipita a 0.000001, un miglioramento di oltre 2000 volte, e l'accordo sul token successivo sale dal 96,5% al 99,9%: in pratica, un errore ogni 29 token spariva del tutto.

Dal punto di vista delle prestazioni, il fix non introduce penalizzazioni. Il prefill è rimasto identico entro il margine di rumore, mentre il decode ha mostrato un incremento dell'1,4% circa. Il motivo è semplice: i carichi di inference reali su P100 sono vincolati dalla banda di memoria HBM2 (732 GB/s) e dalle operazioni GEMM, non dal percorso vettoriale FP16. Il percorso "veloce" non stava comprando nulla, se non imprecisione.

La scoperta ha implicazioni che vanno oltre la correzione di un bug. Sul mercato dell'usato, la P100 da 16 GB di HBM2 viene spesso scavalcata dalla P40, che pure ha solo GDDR5 a 346 GB/s, perché la seconda costa circa 300 dollari e la prima circa 80. Il prezzo più basso della P100 veniva interpretato come una conferma della sua inferiorità per i carichi LLM. Ora sappiamo che parte di quel divario era artificiale, generato da un errore software rimasto latente per anni. Per chi allestisce nodi di inference on-premise con budget ridotti, il rapporto costo-efficacia della P100 sale nettamente, rendendola una scelta improvvisamente competitiva per eseguire modelli quantizzati in contesti dove la sovranità dei dati e il controllo dell'infrastruttura contano.

La vicenda mette a nudo una dinamica nota ma spesso sottovalutata nell'ecosistema dei framework LLM open-source: i test approfonditi si concentrano sulle architetture più recenti (Volta, Ampere, Ada), mentre le GPU di precedente generazione, pur abbondanti sul mercato secondario, possono trascinarsi per anni difetti di precisione che alterano la qualità dell'output. Nel caso specifico, l'anomalia è stata isolata con l'aiuto di un agente automatizzato, a conferma che la verifica empirica su hardware reale — anche datato — è un complemento necessario alla fiducia nel software comunitario. L'autore ha verificato che altre architetture (sm_61, Volta e successive) non sono toccate dal problema; la domanda aperta è quante altre schede, in altre nicchie, stiano silenziosamente facendo conti sbagliati.

Per chi valuta deployment on-premise, il messaggio è duplice: una patch di tre linee può valere centinaia di dollari in hardware evitato, e la padronanza del proprio stack di inference — compreso il layer aritmetico — incide sulla fedeltà del modello tanto quanto la scelta della quantization. AI-RADAR offre strumenti analitici per orientarsi tra questi trade-off, ma l’insegnamento ultimo è che il controllo passa anche dalla verifica dei calcoli più basso-livello.