Verschil tussen ollama pull en ollama run uitgelegd

ollama pull versus ollama run

ollama pull downloadt een model en stopt daarna. ollama run downloadt het model alleen als het ontbreekt, laadt het vervolgens in het geheugen en opent een interactieve chat. De download is identiek en de bestanden worden op dezelfde locatie opgeslagen. Alleen run blijft daarna actief.

Dat ene verschil bepaalt welk commando in een script thuishoort en welk commando u vanaf het toetsenbord gebruikt.

ollama pull gemma4
ollama run gemma4
ollama run gemma4 "Reply with one word: ready"

De eerste regel haalt het model op en sluit af, waardoor deze veilig is voor provisioning en in een systemd unit. De tweede regel opent een chatsessie; typ /bye of druk op Ctrl+D om deze te verlaten. De derde regel verstuurt een enkele prompt, print het antwoord en sluit af; dit is de vorm die een script vereist wanneer het een antwoord nodig heeft in plaats van een sessie. Modelnamen veranderen snel, dus beschouw gemma4 hier als een tijdelijke aanduiding: dit is het voorbeeld dat de officiële Ollama-documentatie per augustus 2026 gebruikt, en elke tag uit de bibliotheek gedraagt zich op dezelfde manier.

Waarom de eerste ollama run lijkt te zijn vastgelopen

Een eerste run op een nieuwe VPS kan enkele minuten zonder output blijven staan. Er is niets defect. De chat-prompt kan pas verschijnen zodra het model op de schijf staat en in het geheugen is geladen; run voert dus een download van meerdere gigabytes uit voordat er iets getoond kan worden.

Twee factoren maskeren dit proces. Ollama tekent de voortgangsbalk alleen wanneer de output naar een terminal gaat. Daarom print een run in een shell-script, een cron-job, een CI-stap of een eenvoudige ssh host ollama run ... helemaal niets tijdens het downloaden. Zodra de bytes zijn binnengehaald, moet het bestand bovendien van de schijf naar het RAM worden gelezen voordat het eerste token kan worden gegenereerd. Op een kleine VPS verloopt dit leesproces traag. Als de server onvoldoende geheugen heeft voor het model, begint de kernel met swappen en neemt de wachttijd aanzienlijk toe.

Monitor het proces vanuit een tweede sessie in plaats van te gissen:

df -h /
watch -n5 df -h /

Vrije schijfruimte die stapsgewijs afneemt, betekent dat de download nog bezig is. Vrije schijfruimte die stopt met afnemen terwijl het commando nog actief is, betekent dat de download is voltooid en het laden in het geheugen is gestart.

Dit is de reden om modellen vooraf op te halen. De gebruiker die ollama run uitvoert, zou nooit degene moeten zijn die op de download moet wachten.

Haal het model op voordat erom gevraagd wordt

Haal op een nieuwe server hetzelfde script op dat de server installeert:

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

Als u de server voor de eerste keer opzet, behandelt de volledige Ollama op een VPS installatie de service zelf en wie deze mag benaderen. Daarna is het de moeite waard om een pull-opdracht in te stellen die langer duurt dan uw terminalsessie; een download die halverwege wordt afgebroken, leidt er namelijk toe dat gebruikers eindigen met een gedeeltelijk gevulde modelopslag.

Voer dit uit binnen tmux, of geef het aan systemd als een one-shot unit die bij het opstarten wordt uitgevoerd. Schrijf /etc/systemd/system/ollama-pull.service:

[Unit]
Description=Pre-pull Ollama models
Wants=ollama.service network-online.target
After=ollama.service network-online.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c 'until ollama list >/dev/null 2>&1; do sleep 2; done'
ExecStart=/bin/sh -c 'ollama pull gemma4'

[Install]
WantedBy=multi-user.target

Beide opdrachten worden bewust uitgevoerd via /bin/sh -c. Een kale ExecStart= vereist een absoluut pad, en het installatieprogramma plaatst het binaire bestand niet altijd in dezelfde map, dus command -v ollama op uw eigen systeem is het enige betrouwbare antwoord. Het gebruik van de shell hanteert het PATH van de service in plaats van een pad dat uit een handleiding is gekopieerd. De eerste ExecStart is ook van belang: After=ollama.service betekent dat de server-unit is gestart, wat niet hetzelfde is als gereed zijn, dus de lus wacht totdat ollama list antwoordt voordat de pull begint.

