Self-hosting di un LLM open-weight vs. un'API: la vera matematica dei costi

Il tuo prodotto va in produzione, chiama un'API LLM, e la bolletta è cresciuta poco a poco ogni mese. Così fai la cosa che ogni builder finisce per fare: apri una nuova scheda e ti chiedi se noleggiare una GPU ed eseguire Llama da solo sarebbe più economico.

La questione del costo del self-hosting di un LLM ha una risposta, ma non è il singolo numero che i primi risultati di ricerca e le AI Overview continuano a ripetere. Dipende da tre cose che quegli articoli appiattiscono: contro quale API stai facendo il confronto, quanto è impegnata la tua GPU e il costo operativo che nessuno mette nel foglio di calcolo.

Ecco la versione breve prima dei dettagli: per la maggior parte dei builder solitari, il self-hosting al momento non vince sui costi. Ma c'è una linea precisa in cui la cosa si ribalta, e puoi calcolarla sulla tua stessa bolletta in circa due minuti. Di seguito trovi la matematica del 2026 (prezzi attuali, numeri di VRAM per modello e una formula che puoi eseguire).

La versione breve

• Il punto di pareggio non è un numero solo. Sono tre, a seconda di contro quale API stai facendo il confronto. Contro un'API di frontiera (GPT-5.x, Claude Sonnet 5 / Opus 4.8, Gemini Pro), il self-hosting raggiunge il pareggio prima di tutto. Contro un'API open-weight economica (DeepSeek, DeepInfra, Together a circa $0.14–$0.50 per milione di token), non vince quasi mai sul costo da solo.
• L'utilizzo è il moltiplicatore che affossa il caso del builder solitario. Una GPU noleggiata costa lo stesso da inattiva come a pieno carico, quindi una GPU che gira al 10% di utilizzo costa all'incirca 10× per token rispetto a quanto costa a pieno carico. I carichi di lavoro solitari a raffica si assestano su un basso utilizzo per impostazione predefinita.
• Sotto il punto di pareggio, il risparmio sui costi consiste di solito nel passare a un'API open-weight economica, non nel self-hosting. Il self-hosting si ripaga quando un volume sostenuto contro i prezzi di frontiera supera la linea al 60%+ di utilizzo, oppure quando hai un motivo non legato ai costi (privacy, latenza, controllo del fine-tuning).
• Esegui la formula sui tuoi numeri prima di noleggiare qualsiasi cosa. Token di pareggio ≈ costo mensile del GPU VPS ÷ il tuo prezzo API misto per token.

Cosa non copre questo articolo

• Cluster GPU multi-nodo o su scala datacenter. Questa è una decisione sui costi per un builder solitario, non per una flotta.
• L'economia del fine-tuning in qualsiasi profondità (un calcolo separato con i suoi compromessi).
• Un tutorial passo dopo passo per la configurazione Ollama-contro-vLLM. L'ambito qui è la questione dei soldi, non l'installazione.
• L'hardware di proprietà come veicolo principale. L'assunzione di fondo è una GPU noleggiata, dato che è il percorso realistico per un builder che non ha già una GPU sulla scrivania.

Cosa determina il costo (e dove i numeri più diffusi sbagliano)

Cerca "self host LLM vs API cost" e finirai su un'ordinata cifra di pareggio: qualcosa come 11 miliardi di token al mese, o intorno ai $4,200 di spesa API mensile, citata dall' analisi dei costi di braincuber e ripetuta quasi alla lettera nell'AI Overview in cima alla pagina. È un numero pulito. È anche pressoché inutile da solo, perché nasconde le due variabili che decidono la tua risposta.

Il motivo per cui la cosa è scivolosa è che i due lati del confronto hanno forme di costo diverse. Una bolletta API è un costo variabile: paghi per token, quindi la bolletta sale e scende con quanto la usi. Una GPU noleggiata è un costo fisso: paghi la stessa tariffa mensile sia che ci spingi attraverso un miliardo di token sia che la lasci inattiva. Confrontare un costo variabile con un costo fisso usando un solo numero richiede di fingere di sapere esattamente quanti token scorreranno, e su scala solitaria di solito non lo sai.

