Verschil Ollama pull en run: waar staan de modellen?

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 een 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 opent een chatsessie; typ /bye of druk op Ctrl+D om deze te verlaten. De derde 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. Die derde vorm laat de lengte van het antwoord nog steeds volledig over aan het model, dus een vraag van één regel kan resulteren in drie alinea's. Daarom is het antwoord beperken met num_predict de manier om een gescripte run binnen een omvang te houden die de aanroeper daadwerkelijk kan verwerken. Modelnamen veranderen snel, dus beschouw gemma4 hier als een tijdelijke aanduiding: het is het voorbeeld dat de officiële Ollama-documentatie per augustus 2026 gebruikt, en elke tag uit de bibliotheek gedraagt zich op dezelfde manier. Als u liever een model gebruikt dat al is afgestemd op een echte server, biedt het draaien van Nemotron 3.5 Lightning op een VPS de exacte tag om op te halen en het geheugen dat daarvoor vereist is.

Waarom de eerste ollama run lijkt te zijn vastgelopen

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

Twee factoren verhullen dit proces. Ollama tekent de voortgangsbalk alleen wanneer de output naar een terminal gaat; daarom print een run binnen 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 wordt gegenereerd, en op een kleine VPS verloopt dit lezen 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 te downloaden. De persoon die ollama run typt, zou nooit degene moeten zijn die op de download moet wachten.

Haal het model op voordat iemand erom vraagt

Hetzelfde geldt voor alles wat geen persoon is: een coding agent die naar uw Ollama endpoint wijst zal doorgaans opgeven bij het eerste verzoek in plaats van te wachten op een download van meerdere gigabytes. Haal op een nieuwe machine 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 in te stellen die uw terminalsessie overleeft, omdat een download die halverwege wordt afgebroken de reden is dat mensen eindigen met een half gevulde model store.

Voer dit uit binnen tmux, of geef het aan systemd als een one-shot unit die bij het opstarten draait. 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 commando's worden bewust uitgevoerd via /bin/sh -c. Een kale ExecStart= vereist een absoluut pad, en de installer plaatst het binaire bestand niet altijd in dezelfde map, dus command -v ollama op uw eigen machine is het enige betrouwbare antwoord. Via de shell gebruiken we het service PATH 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, dus de lus wacht tot ollama list antwoordt voordat de pull begint.

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

De journal zou moeten laten zien dat de pull zonder fouten wordt 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-entry 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 de volgende keer dat de server start.

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 verspild werk: voer de betreffende 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 instelling daarna weer, omdat die opschoonactie bij het opstarten voorkomt dat verweesde lagen 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 aangeeft en du in de modelmap dit niet verklaart, is de ruimte ergens anders naartoe gegaan, en is het de moeite waard om de redenen waarom df en du verschillen te lezen voordat u iets verwijdert.

Waar slaat Ollama modellen op op een VPS?

Raadpleeg 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, daar zichtbaar wordt. Zonder een dergelijke 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 doorzoekt een bestandssysteem naar de blobs-map, waar de lagen daadwerkelijk worden weggeschreven. Laat -xdev weg als de modellen mogelijk al op een apart koppelpunt staan.

Meet nu en lees uw eigen cijfers:

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, en dat bestand somt de lagen op waaruit de tag is opgebouwd. blobs bevat de lagen zelf, elk vernoemd naar de hash van de inhoud, en vrijwel de gehele omvang bevindt zich daar. 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 eenmaal op de schijf innemen. De opgetelde groottes kunnen daarom hoger uitvallen dan wat du rapporteert voor de map.

Modelbestanden vullen een klein VPS-rootbestandssysteem 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 hoort uw nieuwe pad weer te geven en ollama list hoort dezelfde modellen te 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 schrijfrechten nodig voor 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 daarop 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 getoond, betekent dit dat de bind actief is. Een bind mount is nuttig wanneer een ander proces op de machine al de standaardlocatie 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 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 lagen waarnaar geen enkel overgebleven manifest meer verwijst. De schijfruimte komt direct vrij zodra die bestanden zijn ontkoppeld, dus df werkt onmiddellijk. Omdat lagen 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, geen mislukte verwijdering.

Het handmatig verwijderen van bestanden verbreekt de koppeling. Verwijder een blob met rm en het manifest bevat deze nog steeds, waardoor ollama list het model blijft tonen en elke poging om het te gebruiken faalt zodra de ontbrekende laag wordt gelezen. Verwijder een manifest handmatig en de lagen 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 wist de lagen waar niets naar verwijst.

Nog één laatste onderscheid, omdat de twee constant door elkaar worden gehaald. ollama rm gaat over schijfruimte. ollama stop gemma4 ontlaadt een model uit het geheugen en maakt geen schijfruimte vrij. Hoe lang een model in het RAM-geheugen blijft staan nadat het downloaden 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 daarna 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 commando's schrijven dezelfde bestanden naar dezelfde map. Gebruik pull in provisioning en 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 uitvoer 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 thuismap 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 aangekoppelde volume, en docker volume inspect ollama toont het host-Mountpoint.

Hoe verplaats ik Ollama-modellen naar een andere schijf?

Stop de service, kopieer de opslag naar de nieuwe locatie met rsync -a, geef het eigendom van de map 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 start de service opnieuw. 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 bevat nog steeds het model, waardoor het blijft verschijnen in ollama list en faalt bij gebruik. Verwijder een manifest en de bijbehorende lagen blijven op de schijf staan zonder dat er naar verwezen wordt. Gebruik ollama rm <model>, wat het manifest verwijdert en vervolgens de lagen die door geen enkel ander model nodig zijn. Als bestanden al handmatig zijn verwijderd, voer dan ollama rm uit op de tag om de invoer te wissen en herstart daarna de server; dit verwijdert lagen waar geen enkel manifest naar verwijst.