Szybki start z llama.cpp: CLI i serwer

Nieustannie wracam do llama.cpp do lokalnej inferencji – daje ono kontrolę, którą Ollama i inne narzędzia abstrahują, i po prostu działa. Łatwo uruchomić modele GGUF interaktywnie za pomocą llama-cli lub wystawić kompatybilne z OpenAI API HTTP za pomocą llama-server.

Jeśli nadal decydujesz między podejściami lokalnymi, self-hostowanymi i chmurowymi, zacznij od przewodnika filarowego LLM Hosting w 2026 roku: Porównanie infrastruktury lokalnej, self-hostowanej i chmurowej.

Dlaczego llama.cpp w 2026 roku

llama.cpp to lekki silnik inferencji z nastawieniem na:

• przenośność między CPU a wieloma backendami GPU,
• przewidywalne opóźnienia na pojedynczym urządzeniu,
• elastyczność wdrożenia, od laptopów po węzły on-prem.

Wysycha, gdy zależy Ci na prywatności i pracy offline, gdy potrzebujesz deterministycznej kontroli nad flagami runtime, lub gdy chcesz wbudować inferencję w większy system bez uruchamiania ciężkiego na Pythonie stacku.

Warto też rozumieć llama.cpp nawet jeśli później wybierzesz serwerowy runtime o wyższej przepustowości. Na przykład, jeśli Twoim celem jest maksymalna przepustowość serwowania na GPU, możesz chcieć porównać go z vLLM, używając: vLLM Quickstart: Wysokowydajne serwowanie LLM oraz możesz zmierzyć wybór narzędzi w: Ollama vs vLLM vs LM Studio: Najlepszy sposób na uruchamianie LLM lokalnie w 2026?.

Jeśli konkretnie Ollama jest alternatywą, z którą porównujesz llama-server, llama.cpp vs Ollama w 2026 to dedykowane porównanie punktowe, z konkretnymi czynniami, kiedy zachować Ollama, a kiedy przejść na bezpośrednie llama.cpp.

Instalacja llama.cpp na Windows, macOS i Linux

Istnieją trzy praktyczne ścieżki instalacji, w zależności od tego, czy zależy Ci na wygodzie, przenośności czy maksymalnej wydajności.

Instalacja przez menedżery pakietów

To najszybsza opcja „uruchomienia od ręki”.

# macOS lub Linux
brew install llama.cpp

# Windows
winget install llama.cpp

# macOS (MacPorts)
sudo port install llama.cpp

# macOS lub Linux (Nix)
nix profile install nixpkgs#llama-cpp

Wskazówka: po instalacji upewnij się, czy narzędzia istnieją:

llama-cli --version
llama-server --version

Instalacja przez prezbudowane binaria

Jeśli chcesz czystej instalacji bez kompilatorów, użyj oficjalnych prezbudowanych binariów opublikowanych w release’ach GitHub llama.cpp. Zwykle obejmują one wiele systemów operacyjnych i wiele backendów (warianty tylko CPU i z obsługą GPU).

Popularny workflow:

# 1) Pobierz odpowiedni archiwum dla Twojego systemu i backendu
# 2) Rozpakuj je
# 3) Uruchom z rozpakowanego folderu

./llama-cli --help
./llama-server --help

Zbudowanie ze źródła dla Twojego konkretnego sprzętu

Jeśli zależy Ci na wycisnięciu najlepszej wydajności z Twojego backendu CPU/GPU, zbuduj ze źródła za pomocą CMake.

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp

# Build CPU
cmake -B build
cmake --build build --config Release

Po budowie binaria znajdują się zwykle tutaj:

ls -la ./build/bin/

Budowanie z obsługą GPU w jednej komendzie

Włącz backend pasujący do Twojego sprzętu (przykłady pokazano dla CUDA i Vulkan):

# NVIDIA CUDA
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release

# Vulkan
cmake -B build -DGGML_VULKAN=ON
cmake --build build --config Release

Ubuntu 24.04 + GPU NVIDIA: pełny przewodnik po budowie

Na Ubuntu 24.04 z GPU NVIDIA potrzebujesz narzędzia CUDA i OpenSSL przed budową. Oto przetestowana kolejność:

1. Zainstaluj CUDA toolkit 13.1

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-ubuntu2404.pin
sudo mv cuda-ubuntu2404.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/13.1.1/local_installers/cuda-repo-ubuntu2404-13-1-local_13.1.1-590.48.01-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu2404-13-1-local_13.1.1-590.48.01-1_amd64.deb
sudo cp /var/cuda-repo-ubuntu2404-13-1-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-13-1

