Il costo reale di eseguire LLM in locale

"Quanto costa eseguire un LLM in locale?" non ha una risposta unica, perché la variabile dominante non è l'hardware — è quanto lo tieni occupato. L'errore più comune e più costoso è confrontare il prezzo d'acquisto di una GPU con una tariffa oraria cloud. Non sono confrontabili: uno è capitale già speso, l'altra è consumo a contatore. L'unico confronto che dice la verità è il costo totale di possesso (TCO) per unità di output — euro per milione di token — sulla vita realistica dell'hardware. Questa guida costruisce quel numero da zero a tre scale, poi mostra le leve che ribaltano il verdetto.

Lo stack completo dei costi

Un deployment locale ha cinque livelli di costo. La maggior parte dei team mette a budget solo il primo e viene sorpresa dagli altri:

Esempi svolti a tre scale

Valori illustrativi per mostrare il metodo — inserisci i tuoi prezzi. Tutti assumono ammortamento lineare a 3 anni e ~0,25€/kWh.

Scala 1 — Singolo: una RTX 3090 usata (24GB)

• Hardware: quota rig ~900€ → ~25€/mese ammortizzati.
• Energia: sistema ~400W sotto carico al 15% di duty ≈ 45 kWh → ~11€/mese.
• Manutenzione: il tuo tempo (non pagato, ma reale).
• Totale ≈ 36€/mese fissi. A volumi da hobbista (diciamo 2–3M token/mese di uso reale) sono ~12–18€ per milione di token — ben sopra una API cloud economica. La conclusione onesta: i singoli raramente vanno in locale per risparmiare; lo fanno per privacy, capacità offline, sperimentazione illimitata e apprendimento — ritorni reali, solo non fatturabili.

Scala 2 — Team: rig dual-3090 che serve un 70B a 4-bit

• Hardware: ~2.400€ → ~67€/mese. Energia al 50% di duty: ~250 kWh → ~63€/mese. Manutenzione/overhead: ~40€/mese.
• Totale ≈ 170€/mese, fissi — che tu generi 1 milione o 1 miliardo di token.
• Servendo un team via vLLM con batching (vedi sotto), un output costante di decine di milioni di token/mese è realistico → ~2–8€ per milione di token, competitivo o migliore del pricing API a qualità equivalente, con i dati che non lasciano mai l'edificio.

Scala 3 — Azienda: un server di inferenza 4×48GB

• Hardware: server ~25–35k€ → ~700–950€/mese. Energia: ~1,5–2kW al 60% di duty ≈ 650–900 kWh → ~160–225€/mese. Manutenzione: ore ingegnere vere — budget ~300–500€/mese.
• Totale ≈ 1.200–1.700€/mese. Con batching tra reparti, centinaia di milioni di token/mese → ben sotto i 5€ per milione di token a qualità di modello equivalente, più i benefici di compliance/residenza che spesso hanno motivato il progetto. È la scala a cui l'economia on-prem brilla davvero — se il carico esiste.

Il break-even: è tutta questione di utilizzo

GPU cloud e API a token fatturano solo ciò che usi, quindi il loro costo scala linearmente. L'hardware di proprietà costa uguale, fermo o al massimo. Su un grafico si incrociano a una soglia di utilizzo — empiricamente spesso intorno al 30–40% costante. Sotto, paghi un asset costoso e inattivo. Sopra, il costo fisso è "riempito" e ogni token extra è quasi gratis — e il divario cresce con la scala.

Fai girare onestamente lo scenario 5% prima di comprare: il rig da team qui sopra al 5% di utilizzo produce un decimo dei token per gli stessi 170€ — costo per token 10 volte peggiore, che perde contro qualsiasi API. L'hardware non è cambiato; l'utilizzo sì. La maggior parte delle delusioni sui costi dell'AI locale sono delusioni di utilizzo.

Il moltiplicatore che tutti ignorano: il batching

La chat single-stream lascia la GPU per lo più inattiva — la generazione di token è limitata dalla banda di memoria e la richiesta di un singolo utente usa una fetta minima del compute. Un motore di serving con continuous batching (vLLM, TGI) intreccia molte richieste concorrenti sulla stessa scheda, moltiplicando il throughput totale di token 10–20× con impatto modesto sulla latenza. Poiché i tuoi costi sono fissi, il costo per token si divide per lo stesso fattore.

Conseguenza pratica: il verdetto locale-vs-cloud si ribalta con la concorrenza. Un assistente mono-utente quasi mai ripaga la sua GPU; un servizio interno da 20 utenti sulla stessa GPU spesso batte ogni alternativa. Nelle stime, conta la domanda concorrente, non solo il volume totale — e se ce l'hai, servi via vLLM invece che con un runtime single-stream, perché l'economia è giorno e notte.

