Ollama pull a run: różnice i lokalizacja plików modeli

ollama pull a ollama run

ollama pull pobiera model i kończy działanie. ollama run pobiera model tylko wtedy, gdy go brakuje, a następnie ładuje go do pamięci i otwiera interaktywny czat. Proces pobierania jest identyczny, a pliki trafiają w to samo miejsce. Tylko run kontynuuje działanie po zakończeniu pobierania.

Ta jedna różnica decyduje o tym, które polecenie należy umieścić w skrypcie, a które wywołać z klawiatury.

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

Pierwsza linia pobiera model i kończy działanie, dlatego jest bezpieczna w procesach wdrażania oraz w jednostkach systemd. Druga otwiera sesję czatu; wpisz /bye lub naciśnij Ctrl+D, aby ją opuścić. Trzecia wysyła pojedyncze zapytanie, wyświetla odpowiedź i kończy działanie – jest to forma pożądana w skryptach, gdy wymagana jest odpowiedź, a nie sesja interaktywna. Ta trzecia forma pozostawia długość odpowiedzi całkowicie w gestii modelu, więc pytanie jednowierszowe może skutkować trzema akapitami tekstu, dlatego ograniczenie odpowiedzi za pomocą num_predict pozwala utrzymać wynik skryptowego run w rozmiarze użytecznym dla wywołującego procesu. Nazwy modeli zmieniają się dynamicznie, więc traktuj gemma4 w tym miejscu jako symbol zastępczy: jest to przykład używany w oficjalnej dokumentacji Ollama na sierpień 2026, a każdy tag z biblioteki zachowuje się w ten sam sposób. Jeśli wolisz użyć modelu, którego rozmiar został już zweryfikowany na rzeczywistym serwerze, uruchomienie Nemotron 3.5 Lightning na VPS wskazuje dokładny tag do pobrania oraz ilość pamięci, jakiej wymaga ten model.

Dlaczego pierwsze uruchomienie ollama wygląda na zawieszone

Pierwsze wywołanie run na świeżym VPS może przez kilka minut nie generować żadnych komunikatów. Nie oznacza to awarii. Prompt czatu nie pojawi się, dopóki model nie zostanie pobrany na dysk i załadowany do pamięci, więc run wykonuje pobieranie o rozmiarze wielu gigabajtów, zanim będzie w stanie wyświetlić cokolwiek.

Dwa czynniki maskują ten proces. Ollama rysuje pasek postępu tylko wtedy, gdy wyjście jest terminalem, więc run wewnątrz skryptu powłoki, zadania cron, kroku CI lub zwykłego ssh host ollama run ... nie drukuje niczego podczas pobierania. Następnie, gdy dane zostaną zapisane, plik musi zostać odczytany z dysku do pamięci RAM przed wygenerowaniem pierwszego tokena, a na małym VPS ten odczyt jest powolny. Jeśli serwer nie posiada wystarczającej ilości pamięci dla modelu, jądro zaczyna korzystać ze swapu, co znacznie wydłuża czas oczekiwania.

Zamiast zgadywać, należy monitorować proces z drugiej sesji:

df -h /
watch -n5 df -h /

Spadek wolnego miejsca w krokach oznacza, że pobieranie nadal trwa. Jeśli wolne miejsce przestaje maleć, a polecenie jest nadal zajęte, oznacza to, że pobieranie się zakończyło i rozpoczęło się ładowanie do pamięci.

To główny argument za wcześniejszym pobieraniem modeli. Osoba wpisująca ollama run nigdy nie powinna być tą, która czeka na zakończenie pobierania.

Pobierz model, zanim ktokolwiek o niego zapyta

To samo dotyczy wszystkiego, co nie jest człowiekiem: agent programistyczny skierowany na endpoint Ollama zazwyczaj podda się przy pierwszym żądaniu, zamiast czekać na pobranie wielu gigabajtów danych. Na nowej maszynie pobierz model za pomocą tego samego skryptu, który instaluje serwer:

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

Jeśli uruchamiasz serwer po raz pierwszy, pełna instalacja Ollama na VPS obejmuje samą usługę oraz listę podmiotów uprawnionych do łączenia się z nią. Następnie warto skonfigurować pobieranie, które nie zostanie przerwane po zamknięciu terminala, ponieważ przerwanie pobierania w połowie prowadzi do powstania niekompletnych plików w magazynie modeli.

Uruchom to wewnątrz tmux lub przekaż do systemd jako jednostkę typu one-shot, która wykonuje się podczas startu systemu. Utwórz /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

