6 giugno 2026 · 11 min lettura
Self-HostingCome far girare ollama proxmox lxc senza GPU: zstd mancante, systemd da zero, 13-15 t/s reali con llama3.2 su CPU AMD Ryzen.
Intelligenza ArtificialeMoneyPrinterTurbo con Ollama self-hosting: cos'è, feature e setup Docker per generare video AI in locale gratis. Parte 1, con un asterisco su Pexels.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
Ollama e Open WebUI girano in locale, ma la config default manda dati fuori. Guida pratica: cosa bloccare, come isolare l'inferenza senza cloud nel 2026.
Cosa succede se carichi una notizia in un programma e chiedi a una folla di agenti AI di prevedere come reagirà internet?
È esattamente la promessa di MiroFish, un motore di predizione AI che ho trovato per caso su GitHub. Non genera un testo, non risponde a una domanda: simula. Costruisce una comunità finta — sviluppatori, self-hoster, account aziendali — la fa parlare per sedici round e poi ti consegna un report su come andrà a finire. Suona come fantascienza, o come l'ennesimo demo che funziona solo nel video di lancio. Così l'ho installato per davvero, in locale sul mio hardware, e ho provato a romperlo: MiroFish in locale, sulla mia GPU, zero cloud.
Lo spoiler tecnico, per chi vuole solo quello: ci si riesce, gira tutto in locale e gratis sulla mia GPU — ma il punto di rottura non era dove pensavo. Non la VRAM, non WSL, non il cloud. Era il modo in cui un singolo modello scrive le sue chiamate ai tool. Ci arrivo. Partiamo da cosa fa questa cosa.
MiroFish è un motore di simulazione multi-agente per la predizione, il tipo di agenti AI di predizione self-hosted che puoi tenere in casa: gli dai un "seme" — un report, una notizia, un annuncio — descrivi cosa vuoi prevedere, e lui istanzia una folla di agenti AI dotati di personalità e memoria che simulano l'evoluzione di una community su Reddit o Twitter per anticiparne la reazione. Non è un chatbot che ti dà un'opinione: è una simulazione sociale dove ogni agente posta, commenta, mette like e risponde agli altri, e dal rumore emerge una previsione. Il progetto è rilasciato sotto licenza AGPL-3.0.
Sotto il cofano lo stack è una catena di pezzi interessanti. Il backend è in Flask, il frontend in Vue. Il motore di simulazione vero e proprio è OASIS, il framework social multi-agente di camel-ai capace — almeno sulla carta — di modellare fino a un milione di utenti, mescolando agenti rule-based con agenti LLM più realistici (paper arXiv 2411.11581). La memoria degli agenti vive su Zep, un knowledge graph temporale che tiene traccia di chi ha detto cosa e quando, con intervalli di validità per ogni relazione (paper arXiv 2501.13956). E l'intelligenza vera arriva da un LLM esposto via API OpenAI-compatibile.
Tieni a mente questa frase, perché è il bivio dove l'intera prova ha rischiato di deragliare — la stessa scelta tra agenti AI self-hosted vs cloud che torna ogni volta che provi a portare un sistema agentico sotto la tua scrivania.
Installare MiroFish sul mio homelab è stato meno doloroso del previsto, ma non indolore. L'ho messo su WSL con Python 3.12 gestito da uv, perché il backend Flask e il frontend Vue vogliono ciascuno il proprio ambiente, e camel-ai si trascina dietro mezzo deep-learning stack — torch incluso. Il primo download non è leggero: metti in conto qualche giga e un po' di pazienza mentre le dipendenze si sistemano.
L'ambiente Python l'ho preparato con uv, che risolve e installa tutto in una frazione del tempo di pip:
uv venv --python 3.12
source .venv/bin/activate
uv pip install -r requirements.txt # camel-ai si porta dietro torch: aspettaOltre al codice servono due chiavi. Una per l'LLM (qualunque endpoint OpenAI-compatibile va bene) e una per Zep, che ha un free tier sufficiente per giocare. Il repo, va detto, raccomanda ufficialmente il modello Qwen-plus di Alibaba via cloud, con un avvertimento che a posteriori suona come una profezia: "High consumption, try simulations with fewer than 40 rounds first". Tradotto: costa, e brucia token. Una raccomandazione del genere, per chi ha un homelab, è una sfida, non un consiglio.
Per mettere alla prova MiroFish ho costruito un seme fittizio ma plausibile: l'annuncio che un database open-source immaginario, NimbusDB, passa da licenza Apache-2.0 a Business Source License 1.1. La domanda alla simulazione era semplice e cattiva: come reagirà la community di sviluppatori e self-hoster? Ci sarà un fork? Ho scelto questo scenario perché non è affatto fantascienza — è la storia degli ultimi anni dell'open source infrastrutturale.
Il copione l'abbiamo già visto recitare da attori veri. HashiCorp ha spostato Terraform da MPL a BSL 1.1 il 10 agosto 2023, e quindici giorni dopo la community aveva già forkato: nasceva OpenTofu, adottato dalla Linux Foundation e arrivato a una release stabile il 10 gennaio 2024. Redis è passato da BSD a un doppio RSALv2 + SSPL il 20 marzo 2024, con la motivazione esplicita che i cloud provider "commoditizzano" il suo lavoro senza restituire nulla. La BSL stessa, nata in MariaDB nel 2016, non è open source perché limita l'uso in produzione: è una springing license che converte ad aperto solo dopo al massimo quattro anni. Insomma, NimbusDB è inventato, ma ogni self-hoster ha vissuto la sua versione reale.
La parte sorprendente è cosa fa MiroFish con questo seme prima ancora di simulare. Legge l'annuncio e ne estrae automaticamente un'ontologia: entità (il database, la vecchia licenza, la nuova, i cloud provider, la community) e le relazioni tra loro. È il materiale grezzo con cui poi popola il knowledge graph e gli agenti.
Da quell'ontologia MiroFish costruisce il knowledge graph temporale su Zep, dove ogni entità diventa un nodo e ogni relazione un arco etichettato e datato. È la memoria condivisa su cui gli agenti pescheranno durante il dibattito.
La prima simulazione non è mai arrivata in fondo, e il motivo è banale quanto frustrante: ho finito i token. Per evitare di pagare Qwen-plus ero partito dal free tier di Groq, agganciando il modello da 70 miliardi di parametri. Funzionava benissimo — finché a metà corsa il budget giornaliero da centomila token si è esaurito e l'API ha iniziato a sputare errori 429 uno dietro l'altro. La simulazione si è fermata a metà strada, con metà community ancora muta.
Qui c'è una lezione che vale per qualunque sistema multi-agente, non solo per MiroFish: gli agenti sono ingordi. Ogni round moltiplica le chiamate per il numero di agenti, e una conversazione di sedici round con una folla di personaggi divora token a una velocità che un singolo chatbot non si sogna. Il free tier di un cloud, per questo tipo di carico, è un giocattolo che si scarica prima di pranzo.
È lo stesso trucco che uso per far girare AI in locale a costo zero con Ollama in altri progetti.
Una precisazione sull'infrastruttura, perché nel mio caso ci sono due GPU. La 5080 è sulla workstation locale; sul server Proxmox vive invece una più modesta 2070 Super. Per questo lavoro è bastata la workstation: Ollama gira lì, MiroFish gira lì sopra WSL, e tutto resta in localhost. Niente data center, niente bolletta a consumo.
Il puntamento è una riga di configurazione. Basta dire a MiroFish che l'endpoint OpenAI ora è Ollama:
ollama pull llama3.1:8b
ollama serve # API OpenAI-compatibile su http://localhost:11434/v1# .env di MiroFish — l'LLM ora è locale, gratis, senza rate-limit
LLM_BASE_URL=http://localhost:11434/v1
LLM_API_KEY=ollama
LLM_MODEL=llama3.1:8bZero costi, zero rate-limit, zero 429. Pensavo di aver risolto. E invece la simulazione ha smesso di funzionare in un modo nuovo e molto più subdolo.
Non era la GPU, non era l'ambiente: il vero problema era il function-calling del modello. Una volta in locale la simulazione si bloccava sempre nello stesso punto, e ho perso un po' di tempo a sospettare i soliti colpevoli. La VRAM era sufficiente, WSL reggeva, il recommendation engine girava. Eppure camel-ai andava in stallo a metà round con un messaggio criptico: "Multiple messages returned in step()".
Stavo usando qwen2.5:14b, un modello più grande e teoricamente più sveglio del piccolo llama. La trappola era proprio lì. OASIS fa lavorare gli agenti tramite function-calling: ogni azione — postare, commentare, mettere like — è una chiamata a un tool con argomenti strutturati. E qwen2.5:14b quelle chiamate le scriveva sbagliate: un argomento di troppo, un payload malformato, e camel-ai riceveva più messaggi dove ne aspettava uno solo. Da lì, lo stallo. Il modello non era stupido. Era indisciplinato.
La conferma è nella documentazione di Ollama. La pagina ufficiale sul tool-support elenca i modelli che generano chiamate conformi — Llama 3.1, Mistral Nemo, Firefunction v2, Command-R+ — e qwen2.5 in quella lista non c'è. Llama 3.1, addestrato da Meta proprio per il tool-use, sì. Così ho cambiato un'unica variabile:
# da questo (stalla):
LLM_MODEL=qwen2.5:14b
# a questo (gira fino in fondo):
LLM_MODEL=llama3.1:8bCon llama3.1:8b la simulazione è andata in porto al primo colpo. Stesso hardware, stesso codice, stessa GPU — un modello più piccolo che però scrive le sue chiamate come si deve. Ed è chiaro adesso perché il repo raccomanda Qwen-plus cloud e non un qwen locale qualsiasi: il modello cloud è messo a punto per il tool-calling, quello scaricato da Ollama no.
Con il modello giusto in cattedra, gli agenti hanno finalmente preso vita. E qui le cose si sono fatte sorprendenti.
A simulazione completa è successo qualcosa che non mi aspettavo: un dibattito che sembrava vero. Sedici round, tredici post pubblicati dagli agenti, e soprattutto agenti che si rispondevano e si citavano a vicenda invece di parlare ognuno per conto suo. Non era una sequenza di monologhi: era una discussione con fazioni, attriti e argomenti che rimbalzavano da un post all'altro.
Sorprendente: la simulazione ha ricreato spontaneamente le posizioni reali del dibattito open source. L'agente che impersonava i cloud provider ha difeso il cambio licenza con una frase che potrebbe uscire da un comunicato di Redis:
"After years of profiting without contributing back, this change is necessary." — l'agente "cloud provider" nella simulazione
Dall'altra parte, l'agente self-hoster faceva esattamente la domanda che fa ogni self-hoster davanti a un cambio licenza: e adesso ci sarà un fork? Il timore del fork — quello che nella realtà ha generato OpenTofu da Terraform e Valkey da Redis — è emerso da solo nel dibattito, senza che io lo suggerissi. Gli agenti hanno trovato la frattura giusta.
Alla fine MiroFish ha distillato tutto il rumore degli agenti in un report di predizione strutturato in quattro sezioni:
Confrontato con la cronaca reale — Terraform forkato in quindici giorni, Redis che genera Valkey — il report non era profetico, ma era coerente: leggeva le stesse linee di tensione che hanno mosso i casi veri. Ed è il massimo che puoi chiedere a una simulazione partita da un seme inventato.
MiroFish funziona, e la cosa più sorprendente è che funziona interamente in locale, gratis, sulla GPU di una workstation. Questo è il vero takeaway per chi ha un homelab: un sistema multi-agente con knowledge graph e sedici round di simulazione non è più roba da budget cloud aziendale. Gira sotto la scrivania, a patto di avere abbastanza VRAM e — soprattutto — il modello giusto.
Cosa non funziona: la simulazione multi-round è fragile. Col modello sbagliato si rompe in modo silenzioso e difficile da diagnosticare, e ho perso più tempo a inseguire la GPU e WSL che a guardare dove stava davvero il problema. È un sistema giovane, con tutte le ruvidità del caso. Se ti aspetti un prodotto chiavi in mano, non è ancora questo.
Vale anche quando costruisci un agente AI locale, zero cloud per tutt'altro scopo.
E tu, la prossima volta che un sistema di agenti si blocca a metà, sospetterai ancora la VRAM — o andrai a leggere come parla il modello ai suoi tool?
Fonti: MiroFish, OASIS (arXiv 2411.11581), Zep (arXiv 2501.13956), Ollama tool support, OpenTofu fork di Terraform, Redis dual licensing.