vLLM czy SGLang? Czym serwować model dla całej firmy (i dlaczego nie Ollama)

Szybka odpowiedź

Ollama i llama.cpp to narzędzia do pracy lokalnej: laptop, domowy serwer, jedna stacja robocza, prototyp, jeden użytkownik albo kilka osób. Są w tym bardzo dobre. vLLM i SGLang to silniki produkcyjne: stawia się je za firmowym API, z którego naraz korzystają dziesiątki osób i agentów. Różnicy nie widać przy jednym pytaniu. Widać ją, gdy kilkanaście osób pyta naraz, a agent wysyła długie prompty z dokumentami. My serwujemy modele przez vLLM i SGLang, a który z nich obsługuje dany model, rozstrzygamy pomiarem.

Stan na 20 sierpnia 2026 r.: vLLM 0.27.1, SGLang 0.5.17, Ollama 0.32.15, llama.cpp wydawany jako codzienne buildy.

Dwa światy: lokalnie i produkcyjnie

Źródła w tabeli: Ollama FAQ, llama.cpp server README, vLLM README, SGLang README, SGLang: HiCache, SGLang: Anthropic-Compatible API.

Dlaczego liczba użytkowników zmienia wszystko?

Model językowy generuje odpowiedź token po tokenie. Przy każdym tokenie GPU musi odczytać z pamięci wszystkie wagi modelu. Gdy pyta jedna osoba, karta przez większość czasu czeka na pamięć, a jej moc obliczeniowa leży odłogiem. Gdy pyta kilkanaście osób naraz, silnik może przetwarzać ich zapytania w jednej partii (batchu): wagi czyta się raz, a liczy kilkanaście odpowiedzi.

Problemem jest cache KV, czyli pamięć na kontekst każdej rozmowy. Rośnie z długością promptu i liczbą równoległych zapytań. Jak go policzyć, pokazujemy w przewodniku ile VRAM do lokalnego LLM.

Silniki różnią się tym, jak tym cache zarządzają:

• Rezerwacja z góry. Każdy slot dostaje stały kawałek pamięci na maksymalny kontekst. Proste, ale marnuje pamięć, bo większość rozmów jest krótsza niż maksimum. Tak działają narzędzia lokalne, w których i tak pyta jedna osoba.
• PagedAttention (vLLM). Cache KV dzieli się na małe bloki przydzielane na żądanie, jak strony pamięci w systemie operacyjnym. Autorzy vLLM pokazali, że to pozwala obsłużyć 2-4 razy większą przepustowość przy tym samym opóźnieniu niż wcześniejsze systemy (Kwon i in., 2023).
• RadixAttention (SGLang). Cache KV wszystkich zapytań trzymany jest w drzewie prefiksów (radix tree). Nowe zapytanie, które zaczyna się tak samo jak wcześniejsze, korzysta z już policzonej części, a rzadko używane gałęzie są usuwane, gdy brakuje pamięci (Zheng i in., 2023). To dobrze pasuje do agentów, które rozgałęziają rozmowę i wysyłają w kółko ten sam prompt systemowy i te same definicje narzędzi.
• Ciągły batching. Nowe zapytanie dołącza do trwającej partii, gdy tylko zwolni się miejsce, zamiast czekać, aż skończą się wszystkie odpowiedzi.
• Cache prefiksów. Gdy wiele zapytań zaczyna się tak samo, silnik nie liczy wspólnego początku od nowa. W vLLM robi to automatyczny cache prefiksów (vLLM: Automatic Prefix Caching), w SGLang wspomniane drzewo. W RAG i u agentów to duża oszczędność czasu do pierwszego tokenu.

Ollama i llama.cpp: świetne lokalnie

Ollama to najszybszy sposób, żeby uruchomić model na własnym komputerze: jedna komenda pobiera wagi i startuje serwer. Pod spodem korzysta z llama.cpp i formatu GGUF. Ma API zgodne z OpenAI, więc aplikacja napisana pod Ollamę przejdzie później na silnik produkcyjny bez przepisywania (Ollama: OpenAI compatibility).

Dlaczego nie stawiamy jej za firmowym API, wynika wprost z dokumentacji (Ollama FAQ):

• OLLAMA_NUM_PARALLEL domyślnie wynosi 1, czyli jeden model obsługuje jedno zapytanie naraz. Kolejne trafiają do kolejki (domyślnie do 512 zapytań).
• Po zwiększeniu równoległości pamięć potrzebna na kontekst rośnie proporcjonalnie do liczby równoległych zapytań i długości kontekstu.
• Ollama ładuje modele na żądanie i trzyma kilka w pamięci (domyślnie do 3 na GPU). Na stacji roboczej to wygoda, na serwerze produkcyjnym oznacza niespodziewane przeładowania.

