L'intervento su Reddit era tanto laconico quanto rivelatore: «When you don't have a data center GPU». Un lamento – o forse un invito a non riempire il thread di nomi chilometrici di modelli fine-tuned – che fotografa un tratto comune a chi sperimenta con LLM self-hosted: la distanza siderale fra le risorse di un laboratorio enterprise e la scrivania di uno sviluppatore, un piccolo team o un'azienda che rivendica il controllo dei propri dati.

La domanda implicita, però, è tutt'altro che banale: quanto si può fare davvero quando manca una scheda da decine di gigabyte di VRAM e le pipeline di inference si scontrano con i limiti di hardware consumer?

Fuori dal data center: il panorama hardware reale

Il discorso ruota quasi sempre attorno alla memoria. Le GPU da data center (A100, H100, MI300X) offrono VRAM che va dagli 80 GB in su, banda passante nell'ordine dei terabyte al secondo e interconnessioni dedicate come NVLink. Il mondo consumer, invece, è dominato da GeForce RTX 3090/4090 con i loro 24 GB, oppure da soluzioni Apple Silicon che, grazie all'architettura unificata, possono raggiungere 128 GB di memoria condivisa (ma con una banda reale assai inferiore).

Questo divario plasma ogni decisione: un modello da 70 miliardi di parametri in FP16 occupa circa 140 GB solo per i pesi. L'approccio onesto, quando non si possiedono GPU enterprise, passa inevitabilmente per la quantization – INT8, INT4, persino 2-bit – e tecniche di offloading parziale su RAM di sistema e NVMe.

Framework come llama.cpp, Ollama, vLLM e TensorRT-LLM consentono di distribuire i carichi su più GPU consumer, ma con colli di bottiglia lato PCIe e latenze più elevate. Sul fronte CPU, le ultime istruzioni AVX-512 e AMX abilitano inference su Xeon di ultima generazione o su Apple M2 Ultra, con token al secondo che, pur lontani dalle GPU, diventano accettabili per applicazioni batch o chatbot a bassa concorrenza.

Il trade-off fra controllo e potenza di calcolo

Chi sceglie di restare on-premise senza hardware HPC lo fa quasi sempre per una ragione precisa: la sovranità. Dati sanitari, documenti legali, codice proprietario non possono lasciare i server aziendali, e il cloud – per quanto agnostico – introduce un vettore di rischio regolatorio e un costo operativo variabile difficile da prevedere.

L'analisi del TCO cambia radicalmente: una RTX 4090 costa meno di 2.000 euro e consuma circa 450 W in punta; una A100 da 80 GB ne costa quindici volte tanto e richiede un ecosistema di raffreddamento, alimentazione e gestione che ricade nell'infrastruttura di un CED. Per un carico di lavoro sporadico o per prototipi, il pareggio economico si raggiunge molto tardi. Tuttavia, si paga in termini di finestra di contesto ridotta, di fine-tuning limitato a PEFT/LoRA e di time-to-solution che dilata i cicli iterativi.

Questo trade-off non è lineare: un piccolo impianto consumer può gestire modelli da 7 a 13 miliardi di parametri quantizzati, sufficienti per RAG di documenti interni o assistenti di codice, ma diventa rapidamente un vicolo cieco se l'obiettivo è un LLM generalista da centinaia di miliardi di parametri o un training multi-nodo.

Quando il cloud diventa l'unica alternativa sensata

Esiste una soglia oltre la quale la molatura del ferro domestico frana sotto il peso di vincoli fisici. Per fine-tuning completo di modelli medio-grandi, o per inference a latenze inferiori ai 10 millisecondi su traffico sostenuto, il cloud – con GPU on-demand – resta la leva più pragmatica, soprattutto se si usano orchestration layer che astraggono l'infrastruttura e consentono il fallback locale per carichi ridotti.

L'architettura più flessibile, oggi, è quella ibrida: dati e modelli risiedono on-premise per le richieste a basso volume, mentre picchi di traffico o job di training vengono delegati a istanze cloud con GPU enterprise, con meccanismi stringenti di cancellazione dei dati al termine del processing. È una via che mitiga i rischi di lock-in e preserva la sovranità sul dato a riposo, ma richiede una governance matura dei flussi di rete e della gestione identitaria.

La prospettiva: ferro più democratico, software più furbo

Guardando avanti, la tendenza è chiara: da un lato le GPU consumer aumentano la VRAM (le RTX 5000 potrebbero portare 32-48 GB nel segmento appassionati), dall'altro la ricerca sulla sparsità, sul mixture-of-experts e sulla quantization dinamica sta riducendo la taglia minima per eseguire modelli capaci.

Nel frattempo, FPGA e NPU dedicate – integrate nei SoC mobile o in schede PCIe – stanno ritagliandosi una nicchia per inference a bassissimo consumo, anche se i framework di sviluppo restano meno maturi.

Il punto non è chiedersi se una GPU da data center serva in assoluto, ma mappare con precisione il proprio spazio di necessità: carico di lavoro, latenza accettabile, budget di potenza e volume di richieste. Quella mappa – non l'ultima scheda NVIDIA – è il vero asset decisionale. Non occorre l'ennesima risposta chilometrica con nomi di modelli esotici: bastano progettazione dei vincoli e una comprensione sobria degli strumenti a disposizione.