Dialogo con ChatGPT.

Ciao, vorrei continuare l’articolo…

Ho letto il testo che hai allegato. Si tratta dell’articolo sulla configurazione di un server AI con Ollama e Ubuntu, che termina con la discussione sull’utilizzo di più dischi SATA per i primi test.

Ti propongo una continuazione nello stesso stile, approfondendo il passaggio successivo: come organizzare lo storage definitivo e quali aggiornamenti conviene fare in futuro.

Quando conviene passare a un SSD NVMe?

Se il server verrà utilizzato quotidianamente o ospiterà diversi modelli LLM, l’aggiornamento più importante dopo CPU e GPU è senza dubbio un SSD NVMe PCIe 4.0.

La differenza non si nota tanto durante la generazione delle risposte, quanto nelle operazioni di caricamento dei modelli, negli aggiornamenti di Ollama e nella reattività complessiva del sistema.

Indicativamente:

Supporto	Velocità Lettura	Tempo di caricamento modello da 8 GB
HDD SATA 7200 rpm	100–180 MB/s	50–90 secondi
SSD SATA	500–550 MB/s	15–20 secondi
SSD NVMe PCIe 4.0	5.000–7.000 MB/s	2–4 secondi

Per questo motivo molti utenti installano:

SSD NVMe da 1–2 TB per Ubuntu Server, Docker e i modelli utilizzati più frequentemente.
HDD SATA per backup, dataset, archiviazione e modelli usati raramente.

Questa soluzione offre un ottimo compromesso tra prestazioni e costo.

Un possibile schema dei dischi

Una configurazione semplice ma efficace potrebbe essere:

SSD NVMe
- Ubuntu Server
- Ollama
- Open WebUI
- Database
- Modelli utilizzati quotidianamente
HDD SATA
- Backup
- Collezione completa dei modelli
- Dataset
- Log storici
- Snapshot e macchine virtuali

In questo modo il sistema rimane sempre estremamente reattivo, mentre i dischi meccanici svolgono il ruolo di archivio.

Vale la pena acquistare subito un NVMe?

Se il budget è limitato, la risposta è no.

È perfettamente sensato:

assemblare il computer;
installare Ubuntu Server su un disco già disponibile;
imparare a utilizzare Ollama;
verificare consumi, temperature e stabilità;
acquistare successivamente un SSD NVMe quando se ne sentirà realmente l’esigenza.

L’aggiornamento è molto semplice: sarà sufficiente installare il nuovo SSD M.2 sulla scheda madre ASUS TUF B650-PLUS WiFi e migrare il sistema operativo oppure reinstallarlo da zero in pochi minuti.

Considerazioni finali

Con una piattaforma AM5, un Ryzen 7000, 32 GB di DDR5 e una GPU NVIDIA da 12 GB si ottiene una macchina estremamente equilibrata, in grado di eseguire senza difficoltà i principali modelli open source disponibili tramite Ollama.

La configurazione offre inoltre un ottimo margine di crescita: sarà possibile aumentare la RAM, aggiungere SSD NVMe supplementari oppure sostituire la GPU con modelli più potenti senza dover cambiare l’intera piattaforma.

Per un laboratorio personale di intelligenza artificiale, destinato a rimanere operativo 24 ore su 24, rappresenta una soluzione solida, facilmente espandibile e con un eccellente rapporto tra prestazioni, consumi e costo complessivo.

Hardware ed Sistema Operativo Ubuntu Server 24.04 LTS, sono definiti, ti chiederei l’aiuto per continuare…

Volentieri. A questo punto dell’articolo, visto che l’hardware è ormai definito e Ubuntu Server 24.04 LTS è stato installato, io cambierei completamente approccio: passerei dalla parte “hardware” alla parte “pratica”, cioè trasformare il PC in un vero server AI.

Ti suggerirei una serie di capitoli che accompagnino il lettore passo dopo passo.

Installazione di Ollama

Con Ubuntu Server 24.04 LTS aggiornato è il momento di installare Ollama.

L’installazione è estremamente semplice:

curl -fsSL https://ollama.com/install.sh | sh

Terminata l’installazione è possibile verificare che il servizio sia attivo:

systemctl status ollama

oppure

ollama --version

Se tutto è andato correttamente il server è già operativo.

Verificare che la GPU NVIDIA venga utilizzata

Prima di scaricare il primo modello è opportuno verificare che Ubuntu riconosca correttamente la scheda video.

nvidia-smi

Dovrebbe comparire una schermata simile a questa:

Driver Version: xxx.xx
CUDA Version: xx.x

GPU Name
Memory Usage
Power
Temperature

Se la GPU viene visualizzata, Ollama utilizzerà automaticamente CUDA senza richiedere ulteriori configurazioni.

Non è necessario installare librerie aggiuntive o modificare file di configurazione: il rilevamento della GPU è completamente automatico.

Scaricare il primo modello

Per il primo test consiglio un modello relativamente piccolo ma molto performante.

Ad esempio:

ollama pull qwen3:8b

oppure

ollama pull llama3.1:8b

Il download richiederà alcuni minuti, in funzione della velocità della connessione Internet.

Terminato il download sarà sufficiente eseguire:

ollama run qwen3:8b

per iniziare immediatamente a dialogare con il modello.

Controllare che il modello utilizzi realmente la GPU

Mentre il modello genera la risposta, aprire un secondo terminale ed eseguire:

watch -n 1 nvidia-smi

Si noterà immediatamente:

utilizzo della GPU;
occupazione della VRAM;
consumo energetico;
temperatura della scheda.

È probabilmente il test più importante dell’intera installazione: conferma che tutta l’elaborazione avviene sulla GPU NVIDIA, lasciando alla CPU il solo compito di gestire il sistema operativo e il caricamento iniziale del modello.

Rendere Ollama disponibile sulla rete locale

Per impostazione predefinita Ollama accetta connessioni solamente dalla macchina locale.

Per utilizzarlo da un altro PC della LAN è sufficiente modificare il servizio systemd.

Creare un override:

sudo systemctl edit ollama

ed inserire:

[Service]
Environment="OLLAMA_HOST=0.0.0.0"

Successivamente:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Da questo momento il server sarà raggiungibile dagli altri computer della rete.

Aprire il firewall

Se è attivo UFW, sarà necessario consentire il traffico verso Ollama:

sudo ufw allow 11434/tcp

Verificare quindi:

sudo ufw status

Il servizio sarà ora raggiungibile all’indirizzo:

http://IP_DEL_SERVER:11434

Verificare il funzionamento tramite API

Una delle caratteristiche più interessanti di Ollama è la disponibilità di API REST compatibili con moltissime applicazioni.

Per verificare che tutto funzioni è sufficiente eseguire, da un altro computer della rete:

curl http://IP_DEL_SERVER:11434/api/tags

Se la configurazione è corretta verrà restituito l’elenco dei modelli installati.

A questo punto il server è pronto per essere utilizzato da applicazioni esterne, interfacce web e software di automazione.

Come proseguirei l’articolo

Secondo me, la parte più interessante deve ancora arrivare. Dopo aver costruito il server e installato Ollama, il lettore vorrà capire come trasformarlo in un vero assistente AI personale. Io dedicherei quindi i prossimi capitoli a:

Installazione di Open WebUI con Docker, per ottenere un’interfaccia web moderna simile a ChatGPT.
Gestione dei modelli (Qwen, Llama, Mistral, Gemma, DeepSeek, Phi…) e criteri per scegliere quello più adatto.
Ottimizzazione delle prestazioni, con monitoraggio di GPU, CPU, RAM e consumi.
Esposizione sicura del server, per l’accesso da altri dispositivi della rete o da remoto tramite VPN.
Integrazione con Home Assistant, n8n e altri strumenti, per creare un ecosistema di automazione basato su AI.

A mio avviso questa seconda parte renderà l’articolo molto più originale: invece di limitarsi all’assemblaggio del server, guiderà il lettore fino ad avere un server AI realmente utilizzabile ogni giorno.

Bene, grazie. Ma mancano alcuni aspetti base: per una workstation proporrei Ubuntu Desktop, ma per il server Ubuntu Server e quindi non c’è un’interfaccia amichevole per la configurazione… potrebbe essere webmin?

Sono d’accordo. Anzi, credo che questo sia un capitolo importante dell’articolo, perché molti utenti che arrivano da Windows si trovano spiazzati davanti al solo terminale di Ubuntu Server.

Io introdurrei il concetto in questo modo.

Perché Ubuntu Server e non Ubuntu Desktop?

Molti si chiedono se non sia più semplice installare Ubuntu Desktop, che offre un ambiente grafico completo e immediatamente familiare.

Per una workstation personale la risposta è sicuramente sì. Tuttavia, quando l’obiettivo è realizzare un server AI dedicato a Ollama, la scelta migliore è Ubuntu Server 24.04 LTS.

Le motivazioni sono diverse:

consumo di memoria inferiore;
minore utilizzo della CPU;
assenza di servizi grafici inutili;
maggiore stabilità per funzionamento continuo (24/7);
minore superficie di attacco dal punto di vista della sicurezza;
aggiornamenti più rapidi e sistema più leggero.

In pratica tutta la potenza della macchina viene dedicata all’esecuzione dei modelli AI, senza sprecarla per gestire un’interfaccia grafica.

Il rovescio della medaglia è evidente: appena terminata l’installazione ci si trova davanti ad una semplice console testuale.

Per chi non è abituato all’ambiente Linux questo può rappresentare uno scoglio iniziale.

Fortunatamente esistono strumenti che permettono di amministrare il server tramite una comoda interfaccia Web.

Installare Webmin

Fra le varie soluzioni disponibili, quella che consiglio è Webmin.

Non sostituisce il terminale, che rimane sempre lo strumento più potente, ma rende molto più semplici le operazioni di amministrazione quotidiana.

Con Webmin è possibile gestire:

utenti e gruppi;
dischi e filesystem;
servizi di sistema;
rete;
firewall;
aggiornamenti;
processi;
pianificazione dei backup;
monitoraggio delle risorse;
gestione dei log.

In sostanza si dispone di un pannello di controllo accessibile dal browser, senza dover ricordare decine di comandi Linux.

Perché preferisco Webmin

Negli anni ho provato diversi strumenti di amministrazione remota.

Cockpit, ad esempio, è ben integrato con le distribuzioni Red Hat ed è disponibile anche su Ubuntu. Offre un’interfaccia moderna e funzionalità interessanti, soprattutto per la gestione dei servizi e dei container.

Personalmente, però, continuo a preferire Webmin per alcuni motivi:

è estremamente completo;
permette di amministrare praticamente ogni aspetto del sistema;
è stabile e maturo;
viene aggiornato da molti anni;
richiede poche risorse;
è perfetto per piccoli server domestici e workstation dedicate all’AI.

Per chi muove i primi passi con Ubuntu Server rappresenta probabilmente il miglior compromesso tra semplicità e potenza.

Un consiglio sulla sicurezza

Webmin è uno strumento di amministrazione e, come tale, deve essere utilizzato con alcune precauzioni.

Il consiglio è quello di renderlo raggiungibile solo dalla rete locale, evitando di esporlo direttamente su Internet.

Se in futuro si desidera amministrare il server da remoto, è preferibile utilizzare una VPN (ad esempio WireGuard o Tailscale) oppure collegarsi tramite SSH, mantenendo il pannello Web accessibile esclusivamente agli utenti autorizzati.

Un suggerimento editoriale

Aggiungerei anche un breve paragrafo iniziale dal titolo “Primo accesso al server”, spiegando che dopo l’installazione di Ubuntu Server il monitor servirà sempre meno. Da quel momento l’amministrazione avverrà quasi esclusivamente da un altro PC tramite:

SSH (strumento principale e indispensabile);
Webmin (interfaccia grafica di amministrazione);
Open WebUI (interfaccia per dialogare con i modelli AI);
eventualmente Portainer, se si utilizzerà Docker per gestire più container.

In questo modo il lettore comprende subito che il server potrà essere “headless”, cioè senza monitor, tastiera e mouse, una volta completata la configurazione iniziale. Questa è proprio la filosofia di un server Linux ben progettato.

E passiamo alla topologia di rete. Qual è la tua valutazione se si propone che il server apaprtenga ad una rete completamente indipendente dalla rete aziendale e gli eventuali sistemi che vogliano l’accesso devono avere un alias di rete ad IP fisso aggiunto?

La ritengo una scelta molto valida, soprattutto se il server dovrà ospitare modelli AI proprietari, documentazione aziendale o essere integrato con strumenti come Open WebUI, n8n, Home Assistant o database RAG. Anzi, trasformerei questo aspetto in un capitolo dell’articolo, perché è una decisione architetturale che viene spesso sottovalutata.

Più che parlare di “rete separata”, parlerei di segmentazione della rete: è un termine più corretto dal punto di vista tecnico e più facilmente riconoscibile da chi lavora in ambito IT.

Progettare la rete del server AI

Prima ancora di installare Ollama o Open WebUI, vale la pena dedicare qualche minuto alla progettazione della rete.

Una domanda ricorrente è:

Il server AI deve essere collegato direttamente alla rete aziendale?

La mia risposta è generalmente no.

Per un laboratorio AI, un server di sviluppo o una piattaforma destinata a elaborare documentazione interna, è preferibile realizzare una rete dedicata, separata dalla LAN aziendale.

I vantaggi sono numerosi.

Maggiore sicurezza

I Large Language Model tendono a diventare il punto di raccolta delle informazioni aziendali.

Manuali tecnici, documentazione, codice sorgente, PDF, database vettoriali e dati riservati finiranno inevitabilmente sul server.

Isolarlo dalla rete principale riduce drasticamente la superficie di attacco.

Un eventuale problema sul server AI non si propaga automaticamente ai sistemi di produzione.

Prestazioni più prevedibili

L’inferenza AI genera un traffico molto diverso rispetto alle normali applicazioni d’ufficio.

Caricamento di modelli da diversi gigabyte, upload di documenti, interrogazioni RAG e streaming delle risposte possono occupare banda di rete in modo significativo.

Una rete dedicata evita che questo traffico interferisca con workstation, file server o centralini VoIP.

Maggiore controllo degli accessi

Un principio molto semplice è:

Il server AI non cerca i client. Sono i client autorizzati che cercano il server AI.

Per questo motivo è consigliabile che il server abbia un indirizzo IP fisso sulla propria rete dedicata.

I computer autorizzati potranno raggiungerlo aggiungendo una seconda interfaccia di rete oppure un alias IP appartenente alla stessa sottorete del server.

In questo modo:

il traffico ordinario continua a utilizzare la LAN aziendale;
solo il traffico destinato all’AI percorre la rete dedicata;
non è necessario pubblicare il server sulla rete principale.