2. Dodaj CUDA do swojego środowiska (dodaj do ~/.bashrc):

# cuda toolkit
export PATH=/usr/local/cuda-13.1/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-13.1/lib64:$LD_LIBRARY_PATH

Następnie uruchom source ~/.bashrc lub otwórz nowy terminal.

3. Zainstaluj nagłówki deweloperskie OpenSSL (wymagane do czystej budowy):

sudo apt update
sudo apt install libssl-dev

4. Zbuduj llama.cpp (z katalogu zawierającego klon llama.cpp, z włączonym CUDA):

cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first --target llama-cli llama-mtmd-cli llama-server llama-gguf-split llama-embedding
cp llama.cpp/build/bin/llama-* llama.cpp

Prowadzi to do llama-cli, llama-mtmd-cli, llama-server, llama-embedding oraz llama-gguf-split w katalogu llama.cpp.

Możesz również skompilować wiele backendów i wybierać urządzenia w czasie wykonania. Jest to przydatne, jeśli wdrażasz ten sam build na nihomogenicznych maszynach.

Wybór modelu GGUF i kwantyzacji

Aby uruchomić inferencję, potrzebujesz pliku modelu GGUF (*.gguf). GGUF to format pojedynczego pliku, który wiąże wagi modelu wraz ze zstandaryzowanymi metadanymi potrzebnymi silnikom takim jak llama.cpp.

Dwa sposoby uzyskania modelu

Opcja A: Użycie lokalnego pliku GGUF

Pobierz lub skopiuj GGUF do ./models/:

mkdir -p models
# Umieść swój GGUF w models/my-model.gguf

Następnie uruchom go przez ścieżkę:

llama-cli -m models/my-model.gguf -p "Hello! Wyjaśnij, czym jest llama.cpp." -n 128

Opcja B: Pozwól llama.cpp pobrać z Hugging Face

Nowoczesne buildy llama.cpp mogą pobierać z Hugging Face i przechowywać pliki w lokalnej pamięci podręcznej. To często najłatwiejszy workflow do szybkich eksperymentów.

# Pobierz model z HF i uruchom prompt
llama-cli \
  --hf-repo ggml-org/tiny-llamas \
  --hf-file stories15M-q4_0.gguf \
  -p "Był sobie raz," \
  -n 200

Możesz też指定ić kwantyzację w selektorze repozytorium i pozwolić narzędziu wybrać pasujący plik:

llama-cli \
  --hf-repo unsloth/phi-4-GGUF:q4_k_m \
  -p "Podsumuj koncepcję kwantyzacji w jednym akapicie." \
  -n 160

Jeśli potrzebujesz całkowicie offline’owego workflow później, --offline wymusza użycie pamięci podręcznej i zapobiega dostępowi do sieci.

Wybór kwantyzacji do lokalnej inferencji

Kwantyzacja jest praktyczną odpowiedzią na pytanie „Która kwantyzacja GGUF powinnaś wybrać do lokalnej inferencji”, ponieważ bezpośrednio łączy jakość, rozmiar modelu i szybkość.

Praktyczny punkt startowy:

• zacznij od wariantu Q4 lub Q5 dla maszyn opartych na CPU,
• przesuń się do wyższej precyzji (lub mniej agresywnej kwantyzacji), gdy możesz pozwolić sobie na RAM lub VRAM,
• gdy model „jest głupi” dla Twojego zadania, naprawą często jest lepszy model lub mniej agresywna kwantyzacja, a nie tylko modyfikacje próbkowania.

Pamiętaj też, że okno kontekstowe ma znaczenie: większe rozmiary kontekstu zwiększają zużycie pamięci (czasami drastycznie), nawet jeśli sam plik GGUF mieści się w pamięci.

Szybki start llama-cli i kluczowe parametry

llama-cli to najszybszy sposób na zweryfikowanie, czy Twój model się ładuje, czy Twój backend działa i czy Twoje prompty zachowują się prawidłowo.

Minimalne uruchomienie

llama-cli \
  -m models/my-model.gguf \
  -p "Napisz krótkie porównanie TCP vs UDP." \
  -n 200

Interaktywna sesja czatu

Tryb konwersacji jest zaprojektowany dla szablonów czatu. Zwykle umożliwia zachowanie interaktywne i formatuje prompty zgodnie z szablonem modelu.

llama-cli \
  -m models/my-model.gguf \
  --conversation \
  --system-prompt "Jesteś zwięzłym asystentem inżynierii systemów." \
  --ctx-size 4096

Aby zakończyć generowanie, gdy model wyświetli konkretną sekwencję, użyj reverse promptu. Jest to szczególnie przydatne w trybie interaktywnym.