sudo systemctl daemon-reload
sudo systemctl enable --now ollama-pull.service
journalctl -u ollama-pull.service

Het logboek (journal) zou moeten laten zien dat de pull zonder fouten is voltooid en ollama list zou daarna het model moeten tonen. Om een bewegende tag actueel te houden, voegt u een systemd-timer of een wekelijkse cron-taak toe die dezelfde pull uitvoert. Het opnieuw ophalen van een tag die is verplaatst, downloadt de nieuwe lagen en laat de oude lagen achter zonder verwijzingen; deze worden opgeschoond zodra de server de volgende keer opstart.

Wat gebeurt er als een pull wordt onderbroken

Elke laag van een model wordt opgeslagen onder een hash van de eigen inhoud. Een onderbroken pull is daarom geen verloren werk: voer hetzelfde ollama pull opnieuw uit en de lagen die al voltooid waren, worden herkend en overgeslagen, zodat de download doorgaat bij de laag die werd afgebroken.

Eén actie vernietigt die voortgang. Wanneer de Ollama server start, verwijdert deze opgeslagen lagen waarnaar geen enkel modelmanifest verwijst, en de gedeeltelijke laag die achterblijft na een afgebroken pull is precies dat. Het herstarten van de service voordat u het opnieuw probeert, gooit dus het deel weg dat u al had gedownload. Probeer de pull eerst opnieuw en herstart pas later. Als een gedeeltelijke download echt een herstart moet overleven, stel dan OLLAMA_NOPRUNE=1 in de service-omgeving in en verwijder deze daarna weer, omdat die opruiming bij het opstarten voorkomt dat weeslagen zich op de schijf ophopen.

Als de pull is mislukt met no space left on device, maak dan schijfruimte vrij voordat u het opnieuw probeert. Als df een volle schijf rapporteert en du in de modelmap dit niet verklaart, is de ruimte ergens anders naartoe gegaan en is de redenen waarom df en du verschillen het lezen waard voordat u iets verwijdert.

Waar slaat Ollama modellen op op een VPS?

Vraag het aan uw eigen server in plaats van te vertrouwen op een pad uit een handleiding, inclusief deze. De locatie verschilt tussen een pakketinstallatie en een container, en verandert opnieuw als iemand OLLAMA_MODELS heeft ingesteld.

systemctl cat ollama.service
getent passwd ollama
sudo find / -xdev -type d -name blobs 2>/dev/null

systemctl cat toont het unit-bestand samen met elke drop-in, waardoor een OLLAMA_MODELS-regel die door u is ingesteld of in uw image is ingebakken, zichtbaar wordt. Zonder zo'n regel bevindt de opslag zich in de thuismap van het account waaronder de service draait, en getent passwd toont die thuismap in het zesde, door dubbele punten gescheiden veld. Het find-commando doorzoekt een bestandssysteem naar de blobs-map, waar de lagen daadwerkelijk worden weggeschreven. Gebruik -xdev als de modellen mogelijk al op een apart mountpoint staan.

Meet nu zelf en lees uw eigen cijfers af:

ollama list
df -h /
sudo du -sh /the/directory/you/found
sudo du -h -d1 /the/directory/you/found

De opslag bestaat uit twee delen. manifests bevat één klein bestand per model-tag, waarin de lagen staan waaruit de tag is opgebouwd. blobs bevat de lagen zelf, elk vernoemd naar de hash van de inhoud; hier bevindt zich vrijwel de gehele omvang. Omdat lagen worden gedeeld tussen tags, rapporteren twee modellen die op dezelfde gewichten zijn gebaseerd elk hun eigen grootte in ollama list, terwijl ze die ruimte slechts één keer op de schijf innemen. De opgetelde groottes kunnen daarom hoger uitvallen dan wat du rapporteert voor de map.

Modelbestanden vullen een klein root-bestandssysteem van een VPS sneller dan vrijwel alles wat u anders zou installeren, en de belangrijkste factor voor de omvang is het gewichtsformaat. Kiezen tussen q4, q8 en fp16 scheelt gigabytes per model.

Verplaats de modellen naar een datavolume met OLLAMA_MODELS

Als het plan voorziet in een tweede schijf of een groter datavolume, verplaats de opslag dan voordat het root-bestandssysteem vol raakt. Stop eerst de server, zodat u geen bestand kopieert dat nog wordt weggeschreven.

