Quanto costa oggi un LLM self-hosted su VPS dopo il rincaro Hetzner

Il 15 giugno 2026, alle 8:00 CEST, Hetzner ha applicato il secondo aumento di listino dell'anno sul cloud, dopo quello del 1 aprile. Non è stato un ritocco: sulla linea a vCPU dedicate la CCX13 è passata da 15,99 a 42,99 euro al mese (+169%), la CCX33 da 62,49 a 138,49, e sulla linea condivisa AMD la CPX22 è salita da 7,99 a 19,49 euro. Tutti i prezzi che leggi in questo articolo sono espressi in EUR al mese, IVA esclusa, listino delle location tedesche e finlandese (eu-central), e li ho ri-verificati il 17 settembre 2026 sulle tabelle ufficiali di price adjustment di Hetzner. Il dettaglio che quasi tutti i commenti hanno mancato, però, è un altro: i server esistenti mantengono i prezzi precedenti. L'aumento vale per gli ordini nuovi e per i rescale. Per chi sta valutando un LLM self-hosted su infrastruttura Hetzner questo singolo fatto riscrive la strategia, perché divide il mondo in due popolazioni: chi una macchina ce l'ha già e siede su condizioni che oggi non esistono più, e chi parte da zero e deve fare i conti con il listino nuovo. In questo articolo faccio esattamente quei conti, da ingegnere che l'inferenza self-hosted la esercisce davvero, con tre scenari di spesa verificabili e un confronto con le API che non tifa per nessuna delle due squadre.

Quanto costa davvero far girare un LLM su Hetzner a fine 2026?

La risposta sintetica: si parte da circa 21 euro al mese per la sperimentazione su CPU con modelli piccoli quantizzati, si sta fra i 40 e i 140 euro per un carico batch di produzione leggera sempre su CPU, e si sale di un ordine di grandezza, oltre i mille euro al mese, quando serve una GPU dedicata per modelli grandi o latenze interattive. La tabella che segue è la fotografia del listino attuale sulle taglie che hanno senso per l'inferenza:

Per la linea GEX il listino esposto nelle stesse tabelle di price adjustment va da 1.197,30 a 2.297,30 euro al mese a seconda della configurazione: negli articoli preferisco citarla come classe, perché i dedicati cambiano listino con più frequenza del cloud. E una regola di igiene contabile che applico sempre: mai convertire il canone mensile di un dedicato in una tariffa oraria da confrontare con il cloud a consumo, perché il dedicato lo paghi anche quando non lo usi, e quel confronto apparentemente neutro è il modo più rapido per mentirsi sul break-even.

La scelta della linea Arm64 (CAX) negli scenari CPU non è casuale: a parità di RAM è la più economica del listino, e per l'inferenza su CPU la RAM è il vincolo dimensionante prima ancora dei core. Un modello da 7-8 miliardi di parametri quantizzato a 4 bit occupa nell'ordine dei 5-6 GB, a cui va sommata la memoria per il contesto: su 16 GB ci sta comodo, su 8 GB ci sta stretto. Prendi però questa stima per quello che è, un dimensionamento di massima e non una garanzia di avvio: fra dimensione del contesto, KV cache e overhead del runtime, l'unico test che vale è caricare il modello con la configurazione che userai davvero. Per farti un'idea rapida di quale taglio regge quale carico, ho costruito uno strumento di dimensionamento dei server Hetzner che tiene i prezzi allineati al listino reale, e un comparatore più generale su quale server comprare quando il perimetro non è ancora deciso.

Se vuoi vedere come integro LLM self-hosted in architetture di produzione per aziende, con requisiti di residenza del dato e governance dei costi dichiarati, nel mio hub dedicato all'AI per le aziende trovi la raccolta di articoli tecnici con metodologia e perimetro espliciti.

Cosa è cambiato il 15 giugno, e perché il grandfathering è la notizia vera

