Ollama czy llama.cpp na VPS bez GPU? Porównanie

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

Ollama i llama.cpp nie są konkurentami w sposób sugerowany przez pytanie. llama.cpp to silnik wnioskowania: ładuje plik modelu i zamienia prompt na tokeny. Ollama to menedżer modeli, demon działający w tle oraz API HTTP umieszczone nad tym silnikiem. Plik README projektu Ollama nadal wymienia llama.cpp jako swój backend wnioskowania (stan na 27 października 2026). Zatem właściwe pytanie brzmi: na której warstwie chcesz pracować na swoim VPS, a nie która z nich jest szybsza.

Uruchom Ollama, gdy potrzebujesz usługi, która pobiera modele po nazwie i działa bezobsługowo. Uruchom llama.cpp bezpośrednio, gdy serwer jest mały 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 faktycznie jest każdy z projektów

llama.cpp to implementacja inferencji modeli transformer w językach C i C++, oparta na bibliotece ggml. Odczytuje pliki GGUF. GGUF (GGML universal file format) to jednoplikowy kontener zawierający wagi, tokenizator i metadane wymagane przez silnik do uruchomienia modelu. Projekt udostępnia osobne pliki binarne do osobnych zadań. llama-server to serwer HTTP, llama-cli to interaktywny prompt, a llama-bench mierzy przepustowość. Projekt publikuje obecnie wydania zgodne z wersjonowaniem semantycznym (MAJOR.MINOR.PATCH), a v0.7.0, opublikowane 15 October 2026, było najnowszym wydaniem na 27 October 2026. Obok nich nadal pojawiają się tagi nightly z numerem kompilacji, kilka dziennie. Najnowszym tagiem na 27 October 2026 był b11913.

Ollama to program napisany w Go. Uruchamiany za pomocą ollama serve demon działający w tle ładuje modele i odpowiada na żądania HTTP, a klient wiersza poleceń komunikuje się z tym demonem. Za oboma komponentami znajduje się rejestr pod adresem ollama.com, zawierający gotowe pakiety modeli. Ollama używa wersjonowania semantycznego. Wersja v0.32.5 została wydana 27 July 2026, a v0.40.12 wydano 27 October 2026 o 00:07 UTC. ollama pull pobiera plik GGUF wraz z szablonem promptu i zestawem parametrów domyślnych, a następnie zapisuje go w systemie Linux w lokalizacji /usr/share/ollama/.ollama/models. Pliki te znajdują się na dysku root i każdy z nich może zajmować kilka gigabajtów. Dlatego na VPS z wolumenem root o pojemności 25 GB warto wiedzieć co pozostawia polecenie pull i jak przenieść katalog modeli w inne miejsce, zanim trzecie pobranie go zapełni.

Na tym polega cała różnica w sposobie pakowania. Ollama samodzielnie wybiera kwantyzację, szablon i długość kontekstu, a użytkownik zapamiętuje tylko jedną nazwę. llama.cpp udostępnia te wybory jako flagi i automatycznie dobiera wartości domyślne dla ustawień, których nie określono.

Oś 1: kontrola modelu i kwantyzacji

Kwantyzacja zapisuje wagi przy użyciu mniejszej liczby bitów niż 16 lub 32 bity modelu źródłowego, a typowe kompilacje GGUF używają średnio około 4, 5 lub 8 bitów na wagę. Precyzja nie jest jednakowa w całym pliku. W kodzie źródłowym kwantyzatora llama.cpp (odczytanym 27 October 2026) kompilacja Q4_K_M przechowuje większość tensorów w formacie 4-bitowym, ale warstwę wyjściową oraz tensory wartości attention i down feed-forward w około połowie warstw zapisuje zamiast tego jako 6-bitowe Q6_K. Małe tensory, takie jak normy, nie są kwantyzowane. Dzięki temu model z 8 billion parametrów mieści się w pamięci RAM zwykłego VPS. Nazewnictwo GGUF staje się czytelne po poznaniu wzorca: Q4_K_M oznacza 4-bitową kwantyzację K o średnim rozmiarze. Wyższa liczba oznacza większą precyzję i większe zużycie 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 na Hugging Face, odczytane 2 August 2026 i przeliczone z bajtów na GiB. Dostępnych jest 6 kompilacji jednego modelu, a najmniejsza ma 2.96 GiB, podczas gdy największa ma 7.95 GiB. Typowy wybór domyślny, Q4_K_M, ma 4.58 GiB. Na VPS z 4 GiB ta pojedyncza decyzja rozstrzyga, czy model w ogóle się załaduje. Rozmiar to tylko połowa tej decyzji, ponieważ wariant, na który można sobie pozwolić, nie jest automatycznie wariantem wartym użycia. Informacja ile w praktyce kosztują Q4, Q8 i fp16 pod względem jakości odpowiedzi pozwala ocenić, czy dodatkowe gigabajty zapewniają zauważalną korzyść.

