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. Nazwy modeli zmieniają się dynamicznie, więc traktuj gemma4 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.

Dlaczego pierwsze uruchomienie ollama wygląda na zawieszone

Pierwsze wywołanie run na nowym serwerze VPS może przez kilka minut nie generować żadnych danych wyjściowych. Nie oznacza to awarii. Prompt czatu nie pojawi się, dopóki model nie zostanie pobrany na dysk i załadowany do pamięci, dlatego run wykonuje pobieranie o rozmiarze wielu gigabajtów, zanim wyświetli jakiekolwiek informacje.

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 serwerze 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 poziomu drugiej sesji:

df -h /
watch -n5 df -h /

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

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

Pobranie modelu przed wystąpieniem zapytania

Na nowym serwerze należy pobrać ten sam skrypt, który instaluje serwer:

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

Jeśli serwer jest uruchamiany po raz pierwszy, pełna instalacja Ollama na VPS opisuje samą usługę oraz zasady dostępu do niej. Następnie warto skonfigurować pobieranie, które nie zostanie przerwane po zamknięciu terminala, ponieważ przerwanie pobierania w połowie prowadzi do niekompletnej bazy modeli.

Uruchom proces wewnątrz tmux lub przekaż go do systemd jako jednostkę typu one-shot wykonywaną przy starcie systemu. Utwórz plik /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 wykorzystują /bin/sh -c. Samodzielne ExecStart= wymaga podania ścieżki bezwzględnej, a instalator nie zawsze umieszcza plik binarny w tym samym katalogu, dlatego command -v ollama na własnej maszynie jest jedynym niezawodnym rozwiązaniem. Użycie powłoki pozwala na skorzystanie ze 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 oczekuje na odpowiedź ollama list przed rozpoczęciem pobierania.

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, należy dodać timer systemd lub wpis w cronie uruchamiany raz w tygodniu, który wykona to samo polecenie pobierania. Ponowne pobranie tagu, który został zaktualizowany, spowoduje pobranie nowych warstw i pozostawienie starych bez odniesień; zostaną one 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. Podczas uruchamiania serwer Ollama usuwa zapisane warstwy, do których nie odwołuje się żaden manifest modelu, a niekompletna warstwa pozostawiona przez przerwane pobieranie jest właśnie takim elementem. Zrestartowanie usługi przed ponowieniem próby powoduje więc usunięcie części danych, które zostały już pobrane. Najpierw należy ponowić pobieranie, a dopiero później zrestartować usługę. Jeśli częściowe pobieranie musi przetrwać restart, należy ustawić OLLAMA_NOPRUNE=1 w środowisku usługi, a następnie usunąć 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, przed ponowieniem próby należy zwolnić miejsce. Jeśli df wskazuje na zapełnienie dysku, a du w katalogu modelu nie wyjaśnia tego stanu, oznacza to, że miejsce zostało zajęte gdzie indziej. Przed usunięciem jakichkolwiek plików warto zapoznać się z informacjami na temat przyczyn rozbieżności między df a du.

Gdzie Ollama przechowuje modele na serwerze VPS?

Należy sprawdzić własny system zamiast polegać na ścieżce podanej w jakimkolwiek poradniku, w tym w tym dokumencie. Lokalizacja różni się w zależności od tego, czy oprogramowanie zainstalowano jako pakiet, czy uruchomiono w kontenerze, a także zmienia się, jeśli zdefiniowano zmienną OLLAMA_MODELS.

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

Polecenie systemctl cat wyświetla plik jednostki wraz ze wszystkimi plikami uzupełniającymi, dzięki czemu linia OLLAMA_MODELS ustawiona przez użytkownika lub wbudowana w obraz będzie widoczna. Jeśli taka linia nie istnieje, magazyn znajduje się w katalogu domowym konta, na którym działa usługa, a getent passwd wyświetla ten katalog w szóstym polu oddzielonym dwukropkiem. Polecenie find przeszukuje system plików w poszukiwaniu katalogu blobs, w którym faktycznie zapisywane są warstwy. Użyj -xdev, jeśli modele mogą już znajdować się na oddzielnym punkcie montowania.

Teraz wykonaj pomiar i odczytaj 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 jest nazwana zgodnie z hashem swojej zawartości; 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, podczas gdy na dysku zajmują to miejsce tylko raz. Z tego powodu sumaryczny rozmiar modeli może przekraczać wartość raportowaną przez 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, do którego wciąż trwa zapis.

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 pakietowa 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 zachowuje oryginalną ścieżkę i montuje w niej wolumen 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 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 rozwiązaniem łatwiejszym do wyjaśnienia dla kolejnego administratora.

Gdzie kontener przechowuje te dane

Oficjalny obraz przechowuje modele w miejscu, które zostanie zamontowane, a nie w katalogu hosta należącym do użytkownika ollama. Udokumentowane polecenie uruchomienia 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 du w odniesieniu do ścieżek z poprzedniej sekcji nic nie zwraca, ponieważ dane tam nie istnieją. Wyświetl rzeczywistą lokalizację i rozmiar:

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

Odczytaj pole Mountpoint z docker volume inspect, a następnie uruchom sudo du -sh dla tej ścieżki. Aby umieścić modele na wolumenie danych, zastąp nazwany wolumen katalogiem hosta (-v /mnt/data/ollama:/root/.ollama) i utwórz kontener ponownie. Kontener zapisuje dane jako root, więc katalog hosta staje się własnością użytkownika root. W przypadku bezkorzeniowego (rootless) Podmana identyfikatory są mapowane na zakres subuid użytkownika, więc własność na hoście wygląda inaczej: uruchamianie Ollama w rootless Podman opisuje to mapowanie.

Ostrzeżenie dotyczące czyszczenia. 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. Przeczytaj jak czyścić użycie dysku przez Docker na VPS przed uruchomieniem polecenia prune na serwerze, który przechowuje modele.

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. Odzyskiwanie miejsca następuje natychmiast po odłączeniu tych plików, więc df działa niezwłocznie. Ponieważ warstwy są współdzielone, usunięcie jednego z dwóch ściśle powiązanych tagów może zwolnić znacznie mniej miejsca niż rozmiar ollama list wyświetlony obok niego. Jest to poprawne zachowanie, a nie błąd usuwania.

Ręczne usuwanie plików narusza spójność pary. Usunięcie obiektu blob za pomocą rm sprawia, że manifest nadal go uwzględnia, 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 element, co zajmuje miejsce, o którym żadne polecenie Ollama nie poinformuje użytkownika. Jeśli taka operacja została już wykonana, ollama rm dla danego 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 zwalnia 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 to zagadnienie.

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 obsługuje terminal. ollama run <model> "your prompt" wysyła pojedynczy 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 żadnych informacji podczas pracy. Otwórz drugą sesję i uruchom watch -n5 df -h /: zmniejszająca się 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, dlatego należy ją sprawdzić, zamiast zakładać domyślną. Uruchom systemctl cat ollama.service, aby sprawdzić, czy zmienna OLLAMA_MODELS jest ustawiona 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 na 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 niespójnym stanie. Usunięcie obiektu blob przy zachowaniu manifestu sprawia, że model nadal pojawia się w ollama list i kończy się błędem przy próbie użycia. Usunięcie manifestu pozostawia na dysku warstwy, do których nic się nie odwołuje. 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 niepowiązane z żadnym manifestem.