L'elettricità, onestamente

• La base 24/7: una GPU da 350W a pieno regime tutto il giorno fa ~250 kWh/mese — 50–90€/mese ai prezzi UE tipici (l'Italia spesso sta nella fascia alta). Il consumo a riposo (10–30W GPU + 40–80W sistema) costa 10–25€/mese solo per stare accesa.
• Il power-limit è denaro gratis: limitare una 3090 a ~250–280W (nvidia-smi -pl) costa ~5–10% di velocità in inferenza e risparmia ~25–30% di energia. Per l'inferenza bandwidth-bound, gli stati di potenza alti sono in gran parte sprecati comunque.
• Conta l'intera catena: perdite dell'alimentatore (~10%), raffreddamento, e in ufficio l'aria condizionata che rimuove il calore che hai appena pagato per produrre. D'estate paghi due volte.
• Programma il programmabile: i job batch (indicizzazione, eval, fine-tune) spostati sulle tariffe notturne tagliano la bolletta dove esiste il time-of-use.

Ammortamento e rivendita: più gentile di quanto sembri

L'ammortamento lineare a zero è la finzione contabile prudente. La realtà è più gentile: le GPU con molta VRAM tengono il valore insolitamente bene perché la domanda AI continua ad assorbire l'usato — le 3090 si vendono ancora oggi a una frazione sostanziosa del vecchio prezzo, anni dopo il lancio. Un modello realistico: assumi di recuperare il 30–50% del costo GPU alla rivendita dopo 3 anni, il che abbassa materialmente il TCO vero. Due avvertenze: le schede datacenter senza uscite video si rivendono in un mercato più sottile, e una vera rottura architetturale (una nuova generazione con salto di efficienza) può riprezzare l'usato da un giorno all'altro — è il premio di rischio del possedere.

Costi nascosti che si dimenticano

• Tempo ingegneri — driver, aggiornamenti CUDA, monitoraggio, il guasto occasionale alle 2 di notte. A scala team è spesso la voce più grande dopo l'hardware.
• Ridondanza — una GPU è un singolo punto di guasto; la produzione richiede un ricambio, un piano di failover o una storia di downtime accettata.
• La tassa di sperimentazione — il ricambio dei modelli è reale: ri-scaricare, ri-quantizzare, ri-valutare ogni nuova release costa storage e ore.
• Costo opportunità — capitale immobilizzato in hardware che si svaluta; e il rischio di calendario che la GPU dell'anno prossimo faccia lo stesso lavoro a metà dei watt.

Cosa ribalta davvero il verdetto — sensibilità

• Utilizzo (dominante): 5% → il cloud vince nettamente; 60% + batching → il locale vince nettamente. Tutto il resto è di secondo ordine.
• Prezzo dell'elettricità: a 0,10€/kWh (alcune regioni/solare) il locale costa ~30% in meno da far girare rispetto ai conti a 0,30€ media UE.
• Dimensione del modello vs bisogno: se un fine-tune 8–14B copre il tuo task, l'asticella hardware (e la bolletta) crolla rispetto a insistere sul 70B per tutto. Dimensionare bene il modello è la singola ottimizzazione di costo più grande.
• Concorrenza: come sopra — i carichi multi-utente sono dove l'hardware di proprietà si guadagna il posto.

La strategia ibrida (quella che la maggior parte dei team dovrebbe adottare)

Possiedi hardware dimensionato sul tuo carico di base costante; noleggia tutto ciò che è spiky: GPU cloud al secondo per esperimenti, job una-tantum fuori misura e picchi di traffico, e chiamate API per i modelli che non puoi giustificare di ospitare. Ottieni l'economia dell'hardware proprio dove l'utilizzo è dimostrabilmente alto, la flessibilità del cloud dove non lo è, e un percorso di migrazione naturale — quando il burst noleggiato diventa costante, è il segnale per comprare la prossima scheda. Instrada le richieste per difficoltà (prima il modello piccolo locale, il grande in escalation) e usa cache aggressive: entrambe tagliano token prima ancora che vengano generati.

Una checklist decisionale rapida

1. Stima il tuo volume mensile reale di token e la concorrenza (sii onesto — quasi tutti sovrastimano il volume e sottostimano il tempo morto).
2. Calcola il TCO locale/mese: hardware ÷ 36 − rivendita attesa/36 + energia + manutenzione.
3. Dividi per l'output realistico di token (con batching se multi-utente) → €/M token locale.
4. Confronta con una API cloud a token e un noleggio GPU al secondo allo stesso volume.
5. Aggiungi un valore per privacy/residenza/controllo se applicabile — poi decidi, e rivedi ogni anno perché i prezzi si muovono.