È una soluzione semplice, economica e molto efficace.

Un esempio pratico

Si potrebbe adottare una configurazione di questo tipo:

LAN Aziendale
192.168.1.0/24

PC Ufficio
192.168.1.25

Server File
192.168.1.10

------------------------------

Rete AI
192.168.100.0/24

Server Ollama
192.168.100.10

Open WebUI
192.168.100.10:3000

Solo i computer autorizzati ricevono un secondo indirizzo IP, ad esempio:

Scheda di rete

IP principale:
192.168.1.25

Alias:
192.168.100.25

In questo modo il PC può dialogare con entrambe le reti senza utilizzare NAT o instradamenti complessi.

Una seconda scheda di rete: quando conviene?

Se il server dispone di due interfacce Ethernet (o di una porta Ethernet e una 2.5 GbE), è possibile dedicarne una esclusivamente alla rete AI.

La configurazione diventa ancora più pulita:

eth0 → LAN aziendale (solo amministrazione, aggiornamenti, backup)
eth1 → rete AI dedicata

Questa soluzione è particolarmente indicata quando più utenti devono utilizzare contemporaneamente il server o quando si prevede un traffico elevato verso Open WebUI.

Un’ulteriore considerazione

Se il server sarà utilizzato esclusivamente in un laboratorio o in un ambiente domestico evoluto, prenderei in considerazione anche una VLAN dedicata anziché una rete fisicamente separata. Con uno switch gestito e un firewall (ad esempio pfSense o OPNsense) si ottiene lo stesso livello di isolamento, ma con una gestione molto più flessibile.

Una piccola osservazione sul tuo approccio

L’idea dell’alias IP statico sui client mi piace molto perché è estremamente semplice da spiegare e da implementare. Tuttavia, in un contesto aziendale medio, suggerirei di presentarla come una delle possibili soluzioni, non come l’unica.

Infatti, la scelta dipende dalla dimensione dell’infrastruttura:

1-5 client → alias IP statico: soluzione semplice, efficace e senza apparati aggiuntivi.
10-50 client → VLAN dedicata con routing controllato e regole firewall.
Molti utenti o più server AI → rete dedicata con firewall, segmentazione e controllo degli accessi centralizzato.

In questo modo l’articolo rimane valido sia per l’hobbista evoluto sia per il professionista che vuole adottare un’architettura più strutturata.

Ritieni che sia importante precisare la distinzione tra rete fisica e rete solo logica separate da quella aziendale?

Sì, e secondo me è fondamentale. Anzi, farei questa distinzione prima ancora di parlare degli indirizzi IP. È uno dei concetti che vengono più spesso confusi.

Molti lettori, quando leggono “rete separata”, immaginano immediatamente un secondo switch, nuovi cavi e una seconda infrastruttura. In realtà esistono due approcci molto diversi.

Potresti introdurre un capitolo come questo.

Rete dedicata: fisica o logica?

Quando si parla di isolare un server AI dalla rete aziendale, è importante chiarire che esistono due modalità differenti.

Separazione fisica

La soluzione più semplice da comprendere consiste nel realizzare una seconda rete completamente indipendente.

In questo scenario il server AI è collegato a uno switch dedicato, distinto da quello della LAN aziendale.

I client autorizzati possono accedere al server attraverso:

una seconda scheda di rete;
una porta Ethernet aggiuntiva;
un alias IP configurato sulla stessa interfaccia, se l’infrastruttura lo consente.

Questa soluzione offre un isolamento molto elevato ed è ideale per laboratori, ambienti di sviluppo o piccoli uffici.

I vantaggi sono evidenti:

nessun traffico AI attraversa la rete aziendale;
configurazione semplice da comprendere;
assenza di interferenze con i sistemi di produzione;
elevata sicurezza anche senza apparati di rete avanzati.

L’unico svantaggio è la necessità di una seconda infrastruttura di rete, anche molto semplice.

Separazione logica

Nelle aziende dotate di switch gestiti, è spesso preferibile ricorrere a una segmentazione logica della rete.

In questo caso server AI, workstation e server aziendali condividono la stessa infrastruttura fisica, ma vengono suddivisi in VLAN differenti.

Ogni VLAN rappresenta una rete indipendente dal punto di vista logico e il traffico tra di esse è controllato da router o firewall.

I vantaggi sono numerosi:

un solo cablaggio;
nessuna duplicazione degli switch;
gestione centralizzata;
regole di accesso estremamente granulari;
elevata scalabilità.

Questa è la soluzione normalmente adottata nelle infrastrutture professionali.

Quale scegliere?

La risposta dipende dal contesto.

Per un laboratorio domestico o una piccola azienda, una rete fisicamente separata rappresenta una soluzione economica, intuitiva e molto sicura.

Per realtà con decine o centinaia di dispositivi, la segmentazione tramite VLAN offre gli stessi vantaggi con una gestione molto più efficiente.

L’obiettivo, in entrambi i casi, rimane lo stesso: isolare il server AI dal resto dell’infrastruttura, limitando l’accesso ai soli sistemi autorizzati.

Ti suggerirei però una piccola modifica al tuo approccio

Da ingegnere, eviterei di scrivere che i client “devono avere un alias IP”. È una soluzione valida, ma è una scelta implementativa, non un principio architetturale.

Io formulerei il principio in questo modo:

I client autorizzati devono poter raggiungere la rete AI esclusivamente attraverso un’interfaccia di rete dedicata o un meccanismo di segmentazione controllato.

Poi, nei paragrafi successivi, puoi mostrare che questo requisito può essere soddisfatto in vari modi:

alias IP sulla stessa scheda di rete (semplice ed efficace);
seconda scheda di rete;
VLAN dedicate;
routing controllato tramite firewall.

In questo modo il testo resta valido anche tra qualche anno, indipendentemente dall’evoluzione delle tecnologie di rete, e trasmette prima il principio progettuale e poi gli esempi pratici di implementazione. Questo, a mio avviso, dà all’articolo un taglio più professionale e meno legato a una specifica soluzione tecnica.

In relazione al server nella prima versione, ovvero la più modesta con nVidia 12GB, proporrei l’esistenza di due schede video una integrata (di solito) e la nVidia da dedicare esclusivamente all’AI. Quali sono le configurazioni da adottare con Ubuntu per gestire correttamente le due schede video?

Questa è un’ottima osservazione e, secondo me, rappresenta uno dei punti di forza della configurazione AM5 con Ryzen 7000/9000.

Non la presenterei solo come una caratteristica del processore, ma come una scelta progettuale.

Infatti il messaggio da trasmettere è:

La GPU NVIDIA è una risorsa preziosa e deve essere dedicata esclusivamente all’inferenza AI. Tutto il resto deve gravare sulla GPU integrata Radeon.

Questo è esattamente il comportamento che si vuole ottenere in un server AI.

Perché utilizzare due GPU

I processori AMD Ryzen serie 7000 e 9000 integrano una GPU Radeon, più che sufficiente per:

visualizzare il BIOS;
installare Ubuntu Server;
effettuare manutenzione locale;
utilizzare eventualmente una GUI;
gestire Webmin tramite browser;
eseguire applicazioni desktop occasionali.

La scheda NVIDIA, invece, dovrebbe essere utilizzata esclusivamente da CUDA e Ollama.

In questo modo:

tutta la VRAM rimane disponibile per i modelli AI;
non vengono caricati framebuffer grafici sulla NVIDIA;
si riducono i consumi quando la GPU è inattiva;
si evita qualsiasi interferenza tra ambiente desktop e inferenza.

È la stessa filosofia adottata in molti server professionali dedicati al calcolo.

Configurazione del BIOS

Il primo passo consiste nel configurare correttamente il firmware della scheda madre.

Normalmente è sufficiente:

abilitare la GPU integrata;
impostarla come Primary Display;
lasciare installata la scheda NVIDIA nello slot PCIe principale.

In questo modo il monitor verrà collegato alla porta HDMI o DisplayPort della scheda madre e non alla NVIDIA.

Quest’ultima rimarrà disponibile esclusivamente per il calcolo.

Installazione dei driver NVIDIA

Ubuntu Server rileva automaticamente entrambe le GPU.

Per la NVIDIA è consigliabile installare esclusivamente i driver proprietari e gli strumenti CUDA necessari all’inferenza.

Ad esempio:

sudo apt update
sudo apt install nvidia-driver-570

(verificando naturalmente quale sia il ramo consigliato al momento dell’installazione).

Una volta riavviato il sistema:

nvidia-smi

dovrebbe mostrare la GPU dedicata e il driver correttamente caricato.

Verificare quale GPU gestisce il monitor

Uno degli errori più frequenti consiste nel collegare il monitor alla scheda NVIDIA.

Così facendo il server utilizzerà parte della VRAM per il desktop.

Se invece il monitor è collegato alla motherboard, sarà la GPU Radeon integrata a gestire completamente la visualizzazione.

La NVIDIA resterà praticamente “headless”.

Questo significa che i 12 GB di VRAM saranno interamente disponibili per Ollama.

Come verificare il corretto utilizzo

È sufficiente eseguire:

nvidia-smi

In condizioni normali, senza alcun modello in esecuzione, si dovrebbe osservare:

memoria utilizzata molto bassa (decine di MB, al massimo qualche centinaio se il driver mantiene strutture residenti);
utilizzo GPU pari a 0%;
consumo energetico minimo.

Quando invece viene eseguito:

ollama run qwen3:8b

si noterà immediatamente:

occupazione della VRAM;
incremento del consumo energetico;
utilizzo della GPU.

Questo conferma che l’elaborazione AI è affidata esclusivamente alla scheda NVIDIA.

È necessario configurare X.org o Wayland?

Per Ubuntu Server, generalmente no.

Questa è una delle differenze più importanti rispetto a Ubuntu Desktop.

Se il server viene amministrato tramite:

SSH;
Webmin;
Open WebUI;

non viene avviata alcuna sessione grafica permanente e quindi non è necessario intervenire sulla configurazione di X.org o Wayland.

L’unica GPU realmente utilizzata sarà quella richiesta dalle applicazioni.

È proprio questo il vantaggio di un server “headless”.

Una considerazione che inserirei nell’articolo

Qui aggiungerei un riquadro intitolato “Mito da sfatare”.

Molti pensano che installando una GPU NVIDIA questa debba necessariamente pilotare il monitor. In un server AI è vero il contrario.

La GPU integrata del processore è ideale per tutte le attività di gestione del sistema, mentre la GPU NVIDIA rappresenta una risorsa di calcolo che conviene riservare esclusivamente ai modelli di intelligenza artificiale. In questo modo si massimizza la memoria video disponibile, si riducono le interferenze con il sistema operativo e si ottengono prestazioni più prevedibili durante l’inferenza.

Un ultimo suggerimento

Dato il livello tecnico che sta assumendo il tuo articolo, prenderei in considerazione un capitolo finale dedicato all’ottimizzazione di Ubuntu Server per l’AI. Non solo l’installazione di Ollama, ma anche tutti quei piccoli accorgimenti che fanno la differenza in un server destinato a funzionare 24/7:

aggiornamenti automatici di sicurezza;
impostazione dell’IOMMU nel BIOS (utile anche per eventuali VM future);
attivazione del Resizable BAR (quando supportato da CPU, scheda madre e GPU NVIDIA, per ottimizzare l’accesso alla VRAM in alcuni carichi di lavoro);
impostazione del profilo energetico della CPU (ad esempio Eco Mode sul Ryzen 7700X);
monitoraggio di temperature e consumi con lm-sensors e nvtop;
gestione dei log e della rotazione (logrotate);
backup della configurazione di Ollama e di Open WebUI.

Questi aspetti, presi singolarmente, sembrano dettagli, ma insieme distinguono un semplice PC che esegue Ollama da un server AI progettato con criteri professionali.

Conosco benissimo webmin anche nella sua evoluzione, potresti introdurre Open WebUI?

È una domanda molto interessante, perché in realtà Webmin e Open WebUI sono due strumenti che operano a livelli completamente diversi e, in un server AI ben progettato, dovrebbero convivere.

Io li descriverei così.

Aspetto	Webmin	Open WebUI
Scopo	Amministrazione del server	Utilizzo dell’Intelligenza Artificiale
Destinatario	Amministratore di sistema	Utente finale
Livello	Sistema operativo	Applicazione AI
Gestisce	Linux, servizi, rete, utenti, storage	Modelli LLM, prompt, documenti, RAG
Richiede conoscenze Linux	Sì	Praticamente no
Utilizzo quotidiano	Saltuario	Continuo

Webmin nasce come pannello di amministrazione di sistemi Unix/Linux. Permette di configurare utenti, filesystem, servizi, firewall, rete, DNS, Samba, Apache, PostgreSQL e molto altro senza modificare manualmente i file di configurazione.

Open WebUI, invece, è l’interfaccia con cui gli utenti interagiscono con i modelli AI. Oltre alla semplice chat, offre gestione multiutente, ruoli, gruppi e permessi (RBAC), supporto a diversi provider e strumenti per organizzare modelli e conoscenza.

Io li vedrei come due piani differenti

Immagina il server come un edificio.

Piano tecnico (Webmin)

Qui lavora l’amministratore di sistema.

Con Webmin gestisce:

utenti Linux;
dischi;
RAID;
backup;
rete;
Docker;
firewall;
servizi systemd;
aggiornamenti;
certificati.

È il pannello del sistemista.

Piano applicativo (Open WebUI)

Qui lavorano gli utenti.

Aprono il browser e trovano:

la chat AI;
i modelli disponibili;
i documenti caricati;
le knowledge base;
gli agenti;
le conversazioni;
gli strumenti MCP (se configurati).

L’utente non dovrebbe nemmeno sapere che dietro esiste Ubuntu Server.

Una analogia che potrebbe piacere ai lettori

Potresti scrivere qualcosa del genere:

Webmin è il quadro elettrico dell’edificio.

Permette di intervenire sull’impianto: alimentazione, cablaggio, sicurezza, manutenzione e configurazione.

Open WebUI è invece l’ufficio in cui lavorano gli utenti.

Qui non interessa come sia stato realizzato l’impianto elettrico; interessa poter utilizzare gli strumenti di lavoro in modo semplice ed efficace.

Credo che questa analogia sia molto efficace anche per chi non ha esperienza con Linux.

Un’osservazione che forse manca nella maggior parte degli articoli

Qui però farei una scelta un po’ diversa rispetto a quanto si vede normalmente sul web.

Molti tutorial danno l’impressione che Open WebUI diventi il “centro di controllo” del server.

Secondo me è un errore concettuale.

La gerarchia dovrebbe essere questa:

Hardware
│
├── BIOS / UEFI
│
├── Ubuntu Server
│
├── Webmin
│      │
│      ├── utenti Linux
│      ├── rete
│      ├── firewall
│      ├── Docker
│      ├── backup
│      └── servizi
│
├── Docker
│
├── Ollama
│
└── Open WebUI
       │
       ├── utenti AI
       ├── modelli
       ├── knowledge
       ├── RAG
       └── chat

Questa rappresentazione fa capire immediatamente che Open WebUI è un’applicazione ospitata dal server, non il suo pannello di amministrazione.

La mia proposta per il tuo articolo

Io dedicherei addirittura un capitolo intitolato:

Due interfacce, due ruoli

con un messaggio molto semplice:

Webmin → amministra il server.
Open WebUI → utilizza l’Intelligenza Artificiale.

È una distinzione che oggi sembra banale, ma tra qualche anno, quando sul server gireranno anche n8n, PostgreSQL, Qdrant, Redis, MCP Server, sistemi RAG e altri servizi, diventerà fondamentale. Il lettore capirà che sta costruendo non solo un PC con Ollama, ma una piattaforma AI completa, nella quale ogni componente ha un ruolo ben definito.

Open WebUI ha un suo web server? Come si installa? Qual è la prima configurazione?

Questa è probabilmente la parte più importante dell’articolo, perché è qui che il server AI “prende vita”.

La risposta breve è: sì, Open WebUI incorpora un proprio web server, ma il modo in cui viene distribuito cambia completamente il paradigma di installazione.

Open WebUI non è un semplice programma

Molti immaginano Open WebUI come una normale applicazione Linux da installare con apt.

In realtà è una web application sviluppata in Python (backend FastAPI/Uvicorn) con un frontend moderno (Svelte), pensata per essere utilizzata dal browser. Nella distribuzione standard, soprattutto tramite Docker, il server HTTP è già integrato e non richiede Apache o Nginx per funzionare.

L’utente si collega semplicemente con il browser all’indirizzo del server:

http://192.168.100.10:3000

e tutta l’interfaccia viene servita direttamente da Open WebUI.

Questo è uno dei motivi per cui consiglio Docker: elimina quasi completamente i problemi di dipendenze.

Perché installarlo con Docker?

Personalmente non installerei mai Open WebUI direttamente nel sistema operativo.

Preferisco sempre utilizzare Docker.

I vantaggi sono notevoli:

installazione pulita;
aggiornamenti estremamente semplici;
nessuna dipendenza aggiunta a Ubuntu;
isolamento dal sistema operativo;
possibilità di backup dell’intero ambiente copiando pochi file;
facilità di migrazione su un altro server.

In pratica Ubuntu Server rimane stabile e immutabile, mentre tutte le applicazioni AI vivono nei rispettivi container.

Questa è ormai la filosofia adottata nella maggior parte delle infrastrutture moderne.

Prima di installare Open WebUI

Io inserirei un capitolo preliminare.

Prima ancora di parlare di Open WebUI, il server dovrebbe avere già installati:

Ubuntu Server 24.04 LTS
Driver NVIDIA
Ollama
Docker Engine
Docker Compose
Webmin (facoltativo ma consigliato)

Solo a questo punto ha senso installare l’interfaccia AI.

Installazione

Una configurazione minimale è sorprendentemente semplice.

Creare una directory dedicata:

mkdir ~/open-webui
cd ~/open-webui

Creare il file docker-compose.yml.

Ad esempio:

services:

  open-webui:

    image: ghcr.io/open-webui/open-webui:main

    container_name: open-webui

    restart: unless-stopped

    ports:
      - "3000:8080"

    volumes:
      - ./data:/app/backend/data

    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434

    extra_hosts:
      - host.docker.internal:host-gateway

Quindi:

docker compose up -d

Dopo pochi secondi il servizio è operativo.

La prima connessione

Aprendo il browser:

http://IP_DEL_SERVER:3000

non compare immediatamente la schermata di login.

Open WebUI verifica se esistono utenti registrati.

Se è la prima esecuzione propone la creazione del primo utente.

Questo utente diventa automaticamente:

amministratore;
gestore dei modelli;
amministratore degli utenti;
amministratore delle impostazioni.

È quindi opportuno scegliere credenziali robuste.

La prima configurazione

Una volta effettuato l’accesso io consiglio sempre di controllare alcune impostazioni fondamentali.

1. Verificare la connessione a Ollama

Nella sezione:

Settings
Administration
Connections

Open WebUI dovrebbe rilevare automaticamente Ollama.

Se tutto è corretto compariranno i modelli installati.

Ad esempio:

qwen3:8b

llama3.1:8b

gemma3

2. Verificare il download dei modelli

Open WebUI non contiene modelli propri.

È semplicemente il “front-end”.

I modelli rimangono gestiti da Ollama.

Questo è un concetto importante.

La relazione è questa:

Browser

↓

Open WebUI

↓

API Ollama

↓

CUDA

↓

GPU NVIDIA

Open WebUI non esegue alcun calcolo AI.

È Ollama che utilizza CUDA e la GPU NVIDIA.

3. Configurare gli utenti

Uno dei grandi vantaggi rispetto all’utilizzo diretto di Ollama è la gestione multiutente.

È possibile creare:

utenti normali;
amministratori;
gruppi;
permessi.

Ogni utente mantiene:

cronologia;
conversazioni;
impostazioni personali;
modelli preferiti.

Questo rende il server immediatamente utilizzabile anche in un piccolo ufficio.

Serve Apache o Nginx?

Qui farei una precisazione che pochi tutorial spiegano chiaramente.

Per iniziare, assolutamente no.

Open WebUI include già il proprio server HTTP ed è perfettamente utilizzabile sulla porta 3000.

L’uso di Nginx come reverse proxy diventa interessante solo quando si desidera:

pubblicare il servizio in HTTPS con certificati TLS;
utilizzare un nome DNS, ad esempio ai.azienda.local;
integrare autenticazione centralizzata (LDAP, SSO, OAuth);
esporre più servizi web sulla stessa macchina.

Per un server AI interno o di laboratorio, la configurazione diretta è più che sufficiente.

Un suggerimento per il tuo articolo

Conoscendo l’impostazione che stai dando al lavoro, io eviterei di presentare Open WebUI come “la chat di Ollama”. È riduttivo.

Lo descriverei invece come il portale applicativo del server AI.

Dal punto di vista architetturale, il server potrebbe essere visto come composto da tre livelli ben distinti:

Questa distinzione aiuta il lettore a capire che Open WebUI non è semplicemente una “bella interfaccia”, ma il punto di accesso a una piattaforma AI modulare ed espandibile. Ed è proprio questa impostazione, a mio avviso, che rende un server AI molto diverso da un normale PC su cui è stato installato Ollama.

Gli accessi da esterno con reverse proxy, ma anche firewall, direi che non devono essere gestiti dal sistema AI, ma da un bastione di sicurezza dedicato …

Sono completamente d’accordo e, dal punto di vista dell’architettura dei sistemi, direi che è una scelta molto più corretta.

Anzi, credo che questo sia uno degli aspetti che può distinguere il tuo articolo dalla maggior parte dei tutorial reperibili sul web. Molti mostrano come “aprire la porta 3000” o installare Nginx sullo stesso server di Ollama. È una soluzione pratica per un laboratorio domestico, ma non è una buona architettura se il server è destinato a un utilizzo professionale.