Restano quindi tre leve che spostano il punto di pareggio:

• Contro quale API stai facendo il confronto. Un'API di frontiera e un'API open-weight economica sono separate da circa due ordini di grandezza nel prezzo. Il punto di pareggio contro ciascuna è enormemente diverso.
• Il tuo utilizzo della GPU. Il costo fisso si ripaga solo se la GPU è impegnata. Il tempo di inattività è denaro speso per niente.
• Il costo operativo nascosto. Le tue ore, il ricambio dovuto agli aggiornamenti dei modelli e le sorprese di VRAM che non si palesano finché non sei in produzione.

Metti un prezzo su ciascuna di queste e la nebbia si dirada. È di questo che tratta il resto dell'articolo.

Da ricordare della sezione: il punto di pareggio non è un numero solo. Sono tre numeri, uno per fascia di API, e scegliere la fascia sbagliata da confrontare è dove la maggior parte delle stime di costo va storta.

Il pareggio a tre vie: API di frontiera vs. fascia media vs. economica

Fare self-hosting di un LLM open-weight su un GPU VPS batte un'API di frontiera (classe GPT-5, Claude Sonnet 5 / Opus 4.8, Gemini Pro) a circa qualche milione di token al giorno, a patto che tu tenga la GPU a un utilizzo sano (diciamo 60% o superiore). Contro un'API open-weight economica intorno a $0.14–$0.50 per milione di token, non vince quasi mai sul costo. Quella differenza è tutta la storia, ed è il motivo per cui un solo numero di pareggio non può essere corretto.

Ecco come si presenta la cosa attraverso le tre fasce. Tratta queste soglie come intervalli indicativi, non come linee nette. Provengono da stime della community e dai prezzi del 2026, entrambi in rapido movimento.

Prezzi dalle pagine dei prezzi di OpenAI, Anthropic, Google, DeepInfra, Together, e DeepSeek aggiornati a July 2026. Ognuno di questi numeri ha una durata misurabile in mesi, quindi controlla le pagine attuali prima di impegnarti.

Ora il punto controcorrente, perché è quello che cambia le decisioni. C'è un argomento rumoroso e corretto che gira secondo cui le API economiche hanno ucciso il pareggio del self-hosting. Le API open-weight come DeepInfra e i piani Together ora servono i modelli Llama e Qwen a una frazione dei prezzi di frontiera, e gli stessi prezzi di frontiera sono calati bruscamente dal 2025. Contro quelle tariffe economiche, il pareggio per token arriva a miliardi di token al mese. Un solopreneur non spinge miliardi di token al mese. Quindi se il tuo unico obiettivo è una bolletta più bassa, la prima mossa di solito non è "noleggiare una GPU", è "passare a un'API open-weight economica e non avere zero operatività".

Il caso economico del self-hosting sopravvive in due punti: nel confronto contro i costosi prezzi di frontiera a un volume genuinamente alto e sostenuto, e per i motivi non legati ai costi (privacy, latenza, controllo del fine-tuning) trattati più avanti. Ovunque altro, l'API economica vince l'argomento dei soldi.

La formula del pareggio

break-even tokens per month ≈ GPU VPS monthly cost ÷ your blended API price per token

Esempio pratico, scala solopreneur: diciamo che un singolo GPU VPS di fascia alta costa circa $1,000/mese (intervallo del catalogo 2026 per una fascia top a GPU singola), e sei su un'API di frontiera con una tariffa mista intorno ai $6 per milione di token (all'incirca $0.000006 per token). Sono ~$1,000 ÷ $0.000006 ≈ 167 milioni di token/mese prima che la GPU si ripaghi sulla carta. Ora rifallo contro un'API open-weight economica a $0.40 per milione ($0.0000004/token): ~$1,000 ÷ $0.0000004 = 2.5 miliardi di token/mese. Stessa GPU, stesso costo fisso, e il pareggio si sposta di più di 10× a seconda puramente di quale API metti al denominatore. E questo è prima dell'utilizzo, che peggiora il numero.

