Ollama czy llama.cpp na VPS: co wybrać?

Ollama a llama.cpp: na której warstwie chcesz pracować?

Ollama i llama.cpp nie są konkurentami w sposób sugerowany przez to pytanie. llama.cpp to silnik wnioskowania: ładuje on plik modelu i przekształca prompt w tokeny. Ollama to menedżer modeli, demon działający w tle oraz API HTTP, które korzysta z tego silnika. Plik README projektu Ollama nadal wskazuje llama.cpp jako backend wnioskowania (stan na 2 sierpnia 2026). Zatem właściwe pytanie brzmi: na której warstwie chcesz operować na swoim VPS, a nie która z nich jest szybsza.

Uruchom Ollama, jeśli potrzebujesz usługi, która pobiera modele po nazwie i działa bezobsługowo. Uruchom llama.cpp bezpośrednio, gdy dysponujesz ograniczonymi zasobami i musisz precyzyjnie wybrać plik modelu, rozmiar kontekstu oraz liczbę wątków, ponieważ na małym VPS każde z tych ustawień zużywa pamięć, której nie masz w nadmiarze.

Czym w rzeczywistości jest każdy z projektów

llama.cpp to implementacja wnioskowania transformerów w języku C i C++, zbudowana na bazie biblioteki ggml. Odczytuje ona pliki GGUF. GGUF (GGML universal file format) to kontener w jednym pliku, przechowujący wagi, tokenizator oraz metadane niezbędne silnikowi do uruchomienia modelu. Projekt udostępnia oddzielne pliki binarne dla różnych zadań. llama-server to serwer HTTP, llama-cli to interaktywny wiersz poleceń, a llama-bench mierzy przepustowość. Wydania są oznaczane numerem kompilacji, a nie wersjonowaniem semantycznym. Obecny tag to b10224, opublikowany 2 sierpnia 2026, a nowy tag pojawia się w większość dni roboczych.

Ollama to program napisany w języku Go. Działający w tle demon, uruchamiany za pomocą ollama serve, ładuje modele i odpowiada na żądania HTTP, a klient wiersza poleceń komunikuje się z tym demonem. Za obydwoma elementami stoi rejestr pod adresem ollama.com, przechowujący gotowe pakiety modeli. Ollama stosuje wersjonowanie semantyczne, a wersja v0.32.5 została wydana 27 lipca 2026. ollama pull pobiera plik GGUF wraz z szablonem promptu i zestawem domyślnych parametrów, a następnie przechowuje go w /usr/share/ollama/.ollama/models w systemie Linux. Pliki te znajdują się na partycji root i każdy z nich zajmuje kilka gigabajtów, więc na serwerze VPS z partycją root o rozmiarze 25 GB warto wiedzieć, co pozostawia po sobie polecenie pull i jak przenieść katalog modeli w inne miejsce, zanim trzecie pobieranie zapełni przestrzeń dyskową.

To pakowanie stanowi całą różnicę. Ollama decyduje za użytkownika o kwantyzacji, szablonie i długości kontekstu, oferując jedną nazwę do zapamiętania. llama.cpp nie narzuca niczego i udostępnia odpowiednie flagi.

Oś 1: kontrola modelu i kwantyzacji

Kwantyzacja zmniejsza rozmiar każdej wagi z 16 lub 32 bitów do 4, 5 lub 8 bitów. Dzięki temu model o 8 miliardach parametrów mieści się w pamięci RAM typowego serwera VPS. Nazewnictwo GGUF staje się zrozumiałe po poznaniu schematu: Q4_K_M oznacza 4-bitową kwantyzację typu K o średnim rozmiarze. Wyższa liczba oznacza większą precyzję, ale wymaga więcej pamięci.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

Są to opublikowane rozmiary plików w repozytorium bartowski/Meta-Llama-3.1-8B-Instruct-GGUF w serwisie Hugging Face, odczytane 2 sierpnia 2026 r. i przeliczone z bajtów na GiB. 6 kompilacji jednego modelu, z czego najmniejsza ma 2.96 GiB, a największa 7.95 GiB. Standardowy wybór, Q4_K_M, zajmuje 4.58 GiB. Na serwerze VPS z 4 GiB pamięci RAM ten jeden wybór decyduje o tym, czy model w ogóle się załaduje. Rozmiar to tylko połowa decyzji, ponieważ wiersz, na który można sobie pozwolić, nie zawsze jest wierszem wartym użycia, a to, co faktycznie kosztują Q4, Q8 i fp16 w kontekście jakości odpowiedzi pozwala ocenić, czy dodatkowe gigabajty przynoszą zauważalną korzyść.

