Ollama czy vLLM: który serwer LLM wybrać?

Ollama vs vLLM — w jednym akapicie

Ollama to menedżer modeli z dołączonym serwerem: pobiera skwantyzowane wagi, ładuje je i odpowiada na 127.0.0.1:11434, używając CPU, jeśli tylko taki sprzęt jest dostępny na danym hoście. vLLM to silnik przepustowości: utrzymuje wysokie wykorzystanie GPU, obsługując jednocześnie wiele żądań, dlatego nie jest właściwym narzędziem na maszynie bez GPU. To jest całe kryterium wyboru. Rozmowa jednej osoby z lokalnym asystentem to zadanie dla Ollama. Aplikacja obsługująca zespół to zadanie dla vLLM.

Oba rozwiązania udostępniają zgodny z OpenAI interfejs HTTP API, dlatego kod klienta można przenosić między nimi przez zmianę bazowego URL. API nie stanowi różnicy. Różnica dotyczy tego, co dzieje się, gdy nadejdzie drugie żądanie, a pierwsze nadal generuje tokeny.

Czym faktycznie jest Ollama

Ollama to warstwa ułatwiająca obsługę. Jedno polecenie instalacji zapewnia rejestr modeli (ollama pull llama3.1:8b), lokalny magazyn wag, interfejs czatu, usługę systemd oraz interfejs API HTTP. Udostępniane modele są plikami GGUF, zwykle poddanymi kwantyzacji 4-bitowej. Dlatego model 7B lub 8B zajmuje na dysku około 5 GB zamiast 16 GB. To kwantyzacja umożliwia wnioskowanie na CPU.

Jego runner jest oparty na llama.cpp, bibliotece wnioskowania C++, która umożliwiła praktyczne stosowanie kwantyzacji GGUF na standardowym sprzęcie. Od tego czasu Ollama dodała własny silnik dla niektórych nowszych rodzin modeli, ale llama.cpp nadal stanowi podstawę większości udostępnianych modeli. Dlatego porównanie Ollama z llama.cpp jest w większości porównaniem warstwy ergonomii z rozwiązaniem, które ta warstwa opakowuje.

Docelowo rozwiązanie jest przeznaczone dla jednego użytkownika. W lipcu 2026 domyślna wartość OLLAMA_NUM_PARALLEL wynosi 1. Oznacza to, że jeden model przetwarza jedno żądanie naraz, a pozostałe oczekują w kolejce, która domyślnie mieści 512 wpisów (OLLAMA_MAX_QUEUE). Można zwiększyć ustawienie równoległości. W poniższej sekcji wyjaśniono związane z tym koszty. Jeśli Ollama nie była jeszcze uruchamiana, należy rozpocząć od hostowanie Ollama na VPS i pozostawienie zamkniętego portu 11434, ponieważ interfejs API nie zapewnia żadnego uwierzytelniania.

Czym właściwie jest vLLM

vLLM jest wyłącznie serwerem inferencyjnym. Nie zarządza biblioteką modeli, nie ma wbudowanego promptu czatu i nie pobiera modelu na żądanie. Podczas uruchamiania wskazuje się repozytorium Hugging Face. vLLM ładuje ten jeden model i udostępnia go do czasu zatrzymania procesu.

Ta specjalizacja zapewnia wysoką przepustowość. Odpowiadają za to dwa mechanizmy. PagedAttention przechowuje pamięć podręczną KV (key-value cache, stan mechanizmu uwagi dla poszczególnych tokenów, utrzymywany przez model dla każdego aktywnego żądania) w blokach o stałym rozmiarze, podobnie jak system operacyjny stronicuje pamięć. Żądanie nie wymaga już jednej dużej, ciągłej rezerwacji o rozmiarze określonym przez najgorszy przypadek. Dzięki temu pamięć, która wcześniej pozostawała zarezerwowana i niewykorzystana, może obsługiwać większą liczbę równoczesnych żądań. Continuous batching umożliwia dołączenie nowego żądania do przetwarzanej partii przy następnym kroku dekodowania, zamiast oczekiwania na zakończenie bieżącej partii. Po zakończeniu sekwencja natychmiast opuszcza partię, a jej miejsce zostaje ponownie wykorzystane.

W praktyce oznacza to, że na pojedynczym GPU zwiększenie liczby równoczesnych użytkowników z 1 do 30 znacznie podnosi łączną liczbę tokenów przetwarzanych na sekundę, a szybkość dla pojedynczego użytkownika spada znacznie mniej, niż można się spodziewać. Przy ustawieniach domyślnych Ollama zwiększenie liczby użytkowników z 1 do 30 sprawia, że 29 osób musi czekać.

Ciągłe przetwarzanie wsadowe jest kluczową różnicą

Załóżmy, że pięć żądań trafia do każdego serwera w tej samej chwili, na identycznym sprzęcie.

