Ollama i Docker: GPU-stöd och beständig modellagring

Ett svart datorchassi med grön kant står öppet med en utdragen metallåda framför en ribbad komponent. En smal lös modul ligger på det grå underlaget framför chassit. — Containern kan ersättas, men modellagringen behöver en egen livscykel. Illustrationen visar separata delar i ett öppet chassi.

Ollama i Docker kräver två separata beslut: vilken hårdvara containern får använda och var modellfilerna ska leva. Ett lyckat containerbyte säger inget om GPU-körningen. En fungerande GPU säger inget om modellerna överlever nästa byte. Planera därför värddator, container och modellvolym var för sig, och kontrollera sedan att de möts i samma körning.

Beslutet före start

Välj en dokumenterad körväg för ditt operativsystem, spara ett bestämt image-id och montera en namngiven volym på Ollamas modellplats. Behåll volymen när du ersätter containern. Kontrollera modellens faktiska läge efter starten.

Tre lager med olika ansvar

På Linux börjar NVIDIA-spåret utanför containern. NVIDIAs installationsanvisning kräver en GPU-drivrutin på värden och beskriver därefter installation av Container Toolkit. Docker konfigureras med sudo nvidia-ctk runtime configure --runtime=docker och dess daemon startas om. Det är en värdändring; den görs inte genom att installera paket inne i Ollama-containern.

Lager	Vad du behöver bestämma	Vad det inte bevisar
Värddator	Operativsystem, drivrutin och dokumenterad GPU-väg.	Att just modellen hamnar i GPU-minnet.
Container	Image, GPU-flaggor och portbindning.	Att modellfilerna finns kvar efter att containern tas bort.
Modellvolym	Namn, monteringspunkt och återställningsplan.	Att en äldre Ollama-version kan läsa data efter en uppgradering.

Tabellen är en felsökningsordning. Om servern svarar men modellen går på CPU ska du undersöka GPU-vägen. Om modellistan blir tom efter ett byte ska du först undersöka monteringen. Ändra inte både drivrutin, image och volymnamn i samma försök: då blir ett förbättrat eller försämrat resultat svårt att förklara.

CPU, NVIDIA och plattformens gränser

Ollamas Docker-dokumentation visar ett CPU-exempel utan GPU-flaggor och ett NVIDIA-exempel med --gpus=all. På Linux hör NVIDIA Container Toolkit till förutsättningarna. CPU är därför ett tydligt första alternativ när du vill kontrollera modelllagringen innan GPU-vägen är färdig. Här anges ingen hastighet eller lämplig modellstorlek.

För Docker Desktop på Windows beskriver Dockers GPU-anvisning NVIDIA-åtkomst till Linux-containrar med WSL2-backend. Kraven omfattar ett NVIDIA-kort, uppdaterat Windows 10 eller 11, en NVIDIA-drivrutin med WSL2 GPU-PV-stöd, uppdaterad WSL2-kärna och aktiverad WSL2-backend. Det är inte ett påstående om valfri Windows-container eller AMD-konfiguration. Följ Desktop-anvisningen för värden i stället för att överföra Linux-värdens installationskommandon ordagrant.

På macOS anger Ollamas FAQ att GPU-acceleration för Ollama i Docker Desktop saknas på grund av begränsad GPU-genomkoppling och emulering. Om GPU är ditt krav behöver du välja en annan dokumenterad körform där. Att själva Macen har en GPU räcker inte för det Docker-upplägg som behandlas här.

AMD avgränsas här till Ollamas dokumenterade ROCm-exempel: imagen med taggen rocm och enhetsåtkomst via /dev/kfd samt /dev/dri. Kontrollera din kombination mot leverantörens stöd innan du väljer den vägen. Denna artikel är inget kompatibilitetsbesked för ett visst Radeon-kort. Docker-sidan beskriver även Vulkan; det spåret analyseras inte här.

Välj image innan du skapar containern

Docker skiljer mellan en tagg och en digest. Enligt referensen för image pull ger hämtning med digest ett bestämt image-innehåll. Taggar kan ändras. Välj först en publicerad version du avser att använda, hämta den och anteckna dess digest. En versionspinning är ett beslut om vilket innehåll du kör, inte ett löfte om framtida modellkompatibilitet.

I exemplen nedan använder du PowerShell. Den första raden frågar efter en faktisk versionsreferens, exempelvis formen ollama/ollama:VERSION; VERSION är en beskrivning här och ska ersättas med en befintlig tagg. Skriv inte in ordet VERSION. Efter hämtningen läser du av imagen och anger den fullständiga referensen på formen ollama/ollama@sha256:... vid den andra frågan. Ingen digest eller rekommenderad utgåva är påhittad i exemplet.

$versionImage = Read-Host 'Ange ollama/ollama med vald publicerad versionstagg'
docker pull $versionImage
docker image inspect $versionImage --format '{{json .RepoDigests}}'
$ollamaImage = Read-Host 'Ange hela ollama/ollama@sha256-referensen från utskriften'

Spara både tagg och digest i ditt driftkort. Notera också att hämtning av en ny image inte byter programmet i en redan skapad container. Bytet nedan skapar en ny container och återanvänder den befintliga volymen.

Två alternativa starter, samma modellvolym

