Eseguire LLM in Locale sul Proprio Hardware

L'anno scorso ho speso 4.200 dollari per costruire una macchina per l'inferenza locale in grado di far girare un modello da 70 miliardi di parametri a una velocità ragionevole. Un collega ha guardato la mia configurazione e mi ha fatto la domanda ovvia: 'Perché non usi semplicemente l'API? Sono tipo otto anni di crediti API.' Sui conti non aveva torto. Ma sul ragionamento complessivo sbagliava.

Far girare large language model in locale era un tempo appannaggio dei laboratori di ricerca con cluster di GPU montati su rack. Le cose sono cambiate in fretta. Hardware consumer, tecniche di quantizzazione e motori di inferenza ottimizzati hanno portato i modelli da 70B+ alla portata di hobbisti e piccoli team. Dispositivi come la Tinybox spingono ancora oltre: hardware progettato appositamente per far girare modelli da 120 miliardi di parametri offline, senza bisogno del cloud.

Ma 'possibile' e 'pratico' sono cose diverse. Vediamo cosa serve davvero per eseguire modelli grandi in locale, quando ha senso farlo e quando conviene invece pagare un'API.

Perché eseguire modelli in locale?

Il modello con API — inviare i dati a un provider cloud e ricevere i risultati — funziona bene per la maggior parte dei casi d'uso. È più semplice, costa meno per query a volumi bassi e ti dà sempre accesso ai modelli più recenti. Allora perché qualcuno dovrebbe preoccuparsi dell'inferenza locale?

• Privacy e conformità. Alcuni dati non possono uscire dalla tua rete. Cartelle cliniche, documenti legali, codice proprietario, dati finanziari: i settori regolamentati hanno spesso requisiti rigidi sulla residenza dei dati. Inviare le cartelle dei pazienti a un endpoint API, anche cifrato, potrebbe violare l'HIPAA. L'inferenza locale mantiene tutto on-premises.
• Latenza. Le chiamate API comportano round trip di rete, possibili attese in coda e limiti di frequenza. L'inferenza locale non ha latenza di rete e non finisci mai in coda. Per applicazioni interattive — assistenti di programmazione in tempo reale, traduzione on-device, interfacce vocali — la differenza tra 50 ms e 500 ms è la differenza tra 'reattivo' e 'lento'.
• Costi su larga scala. I prezzi delle API sono a token. A volumi bassi sono trascurabili. A volumi alti crescono in modo brutale. Un team che fa molta code review, analisi di documenti o elaborazione batch può bruciare migliaia di dollari al mese in costi API. L'hardware locale ha un costo fisso: una volta pagato, l'inferenza è praticamente gratuita.
• Disponibilità. Le API cloud vanno giù. Vengono imposti limiti di frequenza. I prezzi cambiano senza preavviso. I modelli vengono deprecati. Se il tuo prodotto dipende da un'API di terzi, sei in balia delle loro decisioni di business. Con l'inferenza locale, le tue funzionalità non svaniscono perché il server di qualcun altro ha una brutta giornata.
• Libertà di sperimentazione. I provider API hanno policy d'uso. Decidono cosa puoi e non puoi fare con il modello. I modelli locali non hanno queste restrizioni: puoi fare fine-tuning, modificarli, usarli per qualsiasi scopo ed eseguirli quante volte vuoi.

La realtà dell'hardware

Il vincolo fondamentale per l'inferenza di LLM è la memoria, non il calcolo. I parametri del modello devono stare in memoria (VRAM della GPU o RAM di sistema) prima che tu possa farci qualsiasi cosa. Un modello da 70B parametri in virgola mobile a 16 bit richiede circa 140 GB di memoria. Più di quanto offra qualsiasi GPU consumer.

Qui entra in gioco la quantizzazione. Riducendo la precisione dei pesi del modello da 16 bit a 8 bit, 4 bit o persino 2 bit, puoi abbattere drasticamente i requisiti di memoria:

Memory requirements for a 70B parameter model:
FP16 (full precision):  ~140 GB  → requires multiple A100s
INT8 (8-bit quant):     ~70 GB   → requires 2x RTX 4090 (48GB total)
Q4_K_M (4-bit quant):   ~40 GB   → fits on 2x RTX 3090 or 1x A6000
Q2_K (2-bit quant):     ~25 GB   → fits on 1x RTX 4090 (24GB)
For a 120B parameter model:
FP16:                   ~240 GB  → enterprise GPU territory
INT8:                   ~120 GB  → 5x RTX 4090 or purpose-built device
Q4_K_M:                 ~70 GB   → 3x RTX 4090
Q2_K:                   ~40 GB   → 2x RTX 4090

