Ollama jak utrzymać model w pamięci RAM na stałe

Dlaczego Ollama zwalnia model z pamięci po kilku minutach?

Ollama utrzymuje model w pamięci przez pięć minut od ostatniego żądania, a następnie zwalnia zasoby. Kolejne żądanie wymaga ponownego odczytania wag z dysku i zmapowania ich do pamięci RAM lub VRAM, co powoduje opóźnienie przed wygenerowaniem pierwszego tokena. Dlatego interfejs czatu lub agent programistyczny działa płynnie, po pewnym czasie przechodzi w stan bezczynności, a przy kolejnej wiadomości reaguje wolniej. Nie oznacza to awarii. Upłynął po prostu czas bezczynności.

Licznik czasu nosi nazwę keep_alive. Działa on w odniesieniu do każdego modelu z osobna i resetuje się po zakończeniu każdego żądania. Model, który aktualnie przetwarza zapytanie, nigdy nie jest zwalniany, ponieważ serwer usuwa z pamięci tylko te modele, dla których nie ma aktywnych żądań. Według stanu na sierpień 2026 r. wartość domyślna wynosi pięć minut i dotyczy każdego modelu ładowanego przez serwer.

Istnieją dwa miejsca, w których można ustawić keep_alive: w pojedynczym żądaniu lub jako wartość domyślną dla całego serwera. Plik typu drop-in dla systemd pozwala zachować domyślne ustawienia serwera po restarcie. Niniejszy przewodnik zakłada, że Ollama działa już jako usługa. Jeśli tak nie jest, należy rozpocząć od instalacji Ollama na VPS, a następnie powrócić do tego miejsca.

Które modele są obecnie w pamięci i kiedy wygasają?

ollama ps

NAME        ID              SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3:8b    500a1f067a9f    6.6 GB    100% GPU     4096       4 minutes from now

Puste wyjście oznacza, że żaden model nie jest załadowany, więc kolejne żądanie spowoduje pełne ładowanie. PROCESSOR wskazuje lokalizację wag. 100% GPU oraz 100% CPU to przypadki jednoznaczne. Podział taki jak 25%/75% CPU/GPU oznacza, że model nie zmieścił się w VRAM, więc jego część działa na procesorze, co spowalnia generowanie.

UNTIL to licznik czasu, który wyświetla czas relatywny, na przykład 4 minutes from now. Wyświetla Forever, gdy model został załadowany z ujemną wartością keep_alive. Wyświetla Stopping... w krótkim oknie czasowym podczas zwalniania modelu z pamięci przez serwer.

Zestaw kolumn uległ zmianie między wydaniami, dlatego należy czytać nagłówki zamiast liczyć pola w skryptach. W przypadku automatyzacji należy odpytać API:

curl -s http://localhost:11434/api/ps

Każdy wpis zawiera expires_at, czyli bezwzględny znacznik czasu, taki jak 2026-08-09T14:38:31.83753Z, oraz size_vram, określający część modelu znajdującą się w pamięci GPU. Wartość size_vram równa 0 oznacza, że model działa na CPU.

Jaki jest rzeczywisty koszt przeładowania

Nie należy zgadywać. Ollama raportuje czas ładowania w każdej odpowiedzi jako load_duration, w nanosekundach.

sudo apt install -y jq
ollama stop qwen3:8b
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'
curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "prompt": "hi", "stream": false}' | jq '{load_duration, total_duration}'

Pierwsze wywołanie ładuje model, więc jego wartość load_duration jest wysoka. Należy podzielić ją przez 1000000000, aby odczytać wynik w sekundach. Drugie wywołanie następuje, gdy model znajduje się już w pamięci, i zwraca znacznie mniejszą liczbę. Różnica między tymi dwiema wartościami to koszt, który ponosi każdy użytkownik po wygaśnięciu licznika; jest to główny powód zmiany keep_alive. Większość tej różnicy wynika z operacji odczytu z dysku, więc jeśli katalog modelu został przeniesiony na drugi wolumin, szybkość tego woluminu wyznacza dolną granicę czasu każdego zimnego ładowania. Informacje o szybkości generowania po obu stronach tej pauzy znajdują się w sekcji jak zmierzyć liczbę tokenów na sekundę na własnej maszynie.