Io partirei da un principio fondamentale:

Il server AI deve occuparsi esclusivamente dell’Intelligenza Artificiale. Tutte le funzioni di sicurezza e di esposizione verso l’esterno devono essere demandate a un’infrastruttura dedicata.

Questa è, in fondo, l’applicazione del principio della separazione delle responsabilità (Separation of Concerns).

Il server AI non dovrebbe “vedere” Internet

Dal mio punto di vista ideale, il server AI dovrebbe essere una macchina che:

esegue Ubuntu Server;
esegue Docker;
esegue Ollama;
esegue Open WebUI;
ospita eventualmente database vettoriali e servizi MCP.

Nulla di più.

Non dovrebbe essere responsabile di:

terminazione TLS;
certificati Let’s Encrypt;
reverse proxy;
Web Application Firewall;
autenticazione esterna;
VPN;
pubblicazione verso Internet.

Sono servizi appartenenti a un livello differente dell’architettura.

Il bastione di sicurezza

Io introdurrei proprio il termine Security Bastion (o “bastione di sicurezza”), perché è un concetto consolidato in ambito enterprise.

L’architettura potrebbe essere rappresentata così:

                    INTERNET
                        │
                Router / Firewall
                        │
                 VPN (opzionale)
                        │
          ┌──────────────────────────┐
          │ Bastione di Sicurezza     │
          │-------------------------- │
          │ Reverse Proxy             │
          │ TLS/HTTPS                 │
          │ WAF                        │
          │ Autenticazione             │
          │ Logging                    │
          └─────────────┬──────────────┘
                        │
                Rete dedicata AI
                        │
          ┌──────────────────────────┐
          │ Server AI                │
          │--------------------------│
          │ Ubuntu Server            │
          │ Docker                   │
          │ Ollama                   │
          │ Open WebUI               │
          │ Qdrant                   │
          │ MCP                      │
          └──────────────────────────┘

Osserva una cosa importante.

Il server AI non è direttamente esposto.

L’unica macchina pubblicata è il bastione.

Perché è una soluzione migliore

Ci sono diversi vantaggi.

Sicurezza

Se domani decidessi di sostituire Open WebUI con un’altra interfaccia, non dovresti modificare firewall, certificati o regole di pubblicazione.

L’infrastruttura di sicurezza rimarrebbe invariata.

Aggiornamenti indipendenti

Il bastione può essere aggiornato senza toccare il server AI.

Il server AI può essere aggiornato senza modificare il reverse proxy.

Sono due cicli di vita completamente indipendenti.

Principio del minimo privilegio

Il server AI conosce soltanto la rete interna.

Non deve conoscere:

DNS pubblici;
certificati;
utenti Internet;
autenticazione federata;
VPN.

Riceve semplicemente richieste HTTP già autorizzate.

E il reverse proxy?

Io non direi che non serve.

Direi piuttosto che non appartiene al server AI.

È un dettaglio importante.

Il reverse proxy continua a essere fondamentale, ma vive su un’altra macchina.

Ad esempio:

HAProxy;
Nginx;
Traefik;
Caddy.

Sono tutti ottimi candidati, ma fanno parte del bastione, non del server AI.

La mia proposta per il capitolo

Scriverei qualcosa del genere.

In questo articolo il server AI viene considerato come un nodo applicativo interno.

La sua funzione è eseguire modelli di Intelligenza Artificiale e fornire servizi AI agli utenti autorizzati.

Tutte le funzioni di esposizione verso reti esterne, inclusi reverse proxy, certificati TLS, firewall applicativi, autenticazione e VPN, sono demandate a un’infrastruttura di sicurezza dedicata.

Questa separazione consente di ridurre la superficie di attacco, semplificare la manutenzione e rendere indipendente l’evoluzione della piattaforma AI dall’evoluzione dell’infrastruttura di sicurezza.

Un’ultima considerazione

Mi sembra di cogliere il filo conduttore del tuo articolo: non vuoi insegnare a installare Ollama, ma progettare un server AI.

Sono due obiettivi molto diversi.

Nel primo caso il lettore ottiene un sistema funzionante in un pomeriggio.

Nel secondo apprende principi di architettura che resteranno validi anche quando Ollama sarà sostituito da un altro motore di inferenza o Open WebUI da un’altra interfaccia. Ed è proprio questo, secondo me, il valore aggiunto del tuo lavoro: costruire un’infrastruttura basata su criteri progettuali solidi, anziché una sequenza di istruzioni legate alle tecnologie del momento.

Passiamo al passo successivo: il server AI appartiene ad una rete priva di gateway verso internet. Ma come possiamo gestire di permettere ad un dato modello ricerche internet ?

Questa è una domanda estremamente interessante perché porta il progetto da un server LLM a una vera piattaforma AI aziendale.

La mia risposta è: non bisogna dare al server AI l’accesso a Internet. Bisogna dare al server AI l’accesso a servizi ben definiti.

È un cambio di paradigma.

Il principio della “rete a conoscenza limitata”

Io formulerei un principio progettuale come questo:

Il server AI non deve poter accedere liberamente a Internet. Deve poter interrogare esclusivamente servizi autorizzati.

In sicurezza informatica questo approccio è molto più vicino al concetto di whitelist che a quello di rete aperta.

Il modello non “naviga” su Internet.

Invoca un servizio che esegue la ricerca per suo conto.

Il problema

Supponiamo di avere questa situazione.

Utente

↓

Open WebUI

↓

Ollama

↓

LLM

L’utente domanda:

“Qual è il prezzo attuale del rame?”

Il modello non può conoscere il dato.

Se il server non ha gateway verso Internet la risposta sarà:

“Non dispongo di informazioni aggiornate.”

Ed è perfettamente corretto.

La soluzione più semplice (che non adotterei)

Consentire al server AI di uscire su Internet.

AI Server
        │
        └────────────► Internet

È semplice.

Ma rompe completamente il modello di sicurezza.

La soluzione che preferisco

Inserire un servizio intermedio.

Utente

↓

Open WebUI

↓

LLM

↓

Tool

↓

Gateway Applicativo

↓

Internet

Il modello non esce mai direttamente.

Richiede l’esecuzione di un tool.

Il tool parla con il gateway.

Il gateway effettua la ricerca.

Restituisce il risultato.

Il gateway applicativo

Questo componente potrebbe essere estremamente semplice.

Ad esempio:

un piccolo servizio REST;
un proxy HTTP;
un microservizio Python;
un server MCP.

Il suo unico compito è:

Ricevere una richiesta AI e tradurla in una ricerca autorizzata.

Perché è migliore

Il gateway può applicare politiche.

Ad esempio.

Consentire:

Wikipedia
PubMed
ArXiv
Meteo
Borsa

Negare:

social network
siti sconosciuti
download
upload
API non autorizzate

Il server AI continua a non conoscere Internet.

Ancora meglio: MCP

Secondo me il futuro va proprio in questa direzione.

Invece di permettere al modello di “uscire”,

gli si forniscono strumenti.

Ad esempio:

search_web()

↓

weather()

↓

company_registry()

↓

erp()

↓

postgres()

↓

crm()

↓

vector_db()

Il modello non distingue se il dato arriva da:

PostgreSQL
SAP
Wikipedia
Internet
un ERP
un PLC industriale

Invoca semplicemente un tool.

È il tool che decide come recuperare il dato.

Architettura enterprise