Oba polecenia celowo przechodzą przez /bin/sh -c. Wywołanie samego ExecStart= wymaga podania ścieżki bezwzględnej, a instalator nie zawsze umieszcza plik binarny w tym samym katalogu, więc command -v ollama na własnej maszynie jest jedynym niezawodnym rozwiązaniem. Użycie powłoki pozwala na wykorzystanie zmiennej PATH usługi, zamiast ścieżki skopiowanej z poradnika. Pierwsze ExecStart jest również istotne: After=ollama.service oznacza, że jednostka serwera została uruchomiona, co nie jest równoznaczne z gotowością do pracy, dlatego pętla czeka, aż ollama list odpowie, zanim rozpocznie się pobieranie.

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

Dziennik powinien wykazać zakończenie pobierania bez błędów, a ollama list powinno następnie wyświetlić model. Aby utrzymać aktualność zmiennego tagu, dodaj timer systemd lub wpis w cronie wykonywany raz w tygodniu, który uruchamia to samo polecenie pobierania. Ponowne pobranie tagu, który został zaktualizowany, spowoduje pobranie nowych warstw i pozostawienie starych bez odniesień, a te zostaną usunięte przy następnym uruchomieniu serwera.

Co się dzieje w przypadku przerwania pobierania

Każda warstwa modelu jest przechowywana pod hashem własnej zawartości. Przerwane pobieranie nie oznacza zatem zmarnowanej pracy: ponowne uruchomienie tego samego ollama pull powoduje rozpoznanie i pominięcie warstw, które zostały już pobrane, dzięki czemu proces jest kontynuowany od warstwy, na której został przerwany.

Jedno działanie niweczy ten postęp. Po uruchomieniu serwera Ollama usuwa on przechowywane warstwy, do których nie odwołuje się żaden manifest modelu, a częściowa warstwa pozostała po przerwaniu pobierania jest właśnie takim elementem. Zatem restart usługi przed ponowieniem próby powoduje utratę już pobranych danych. Najpierw ponów pobieranie, a dopiero później wykonaj restart. Jeśli częściowe pobieranie musi przetrwać restart, ustaw OLLAMA_NOPRUNE=1 w środowisku usługi, a następnie usuń to ustawienie, ponieważ to właśnie czyszczenie przy starcie zapobiega gromadzeniu się osieroconych warstw na dysku.

Jeśli pobieranie zostało przerwane z powodu no space left on device, zwolnij miejsce przed ponowną próbą. Jeśli df wskazuje na zapełnienie dysku, a du w katalogu modelu nie wyjaśnia tego stanu, miejsce zostało zajęte przez inne dane i warto zapoznać się z przyczynami rozbieżności między df a du przed usunięciem jakichkolwiek plików.

Gdzie Ollama przechowuje modele na serwerze VPS?

Należy sprawdzić własną instancję, zamiast polegać na ścieżce z jakiegokolwiek poradnika, w tym niniejszego. Lokalizacja różni się w zależności od tego, czy instalacja odbyła się z pakietu, czy w kontenerze, a także zmienia się, jeśli zdefiniowano OLLAMA_MODELS.

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

systemctl cat wyświetla plik jednostki wraz ze wszystkimi plikami uzupełniającymi, więc linia OLLAMA_MODELS ustawiona przez użytkownika lub zawarta w obrazie będzie tam widoczna. W przypadku braku takiej linii, magazyn znajduje się w katalogu domowym konta, na którym uruchomiona jest usługa, a getent passwd wyświetla ten katalog domowy w szóstym polu oddzielonym dwukropkiem. Polecenie find przeszukuje system plików w poszukiwaniu katalogu blobs, w którym faktycznie zapisywane są warstwy. Należy pominąć -xdev, jeśli modele mogą już znajdować się na oddzielnym punkcie montowania.

Teraz należy dokonać pomiaru i odczytać własne wartości:

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

Magazyn składa się z dwóch części. manifests przechowuje jeden mały plik dla każdego tagu modelu, a plik ten zawiera listę warstw, z których zbudowany jest dany tag. blobs przechowuje same warstwy, z których każda nazwana jest zgodnie z hashem swojej zawartości, i to tam znajduje się większość zajmowanego miejsca. Ponieważ warstwy są współdzielone między tagami, dwa modele zbudowane na tych samych wagach raportują własny rozmiar w ollama list, zajmując przy tym to miejsce na dysku tylko raz, dlatego sumaryczne rozmiary mogą być większe niż te, które raportuje du dla całego katalogu.

Pliki modeli zapełniają mały system plików root na serwerze VPS szybciej niż jakikolwiek inny komponent, a najważniejszym czynnikiem wpływającym na ich rozmiar jest format wag. Wybór między q4, q8 a fp16 pozwala zaoszczędzić gigabajty na każdym modelu.

