Come fare self-hosting di un LLM su un server GPU privato

Eseguire un modello linguistico su hardware che noleggi è l'unico modo per essere certo che i tuoi prompt non vengano registrati, conservati o letti da nessuno tranne te. Ogni API in hosting — per quanto buona sia la sua informativa sulla privacy — riceve ogni token che invii, e quella policy può cambiare senza il tuo coinvolgimento. Il self-hosting sposta il confine: i pesi risiedono su un disco che controlli tu, l'inferenza avviene nella VRAM che hai noleggiato a ore, e nulla lascia la macchina a meno che non sia tu a inviarlo altrove. Il lato software è diventato genuinamente semplice. Ciò che ancora coglie di sorpresa è dimensionare la scheda prima di ordinarla, e ricordare che una porta di inferenza aperta è una porta di inferenza aperta.

Cosa ti dà davvero il self-hosting — e cosa non ti dà

Sii preciso riguardo al beneficio, perché la «AI privata» viene venduta in modo vago. Un modello sulla tua GPU cambia alcune cose completamente e altre per nulla.

• I tuoi prompt e i tuoi output restano sulla macchina — nessun logging lato provider, nessuna finestra di conservazione, nessun dataset costruito da ciò che hai chiesto.
• Nessun account, nessun rate limit per chiave, e nessuno strato di policy tra te e i pesi. Il modello che hai distribuito è il modello che ottieni.
• Costo prevedibile su grandi volumi. Oltre pochi milioni di token al giorno una scheda noleggiata costa meno del pricing per token, e il prezzo non si muove quando un provider rivede il suo listino.
• Non rende forte un modello debole. Un modello open-weights sul tuo hardware resta quel modello — il self-hosting compra controllo, non capacità di frontiera.
• Non nasconde nulla all'host. Chiunque abbia accesso fisico a una macchina in funzione può in linea di principio leggerne la memoria, il che è una questione che riguarda l'host, non il modello.

La VRAM è tutto: dimensionare un modello per una scheda

Quasi ogni primo tentativo fallito è un errore di calcolo sulla VRAM. Pesi, KV cache e margine di lavoro devono entrare tutti insieme nella scheda, e non esiste un degrado morbido — si ottiene un errore di memoria esaurita dopo pochi secondi di caricamento. La regola empirica è pratica: a precisione 16-bit un modello richiede circa 2 GB di VRAM per miliardo di parametri, circa 1 GB a 8-bit, e circa 0,6 GB a 4-bit. Poi va aggiunta la KV cache, che cresce con la lunghezza del contesto e con le richieste concorrenti, ed è quella che in produzione ti morde davvero, non in fase di test.

• Un modello da 7B a 8B: circa 16 GB in FP16, o comodamente sotto gli 8 GB in 4-bit. È la classe che rientra in una RTX A4000 16 GB con margine da vendere.
• Un modello da 13B a 14B: circa 28 GB in FP16, intorno ai 9 GB in 4-bit. Una RTX 4090 24 GB lo esegue quantizzato con molto contesto residuo.
• Un modello da 30B a 34B: intorno ai 68 GB in FP16, vicino ai 20 GB in 4-bit — la collocazione naturale per una RTX 5090 32 GB.
• Un modello da 70B: circa 140 GB in FP16, circa 40 GB in 4-bit. Questo significa una A100 o una H100 80 GB, e a piena precisione significa più di una scheda.
• Un contesto lungo moltiplica la KV cache, non i pesi. Una finestra da 128k token su un modello grande può richiedere da sola decine di gigabyte — mettilo in conto prima di ordinare, non dopo.

Scegliere la GPU: dalla A4000 alla H100, e quando l'orario batte il mensile

Ogni piano della gamma server GPU è una scheda fisica intera con tutta la sua VRAM — nessun partizionamento MIG, nessuna condivisione a turni — quindi il numero sulla scheda tecnica è il numero che puoi davvero riempire. Abbina la scheda al modello che intendi servire, non al modello che magari proverai un giorno.