llama.cpp to biblioteka i serwer llama-server, na których opiera się m.in. Ollama. Działa na CPU, kartach NVIDIA (CUDA), AMD (HIP), Intel (SYCL), przez Vulkan i na Macach (Metal) (README llama.cpp), a kwantyzacje GGUF pozwalają zmieścić model na sprzęcie z małą ilością pamięci, kosztem jakości przy niskich bitach. Serwer ma więcej możliwości, niż się zwykle zakłada: sloty z automatycznie dobieraną liczbą, ciągły batching domyślnie włączony, wspólny bufor cache KV, cache promptu, endpointy zgodne z OpenAI, klucz API i tryb routera, który ładuje kilka modeli z katalogu (README serwera).

Do czego ich używać:

• laptop programisty i prywatny asystent,
• domowy serwer albo jedna stacja robocza,
• nauka, testy nowych modeli, prototypy,
• Mac, CPU, GPU inne niż NVIDIA, urządzenia brzegowe,
• modele, które trzeba mocno skwantyzować, żeby w ogóle się zmieściły.

Czego im nie powierzamy: firmowego API, z którego naraz korzysta kilkanaście lub kilkadziesiąt osób i agentów. Tam przewagę dają silniki zbudowane wokół wielu równoległych rozmów.

vLLM i SGLang: silniki produkcyjne

Gdy model ma obsłużyć całą firmę, czyli kilkanaście lub kilkadziesiąt osób naraz, agentów i wsadowe przetwarzanie dokumentów, wybieramy jeden z dwóch silników. Oba mają licencję Apache 2.0 i bardzo podobny zakres funkcji.

vLLM daje w jednym pakiecie (README vLLM):

• PagedAttention, ciągły batching, chunked prefill i cache prefiksów,
• kwantyzacje FP8, MXFP8/MXFP4, NVFP4, INT8, INT4, GPTQ/AWQ i GGUF,
• dekodowanie spekulatywne,
• tensor, pipeline, data i expert parallelism, czyli podział modelu na kilka GPU,
• wiele adapterów LoRA na jednym modelu bazowym (vLLM: LoRA),
• structured outputs oraz parsery wywołań narzędzi i rozumowania dla agentów,
• API zgodne z OpenAI, a także z API Anthropic Messages i gRPC,
• wsparcie GPU NVIDIA, AMD i Intel, CPU oraz innych akceleratorów przez wtyczki.

SGLang ma podobny zakres (README SGLang):

• RadixAttention, czyli cache prefiksów w drzewie, ciągły batching, paged attention i chunked prefill,
• hierarchiczny cache KV (HiCache): GPU, pamięć RAM i zewnętrzny magazyn, przydatny przy długim kontekście i rozmowach wieloturowych (SGLang: HiCache),
• kwantyzacje FP4, FP8, INT4, AWQ i GPTQ (SGLang: Quantization),
• dekodowanie spekulatywne i rozdzielenie prefill i decode na osobne maszyny,
• tensor, pipeline, expert i data parallelism,
• wiele adapterów LoRA w jednej partii, oparte na technikach S-LoRA i Punica (SGLang: LoRA Serving),
• structured outputs, parsery narzędzi i rozumowania (SGLang: Tool Parser),
• API zgodne z OpenAI oraz endpoint /v1/messages zgodny z API Anthropic, włączony domyślnie (SGLang: Anthropic-Compatible API).

Czym się różnią w praktyce?

Oba projekty rozwijają się bardzo szybko i przejmują od siebie pomysły, więc różnice w funkcjach z wersji na wersję się zacierają. Różnice w wydajności zależą od modelu, kwantyzacji, długości promptów i wersji silnika. Dlatego nie wybieramy silnika z rankingu, tylko mierzymy oba na ruchu, który model ma obsługiwać.

Koszt tej mocy w obu przypadkach: więcej konfiguracji niż w Ollamie, wymóg wag w formacie Hugging Face, częste wydania (nowa wersja co kilka tygodni) i to, że nowe modele często wymagają najnowszej wersji silnika.

A co z TGI?

Text Generation Inference od Hugging Face od grudnia 2025 r. jest w trybie utrzymania: przyjmuje tylko drobne poprawki i dokumentację. Sam Hugging Face poleca vLLM, SGLang oraz lokalne silniki w rodzaju llama.cpp i MLX (README TGI). Ostatnie wydanie, 3.3.7, pochodzi z grudnia 2025 r. Nowych wdrożeń nie warto na nim budować.

Formaty wag: GGUF czy safetensors?

To praktyczna różnica, którą łatwo przeoczyć:

• GGUF to format llama.cpp i Ollamy. Ma wiele wariantów kwantyzacji (np. Q4, Q5, Q8), dobrze działa na CPU i Macach.
• Safetensors z Hugging Face to format, w którym producenci publikują modele i oficjalne kwantyzacje (FP8, NVFP4, AWQ). Na nim pracują vLLM i SGLang.

