Questo articolo contiene link di affiliazione. ServerDiCasa partecipa al Programma Affiliazione Amazon EU e al programma di affiliazione Hostinger: se attivi un servizio passando dai link presenti in questa pagina, il sito riceve una commissione senza costi aggiuntivi per te. Questo non influisce sulle valutazioni, che restano basate sui test descritti.
Dopo aver verificato che un assistente AI locale su hardware di recupero funziona davvero, resta la domanda pratica: tenere OpenClaw in homelab o su hosting?
Le opzioni sono due. Sul mio homelab, che è già acceso ventiquattro ore su ventiquattro. Oppure su un piccolo server in hosting, pagando qualche euro al mese e togliendomi dei pensieri.
Come per il PC ricondizionato, non ho ancora deciso. Metto giù i criteri e i numeri, e ragiono ad alta voce.
Cosa deve fare, esattamente
La domanda “homelab o hosting” non ha una risposta astratta: dipende da cosa gira sopra. Nel mio caso un agente leggero che riceve messaggi, esegue qualche azione circoscritta e risponde. Poco carico, sempre disponibile, e con dentro dati che preferisco restino a casa mia.
È un profilo che cambia completamente il confronto rispetto a un’applicazione web che deve reggere traffico.
I punti a favore dell’homelab
Il modello locale è già lì e funziona. Nei test sull’affidabilità delle chiamate a strumento, qwen2.5:3b ha dato zero falsi positivi su otto frasi di cortesia, occupando 1,9 GB di VRAM e senza toccare la RAM di sistema. Su una macchina dove la memoria è la risorsa scarsa, è memoria che non usa nessun altro.
I sette secondi per azione non sono un problema. Un agente asincrono non ha nessuno che guarda il cursore lampeggiare: reagisce a un messaggio o rilegge un file di stato ogni mezz’ora. La latenza conterebbe in una chat, non qui.
L’accesso da remoto è già risolto. Ho Tailscale attivo sull’homelab: raggiungere una dashboard interna da fuori casa non richiede aprire porte né configurare nulla di nuovo.
Il CGNAT non blocca quello che serve. La mia connessione è quasi certamente dietro CGNAT, il che significa nessun indirizzo IP pubblico raggiungibile dall’esterno. Sembra un ostacolo, ma non lo è: un bot Telegram o WhatsApp funziona con connessioni in uscita, quindi il CGNAT è irrilevante. Lo sarebbe solo se dovessi esporre un servizio in entrata.
Il costo marginale è zero. La macchina è già accesa per Jellyfin, Home Assistant e il resto: aggiungere un processo non cambia la bolletta in modo percepibile.
I punti a favore dell’hosting
Non dipende dalla mia connessione né dalla mia corrente. Un blackout, un guasto del router, un problema dell’operatore: sull’homelab tutto questo spegne l’agente. Su un server esterno no. Per un servizio che deve rispondere quando serve, è l’argomento più forte.
Non ruba risorse a una macchina già carica. Il mio server ha 8 GB di RAM e sedici container attivi: come ho raccontato nell’articolo sulla RAM, ogni cosa che aggiungo se la prende da qualcun altro.
Isola i guasti. Se sbaglio una configurazione su un server dedicato all’agente, non porto giù il media server di casa. Su una macchina condivisa il rischio c’è.
Un VPS di fascia entry su Hostinger costa pochi euro al mese, ed è la soluzione che valuterei se decidessi di spostarmi.
Il punto che sposta tutto: dove gira il modello
C’è un aspetto che il confronto “homelab contro hosting” di solito non considera, e nel mio caso è decisivo.
L’agente in sé è leggerissimo: pochi megabyte, gira ovunque. Quello che pesa è il modello linguistico. E un VPS economico non ha una GPU: farci girare un modello da 3 miliardi di parametri significa tornare all’inferenza su CPU, con le prestazioni che ho misurato nel primo articolo della serie.
Le combinazioni possibili diventano quindi tre, non due:
| Configurazione | Costo | Dati fuori casa | Dipende dalla mia connessione |
|---|---|---|---|
| Tutto sull’homelab | 0 € | No | Sì |
| Agente in hosting, modello a casa | pochi €/mese | No | Sì (per il modello) |
| Agente in hosting, modello via API | hosting + consumo API | Sì | No |
La seconda riga è quella che sembra furba e invece non risolve niente: sposti l’agente fuori ma resti legato alla connessione di casa per raggiungere il modello, quindi ti tieni il problema e in più paghi.
La terza funziona davvero, ma rinuncia al motivo per cui volevo un assistente locale: i dati escono di casa e finiscono su un servizio esterno. A quel punto tanto vale usare un assistente commerciale, che è più bravo.
Dove sono arrivato
Messa così, la scelta non è fra due opzioni ma fra due priorità.
Se conta che i dati restino a casa, l’homelab vince e non c’è partita: è l’unica configurazione in cui il modello gira su hardware mio, e per giunta a costo marginale zero su una macchina già accesa.
Se conta che il servizio risponda sempre, vince l’hosting — ma a patto di accettare le API esterne, cioè di rinunciare alla privacy che era il punto di partenza.
Nel mio caso specifico la prima priorità pesa più della seconda: un agente che gestisce cose di casa non è un servizio critico, e se resta fermo mezza giorno per un blackout non muore nessuno. Ma è una valutazione mia, legata a cosa gli faccio fare.
Se il tuo agente deve rispondere a clienti, o se ci costruisci sopra qualcosa da cui dipendono altre persone, il ragionamento si ribalta.
Cosa guarderei prima di decidere
- Quanto ti serve davvero che sia sempre acceso. Se la risposta onesta è “sarebbe comodo”, non è un requisito.
- Se hai già una VPN verso casa. Con Tailscale o simili, metà dei vantaggi dell’hosting spariscono.
- Quanta RAM ti resta libera sulla macchina che hai già. Se sei al limite, aggiungere un agente peggiora tutto il resto.
- Se sei disposto a far uscire i dati. È la domanda che decide, e va fatta all’inizio invece che alla fine.
Domande frequenti
Serve un IP pubblico per far girare un agente in casa?
Dipende da come lo raggiungi. Se usi un bot Telegram, Discord o WhatsApp la comunicazione avviene con connessioni in uscita e il CGNAT non è un ostacolo. Serve un indirizzo raggiungibile solo se devi esporre un servizio in entrata, e anche lì una VPN come Tailscale risolve senza aprire porte.
Quanto costa un VPS per un assistente AI?
L’agente in sé gira su qualsiasi piano entry level, perché occupa pochi megabyte. Il costo vero non è il server: è il modello. Senza GPU sul VPS devi scegliere fra inferenza su CPU, molto lenta, o API esterne a consumo — e quest’ultima voce può superare abbondantemente il canone dell’hosting.
Conviene tenere il modello in casa e l’agente in hosting?
È la soluzione che sembra più elegante e che invece risolve meno di quanto prometta: l’agente diventa indipendente dalla tua corrente, ma per funzionare deve comunque raggiungere il modello a casa tua. Se salta la connessione, sei fermo lo stesso — e nel frattempo paghi un canone.
Conclusione
Come per il PC ricondizionato, sulla scelta fra OpenClaw in homelab o su hosting la conclusione utile non è quale opzione ho scelto io, ma quale domanda va fatta per prima. E qui la domanda è una sola: sei disposto a far uscire i dati di casa tua?
Se la risposta è no, la discussione su homelab o hosting è già finita — perché senza una GPU sul server esterno, l’unico modo per tenere il modello fuori casa è affidarlo a qualcun altro.
Quando avrò deciso, e soprattutto quando avrò qualche settimana di funzionamento reale alle spalle, ne scriverò il seguito.
Questo articolo fa parte di IA locale su hardware di recupero, la serie in cui provo a far girare modelli in locale su un PC del 2013 misurando tutto: cosa gira davvero, quanto costa tenerlo acceso, a cosa serve. Nell’indice ci sono tutti gli articoli in ordine.
