Bo lokalny LLM to nie jedno pudełko. To silnik i obudowa. I zanim wybierzesz, w czym odpalać modele, warto wiedzieć, kto tu jest maszyną, a kto tylko ładnie polakierowanym panelem z pokrętłami. Nie po to, żeby wybierać strony w kolejnej wojnie plemiennej — po to, żeby wiedzieć, kiedy nakładka ci wystarczy, a kiedy trzeba zejść piętro niżej.

Silnik, którego nie widać: llama.cpp i ggml

Zacznijmy od dna, bo tam mieszka bohater tej historii. llama.cpp (repo ggml-org/llama.cpp) to biblioteka i silnik inferencji LLM napisane w czystym C/C++, z minimalnymi zależnościami, na licencji MIT.¹ Nie ma ładnego okienka. Nie ma listy modeli do kliknięcia. To surowy kod, który bierze wagi modelu i liczy — a liczy na bibliotece tensorowej niższego poziomu o nazwie ggml, i to ona jest właściwym mięśniem, który mnoży macierze pod całą tą konstrukcją.

To właśnie tu żyją rzeczy, które w codziennym „odpal i gadaj" są niewidzialne. Kwantyzacja po treningu (post-training quantization — ściskanie gotowych wag, nie trenowanie modelu od zera w niskiej precyzji, bo to dwie różne bajki) w formacie GGUF, z poziomami od 1.5-bitowego po 8-bitowy.¹ Akceleracja na Metal (Apple Silicon), CUDA (NVIDIA), HIP (AMD), Vulkan, SYCL (Intel), plus optymalizacje CPU (AVX/AVX2/AVX512).¹ Zestaw narzędzi z linii komend: llama-cli do rozmowy, llama-server z API, llama-bench do mierzenia wydajności, llama-quantize do ściskania modeli.¹ Rozbieraliśmy te flagi na czynniki pierwsze tutaj, a nazwy kwantyzacji GGUF (Q4_K_M i cała ta rodzina) tutaj.

Zapamiętaj jedno: kiedy Ollama, LM Studio albo KoboldCpp „uruchamia model", to w przytłaczającej większości przypadków pod spodem kręci się właśnie ten silnik. Reszta to obudowa. Świetna, wygodna, oszczędzająca ci godzin — ale obudowa.

Ollama: nakładka, która po cichu wyhodowała własny silnik

Ollama to najpopularniejszy sposób, w jaki ludzie wchodzą w lokalne LLM-y, i przez długi czas najkrótszy opis brzmiał: „llama.cpp z ładnym zarządzaniem modelami". Sama dokumentacja projektu mówi, że Ollama jest oparta na llama.cpp założonym przez Georgiego Gerganova i historycznie korzystała z niego jako silnika wykonawczego pod spodem; licencja MIT.²

Do tego dokłada rzeczy, których gołe llama.cpp ci nie da od strzału. Modelfile — format konfiguracyjny w duchu Dockerfile, który opisuje parametry, prompt systemowy i wagi, żeby zbudować z tego gotowy „obraz" modelu.² Rejestr ollama.com/library, z którego ściągasz modele jednym ollama pull, jak obrazy z Docker Huba. I własne REST API na porcie 11434 (http://localhost:11434/api/), odrębne od tego, co wystawia llama-server.² To jest właśnie ta wygoda, za którą się Ollamę kocha: nie myślisz o plikach GGUF, o ścieżkach, o flagach. Wpisujesz nazwę i działa.

Ale tu jest zwrot akcji, o którym połowa internetu wciąż nie wie. Od maja 2025, wraz z ogłoszeniem „Ollama’s new engine for multimodal models", Ollama dla części modeli — między innymi Meta Llama 4, Google Gemma 3, Qwen 2.5 VL czy Mistral Small 3.1 — przeszła na własny silnik napisany w Go, który korzysta bezpośrednio z biblioteki ggml, z pominięciem llama.cpp.³ llama.cpp i ggml zostają dla wstecznej kompatybilności na CPU i dla pozostałych modeli, ale samo hasło „Ollama to po prostu llama.cpp w ładnym opakowaniu" zrobiło się nieaktualne. Ciekawostka, ale ważna: nawet gdy nakładka odcina się od llama.cpp, i tak stoi na tym samym fundamencie — ggml. Mięsień został ten sam, zmieniło się tylko, kto go obsługuje.

LM Studio: okno, dwa silniki i zamknięte drzwi

A co, jeśli w ogóle nie chcesz terminala? Wtedy wchodzi LM Studio — aplikacja desktopowa na Windows, Linux i macOS, z prawdziwym GUI: przeglądasz modele, klikasz, pobierasz, gadasz. Pod spodem uruchamia modele przez llama.cpp w formacie GGUF, a na Apple Silicon dorzuca dodatkowo silnik MLX — inferencyjny framework Apple — jako alternatywę dla llama.cpp.⁴ Czyli znów: ten sam silnik u podstaw, tylko schowany za oknem, w które można klikać.

