Qualche settimana fa ho raccontato perché uso l'intelligenza artificiale in locale: niente abbonamenti che si sommano, niente dati che escono di casa. Quello che non avevo raccontato è il problema che arriva subito dopo, quando i modelli diventano più di uno e le macchine più di una. Questo articolo è il resoconto di come l'ho risolto, con i numeri misurati e gli errori che ho fatto per strada.
Il punto di partenza: due macchine, sette modelli
La mia infrastruttura domestica ha due protagonisti con caratteri molto diversi:
- Un Raspberry Pi 5 (8 GB), sempre acceso. Consuma pochissimo e ci girano già n8n, le pubblicazioni sui social e i backup. Niente GPU: i modelli che ci stanno sono piccoli (1-2 miliardi di parametri) e lenti, ma ci sono sempre.
- Un PC con una RTX 4060 Ti. Qui girano i modelli seri, fino a 27 miliardi di parametri, a velocità vera. Ma per risparmiare energia dalle 23 alle 8 il PC dorme.
Su entrambe le macchine gira Ollama, il motore che fa funzionare i modelli open source. In totale: due modelli piccoli sul Pi, cinque sul PC. Più, all'occorrenza, un servizio cloud a pagamento per quando serve potenza e il PC non c'è.
Il problema non era la potenza. Era l'ordine: ogni programma doveva sapere a quale macchina rivolgersi, con quale nome di modello, con quale chiave. Cambiare un modello significava cambiare dieci script. E se il PC dormiva, lo script falliva e basta.
L'idea: un portinaio unico
La soluzione ha un nome tecnico, gateway LLM, ma l'idea è semplice: un solo indirizzo a cui tutti i programmi fanno le loro domande. Il gateway sa quali modelli esistono, dove stanno e se sono raggiungibili, e smista.
Ho scelto LiteLLM, un progetto open source che parla lo stesso "dialetto" delle API di OpenAI. Il vantaggio è enorme: qualsiasi programma o libreria che sa usare ChatGPT sa usare anche il mio gateway, basta cambiare l'indirizzo. Gira in un container Docker sul Raspberry Pi, e la scelta non è casuale: il portinaio deve stare nella macchina che non dorme mai.
La parte più utile è che i programmi non chiedono più un modello per nome, ma un livello:
| Livello | Chi risponde di giorno | Se il PC dorme | Tempo misurato |
|---|---|---|---|
| veloce | modello da 1B sul Pi | stesso (è sul Pi) | 8-11 s |
| medio | modello da 8B sul PC | modello da 1,7B sul Pi (gratis) | 10-16 s |
| potente | modello da 27B sul PC | cloud, poi Pi come ultima spiaggia | circa 37 s |
| ragiona | 27B con ragionamento attivo | modello cloud di ragionamento | minuti, per problemi difficili |
Il giorno in cui cambierò il modello "potente" con uno migliore, lo modificherò in un solo file di configurazione. Nessuno script se ne accorgerà.
Il ripiego automatico: quando il PC dorme
Questa era la parte che mi interessava di più, e l'ho testata simulando un PC irraggiungibile. Il comportamento finale è questo:
- La prima richiesta prova il PC, aspetta il timeout (circa 25 secondi) e poi passa al piano B.
- Il gateway mette il PC "in pausa" per un minuto: le richieste successive vanno direttamente al piano B, in 1-3 secondi.
- Passato il minuto, riprova il PC. Se si è svegliato, torna a usarlo.
Ho scelto consapevolmente cosa costa e cosa no: il livello "medio" ripiega sempre su un modello del Pi, quindi resta gratuito. Solo "potente" e "ragiona" ripiegano sul cloud a pagamento, perché lì il salto di qualità giustifica qualche centesimo.
Una chat tutta mia, raggiungibile solo da me
Sopra al gateway ho installato Open WebUI: un'interfaccia tipo ChatGPT, dal browser o dal telefono, con tutti i livelli e i modelli nel menu a tendina. Anche questa gira sul Pi.
La cosa a cui tengo di più è dove è raggiungibile: solo dentro la mia rete privata virtuale (uso Tailscale, una VPN che collega i miei dispositivi ovunque si trovino). Non dalla rete di casa, non da internet. Il gateway stesso resta chiuso: ascolta solo sulla macchina locale e viene esposto alla VPN con un inoltro dedicato, protetto da chiave. Senza la chiave risponde "non autorizzato".
Gateway e chat insieme occupano circa 1,2 GB di RAM su un Raspberry Pi che ne ha 8. Il Pi continua a fare tutto il resto come prima.
Tre trappole che nessuna guida ti dice
1. I modelli che "pensano" restituivano risposte vuote. Alcuni modelli recenti, prima di rispondere, fanno un ragionamento interno. Con un limite di lunghezza normale, il ragionamento si mangiava tutto lo spazio e la risposta arrivava vuota: il livello "potente" impiegava 78 secondi per non dire nulla. Soluzione: ragionamento spento di default e un livello apposito, "ragiona", per quando serve davvero. Stessa cosa, scoperta dopo, sul modello cloud. Risultato: da 78 secondi a vuoto a 37 secondi con risposta.
2. Il ripiego c'era, ma aspettava ogni volta. Con la configurazione "prudente" (mettere in pausa un modello solo dopo due errori), ogni singola richiesta notturna aspettava l'intero timeout prima di ripiegare. Leggendo il codice del gateway ho capito il motivo: quando in un gruppo c'è un solo modello, le protezioni standard si disattivano per non lasciarti a secco. La soluzione è stata abbassare la soglia a zero errori tollerati: prima richiesta lenta, tutte le altre immediate.
3. Prima di migrare, conta. Finito il gateway, il passo successivo era spostarci sopra tutti gli script che usano l'AI. Prima di toccare qualcosa ho fatto un censimento dei job automatici, sia sul Pi sia sul PC, e la sorpresa è stata che nessuno di quelli attivi usava più l'AI. Alcuni erano stati spenti, altri usavano l'AI solo in una fase manuale. Migrare "per completezza" avrebbe significato toccare codice che non gira. Il gateway è pronto e aspetta: i prossimi script nasceranno già collegati.
A chi serve davvero un'architettura così
Non a tutti. Se usi un solo modello su un solo computer, Ollama da solo basta e avanza. Il gateway comincia ad avere senso quando:
- hai più macchine (un server sempre acceso e un PC potente che non lo è);
- hai più programmi che usano l'AI e non vuoi che ognuno gestisca chiavi e indirizzi per conto suo;
- vuoi decidere una volta sola cosa resta in casa, cosa può andare nel cloud e quanto sei disposto a spendere;
- gestisci dati che non devono uscire dallo studio o dall'azienda, ma vuoi comunque un piano B quando la macchina principale è spenta.
È esattamente lo scenario di molti studi professionali: un piccolo server sempre acceso, qualche postazione, dati sensibili e zero voglia di abbonamenti che si moltiplicano.
Conclusione
Con hardware che avevo già (un Raspberry Pi e il PC di tutti i giorni) e solo software open source, ho trasformato sette modelli sparsi in un servizio unico: un indirizzo, quattro livelli, ripiego automatico di notte e una chat privata raggiungibile solo da me. Il costo aggiuntivo è zero, tranne i centesimi del cloud quando lo chiedo io.
La lezione più utile, però, non è tecnica: misura prima di costruire, e conta prima di migrare. Due delle tre trappole le ho trovate solo perché ho testato con i cronometri e con il PC "spento" per finta, invece di fidarmi della configurazione sulla carta.