Sembra la domanda di un hobbista in un forum, ma in realtà tocca uno snodo cruciale per chiunque esegua LLM on-premise. Un utente di Reddit ha chiesto: qual è il prossimo modello dopo il fidato Qwen 3.6 27B? E, soprattutto, quanta VRAM serve? Dietro la curiosità c’è un problema che riguarda sistemisti, sviluppatori e responsabili IT alle prese con scenari reali di inference self-hosted.

Partiamo da un dato di fatto: un modello della classe dei 27–32 miliardi di parametri, se quantizzato in modo aggressivo (4 bit), può convivere con una GPU consumer dotata di 24 GB di VRAM. Qwen 3.6 27B stessa è un esempio: è probabile che chi la stia usando l’abbia messa in produzione su una scheda come la RTX 3090 o 4090, oppure su una workstation con A5000. Il salto verso la fascia successiva — i modelli da 70 miliardi di parametri, come le varianti più grandi delle famiglie Llama 3 o Qwen2.5 — rompe questo equilibrio. Anche in 4 bit, un 70B ha bisogno di 35–40 GB di VRAM solo per i pesi, a cui si aggiungono il contesto e l’overhead di esecuzione. Significa che non basta più una singola GPU consumer: servono configurazioni multi-GPU, con NVLink o senza, oppure il passaggio a hardware professionale (A100, H100, o workstation a 48 GB come la RTX 6000 Ada).

Ed è qui che si materializza la vera posta in gioco. La scelta del modello non è più soltanto una questione di benchmark o di preferenza personale. Diventa una decisione di infrastructure. Chi gestisce dati sensibili — uffici legali, aziende sanitarie, pubbliche amministrazioni — non può semplicemente deviare l’inference su un’API cloud per aggirare i limiti hardware: perderebbe il controllo sulla residenza dei dati, con le ovvie ripercussioni su GDPR e compliance. Per questi attori, il “prossimo upgrade” non è un nome di modello, ma un investimento calcolato in potenziamento della GPU farm on-premise.

C’è un’altra dimensione, spesso trascurata: il costo totale di possesso. Rimanere nel perimetro self-hosted con modelli più grandi significa affrontare CapEx più elevato (l’hardware) e, in certi casi, anche un incremento dell’OpEx (consumi energetici, raffreddamento, manutenzione). Alcuni team provano a differire il problema sfruttando architetture a mistura di esperti (MoE), che attivano solo un sottoinsieme dei parametri per ogni token. Ma anche questo approccio, per quanto efficiente nell’inference, impone requisiti minimi di VRAM per ospitare l’intero insieme di esperti, e non elimina le riflessioni sulla sovranità.

Il dibattito aperto dalla domanda su Reddit ci dice qualcosa di strutturale: la forbice tra le dimensioni dei modelli open-weight e le capacità delle GPU consumer si sta allargando. Fino a un anno fa, un singolo top di gamma consumer bastava per far girare in locale modelli capaci di competere con le offerte cloud di fascia media. Oggi, per replicare la stessa esperienza con i modelli della generazione successiva, si deve per forza considerare un setup multi-GPU, con tutto ciò che comporta in termini di complessità di gestione e costi. È un segnale che la diffusione capillare dell’AI self-hosted potrebbe presto dipendere non solo dalla qualità del software — framework di serving, quantization, ottimizzazione del runtime — ma anche da quanto il mercato hardware saprà colmare quel divario.

Il nostro consiglio spassionato a chi si trova nella stessa situazione? Prima di studiare i benchmark di un nuovo LLM, guardate la VRAM. Poi guardate il budget. E infine domandatevi se la vostra architettura on-premise sia pronta a sostenere il passo successivo, perché la risposta non sarà mai solo un nome di modello. Sarà una scelta di sovranità digitale.