Il repricing di giugno ha colpito in modo molto asimmetrico. Le linee condivise Intel e Arm (CX e CAX) restano la parte bassa del listino, fra 5,49 e 40,99 euro: sono loro oggi il punto d'ingresso razionale. Le linee CPX e CCX, quelle che le guide degli ultimi due anni raccomandavano di default per l'inferenza "perché hanno più spinta", hanno subito rincari fra il 100% e il 169%: la CPX62 è passata da 50,49 a 129,99 euro, la CCX13 da 15,99 a 42,99. Qualunque articolo, foglio di calcolo o preventivo che citi prezzi Hetzner precedenti al 15 giugno 2026 oggi è sbagliato, ed è sbagliato per difetto, che è il verso peggiore: il lettore scopre il prezzo vero al checkout.

Il grandfathering dei contratti esistenti, confermato nero su bianco nella pagina ufficiale, ha due conseguenze operative che vale la pena dire esplicitamente. La prima: se hai già server Hetzner attivi su piani CPX o CCX, quelle macchine sono un asset a condizioni fuori mercato, e la mossa più costosa che puoi fare è distruggerle e ricrearle con leggerezza, perché il rescale verso l'alto ti sposta al listino nuovo. Prima di ogni resize la domanda giusta è se il problema non si risolva a parità di piano: nel mio mestiere, la metà dei "ci serve più server" si rivela un problema di configurazione, non di capacità. La seconda conseguenza: per i carichi nuovi conviene ripartire da un foglio bianco invece di replicare la topologia storica, perché la gerarchia di convenienza fra le linee è cambiata, e la risposta giusta del 2024 (CPX ovunque) oggi è quasi sempre quella sbagliata.

Un listino che cambia due volte in un anno non è un dettaglio amministrativo: è un parametro di progetto. Se il tuo piano di adozione AI regge solo con i prezzi di ieri, non era un piano, era una speranza con un foglio Excel.

C'è anche il capitolo hardware di proprietà: la fascia GPU consumer che molti usano per l'inferenza in casa è in piena turbolenza di prezzi per la crisi della memoria, e questo rende il perimetro "compro una GPU invece di affittarla" meno lineare di sei mesi fa. È un tema che merita un articolo a parte; qui basta la conseguenza: il canone di un dedicato GPU va confrontato con il costo reale e attuale dell'alternativa in casa, non con il prezzo che la stessa scheda aveva quando l'hai guardata l'ultima volta.

Quale modello, con quale runtime, su quale ferro

Il costo dell'infrastruttura è metà del conto; l'altra metà è non chiedere al ferro ciò che non può dare. La distinzione che uso, e che raccomando di adottare come lessico interno, è fra due classi di stack. La prima è la classe workstation e prototipazione: Ollama e llama.cpp, quantizzazione GGUF, modelli piccoli, richieste sequenziali. Gira benissimo su CPU, anche sui CAX di cui sopra, e copre una quantità sorprendente di casi d'uso PMI reali: classificazione di documenti in batch notturno, generazione di embedding per un RAG interno, estrazione strutturata da testi, bozze di risposte non esposte al cliente. La seconda è la classe produzione su GPU: vLLM o SGLang, batching continuo, più utenti concorrenti, latenze interattive. Un proof of concept della prima classe non è un dimensionamento della seconda, e la maggior parte dei progetti self-hosted che ho visto fallire è morta esattamente su questo equivoco: hanno validato su Ollama e promesso agli utenti l'esperienza di vLLM.

Noterai che non ti ho dato numeri di token al secondo, ed è una scelta deliberata: il throughput dipende da modello, quantizzazione, lunghezza del contesto e concorrenza in un modo che rende ogni numero fuori dal tuo carico una promessa non mantenibile. I numeri di esercizio del mio setup, misurati e datati, li ho pubblicati nell'aggiornamento dopo mesi di inferenza self-hosted su GPU Hetzner: usali come scala empirica, non come garanzia trasferibile.

Sul fronte modelli, la buona notizia del 2026 è che il segmento open-weight offre scelte con licenze pulite: la famiglia Qwen di Alibaba e gli open-weight di Mistral sono Apache 2.0, DeepSeek V4 è MIT. Sono licenze che un ufficio acquisti può leggere senza avvocato, ed è un criterio di selezione tanto quanto la qualità del modello: l'errore da non fare è dire "open source" a ogni famiglia con i pesi scaricabili, perché alcune (Llama in testa) hanno licenze community con restrizioni d'uso che in un contesto aziendale vanno lette per intero. Nella mia pipeline personale di automazione la selezione parte sempre da lì: prima il vincolo legale e di residenza, poi la capacità, perché un modello brillante che il tuo settore non può usare è un benchmark, non uno strumento.

