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 pytanie. llama.cpp to silnik wnioskowania: ładuje 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. W pliku README projektu Ollama nadal widnieje 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 małym serwerem 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 bibliotece ggml. Odczytuje ona pliki GGUF. GGUF (GGML universal file format) to kontener w formie pojedynczego pliku, przechowujący wagi, tokenizator oraz metadane niezbędne silnikowi do uruchomienia modelu. Projekt dostarcza 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 roku, a nowy tag pojawia się w większość dni roboczych.

Ollama to program napisany w języku Go. Demon działający w tle, uruchamiany za pomocą ollama serve, ładuje modele i odpowiada na żądania HTTP, a klient wiersza poleceń komunikuje się z tym demonem. Za oboma 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 roku. ollama pull pobiera plik GGUF wraz z szablonem promptu i zestawem domyślnych parametrów, a następnie przechowuje go w lokalizacji /usr/share/ollama/.ollama/models w systemie Linux.

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 podejmuje żadnych decyzji i udostępnia flagi.

Oś 1: kontrola modelu i kwantyzacji

Kwantyzacja redukuje 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 jest czytelne po zrozumieniu schematu: Q4_K_M oznacza kwantyzację K-quant 4-bitową o średnim rozmiarze. Wyższa liczba zachowuje 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. Dostępnych jest 6 kompilacji jednego modelu, a najmniejsza z nich ma 2.96 GiB w porównaniu do 7.95 GiB dla największej. Powszechnie stosowany standard, 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 zostanie załadowany.

W przypadku llama.cpp nazwa pliku jest definiowana ręcznie, więc wybór konkretnego wariantu 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 zostanie przeniesionych do GPU (wartość 0 na serwerze bez GPU). Żaden z tych parametrów nie jest dobierany automatycznie.

W narzędziu Ollama kwantyzacja jest powiązana z tagiem pobieranego obrazu, a ollama ls pozwala sprawdzić, co faktycznie znajduje się na dysku. Jeśli w rejestrze nie ma poszukiwanej 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 zweryfikować wynik:

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

Długość kontekstu to ustawienie, które często sprawia trudności. Ollama wybiera wartość domyślną na podstawie dostępnej pamięci VRAM, a serwer bez GPU przypisuje najniższy limit: 4096 tokenów. Przesłanie dokumentu o długości 20 000 tokenów spowoduje odrzucenie nadmiarowych danych, zanim model je przetworzy, co skutkuje błędnymi odpowiedziami opartymi na niepełnych informacjach. Wartość tę można zwiększyć za pomocą OLLAMA_CONTEXT_LENGTH w konfiguracji demona lub PARAMETER num_ctx w pliku Modelfile. Narzędzie llama.cpp również nie posiada domyślnych ustawień, na których można polegać. Należy jawnie zdefiniować -c i mieć pełną świadomość dokonanego wyboru.

Arytmetyka pamięci, o której nikt nie wspomina

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 zarówno klucz, jak 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 wymaga 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 na pamięć podręczną oraz zasoby dla samego środowiska uruchomieniowego. Nie zmieści się on w 4 GiB pamięci RAM. Zmieści się w 8 GiB z zapasem na operacje. Zwiększenie kontekstu do 32k na tym samym urządzeniu z 8 GiB RAM 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 zweryfikowano pomiarami. Jeśli planujesz wdrożenie modelu znacznie większego niż 8B, ta sama arytmetyka zastosowana dla modelu 27B na serwerze VPS tylko z CPU pokazuje, co faktycznie mieści się w każdej kategorii od 8 do 64 GB.

Ollama potęguje ten efekt. OLLAMA_NUM_PARALLEL domyślnie wynosi 1, a pamięć wymagana przez model skaluje się wraz z iloczynem tej wartości i długości kontekstu. Zwiększenie obu tych parametrów jednocześnie sprawi, że daemon zażąda znacznie więcej pamięci RAM, niż przewidywano. Ta sama arytmetyka wyznacza górny limit liczby jednoczesnych użytkowników, ponieważ każde równoległe żądanie wymaga własnego fragmentu pamięci podręcznej KV, co wyjaśnia, dlaczego serwer działający poprawnie dla jednej osoby przestaje odpowiadać przy pięciu.

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

Skrypt instalacyjny Ollama tworzy jednostkę systemd, powołuje użytkownika systemowego ollama i aktywuje usługę. Zarządzanie cyklem życia odbywa się automatycznie. Konfiguracja przebiega poprzez 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 serwerach VPS opartych na CPU niż gdziekolwiek indziej. Modele są domyślnie utrzymywane w pamięci przez 5 minut, a następnie usuwane. Kolejne żądanie wymusza odczyt całego pliku z dysku przed udzieleniem odpowiedzi, więc ponowne wczytanie 4.58 GiB zmienia dwusekundową odpowiedź w trzydziestosekundową na wolnych nośnikach. Dłuższy 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 dotkliwe.

