GPU su Hetzner per inference self-hosted: aggiornamento dopo mesi di esercizio
Self-hostare un LLM non è installare Ollama e dichiarare vittoria. Lo dico perché nel mio stack personale di sperimentazione tengo da mesi un server GPU di Hetzner che fa inference su modelli a pesi aperti, e la distanza tra il "funziona sul mio laptop" del primo giorno e il "regge un carico reale" di oggi è fatta di scelte che nei tutorial non compaiono. Il server è un GEX44, il taglio d'ingresso della linea GPU di Hetzner: monta una NVIDIA RTX 4000 SFF Ada con 20 GB di memoria GDDR6 ECC, una CPU Intel Core i5-13500, 64 GB di RAM e due NVMe da 1,92 TB, a 184,00 EUR al mese più 79,00 EUR una tantum di setup (IVA esclusa, datacenter di Falkenstein, listino Hetzner rilevato a giugno 2026). Il fratello maggiore, il GEX130, monta una RTX 6000 Ada da 48 GB a 838,00 EUR al mese. Dopo mesi di esercizio, alcuni numeri e alcune scelte si sono chiariti, e vale la pena raccontarli per quello che sono: dati di esercizio della mia sandbox, non stime da slide. Una premessa di trasparenza, perché è onesto dirla: nella mia pipeline di produzione uso modelli di frontiera via API (Claude in testa), e questo pezzo non è un manifesto contro le API, è una valutazione ingegneristica di quando il self-hosting ha senso e quando no.
Il primo numero che cambia tutto: l'energia è già nel canone
La sorpresa più piacevole del self-hosting su un dedicato Hetzner, rispetto al mettere una GPU in casa o in un rack proprio, è che il costo dell'energia non esiste come voce separata: è già dentro il canone mensile. Su hardware on-premise una RTX di classe workstation sotto carico continuo aggiunge una bolletta elettrica tutt'altro che trascurabile, più il raffreddamento, più la sostituzione dell'hardware che si ammortizza. Sul GEX44 il conto del primo anno è invece lineare e prevedibile: dodici mensilità più il setup, 2.287,00 EUR tutto compreso, energia, banda e datacenter inclusi. Sul GEX130 da 48 GB si sale a poco più di 10.000 EUR l'anno.
La voce che fa esplodere i budget del self-hosting on-premise, l'energia, su un dedicato in datacenter sparisce dentro un canone fisso. È la ragione per cui, per chi vuole una GPU dedicata senza gestire il ferro, l'affitto mensile batte quasi sempre l'acquisto.
Questo rende il calcolo dei costi onesto fin dall'inizio, perché elimina la variabile più sfuggente. Quando confronto il self-hosting con un'API, parto da un numero certo e fisso, non da una stima della bolletta. È lo stesso ragionamento che ho sviluppato parlando di LLM self-hosted su VPS Hetzner con Ollama per le PMI, ma con mesi di dati reali in più a fare da controprova.
I runtime a confronto: Ollama va bene per provare, non per servire
La prima scelta che cambia tutto è il runtime, ed è anche quella su cui ho cambiato idea con l'esercizio. Ollama e llama.cpp sono ottimi per la prototipazione e per il lavoro su workstation: si installano in minuti, gestiscono la quantizzazione GGUF, girano su hardware modesto. Ma non sono pensati per servire un carico concorrente con throughput alto. Quando il server ha smesso di essere un giocattolo e ha iniziato a ricevere richieste multiple in parallelo, il limite di questo approccio è diventato evidente: la latenza saliva e la GPU restava sottoutilizzata.
Il passaggio che ha cambiato l'esercizio è stato spostarsi su un runtime di serving vero, come vLLM o SGLang, progettati per il throughput in produzione con tecniche come il continuous batching che tengono la GPU satura. La distinzione che ripeto sempre a chi mi chiede di self-hostare è questa: un PoC su Ollama non è un dimensionamento di produzione, e confondere i due è il modo più rapido per concludere, sbagliando, che "il self-hosting non scala". Scala, ma con lo stack giusto, ed è una scelta di ingegneria che ho approfondito parlando di orchestrazione in container di LLM self-hosted su VPS con GPU.
Se stai valutando di portare l'inference dentro la tua infrastruttura e vuoi capire come imposto lo stack di serving senza trasformarlo in un costo nascosto, nel mio hub dedicato all'AI per l'integrazione raccolgo gli articoli con la metodologia che applico sul campo.
Il costo nascosto che nessuno mette in conto: la gestione
C'è una voce che non compare nel canone Hetzner e che dopo mesi di esercizio è quella che pesa di più sul tempo, anche se non sulla fattura: la gestione del sistema. Una GPU in produzione vuole driver NVIDIA allineati, una versione di CUDA compatibile con il runtime, e un runtime di serving che si aggiorna spesso e a volte introduce breaking change. Un aggiornamento del kernel può rompere il driver; una nuova versione di vLLM può cambiare il formato dei pesi attesi; un modello più grande del previsto manda la GPU in out of memory a metà di una richiesta. Niente di insormontabile per chi fa il sistemista di mestiere, ma tutt'altro che il "lancia un comando e dimenticatene" che la narrazione del self-hosting lascia intendere.
A questo si aggiunge la gestione della memoria della GPU, che sui 20 GB del GEX44 è il vincolo dominante: la dimensione del modello, la lunghezza del contesto e il numero di richieste concorrenti competono tutti per la stessa VRAM, e dimensionare male uno dei tre fa cadere gli altri due. La quantizzazione aiuta a far entrare un modello più grande nella memoria disponibile, ma è un compromesso sulla qualità che va misurato sul proprio caso, non dato per neutro. E poi c'è la sicurezza ordinaria: il box è un server Linux esposto come tutti gli altri, da patchare, da monitorare, da inserire nei backup. La GPU non cambia le regole dell'hardening.
Il canone di Hetzner ti dà l'hardware con l'energia inclusa, non un servizio gestito. La differenza tra il prezzo del server e il costo reale del self-hosting è esattamente il tempo che ci metti tu, o qualcuno per te, a tenerlo in piedi. È una voce reale, va messa nel calcolo.
Quando metto a budget un self-hosting per un cliente, questa voce la esplicito sempre, perché è la più sottostimata e la più decisiva: spesso è proprio il costo di gestione, non quello dell'hardware, a far pendere la bilancia verso l'API per chi non ha competenze sistemistiche interne.
Il calcolo build contro buy, fatto onestamente
Qui sta il cuore della questione, e va fatto senza tifoserie. Il GEX44 costa 2.287 EUR il primo anno, un numero fisso indipendente dal volume. Un'API di frontiera costa a consumo, con tariffe nell'ordine di unità di dollari per milione di token in input e decine in output per la fascia top, fino a centesimi per i modelli economici o a pesi aperti ospitati. La matematica è semplice e impietosa: a basso volume o uso sporadico vince l'API, perché paghi solo quello che usi e non ti accolli un canone fisso per una GPU che resta accesa a vuoto. A volume costante e alto, o con un carico prevedibile che tiene la GPU occupata, il canone fisso del self-hosting diventa competitivo, perché spalmi quel costo su moltissime richieste.
Il modo concreto in cui faccio questo conto è ragionare per break-even di utilizzo, non per prezzo nudo. I 2.287 EUR annui del GEX44 equivalgono a circa 190 EUR al mese di spesa fissa: la domanda operativa diventa "quante richieste devo servire perché quei 190 EUR costino meno di quanto pagherei le stesse richieste a un'API equivalente?". Se il volume mensile supera quella soglia in modo stabile, il self-hosting vince; se ci arriva solo nei picchi e per il resto la GPU resta accesa a vuoto, sto pagando un canone per del compute inutilizzato e l'API è più efficiente. La trappola in cui vedo cadere più spesso è dimensionare sul picco e poi sottoutilizzare: un GEX130 da oltre 10.000 EUR l'anno preso "per stare larghi" e tenuto al 15% di utilizzo è il modo più rapido per rendere il self-hosting antieconomico e dare la colpa alla tecnologia invece che al dimensionamento.
C'è però un secondo asse che il confronto a soli costi nasconde, e che è il vero motivo per cui la maggior parte delle persone sceglie male: la capacità non è la stessa. Una singola RTX da 20 o 48 GB fa girare bene modelli a pesi aperti (Llama, Qwen, DeepSeek nelle loro varianti quantizzate), non un modello di frontiera. Confrontare il costo del GEX44 con il costo dell'API di un modello di punta è confrontare due cose diverse: stai pagando meno perché stai servendo un modello meno capace. La domanda corretta non è "costa meno self-hostare?", è "il modello che posso self-hostare basta per il mio caso d'uso?". Per moltissimi task aziendali (classificazione, estrazione, RAG ben fatto) la risposta è sì, e lì il self-hosting ha un senso economico reale. Per i task che richiedono il ragionamento di un frontier model, no, e fingere il contrario è disonesto.
L'argomento che a giugno 2026 ha reso urgente il self-hosting: la continuità
Per mesi il confronto build-contro-buy si è giocato su due assi soltanto, costo e privacy del dato. Il 12 giugno 2026 se n'è aggiunto un terzo, e pesa. Quel giorno Anthropic ha disabilitato l'accesso ai suoi modelli Fable 5 e Mythos 5 per tutti i clienti del mondo, a poche ore dal lancio, per ottemperare a una direttiva di export control del governo statunitense che ne vietava l'accesso ai cittadini stranieri; non potendo applicare il divieto utente per utente su un cloud condiviso, l'unico modo per essere conforme è stato spegnerli per tutti, clienti americani inclusi. È il primo export control mirato a modelli AI specifici, e va detto con onestà che la situazione è in evoluzione (Anthropic dichiara di lavorare al ripristino) e che lo stesso vendor contesta il fondamento tecnico del provvedimento. I fatti e le fonti sono nel comunicato ufficiale di Anthropic.
Il punto, per un decisore, non è la singola vicenda: è che il rischio di costruire su un modello di frontiera di terze parti è passato da commerciale (prezzi, migrazione) a continuità imposta dall'alto. L'asset può sparire per decisione di una giurisdizione terza, contro il parere del fornitore e senza un fondamento tecnico dimostrato. Qui il self-hosting su una GPU europea smette di essere solo una questione di costo o di privacy e diventa una polizza sulla continuità: un fallback caldo, già provato, che non dipende da un kill-switch sovrano. Non sto dicendo di abbandonare i frontier model, li uso io stesso ogni giorno; sto dicendo di progettarne la sostituibilità, e una GPU self-hosted che fa girare un modello a pesi aperti accettabile è uno dei modi concreti per farlo, esattamente il trade-off che ho messo a confronto parlando di agenti gestiti contro sandbox self-hosted.
Conviene self-hostare l'inference nel 2026?
La risposta onesta è "dipende da tre cose, e nessuna è la moda". Dipende dall'utilizzo: se la GPU resta occupata, il canone fisso si ripaga; se la usi a sprazzi, l'API costa meno. Dipende dalla capacità che ti serve: se un buon modello a pesi aperti basta per il tuo caso, il self-hosting è competitivo; se ti serve il ragionamento di un frontier model, non lo sostituisci con una singola RTX. E dipende dai tuoi vincoli di sovranità e continuità: se hai dati che non possono uscire dal perimetro europeo, o se non puoi permetterti che un modello sparisca per una decisione esterna, il self-hosting compra una garanzia che l'API non ti dà, a un costo che ora conosci con precisione.
Dopo mesi di esercizio, la lezione che porto a casa è meno spettacolare di come la raccontano i due partiti contrapposti. Il self-hosting su GPU Hetzner non è né la rivoluzione che ti libera dalle big tech né lo spreco di soldi che molti liquidano in tre righe. È uno strumento con un profilo di costo finalmente prevedibile (energia inclusa, canone fisso, 2.287 EUR il primo anno sul taglio d'ingresso), una curva di efficienza che premia il volume e lo stack di serving giusto, e un valore strategico nuovo che il 2026 ha reso evidente: la sostituibilità di un modello che qualcun altro può spegnere. Per un'azienda la scelta giusta quasi mai è "tutto self-hosted" o "tutto API": è un'architettura che tiene i frontier model dove servono davvero e un fallback self-hosted dove la continuità e la sovranità contano. Se stai valutando questo bilanciamento per la tua infrastruttura e vuoi capire dove conviene affittare una GPU e dove no, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.