• RTX A4000 16 GB a $89/mo — 8 vCPU e 64 GB RAM. Sufficiente per un assistente quantizzato da 7B a 13B, un servizio di embedding, o una pipeline di classificazione attiva tutto il giorno.
• RTX 4090 24 GB a $189/mo — 16 vCPU, 128 GB e 2 TB NVMe. Il miglior rapporto valore/token per modelli da 13B a 34B in 4-bit, e la scelta abituale per un piccolo endpoint di produzione.
• RTX 5090 32 GB a $279/mo — 24 vCPU e 192 GB. Quegli 8 GB in più fanno spesso la differenza tra un modello da 34B che ci sta con un contesto reale e uno che non ci sta.
• A100 80 GB a $690/mo — 32 vCPU, 256 GB e 4 TB NVMe. Banda HBM2e e memoria sufficiente per un 70B in 4-bit con una finestra lunga, o per un serving fortemente in batch.
• H100 80 GB a $1190/mo — 48 vCPU, 384 GB, 8 TB NVMe e una porta da 10 Gbps. Il supporto FP8 e la banda HBM3 la rendono l'unica scelta sensata per un throughput serio o per il training.

La fatturazione è oraria o mensile dallo stesso saldo prepagato, e questo cambia l'aritmetica più di quanto ci si aspetti. Una valutazione che richiede due pomeriggi su una H100 costa le ore in cui è girata, non un mese. Un endpoint di chat che deve rispondere alle tre di notte vuole una macchina mensile. Se ti servono più schede in una sola macchina, o una GPU affiancata a molto storage locale, un server dedicato è la forma migliore — e il discorso generale sul pagare in crypto è trattato in noleggiare un server GPU con crypto.

Passo dopo passo: dalla ricarica in crypto a un endpoint funzionante

1. 01Crea un account con un'email usa e gettaUn'email e una password. Nessun nome, telefono o documento, così nulla dal nostro lato collega il modello che esegui a te.
2. 02Ricarica il saldo in cryptoAlimenta un saldo prepagato con Bitcoin, Monero o una qualsiasi delle 8 crypto disponibili. Non scade mai e non viene mai congelato.
3. 03Distribuisci un'istanza GPU su un'immagine CUDAScegli la scheda, una regione e un'immagine pronta per CUDA con driver recenti e PyTorch. La macchina è pronta in pochi minuti.
4. 04Conferma che la scheda sia visibile prima di scaricare qualsiasi cosaUna singola chiamata a nvidia-smi riporta la GPU, la versione del driver e la VRAM libera. È un controllo di dieci secondi che risparmia un'ora di confusione.
5. 05Scarica i pesi sull'NVMe localeScarica il modello sul disco proprio dell'istanza invece che su un mount di rete. I pesi arrivano a decine di gigabyte e li caricherai più di una volta.
6. 06Avvia il server legato a localhostAvvia vLLM o Ollama su 127.0.0.1, conferma un completamento in locale, e solo dopo decidi come raggiungerlo dall'esterno.

vLLM, Ollama o llama.cpp: scegliere lo stack di serving

Tre stack coprono quasi ogni caso, e quello giusto dipende da quante richieste vedrà l'endpoint, non da quale sia tecnicamente il più impressionante.

• Ollama — la strada più breve dal nulla a un endpoint funzionante. Un solo comando scarica un modello quantizzato e lo serve dietro un'API compatibile con OpenAI. Ideale per un singolo utente, un prototipo o un assistente privato.
• vLLM — la risposta per la produzione. Il continuous batching e la paged attention permettono a una singola scheda di servire molte richieste concorrenti a un throughput più volte superiore a quello di un loop ingenuo. È la differenza tra un endpoint per te e un endpoint per un'applicazione.
• llama.cpp — il pragmatico. Quantizzazioni GGUF fino a 4-bit e oltre, offload su CPU per i layer che non entrano, e la soglia di memoria minima più bassa dei tre. È quello che permette a un modello sovradimensionato di girare comunque su una scheda sottodimensionata.
• TGI, SGLang e TensorRT-LLM sono ancora più veloci in scenari specifici. Prendili in considerazione solo dopo aver misurato un collo di bottiglia, non prima.

Tutti e tre espongono una route di chat-completions compatibile con OpenAI, quindi il codice applicativo scritto per un'API commerciale di solito richiede solo il cambio di un base-URL e nient'altro. Questa compatibilità è la ragione pratica per cui il self-hosting ha smesso di essere un progetto ed è diventato una scelta di configurazione.

Mantenere l'endpoint privato: non esporre mai la porta di inferenza