sudo systemctl stop ollama
sudo mkdir -p /mnt/data/ollama-models
sudo rsync -a /the/directory/you/found/ /mnt/data/ollama-models/
sudo chown -R ollama:ollama /mnt/data/ollama-models
sudo systemctl edit ollama.service

systemctl edit opent een editor voor een drop-in-bestand, zodat de meegeleverde unit ongewijzigd blijft en een pakket-upgrade uw wijziging niet kan overschrijven. Voeg deze twee regels toe:

[Service]
Environment="OLLAMA_MODELS=/mnt/data/ollama-models"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment
ollama list

systemctl show zou uw nieuwe pad moeten weergeven en ollama list zou dezelfde modellen moeten tonen als voor de verplaatsing. Een lege lijst betekent dat de server de nieuwe map niet kan lezen. De service draait als de ollama-gebruiker, dus die gebruiker heeft lees- en schrijftoegang nodig tot de bestemming; dit is de taak van de bovenstaande chown-regel. Controleer journalctl -e -u ollama op rechtenfouten die het nieuwe pad vermelden. Verwijder de oude kopie pas nadat de lijst correct is, want een mislukte verplaatsing in combinatie met een verwijderde bron betekent dat alles opnieuw moet worden gedownload.

De andere optie behoudt het oorspronkelijke pad en koppelt het datavolume hierop aan:

echo '/mnt/data/ollama-models /the/directory/you/found none bind 0 0' | sudo tee -a /etc/fstab
sudo mount -a
findmnt /the/directory/you/found
df -h /

findmnt als de mount wordt weergegeven, betekent dit dat de bind actief is. Een bind-mount is nuttig wanneer iets anders op de machine de standaardlocatie al verwacht. Er is één valkuil: de bestanden die u hebt gekopieerd, staan nog steeds onder het mountpoint op de root-schijf, verborgen door de mount. De schijfruimte komt pas vrij nadat u de mount ontkoppelt en de bestanden verwijdert. De omgevingsvariabele is de makkelijkste van de twee om uit te leggen aan de volgende beheerder die inlogt.

Waar een container ze bewaart

De officiële image slaat modellen op in wat u ook mount, niet in een host-directory die toebehoort aan een ollama-gebruiker. Het gedocumenteerde run-commando is:

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

ollama voor de dubbele punt is een named Docker volume, en /root/.ollama is de locatie waar de server binnen de container naar schrijft. Daarom vindt du op de paden uit de vorige sectie niets, omdat daar niets staat. Toon de werkelijke locatie en grootte:

docker volume inspect ollama
docker system df -v
docker exec -it ollama ollama list

Lees het Mountpoint-veld uit docker volume inspect en voer vervolgens sudo du -sh uit op die locatie. Om de modellen op een data-volume te plaatsen, vervangt u het named volume door een host-directory (-v /mnt/data/ollama:/root/.ollama) en maakt u de container opnieuw aan. De container schrijft als root, waardoor die host-directory eigendom wordt van root. Bij rootless Podman worden de id's in plaats daarvan gemapt naar het subuid-bereik van uw gebruiker, waardoor het eigendom op de host er weer anders uitziet: Ollama draaien onder rootless Podman behandelt die mapping.

Eén waarschuwing over opschonen. docker volume prune verwijdert elk volume waarnaar geen enkele container verwijst. Als u de ollama-container verwijdert of opnieuw aanmaakt zonder het bijbehorende volume, zal een latere prune elk model dat u heeft gedownload verwijderen, zonder mogelijkheid tot herstel behalve door ze opnieuw te downloaden. Lees hoe Docker-schijfgebruik op een VPS op te schonen voordat u prune uitvoert op een server die modellen host.

Verwijder een model met ollama rm, niet met rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm verwijdert het manifest voor die tag en verwijdert vervolgens de layers waarnaar geen enkel overgebleven manifest meer verwijst. De schijfruimte komt direct vrij zodra deze bestanden zijn ontkoppeld, dus df werkt onmiddellijk. Omdat layers worden gedeeld, kan het verwijderen van een van twee nauw verwante tags veel minder ruimte vrijmaken dan de grootte die ollama list ernaast weergeeft. Dit is correct gedrag en geen mislukte verwijdering.