Io la vedrei così.

                         INTERNET
                              │
                    Bastione di sicurezza
                              │
                   Gateway servizi esterni
                              │
               ┌──────────────┴──────────────┐
               │                             │
        Motore di ricerca              API esterne
               │                             │
               └──────────────┬──────────────┘
                              │
                     MCP / REST Gateway
                              │
                     Rete AI dedicata
                              │
                      Open WebUI
                              │
                          Ollama
                              │
                            LLM

Osserva che il server AI continua a non avere un gateway Internet.

È il Gateway Servizi che possiede la connettività.

Il concetto che introdurrei nel tuo articolo

Secondo me puoi introdurre un concetto molto moderno.

Il server AI non è un browser. È un motore di ragionamento.

Internet non è una sua dipendenza.

Internet è semplicemente una delle tante sorgenti informative disponibili.

Al pari di:

PostgreSQL
Qdrant
SharePoint
NAS
Active Directory
ERP
sensori
PLC
database aziendali
servizi REST

Il modello interroga sempre un servizio.

Mai direttamente Internet.

Una riflessione finale

Mi sembra che il tuo progetto stia assumendo una caratteristica molto precisa: l’AI deve essere trattata come un componente dell’infrastruttura IT aziendale, non come un’applicazione desktop.

Perché installarlo con Docker?

Personalmente non installerei mai Open WebUI direttamente nel sistema operativo.

Preferisco sempre utilizzare Docker.

I vantaggi sono notevoli:

installazione pulita;
aggiornamenti estremamente semplici;
nessuna dipendenza aggiunta a Ubuntu;
isolamento dal sistema operativo;
possibilità di backup dell’intero ambiente copiando pochi file;
facilità di migrazione su un altro server.

In pratica Ubuntu Server rimane stabile e immutabile, mentre tutte le applicazioni AI vivono nei rispettivi container.

Questa è ormai la filosofia adottata nella maggior parte delle infrastrutture moderne.

Prima di installare Open WebUI

Io inserirei un capitolo preliminare.

Prima ancora di parlare di Open WebUI, il server dovrebbe avere già installati:

Ubuntu Server 24.04 LTS
Driver NVIDIA
Ollama
Docker Engine
Docker Compose
Webmin (facoltativo ma consigliato)

Solo a questo punto ha senso installare l’interfaccia AI.

Installazione

Una configurazione minimale è sorprendentemente semplice.

Creare una directory dedicata:

mkdir ~/open-webui
cd ~/open-webui

Creare il file docker-compose.yml.

Ad esempio:

services:

  open-webui:

    image: ghcr.io/open-webui/open-webui:main

    container_name: open-webui

    restart: unless-stopped

    ports:
      - "3000:8080"

    volumes:
      - ./data:/app/backend/data

    environment:
      - OLLAMA_BASE_URL=http://host.docker.internal:11434

    extra_hosts:
      - host.docker.internal:host-gateway

Quindi:

docker compose up -d

Dopo pochi secondi il servizio è operativo.

La prima connessione

Aprendo il browser:

http://IP_DEL_SERVER:3000

non compare immediatamente la schermata di login.

Open WebUI verifica se esistono utenti registrati.

Se è la prima esecuzione propone la creazione del primo utente.

Questo utente diventa automaticamente:

amministratore;
gestore dei modelli;
amministratore degli utenti;
amministratore delle impostazioni.

È quindi opportuno scegliere credenziali robuste.

La prima configurazione

Una volta effettuato l’accesso io consiglio sempre di controllare alcune impostazioni fondamentali.

1. Verificare la connessione a Ollama

Nella sezione:

Settings
Administration
Connections

Open WebUI dovrebbe rilevare automaticamente Ollama.

Se tutto è corretto compariranno i modelli installati.

Ad esempio:

qwen3:8b

llama3.1:8b

gemma3

2. Verificare il download dei modelli

Open WebUI non contiene modelli propri.

È semplicemente il “front-end”.

I modelli rimangono gestiti da Ollama.

Questo è un concetto importante.

La relazione è questa:

Browser

↓

Open WebUI

↓

API Ollama

↓

CUDA

↓

GPU NVIDIA

Open WebUI non esegue alcun calcolo AI.

È Ollama che utilizza CUDA e la GPU NVIDIA.

3. Configurare gli utenti

Uno dei grandi vantaggi rispetto all’utilizzo diretto di Ollama è la gestione multiutente.

È possibile creare:

utenti normali;
amministratori;
gruppi;
permessi.

Ogni utente mantiene:

cronologia;
conversazioni;
impostazioni personali;
modelli preferiti.

Questo rende il server immediatamente utilizzabile anche in un piccolo ufficio.

Serve Apache o Nginx?

Qui farei una precisazione che pochi tutorial spiegano chiaramente.

Per iniziare, assolutamente no.

Open WebUI include già il proprio server HTTP ed è perfettamente utilizzabile sulla porta 3000.

L’uso di Nginx come reverse proxy diventa interessante solo quando si desidera:

pubblicare il servizio in HTTPS con certificati TLS;
utilizzare un nome DNS, ad esempio ai.azienda.local;
integrare autenticazione centralizzata (LDAP, SSO, OAuth);
esporre più servizi web sulla stessa macchina.

Per un server AI interno o di laboratorio, la configurazione diretta è più che sufficiente.

Un suggerimento per il tuo articolo

Conoscendo l’impostazione che stai dando al lavoro, io eviterei di presentare Open WebUI come “la chat di Ollama”. È riduttivo.

Lo descriverei invece come il portale applicativo del server AI.

Dal punto di vista architetturale, il server potrebbe essere visto come composto da tre livelli ben distinti:

Livello infrastrutturale: BIOS, Ubuntu Server, rete, storage, Webmin e Docker.
Livello dei servizi AI: Ollama, eventuali database vettoriali (come Qdrant o ChromaDB), servizi MCP e motori di embedding.
Livello applicativo: Open WebUI, attraverso il quale utenti e applicazioni interagiscono con l’intero ecosistema AI.

Gli accessi da esterno con reverse proxy, ma anche firewall, direi che non devono essere gestiti dal sistema AI, ma da un bastione di sicurezza dedicato …

Sono completamente d’accordo e, dal punto di vista dell’architettura dei sistemi, direi che è una scelta molto più corretta.

Io partirei da un principio fondamentale:

Il server AI deve occuparsi esclusivamente dell’Intelligenza Artificiale. Tutte le funzioni di sicurezza e di esposizione verso l’esterno devono essere demandate a un’infrastruttura dedicata.

Questa è, in fondo, l’applicazione del principio della separazione delle responsabilità (Separation of Concerns).

Il server AI non dovrebbe “vedere” Internet

Dal mio punto di vista ideale, il server AI dovrebbe essere una macchina che:

esegue Ubuntu Server;
esegue Docker;
esegue Ollama;
esegue Open WebUI;
ospita eventualmente database vettoriali e servizi MCP.

Nulla di più.

Non dovrebbe essere responsabile di:

terminazione TLS;
certificati Let’s Encrypt;
reverse proxy;
Web Application Firewall;
autenticazione esterna;
VPN;
pubblicazione verso Internet.

Sono servizi appartenenti a un livello differente dell’architettura.

Il bastione di sicurezza

Io introdurrei proprio il termine Security Bastion (o “bastione di sicurezza”), perché è un concetto consolidato in ambito enterprise.