Un server di inferenza senza autenticazione è l'equivalente moderno di un database aperto. Gli scanner trovano nuovi IP entro poche ore, e un endpoint esposto significa che qualcun altro sta spendendo le tue ore di GPU — o leggendo tutto ciò che la tua applicazione invia attraverso di esso.

Se l'endpoint deve davvero essere pubblico — un prodotto e non un assistente privato — termina il TLS su un reverse proxy, richiedi un bearer token che ruoti periodicamente, e applica un rate limit per chiave. Mettere quel proxy su un piccolo VPS separato e lasciare la macchina GPU raggiungibile solo tramite il tunnel è la soluzione più pulita. È lo stesso ragionamento di ospitare un sito web senza KYC: la macchina che affronta internet dovrebbe contenere il meno possibile.

Fine-tuning: quando un pomeriggio su una scheda noleggiata batte una bolletta mensile

Il fine-tuning è l'argomento più forte a favore del noleggio rispetto all'abbonamento. Un run LoRA o QLoRA su un modello da 7B a 13B — qualche migliaio di esempi, una manciata di epoche — finisce in poche ore su una 4090 e costa esattamente le ore in cui è girato. L'adapter che ne esce è di poche centinaia di megabyte, quindi puoi conservare il checkpoint, distruggere l'istanza, e in seguito caricare quell'adapter su una scheda più piccola per il serving. I fine-tuning completi di un modello da 70B richiedono un budget diverso e vogliono una A100 o una H100 con spazio per lo stato dell'ottimizzatore, ma si misurano comunque in giorni, non in un contratto.

Il workflow che la fatturazione oraria abilita è semplice: distribuisci, allena, copia l'adapter fuori dalla macchina, distruggila. Paghi il calcolo che hai usato e non c'è nessuna scheda inattiva nel mezzo. Tieni il dataset sull'NVMe dell'istanza mentre lavori e riportalo fuori quando hai finito — nulla di ciò che lasci su una macchina noleggiata dovrebbe mai essere l'unica copia.

Il compromesso di privacy onesto di una GPU che non possiedi

Il self-hosting elimina la fuga più grande e più concreta: una terza parte che riceve ogni prompt, lo trattiene per una qualche finestra di conservazione, e decide da sola cosa farne. Su una scheda noleggiata il modello e i tuoi dati vivono dentro una macchina che risponde solo alla tua chiave. Ciò che il noleggio non può eliminare è l'host stesso. Chiunque abbia accesso fisico a un server in funzione può in linea di principio leggerne la memoria, e la crittografia completa del disco su una macchina remota ti protegge da un disco rubato, non da uno in funzione.

Quindi la domanda utile non è «l'host può vederlo» ma «l'host sa chi sono». L'hosting no-KYC risponde proprio a questa: un'email e una password, nessuna verifica, niente agli atti da far trapelare o da richiedere con un mandato. Pagare da un saldo in crypto elimina la banca. Fino a che punto spingere il lato dei pagamenti è una scelta di modello di minaccia — Bitcoin è pseudonimo, non anonimo, quindi delle coin ricondotte a un exchange verificato portano comunque da qualche parte, mentre ricaricare in Monero chiude quel varco a livello di protocollo.

Errori che sprecano silenziosamente ore di GPU

• Dimensionare solo sui pesi e dimenticare la KV cache, così il modello si carica felicemente e poi muore alla prima richiesta lunga.
• Servire in FP16 su una scheda che eseguirebbe lo stesso modello in 4-bit con tre volte il contesto, per una preoccupazione sulla qualità che nessuno ha mai davvero misurato.
• Scaricare quaranta gigabyte di pesi su un mount di rete, e poi chiedersi perché ogni riavvio richiede venti minuti.
• Lasciare il server legato a 0.0.0.0 «solo per fare un test dal mio laptop», che su un IP pubblico viene trovato lo stesso giorno.
• Pagare mensilmente per una scheda che resta inattiva venti ore al giorno, quando il carico di lavoro era in realtà sempre un job in batch.
• Fare benchmark con una richiesta alla volta, concludere che vLLM non vale la pena, e perdersi che tutto il suo vantaggio emerge sotto concorrenza.

Nessuno di questi è un guasto esotico. Sono ciò che succede quando la scheda viene scelta prima del modello. Decidi prima il modello e la quantizzazione, fai onestamente i conti sulla VRAM, tieni chiusa la porta, e un LLM in self-hosting è una delle cose meno impegnative che puoi lasciare in funzione.