Dlaczego lokalny model AI działa wolno? Problem z keep_alive w Ollama

Wdrażanie lokalnych modeli sztucznej inteligencji staje się coraz popularniejszym krokiem wśród małych i średnich przedsiębiorstw. Możliwość uruchomienia darmowego asystenta AI na własnym sprzęcie, bez konieczności opłacania abonamentów i przesyłania poufnych danych firmy do zewnętrznych chmur, brzmi niezwykle kusząco. Lokalny chatbot może wspierać obsługę klienta, automatyzować analizę dokumentacji czy pomagać w codziennej pracy biurowej.

Wielu przedsiębiorców i programistów napotyka jednak frustrujący problem podczas wdrożenia: system działa błyskawicznie podczas testów deweloperskich, ale drastycznie zwalnia, gdy zaczyna być używany w realnych warunkach biznesowych. Po kilkunastu minutach bezczynności, pierwsze zapytanie zadane asystentowi potrafi zawiesić się na kilkanaście sekund, zmuszając użytkownika do patrzenia na migający kursor.

Jak się okazuje, winowajcą rzadko jest zbyt słaby komputer czy mało wydajny model językowy. Przyczyna najczęściej tkwi w ukrytym, domyślnym ustawieniu popularnego narzędzia Ollama, które zarządza ładowaniem modeli. Analiza rzeczywistego przypadku pokazuje, że nieoptymalna konfiguracja jednego parametru doprowadziła do przeładowania modelu z dysku aż 214 razy w ciągu jednej doby. Poniżej szczegółowo opisujemy tę sytuację oraz przedstawiamy sprawdzone sposoby na eliminację opóźnień.

Anatomia opóźnień: Dlaczego lokalne AI nagle zwalnia?

Podczas pracy nad lokalnymi wdrożeniami łatwo wpaść w pułapkę pozornej wydajności. W opisywanym przez jednego z programistów przypadku, lokalna aplikacja działała bez zarzutu podczas testów – czas do wygenerowania pierwszego tokenu (TTFT - Time-to-First-Token) wynosił poniżej sekundy. Jednak powrót do pracy po przerwie obiadowej i zadanie jednego pytania skutkowało aż 11-sekundowym oczekiwaniem na odpowiedź.

Problem ten nie wynikał z powolnego działania samego modelu, lecz z faktu, że Ollama po prostu usuwała go z pamięci i zapisywała z powrotem na dysku. Domyślne ustawienie parametru keep_alive w środowisku Ollama wynosi bowiem zaledwie 5 minut. Jeśli przez ten czas system nie otrzyma żadnego zapytania, proces wykonawczy (runner) wyłącza się, a wagi modelu opuszczają pamięć VRAM karty graficznej. Każde kolejne zapytanie zmusza system do ponownego odczytania gigabajtów danych z dysku twardego i zaalokowania pamięci, co generuje ogromne opóźnienie.

Analiza testu: 214 przeładowań w ciągu jednej doby

Aby dokładnie zbadać skalę tego zjawiska, autor eksperymentu przeprowadził 24-godzinny test wydajnościowy na maszynie wyposażonej w 16 GB pamięci VRAM oraz szybki dysk NVMe. W środowisku uruchomiono trzy modele:

• llama3.1:8b – model do obsługi czatu (rozmiar około 4,9 GB),
• qwen2.5-coder:14b – model pomocniczy do kodowania (rozmiar około 9 GB),
• nomic-embed-text – model do generowania osadzeń tekstowych (rozmiar około 274 MB).

Infrastruktura obsługiwała trzech klientów: interfejs czatu używany ręcznie przez użytkownika, mały indeksator RAG oraz zadanie cron, które co 10 minut uruchamiało podsumowywanie notatek.

Wyniki dobowego monitoringu okazały się zaskakujące. Na 1180 wysłanych zapytań system odnotował aż 214 zdarzeń pełnego ładowania modelu z dysku. Oznacza to, że średnio co 5,5 zapytania model musiał być ładowany na nowo. Ponieważ zadanie cron uruchamiało się co 10 minut (czyli po upływie domyślnego 5-minutowego czasu bezczynności), trafiało ono na "zimny" model w 100% przypadków. W efekcie średni czas odpowiedzi (p50) dla wszystkich zapytań wzrósł do 3,1 sekundy, a niemal co piąte zapytanie (18,1%) obarczone było pełnym, trwającym 11,4 sekundy procesem ładowania z dysku NVMe.

Jak sprawdzić, czy Twój model Ollama ciągle się przeładowuje?

Jeśli podejrzewasz, że Twój lokalny asystent AI cierpi na tę samą przypadłość, możesz to zweryfikować w prosty sposób za pomocą dwóch kroków.

Krok 1: Kontrola aktywnych modeli w pamięci

Wpisz w terminalu polecenie:

ollama ps

Jeśli po okresie bezczynności wynik tego polecenia jest pusty, oznacza to, że Twój model został usunięty z pamięci i znajduje się wyłącznie na dysku. Kolumna "UNTIL" w wyjściu tego polecenia pokazuje rzeczywisty czas, jaki pozostał do usunięcia modelu z pamięci.

Krok 2: Analiza logów systemowych