Przenoszenie modeli do wolumenu danych za pomocą OLLAMA_MODELS

Jeśli serwer posiada drugi dysk lub większy wolumen danych, należy przenieść magazyn przed zapełnieniem systemu plików root. Najpierw zatrzymaj serwer, aby uniknąć kopiowania pliku, który jest w trakcie zapisu.

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 otwiera edytor pliku typu drop-in, dzięki czemu dostarczona jednostka pozostaje nienaruszona, a aktualizacja pakietu nie nadpisze wprowadzonych zmian. Dodaj te dwie linie:

[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 powinno wyświetlić nową ścieżkę, a ollama list powinno pokazać te same modele, co przed przeniesieniem. Pusta lista oznacza, że serwer nie może odczytać nowego katalogu. Usługa działa jako użytkownik ollama, więc musi on posiadać uprawnienia do odczytu i zapisu w miejscu docelowym, co zapewnia linia chown powyżej. Sprawdź journalctl -e -u ollama pod kątem błędów uprawnień wskazujących na nową ścieżkę. Usuń starą kopię dopiero po upewnieniu się, że lista jest poprawna, ponieważ nieudane przeniesienie połączone z usunięciem źródła oznacza konieczność ponownego pobrania wszystkich danych.

Druga opcja polega na zachowaniu oryginalnej ścieżki i zamontowaniu w niej wolumenu danych:

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 wyświetlające punkt montowania oznacza, że bind jest aktywny. Montowanie typu bind jest przydatne, gdy inne elementy systemu oczekują domyślnej lokalizacji. Istnieje jednak pewne ryzyko: skopiowane pliki nadal znajdują się pod punktem montowania na dysku root, ukryte przez montowanie, więc zwolnienie miejsca nastąpi dopiero po odmontowaniu i usunięciu tych plików. Zmienna środowiskowa jest łatwiejsza do wyjaśnienia dla kolejnego administratora systemu.

Gdzie kontener przechowuje te dane

Oficjalny obraz przechowuje modele w lokalizacji, którą użytkownik zamontuje, a nie w żadnym katalogu hosta należącym do użytkownika ollama. Udokumentowane polecenie uruchomieniowe to:

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

ollama przed dwukropkiem to nazwany wolumen Docker, a /root/.ollama to ścieżka, w której serwer zapisuje dane wewnątrz kontenera. Dlatego polecenie du wykonane dla ścieżek z poprzedniej sekcji nic nie zwraca, ponieważ dane tam nie istnieją. Aby wyświetlić rzeczywistą lokalizację i rozmiar, należy użyć:

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

Należy odczytać pole Mountpoint z danych wyjściowych docker volume inspect, a następnie wykonać sudo du -sh dla tej ścieżki. Aby umieścić modele na wolumenie danych, należy zastąpić nazwany wolumen katalogiem hosta (-v /mnt/data/ollama:/root/.ollama) i ponownie utworzyć kontener. Kontener zapisuje dane jako root, więc katalog hosta staje się własnością użytkownika root. W przypadku bezkorzeniowego (rootless) Podman identyfikatory są mapowane na zakres subuid użytkownika, więc własność na hoście wygląda inaczej: uruchamianie Ollama w trybie rootless Podman zawiera szczegóły tego mapowania.

Ostrzeżenie dotyczące czyszczenia. Polecenie docker volume prune usuwa każdy wolumen, do którego nie odwołuje się żaden kontener. Usunięcie lub ponowne utworzenie kontenera ollama bez jego wolumenu, a następnie wykonanie operacji prune, spowoduje usunięcie wszystkich pobranych modeli bez możliwości ich odzyskania poza ponownym pobraniem. Przed uruchomieniem czyszczenia na serwerze przechowującym modele należy zapoznać się z artykułem jak czyścić przestrzeń dyskową Docker na VPS.

Usuwanie modelu za pomocą ollama rm, a nie rm

ollama list
ollama rm gemma4
ollama list
df -h /

ollama rm usuwa manifest dla danego tagu, a następnie usuwa warstwy, do których nie odwołuje się żaden pozostały manifest. Miejsce na dysku zostaje odzyskane natychmiast po odlinkowaniu tych plików, więc df zwalnia przestrzeń od razu. Ponieważ warstwy są współdzielone, usunięcie jednego z dwóch blisko powiązanych tagów może zwolnić znacznie mniej miejsca niż wskazuje rozmiar ollama list wyświetlony obok. Jest to poprawne zachowanie, a nie błąd usuwania.

Ręczne usuwanie plików narusza spójność pary. Usunięcie bloba za pomocą rm sprawia, że manifest nadal go wymienia, więc ollama list wciąż wyświetla model, a każda próba jego użycia kończy się niepowodzeniem w momencie odczytu brakującej warstwy. Ręczne usunięcie manifestu powoduje, że jego warstwy pozostają na dysku, nie będąc wskazywanymi przez żaden obiekt, co zajmuje miejsce, o którym żadne polecenie Ollama nie poinformuje. Jeśli taka operacja została już wykonana, ollama rm na danym tagu wyczyści pozostały wpis, a restart serwera usunie warstwy, do których nic się nie odwołuje.

Ostatnie rozróżnienie, ponieważ te dwie kwestie są stale mylone. ollama rm dotyczy dysku. ollama stop gemma4 usuwa model z pamięci i nie zwalnia żadnego miejsca na dysku. Czas, przez jaki model pozostaje w pamięci RAM po zakończeniu pobierania, jest osobnym ustawieniem, a utrzymywanie modelu w pamięci zamiast przeładowywania go przy każdym żądaniu omawia ten temat.

FAQ

Jaka jest różnica między ollama pull a ollama run?

ollama pull pobiera model na dysk i kończy działanie. ollama run sprawdza, czy model znajduje się już na dysku, pobiera go w razie potrzeby, ładuje do pamięci, a następnie otwiera interaktywną sesję czatu. Oba polecenia zapisują te same pliki w tym samym katalogu. Używaj pull w procesach wdrażania i skryptach, a run, gdy użytkownik pracuje przy klawiaturze. ollama run <model> "your prompt" wysyła jeden prompt i kończy działanie; jest to skryptowalna forma run.

Dlaczego pierwsze uruchomienie ollama run wydaje się zawieszać?

Trwa pobieranie. Prompt czatu nie pojawi się, dopóki model nie zostanie pobrany na dysk i załadowany do pamięci, a modele zajmują kilka gigabajtów. Ollama wyświetla pasek postępu tylko wtedy, gdy wyjście jest terminalem, więc run wewnątrz skryptu, zadania cron lub ssh host ollama run ... nie pokazuje niczego podczas pracy. Otwórz drugą sesję i uruchom watch -n5 df -h /: spadająca ilość wolnego miejsca oznacza, że pobieranie trwa. Pobierz model wcześniej, aby wyeliminować czas oczekiwania.

Gdzie Ollama przechowuje swoje modele?

Lokalizacja zależy od instalacji, więc należy ją sprawdzić, zamiast zakładać domyślną. Uruchom systemctl cat ollama.service, aby sprawdzić, czy OLLAMA_MODELS jest ustawione w jednostce lub pliku drop-in. Jeśli nie, magazyn znajduje się w katalogu domowym konta, na którym działa usługa, co wyświetla getent passwd ollama. sudo find / -xdev -type d -name blobs 2>/dev/null wskazuje bezpośrednio katalog warstw. W przypadku obrazu kontenera magazyn znajduje się wewnątrz zamontowanego wolumenu, a docker volume inspect ollama wyświetla jego ścieżkę Mountpoint na hoście.

Jak przenieść modele Ollama na inny dysk?

Zatrzymaj usługę, skopiuj magazyn do nowej lokalizacji za pomocą rsync -a, nadaj uprawnienia do katalogu dla konta usługi za pomocą sudo chown -R ollama:ollama <directory>, a następnie uruchom sudo systemctl edit ollama.service i dodaj Environment="OLLAMA_MODELS=<directory>" pod sekcją [Service]. Przeładuj konfigurację za pomocą sudo systemctl daemon-reload i zrestartuj usługę. Potwierdź za pomocą systemctl show ollama --property=Environment oraz ollama list. Pusta lista prawie zawsze oznacza, że użytkownik ollama nie ma uprawnień do odczytu nowego katalogu; journalctl -e -u ollama wskaże właściwą ścieżkę.

Czy usunięcie plików modelu zwalnia miejsce?

Ręczne usuwanie plików zwalnia bajty, ale pozostawia magazyn w stanie niespójnym. Usunięcie obiektu blob sprawia, że manifest nadal wymienia dany model, więc pojawia się on w ollama list i kończy błędem przy próbie użycia. Usunięcie manifestu pozostawia jego warstwy na dysku bez odniesień. Używaj ollama rm <model>, które usuwa manifest, a następnie warstwy, których nie potrzebuje żaden inny model. Jeśli pliki zostały już usunięte ręcznie, uruchom ollama rm dla danego tagu, aby wyczyścić wpis, a następnie zrestartuj serwer, co usunie warstwy, do których nie odwołuje się żaden manifest.