Utrzymywanie modelu Ollama w pamięci po żądaniu

Wraz z żądaniem należy wysłać keep_alive. Parametr ten dotyczy danego modelu od momentu zakończenia przetwarzania żądania.

curl -s http://localhost:11434/api/chat -d '{
  "model": "qwen3:8b",
  "messages": [{"role": "user", "content": "hello"}],
  "keep_alive": "30m"
}'

Akceptowane są cztery formaty wartości:

• ciąg znaków określający czas trwania: "30m", "24h", "90s"
• zwykła liczba, interpretowana jako sekundy: 3600
• wartość ujemna, -1 lub "-1m", oznaczająca brak limitu czasu bezczynności
• 0, oznaczające zwolnienie pamięci natychmiast po zakończeniu żądania

Wartość podana w żądaniu nadpisuje ustawienia domyślne serwera w obie strony. Jest to istotniejsze, niż mogłoby się wydawać: klient wysyłający własne keep_alive ma pierwszeństwo przed konfiguracją serwera.

Możliwe jest również załadowanie modelu bez generowania jakiejkolwiek treści. Wystarczy wysłać samą nazwę modelu. Serwer załaduje go i zwróci pustą odpowiedź z "done": true.

curl -s http://localhost:11434/api/generate -d '{"model": "qwen3:8b", "keep_alive": "30m"}'

Jest to polecenie, które należy uruchomić po restarcie systemu lub po pobraniu nowego modelu, aby pierwsze rzeczywiste żądanie użytkownika nie było obciążone czasem ładowania. Interfejs CLI wykonuje to samo zadanie przy użyciu flagi:

ollama run --keepalive 30m qwen3:8b "hello"

Utrzymywanie modelu w pamięci za pomocą OLLAMA_KEEP_ALIVE

Serwer odczytuje OLLAMA_KEEP_ALIVE podczas uruchamiania i stosuje tę wartość dla każdego modelu, który nie posiada własnej konfiguracji. Obsługiwane są te same formaty, co w przypadku pola żądania, więc 30m, 3600 oraz -1 działają poprawnie.

Kluczową kwestią jest to, w jakim środowisku zmienna musi zostać ustawiona. Wykonanie export OLLAMA_KEEP_ALIVE=30m w sesji SSH nie przynosi efektu, ponieważ instalacja pakietowa uruchamia serwer jako usługę systemd, działającą na własnym koncie użytkownika i w odizolowanym środowisku. Powłoka logowania użytkownika i wspomniana usługa nie współdzielą środowiska. Jest to najczęstsza przyczyna, dla której ustawienie wydaje się być ignorowane.

Zapewnienie trwałości po restarcie za pomocą pliku drop-in systemd

sudo systemctl edit ollama.service

Edytor otworzy się z dwoma znacznikami komentarza. Wpisz treść pomiędzy nimi: systemd odrzuca wszystko, co zostanie umieszczone poniżej drugiego znacznika.

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

Zapisanie pliku tworzy /etc/systemd/system/ollama.service.d/override.conf. Jest to plik typu drop-in, a nie edycja dostarczonej jednostki, dzięki czemu aktualizacja pakietu Ollama, która zastępuje ollama.service, nie nadpisze wprowadzonych ustawień. Jeśli pliki drop-in oraz pliki jednostek są nowością, przewodnik po usługach i timerach systemd wyjaśnia zasady ich działania.

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

Ostatnie polecenie wyświetla środowisko, w którym usługa będzie faktycznie uruchamiana. Jeśli OLLAMA_KEEP_ALIVE=30m nie znajduje się w tej linii, oznacza to, że plik drop-in nie został uwzględniony, a przyczyną jest niemal zawsze brak nagłówka [Service] lub wpisanie linii poniżej znacznika. Sam restart usuwa wszystkie załadowane modele, więc kolejne żądanie spowoduje ładowanie "na zimno". Warto rozgrzać usługę za pomocą powyższego wywołania preload.

Koszty utrzymywania modelu w pamięci

