La domanda arriva da chi ha già scelto la strada dell’inference locale, ma si ritrova a navigare un panorama dove le classifiche abbondano e le risposte scarseggiano. Un utente su Reddit, con abbastanza VRAM per flirtare con modelli della classe GLM-5.2, cerca una mappa che metta fianco a fianco LLM proprietari e open-weight, non su punteggi accademici ma sulla reale convenienza di eseguirli su hardware proprio. Il dilemma è concreto ed è lo stesso che attanaglia i team IT di mezza industria: servono davvero quei colossi da 70 a 350 miliardi di parametri, o il salto di qualità percepito non ripaga la complessità?

La frammentazione delle classifiche

Chi cerca una classifica “closed vs open” si scontra subito con un muro. I benchmark popolari – Chatbot Arena, Open LLM Leaderboard, MMLU – sono pensati per confrontare modelli in condizioni astratte, spesso tramite API pubbliche. Raramente integrano metriche come l’uso di VRAM in inference, la latenza su hardware consumer o il costo reale del self-hosted. Ne esce un framework che premia i modelli massicci, ottimizzati per il serving cloud con GPU di fascia enterprise, ma poco utile per chi deve far girare tutto su un server in azienda o in un laboratorio.
Il risultato è una domanda inevasa: qual è il miglior LLM open-weight che posso eseguire localmente senza svenarmi in GPU? E come si confronta davvero con un’alternativa closed via API, al netto di latenza, privacy e Total Cost of Ownership? Senza benchmark che simulino carichi on-premise – con quantization spinta, finestre di contesto lunghe e throughput misurato sul ferro reale – la scelta resta affidata all’istinto e ai racconti di altri utenti.

Modelli oversize: il mito del più è meglio

C’è poi la sensazione che la fascia 70B–350B sia “vuota”. L’utente cita Qwen3.6 27B e modelli della linea GLM come esempi di un’efficienza che sfida la legge dei parametri. L’intuizione non è campata in aria: molti addetti ai lavori osservano che, nel salto da 27B a 70B, il guadagno qualitativo raramente è proporzionale all’esplosione di VRAM e alla complessità di serving. Alcuni modelli da 350B richiedono quattro o più GPU collegate via NVLink solo per l’inference, ma se li si interroga su problemi di ragionamento medio-piccolo, la differenza con un 30B ben fatto può essere marginale.
Qui entra in gioco la quantization. Un modello 70B in FP16 può occupare oltre 140 GB di VRAM, ma portato a INT8 o INT4 diventa gestibile su hardware più modesto. Tuttavia, la degradazione delle performance non è lineare e dipende molto dall’architettura. Senza dati solidi su come i modelli si comportano dopo compressione, il confronto tra taglie diventa ancora più opaco.

L’on-premise come cartina di tornasole

Per chi valuta deployment on-premise, la questione non è solo tecnica ma anche economica e di sovranità. Un LLM chiuso via API può sembrare più comodo, ma introduce latenza di rete, costi ricorrenti e la necessità di spedire dati sensibili fuori dal perimetro aziendale. Al contrario, un modello self-hosted – purché la dimensione sia sostenibile – garantisce controllo, prevedibilità dei costi e rispetto di vincoli normativi come il GDPR.
AI-RADAR segue da vicino queste dinamiche, offrendo su /llm-onpremise framework analitici per decifrare i trade-off fra performance, TCO e compliance. Il punto non è se un modello closed sia meglio in assoluto, ma in quale contesto di deployment un open-weight diventa la scelta più razionale. E la risposta cambia radicalmente se si dispone di un server con 48 GB di VRAM o di un cluster con centinaia di GPU.

Oltre i benchmark: cosa conta davvero

La ricerca di una classifica universale rischia di essere una falsa pista. Il vero bisogno è un framework decisionale che ponderi il costo dell’hardware, la facilità di fine-tuning, il throughput in inference e la qualità percepita su task reali. Le esperienze di chi opera in autonomia – come l’utente che ha acceso il dibattito – diventano fonti preziose, perché svelano le fragilità di un mercato ancora in costruzione.