Główne flagi llama-cli, które mają znaczenie

Zamiast zapamiętywać 200 flag, skup się na tych, które dominują poprawność, opóźnienia i pamięć.

Model i pobieranie

Kontekst i przepustowość

Offload GPU i wybór sprzętu

Próbkowanie i jakość wyjścia

Przykładowe obciążenia z llama-cli

Podsumowanie pliku, nie tylko promptu

llama-cli \
  -m models/my-model.gguf \
  --system-prompt "Podsumowujesz dokumenty techniczne. Wyjście maksymalnie pięć punktów." \
  --file ./docs/incident-report.txt \
  -n 300

Uczynienie wyników bardziej replikowalnymi

Gdy debugujesz prompty, ustabilizuj nasiono i zmniejsz losowość:

llama-cli \
  -m models/my-model.gguf \
  -p "Wyciągnij kluczowe ryzyka z tej notki projektowej." \
  -n 200 \
  --seed 42 \
  --temp 0.2

Szybki start llama-server z API kompatybilnym z OpenAI

llama-server to wbudowany serwer HTTP, który może wystawić:

• endpointy kompatybilne z OpenAI dla czatu, uzupełnień, embeddowań i odpowiedzi,
• interfejs Web UI do testów interaktywnych,
• opcjonalne endpointy monitoringu dla widoczności produkcyjnej.

Uruchomienie serwera z lokalnym modelem

llama-server \
  -m models/my-model.gguf \
  -c 4096

Domyślnie nasłuchuje na 127.0.0.1:8080.

Aby wiązać z zewnętrznym (na przykład wewnątrz Dockera lub LAN), określ host i port:

llama-server \
  -m models/my-model.gguf \
  -c 4096 \
  --host 0.0.0.0 \
  --port 8080

Opcjonalne, ale ważne flagi serwera

Jeśli uruchamiasz w kontenerach, wiele ustawień może być również kontrolowanych przez zmienne środowiskowe LLAMA_ARG_*.

Przykładowe wywołania API

Uzupełnienia czatu z curl

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer no-key" \
  -d '{
    "model": "gpt-3.5-turbo",
    "messages": [
      { "role": "system", "content": "Jesteś pomocnym asystentem." },
      { "role": "user", "content": "Daj mi szybką ściągawkę do llama.cpp." }
    ],
    "temperature": 0.7
  }'

Wskazówka dla rzeczywistych wdrożeń: jeśli ustawisz --api-key, możesz wysłać go przez nagłówek x-api-key (lub nadal używać nagłówków Authorization w zależności od Twojej bramki).

Klient Pythona OpenAI skierowany do llama-server

Z serwerem kompatybilnym z OpenAI wiele klientów może działać, zmieniając tylko base_url.

import openai

client = openai.OpenAI(
    base_url="http://localhost:8080/v1",
    api_key="sk-no-key-required",
)

resp = client.chat.completions.create(
    model="gpt-3.5-turbo",
    messages=[
        {"role": "system", "content": "Jesteś zwięzłym asystentem."},
        {"role": "user", "content": "Wyjaśnić wątki vs rozmiar batcha w llama.cpp."},
    ],
)

print(resp.choices[0].message.content)

Embeddowania

Kompatybilne z OpenAI embeddowania są wystawiane w /v1/embeddings, ale model musi obsługiwać tryb pooling embeddowań, który nie jest none.

curl http://localhost:8080/v1/embeddings \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer no-key" \
  -d '{
    "input": ["hello", "world"],
    "model": "GPT-4",
    "encoding_format": "float"
  }'

Jeśli uruchamiasz dedykowany model embeddowań, rozważ uruchomienie serwera w trybie tylko embeddowań:

llama-server \
  -m models/Qwen3-Embedding-0.6B-Q8_0.gguf \
  --embeddings \
  --host 127.0.0.1 \
  --pooling last \
  --port 8080

albo jeśli chcesz uruchomić llama-cpp z modelem embeddowań na CPU:

CUDA_VISIBLE_DEVICES="" llama-server \
  -m models/Qwen3-Embedding-0.6B-Q8_0.gguf \
  --embeddings \
  --host 127.0.0.1 \
  --pooling last \
  --port 8080

spróbuj w ten sposób:

CUDA_VISIBLE_DEVICES="" llama-embedding \
  -m /path/to/Qwen3-Embedding-0.6B-Q8_0.gguf \
  -p "twój tekst tutaj" \
  --pooling last \
  --verbose-prompt

Serwowanie wielu modeli z jednego procesu