Ollama przy ustawieniach domyślnych przetwarza pierwsze żądanie do końca, następnie drugie itd. Piąty klient czeka na cztery pełne generowania. Całkowita przepustowość jest w przybliżeniu równa szybkości jednego generowania, ponieważ procesor wykonuje pracę tylko nad jedną sekwencją naraz.

vLLM dekoduje wszystkie pięć sekwencji w tym samym przebiegu w przód. Wygenerowanie jednego tokena dla pięciu sekwencji kosztuje niewiele więcej niż wygenerowanie jednego tokena dla jednej sekwencji, ponieważ kosztowną operacją jest odczyt wag modelu z pamięci, a ten odczyt jest współdzielony przez całą partię. Jest to ten sam fakt dotyczący przepustowości pamięci, który spowalnia wnioskowanie na CPU: koszt wynika z przesyłania wag, a nie z wykonywania obliczeń arytmetycznych.

Można ustawić OLLAMA_NUM_PARALLEL=4 i uzyskać część tych korzyści. Kosztem jest pamięć. Każde równoległe miejsce potrzebuje własnej pamięci podręcznej KV, a Ollama dzieli okno kontekstu między te miejsca. W rezultacie cztery równoległe żądania dla modelu skonfigurowanego na 8192 tokenów pozostawiają każdemu żądaniu kontekst o długości 2048 tokenów. Stronicowana pamięć podręczna vLLM pozwala uniknąć tego kompromisu, ponieważ bloki są przydzielane żądaniu w miarę jego rzeczywistego wzrostu.

Instalacja i uruchamianie za pomocą Ollama

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

Skrypt instalacyjny tworzy użytkownika systemowego ollama, instaluje plik binarny i rejestruje usługę ollama.service powiązaną z 127.0.0.1:11434. Wiersz eval rate wyświetlany przez --verbose zawiera rzeczywistą liczbę tokenów na sekundę na danym serwerze. Należy traktować tę wartość jako wiarygodną, a nie dane publikowane w dokumentacji.

Aby zwiększyć współbieżność, należy użyć rozszerzenia systemd typu drop-in, dzięki czemu aktualizacja nie nadpisze tej zmiany:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps pokazuje, co jest załadowane, a jego kolumna PROCESSOR przedstawia rzeczywistą wartość. 100% CPU oznacza, że GPU nie jest używane. Jest to właściwe wyjaśnienie większości zgłoszeń dotyczących powolnego działania Ollama.

Instalacja i uruchamianie za pomocą vLLM

vLLM wymaga systemu Linux oraz języka Python w wersji od 3.10 do 3.13. Należy zainstalować go we własnym środowisku wirtualnym, ponieważ pobiera określoną kompilację PyTorch:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

Następnie należy uruchomić model. Nazwa jest identyfikatorem repozytorium Hugging Face, a nie krótkim znacznikiem:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

Pierwsze uruchomienie trwa długo, ponieważ najpierw pobierane są wagi, a następnie profilowany jest procesor GPU w celu określenia liczby mieszczących się bloków pamięci podręcznej KV. Usługa nasłuchuje na porcie 8000. Należy sprawdzić jej działanie przed napisaniem kodu klienta:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Jeśli na serwerze jest już zainstalowany Docker, oficjalny obraz eliminuje konieczność obsługi zależności CUDA:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host jest wymagane i nie jest opcjonalne: PyTorch przekazuje tensory między procesami za pośrednictwem pamięci współdzielonej, a domyślny przydział pamięci współdzielonej Docker jest zbyt mały dla wnioskowania z równoległością tensorów.

Najważniejsze w środowisku produkcyjnym są flagi --max-model-len (okno kontekstu, za które jest się gotowym zapłacić), --gpu-memory-utilization (ułamek pamięci karty, który vLLM może zająć; od lipca 2026 domyślnie 0.92), --tensor-parallel-size służąca do podziału jednego modelu między kilka procesorów GPU oraz --api-key.

Uwierzytelnianie w vLLM jest obsługiwane za pomocą jednej flagi, a w Ollama nie jest dostępne

vLLM wymusza użycie tokenu bearer, jeśli zostanie mu przekazany:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

Ta sama wartość może pochodzić ze zmiennej środowiskowej VLLM_API_KEY. Żądanie bez tego tokenu otrzymuje odpowiedź HTTP 401. Nadal nie jest to powód, aby udostępniać port 8000 na publicznym interfejsie, ponieważ vLLM nie ogranicza liczby żądań, a token przesyłany przez zwykły HTTP można odczytać podczas transmisji. Oznacza to jednak, że serwer rozpoznaje pojęcie klienta.