Aby sprawdzić, ile razy model był ładowany w ciągu ostatniej doby, możesz przeszukać logi serwera Ollama. W systemie Linux (systemd) służy do tego komenda:

journalctl -u ollama --since "24 hours ago" | grep -ci "llama runner started"

Z kolei na systemach macOS liczbę przeładowań sprawdzisz poleceniem:

grep -ci "llama runner started" ~/.ollama/logs/server.log

Warto pamiętać, że dokładna treść logów może się nieznacznie różnić w zależności od wersji Ollama, dlatego dobrze jest najpierw ręcznie przejrzeć logi i dopasować frazę kluczową.

Pułapki konfiguracji: Gdzie tkwi błąd w ustawieniach keep_alive?

Próby samodzielnego rozwiązania problemu z parametrem keep_alive często prowadzą do kolejnych błędów. W analizowanym przypadku autor zderzył się z dwoma poważnymi problemami konfiguracyjnymi.

Po pierwsze, przekazywanie parametru keep_alive bezpośrednio w treści zapytania (request body) okazało się całkowicie bezskuteczne w przypadku korzystania z punktu końcowego zgodnego z OpenAI (ścieżka /v1/chat/completions). Biblioteki i SDK kompatybilne z OpenAI ignorowały to ustawienie. Parametr ten był respektowany wyłącznie przy bezpośrednich zapytaniach do natywnego API Ollama (ścieżka /api/chat).

Po drugie, intuicyjne ustawienie wartości keep_alive: -1 (co teoretycznie nakazuje systemowi bezterminowe utrzymywanie modeli w pamięci) przyniosło odwrotny skutek, gdy w systemie działały dwa duże modele. Ponieważ łączny rozmiar modeli llama3.1:8b oraz qwen2.5-coder:14b przekraczał dostępną pamięć VRAM (16 GB), Ollama została zmuszona do przeniesienia części obliczeń na procesor (CPU offload). W rezultacie prędkość generowania tekstu drastycznie spadła – z wydajnych 42 tokenów na sekundę do zaledwie 6 tokenów na sekundę.

Jak skutecznie rozwiązać problem wolnego ładowania modeli?

Rozwiązanie problemu powolnego działania lokalnego AI wymagało zmiany podejścia do konfiguracji serwera. Zamiast sterować parametrami z poziomu poszczególnych zapytań, wprowadzono następujące zmiany:

1. Zmienna środowiskowa serwera: Ustawiono globalną zmienną środowiskową OLLAMA_KEEP_ALIVE=24h na poziomie konfiguracji systemowej serwera. Dzięki temu raz załadowany model pozostaje w pamięci przez całą dobę.
2. Zasada jednego modelu na GPU: Zrezygnowano z prób jednoczesnego utrzymywania w pamięci VRAM dwóch dużych modeli, zapobiegając spowolnieniu generowania tekstu.
3. Oddelegowanie osadzeń (embeddings): Model nomic-embed-text, odpowiedzialny za generowanie osadzeń na potrzeby wyszukiwania informacji (RAG), został przeniesiony na osobną instancję Ollama, uruchomioną wyłącznie na procesorze (CPU).

Dzięki tym modyfikacjom liczba dobowych przeładowań modeli spadła z dramatycznych 214 do zaledwie 9, co całkowicie wyeliminowało problem kilkunastosekundowych opóźnień podczas codziennej pracy.

Co to oznacza dla małej firmy?

Dla małych przedsiębiorstw, zwłaszcza tych działających lokalnie w województwie śląskim – w miastach takich jak Czechowice-Dziedzice, Bielsko-Biała czy Katowice – sprawność działania systemów IT ma kluczowe znaczenie. Jeśli decydujesz się na wdrożenie lokalnego asystenta AI do obsługi klientów na swojej stronie internetowej lub do szybkiego przeszukiwania dokumentów firmowych, nie możesz pozwolić sobie na to, aby system odpowiadał z opóźnieniem rzędu 11 sekund. Klient oczekujący na interaktywnym czacie natychmiast opuści witrynę, uznając, że narzędzie po prostu nie działa.

Prawidłowa konfiguracja infrastruktury AI wymaga specjalistycznej wiedzy. Samo pobranie darmowego modelu to dopiero początek drogi. Aby automatyzacje i narzędzia AI przynosiły realne korzyści biznesowe, muszą być zoptymalizowane pod kątem posiadanego sprzętu. W prowebcrafting.com pomagamy lokalnym firmom z Śląska wdrażać nowoczesne, szybkie i bezpieczne rozwiązania oparte o sztuczną inteligencję, dbając o każdy techniczny detal konfiguracji.

Podsumowanie

Domyślne ustawienia narzędzi takich jak Ollama są projektowane z myślą o oszczędzaniu energii na laptopach programistów, a nie o ciągłej pracy w środowisku biznesowym. Jeśli Twoje lokalne AI działa wolno, nie spiesz się z zakupem droższej karty graficznej. Sprawdź logi systemowe, zweryfikuj liczbę przeładowań modeli i dostosuj parametr keep_alive na poziomie serwera. Odpowiednia optymalizacja potrafi skrócić czas reakcji asystenta z kilkunastu sekund do ułamka sekundy, zapewniając płynną i profesjonalną obsługę każdego zapytania.

Zdjęcie: panumas nikhomkhai / Pexels