W llama.cpp podaje się nazwę pliku, więc wariant wybiera się samodzielnie.

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 oznacza rozmiar kontekstu w tokenach, -t oznacza liczbę wątków, a -ngl określa, ile warstw zostanie przeniesionych na GPU (0 na komputerze używającym wyłącznie CPU). Nieustawione opcje mają wartości domyślne, a --fit jest domyślnie włączone i dostosowuje nieustawione argumenty do pamięci urządzenia.

W Ollama kwantyzacja jest przypisana do pobieranego tagu, a ollama ls pokazuje, co faktycznie znajduje się na dysku. Jeśli registry nie zawiera potrzebnej kompilacji, należy samodzielnie zaimportować plik GGUF. Należy utworzyć plik Modelfile:

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

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

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

Długość kontekstu to ustawienie, które często powoduje problemy. Ollama wybiera wartość domyślną na podstawie dostępnej pamięci VRAM, a komputer bez GPU trafia do najmniejszego przedziału: 4096 tokenów. Po przesłaniu dokumentu zawierającego 20,000 tokenów dodatkowe tokeny zostaną odrzucone, zanim model je zobaczy. W rezultacie odpowiedź może być przekonująca, ale błędna, ponieważ model przeczytał tylko część pliku. Wartość tę można zwiększyć za pomocą OLLAMA_CONTEXT_LENGTH na daemonie albo za pomocą PARAMETER num_ctx w pliku Modelfile. Jeśli większe okno jest potrzebne tylko jednemu zadaniu, num_ctx można ustawić dla konkretnego żądania zamiast globalnie dla serwera, dzięki czemu dodatkowa pamięć cache nie będzie rezerwowana dla pozostałych zadań obsługiwanych przez daemon. llama.cpp również nie ma wartości domyślnej, której można bez zastrzeżeń ufać. Należy jawnie ustawić -c i znać ustawioną wartość.

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 trzeba zarządzać

Skrypt instalacyjny Ollama zapisuje jednostkę systemd, tworzy użytkownika systemowego ollama i włącza usługę. Zarządzanie cyklem życia jest dostępne bez ręcznego tworzenia tych elementów. Konfiguracja odbywa 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 innych środowiskach. Modele są domyślnie przechowywane w pamięci przez 5 minut, a następnie usuwane z pamięci. Przed udzieleniem odpowiedzi kolejne żądanie musi ponownie wczytać cały plik. Jeśli jądro nadal przechowuje plik w page cache, operacja przebiega szybko, ale może to nastąpić tylko wtedy, gdy pozostaje dostępna pamięć RAM. Gdy inne zadania usuną plik z cache, zostanie on ponownie odczytany z dysku, więc ponowne wczytanie pliku o rozmiarze 4.58 GiB może wydłużyć odpowiedź z 2 sekund do 30 sekund na wolnym nośniku. Długi keep-alive eliminuje to opóźnienie, ale stale zajmuje pamięć RAM. Oba rozwiązania wiążą się z rzeczywistym kosztem. Należy wybrać to, które powoduje mniejsze problemy. Jeśli model ma pozostać stale w pamięci, ustawienie keep_alive, aby pozostawał w pamięci podczas bezczynności i po restartach wymaga kilku wierszy i eliminuje konieczność ręcznego rozgrzewania modelu po każdym restarcie serwera.

llama.cpp nie udostępnia demona ani użytkownika usługi, dlatego oba elementy trzeba skonfigurować samodzielnie. Z katalogu llama.cpp, w którym przeprowadzono kompilację, należy zainstalować plik binarny i jego biblioteki w /usr/local, utworzyć użytkownika llama oraz przekazać mu kopię modelu:

sudo cmake --install build
sudo ldconfig
sudo useradd --system --no-create-home --shell /usr/sbin/nologin llama
sudo install -d -o llama -g llama /srv/models
sudo install -o llama -g llama -m 644 ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf /srv/models/model-Q4_K_M.gguf

Jeśli użyto archiwum wydania zamiast kompilacji, należy wskazać w ExecStart katalog llama-server znajdujący się w archiwum, ponieważ biblioteki są w nim przechowywane obok pliku binarnego. Następnie należy zapisać jednostkę 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

Należy ją włączyć za pomocą sudo systemctl enable --now llama-server. Proces będzie wtedy przechowywać model przez cały czas działania. Domyślnie model nie jest usuwany z pamięci podczas bezczynności, ale dodanie --sleep-idle-seconds włącza automatyczne usuwanie i ponowne wczytywanie bez zatrzymywania usługi. Jeśli tworzenie jednostek jest nowym zagadnieniem, jest to ten sam wzorzec co uruchamianie własnych usług w systemd na VPS.

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

