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

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 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. 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 pracować 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 bezpośrednio llama.cpp, gdy serwer ma ograniczone zasoby i musisz precyzyjnie dobrać 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 transformatorów w językach C i C++, zbudowana na bibliotece 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 dostarcza oddzielne pliki binarne do 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 r., 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, wczytuje 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 r. 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 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 jest czytelne po zrozumieniu schematu: Q4_K_M oznacza 4-bitową kwantyzację typu K 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, z czego najmniejsza zajmuje 2.96 GiB, a największa 7.95 GiB. Powszechnie stosowany standard, Q4_K_M, zajmuje 4.58 GiB. Na serwerze VPS z 4 GiB pamięci RAM ten 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 użytkownik sam wybiera odpowiedni wiersz.

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 dla serwera działającego wyłącznie na CPU). Żaden z tych parametrów nie jest dobierany automatycznie.

W narzędziu Ollama kwantyzacja jest powiązana z tagiem pobieranego obrazu, a ollama ls pokazuje, co faktycznie znajduje się na dysku. Jeśli rejestr nie zawiera pożądanej 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 trafia do najniższego przedziału: 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 wynikającymi z niepełnego odczytu pliku. Wartość tę można zwiększyć za pomocą OLLAMA_CONTEXT_LENGTH w konfiguracji demona lub za pomocą 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 mówi

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 2 bajty na każdy element 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 zajmuje zatem 512 MiB, a kontekst 32,768 tokenów kosztuje 4 GiB.

Zatem model Q4_K_M 8B z kontekstem 4k wymaga w przybliżeniu 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 pamięci RAM. Zmieści się w 8 GiB z zapasem na działanie. Zwiększenie kontekstu do 32k na tym samym urządzeniu z 8 GiB RAM spowoduje, że sama pamięć podręczna wyczerpie dostępną przestrzeń. Monitoruj użycie na żywo za pomocą free -h podczas ładowania modelu i nie ufaj szacunkom, których nie zweryfikowano pomiarami.

Ollama zwielokrotnia ten efekt. OLLAMA_NUM_PARALLEL domyślnie wynosi 1, a zapotrzebowanie modelu na pamięć skaluje się wraz z iloczynem tej wartości i długości kontekstu. Zwiększenie obu tych parametrów jednocześnie sprawia, że daemon w tle niepostrzeżenie wymaga kilkukrotnie więcej pamięci RAM, niż zakładano.

Oś 2: demon, którym musisz zarządzać

Skrypt instalacyjny Ollama tworzy jednostkę systemd, dodaje użytkownika systemowego ollama i aktywuje usługę. Zarządzanie cyklem życia odbywa się automatycznie. Konfiguracja przebiega 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 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 podtrzymania (keep-alive) eliminuje opóźnienia, ale trwale zajmuje pamięć RAM. Oba rozwiązania wiążą się z kosztami. Wybierz to, które jest mniej dotkliwe.

llama.cpp nie dostarcza demona, więc 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 w pamięci przez cały czas swojego działania. W stanie bezczynności nic nie jest usuwane, co eliminuje opóźnienia przy ponownym wczytywaniu, ale uniemożliwia zwolnienie pamięci bez zatrzymania usługi. Jeśli tworzenie 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ą obecnie format czatu OpenAI, dzięki czemu większość bibliotek klienckich współpracuje z każdym z nich po zmianie jedynie adresu bazowego (base 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. Udokumentowana jest również ścieżka zgodna 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 udostępnia /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 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. 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 nasłuchują na interfejsie zwrotnym (loopback) z uzasadnionych powodów. 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 może VPS z samym CPU

VPS z samym CPU uruchamia małe modele powoli. To uczciwe podsumowanie, a kluczowe jest zrozumienie, gdzie leży granica 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 wartości podano 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 wydłuża czas oczekiwania przy każdym zapytaniu.

Zastosowania na CPU: modele od 1B do 4B do klasyfikacji, ekstrakcji danych, krótkich podsumowań lub routingu. Odpowiedzi pojawiają się w ciągu sekund, a zapotrzebowanie na pamięć mieści się w standardowym planie. Zastosowania niezalecane 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 zapytań po cztery sekundy każde wymaga minuty, zanim wygeneruje jakikolwiek wynik.

Istnieją dwa wyjścia, gdy wyniki nie są zadowalające. Jeśli problemem jest współbieżność, czyli wielu użytkowników korzystających z modelu jednocześnie, należy zmienić silnik, co opisuje porównanie Ollama i vLLM w obsłudze współbieżnej. 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ń należy ustalić 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ę wdrożonego oprogramowania. Standardowe polecenie 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ą 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 woli uniknąć przesyłania 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 etap 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 postaci:

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 wyjaśnieniem przyczyny. Należy wybrać model o stopień niżej w 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 każdym tokenie, co powoduje spadek wydajności do poziomu 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 wygeneruje 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 konkretnej 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 (connection refused). Zmienną OLLAMA_HOST=0.0.0.0:11434 ustawioną na systemctl edit ollama należy stosować 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 wykaże brak załadowanych modeli, co potwierdza tę diagnozę. 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ą 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 uczciwe rozwiązanie na serwerze VPS, gdzie model mieści się w pamięci z trudem, ponieważ ustawienia optymalizacyjne 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 produkcyjnego, którego konfiguracja ma pozostać niezmienna.

FAQ

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

Blisko, ale ta nakładka wykonuje realną pracę. Plik README projektu Ollama wskazuje llama.cpp jako backend wnioskowania (stan na 2 sierpnia 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 zazwyczaj wynikają 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 wynikach.

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 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.