W przypadku llama.cpp nazwa pliku jest definiowana ręcznie, więc wybór wiersza należy do użytkownika.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c to rozmiar kontekstu w tokenach, -t to liczba wątków, a -ngl określa, ile warstw jest przenoszonych do GPU (wartość 0 dla serwera bez GPU). Żadne ustawienie nie jest dobierane automatycznie.

W Ollama kwantyzacja jest powiązana z pobieranym tagiem, a ollama ls pokazuje, co faktycznie znajduje się na dysku. Jeśli rejestr nie zawiera potrzebnej kompilacji, należy zaimportować plik GGUF samodzielnie. W tym celu należy utworzyć plik Modelfile:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

Następnie należy zbudować model i sprawdzić wynik:

ollama create llama31-q4 -f ./Modelfile
ollama ls

Długość kontekstu to ustawienie, które często sprawia problemy. Ollama wybiera wartość domyślną na podstawie dostępnej pamięci VRAM, a serwer bez GPU przypisuje najmniejszy dostępny zakres: 4096 tokenów. W przypadku przesłania dokumentu o długości 20 000 tokenów, nadmiarowe tokeny są odrzucane, zanim model je przetworzy, co prowadzi do błędnych odpowiedzi wynikających z niepełnego odczytu pliku. Wartość tę można zwiększyć za pomocą OLLAMA_CONTEXT_LENGTH w demonie lub PARAMETER num_ctx w pliku Modelfile. Jeśli tylko jedno zadanie wymaga większego okna, num_ctx można ustawić dla pojedynczego żądania zamiast globalnie dla serwera, co pozwala uniknąć niepotrzebnego obciążenia pamięci podręcznej przy innych zadaniach. Narzędzie llama.cpp również nie posiada wartości domyślnej, na której można polegać. Należy jawnie ustawić -c i mieć pełną kontrolę nad konfiguracją.

Arytmetyka pamięci, której nikt nie pokazuje

Plik modelu to nie jedyny koszt. Pamięć podręczna KV (key/value cache) przechowuje jeden wpis na warstwę dla każdego tokena kontekstu i rośnie wraz z długością konwersacji.

Obliczmy to dla Llama 3.1 8B. Model posiada 32 warstwy, 8 głowic klucza/wartości oraz wymiar głowicy równy 128. Każdy token przechowuje klucz i wartość, zajmując po 2 bajty w formacie f16, co daje 2 x 8 x 128 x 2 = 4096 bajtów na warstwę. Dla 32 warstw jest to 128 KiB na token. Kontekst o długości 4096 tokenów kosztuje zatem 512 MiB, a kontekst 32 768 tokenów zajmuje 4 GiB.

Zatem model Q4_K_M 8B przy kontekście 4k wymaga około 4.58 GiB na wagi, plus około 0,5 GiB pamięci podręcznej oraz zasoby dla samego środowiska uruchomieniowego. Nie zmieści się on w 4 GiB RAM. Zmieści się w 8 GiB z zapasem na operacje. Zwiększenie kontekstu do 32k na tym samym serwerze 8 GiB sprawi, że sama pamięć podręczna wyczerpie dostępny zapas. Monitoruj użycie na żywo za pomocą free -h podczas ładowania modelu i nie ufaj szacunkom, których nie zweryfikowałeś pomiarem. Jeśli planujesz zasoby dla modelu znacznie większego niż 8B, ta sama arytmetyka zastosowana dla modelu 27B na VPS z samym CPU pokazuje, co faktycznie mieści się w każdym przedziale od 8 do 64 GB.

Ollama zwielokrotnia ten efekt. OLLAMA_NUM_PARALLEL domyślnie wynosi 1, a pamięć wymagana przez model skaluje się wraz z tą liczbą pomnożoną przez długość kontekstu. Zwiększenie obu tych wartości jednocześnie spowoduje, że daemon po cichu zażąda kilkukrotnie więcej pamięci RAM, niż przewidywano. Ta sama arytmetyka wyznacza limit jednoczesnych użytkowników, ponieważ każde równoległe żądanie wymaga własnego fragmentu pamięci podręcznej KV, co jest powodem, dlaczego serwer działający poprawnie dla jednej osoby zawiesza się przy pięciu.

Oś 2: demon, którym należy zarządzać