Dessa exempel är bearbetningar av de officiella kommandona. Volymen ollama-modeller monteras på /root/.ollama, samma containerplats som Ollama visar. Namnet ollama-server är containerns namn. Välj en av de två starterna; kör dem inte parallellt. Vid byte från CPU till NVIDIA följer du först stopp och borttagning i nästa avsnitt, eftersom namnet redan används.

# Alternativ A: CPU, med den image du valt ovan
docker run -d --name ollama-server -v ollama-modeller:/root/.ollama -p 127.0.0.1:11434:11434 $ollamaImage

# Alternativ B: NVIDIA, efter att värdens GPU-väg är konfigurerad
docker run -d --name ollama-server --gpus=all -v ollama-modeller:/root/.ollama -p 127.0.0.1:11434:11434 $ollamaImage

Portdelen är en medveten ändring av leverantörens exempel. Dockers dokumentation om portpublicering beskriver hur en angiven loopback-adress begränsar den publicerade portens åtkomst till värden i det vanliga bridge-upplägget. Utan angiven värdadress publiceras porten på värdens adresser. Kontrollera att ingen annan Ollama-process redan använder port 11434.

Docker dokumenterar ett undantag för versioner äldre än 28.0.0: datorer på samma L2-segment kan då nå portar publicerade till localhost. Exemplet är därför inte en fristående säkerhetsgaranti för en äldre Docker-installation eller ett nät med särskild direkt routing. Kontrollera Docker-version och nätkonfiguration innan du behandlar porten som lokal.

Volymens liv är längre än containerns

Enligt Dockers volymdokumentation har volymdata en livscykel utanför containern. Docker skapar en namngiven volym om den saknas när den monteras. Samma namn återanvänder en befintlig volym. Det gör ett stavfel betydelsefullt: ett nytt namn kan ge en ny tom lagringsplats, fast den gamla fortfarande finns kvar.

Åtgärd	Effekt i detta upplägg
`docker stop ollama-server`	Stoppar containern; den namngivna volymen behålls.
`docker rm ollama-server`	Tar bort den stoppade containern; volymen behålls.
`docker volume rm ollama-modeller`	Raderar modellvolymen och dess data när den inte används.

Tabellens kommandon har separata uppgifter enligt referenserna för container stop, container rm och volume rm. Den sista raden är destruktiv och ingår inte i uppdateringsflödet. Behandla också volymrensning som ett separat beslut när gamla containrar städas bort; en volym som tillfälligt inte används kan fortfarande vara ditt modellbibliotek.

En återanvänd volym är inte en säkerhetskopia. Den hjälper vid containerbyte men ersätter inte ett återställningsprov från en separat kopia. För flytt av modeller utanför containerupplägget finns artikeln om modellagring på en annan disk. Blanda inte den installationens värdsökvägar med sökvägen inne i denna container.

Byt container och kontrollera två olika saker

Före ett byte rekommenderar vi att du sparar nuvarande image-referens, modellistan och hur containern skapades. Gör en separat återställningsbar kopia av volymen enligt din backupplan. Välj därefter den nya imagen med samma metod som ovan. Återanvändningen av modellvolymen säger inget om möjligheten att backa efter att en ny version har skrivit i den.

# Inventering före byte
docker exec ollama-server ollama ls
docker inspect ollama-server

# Containerbyte: behåll ollama-modeller
docker stop ollama-server
docker rm ollama-server
docker run -d --name ollama-server -v ollama-modeller:/root/.ollama -p 127.0.0.1:11434:11434 $ollamaImage

# Kontroll efter byte
docker exec ollama-server ollama ls
docker exec -it ollama-server ollama run llama3.2
docker exec ollama-server ollama ps

Bytesexemplet använder CPU-alternativet. Om du har valt NVIDIA ska startraden ha samma --gpus=all som NVIDIA-alternativet ovan. Modellnamnet llama3.2 kommer från Ollamas dokumenterade exempel; för ett lagringsprov väljer du hellre ett exakt namn som redan finns i din sparade lista, så att provet inte behöver hämta en ny modell.

CLI-referensen skiljer mellan ollama ls, som listar modeller, och ollama ps, som listar modeller laddade i minnet. Den första kontrollen prövar därför biblioteket; den andra prövar körläget efter modellstart. Kör ps medan modellen är laddad. En tom utskrift efter att modellen har laddats ur visar inte vilket läge den hade tidigare.

FAQ beskriver kolumnen PROCESSOR: 100% GPU betyder helt laddad på GPU, 100% CPU helt i systemminnet, och en fördelning CPU/GPU betyder att båda används. Flaggan på startraden är alltså inte ditt slutbevis. Anteckna modellnamnet och resultatet från ps tillsammans med imagen. Kontrollera därefter ett kort svar med samma prompt före och efter bytet.

När både modellistan och körläget är kontrollerade kan du ansluta ett användargränssnitt enligt guiden till Open WebUI ovanpå Ollama. Den guiden har ett annat ansvar: gränssnittets data och anslutning. Behåll Ollamas modellvolym som en egen post i drift- och backupplanen.

Källor

Metod och avgränsning

Underlaget kontrollerades 11 oktober 2026. Exemplen bygger på leverantörernas dokumentation och har inte körts mot lokal Docker- eller GPU-hårdvara. Inga prestandaresultat, testade installationer eller kompatibilitetslöften anges. Kontrollera stödet igen när operativsystem, drivrutin eller image-version ändras.