Da ricordare della sezione: l'API con cui ti confronti può spostare il tuo pareggio di 10× o più, quindi "fare i conti" significa farli contro l'API specifica che sostituiresti davvero.

Cosa fa l'utilizzo al costo per token

Prendi quel pareggio di frontiera da ~167 milioni di token e aggiungi la variabile che la formula silenziosamente dà per scontata: che la tua GPU sia impegnata per tutto il tempo. Non lo è. Una GPU noleggiata fattura lo stesso importo sia che sia satura sia che sia inattiva, quindi il tuo costo effettivo per token del GPU VPS scala in modo inversamente proporzionale all'utilizzo. Gira al 10% di carico e ogni token che servi porta con sé all'incirca 10× il costo che avrebbe a pieno carico, perché stai pagando per il 90% di capacità che non hai usato. Le stime della community e i resoconti dei professionisti collocano il pavimento pratico intorno al 50–60% di utilizzo sostenuto prima che i numeri smettano di metterti in imbarazzo (cifre indicative, non costanti da laboratorio).

Per un carico di lavoro solitario a raffica (traffico che si impenna durante il giorno e si appiattisce di notte), un utilizzo sostenuto del 60% è difficile da raggiungere. È questa la trappola. Ecco cosa fa al costo per milione di token attraverso alcuni punti concreti, usando i prezzi delle GPU del catalogo 2026 divisi per un throughput mensile approssimativo a ciascun livello di utilizzo:

I cent-per-token assoluti dipendono dal tuo modello, dalla quantizzazione e da quante richieste concorrenti riesci a stipare sulla scheda, quindi tratta le colonne come indicative della forma della penalità piuttosto che di un preventivo. Il punto è il moltiplicatore: scendi dal pieno carico a un quarto di carico e il tuo costo per token all'incirca quadruplica. È di solito questo ad affossare il caso del self-hosting solitario, non il prezzo di listino della GPU.

C'è una via di fuga strutturale, ed è il motivo per cui noleggiare può battere possedere per una domanda irregolare: puoi fermare un'istanza noleggiata quando è inattiva. Possiedi l'hardware e si deprezza e assorbe corrente che tu lo usi o no. Sui noleggi a ore o on-demand, puoi fermare o smantellare l'istanza quando il lavoro è finito ed evitare di pagare per le ore di inattività. Sui piani mensili fissi, la bolletta resta fissa per il periodo di fatturazione, quindi l'utilizzo rimane il principale problema di costo. Non risolve un carico di lavoro genuinamente a basso utilizzo tutto il giorno, ma per una domanda impegnata a raffiche e morta nel mezzo, la capacità di spegnere il contatore è l'unica leva che fa pendere il confronto noleggiare-contro-possedere verso il noleggio.

Da ricordare della sezione: è l'utilizzo, non il prezzo mensile della GPU, che di solito decide se il self-hosting ha senso sui conti, ed è la variabile che i numeri di pareggio più diffusi lasciano completamente fuori.

Quale modello sta in quale GPU: la realtà della VRAM

Il piano che salta per primo è "faccio semplicemente girare un 70B su una 4090". Non puoi. Un modello 70B a quantizzazione Q4_K_M ha bisogno di all'incirca 40–46 GB di VRAM, e una RTX 4090 da 24 GB o una RTX 5090 da 32 GB semplicemente non ne hanno lo spazio. Forzalo su una scheda da 24 GB e sei costretto alla quantizzazione Q2_K (intorno ai 21 GB) con una perdita di qualità visibile, oppure il modello trabocca sulla RAM di sistema e la velocità di generazione crolla. La VRAM è il muro duro che decide quali modelli sono addirittura sul tavolo per una data GPU.