La quantizzazione a 4 bit (Q4_K_M nell'ecosistema llama.cpp) è al momento il punto di equilibrio ideale. La degradazione della qualità è misurabile ma spesso accettabile per uso pratico: la maggior parte delle persone non riesce a distinguere l'output Q4 da quello a piena precisione nei test alla cieca. La quantizzazione a 2 bit impatta in modo evidente la qualità, soprattutto nei compiti che richiedono ragionamento, ma funziona ancora per applicazioni più semplici come la classificazione del testo o il riassunto.

Configurazioni hardware consumer

Se stai costruendo una configurazione locale per l'inferenza, hai tre strade di base, ciascuna con un diverso rapporto prezzo-prestazioni.

Il percorso con una singola GPU

Una RTX 4090 (24 GB di VRAM, circa 1.600 dollari) può far girare comodamente modelli quantizzati a 4 bit fino a circa 30B parametri, oppure modelli da 70B con quantizzazione a 2 bit spinta. Per la maggior parte dei modelli da 7B–13B è esagerata: otterrai oltre 40 token al secondo, più velocemente di quanto la maggior parte delle persone riesca a leggere. È la strada più semplice: compri una GPU, installi llama.cpp o Ollama e sei operativo.

Il percorso multi-GPU

Due o più GPU ti permettono di distribuire un modello su più dispositivi (tensor parallelism). Due RTX 3090 (48 GB di VRAM totale, circa 2.200 dollari usate) possono far girare comodamente modelli da 70B a 4 bit. Il problema: ti servono una scheda madre con abbastanza lane PCIe e spazio fisico per più GPU di dimensioni standard. Il flusso d'aria diventa un problema serio: due GPU da 350 W in un case generano parecchio calore.

Il percorso con memoria unificata

I Mac con Apple Silicon e grande memoria unificata offrono un'opzione sorprendentemente valida. Un M2 Ultra con 192 GB di memoria unificata può contenere interamente un modello da 70B a piena precisione. La velocità di inferenza è inferiore rispetto alle GPU dedicate — forse 10-15 token al secondo per un modello da 70B — ma la semplicità è difficile da battere. Niente problemi di driver, niente configurazione multi-GPU, niente gestione termica. Basta un Mac Studio sulla scrivania che fa girare un modello da 70B.

Le chip della serie M ottengono questo grazie all'architettura a memoria unificata: CPU e GPU condividono lo stesso pool di memoria, quindi non c'è il collo di bottiglia della copia dei dati tra RAM della CPU e VRAM della GPU. La larghezza di banda della memoria è inferiore a una configurazione con GPU dedicata, ed è per questo che l'inferenza è più lenta, ma avere 192 GB di memoria indirizzabile in un dispositivo che consuma 60 watt è davvero impressionante.

Dispositivi per l'inferenza costruiti appositamente

La categoria più recente è quella degli hardware per l'inferenza locale progettati appositamente: dispositivi dedicati pensati per far girare modelli grandi in modo efficiente. Puntano a risolvere la seccatura del multi-GPU: invece di assemblare GPU consumer tra cavi e problemi di gestione, ottieni un'appliance concepita fin dall'inizio per l'inferenza.

Il vantaggio è evidente. Lo colleghi, indirizzi la tua applicazione verso di lui e fa girare il modello. Niente conflitti di driver, niente gestione delle versioni di CUDA, niente thermal throttling perché qualcuno ha messo tre GPU troppo vicine. Il compromesso è il costo: i dispositivi dedicati costano in genere di più per FLOP rispetto alle GPU consumer equivalenti. Stai pagando per l'integrazione, l'affidabilità e il fatto di non dover fare debug dell'allocazione delle lane PCIe.

Per le piccole aziende che hanno bisogno di inferenza locale ma non hanno ingegneri hardware in organico, questi dispositivi hanno senso. Per gli appassionati che amano costruire le cose, le configurazioni multi-GPU fai-da-te restano più economiche e più flessibili.

Lo stack software

L'hardware è solo metà della storia. Lo stack software per l'inferenza è evoluto rapidamente, e la scelta giusta può raddoppiare il throughput sullo stesso hardware.

• llama.cpp — Il coltellino svizzero dell'inferenza locale. Scritto in C/C++, gira su qualsiasi cosa, dai Raspberry Pi ai server multi-GPU. Supporta decine di architetture di modelli e formati di quantizzazione. Non sempre il più veloce, ma il più portabile e costantemente mantenuto.
• vLLM — Ottimizzato per il throughput su GPU NVIDIA. Usa PagedAttention per gestire in modo efficiente la memoria della GPU, il che migliora drasticamente l'inferenza in batch. Se servi più utenti da una singola macchina, vLLM è di solito la scelta migliore.
• Ollama — L'approccio 'Docker per gli LLM'. Incapsula llama.cpp in un'interfaccia user-friendly con un registro di modelli. Esegui ollama run llama3:70b e scarica il modello, configura la quantizzazione e avvia il servizio. Ottimo per iniziare, ma meno configurabile del llama.cpp puro.
• MLX — Il framework di machine learning di Apple, ottimizzato per Apple Silicon. Se usi un Mac con chip serie M, MLX di solito offre prestazioni migliori di llama.cpp perché sfrutta in modo più efficace l'architettura a memoria unificata.

# Getting started with Ollama (the easiest path)
# Install: https://ollama.ai
# Run a 7B model (downloads automatically, ~4GB)
$ ollama run mistral
# Run a 70B model (needs ~40GB RAM/VRAM)
$ ollama run llama3:70b-instruct-q4_K_M
# Serve as an API endpoint (OpenAI-compatible)
$ ollama serve
$ curl http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "mistral",
"messages": [{"role": "user", "content": "Explain TCP handshakes"}]
}'

