Ollama jak utrzymać model w pamięci RAM

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

Ollama utrzymuje model w pamięci przez pięć minut od ostatniego żądania, po czym 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. Z tego powodu 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 jest to awaria. 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 generuje odpowiedź, 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 domyślna wartość 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 serwera. Plik typu drop-in dla systemd pozwala na trwałe zachowanie domyślnej konfiguracji serwera po restarcie. Niniejszy przewodnik zakłada, że Ollama działa już jako usługa. Jeśli tak nie jest, należy zacząć od instalacji Ollama na VPS i wrócić do tego punktu.

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

Pusty wynik 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ł typu 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 odliczanie, które 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 przez serwer.

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

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

Każdy wpis zawiera expires_at, bezwzględny znacznik czasu, taki jak 2026-08-09T14:38:31.83753Z, oraz size_vram, czyli 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 load_duration jest duże. Należy podzielić tę wartość przez 1000000000, aby uzyskać wynik w sekundach. Drugie wywołanie następuje, gdy model znajduje się już w pamięci, co skutkuje 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 czasu; jest to główny powód zmiany keep_alive. Informacje o szybkości generowania przed i po tej pauzie znajdują się w sekcji jak samodzielnie zmierzyć liczbę tokenów na sekundę.

Utrzymywanie modelu Ollama w pamięci po zakończeniu żądania

Należy wysłać keep_alive wraz z żądaniem. Parametr ten ma zastosowanie do 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"
• liczba całkowita, interpretowana jako sekundy: 3600
• wartość ujemna, -1 lub "-1m", oznaczająca brak limitu czasu bezczynności
• 0, oznaczająca zwolnienie modelu z pamięci natychmiast po zakończeniu żądania

Wartość przesłana w żądaniu nadpisuje ustawienie domyślne serwera w obie strony. Jest to istotniejsze, niż mogłoby się wydawać: klient przesyłający własny parametr keep_alive ma pierwszeństwo przed konfiguracją serwera.

Istnieje również możliwość załadowania modelu bez generowania jakiejkolwiek treści. Wystarczy przesłać samą nazwę modelu. Serwer załaduje go i zwróci pustą odpowiedź z kodem "done": true.

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

Jest to polecenie, które należy wykonać po restarcie systemu lub po pobraniu nowego modelu, aby pierwsze rzeczywiste żądanie użytkownika nie było obciążone czasem ładowania. Interfejs CLI realizuje to samo zadanie za pomocą 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 polu żądania, więc 30m, 3600 oraz -1 działają poprawnie.

Problem polega na tym, w jakim środowisku zmienna musi zostać zdefiniowana. Wykonanie export OLLAMA_KEEP_ALIVE=30m w sesji SSH nie przynosi efektu, ponieważ pakiet instalacyjny uruchamia serwer jako usługę systemd, działającą na własnym koncie użytkownika i w odrębnym ś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 typu drop-in systemd

sudo systemctl edit ollama.service

Edytor otworzy się z dwoma znacznikami komentarza. Należy pisać pomiędzy nimi: systemd ignoruje wszystko, co zostanie wpisane 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 typu 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. Przyczyną jest niemal zawsze brak nagłówka [Service] lub wpisanie linii poniżej znacznika. Restart powoduje usunięcie wszystkich załadowanych modeli z pamięci, więc kolejne żądanie wywoła tzw. zimny start. Należy go rozgrzać za pomocą powyższego polecenia preload.

Koszt 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 obliczenia dotyczące pamięci dla uruchomienia go na VPS tylko z CPU warto przeanalizować przed podjęciem decyzji o utrzymywaniu go w pamięci operacyjnej. Ustawienie keep_alive na -1 oznacza decyzję, że model ma priorytet nad wszystkimi innymi procesami na serwerze. Na małym VPS jest to bezpośredni kompromis między modelem a bazą danych, aplikacją webową oraz zadaniami kompilacji.

Należy monitorować 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 może jeszcze przydzielić nowemu procesowi. Na serwerze z GPU NVIDIA, nvidia-smi pokazuje analogiczną sytuację w VRAM. Jeśli na serwerze zabraknie pamięci, jądro systemu zakończy proces, aby odzyskać zasoby:

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

Wiersz wskazujący ollama oznacza, że serwer modelu padł ofiarą mechanizmu OOM. Wiersz wskazujący bazę danych oznacza, że model wygrał rywalizację, a istotny proces został zamknięty. 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, czyli stan uwagi dla każdego tokena utrzymywany przez model podczas generowania), a pamięć ta jest częścią rozmiaru procesu w pamięci. OLLAMA_NUM_PARALLEL powyżej 1 rezerwuje tę pamięć podręczną raz dla każdego slotu równoległego. Jeśli planujesz obsługiwać wielu użytkowników za pomocą jednego modelu, zaplanuj pamięć dla 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, aby pamięć była zwalniana po zakończeniu pracy.

Natychmiastowe usuwanie modelu z pamięci

ollama stop qwen3:8b

Polecenie nie zwraca żadnych 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. Wersja 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 stosować tę metodę zamiast restartowania usługi. systemctl restart ollama również zwalnia pamięć, ale powoduje usunięcie wszystkich pozostałych załadowanych modeli i przerywa wszystkie aktualnie przetwarzane żądania.

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 konfiguracji działającej wyłącznie na CPU. Limit odnosi się do 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. Preferowane są modele bez aktywnych żądań. 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 sposób uniemożliwiający jego usunięcie przez żądanie 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 procesu (runner) w celu uzyskania miejsca, znajdujący się obok żądania, które wywołało tę akcję, oznacza, że oba modele nie mieszczą się jednocześnie na tej maszynie. Rozwiązaniem jest zmniejszenie liczby modeli na tym serwerze lub ustawienie długiego okna czasowego dla modelu, który musi odpowiadać szybko, oraz 0 dla modelu wywoływanego rzadko.

Wskazówki zachowujące aktualność po kolejnych wydaniach

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

ollama --version
ollama serve --help

ollama serve --help zawiera listę zmiennych środowiskowych, które są faktycznie odczytywane przez daną kompilację, w tym OLLAMA_KEEP_ALIVE. Dwie zasady pozostają niezmienne w kolejnych wydaniach i można na nich polegać. Wartość przekazana w żądaniu ma pierwszeństwo przed wartością domyślną 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 serwer jest obsługiwany przez edytor lub agenta, przed przypisaniem winy serwerowi należy sprawdzić, co wysyła klient. Kierowanie agenta programistycznego na własny serwer Ollama opisuje lokalizację tych ustawień żądań.

FAQ

Dlaczego Ollama usuwa mój model z pamięci 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. Wtedy ollama ps wyświetli Forever w kolumnie UNTIL. Powoduje to jedynie usunięcie licznika bezczynności. Jeśli zażądano innego modelu, a pamięci jest mało, harmonogram nadal usunie ten model, aby zwolnić miejsce.

Dlaczego OLLAMA_KEEP_ALIVE jest ignorowane?

Należy sprawdzić miejsce ustawienia zmiennej. Wykonaj 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 i sudo systemctl restart ollama. Inną przyczyną jest klient, który wysyła własne keep_alive w żądaniu, co nadpisuje ustawienie domyślne serwera.

Jak zwolnić pamięć bez restartowania Ollama?

ollama stop qwen3:8b natychmiast usuwa 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, na liście nie powinno już być tego modelu.