Il messaggio suona familiare a tanti amministratori di sistema: un nodo GPU, acquistato anni fa per carichi di lavoro ormai superati, giace quasi inutilizzato in un angolo del data center aziendale. È quello che è successo a un tecnico che ha condiviso la sua esperienza su Reddit: il suo datore di lavoro possiede un server con otto NVIDIA Framework RTX 6000, 192 GB di VRAM complessivi, 512 GB di RAM di sistema e circa 112 thread CPU. La domanda sorge spontanea: anziché spegnerlo, possiamo riutilizzarlo per far girare modelli linguistici di grandi dimensioni in locale, facendo cose che una singola scheda non può fare?

La matematica della VRAM: modelli grandi e inference distribuita

Il primo fattore da considerare in uno scenario del genere è la capacità di memoria video. Oggi i modelli linguistici più capaci, come Llama 3 70B o Mixtral 8x22B, richiedono in precisione FP16 rispettivamente circa 140 e 150 GB di VRAM solo per caricare i pesi del modello. Su una singola scheda con al massimo 48 o 80 GB, è impossibile. Con otto Framework RTX 6000 (24 GB l’una), invece, il totale di 192 GB permette di distribuire il modello tra le GPU usando tecniche di parallelismo a tensori o a pipeline, proprio come farebbe un sistema cloud multi-GPU. In più, resta margine per la cache chiave-valore (KV cache) necessaria a gestire sequenze di testo lunghe, elemento critico quando si vogliono finestre di contesto superiori a 32K token. Con gli strumenti giusti – vLLM, TensorRT-LLM, o LMDeploy – è possibile ottenere una latenza accettabile sfruttando l’interconnessione NVLink (tipicamente presente in nodi di questo tipo) per comunicazioni a bassa latenza tra GPU.

Non solo memoria: il ruolo della quantization e delle architetture Turing

I chip Turing delle Framework RTX 6000 non offrono accelerazione per formati più recenti come l’FP8, ma gestiscono egregiamente l’integer a 8 bit (INT8). Ciò significa che applicando la Quantization a 8 bit – o addirittura a 4 bit con tecniche come GPTQ o AWQ – si può ridurre ulteriormente il footprint di memoria, consentendo di eseguire modelli ancora più grandi (persino un Llama 3 405B con Quantization a 4 bit potrebbe entrare nei 192 GB, anche se con margini risicati) o di dedicare più VRAM alla gestione di contesti estesi. In termini di throughput, queste GPU non competono con le moderne A100 o H100, ma per batch di inference a bassa concorrenza – ad esempio un servizio interno all’azienda per analisi documentale – le prestazioni sono più che sufficienti.

Il valore strategico di un deployment on-premise

Al di là dei numeri, la conversazione con il capo può poggiare su argomenti solidi: sovranità dei dati, controllo sulla latenza, assenza di costi ricorrenti di cloud. Una macchina già ammortizzata azzera il CapEx e riduce il TCO a spese di energia e manutenzione. In settori come finanza, sanità o manifatturiero, dove i dati non possono uscire dal perimetro aziendale, poter eseguire LLM in self-hosted rappresenta un vantaggio competitivo e normativo. L’Inference locale evita i rischi di esposizione a terze parti e consente di costruire pipeline di retrieval-augmented generation (RAG) su documenti interni senza timori di compliance.

Quali carichi di lavoro concreti?

Con otto GPU a disposizione, non si è vincolati a un solo modello. Grazie a tecniche di multi-tenancy e al supporto di framework come Ray o il serving distribuito di vLLM, si possono partizionare le risorse per eseguire contemporaneamente più modelli più piccoli, oppure dedicare alcune GPU a un LLM pesante e le restanti a un modello di embedding per un pipeline RAG completa. Per un team IT, questo significa offrire servizi di intelligenza artificiale generativa interni, dalla classificazione di email alla generazione di report, senza aprire una connessione verso API esterne.

La prospettiva: non sprecare ciò che hai

Il caso riportato su Reddit è emblematico di una tendenza più ampia: molte organizzazioni scoprono che l’hardware già presente nei loro data center può diventare la base per una strategia di AI on-premise, a patto di abbinarvi gli strati software e le competenze operative necessarie. In un’epoca in cui tutti guardano al cloud, rivalutare quel vecchio nodo multi-GPU potrebbe essere non solo una scelta ecologica, ma anche la mossa più intelligente per mantenere il controllo su missioni critiche. Come sempre, per chi valuta un deployment on-premise, esistono trade-off tra semplicità operativa e personalizzazione, ma il punto di partenza – 192 GB di VRAM pronti all’uso – non è affatto male.