Het handmatig verwijderen van bestanden verbreekt de samenhang. Verwijder een blob met rm en het manifest blijft ernaar verwijzen, waardoor ollama list het model blijft tonen en elke poging om het te gebruiken faalt zodra de ontbrekende layer wordt ingelezen. Verwijder een manifest handmatig en de bijbehorende layers blijven op de schijf staan zonder dat er iets naar verwijst; ze nemen ruimte in beslag waar geen enkel Ollama-commando u over zal informeren. Als u dit al heeft gedaan, wist ollama rm op de tag het achtergebleven item, en het herstarten van de server ruimt layers op waar niets naar verwijst.

Nog één laatste onderscheid, omdat de twee constant door elkaar worden gehaald. ollama rm heeft betrekking op schijfruimte. ollama stop gemma4 verwijdert een model uit het geheugen en maakt geen schijfruimte vrij. Hoe lang een model in het RAM-geheugen blijft nadat het laden is voltooid, is een afzonderlijke instelling, en een model geladen houden in plaats van het bij elk verzoek opnieuw te laden behandelt dit onderwerp.

FAQ

Wat is het verschil tussen ollama pull en ollama run?

ollama pull downloadt een model naar de schijf en sluit af. ollama run controleert of het model al op de schijf staat, downloadt het indien dit niet het geval is, laadt het in het geheugen en opent vervolgens een interactieve chatsessie. Beide schrijven dezelfde bestanden naar dezelfde map. Gebruik pull bij provisioning en in scripts, en gebruik run wanneer een gebruiker achter het toetsenbord zit. ollama run <model> "your prompt" verstuurt één prompt en sluit af; dit is de scriptbare vorm van run.

Waarom lijkt mijn eerste ollama run te blijven hangen?

Het model wordt gedownload. De chatprompt verschijnt pas zodra het model op de schijf staat en in het geheugen is geladen; een model is enkele gigabytes groot. Ollama toont de voortgangsbalk alleen wanneer de output een terminal is, dus een run in een script, een cron job of een ssh host ollama run ... toont niets terwijl het proces bezig is. Open een tweede sessie en voer watch -n5 df -h / uit: als de vrije schijfruimte stapsgewijs afneemt, is de download bezig. Download het model vooraf om de wachttijd te voorkomen.

Waar slaat Ollama zijn modellen op?

De locatie hangt af van de installatie, dus controleer dit in plaats van ervan uit te gaan. Voer systemctl cat ollama.service uit om te zien of OLLAMA_MODELS is ingesteld in de unit of een drop-in. Als dit niet het geval is, bevindt de opslag zich in de homedirectory van het account waaronder de service draait, wat getent passwd ollama weergeeft. sudo find / -xdev -type d -name blobs 2>/dev/null lokaliseert de map met lagen direct. Voor de container-image bevindt de opslag zich in de gemounte volume, en docker volume inspect ollama toont het host-Mountpoint daarvan.

Hoe verplaats ik Ollama-modellen naar een andere schijf?

Stop de service, kopieer de opslag naar de nieuwe locatie met rsync -a, wijs de map toe aan het service-account met sudo chown -R ollama:ollama <directory>, voer vervolgens sudo systemctl edit ollama.service uit en voeg Environment="OLLAMA_MODELS=<directory>" toe onder een [Service]-regel. Herlaad met sudo systemctl daemon-reload en herstart de service. Bevestig met systemctl show ollama --property=Environment en ollama list. Een lege lijst betekent bijna altijd dat de ollama-gebruiker de nieuwe map niet kan lezen; journalctl -e -u ollama toont het pad.

Maakt het verwijderen van de modelbestanden de ruimte vrij?

Het handmatig verwijderen van bestanden maakt de bytes vrij, maar laat de opslag in een inconsistente staat achter. Verwijder een blob en het manifest blijft het model vermelden, waardoor het in ollama list blijft verschijnen en faalt bij gebruik. Verwijder een manifest en de bijbehorende lagen blijven op de schijf staan zonder verwijzingen. Gebruik ollama rm <model>, wat het manifest verwijdert en vervolgens de lagen die door geen enkel ander model worden gebruikt. Als bestanden al handmatig zijn verwijderd, voer dan ollama rm uit op de tag om de vermelding te wissen, en herstart vervolgens de server; dit verwijdert lagen waarnaar geen enkel manifest meer verwijst.