E allora conviene, rispetto alle API?

Facciamo il confronto senza tifo. Sul puro costo per token, le API dei grandi provider restano difficili da battere per volumi piccoli e discontinui: i modelli di classe economica costano centesimi per milione di token in input, e a quelle tariffe un carico da poche decine di migliaia di richieste al mese non giustifica nemmeno il tempo di configurare un server. I prezzi puntuali cambiano troppo spesso per stamparli qui: si leggono sulla pagina pricing viva del provider il giorno in cui firmi, non su un articolo.

Il self-hosting vince su altri tre assi, e sono assi che per una PMI regolamentata pesano più della tariffa. Il primo è la sovranità del dato: con l'inferenza in casa niente esce dal tuo perimetro, e non è una paranoia di nicchia, visto che secondo il Deloitte State of AI in the Enterprise 2026, survey su 3.235 leader in 24 paesi presentata a Davos a gennaio, l'83% delle aziende considera la sovereign AI un tema strategico. Il secondo è la prevedibilità: il canone di un server è un numero che conosci a budget, mentre il costo API è una funzione del comportamento degli utenti, e chi ha vissuto un mese di adozione entusiasta lo sa. Il terzo è il controllo del ciclo di vita: i modelli API vengono deprecati e ritirati con preavvisi che possono essere di pochi mesi, e ogni ritiro ti impone una migrazione che non hai scelto; i pesi che hai scaricato, invece, non te li ritira nessuno. L'architettura completa di un caso concreto, con RAG self-hosted su VPS Hetzner e i trade-off dichiarati, l'ho descritta nel deployment di un LLM self-hosted con Ollama per PMI con vincoli di data sovereignty.

Il conto onesto per decidere è sempre lo stesso e ha quattro voci: canone dell'infrastruttura al listino di oggi, tempo di gestione (patching, monitoring, aggiornamento dei modelli: ore vere di qualcuno, non "si fa da solo"), costo del fallimento (cosa succede se il servizio è giù mezza giornata), e valore dei tre assi qui sopra per il tuo caso specifico. Quando questo conto lo fai per iscritto, la risposta smette di essere ideologica: certi carichi vanno alle API, certi altri in casa, e la maggior parte delle aziende mature finisce con un modello ibrido, API per il traffico interattivo generalista e self-hosted per i dati che non devono uscire.

Tre scenari di spesa per partire con i numeri di oggi

Chiudo con le tre configurazioni che userei oggi come punto di partenza, ai prezzi verificati a settembre 2026. Scenario uno, esplorazione: una CAX31 da 20,99 euro al mese, Ollama, un modello 7-8B quantizzato, un caso d'uso interno non esposto: serve a capire se il valore c'è, con un impegno economico che si decide senza riunione. Scenario due, produzione batch: una CAX41 da 40,99 euro o una CCX33 da 138,49 se la costanza di prestazioni conta, llama.cpp o Ollama orchestrati da coda, per carichi notturni e asincroni: è lo scenario con il miglior rapporto fra valore e complessità, e per molte PMI è anche il punto d'arrivo. Scenario tre, produzione interattiva: qui si entra nella classe GEX oltre i mille euro al mese, con vLLM, e la decisione smette di essere infrastrutturale per diventare di business: a quel canone il confronto con le API va rifatto ogni trimestre, e la risposta giusta dipende dai volumi e dai vincoli di residenza più che dalla tecnica. In tutti e tre gli scenari, il grandfathering suggerisce la stessa tattica: le macchine che accendi oggi difendile, perché al prossimo repricing saranno loro le condizioni fuori mercato.

Se hai un progetto concreto di AI self-hosted o ibrida e vuoi capire se rientra nel mio perimetro di intervento, il modulo di preventivo gratuito ti risponde in due minuti: sette domande, nessun impegno, e ti dico subito se posso aiutarti o se ti conviene una figura diversa.