Skrypt instalacyjny Ollama tworzy jednostkę systemd, użytkownika systemowego ollama oraz aktywuje usługę. Zarządzanie cyklem życia odbywa się automatycznie. Konfigurację przeprowadza się za pośrednictwem systemd:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE ma większe znaczenie na VPS z procesorem CPU niż w jakimkolwiek innym przypadku. Modele są domyślnie utrzymywane w pamięci przez 5 minut, a następnie zwalniane. Kolejne żądanie wymaga ponownego odczytania całego pliku z dysku przed udzieleniem odpowiedzi, więc przeładowanie pliku o rozmiarze 4.58 GiB zmienia dwusekundowy czas odpowiedzi na trzydziestosekundowy w przypadku wolnych nośników. Długi czas keep-alive eliminuje opóźnienia, ale trwale zajmuje pamięć RAM. Oba rozwiązania wiążą się z kosztami. Należy wybrać to, które jest mniej uciążliwe. Jeśli model ma pozostać w pamięci, ustawienie keep_alive w celu przetrwania okresów bezczynności i restartów wymaga dodania kilku linii i pozwala uniknąć ręcznego ładowania modelu po każdym restarcie serwera.

llama.cpp nie dostarcza demona, dlatego jednostkę należy utworzyć samodzielnie jako /etc/systemd/system/llama-server.service:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

Aktywuj ją za pomocą sudo systemctl enable --now llama-server. Proces utrzymuje model przez cały czas swojego działania. Nic nie jest zwalniane podczas bezczynności, co oznacza brak opóźnień przy ponownym ładowaniu oraz brak możliwości odzyskania pamięci bez zatrzymania usługi. Jeśli tworzenie jednostek jest nowym zagadnieniem, obowiązuje ten sam schemat, co w przypadku uruchamiania własnych usług w systemd na VPS.

Oś 3: API, z którym komunikuje się aplikacja

Ta oś uległa znacznemu zawężeniu. Oba projekty obsługują teraz format czatu OpenAI, więc większość bibliotek klienckich współpracuje z każdym z nich po zmianie jedynie adresu bazowego URL.

Ollama nasłuchuje na 127.0.0.1:11434. Jej ścieżka zgodna z OpenAI to http://localhost:11434/v1/chat/completions, a obok niej utrzymywane jest natywne API pod /api/chat. Udokumentowano również ścieżkę zgodną z Anthropic.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server nasłuchuje na 127.0.0.1:8080 i obsługuje /v1/chat/completions, /v1/completions oraz /v1/embeddings, a także własny punkt końcowy /completion i wbudowany interfejs webowy. Udostępnia również ścieżki operacyjne, których Ollama nie posiada: /health dla sondy gotowości (readiness probe), /props dla ustawień załadowanego modelu, /slots dla podglądu aktywności poszczególnych slotów żądań oraz /metrics w formacie Prometheus. Jeśli planowane jest monitorowanie tej usługi, prawdopodobnie to właśnie ta różnica będzie decydująca.

Żaden z serwerów nie włącza automatycznie uwierzytelniania. Oba domyślnie ograniczają się do interfejsu loopback, co jest uzasadnione. Należy uzyskiwać do nich dostęp przez tunel SSH lub zza reverse proxy; nigdy nie należy wystawiać portów 11434 ani 8080 bezpośrednio do Internetu.

Co faktycznie potrafi VPS bez GPU

VPS wyposażony wyłącznie w CPU uruchamia małe modele powoli. To uczciwe podsumowanie, a kluczowe jest zrozumienie, gdzie leży granica wydajności. Należy wykonać pomiary przed zaprojektowaniem jakiegokolwiek rozwiązania:

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

Kolumna pp oznacza szybkość przetwarzania promptu, a kolumna tg szybkość generowania tokenów, obie w jednostce tokenów na sekundę. W planie z współdzielonym vCPU model 8B w kwantyzacji Q4_K_M zazwyczaj osiąga niskie wartości jednocyfrowe dla tg. Przetwarzanie promptu jest najbardziej kosztownym etapem: cały prompt musi zostać przetworzony przed wygenerowaniem pierwszego tokena wyjściowego, więc długi prompt systemowy dodaje czas oczekiwania do każdego zapytania. Długość odpowiedzi jest elementem, który można kontrolować; przy prędkości trzech tokenów na sekundę model generujący 600 tokenów blokuje zasoby na trzy minuty, dlatego ograniczenie wyjścia za pomocą num_predict jest najskuteczniejszym sposobem na uniknięcie przekroczenia limitu czasu przez zbyt długie odpowiedzi.

