LLM in locale: le 6 domande prima dell'hardware

Sei domande che vengono prima dell’hardware e che decidono tutto: dalla VRAM al raffreddamento, fino a cosa potrai fare davvero il giorno in cui accendi la macchina.

Portare un LLM in locale nel 2026 non è più un esperimento da laboratorio. Studi legali che non possono caricare contratti su cloud esteri, aziende sanitarie vincolate dal GDPR, software house che rifiutano di pagare il token di OpenAI ogni volta che un cliente usa il loro prodotto, pubbliche amministrazioni che devono restare sovrane sui propri dati: tutti, in modi diversi, stanno spostando l’inferenza dei modelli linguistici dentro le proprie mura.

La tentazione, davanti a questo bisogno, è sempre la stessa: prendo una macchina con una GPU grossa e via. È la trappola più costosa che ho visto fare ai miei clienti negli ultimi due anni, perché sposta la domanda dal posto giusto a quello sbagliato. Quando arriva il momento di accendere la macchina, scopri che non risponde alla tua esigenza reale — e a quel punto hai già speso.

Sei domande vengono prima dell’hardware, ognuna sposta il dimensionamento in modo significativo, e nessuna ha una risposta scontata.

Perché sempre più aziende portano gli LLM in casa

Le ragioni per cui un LLM in locale ha senso oggi sono diverse da quelle di tre anni fa, e vale la pena chiarirle perché condizionano direttamente il tipo di workstation che ti serve.

La prima è la privacy dei dati. Cartelle cliniche, atti giudiziari, contratti commerciali, dati industriali coperti da NDA non possono finire sui server di provider esteri. Nei settori regolamentati — legale, sanitario, pubblica amministrazione, difesa — non è nemmeno una scelta: è un vincolo normativo.

La seconda è il costo a regime. Un’azienda che integra un LLM in un suo prodotto SaaS, o che lo usa intensivamente per analisi documentale, scopre rapidamente che le API a consumo non scalano linearmente con il fatturato. Quando il volume diventa serio, l’infrastruttura on-premise paga il proprio costo in mesi, non in anni.

La terza è la latenza e l’indipendenza. Un agente conversazionale che ha bisogno di rispondere in tempo reale, un sistema di analisi che deve girare anche quando la connessione è instabile, un workflow che non vuole dipendere da rate limit imposti da terzi: tutti scenari in cui l’inferenza in casa non è un’ottimizzazione, è una condizione necessaria.

La quarta è la personalizzazione spinta. Modelli come Llama 4, DeepSeek V3.2, Qwen 3 e Gemma 4 si possono adattare al tuo dominio specifico — terminologia legale italiana, schemi clinici di un ospedale, manualistica tecnica di un’azienda — con tecniche di fine-tuning che richiedono però un’infrastruttura completamente diversa dalla semplice inferenza.

Le sei domande che cambiano tutto

Ognuna di queste domande, presa singolarmente, sposta il dimensionamento dell’hardware. Prese insieme, definiscono se la macchina che stai per ordinare risolverà il tuo problema o ne creerà uno nuovo.

1. Inferenza o fine-tuning?

È la prima e più importante delle domande, perché le due attività vivono su scale di hardware completamente diverse. Far girare un modello esistente (inferenza) significa caricarlo in memoria e usarlo: un’operazione relativamente leggera. Adattarlo ai tuoi dati (fine-tuning) significa rieseguire una parte dell’addestramento — e qui i requisiti possono moltiplicarsi anche per dieci.

Per dare una scala: un modello da 70 miliardi di parametri in inferenza con quantizzazione a 4 bit occupa circa 35-55 GB di VRAM. Lo stesso modello in fine-tuning completo dei parametri richiede invece centinaia di GB — perché ai pesi devi affiancare gradienti, stati dell’ottimizzatore e attivazioni intermedie. Tecniche come QLoRA permettono di scendere a circa 46 GB anche per un 70B, ma solo perché addestrano una piccola componente adattiva del modello, non l’intero set di parametri — e questo limita il tipo di personalizzazione realmente possibile.

Il sintomo di chi non se l’è chiesto prima: ho preso una workstation con una GPU da 24 GB pensando di poter anche personalizzare il modello sui miei dati, e adesso scopro che non riesco nemmeno a iniziare un fine-tuning serio.