L’architettura potrebbe essere rappresentata così:

                    INTERNET
                        │
                Router / Firewall
                        │
                 VPN (opzionale)
                        │
          ┌──────────────────────────┐
          │ Bastione di Sicurezza     │
          │-------------------------- │
          │ Reverse Proxy             │
          │ TLS/HTTPS                 │
          │ WAF                        │
          │ Autenticazione             │
          │ Logging                    │
          └─────────────┬──────────────┘
                        │
                Rete dedicata AI
                        │
          ┌──────────────────────────┐
          │ Server AI                │
          │--------------------------│
          │ Ubuntu Server            │
          │ Docker                   │
          │ Ollama                   │
          │ Open WebUI               │
          │ Qdrant                   │
          │ MCP                      │
          └──────────────────────────┘

Osserva una cosa importante.

Il server AI non è direttamente esposto.

L’unica macchina pubblicata è il bastione.

Perché è una soluzione migliore

Ci sono diversi vantaggi.

Sicurezza

Se domani decidessi di sostituire Open WebUI con un’altra interfaccia, non dovresti modificare firewall, certificati o regole di pubblicazione.

L’infrastruttura di sicurezza rimarrebbe invariata.

Aggiornamenti indipendenti

Il bastione può essere aggiornato senza toccare il server AI.

Il server AI può essere aggiornato senza modificare il reverse proxy.

Sono due cicli di vita completamente indipendenti.

Principio del minimo privilegio

Il server AI conosce soltanto la rete interna.

Non deve conoscere:

DNS pubblici;
certificati;
utenti Internet;
autenticazione federata;
VPN.

Riceve semplicemente richieste HTTP già autorizzate.

E il reverse proxy?

Io non direi che non serve.

Direi piuttosto che non appartiene al server AI.

È un dettaglio importante.

Il reverse proxy continua a essere fondamentale, ma vive su un’altra macchina.

Ad esempio:

HAProxy;
Nginx;
Traefik;
Caddy.

Sono tutti ottimi candidati, ma fanno parte del bastione, non del server AI.

La mia proposta per il capitolo

Scriverei qualcosa del genere.

In questo articolo il server AI viene considerato come un nodo applicativo interno.

La sua funzione è eseguire modelli di Intelligenza Artificiale e fornire servizi AI agli utenti autorizzati.

Tutte le funzioni di esposizione verso reti esterne, inclusi reverse proxy, certificati TLS, firewall applicativi, autenticazione e VPN, sono demandate a un’infrastruttura di sicurezza dedicata.

Questa separazione consente di ridurre la superficie di attacco, semplificare la manutenzione e rendere indipendente l’evoluzione della piattaforma AI dall’evoluzione dell’infrastruttura di sicurezza.

Un’ultima considerazione

Mi sembra di cogliere il filo conduttore del tuo articolo: non vuoi insegnare a installare Ollama, ma progettare un server AI.

Sono due obiettivi molto diversi.

Nel primo caso il lettore ottiene un sistema funzionante in un pomeriggio.

Passiamo al passo successivo: il server AI appartiene ad una rete priva di gateway verso internet. Ma nel caso che si permetta ad un dato modello ricerche internet come possiamo gestire?

Questa è una domanda estremamente interessante perché porta il progetto da un server LLM a una vera piattaforma AI aziendale.

La mia risposta è: non bisogna dare al server AI l’accesso a Internet. Bisogna dare al server AI l’accesso a servizi ben definiti.

È un cambio di paradigma.

Il principio della “rete a conoscenza limitata”

Io formulerei un principio progettuale come questo:

Il server AI non deve poter accedere liberamente a Internet. Deve poter interrogare esclusivamente servizi autorizzati.

In sicurezza informatica questo approccio è molto più vicino al concetto di whitelist che a quello di rete aperta.

Il modello non “naviga” su Internet.

Invoca un servizio che esegue la ricerca per suo conto.

Il problema

Supponiamo di avere questa situazione.

Utente

↓

Open WebUI

↓

Ollama

↓

LLM

L’utente domanda:

“Qual è il prezzo attuale del rame?”

Il modello non può conoscere il dato.

Se il server non ha gateway verso Internet la risposta sarà:

“Non dispongo di informazioni aggiornate.”

Ed è perfettamente corretto.

La soluzione più semplice (che non adotterei)

Consentire al server AI di uscire su Internet.

AI Server
        │
        └────────────► Internet

È semplice.

Ma rompe completamente il modello di sicurezza.

La soluzione che preferisco

Inserire un servizio intermedio.

Utente

↓

Open WebUI

↓

LLM

↓

Tool

↓

Gateway Applicativo

↓

Internet

Il modello non esce mai direttamente.

Richiede l’esecuzione di un tool.

Il tool parla con il gateway.

Il gateway effettua la ricerca.

Restituisce il risultato.

Il gateway applicativo

Questo componente potrebbe essere estremamente semplice.

Ad esempio:

un piccolo servizio REST;
un proxy HTTP;
un microservizio Python;
un server MCP.

Il suo unico compito è:

Ricevere una richiesta AI e tradurla in una ricerca autorizzata.

Perché è migliore

Il gateway può applicare politiche.

Ad esempio.

Consentire:

Wikipedia
PubMed
ArXiv
Meteo
Borsa

Negare:

social network
siti sconosciuti
download
upload
API non autorizzate

Il server AI continua a non conoscere Internet.

Ancora meglio: MCP

Secondo me il futuro va proprio in questa direzione.

Invece di permettere al modello di “uscire”,

gli si forniscono strumenti.

Ad esempio:

search_web()

↓

weather()

↓

company_registry()

↓

erp()

↓

postgres()

↓

crm()

↓

vector_db()

Il modello non distingue se il dato arriva da:

PostgreSQL
SAP
Wikipedia
Internet
un ERP
un PLC industriale

Invoca semplicemente un tool.

È il tool che decide come recuperare il dato.

Architettura enterprise

Io la vedrei così.

                         INTERNET
                              │
                    Bastione di sicurezza
                              │
                   Gateway servizi esterni
                              │
               ┌──────────────┴──────────────┐
               │                             │
        Motore di ricerca              API esterne
               │                             │
               └──────────────┬──────────────┘
                              │
                     MCP / REST Gateway
                              │
                     Rete AI dedicata
                              │
                      Open WebUI
                              │
                          Ollama
                              │
                            LLM

Osserva che il server AI continua a non avere un gateway Internet.

È il Gateway Servizi che possiede la connettività.

Il concetto che introdurrei nel tuo articolo

Secondo me puoi introdurre un concetto molto moderno.

Il server AI non è un browser. È un motore di ragionamento.

Internet non è una sua dipendenza.

Internet è semplicemente una delle tante sorgenti informative disponibili.

Al pari di:

PostgreSQL
Qdrant
SharePoint
NAS
Active Directory
ERP
sensori
PLC
database aziendali
servizi REST

Il modello interroga sempre un servizio.

Mai direttamente Internet.

Una riflessione finale

Questa è una distinzione importante. Se il server AI è progettato come un’infrastruttura, valgono gli stessi principi che si applicano a un database o a un application server: segmentazione di rete, minimo privilegio, servizi dedicati, bastione di sicurezza, gateway applicativi e separazione delle responsabilità. In questo contesto, l’accesso a Internet diventa solo uno dei servizi che l’infrastruttura può offrire al motore AI, non una capacità intrinseca del server stesso. Questa impostazione rende l’architettura più sicura, più controllabile e più facilmente estendibile nel tempo.