Kolumna SIZE w ollama ps oznacza pamięć zajętą przez cały czas trwania okna bezczynności, a nie tylko podczas obsługi żądania. Model 8B przy kwantyzacji 4-bitowej zajmuje około 5 do 6 GB. Model 27B to zupełnie inna kwestia, a arytmetyka pamięci dla uruchomienia go na VPS bez GPU wymaga przeliczenia, zanim zdecydujesz się na utrzymywanie go w pamięci operacyjnej. Ustawienie keep_alive na -1 oznacza decyzję, że model ma wyższy priorytet niż cokolwiek innego na serwerze, na stałe. Na małym VPS jest to bezpośredni kompromis kosztem bazy danych, aplikacji webowej i zadań kompilacji.

Monitoruj rzeczywiste wartości zamiast polegać na szacunkach. Uruchom poniższe polecenie, gdy model jest załadowany, a następnie ponownie po ollama stop:

free -h

Kolumna available wskazuje pamięć, którą jądro systemu mogłoby jeszcze przydzielić nowemu procesowi. Na serwerze z GPU NVIDIA, nvidia-smi pokazuje analogiczną sytuację w VRAM. Jeśli serwerowi zabraknie pamięci, jądro zakończy proces, aby odzyskać zasoby:

sudo dmesg -T | grep -i "out of memory"

Wiersz wskazujący ollama oznacza, że serwer modelu był ofiarą. Wiersz wskazujący bazę danych oznacza, że model wygrał, a istotny proces został przerwany. Oba scenariusze wynikają z tej samej decyzji: zbyt długiego okna keep-alive na serwerze bez zapasu pamięci.

Dwa koszty są często pomijane. Dłuższa długość kontekstu rezerwuje większą pamięć podręczną KV (key value cache, stan uwagi dla każdego tokena utrzymywany przez model podczas generowania), a ta pamięć jest częścią rozmiaru rezydentnego. Jej wielkość wynika z num_ctx, więc zwiększenie okna kontekstu zwiększa ilość pamięci zajmowanej przez model przez cały okres bezczynności, a nie tylko podczas generowania odpowiedzi. Wartość OLLAMA_NUM_PARALLEL powyżej 1 rezerwuje tę pamięć podręczną dla każdego równoległego slotu. Jeśli planujesz obsługiwać wielu użytkowników za pomocą jednego modelu, zaplanuj pamięć dla wszystkich slotów, a nie tylko dla wag modelu.

Rozsądne ustawienie domyślne: jeden model na serwerze z zapasem pamięci może używać -1. Na współdzielonym serwerze należy użyć okna pokrywającego przerwy między żądaniami, na przykład 30m, dzięki czemu pamięć zostanie zwolniona, gdy przestaniesz pracować.

Natychmiastowe usuwanie modelu z pamięci

ollama stop qwen3:8b

Polecenie kończy działanie bez zwracania danych wyjściowych, a model znika z ollama ps. Podanie nazwy modelu, który nie jest załadowany, skutkuje błędem couldn't find model "qwen3:8b" to stop. Postać API to żądanie bez promptu z parametrem keep_alive ustawionym na 0:

curl -s http://localhost:11434/api/chat -d '{"model": "qwen3:8b", "messages": [], "keep_alive": 0}'

Odpowiedź zawiera "done_reason": "unload". Należy używać tej metody zamiast restartowania usługi. Polecenie systemctl restart ollama również zwalnia pamięć, ale usuwa wszystkie pozostałe załadowane modele i przerywa każde aktualnie przetwarzane żądanie.

Uruchamianie więcej niż jednego modelu na jednym serwerze

OLLAMA_MAX_LOADED_MODELS ogranicza liczbę modeli utrzymywanych jednocześnie w pamięci. Według stanu na sierpień 2026 r. wartość domyślna wynosi trzy na GPU lub trzy w przypadku maszyny korzystającej wyłącznie z CPU. Limit dotyczy liczby modeli, jednak rzeczywistym ograniczeniem jest pamięć, dlatego drugi duży model może zostać odrzucony na długo przed osiągnięciem limitu trzech jednostek.