2. Quanti utenti contemporanei?

Una workstation usata da una sola persona ha esigenze radicalmente diverse da un server che deve rispondere a dieci colleghi insieme. Non è solo una questione di potenza di calcolo: è soprattutto memoria. Ogni utente attivo aggiunge richieste alla cache, ognuna delle quali occupa VRAM in modo proporzionale alla lunghezza della conversazione.

Il dimensionamento single-user privilegia la velocità di risposta su una singola richiesta. Il multi-utente richiede una VRAM molto più ampia, una gestione del batching delle richieste e spesso un’architettura completamente diversa — con considerazioni su CPU, RAM di sistema e storage che la singola GPU non risolve da sola.

Il sintomo di chi non se l’è chiesto prima: in demo con un solo utente la macchina vola; il giorno in cui in produzione si collegano tre persone insieme, la latenza si triplica e il modello inizia a rifiutare richieste perché va in saturazione.

3. Latenza bassa o throughput alto?

Sono due ottimizzazioni opposte, e quasi nessuno se ne accorge prima di averle messe a confronto. Latenza bassa significa che il modello inizia a rispondere velocemente: serve quando un utente sta digitando e aspetta una risposta in tempo reale. Throughput alto significa che il modello processa più richieste al secondo nel complesso: serve quando di notte devi analizzare 5.000 documenti.

Una workstation ottimizzata per la chat conversazionale userebbe batch size piccoli e quantizzazione meno spinta. Una pensata per il processamento massivo userebbe batch size grandi e accetterebbe latenze più alte sulla singola richiesta. Sono filosofie diverse di tuning, e cambiano il bilanciamento tra GPU, RAM, storage NVMe e persino la scelta del software di inferenza.

Il sintomo di chi non se l’è chiesto prima: ho ottimizzato la macchina per l’agente conversazionale e ora il batch processing notturno dei documenti aziendali ci mette il triplo del previsto.

4. Quale dimensione di modello (oggi e fra dodici mesi)?

Nel 2026 la scelta dei modelli open-source è molto più ricca rispetto al biennio precedente. Llama 4 Scout (109B parametri totali, 17B attivi grazie all’architettura Mixture of Experts), Llama 4 Maverick (400B totali, 17B attivi), DeepSeek V3.2 (685B totali, 37B attivi), Qwen 3 nelle varianti dense fino a 32B e MoE fino a 235B, Gemma 4 con varianti da 2,3B a 31B parametri.

L’architettura MoE introduce un punto critico che molti sottovalutano: anche se solo una frazione dei parametri è attiva ad ogni token, tutti i pesi devono comunque risiedere in VRAM. Llama 4 Scout attiva 17B per token ma occupa la VRAM equivalente ai suoi 109B totali (circa 218 GB a piena precisione, circa 55 GB con quantizzazione a 4 bit).

La domanda vera però non è solo «quale modello uso oggi?», è «dove voglio essere fra un anno?». La velocità con cui escono nuovi modelli rende il dimensionamento sul presente fragile. Una workstation pensata per il modello attuale rischia di costringerti a comprarne un’altra appena il team vuole passare a un modello più capace.

Il sintomo di chi non se l’è chiesto prima: ho dimensionato per Llama 70B convinto che bastasse, sei mesi dopo il team chiede di testare un modello frontier MoE da centinaia di miliardi di parametri e devo rifare l’infrastruttura da zero.

5. Quanto contesto ti serve davvero?

La context window è la quantità di token che il modello può tenere in memoria contemporaneamente: la conversazione in corso, i documenti caricati, le istruzioni di sistema. Modelli moderni offrono finestre da 128.000 a oltre un milione di token. Sembra una caratteristica gratuita; non lo è.

Il KV cache (la memoria che il modello usa per non ricalcolare ogni volta tutto da capo) cresce in modo lineare con il contesto e con il numero di richieste in parallelo. Un modello che entra benissimo a contesto di 4K token può mandare in out-of-memory la stessa GPU non appena il workflow richiede 128K token, perché la cache da sola può arrivare a occupare decine di GB.

Per workflow di tipo RAG (analisi di documentazione aziendale, contratti, manuali) e per agenti conversazionali che mantengono memoria della sessione, la stima realistica del contesto medio è tra 16K e 128K token, non i 512 dei benchmark.