Ecco cosa sta dove. Le cifre di VRAM sono approssimative: sono derivate dalla consueta aritmetica dei byte-per-parametro (FP16 ≈ parametri × 2 con ~15% di overhead; Q4_K_M ≈ parametri × ~0.55 con overhead), quindi trattale come una guida al dimensionamento, non come garanzie.

Le cifre di VRAM sono verificate incrociando le pagine ufficiali delle specifiche GPU di NVIDIA per ciascuna scheda. La A100 dà a un 70B quantizzato un margine più comodo; la RTX 6000 Ada può funzionare per configurazioni Q4 più strette, mentre le schede consumer da 24 GB e 32 GB non hanno abbastanza VRAM per un normale deployment 70B Q4. Se vuoi la scomposizione completa di come i formati GGUF, GPTQ, AWQ ed EXL2 consumano memoria, quella è una tana del coniglio che merita una lettura a sé: GGUF, GPTQ, AWQ, EXL2: come i formati di quantizzazione LLM usano davvero la memoria.

Il punto ideale per la community su una singola scheda da 24 GB è un modello da 24B a 32B (Mistral Small 3.1 o Qwen 3 32B a Q4). È la dimensione che dà a un builder solitario un modello utile sulla fascia GPU più economica senza combattere con la VRAM per tutto il tempo. Se stai valutando quale scheda noleggiare in primo luogo, il nostro benchmark H100 vs RTX 4090 per carichi di lavoro AI confronta le fasce sul throughput.

Consiglio pro: metti a budget la KV cache, non solo i pesi. La sorpresa più comune al primo deployment: dimensioni la GPU per i pesi del modello, lo carichi e ci sta. Poi arrivano le richieste, la KV cache cresce con la lunghezza del contesto e la concorrenza, e finisci la VRAM servendo i tuoi primi utenti. Quando la VRAM va in overflow e il modello trabocca sulla CPU, la velocità di generazione cala di 10–100×. Lascia margine sopra le cifre dei pesi nella tabella per la cache, specialmente se stai servendo contesti lunghi o più utenti contemporaneamente.

I costi nascosti che cancellano i risparmi ingenui

Il foglio di calcolo che dice che il self-hosting è più economico ha quasi sempre una sola voce: il prezzo mensile della GPU. La bolletta che paghi ha più voci. C'è il tuo tempo (ogni ora che passi a fare patch, a riavviare un server di inferenza bloccato o a rincorrere un crash per esaurimento memoria è un'ora che non hai speso sul prodotto). C'è il ricambio dovuto agli aggiornamenti dei modelli: il modello open-weight che hai distribuito viene soppiantato, e ri-benchmarkarlo e ri-distribuirlo è un lavoro ricorrente, non una configurazione una tantum. C'è la sorpresa di VRAM e KV cache della sezione precedente. E c'è lo spreco da inattività, le ore in cui la GPU fattura mentre non gira niente.

I professionisti che li hanno contati stimano il costo reale a circa 1.3–2× il prezzo grezzo della GPU una volta ripiegato dentro il tempo operativo, e alcuni vanno più in alto, a 3–5×, su configurazioni più disordinate. Sono moltiplicatori indicativi tratti dai resoconti della community, non cifre verificate, ma la direzione è il punto. Come afferma un'inquadratura molto citata, una GPU inattiva non è un asset, è una passività fatturata a ore. Per un builder solitario, il modo giusto di dare un prezzo a questo non è una voce di stipendio MLOps, sono le tue ore, che sono la cosa più scarsa che hai. Se il self-hosting ti fa risparmiare $200 al mese sulla carta ma ti costa sei ore di operatività che altrimenti spenderesti a rilasciare, non è ovviamente una vittoria.

Quando il self-hosting vince comunque: privacy, latenza e fine-tuning