Gdy żądany jest nowy model, a ilość pamięci jest niewystarczająca, harmonogram zwalnia jeden z załadowanych modeli, aby zwolnić miejsce. Preferowany jest model bez aktywnego żądania. System może usunąć model, którego licznik czasu nie wygasł, w tym model załadowany za pomocą -1. Wartość ujemna keep_alive oznacza brak limitu czasu bezczynności. Nie powoduje to przypięcia wag modelu w przypadku żądania innego modelu.

Decyzja ta jest rejestrowana na poziomie debug. Należy dodać drugą linię Environment="OLLAMA_DEBUG=1" do tego samego pliku typu drop-in, zrestartować usługę i monitorować dziennik:

sudo journalctl -u ollama -f

Wpis dotyczący zwolnienia zasobów (unloading a runner), znajdujący się obok żądania, które wywołało to działanie, informuje, że oba modele nie mieszczą się jednocześnie na danej maszynie. Rozwiązaniem jest ograniczenie liczby modeli na tym serwerze lub ustawienie długiego okna czasowego dla modelu, który musi odpowiadać szybko, oraz użycie 0 dla modelu wywoływanego rzadko.

Wskazówki wykraczające poza kolejne wydania

Ollama często publikuje nowe wersje, a jej ustawienia domyślne ulegają zmianie, dlatego należy sprawdzać aktualną kompilację zamiast zapamiętywać konkretne liczby:

ollama --version
ollama serve --help

ollama serve --help zawiera listę zmiennych środowiskowych, które dana kompilacja faktycznie odczytuje, w tym OLLAMA_KEEP_ALIVE. Dwie zasady sprawdzają się w kolejnych wydaniach i można na nich polegać. Wartość w żądaniu ma pierwszeństwo przed ustawieniem domyślnym serwera. Z kolei ollama ps stanowi wiarygodne źródło informacji o tym, co zostało załadowane, niezależnie od deklaracji w pliku konfiguracyjnym.

Jeśli serwerem zarządza edytor lub agent, przed przypisaniem winy serwerowi należy sprawdzić, co wysyła klient. Wskazywanie agenta programistycznego na własny serwer Ollama opisuje, gdzie znajdują się te ustawienia żądań.

FAQ

Dlaczego Ollama zwalnia mój model po 5 minutach?

Pięć minut to domyślna wartość keep_alive, czyli licznik bezczynności, który Ollama uruchamia po zakończeniu żądania. Po jego upływie serwer zwalnia wagi modelu, więc kolejne żądanie wymusza ich ponowne wczytanie z dysku, co powoduje odczuwalne opóźnienie. Wartość tę można zwiększyć dla pojedynczego żądania, przesyłając "keep_alive": "30m" w treści JSON, lub dla całego serwera za pomocą zmiennej środowiskowej OLLAMA_KEEP_ALIVE.

Jak utrzymać model Ollama w pamięci na stałe?

Należy użyć wartości ujemnej: "keep_alive": -1 w żądaniu lub OLLAMA_KEEP_ALIVE=-1 dla serwera. Wówczas ollama ps wyświetli Forever w kolumnie UNTIL. Powoduje to jedynie usunięcie licznika bezczynności. Jeśli zażądano innego modelu, a pamięć jest na wyczerpaniu, harmonogram nadal zwolni ten model, aby zwolnić miejsce.

Dlaczego OLLAMA_KEEP_ALIVE jest ignorowane?

Należy sprawdzić miejsce ustawienia zmiennej. Uruchom systemctl show ollama --property=Environment; jeśli zmiennej nie ma w wyniku, serwer jej nie otrzymał, ponieważ zmienna wyeksportowana w powłoce nie dociera do usługi systemd. Ustaw ją za pomocą sudo systemctl edit ollama.service, a następnie wykonaj sudo systemctl daemon-reload oraz sudo systemctl restart ollama. Inną przyczyną jest klient wysyłający własne keep_alive w żądaniu, co nadpisuje ustawienie domyślne serwera.

Jak zwolnić pamięć bez restartowania Ollama?

ollama stop qwen3:8b natychmiast zwalnia dany model, pozostawiając serwer i wszystkie inne załadowane modele w stanie uruchomionym. Przez API należy wysłać żądanie bez promptu i z "keep_alive": 0, a odpowiedź powróci z "done_reason": "unload". Potwierdź stan za pomocą ollama ps, która nie powinna już wyświetlać tego modelu.