13 min di lettura 22 agosto 2026

Installare Ollama con Docker: CPU, GPU, volumi e controlli API

Un percorso pratico per eseguire Ollama in Docker senza perdere i modelli o confondere la rete dell'host con quella del container.

Team editoriale di Odysseus AI Wiki
Team editoriale di Odysseus AI Wiki
Documentazione tecnica e verifica indipendente
Illustrazione concettuale di un modello Ollama dentro un container Docker con CPU, GPU, storage e host locale
Docker aggiunge un confine al runtime Ollama; storage, calcolo e rete devono restare decisioni esplicite.

Risposta breve: Sì, Ollama può funzionare in Docker. La configurazione più affidabile usa un volume nominato per /root/.ollama, pubblica la porta solo quando serve e sceglie un percorso CPU o GPU compatibile con l'host. Controlla container, /api/tags e una piccola richiesta al modello prima di collegare un'altra applicazione.

In questa guida

La ricerca installare Ollama con Docker comprende in genere tre decisioni: dove salvare i modelli, come il container raggiunge l'host o un altro servizio e se usare la CPU o una GPU disponibile. Parti dal percorso minimo. Avvia l'immagine ufficiale con un volume nominato, verifica l'API locale e aggiungi opzioni GPU o una seconda applicazione solo quando il container di base è stabile.

Cosa cambia eseguendo Ollama in Docker

Ollama normalmente sembra un servizio locale: un comando avvia il runtime, i modelli sono sul computer e i client usano la porta 11434. Docker racchiude il servizio in un container con filesystem, processi, rete e ciclo di vita propri. Il deployment diventa ripetibile, ma un modello conservato solo nel layer scrivibile del container può sparire quando il container viene eliminato.

Per questo un comando docker run funzionante non è tutta la configurazione. Decidi se Docker sarà l'unico runtime Ollama, se accederà un'applicazione dell'host o un altro container e se i modelli scaricati dovranno sopravvivere agli aggiornamenti. Mantieni visibili questi confini prima di aggiungere OpenCode, un host MCP, una UI web o un client remoto.

Il ciclo di vita del container non è lo storage dei modelli

Puoi sostituire il container senza perdere i modelli quando /root/.ollama è fuori dal layer scrivibile. Usa un volume nominato o un bind mount scelto consapevolmente.

Scegliere il percorso CPU, NVIDIA GPU o AMD GPU

Usa prima la CPU quando controlli rete, volumi o un nuovo host. È il percorso con meno dipendenze e crea una base pulita per confrontare tempi di caricamento e velocità delle risposte. Quando l'API funziona, passa al comando dell'acceleratore documentato per il tuo host invece di copiare flag Docker da un'altra configurazione.

I container NVIDIA richiedono normalmente un driver host funzionante e NVIDIA Container Toolkit. Le configurazioni AMD possono usare un tag dell'immagine e un mapping dei dispositivi diversi; la compatibilità dipende da sistema operativo, runtime e documentazione Ollama corrente. Considera la GPU un livello di ottimizzazione: endpoint, volume e controlli di base devono restare uguali.

Verificare Docker
docker version
Verificare una GPU NVIDIA dell'host
docker run --rm --gpus=all nvidia/cuda:12.0.0-base-ubuntu22.04 nvidia-smi
Percorso Quando usarlo Controllo importante
CPU Vuoi la base più semplice o non hai un acceleratore supportato Verificare API e piccola risposta prima del tuning
NVIDIA GPU Driver host e NVIDIA Container Toolkit sono già funzionanti Controllare che Docker veda la GPU prima di scaricare un modello grande
AMD GPU Host e immagine Ollama supportano il percorso ROCm richiesto Seguire i requisiti correnti di immagine e dispositivi
Host e container Un altro servizio chiama Ollama su una rete Docker Usare il nome del servizio nella rete, non il loopback dell'host

Creare storage persistente per i modelli

Un volume nominato è il valore predefinito più semplice per Ollama in Docker: Docker gestisce il percorso e il container può essere sostituito senza copiare i modelli a mano. L'immagine ufficiale conserva i dati Ollama in /root/.ollama, quindi monta sempre il volume in quel punto. Non creare un secondo volume durante un aggiornamento se vuoi mantenere la stessa libreria.