Ollama nie oferuje takiej funkcji. Nie ma klucza, logowania ani listy dozwolonych adresów. Każdy proces, który może połączyć się z portem 11434, może uruchamiać, pobierać lub usuwać modele. Należy pozostawić usługę dostępną wyłącznie na interfejsie loopback i uzyskiwać do niej dostęp za pośrednictwem hostowanej samodzielnie sieci VPN WireGuard albo uwierzytelniającego odwrotnego serwera proxy, który kończy połączenie TLS (transport layer security).

Sprzęt: czego wymaga każde rozwiązanie

Ollama działa na CPU. Model poddany kwantyzacji 4-bitowej wymaga około pół gigabajta pamięci RAM na każdy miliard parametrów, a także około 1 gigabajta narzutu środowiska wykonawczego i dodatkowej pamięci na kontekst. Dlatego model 3B wymaga około 4 GB wolnej pamięci, a model 8B około 8 GB. Szybkość na współdzielonym vCPU wynosi od kilku do kilkunastu tokenów na sekundę. Jest to ograniczenie przepustowości pamięci, a nie nieprawidłowa konfiguracja. Nie można go usunąć żadną flagą.

vLLM zakłada użycie GPU. Domyślna ścieżka udostępnia niekwantyzowane wagi z precyzją 16-bitową. Jest to około 2 GB na każdy miliard parametrów. Model 8B wymaga więc około 16 GB pamięci wideo tylko na wagi. Nie obejmuje to pamięci podręcznej KV, która zapewnia współbieżność będącą powodem wdrożenia vLLM. Karta 24 GB pozostawia wystarczającą ilość pamięci podręcznej do praktycznego użycia. Karta 16 GB nie zapewnia takiej ilości pamięci. Należy wtedy wybrać mniejszy model albo przekazać --quantization wraz ze skwantyzowanym punktem kontrolnym. Dostępny jest backend CPU, ale standardowe pakiety wheel nie są dla niego zbudowane. Jego użycie eliminuje również powód uruchamiania vLLM.

Dlatego kwestia sprzętu w większości przypadków rozstrzyga również kwestię oprogramowania. Brak GPU oznacza wybór Ollama. Wypożyczone GPU wykorzystywane w 5 procentach, ponieważ żądania są obsługiwane szeregowo, oznacza wybór vLLM.

Które rozwiązanie wybrać dla danego obciążenia

• Jedna osoba, VPS z CPU, tworzenie i podsumowywanie treści: Ollama. Tempo jest akceptowalne, a nic innego nie jest prostsze.
• Asystent programistyczny lub serwer MCP łączący narzędzia z modelem lokalnym, z którego korzysta tylko jedna osoba: Ollama. Rzeczywiste obciążenie obejmuje jedno równoczesne żądanie.
• Porównywanie pięciu modeli w tym tygodniu: Ollama. Pobieranie i usuwanie modeli oznaczonych tagami to dokładnie zadanie, do którego ten produkt się nadaje, natomiast w przypadku vLLM dla każdego modelu wymagane jest ponowne uruchomienie procesu.
• Aplikacja wewnętrzna, produkt czatowy lub potok wyszukiwania informacji z rzeczywistymi użytkownikami: vLLM. W tym przypadku grupowanie żądań uzasadnia koszt GPU.
• Zadanie wsadowe oceniające sto tysięcy dokumentów w ciągu nocy: vLLM z wysoką wartością --max-num-seqs. Liczy się wyłącznie przepustowość, a opóźnienie dla pojedynczego dokumentu nie ma znaczenia.
• Platforma agentowa, na której kilka samodzielnie hostowanych agentów AI jednocześnie wysyła żądania do modelu: vLLM, ponieważ ruch generowany przez agentów ma charakter skokowy i z natury jest równoległy.

Tryby awarii wraz z komunikatami wyświetlanymi przez system

vLLM odmawia uruchomienia z błędem pamięci podręcznej KV. Komunikat zawiera obie wartości:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Model deklaruje okno kontekstu większe niż ilość pamięci dostępna po załadowaniu wag. Zmniejsz je za pomocą --max-model-len 8192 albo zwiększ --gpu-memory-utilization, jeśli żaden inny proces nie korzysta z karty. Ustawienie wykorzystania powyżej około 0.95 zwykle zamienia ten błąd podczas uruchamiania na późniejszą awarię CUDA out of memory podczas obciążenia. Jest to gorszy z tych dwóch scenariuszy.

Ollama wyświetla Killed w trakcie generowania. Mechanizm Linux OOM killer zatrzymał proces, ponieważ model wymagał więcej pamięci RAM, niż jest dostępne na serwerze. Potwierdź to za pomocą sudo dmesg | grep -i oom. Należy użyć mniejszego modelu albo modelu z silniejszą kwantyzacją. Zmiana ustawień nie rozwiąże tego problemu.