Il sintomo di chi non se l’è chiesto prima: il modello entra in VRAM nei test, ma il giorno in cui carico il primo contratto da 80 pagine va immediatamente in OOM e devo riavviare tutto.

6. Quanta perdita di qualità accetti dalla quantizzazione?

La quantizzazione è la tecnica che permette di comprimere i pesi del modello da FP16 (16 bit per parametro) a FP8, INT4 o formati più nuovi come NVFP4. Dimezza, quartizza o anche divide per otto la VRAM richiesta. Sembra il proiettile d’argento; ha un costo nascosto.

La perdita di qualità rispetto al modello a piena precisione è spesso modesta sui benchmark generici, ma può essere significativa sul tuo dominio specifico — soprattutto su task di precisione (calcolo numerico, codice, terminologia legale o medica). E quasi mai è misurabile in anticipo: la scopri solo testando il modello quantizzato sui tuoi casi d’uso reali.

Il sintomo di chi non se l’è chiesto prima: ho scelto la quantizzazione spinta per risparmiare VRAM, e nel mio settore il modello inizia a sbagliare proprio dove non posso permettermelo — ma ormai la macchina è dimensionata così e non c’è margine per tornare indietro.

Quello che la lista componenti non ti può dire

Anche immaginando di avere risposte chiare alle sei domande, c’è un livello successivo che decide se la macchina eroga davvero il 100% delle sue prestazioni teoriche oppure ne eroga il 70 senza che te ne accorga. È il livello dell’integrazione — la parte che separa una workstation che funziona sui benchmark da una che funziona nel tuo lavoro reale.

Le PCIe lane disponibili, per esempio, decidono se due GPU possono comunicare alla velocità piena oppure se una delle due gira castrata. La maggior parte delle motherboard consumer offre solo una singola GPU con banda piena: configurazioni multi-GPU serie richiedono piattaforme HEDT (Threadripper, Xeon W) con un numero di lane completamente diverso.

La dissipazione è un altro punto sottovalutato. Gli LLM in inferenza non producono picchi di carico: producono carichi sostenuti per ore, talvolta giorni. Un sistema di raffreddamento pensato per il gaming (dove il carico oscilla) si comporta diversamente da uno progettato per inferenza continua. Senza una dissipazione dimensionata per quel tipo di carico, le frequenze scalano verso il basso e la prestazione effettiva crolla rispetto a quella sulla scheda tecnica.

Aggiungi la gestione NUMA su sistemi dual-socket, il tuning del BIOS per garantire la banda di memoria piena, l’alimentazione dimensionata sui carichi continui più un margine ragionevole, lo storage NVMe veloce per il caricamento dei modelli e la swap della cache. Sono dettagli che non compaiono nelle schede tecniche dei singoli componenti, ma fanno la differenza tra una workstation che lavora come deve e una che ti lascia a metà del primo progetto serio.

La domanda che fa la differenza

Se sei arrivato fino a qui hai capito la natura del problema. Mettere un LLM in casa non è una decisione hardware, è una decisione strategica con conseguenze hardware. Le sei domande che ti ho descritto cambiano completamente il dimensionamento, e nessuna di loro ha una risposta che si trova su una scheda tecnica.

Le risposte arrivano da un altro punto: dal tuo workflow reale. Quanti utenti hai oggi e quanti pensi di averne tra dodici mesi. Cosa fai davvero ogni giorno con il modello: chat conversazionale, analisi documentale, codice, RAG su una knowledge base. Quali settori e quali documenti ti vincolano a tenere tutto in casa. Quanto sei disposto a investire ora per non doverlo rifare tra un anno.

Queste cose non si analizzano da soli con una checklist. Si analizzano facendole emergere in una conversazione con qualcuno che le ha già viste in casi simili al tuo — che conosce sia i modelli sia i flussi di lavoro reali, e sa quali compromessi reggono nel tempo e quali no.

In Syspack è il modo in cui lavoriamo da sempre. Prima il lavoro, poi l’hardware. Le domande che hai letto in questo articolo sono le stesse che i nostri esperti fanno in fase di consulenza: servono per capire cosa stai cercando di fare davvero, in modo che la macchina che progettiamo per te risponda al tuo problema reale — non a quello che immaginavi all’inizio.