Un bind mount è utile per controllare lo spazio su un disco preciso o per eseguire backup di una cartella nota dell'host. Aggiunge però decisioni su percorsi e permessi. Per il primo deployment, un volume nominato è di solito più semplice da spiegare e più difficile da danneggiare.

Un volume non è un backup

Un volume protegge i modelli dalla sostituzione del container, ma non crea automaticamente una seconda copia. Esegui backup o ricostruzione in modo deliberato se la libreria è importante.

Diagramma concettuale con client dell'host collegati a un container Ollama Docker, un volume persistente e una rete esterna separata
Percorso dell'applicazione, confine del container, volume persistente e rete in uscita sono decisioni separate.
Creare un volume nominato
docker volume create ollama-data
Avviare il container CPU con storage persistente
docker run -d --name ollama -p 11434:11434 -v ollama-data:/root/.ollama ollama/ollama
Scaricare un modello nel container
docker exec -it ollama ollama pull <model-name>

Avviare il container e verificare l'API

Dopo che docker run restituisce l'ID del container, controlla lo stato prima di scaricare un modello grande. docker ps mostra se il processo è ancora attivo e docker logs può indicare problemi di porta, permessi o runtime. Poi interroga /api/tags dall'host. Una risposta corretta dimostra che l'endpoint HTTP è raggiungibile, non che tutti i modelli siano caricati o che ogni client sia autorizzato.

Usa una piccola richiesta a un modello come seconda prova. In questo modo separi un listener HTTP sano da un percorso del modello funzionante. Se l'API risponde ma la richiesta al modello fallisce, controlla nome del modello, spazio libero, memoria e log prima di modificare la rete.

  1. Controllare il processo

    Conferma che il container sia Up e che la porta pubblicata sia quella prevista.

  2. Controllare l'endpoint

    Richiedi /api/tags dalla macchina che pubblica la porta 11434 e registra il codice di stato.

  3. Controllare un modello

    Scarica un modello piccolo ed esegui una richiesta innocua prima di collegare editor o agent.

Controllare lo stato del container
docker ps --filter name=ollama
Leggere i log recenti
docker logs ollama --tail 100
Controllare l'API locale
curl http://127.0.0.1:11434/api/tags
Elencare i modelli nel container
docker exec -it ollama ollama list

Collegare le applicazioni senza confondere localhost

L'URL Ollama corretto dipende da dove gira il client. Un'applicazione desktop sullo stesso host può normalmente chiamare http://127.0.0.1:11434 quando Docker pubblica la porta. Un secondo container sulla stessa rete Docker deve chiamare il servizio Ollama con il nome Compose e la porta, per esempio http://ollama:11434. Dentro un container, 127.0.0.1 indica quel container e non automaticamente l'host Windows, macOS o Linux.

Per un client remoto servono un indirizzo protetto e una regola firewall esplicita. Non pubblicare la porta 11434 su Internet solo per far funzionare un'applicazione di prova. Documenta percorso, autenticazione o rete privata e il servizio modello preciso che il client può raggiungere.

Posizione del client Endpoint tipico Problema comune
Desktop sull'host http://127.0.0.1:11434 Usare un nome di servizio Docker da un'app host
Altro servizio Compose http://ollama:11434 Usare localhost, che torna al container chiamante
Altra macchina Indirizzo privato e filtrato dell'host Pubblicare un'API senza autenticazione su un'interfaccia pubblica
Odysseus o editor Endpoint richiesto dalle impostazioni del provider Cambiare endpoint prima del test API di base

Proteggere modelli, contesto ed esposizione

Docker non rende automaticamente privato un servizio Ollama. Una porta pubblicata può essere associata a tutte le interfacce in base al comando e ai valori predefiniti dell'host. Per un test solo host, preferisci un binding loopback come -p 127.0.0.1:11434:11434. Se un servizio Compose deve usare l'API internamente, tienilo su una rete privata e non pubblicare una porta host senza motivo.

Lunghezza del contesto, concorrenza e memoria GPU cambiano l'uso di RAM o VRAM del container. Aumenta una variabile alla volta e osserva docker stats, memoria dell'host e comportamento delle risposte. Tieni i segreti fuori da immagini, cronologia shell, screenshot e file Compose versionati; un endpoint locale e uno strumento di ricerca esterno hanno confini di privacy diversi.