Il confronto costi onesto

Facciamo i conti che contano davvero. Supponiamo di far girare un modello da 70B e di elaborare circa 1 milione di token al giorno (più o meno l'equivalente di analizzare 50-100 documenti o gestire qualche centinaio di conversazioni di chat).

Cloud API (approximate pricing for 70B-class model):
Input:  $0.50 per million tokens
Output: $1.50 per million tokens
Daily cost: ~$2.00
Monthly cost: ~$60
Yearly cost: ~$720
Local inference (2x RTX 4090 build):
Hardware: $4,200 (one-time)
Electricity: ~$30/month (assuming 700W, 8h/day, $0.15/kWh)
Break-even: ~5.5 years
Local inference (Mac Studio M2 Ultra 192GB):
Hardware: $5,800 (one-time)
Electricity: ~$3/month (60W)
Break-even: ~8 years

A 1 milione di token al giorno, l'API cloud costa meno per anni. Ma il calcolo cambia radicalmente se il volume cresce. A 10 milioni di token al giorno, l'API costa 7.200 dollari all'anno e l'hardware locale si ripaga in circa 7 mesi. A 50 milioni di token al giorno, l'inferenza locale si ripaga in qualche settimana.

Il confronto dei costi ignora anche i fattori non finanziari: privacy, latenza, disponibilità e libertà di sperimentazione. Se uno di questi è un requisito (e non solo un optional), il confronto economico passa in secondo piano.

Cosa si perde con la quantizzazione

La quantizzazione è ciò che rende possibile l'inferenza locale di modelli grandi, ma non è gratuita. Ridurre la precisione significa perdere parte dell'informazione, e la degradazione non è uniforme tra i diversi compiti.

Nei miei test, i modelli quantizzati a 4 bit si comportano quasi identicamente alla piena precisione in: generazione di testo, riassunti, Q&A semplici, traduzione e generazione di codice per pattern comuni. La degradazione si vede in: ragionamento complesso a più passi, calcolo matematico, compiti che richiedono il richiamo preciso di dati di training e il rispetto di istruzioni sfumate.

In pratica: se usi un modello locale per il completamento del codice, il riassunto di documenti o l'AI conversazionale, la quantizzazione a 4 bit va benissimo. Se lo usi per ragionamenti analitici complessi o per compiti in cui contano le sottili differenze di accuratezza, dovrai testarlo con attenzione ed eventualmente usare una precisione più alta, al prezzo di più memoria o di un modello più piccolo.

Prendere la decisione

Dopo un anno di modelli eseguiti in locale, ecco il mio schema per decidere tra inferenza locale e cloud:

Usa le API cloud quando: ti serve la qualità del modello migliore in assoluto, il volume è da basso a moderato, non hai competenze hardware, devi cambiare modello spesso o la latenza non è critica (qualche centinaio di millisecondi va bene).

Esegui in locale quando: i tuoi dati non possono uscire dalla rete, ti servono latenze costantemente sotto i 100 ms, il volume di token è abbastanza alto da giustificare il costo dell'hardware, vuoi sperimentare liberamente senza costi per query o ti serve un'inferenza disponibile indipendentemente dall'uptime di terzi.

Il panorama sta cambiando in fretta. I modelli diventano più piccoli ed efficienti. Le tecniche di quantizzazione migliorano. L'hardware costa sempre meno. La soglia di volume oltre la quale l'inferenza locale ha senso economico scende ogni anno. Se oggi non ha senso per te, tra diciotto mesi potrebbe averlo, e nel frattempo lo stack software diventerà solo più facile da usare.