Zastosowania możliwe na CPU: modele od 1B do 4B wykonujące klasyfikację, ekstrakcję danych, krótkie podsumowania lub routing. Odpowiedzi generowane są w kilka sekund, a zapotrzebowanie na pamięć mieści się w standardowym planie. Jako przykład praktyczny dla tego rozmiaru, pobranie i pomiar Nemotron 3.5 Lightning na VPS wskazuje dokładny tag, rzeczywiste zapotrzebowanie na RAM oraz prędkość osiąganą bez GPU. Zastosowania niezalecane na CPU: interaktywny czat w czasie rzeczywistym, asystenci programowania, praca z długimi dokumentami lub jakiekolwiek zadania wymagające pętli agenta wykonującej wiele wywołań sekwencyjnie. Pętla wykonująca dwanaście zapytań po cztery sekundy każde wymaga minuty, zanim wygeneruje jakikolwiek wynik. Jeśli planowano użycie asystenta programowania, skierowanie agenta na samodzielnie hostowany model wyjaśnia, w których zadaniach mały lokalny model sprawdza się dobrze, a które wymagają użycia zewnętrznego API.

Istnieją dwa wyjścia, gdy wyniki wydajnościowe są niewystarczające. Jeśli problemem jest współbieżność, czyli wielu użytkowników korzystających z jednego modelu, należy zmienić silnik, a porównanie Ollama z vLLM w obsłudze współbieżnej omawia to zagadnienie. Jeśli problemem jest surowa prędkość, rozwiązaniem jest VPS z dołączonym GPU, gdzie parametr -ngl zaczyna mieć znaczenie. Przed podjęciem jakichkolwiek działań należy ustalić bazową wydajność sprzętu, ponieważ przepustowość dysku i pamięci wpływa na czas ładowania w równym stopniu co CPU. Powtarzalny benchmark VPS jest wart poświęcenia godziny pracy.

Instalacja llama.cpp z przypięciem wersji

Oba projekty rozwijają się w cyklu tygodniowym, dlatego należy odnotować wdrożoną wersję. Standardowe polecenie instaluje bieżące wydanie:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

Aby przypiąć konkretną wersję, należy pobrać gotowe archiwum tarball ze strony wydań. Wersja b10224 jest aktualnym tagiem na dzień 2 sierpnia 2026:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

Alternatywnie można zbudować ten sam tag ze źródeł:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

libssl-dev jest udokumentowaną zależnością wymaganą dla funkcji HTTPS. Kompilacja trwa kilka minut i wymaga więcej pamięci RAM, niż oferują najmniejsze plany serwerowe. W przypadku braku pamięci na małej maszynie należy przeprowadzić budowanie na większym serwerze, a następnie skopiować pliki binarne.

Instalacja Ollama z przypiętą wersją

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

Skrypt odczytuje OLLAMA_VERSION, co pozwala na zachowanie sprawdzonej wersji zamiast pobierania najnowszego wydania. Wersja v0.32.5 została opublikowana 27 lipca 2026. Dostępna jest również metoda ręczna, jeśli użytkownik nie chce przesyłać skryptu bezpośrednio do powłoki:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

Metoda ręczna nie tworzy jednostki systemd ani użytkownika usługi, więc należy skonfigurować je samodzielnie. Pełny przewodnik po instalacji Ollama na VPS opisuje ten proces konfiguracji usługi krok po kroku.

Tryby awarii i komunikaty, które zobaczysz

Ollama odmawia załadowania modelu. ollama run zwraca linię o następującym formacie:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama sprawdza rozmiar przed załadowaniem, więc błąd występuje natychmiast wraz z podaniem przyczyny. Należy przejść o jeden poziom kwantyzacji niżej, zmniejszyć długość kontekstu lub wybrać mniejszy model.

llama.cpp nie zgłasza błędu, ale działa bardzo wolno. llama.cpp domyślnie mapuje plik GGUF w pamięci, więc plik większy niż dostępna pamięć RAM nadal się uruchamia. Jądro systemu przenosi wagi między pamięcią a dyskiem przy każdym tokenie, co powoduje spadek wydajności do kilku sekund na token przy stuprocentowym obciążeniu dysku. Należy użyć flagi --no-mmap, aby wymusić rzeczywistą alokację, co spowoduje natychmiastowy błąd zamiast degradacji wydajności. Gdy jądro systemu przejmuje kontrolę, dmesg wskazuje przyczynę:

Out of memory: Killed process 1234 (llama-server)

Plik modelu w ogóle się nie ładuje. Plik GGUF przygotowany dla rodziny modeli nowszej niż używany silnik powoduje błąd wskazujący na nieznaną architekturę:

error loading model architecture: unknown model architecture: 'qwen3next'

Rozwiązaniem jest aktualizacja silnika, a nie zmiana pliku. Jest to koszt przypisania wersji i powód, dla którego należy zapisywać numer kompilacji. Niezbędna jest wiedza o wersji, z której przeprowadza się aktualizację.