vLLM potrafi wczytać GGUF, ale na GPU NVIDIA lepiej użyć oficjalnych wag FP8 lub NVFP4, bo korzystają z rdzeni Tensor nowych kart. Jak wybrać między FP8, NVFP4 i AWQ, opisujemy w artykule kwantyzacja modeli na GPU Blackwell.

Jak zabezpieczyć serwer modeli?

Wspólna zasada dla wszystkich silników: serwer modeli nie stoi bezpośrednio w sieci użytkowników ani w internecie.

• Ollama domyślnie nasłuchuje tylko na 127.0.0.1:11434 i nie ma własnego uwierzytelniania. Zmiana OLLAMA_HOST na 0.0.0.0 bez niczego przed nią otwiera model dla każdego w sieci.
• llama.cpp i vLLM mają opcję klucza API (--api-key), ale to współdzielony klucz, bez użytkowników, ról i dziennika.
• Przed modelem stawiamy bramkę: uwierzytelnianie użytkowników, limity, dziennik zapytań i jeden adres dla wszystkich aplikacji.

Szersze ryzyka aplikacji z LLM opisujemy w artykule o OWASP Top 10 dla LLM.

Jak to robimy u siebie

Na naszych serwerach z GPU NVIDIA Blackwell serwujemy modele przez vLLM i SGLang. Aplikacje widzą jeden adres zgodny z API OpenAI, więc zmiana silnika albo modelu pod spodem nie wymaga zmian w aplikacjach. Dzięki temu możemy dla każdego modelu wybrać silnik, który na naszym ruchu sprawdza się lepiej, i przełączyć go bez przestoju dla użytkowników. Modele wdrażamy na flotę GPU naszym narzędziem inferctl, w którym Ansible i Terraform siedzą w jednym repozytorium.

Ollamy i llama.cpp używamy tam, gdzie mają przewagę: na laptopach, do szybkiego sprawdzenia nowego modelu i do prototypów.

Najważniejsza lekcja z praktyki: aktualizacja silnika to zmiana produkcyjna, nie formalność. Zdarzało się nam, że nowa wersja silnika, inny parser wywołań narzędzi albo włączone dekodowanie spekulatywne psuły wywołania narzędzi u agentów, choć zwykłe rozmowy działały poprawnie. Dlatego przed każdą zmianą wersji puszczamy zestaw testów na prawdziwych zadaniach agentów, a poprzedni obraz kontenera zostaje na serwerze do szybkiego powrotu.

Lista kontrolna wyboru

1. Ilu użytkowników naraz? Jeden lub kilka osób na własnym sprzęcie: Ollama albo llama.cpp. Firmowe API dla kilkunastu i więcej osób: vLLM albo SGLang.
2. Jaki sprzęt? Serwer z GPU NVIDIA lub AMD: vLLM albo SGLang. Laptop, Mac, CPU: Ollama albo llama.cpp.
3. Jak długie prompty? RAG i agenci z długim kontekstem potrzebują dobrego zarządzania cache KV i cache prefiksów.
4. Czy potrzebujesz agentów? Sprawdź parser wywołań narzędzi dla swojego modelu w obu silnikach i przetestuj go na swoich narzędziach.
5. Czy będą adaptery LoRA? Oba silniki obsługują wiele adapterów na jednym modelu bazowym.
6. vLLM czy SGLang? Zmierz oba na swoim ruchu i swoim modelu, zanim wybierzesz.
7. Kto to utrzyma? Wybierz silnik, który zespół umie aktualizować i diagnozować.
8. Co stoi przed modelem? Bramka z uwierzytelnianiem i logami, zanim pierwszy użytkownik dostanie adres.

Ile to wszystko kosztuje w porównaniu z API, liczymy w artykule ile kosztuje lokalny LLM. Jak projektujemy całą warstwę serwowania modeli, opisujemy na stronie Infrastruktura AI.

Źródła

Dokumentacja silników:

• vLLM: repozytorium i lista funkcji
• vLLM: OpenAI-Compatible Server
• vLLM: Automatic Prefix Caching
• vLLM: LoRA Adapters
• SGLang: repozytorium i lista funkcji
• SGLang: Hierarchical KV Caching (HiCache)
• SGLang: LoRA Serving
• SGLang: Quantization
• SGLang: Tool Parser
• SGLang: Anthropic-Compatible API
• Ollama: FAQ
• Ollama: OpenAI compatibility
• llama.cpp: README i README serwera
• Hugging Face: Text Generation Inference (tryb utrzymania)

Publikacje:

• Kwon i in.: Efficient Memory Management for Large Language Model Serving with PagedAttention (2023)
• Zheng i in.: SGLang, Efficient Execution of Structured Language Model Programs (2023)