Dla programisty LM Studio wystawia dwie rzeczy naraz: OpenAI Compatibility API (żeby podpiąć się jak do OpenAI, tylko lokalnie) oraz własne LM Studio REST API (w wersji beta), a do tego CLI o nazwie lms do zarządzania modelami, serwerem i pobieraniem.⁴ Wygodne? Bardzo. Jest jednak jeden haczyk, który łatwo przeoczyć: to, że LM Studio stoi na otwartoźródłowych silnikach (llama.cpp, MLX), nie czyni z niego projektu open source. Sama aplikacja jest zamkniętym oprogramowaniem. Silnik w środku możesz obejrzeć do ostatniej linijki; obudowę wokół niego — już nie.

KoboldCpp: nie osobny silnik, tylko llama.cpp w jednym pliku

Na koniec przypadek, który najłatwiej źle zaszufladkować. KoboldCpp (LostRuins/koboldcpp) wygląda jak osobne narzędzie — jeden plik wykonywalny, który odpalasz i masz gotowy interfejs. Ale to nie konkurencyjny silnik wobec llama.cpp. To fork i nakładka bazująca bezpośrednio na jego kodzie, spakowana w pojedynczą binarkę i rozszerzona o dodatkowe funkcje. Sam KoboldCpp jest na licencji AGPL v3.0, przy czym zależność llama.cpp w środku pozostaje na MIT.⁵

Obsługuje modele GGUF (z kompatybilnością wsteczną dla starszego GGML — o czym za chwilę) i wystawia równolegle dwa API: własne KoboldAI/KoboldCpp oraz endpoint kompatybilny z OpenAI pod ścieżką /v1. Do tego dorzuca interfejs KoboldAI Lite z trybami chat, adventure, instruct i storywriter.⁵ Innymi słowy: bierze ten sam silnik, co reszta, i buduje wokół niego inny zestaw wygód — mocno wychylony w stronę pisania i grania. Nazwanie tego „rywalem llama.cpp" to jak nazwanie karoserii rywalem silnika.

To którego w końcu wziąć?

Teraz konkret, bo o to naprawdę chodzi. Nie o to, który silnik „lepszy" — bo silnik u podstaw (ggml) jest w dużej mierze wspólny — tylko o to, ile wygody wymieniasz za ile kontroli.

Nakładka wystarczy — i to z nawiązką — kiedy chcesz po prostu ściągać modele jednym poleceniem, przełączać się między nimi bez myślenia o ścieżkach i mieć endpoint, do którego podepniesz swój kod. To codzienność dziewięciu na dziesięciu lokalnych LLM-owców. Ollama do szybkiego pull i run, LM Studio jak wolisz klikać w okno, KoboldCpp jak siedzisz w pisaniu i przygodówkach.

Do gołego llama.cpp schodzisz, gdy zaczyna ci brakować pokręteł. Chcesz wycisnąć konkretny offload warstw na kartę, ustawić dokładny typ kwantyzacji KV-cache, złapać najświeższą flagę, która w repo pojawiła się wczoraj, a do nakładki dojdzie za dwa wydania. Albo chcesz llama-server z równoległym dekodowaniem (parallel decoding), serwujący do tego modele embeddingowe i rerankingowe pod twojego RAG-a.¹ Wtedy obudowa zaczyna przeszkadzać, a ty otwierasz maskę i grzebiesz przy silniku sam.

Zrób to sam: zejdź o piętro

Chcesz na własne oczy zobaczyć, że pod spodem siedzi jeden i ten sam mechanizm? Weź dowolny model GGUF, którego już używasz w Ollamie, i odpal go bezpośrednio w llama.cpp:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
# zbuduj wg instrukcji z README pod swój backend (Metal/CUDA/Vulkan/CPU)

llama-server -m twoj-model-q4_k_m.gguf -c 8192 -fa on

Wchodzisz na http://localhost:8080, dostajesz web UI i OpenAI-kompatybilne API — to samo, co daje ci nakładka, tylko bez pośrednika i z pełnym dostępem do każdej flagi. Kod, aktualne narzędzia i instrukcje budowania są w repo: github.com/ggml-org/llama.cpp. Jak zechcesz wrócić do wygody — Ollama, LM Studio i KoboldCpp czekają tam, gdzie je zostawiłeś. Nic nie tracisz, bo pliki GGUF działają wszędzie tak samo.

Bo cała ta scena — Ollama, LM Studio, KoboldCpp — to w gruncie rzeczy różne obudowy przykręcone do wspólnego silnika. Jedni lubią jeździć autem, nie otwierając nigdy maski, i to jest w porządku — dojedziesz, gdzie chcesz. Inni muszą wiedzieć, co tam warczy, i co jakiś czas zaglądają, czy wszystko na swoim miejscu. Lokalne AI ma miejsce dla obu. Ważne tylko, żeby wiedzieć, że pod każdą z tych błyszczących karoserii bije mniej więcej to samo serce — i że w każdej chwili możesz podnieść klapę i mu się przyjrzeć.