Come scegliere il modello open-source e l'hardware giusti

Distribuire un LLM privato inizia con due decisioni profondamente intrecciate: quale modello eseguire e su quale hardware eseguirlo. Sbagliare l'abbinamento e si sovra-spende su capacità inutilizzata o si sotto-fornisce la potenza di calcolo di cui il caso d'uso ha effettivamente bisogno. La buona notizia è che l'ecosistema open-source è maturato al punto in cui esiste un modello ben testato per quasi ogni budget e compito — se sai come abbinarli.

Parti dal caso d'uso, non dal benchmark

L'errore più comune nella selezione del modello è partire dai punteggi di benchmark piuttosto che dai requisiti del compito. Un modello che raggiunge risultati all'avanguardia su un benchmark di coding potrebbe essere eccessivo per riassumere i ticket di supporto e potrebbe introdurre una latenza che lo rende inadatto all'uso in tempo reale. Prima di scegliere la dimensione del modello, definisci il tuo caso d'uso con precisione: qual è la lunghezza media dell'input in token? Il compito richiede ragionamento multi-step o è principalmente classificazione ed estrazione? Quanti utenti concorrenti servirà il sistema? Qual è la latenza di risposta accettabile? Quali lingue deve gestire il modello con scioltezza? Queste domande limitano lo spazio di ricerca in modo molto più utile di qualsiasi classifica.

Livelli di dimensione del modello: 7–8B, 32–70B e 405B+

Il panorama dei modelli open-source si è consolidato attorno a tre livelli pratici di dimensione. I modelli nella fascia da 7–8 miliardi di parametri — come Mistral 7B, Llama 3.1 8B e Qwen2.5 7B — sono notevolmente capaci per compiti focalizzati: classificazione di documenti, estrazione, riassunto e risposta a domande in stile FAQ su un corpus di recupero. Girano comodamente su una singola GPU consumer o prosumer e offrono bassa latenza anche senza una pesante ottimizzazione. La fascia 32–70B — Llama 3.3 70B, Qwen2.5 32B, Mixtral 8x7B — è dove la qualità del ragionamento generale, la scioltezza multilingue e il rispetto delle istruzioni migliorano sostanzialmente. Questi modelli possono gestire compiti analitici complessi, contesti più lunghi e generazione più sfumata. Richiedono GPU di livello professionale ma rimangono accessibili per un deployment su singolo server. Oltre i 70B, modelli come Llama 3.1 405B offrono capacità di livello frontiera ma richiedono configurazioni multi-GPU e un'attenta pianificazione infrastrutturale; sono meglio riservati a casi d'uso in cui la qualità è il vincolo primario e il budget non lo è.

• Modelli 7–8B: ideali per compiti focalizzati ad alto throughput — classificazione, estrazione, RAG su dati strutturati. GPU singola, costo minimo.
• Modelli 32–70B: forte ragionamento generale, supporto multilingue, contesti più lunghi. GPU singola di fascia alta o piccolo nodo multi-GPU.
• Modelli 405B+: qualità di frontiera per i compiti più esigenti. Multi-GPU richiesta; pianificare attentamente l'infrastruttura.
• Le architetture mixture-of-experts (MoE) (es. Mixtral) possono offrire qualità di classe 70B a un costo più vicino a quello dei parametri attivi a 13B — vale la pena valutarle se il throughput è importante.

Abbinare modelli alle GPU: la VRAM è il vincolo vincolante

La VRAM della GPU è il vincolo principale che determina quali modelli puoi eseguire e a quale velocità. Un modello deve stare nella VRAM per l'inferenza — con margine aggiuntivo per la cache KV, che cresce con la lunghezza del contesto e la dimensione del batch. Come guida approssimativa: un modello 7–8B in precisione 16-bit richiede circa 14–16 GB di VRAM; un modello 32B ne ha bisogno di circa 64 GB; un modello 70B ne richiede circa 140 GB. Ecco perché una singola GPU da 24 GB (come la NVIDIA RTX 3090 o 4090) è la casa naturale per i modelli 7–8B, una scheda da 48 GB (RTX 6000 Ada) o A100/H100 da 80 GB copre la fascia 32–70B su una singola scheda, e qualsiasi cosa più grande richiede configurazioni multi-GPU con interconnessioni NVLink o InfiniBand.

Quantizzazione: andare oltre il budget VRAM

La quantizzazione riduce la precisione dei pesi del modello — dai float a 16 bit agli interi a 8 bit (INT8) o a 4 bit (GPTQ, AWQ, GGUF Q4) — riducendo drasticamente i requisiti di VRAM. Un modello 70B quantizzato a 4 bit può stare in circa 35–40 GB di VRAM, rendendolo accessibile su una configurazione dual GPU da 24 GB. Il compromesso in qualità dipende dal metodo di quantizzazione e dal compito: per la maggior parte dei casi d'uso in produzione, INT8 è quasi senza perdite, e una quantizzazione a 4 bit ben implementata preserva la maggior parte della qualità del modello per compiti non altamente sensibili a sottili errori di ragionamento. La quantizzazione non è un espediente — è una strategia di deployment di primo livello che Privonis usa abitualmente per massimizzare la capacità per euro di budget hardware.

La domanda giusta non è "quale modello è il migliore?" ma "quale modello è sufficiente per questo compito, con il budget hardware che abbiamo?" La quantizzazione colma il divario tra le due risposte più di quanto la maggior parte dei team si aspetti.

Benchmark prima di comprare: l'approccio evaluation-first

Nessun benchmark sostituisce la valutazione di un modello sui propri dati e compiti reali. Prima di impegnarsi nell'hardware, Privonis raccomanda di eseguire una valutazione strutturata: definisci un insieme rappresentativo di input dal tuo caso d'uso in produzione, stabilisci criteri di qualità (accuratezza, aderenza al formato, latenza alla dimensione del batch target) e testa due o tre modelli candidati su istanze GPU cloud noleggiate. Questo costa poche centinaia di euro e richiede tipicamente un giorno o due. Il risultato è una specifica hardware basata su evidenze anziché su supposizioni — e spesso rivela che un modello più piccolo e veloce soddisfa le tue esigenze, risparmiando significativa spesa in conto capitale.

• Definisci gli input di valutazione dai dati reali di produzione prima di scegliere un modello.
• Testa prima su capacità GPU noleggiata — istanze cloud per la valutazione, on-premise per la produzione.
• Misura ciò che conta: accuratezza del compito, latenza p95, token al secondo alla dimensione del batch prevista.
• Considera il fine-tuning di un modello più piccolo prima di scalare a uno più grande — un 7B fine-tuned spesso supera un 70B generico su compiti ristretti.
• Pianifica per la cache KV: i contesti più lunghi consumano VRAM rapidamente; esegui benchmark alla massima lunghezza di contesto prevista.

Come Privonis guida il processo di selezione

Scegliere la giusta combinazione di modello e hardware è una delle decisioni a più alta leva in un deployment AI privato. Uno stack ben abbinato fornisce la qualità necessaria a un costo che rende chiaro il business case; uno mal abbinato sovra-spende su calcolo inattivo o sotto-performa su compiti importanti. Privonis porta esperienza pratica nella selezione, quantizzazione, fine-tuning e benchmarking di LLM open-source attraverso una gamma di casi d'uso enterprise europei. Ti aiutiamo a evitare il ciclo costoso di tentativi ed errori e ad arrivare a una configurazione di deployment che è dimensionata correttamente fin dall'inizio — e che rimane manutenibile man mano che i modelli e i tuoi casi d'uso evolvono.