Da quando i Large Language Models (LLM) hanno iniziato a essere eseguiti localmente, il confine tra VRAM disponibile e spazio su disco ha tracciato la linea tra un’inference ancora fruibile e un’attesa insostenibile. In community come quella di LocalLLaMA, il “disk spillover” — il momento in cui il modello supera la memoria video e comincia a usare la RAM di sistema o il disco — è sempre stato un punto di non ritorno: si passava da 4-5 token al secondo a circa 0,5 token al secondo. Ora, con l’arrivo di una serie di booster per l’inference — dSpark, dFlash, Multi-Token Prediction (MTP), Quantization-Aware Training (QAT) e altri — ci si chiede se quel crollo sia diventato meno ripido.

Queste tecniche, che spaziano dal speculative decoding alle varianti di FlashAttention, dalla generazione multi-token alla quantization consapevole, accelerano l’inference in condizioni ottimali, riducendo il numero di operazioni necessarie o l’occupazione di memoria. Ma il vero test si gioca proprio quando la VRAM finisce. E qui il responso non lascia molto spazio all’ottimismo: il collo di bottiglia si sposta, ma non scompare. Il disco, anche NVMe, ha latenze e bandwidth di ordini di grandezza inferiori rispetto alla VRAM: nessuna ottimizzazione sul compute può compensare un caricamento lento dei pesi. Lo spillover resta un dramma prestazionale.

Tuttavia, l’asticella della frustrazione si sta muovendo. Tecniche come QAT e dFlash possono ridurre l’impronta di memoria e ritardare il momento dello spillover, permettendo magari di eseguire modelli più grandi senza toccare il disco. E quando lo spillover avviene, alcuni utenti riportano incrementi marginali — da 0,5 a 0,7-0,8 token/s — ancora lontani dall’essere accettabili per un chatbot interattivo, ma sufficienti a far nascere domande come quella apparsa su Reddit: “Stiamo diventando tolleranti?”. Il solo fatto che la domanda venga posta segnala un cambio di percezione, frutto di miglioramenti incrementali che, pur non rivoluzionando l’hardware, allargano di qualche centimetro lo spazio di manovra.

Per chi pianifica deployment on-premise, il messaggio è duplice. Le ottimizzazioni software possono estendere la vita di una GPU con VRAM limitata, ma non trasformano un asset sottodimensionato in una macchina performante. L’hardware resta il fondamento. Sapere che con QAT e dFlash si risparmiano qualche gigabyte e lo spillover arriva più tardi è un dato utile per chi valuta il Total Cost of Ownership (TCO), ma non ribalta i rapporti di forza. Il costo di una GPU con più VRAM va soppesato con la garanzia di un’esperienza utente prevedibile, senza la spada di Damocle di un calo a singola cifra di token al secondo. In quest’ottica, i framework analitici per il deployment on-premise aiutano a navigare i trade-off, ricordando che il TCO non si misura solo in velocità di picco, ma anche nella stabilità percepita.

La direzione tecnica è promettente — speculative decoding, tensor parallelism e distribuzione su più GPU potrebbero un giorno relegare il disco a ruolo di backup remoto. Ma oggi chi fa inference locale farebbe bene a considerare queste accelerazioni come un cuscinetto prezioso, non come la rampa di lancio che cancella il bisogno di VRAM.