Controllo Perché conta Valore più sicuro
Binding della porta Determina quali interfacce raggiungono l'API Usare loopback per test locali
Percorso del volume Determina se i modelli sopravvivono al cambio container Usare un volume nominato documentato
Contesto e concorrenza Possono moltiplicare la memoria per richiesta Partire basso e misurare prima di aumentare
Strumenti esterni Possono inviare prompt o contenuti fuori dall'host Controllare il provider e limitare i permessi

Risolvere problemi di health, GPU, volume e API

Quando un deployment Ollama Docker non funziona, modifica un solo livello alla volta. Controlla prima Docker, poi che il container Ollama resti attivo, quindi volume, API, modello e infine l'applicazione client. Sostituire l'intero comando dopo ogni problema nasconde il confine che ha davvero fallito.

I problemi GPU sono spesso problemi del runtime dell'host e non dell'API Ollama. Un container può rispondere a /api/tags e usare comunque la CPU perché la GPU non è stata passata, il driver non è compatibile o l'immagine non corrisponde all'host. Se un modello scompare dopo la ricreazione, confronta docker inspect e la destinazione /root/.ollama prima di scaricarlo di nuovo.

Rimuovere il container non rimuove il volume

L'ultimo comando elimina solo il container. Non eseguire docker volume rm ollama-data finché non hai confermato che i modelli non servono più o che esiste una copia.

Illustrazione concettuale del troubleshooting Ollama Docker con percorsi CPU e GPU, volume persistente, segnale di salute e protezione di rete
Diagnostica in questo ordine: runtime, calcolo, storage, endpoint ed esposizione.
Ispezionare mount e porte
docker inspect ollama
Osservare le risorse
docker stats ollama
Fermare e rimuovere solo il container
docker stop ollama && docker rm ollama
Sintomo Confine probabile Controllo successivo
Il container termina subito Immagine, comando, permessi o runtime Leggere docker logs ollama e il codice di uscita
Connessione API rifiutata Binding della porta o salute del processo Controllare docker ps, porte pubblicate e /api/tags
Modello scomparso Volume errato o assente Confrontare i mount di docker inspect e /root/.ollama
Il flag GPU fallisce Driver host o runtime container Eseguire il test GPU più piccolo del provider
L'host funziona ma il client nel container no Namespace di rete Sostituire localhost con il nome del servizio Compose
Le richieste usano troppa memoria Contesto, concorrenza o dimensione del modello Ridurre un'opzione e osservare le metriche

Domande frequenti su Ollama in Docker

Sì. Il percorso ufficiale avvia il servizio in un container. Gli elementi pratici sono immagine, volume /root/.ollama, runtime CPU o accelerato ed endpoint usato dal client.

Crea un volume nominato, avvia l'immagine ufficiale con la porta 11434 e monta il volume in /root/.ollama. Verifica docker ps e /api/tags prima di scaricare un modello. Per la GPU usa la documentazione ufficiale corrente.

Puoi progettare uno storage condiviso, ma non è consigliabile far scrivere senza coordinamento due runtime nella stessa cartella. Un proprietario chiaro, un backup e una migrazione documentata riducono problemi di lock e permessi.

Usa la CPU come base per verificare l'installazione. NVIDIA o AMD sono adatte quando driver, runtime, immagine e dispositivi sono compatibili insieme. Il percorso GPU dovrebbe mantenere lo stesso volume e gli stessi controlli API.

I client usano namespace di rete diversi. L'host può usare 127.0.0.1:11434 se la porta è pubblicata; un servizio Compose dovrebbe normalmente usare http://ollama:11434.

Usa la variabile d'ambiente e la configurazione documentate per la versione di Ollama in uso, poi ricrea il container con lo stesso volume. Aumenta gradualmente e controlla la memoria.

Non darlo per scontato. Controlla indirizzo di binding e firewall. Per uso solo host lega la porta al loopback; per servizi interni usa una rete Docker privata ed evita una porta pubblica non necessaria.

Riferimenti ufficiali

  1. Documentazione Docker di Ollama - Immagini container e indicazioni Docker ufficiali
  2. Documentazione API di Ollama - Riferimento ufficiale per endpoint e richieste
  3. Supporto GPU in Docker Compose - Prenotazione GPU e configurazione Compose ufficiali

Risorse correlate sull'IA locale

Ultimo aggiornamento: 22 agosto 2026

Torna alla home