Powyższe przykłady wiążą llama-server z jednym modelem przy uruchomieniu. Jeśli potrzebujesz przełączać między modelami na podstawie każdego żądania – bez restartowania procesu – to po to jest tryb routera. Zobacz llama-server router mode: dynamiczne przełączanie modeli bez restartów. Dla skryptowalnego przepływu wyładowania wszystkich, który uwalnia VRAM bez restartowania routera, zobacz Unload All llama.cpp Router Models Without Restarting.

Wydajność, monitoring i wzmocnienie produkcyjne

Pytanie FAQ „Które opcje wiersza poleceń llama.cpp mają największe znaczenie dla szybkości i pamięci” staje się znacznie łatwiejsze, gdy traktujesz inferencję jak system:

• Górna granica pamięci to zwykle pierwsze ograniczenie (RAM na CPU, VRAM na GPU).
• Rozmiar kontekstu to wielki mnożnik pamięci.
• Offload warstw GPU to często najszybsza droga do wyższej liczby tokenów na sekundę.
• Rozmiary batchy i wątki mogą poprawić przepustowość, ale mogą też zwiększyć presję na pamięć.

Dla głębszego, inżynieryjnego punktu widzenia, zobacz: Wydajność LLM w 2026 roku: Benchmarki, wąskie gardła i optymalizacja.

Jeśli chcesz zmierzone wyniki stylu llama-cli na GPU klasy 16 GB – tokeny na sekundę, VRAM i obciążenie GPU podczas skanowania kontekstu (19K / 32K / 64K) na gęstych i MoE GGUF-ach – zobacz Benchmarki LLM na 16 GB VRAM z llama.cpp (szybkość i kontekst).

Konkretnie dla Qwen 3.6, llama.cpp teraz obsługuje wbudowane spekulacyjne dekodowanie Multi-Token Prediction (MTP), które może znacznie podnieść przepustowość generacji. Dla kompleksowego przewodnika pokrywającego wszystkie metody spekulacyjnego dekodowania w llama.cpp, zobacz Spekulacyjne dekodowanie. Dla benchmarków specyficznych dla MTP Qwen 3.6, zobacz Qwen 3.6 MTP vs Standardowe na GPU 16GB.

Monitorowanie llama-server z Prometheus i Grafana

llama-server może wystawić kompatybilne z Prometheus metryki w /metrics, gdy włączono --metrics. Naturalnie łączy się to z konfiguracjami scrape Prometheus i dashboardami Grafana.

Dla dashboardów i alertów specyficznych dla llama.cpp (i vLLM, TGI): Monitorowanie inferencji LLM w produkcji (2026): Prometheus & Grafana dla vLLM, TGI, llama.cpp. Szersze przewodniki: Obserwowalność: Przewodnik po monitoringu, metrykach, Prometheus & Grafana oraz Obserwowalność systemów LLM.

Podstawowa checklista wzmocnienia

Gdy Twój llama-server jest osiągalny poza localhost:

• użyj --api-key (lub --api-key-file), aby żądania były uwierzytelnione,
• unikaj wiązania do 0.0.0.0, jeśli tego nie potrzebujesz,
• rozważ TLS za pomocą flag SSL serwera lub zakończ TLS na reverse proxy,
• ogranicz równoległość za pomocą --parallel, aby chronić opóźnienia pod obciążeniem.

Szybkie rozwiązania problemów

Model się ładuje, ale odpowiedzi w czacie są dziwne

Endpointy czatu są najlepsze, gdy model ma obsługiwany szablon czatu. Jeśli wyjścia wyglądają nieustrukturyzowane, spróbuj:

• użycia llama-cli --conversation plus jawnego --system-prompt,
• weryfikacji, czy Twój model to wariant instrukcyjny lub dostrojony do czatu,
• testowania z użyciem interfejsu Web UI serwera przed podłączeniem go do aplikacji.

Spotkałeś z brakiem pamięci

Zmniejsz kontekst lub wybierz mniejszą kwantyzację:

• obniż --ctx-size,
• zmniejsz --n-gpu-layers, jeśli problemem jest VRAM,
• przejdź na mniejszy model lub bardziej skompresowaną kwantyzację.

Jest wolne na CPU

Zacznij od:

• --threads równych liczbie fizycznych rdzeni,
• umiarkowanych rozmiarów batchy,
• weryfikacji, czy zainstalowałeś build pasujący do Twojej maszyny (funkcje CPU i backend).

Referencje

• Oficjalne repozytorium i dokumentacja llama.cpp
• Oficjalna dokumentacja flag CLI
• Oficjalna dokumentacja llama-server i szczegóły API