Il costo non è l'unico motivo per eseguire un tuo modello, e per alcuni builder non è nemmeno il principale. Sotto il pareggio di costo, dove i soldi dicono "resta sull'API", ci sono tre motivi per fare comunque self-hosting. Sovranità dei dati: tenere i prompt e i dati dei tuoi utenti fuori dalla pipeline di un provider AI esterno, cosa che conta per alcuni prodotti a prescindere da cosa dicono i numeri. Latenza prevedibile: nessuna coda a tenant condiviso, nessun rate limit che non hai impostato tu, nessun rallentamento a sorpresa durante il picco di traffico di qualcun altro. E controllo completo: la libertà di fare fine-tuning, quantizzare, cambiare modelli e fissare le versioni senza aspettare un fornitore.

C'è un'avvertenza sul punto della privacy, e saltarla sarebbe disonesto. Un GPU VPS noleggiato gira comunque sull'hardware di qualcun altro nel datacenter di qualcun altro. Quella è una sovranità significativa dalla pipeline di addestramento e logging del provider AI (i tuoi prompt non stanno passando attraverso i sistemi di un fornitore di modelli), ma non è la stessa cosa di un'apparecchiatura on-premises che controlli fisicamente. Se il tuo requisito è un vero isolamento on-prem, un VPS noleggiato non ti ci porta. Se il tuo requisito è "tenere i nostri dati fuori dalle mani di un fornitore di modelli di terze parti", lo fa. Sappi di quale dei due hai bisogno.

Per i carichi di lavoro che girano in ambienti di rete restrittivi, un modello self-hosted su un'infrastruttura che controlli può anche aggirare le dipendenze da endpoint esterni che potrebbero essere irraggiungibili, una capacità che conta indipendentemente da dove lo distribuisci.

Quindi dovresti fare self-hosting? Una risposta diretta per situazione

Tutto quanto sopra si ordina in una breve decisione. Hai una bolletta, un'idea di massima del tuo volume mensile di token, e ora le tre fasce di pareggio, la penalità di utilizzo e il moltiplicatore dei costi nascosti. Mappa la tua situazione su una di queste:

• Sei sotto il pareggio di frontiera e il costo è la tua unica preoccupazione. Resta su un'API, e prima di ogni altra cosa fai un serio preventivo per un'API open-weight economica (DeepSeek, DeepInfra, Together). Di solito è quello il risparmio sui costi, non il self-hosting. Cambiare API è una modifica di configurazione; il self-hosting è un secondo lavoro.
• Hai un volume alto e sostenuto contro i prezzi di frontiera e riesci a tenere una GPU al 60%+ di utilizzo. È qui che il self-hosting si ripaga. Esegui la formula contro la tua tariffa di frontiera, conferma di superare la soglia con un utilizzo sostenuto (non di picco), e un GPU VPS noleggiato inizia a vincere.
• Hai un fattore non legato ai costi: privacy, latenza o controllo del fine-tuning. Fai self-hosting sotto il pareggio deliberatamente, consapevole che stai pagando per il controllo. Solo, non raccontarti che è più economico se non lo è.
• Sei nel mezzo. Guarda lo schema ibrido su cui la maggior parte dei professionisti si assesta nel 2026: un piccolo modello self-hosted per le attività ad alto volume e semplici, più un'API di frontiera per il ragionamento difficile a cui il tuo modello locale arriva all'85–90% (benchmark della community, non verificati in laboratorio, e l'ultimo tratto è spesso quello in cui hai più bisogno della qualità).

Sulla domanda "come ottengo la GPU", la risposta per un builder solitario è quasi sempre noleggiare, non comprare. Possedere hardware di livello datacenter è una scommessa in conto capitale che ha senso solo a una scala che non hai ancora. L'inferenza serverless può ridurre lo spreco da inattività scalando a zero e fatturando solo per il calcolo attivo, ma spesso lo scambia con una tariffa più alta per ora-GPU e una latenza da cold start. Un GPU VPS noleggiato sta nel mezzo: nessun conto capitale, una bolletta mensile prevedibile, accesso root e la capacità di fermare l'istanza quando è inattiva.

Se hai eseguito la formula, superato il pareggio e vuoi un server di inferenza dedicato, privato e con accesso root senza comprare una scheda, è esattamente a questo che serve una macchina GPU noleggiata. I piani GPU VPS di Cloudzy coprono la gamma da un modello 8B su una singola scheda fino a un 70B quantizzato, e l' app Ollama con un clic nel marketplace si distribuisce in circa un minuto con un'API REST compatibile con i client OpenAI, così il passaggio da un'API a pagamento al tuo server può avvicinarsi a una sostituzione diretta nel tuo codice, senza alcun costo per token dopo il canone mensile fisso. Controlla la pagina per i prezzi attuali; le tariffe GPU si muovono.

L'unica azione che vale la pena fare prima di noleggiare qualsiasi cosa: esegui la formula del pareggio sulla tua stessa bolletta. Ci vogliono due minuti e ti dirà in quale delle quattro situazioni qui sopra ti trovi.

Domande frequenti

È più economico fare self-hosting di un LLM o usare un'API?

Dipende da quale API. Fare self-hosting di un modello open-weight su un GPU VPS può battere un'API di frontiera (classe GPT-5, Claude Sonnet 5 / Opus 4.8) a un volume alto e sostenuto con un buon utilizzo della GPU. Raramente batte un'API open-weight economica (DeepSeek, DeepInfra, Together a circa $0.14–$0.50 per milione di token aggiornati a July 2026) sul costo da solo: quel pareggio arriva a miliardi di token al mese, che la maggior parte dei builder solitari non raggiunge mai.

Di quale GPU ho bisogno per eseguire un modello 70B?

Un modello 70B a quantizzazione Q4_K_M ha bisogno di all'incirca 40–46 GB di VRAM solo per i pesi quantizzati. Una A100 da 80 GB è l'opzione a GPU singola più sicura perché lascia spazio per la KV cache, l'overhead di runtime e i prompt più lunghi. Una RTX 6000 Ada da 48 GB può funzionare per configurazioni Q4 più strette, ma la lunghezza del contesto e la concorrenza vanno gestite con attenzione.

Come influisce l'utilizzo della GPU sul costo per token?

Una GPU noleggiata costa lo stesso sia che sia inattiva sia che sia a pieno carico, quindi il tuo costo effettivo per token scala in modo inversamente proporzionale all'utilizzo. Al 10% di carico, ogni token che servi costa all'incirca 10× quello che costerebbe a pieno carico, perché stai pagando per la capacità inutilizzata. Il pavimento pratico perché il self-hosting abbia senso è intorno al 50–60% di utilizzo sostenuto.

Quanti token al mese prima che il self-hosting valga la pena?

Contro un'API di frontiera, all'incirca 160–256 milioni di token al mese a un utilizzo sano è la soglia indicativa (aggiornata a July 2026). Contro un'API open-weight economica sono miliardi al mese, di fatto irraggiungibili da solo. Il numero esatto dipende dal costo della tua GPU e dalla tua tariffa API mista, quindi esegui la formula: token di pareggio ≈ costo mensile del GPU VPS ÷ il tuo prezzo API per token, poi scontala per l'utilizzo sostenuto.

Posso eseguire un LLM open-weight su un VPS?

Sì, su un GPU VPS dimensionato sulla VRAM del modello. Uno strumento come Ollama esegue modelli open-weight (Llama, Qwen, Mistral e altri) con un deploy con un clic e un'API REST compatibile con OpenAI, così il tuo codice esistente che chiama le API può puntare al tuo server con modifiche minime. Abbina la fascia GPU al tuo modello: un 8B sta comodamente in una scheda da 24 GB, un 70B quantizzato ha bisogno di 48–80 GB.