API odpowiada lokalnie, ale nie z poziomu aplikacji. Ollama wiąże się z 127.0.0.1:11434, dlatego inne hosty otrzymują odmowę połączenia. Zmienną OLLAMA_HOST=0.0.0.0:11434 należy ustawić na systemctl edit ollama tylko wtedy, gdy port znajduje się za firewallem lub w sieci prywatnej, ponieważ API nie posiada wbudowanego mechanizmu uwierzytelniania.

Pierwsza odpowiedź po przerwie jest bardzo wolna. Nastąpiło zwolnienie modelu z pamięci po 5 minutach bezczynności i model jest ponownie odczytywany z dysku. Polecenie ollama ps uruchomione tuż przed żądaniem nie wykazuje załadowanych modeli, co potwierdza ten stan. Należy zwiększyć wartość OLLAMA_KEEP_ALIVE.

Które rozwiązanie wybrać?

Uruchom Ollama, jeśli oczekujesz automatycznego zarządzania modelami oraz punktu końcowego zgodnego z API OpenAI bez dodatkowej konfiguracji. Jest to domyślny wybór przy pierwszym wdrożeniu oraz w sytuacjach, gdy wybór modelu będzie często zmieniany.

Uruchom llama.cpp bezpośrednio, gdy zasoby pamięci są ograniczone i wymagają ręcznego doboru kwantyzacji, gdy potrzebujesz /health, /slots oraz /metrics do monitorowania lub gdy wymagana jest flaga, której Ollama nie udostępnia. Jest to właściwe rozwiązanie na serwerze VPS, gdzie model mieści się w pamięci z trudem, ponieważ parametry optymalizacyjne wymagają wtedy precyzyjnego dostrojenia, które w przypadku Ollama odbywa się automatycznie.

Uruchamianie obu rozwiązań jednocześnie jest standardową praktyką. Ollama służy do eksperymentów, natomiast llama.cpp do modelu produkcyjnego, którego konfiguracja ma pozostać niezmienna.

FAQ

Czy Ollama to tylko nakładka na llama.cpp?

Blisko, jednak nakładka wykonuje realną pracę. Plik README projektu Ollama wskazuje llama.cpp jako backend wnioskowania (stan na 2 sierpnia 2026). Ponad nim Ollama dodaje rejestr modeli, szablony promptów przekształcające wiadomości czatu w zapytania, zestaw domyślnych parametrów próbkowania, demona z funkcją zwalniania pamięci w stanie bezczynności oraz API HTTP. Porównując liczbę tokenów na sekundę przy identycznych ustawieniach, porównuje się ten sam silnik. Wybór dotyczy w rzeczywistości warstwy zarządzającej.

Co jest szybsze na serwerze VPS bez GPU?

Oba rozwiązania współdzielą ten sam silnik, więc przy tym samym pliku modelu, kwantyzacji, rozmiarze kontekstu i liczbie wątków wyniki są zbliżone. Różnice zgłaszane przez użytkowników wynikają zazwyczaj z odmiennych ustawień domyślnych, najczęściej długości kontekstu i liczby wątków, a nie z samego silnika. Należy dokonać pomiaru za pomocą llama-bench -m <file> -p 512 -n 128 i porównać kolumnę tg na własnym serwerze, zamiast polegać na publikowanych danych.

Czy mogę użyć własnego pliku GGUF z Ollama?

Tak. Należy umieścić plik na serwerze, utworzyć Modelfile, którego pierwszą linią jest FROM ./your-model.gguf, dodać wymagane linie PARAMETER, takie jak num_ctx, a następnie uruchomić ollama create your-name -f ./Modelfile. ollama ls wyświetli go obok modeli pobranych z rejestru. Jest to sposób na użycie kwantyzacji, której nie ma w oficjalnym rejestrze.

Ile pamięci RAM potrzeba dla modelu 8B?

Należy uwzględnić rozmiar pliku, pamięć podręczną KV oraz narzut środowiska uruchomieniowego. Kompilacja Q4_K_M modelu Llama 3.1 8B zajmuje około 4.58 GiB na dysku, a kontekst 4096 tokenów dodaje około 512 MiB pamięci podręcznej, więc 8 GiB RAM zapewnia komfort pracy, podczas gdy 4 GiB to za mało. Pamięć podręczna skaluje się wraz z kontekstem: ten sam model przy kontekście 32 768 tokenów wymaga około 4 GiB samej pamięci podręcznej. W przypadku Ollama należy pamiętać, że wymagania rosną również wraz z OLLAMA_NUM_PARALLEL.