Ollama działa poprawnie samodzielnie, ale zatrzymuje się pod obciążeniem. Nigdzie nie pojawia się błąd. Żądania trwają po prostu dłużej wraz ze wzrostem liczby wywołujących je klientów, ponieważ OLLAMA_NUM_PARALLEL=1 obsługuje je szeregowo. Zwiększ tę wartość i zaakceptuj mniejszy kontekst dla pojedynczego żądania albo przenieś obciążenie do vLLM.

vLLM zwraca kod 401 przy każdym wywołaniu. Uruchomiono go z opcją --api-key, ale klient nie wysyła nagłówka Authorization. Większość bibliotek klienckich OpenAI wysyła wartość przekazaną jako klucz, dlatego należy ustawić ją w tym miejscu zamiast usuwać tę opcję.

vLLM informuje, że nie znaleziono modelu. Ollama pobiera modele na żądanie, natomiast vLLM tego nie robi. Pole model w treści żądania musi odpowiadać identyfikatorowi repozytorium użytemu podczas uruchamiania albo wartości --served-model-name, jeśli została ustawiona. Potwierdź dokładny ciąg znaków za pomocą curl http://localhost:8000/v1/models.

Uruchomienie obu rozwiązań jest rozsądną odpowiedzią

Nie wykluczają się wzajemnie. Często stosowany układ obejmuje vLLM na instancji GPU, gdzie obsługuje aplikację, oraz Ollama na zwykłym VPS, gdzie obsługuje lokalne skrypty, zadania cron i testowanie nowych wydań modeli. Oba punkty końcowe są zgodne z OpenAI, dlatego wystarczy jedna biblioteka kliencka oraz zmiana base URL. Kontrola kosztów ma tu większe znaczenie niż wybór któregokolwiek silnika, ponieważ bezczynny GPU kosztuje tyle samo co obciążony, a utrzymywanie przewidywalnych kosztów agentów i inferencji jest odrębnym zadaniem od wyboru serwera.

FAQ

Czy vLLM jest szybszy niż Ollama?

W przypadku pojedynczego żądania na tym samym GPU różnica jest niewielka, ponieważ oba rozwiązania wykonują te same obliczenia. Przy wielu jednoczesnych żądaniach vLLM ma zdecydowaną przewagę, ponieważ continuous batching dekoduje każdą aktywną sekwencję w jednym przebiegu w przód, podczas gdy domyślna konfiguracja Ollama przetwarza je kolejno. Na maszynie wyposażonej wyłącznie w CPU pytanie to nie ma zastosowania: Ollama działa w takim środowisku, a vLLM praktycznie nie.

Czy vLLM może działać bez GPU?

Nie w sposób użyteczny. Standardowe wheels są przeznaczone dla GPU NVIDIA lub AMD, a cel istnienia vLLM, czyli pełne wykorzystanie akceleratora przy przetwarzaniu grup żądań, znika w środowisku CPU. Dostępny jest backend CPU przeznaczony do prac programistycznych. Do rzeczywistego wnioskowania na CPU należy użyć bezpośrednio Ollama lub llama.cpp.

Jaka jest różnica między Ollama a llama.cpp?

llama.cpp jest biblioteką wnioskowania, a GGUF jest jej formatem skwantyzowanych wag. Runner Ollama jest na niej oparty i dodaje elementy, które w llama.cpp pozostają do skonfigurowania samodzielnie: rejestr modeli, automatyczne pobieranie, rezydentny serwer, jednostkę systemd oraz endpoint zgodny z OpenAI. Ollama dodała własny silnik dla niektórych nowszych rodzin modeli, dlatego oba rozwiązania nie są już identyczne wewnętrznie.

Ile pamięci GPU wymaga model 8B w vLLM?

Przy precyzji 16-bit same wagi zajmują około 16 GB, czyli w przybliżeniu 2 GB na każdy miliard parametrów, a dodatkowo należy zapewnić miejsce na pamięć podręczną KV. Karta 24 GB zapewnia komfortowy zapas. Karta 16 GB wymaga użycia skwantyzowanego checkpointu lub mniejszego modelu. vLLM rezerwuje ułamek pamięci karty określony przez --gpu-memory-utilization, którego wartość domyślna wynosi 0.92 według stanu na lipiec 2026.

Czy aby przełączać się między tymi rozwiązaniami, trzeba zmienić kod aplikacji?

Zwykle wystarczy zmienić bazowy URL, klucz API oraz nazwę modelu. Ollama udostępnia zgodny z OpenAI interfejs pod adresem http://127.0.0.1:11434/v1 i ignoruje klucz, natomiast vLLM udostępnia http://localhost:8000/v1 i wymusza użycie klucza, jeśli zostanie on ustawiony. Nazwy modeli mają inną postać: llama3.1:8b w Ollama oraz pełny identyfikator repozytorium, taki jak Qwen/Qwen2.5-1.5B-Instruct, w vLLM.