Zakres tej osi znacznie się zawęził. Oba projekty obsługują teraz format czatu OpenAI, więc większość bibliotek klienckich współpracuje z każdym z nich po zmianie jedynie bazowego adresu URL.

Ollama nasłuchuje na 127.0.0.1:11434. Jego trasa zgodna z OpenAI to http://localhost:11434/v1/chat/completions, a równolegle udostępnia natywne API pod /api/chat. Udokumentowano również trasę zgodną z Anthropic. Żadna z tych tras nie pozwala modelowi samodzielnie wyszukiwać informacji, dlatego jeśli aplikacja wymaga odpowiedzi nowszych niż dane użyte do trenowania modelu, należy zaplanować podłączenie wyszukiwania internetowego przez API Ollama, Open WebUI lub krótką pętlę narzędziową.

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"}]}'

Uruchomiony z powyższymi flagami, llama-server nasłuchuje na 127.0.0.1:8080. Pozostawiony sam sobie, domyślnie korzysta teraz z portu 9931 (stan na 27 października 2026), więc należy zachować --port w linii poleceń, jeśli aplikacja oczekuje portu 8080. Serwis obsługuje /v1/chat/completions, /v1/completions oraz /v1/embeddings, a także własny punkt końcowy /completion oraz wbudowany interfejs webowy. Udostępnia również trasy operacyjne, których nie posiada Ollama: /health do sprawdzania 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 po dodaniu --metrics, ponieważ ten punkt końcowy jest domyślnie wyłączony. Jeśli planowane jest monitorowanie tej usługi, ta różnica prawdopodobnie będzie czynnikiem decydującym.

Żaden z serwerów nie włącza automatycznie uwierzytelniania. Oba domyślnie ograniczają się do interfejsu loopback z uzasadnionych powodów. Należy uzyskiwać do nich dostęp przez tunel SSH lub zza reverse proxy i nigdy nie otwierać portów 11434 ani 8080 na świat.

Co realnie może VPS z samym CPU

VPS z samym CPU uruchamia małe modele powoli. To uczciwe podsumowanie, a użyteczna wiedza polega na określeniu granicy wydajności. Zmierz parametry 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 tokenach na sekundę. W planie ze współdzielonym vCPU model 8B w kwantyzacji Q4_K_M zazwyczaj osiąga niskie wartości jednocyfrowe dla tg. Przetwarzanie promptu jest najbardziej kosztowne: 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 to połowa rachunku, na którą masz realny wpływ, ponieważ przy trzech tokenach na sekundę model generujący 600 tokenów blokuje zasoby na 200 sekund, czyli ponad trzy minuty samej generacji, więc ograniczenie wyjścia za pomocą num_predict jest najtańszym sposobem, aby zapobiec przekroczeniu czasu oczekiwania przez zbyt długą odpowiedź.

Zastosowania na CPU: modele od 1B do 4B do klasyfikacji, ekstrakcji danych, krótkich podsumowań lub routingu. Odpowiedzi pojawiają się w ciągu kilku sekund, a zapotrzebowanie na pamięć mieści się w standardowym planie. Przykład praktyczny dla tego rozmiaru zamiast zakresu: Nemotron 3.5 Lightning pobrany i zmierzony na VPS wskazuje dokładny tag, realne zapotrzebowanie na RAM oraz szybkość uzyskiwaną bez GPU. Zastosowania niezalecane na CPU: interaktywny czat w tempie czytania, asystenci programowania, praca z długimi dokumentami lub cokolwiek z pętlą agenta wykonującą wiele wywołań w sekwencji. Pętla wykonująca dwanaście wywołań po cztery sekundy każde zajmuje minutę, zanim wyprodukuje jakikolwiek wynik. Jeśli planem był asystent programowania, skierowanie agenta na model hostowany samodzielnie wyjaśnia, w których zadaniach mały lokalny model faktycznie wygrywa, a które muszą pozostać w ramach hostowanego API.

Istnieją dwa wyjścia, gdy liczby nie są zadowalające. Jeśli problemem jest współbieżność, czyli wielu użytkowników korzystających z jednego modelu jednocześnie, należy zmienić silnik, a porównanie Ollama z vLLM dla obsługi współbieżnej wyczerpuje ten temat. Jeśli problemem jest czysta szybkość, rozwiązaniem jest VPS z dołączonym GPU, gdzie -ngl zaczyna mieć znaczenie. Przed podjęciem którejkolwiek z tych decyzji, ustal bazową wydajność sprzętu, ponieważ przepustowość dysku i pamięci wpływa na czas ładowania w takim samym stopniu jak CPU. Powtarzalny benchmark VPS jest wart poświęconej godziny.