llama.cpp nie dostarcza gotowego demona, więc jednostkę należy przygotować 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 w pamięci przez cały czas działania. Nic nie jest usuwane w stanie bezczynności, co eliminuje opóźnienia przy ponownym wczytywaniu, ale uniemożliwia odzyskanie pamięci bez zatrzymania usługi. Jeśli pisanie jednostek jest nowym zagadnieniem, schemat postępowania jest identyczny jak 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 trasa zgodna z OpenAI to http://localhost:11434/v1/chat/completions, a obok niej utrzymuje natywne API pod /api/chat. Udokumentowano również trasę 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ż trasy 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, ta różnica prawdopodobnie 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 realnie potrafi VPS wyposażony tylko w CPU

VPS wyposażony wyłącznie w CPU uruchamia małe modele powoli. To uczciwe podsumowanie, a kluczowe jest zrozumienie, gdzie przebiega granica wydajności. Zmierz parametry, zanim zaprojektujesz jakiekolwiek rozwiązanie:

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 wartości podano w tokenach na sekundę. W planie z współdzielonym vCPU model 8B w kwantyzacji Q4_K_M zazwyczaj osiąga niskie wartości jednocyfrowe w tg. Przetwarzanie promptu jest najbardziej odczuwalnym etapem: cały prompt musi zostać przetworzony, zanim pojawi się pierwszy token wyjściowy, więc długi prompt systemowy dodaje czas oczekiwania do każdego pojedynczego żądania.

Zastosowania możliwe na CPU: modele od 1B do 4B wykonujące klasyfikację, ekstrakcję danych, krótkie podsumowania lub routing. Odpowiedzi pojawiają się w ciągu kilku sekund, a zapotrzebowanie na pamięć mieści się w standardowym planie. Zastosowania niemożliwe na CPU: interaktywny czat w tempie czytania, asystenci programowania, praca z długimi dokumentami lub jakiekolwiek zadania z pętlą agenta wykonującą wiele wywołań sekwencyjnie. Pętla wykonująca dwanaście wywołań po cztery sekundy każde wymaga minuty, zanim wygeneruje jakikolwiek wynik. Jeśli plan zakładał użycie asystenta programowania, skierowanie agenta na samodzielnie hostowany model 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 w obsłudze współbieżnej omawia to zagadnienie. Jeśli problemem jest surowa szybkość, rozwiązaniem jest VPS z dołączonym GPU, gdzie -ngl zaczyna mieć znaczenie. Przed podjęciem jakichkolwiek działań 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 wersji

Oba projekty rozwijają się w cyklu tygodniowym, dlatego należy odnotować wersję, która została wdrożona. Polecenie typu one-liner z repozytorium upstream instaluje bieżącą wersję:

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 releases. 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ą dla funkcji HTTPS. Kompilacja trwa kilka minut i wymaga więcej pamięci RAM, niż posiadają najmniejsze plany serwerowe. Jeśli na małej maszynie wystąpi błąd braku pamięci, 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, dzięki czemu można zachować sprawdzoną wersję zamiast pobierać wydanie opublikowane dzisiaj. Wersja v0.32.5 została wydana 27 lipca 2026. Dostępna jest również ścieżka ręczna, jeśli użytkownik woli nie 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 błędów

Ollama odmawia załadowania modelu. ollama run zwraca wiersz o następującej strukturze:

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 wybrać model o niższej kwantyzacji, zmniejszyć długość kontekstu lub wybrać mniejszy model.

llama.cpp nie zgłasza błędu, lecz działa skrajnie wolno. llama.cpp domyślnie mapuje pliki GGUF w pamięci, więc plik większy niż dostępna pamięć RAM mimo wszystko się uruchamia. Jądro systemu przenosi wagi między pamięcią a dyskiem przy generowaniu każdego tokena, 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ę pamięci; dzięki temu proces zakończy się błędem 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 (pinning), dlatego należy zapisywać numer kompilacji. Niezbędna jest wiedza o wersji, z której przeprowadzana jest aktualizacja.

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 wykazuje brak załadowanych modeli, co potwierdza tę przyczynę. 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 właściwy wybór domyślny dla pierwszego wdrożenia 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ą samodzielnego doboru kwantyzacji, gdy potrzebujesz /health, /slots oraz /metrics do monitorowania lub gdy wymagana jest flaga, której Ollama nie udostępnia. Jest to optymalne rozwiązanie na serwerze VPS, gdzie model mieści się w pamięci z trudem, ponieważ ustawienia pozwalające na jego uruchomienie są dokładnie tymi, które Ollama dobiera automatycznie.

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

FAQ

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

Blisko, jednak ta nakładka wykonuje realną pracę. Plik README projektu Ollama wskazuje llama.cpp jako backend wnioskowania (stan na 2 sierpnia 2026). Ollama dodaje do tego 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ądzania.

Co działa szybciej 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, 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.