Instalacja llama.cpp z przypięciem do konkretnego buildu

Oba projekty rozwijają się co tydzień, dlatego należy zapisać wersję wdrożoną na serwerze. Polecenie instalacyjne udostępnione przez projekt nadrzędny instaluje bieżący build:

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

Aby przypiąć konkretny build, należy zamiast tego pobrać gotowe archiwum tarball ze strony wydań. Projekt publikuje obecnie również wydania oparte na wersjonowaniu semantycznym: v0.7.0 było najnowszym wydaniem 27 October 2026, a strona tego wydania wskazuje nightly b11669 jako źródło plików binarnych. Wydanie v0.8.0 pojawiło się 28 October 2026, a jego strona wskazuje nightly b11960 jako źródło plików binarnych. Poniższe polecenia używają b10224, czyli tagu bieżącego 2 August 2026; należy podstawić tag, który został przetestowany:

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'

Można również 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ą funkcji HTTPS. Kompilacja trwa kilka minut i wymaga więcej pamięci RAM, niż zapewniają najmniejsze plany, dlatego należy wykonać ją na większym serwerze, a następnie skopiować pliki binarne, jeśli na małym serwerze zabraknie zasobów.

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 widoczne w systemie

Ollama odmawia załadowania modelu. Starsze wydania Ollama sprawdzały rozmiar przed załadowaniem, a ollama run zwracało komunikat w następującej postaci:

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

Aktualny kod źródłowy Ollama nie zawiera już tego komunikatu (sprawdzono 27 October 2026). Ollama przekazuje teraz ładowanie do llama-server, dlatego model, który się nie mieści, powoduje błąd runnera. Komunikaty zaczynają się wtedy od następujących wierszy:

llama-server reported out-of-memory during startup
llama-server process has terminated

W obu przypadkach rozwiązanie jest takie samo. Należy przejść o jeden wiersz kwantyzacji niżej, zmniejszyć długość kontekstu albo wybrać mniejszy model.

llama.cpp nie kończy działania błędem, ale działa bardzo wolno. llama.cpp domyślnie mapuje plik GGUF do pamięci, dlatego uruchamia się również wtedy, gdy plik jest większy niż dostępna pamięć RAM. Kernel odczytuje wtedy wagi z dysku i zapisuje je na dysku przy każdym tokenie. Generowanie zwalnia do kilku sekund na token, a użycie dysku osiąga 100 procent. Należy przekazać --load-mode none, aby wyłączyć mapowanie pamięci. Ta opcja zastąpiła --no-mmap, które w przypiętej kompilacji b10224 jest oznaczone jako przestarzałe i nie występuje już w aktualnych kompilacjach (sprawdzono 29 October 2026). Gdy kernel podejmuje takie działanie, dmesg pokazuje przyczynę:

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

Pliku modelu nie można załadować w ogóle. GGUF utworzony dla nowszej rodziny modeli niż obsługiwana przez silnik powoduje błąd zawierający nazwę nierozpoznanej architektury. <arch> oznacza nazwę zapisaną w metadanych pliku:

llama_model_load: error loading model: unknown model architecture: '<arch>'

Rozwiązaniem jest aktualizacja silnika, a nie użycie innego pliku. Jest to konsekwencja przypinania wersji. Z tego powodu należy zapisać numer kompilacji. Trzeba wiedzieć, z której wersji wykonywana jest aktualizacja.

API odpowiada lokalnie, ale nie z aplikacji. Ollama nasłuchuje na 127.0.0.1:11434, dlatego z innego hosta zwracane jest odrzucenie połączenia. OLLAMA_HOST=0.0.0.0:11434 należy ustawić przez systemctl edit ollama wyłącznie wtedy, gdy port znajduje się za zaporą sieciową lub w sieci prywatnej, ponieważ API nie ma wbudowanego uwierzytelniania.

Pierwsza odpowiedź po przerwie jest bardzo wolna. Nastąpiło rozładowanie po 5 minutach bezczynności i model jest ponownie ładowany. Odczyt następuje z dysku, jeśli page cache nie zachował modelu. Uruchomienie ollama ps tuż przed żądaniem nie pokazuje żadnego załadowanego modelu, co potwierdza tę sytuację. Należy zwiększyć 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, ale nakładka wykonuje realną pracę. Plik README projektu Ollama wskazuje llama.cpp jako backend wnioskowania (stan na 27 października 2026). Ollama dodaje do niego 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 VPS bez GPU?

Oba rozwiązania korzystają z tego samego silnika, 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 przed uznaniem jakichkolwiek opublikowanych danych za wiarygodne.

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

Tak. Należy umieścić plik na serwerze, utworzyć Modelfile, którego pierwsza linia to 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. Wersja 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.