Czym serwować LLM w produkcji: vLLM vs SGLang vs Ollama

Firma wdraża lokalny model przez Ollama, pisze wewnętrzny chatbot, zespół go uwielbia. Po trzech miesiącach przybywa kolejnych użytkowników, kolejka rośnie, czas odpowiedzi wydłuża się z dwóch sekund do piętnastu. Ktoś mówi: „kupmy mocniejsze GPU." Kupują. Czas odpowiedzi spada do ośmiu sekund. Problem nie leży w sprzęcie — problem tkwi w serving stacku, który nie był zaprojektowany do produkcyjnych obciążeń.

To scenariusz, który widzimy wielokrotnie. Nie dlatego, że zespoły robią coś głupiego — Ollama jest świetnym narzędziem do tego, do czego zostało zaprojektowane. Problem pojawia się, gdy narzędzie developerskie trafia do produkcji, zanim ktoś zada pytanie: „czego właściwie potrzebujemy od serving stacku?" Ten artykuł oferuje kryteria decyzyjne zamiast pauszalnej rekomendacji — bo właściwy wybór zależy od obciążenia, zespołu i infrastruktury.

Dlaczego serving stack ma większe znaczenie, niż się wydaje

Framework serwujący to nie tylko „wrapper wokół modelu." To orchestrator, który decyduje o tym, jak równoległe żądania są grupowane w batche, jak zarządzana jest pamięć podręczna KV cache i jak przydzielana jest pamięć przy wielu jednoczesnych żądaniach.

Klasyczny statyczny batching czeka, aż zbierze się pełna paczka, po czym wysyła wszystkie requesty naraz — model pracuje, wyniki wracają, system czeka na kolejną paczkę. To proste, ale wydajność spada, gdy requesty krótkie i długie przeplatają się ze sobą. Continuous batching (zaimplementowany w vLLM, SGLang i TGI) rozwiązuje ten problem inaczej: każdy wygenerowany token to okazja do dodania do paczki nowego żądania, które właśnie dotarło. Wynik to 2–3× wyższy throughput bez zmiany sprzętu.

Kolejny krytyczny wymiar to zarządzanie pamięcią KV cache — pośrednimi wynikami uwagi (attention), które są zapisywane dla każdego tokenu w kontekście. Naiwna implementacja rezerwuje pamięć dla maksymalnej możliwej długości kontekstu z góry, nawet gdy większość requestów jest znacznie krótsza. PagedAttention (vLLM) rozwiązuje ten problem przez stronicowanie KV cache analogicznie do tego, jak system operacyjny stronicuje RAM — bez rezerwacji z góry, z dynamiczną alokacją. Efektem jest dramatyczne zmniejszenie fragmentacji: z typowych 60–80% marnotrawstwa do poniżej 4%.

Te różnice w środowisku produkcyjnym z dziesiątkami jednoczesnych requestów ujawniają się wielokrotnie silniej niż wskazują proste benchmarki na jednym żądaniu.

vLLM: throughput jako priorytet nadrzędny

vLLM to de facto standard dla produkcyjnego serwowania LLM, gdy priorytetem jest maksymalny throughput na GPU NVIDIA. Powstał na UC Berkeley, ma najszerszy ekosystem integracji i jest aktywnie rozwijany.

Kluczowe właściwości techniczne:

• PagedAttention — zarządzanie KV cache przez wirtualne strony, drastycznie redukuje fragmentację pamięci i umożliwia wyższy poziom równoległości
• Continuous batching — dynamiczne dodawanie requestów do aktualnej paczki bez oczekiwania
• API kompatybilne z OpenAI — migracja z cloud API na self-hosted to w większości przypadków kwestia zmiany URL i klucza API
• Obsługa GPU NVIDIA, AMD (ROCm), Google TPU, Intel Gaudi
• Natywne wsparcie kwantyzacji GPTQ, AWQ, FP8 i NVFP4
• Backend XGrammar dla ustrukturyzowanego wyjścia (tryb JSON) z narzutem poniżej 40 µs na token

Kiedy vLLM jednoznacznie wygrywa:

Gdy obsługujesz endpoint API, do którego jednocześnie sięga wielu użytkowników lub procesów — wewnętrzny chatbot firmowy, backend RAG z wyższym wolumenem, serwer API dla aplikacji produkcyjnej. Na benchmarkach latencji dla pojedynczego requestu różnica w stosunku do konkurencji jest mniejsza. Ale przy 8, 16 lub 32 jednoczesnych requestach dysproporcja jest wyraźna.

Na GPU Blackwell z kwantyzacją NVFP4 benchmarki pokazują nawet ~16× wyższy throughput w porównaniu z Ollama na tym samym sprzęcie — to różnica, która zmienia ekonomikę całego projektu.

Ograniczenia:

vLLM ma stromszą krzywą uczenia się. Konfiguracja do wdrożenia produkcyjnego wymaga rozumienia parametrów takich jak --tensor-parallel-size, --max-model-len, --gpu-memory-utilization. Dla zespołu bez doświadczenia w infrastrukturze LLM początkowy setup jest nietrywialny. W przypadku czystego CPU lub sprzętu konsumenckiego bez GPU NVIDIA ekosystem jest słabszy.

SGLang: złożone workloady i ustrukturyzowane wyjście

SGLang (Structured Generation Language) powstał w środowisku badawczym z myślą o innej klasie problemów: konwersacjach wieloturowych, workloadach agentycznych z długimi prefiksami i ustrukturyzowanym wyjściu (schematy JSON, gramatyki).

Kluczową innowacją jest RadixAttention — pamięć podręczna LRU wartości KV zorganizowana w drzewo radixowe. Gdy wiele requestów dzieli ten sam prefiks (na przykład ten sam prompt systemowy lub ten sam kontekst dokumentu), SGLang oblicza ten prefiks raz i udostępnia go między requestami. W scenariuszach agentic RAG, gdzie każdy request rozpoczyna się od tego samego długiego kontekstu dokumentu, może to mieć ogromne znaczenie.

Gdzie SGLang przewyższa vLLM:

Na workloadach intensywnych prefiksowo benchmarki wskazują ~29% wyższy throughput na H100 oraz ~23% niższy TTFT (Time to First Token) — 79 ms vs 103 ms. To nie są liczby do zignorowania w aplikacjach interaktywnych, gdzie TTFT bezpośrednio wpływa na postrzeganie szybkości.

W przypadku dekodowania ustrukturyzowanego (tryb JSON, gramatyki) SGLang jest szybszy: dekodowanie z ograniczeniami przebiega ~3× szybciej w porównaniu ze starszymi implementacjami, ponieważ kompilacja gramatyki odbywa się wydajniej.

Typowe przypadki użycia, gdzie SGLang błyszczy:

• Agentyczne workloady wieloturowe, gdzie każda runda dzieli długi prefiks historii
• Batch inference na dużym korpusie dokumentów z tym samym promptem systemowym
• Aplikacje z intensywnym wyjściem JSON (ekstrakcja danych strukturalnych, klasyfikacja)
• Pipeline RAG, gdzie ten sam dokument jest odpytywany wielokrotnie w jednej sesji

Ograniczenia:

SGLang ma nieco mniejszy ekosystem niż vLLM, a społeczność jest mniejsza, co przekłada się na tempo naprawy edge-case bugów i dostępność dokumentacji. Dla standardowych workloadów inference bez optymalizacji prefiksowych różnica w stosunku do vLLM jest mniejsza, a wybór zależy raczej od preferencji zespołu.

Ollama: doświadczenie dewelopera na pierwszym miejscu

Ollama to inna kategoria narzędzia. To nie jest produkcyjny framework serwujący — to deweloperskie narzędzie desktopowe, które robi jedną rzecz znakomicie: pozwala uruchomić lokalny model w pięć minut, bez konfiguracji, na dowolnym sprzęcie, w tym na Macu, Linuksie i Windows.

Pod maską działa llama.cpp, zoptymalizowany pod kątem inferencji CPU i efektywnej pracy z kwantyzowanymi modelami GGUF. Do eksperymentowania przez pojedynczego użytkownika i do pracy deweloperskiej to idealny stack.

Gdzie Ollama ma sens:

• Desktopy deweloperskie — lokalne eksperymenty, prototypowanie, testowanie modeli
• Wewnętrzne narzędzia dla jednego użytkownika z niskim obciążeniem (jeden–dwóch jednoczesnych użytkowników)
• Zespoły bez doświadczenia DevOps, które potrzebują czegoś działającego szybko
• Środowiska Mac lub Windows, gdzie vLLM/SGLang nie mają natywnego wsparcia GPU (lub jest ono ograniczone)
• Wdrożenia on-device na laptopach deweloperów

Dlaczego Ollama nie wystarcza do produkcji:

llama.cpp działający pod Ollama nie jest zaprojektowany do obsługi równoległych requestów. Gdy nadejdzie 8 jednoczesnych żądań, kolejka jest przetwarzana szeregowo — bez continuous batching. Benchmarki konsekwentnie pokazują, że na tym samym sprzęcie vLLM jest przy 8 jednoczesnych requestach ~2,3× szybszy. Przy 16 requestach różnica jest jeszcze większa.

To nie jest błąd Ollama — to konsekwencja decyzji projektowych, które przedkładają prostotę i kompatybilność nad throughput. Dla desktopa deweloperskiego to właściwy kompromis. Dla produkcyjnego endpointu z dziesiątkami użytkowników to problem.

Podejmowanie decyzji na podstawie obciążenia i zespołu

Zamiast pauszalnej rekomendacji proponujemy macierz decyzyjną:

Mały zespół (2–5 osób), początki z lokalnymi LLM, eksperymenty: Zacznij od Ollama. Nauczysz się pracy z modelami bez obciążenia infrastrukturalnego. Gdy trafisz na granice wydajności (a trafisz), będzie jasne, dlaczego trzeba migrować.

Produkcyjny endpoint API z wieloma jednoczesnym użytkownikami, GPU NVIDIA: vLLM to domyślny wybór. Najszerszy ekosystem, najlepsza dokumentacja, API kompatybilne z OpenAI. Jeśli zespół nie ma doświadczenia z infrastrukturą LLM, zakładaj, że setup zajmie dni, nie godziny.

Aplikacje agentyczne, RAG z długimi powtarzającymi się prefiksami, intensywne wyjście JSON: Rozważ SGLang — RadixAttention oszczędzi pamięć GPU i zmniejszy latencję przy workloadach intensywnych prefiksowo. Dla zespołów, które już wdrożyły vLLM i działa, nie ma powodu migrować tylko dla marginalnej poprawy. SGLang jest relewantny wtedy, gdy wiesz, że Twój workload jest prefix-heavy.

GPU NVIDIA Blackwell (GB200/B200), maksymalna wydajność: vLLM lub TensorRT-LLM — oba są zoptymalizowane pod kątem kwantyzacji NVFP4 na GPU Blackwell. TensorRT-LLM osiąga wyższy peak, ale znacznie wyższą złożoność setupu i operacji.

Środowisko regulowane, sieć air-gapped, brak zależności chmurowych: Wszystkie trzy działają w pełni offline. Dla produkcyjnych wdrożeń w środowiskach regulowanych rekomendujemy vLLM ze względu na ekosystem i audytowalność. Więcej o specyfice wdrożeń regulowanych w artykule On-prem LLM dla branż regulowanych.

Czym serving stack nie jest: odróżnienie od kwantyzacji i doboru GPU

Gdy firmy zaczynają rozwiązywać problem „jak wdrożyć LLM", trzy tematy regularnie mieszają się ze sobą: serving stack, kwantyzacja i dobór GPU. To odrębne decyzje o różnych priorytetach.

Kwantyzacja to decyzja o numerycznej precyzji wag modelu (FP16 vs Q8 vs Q4 vs GPTQ/AWQ). Wpływa na rozmiar modelu w pamięci i szybkość inferencji przy akceptowalnej utracie jakości. Q4_K_M jest w granicach ~5–8% od FP16 na większości benchmarków — różnica, która w większości produkcyjnych przypadków użycia jest niezauważalna. Kwantyzacja jest ortogonalna względem wyboru serving stacku: możesz uruchamiać skwantyzowany model zarówno przez vLLM, jak i przez Ollama. Więcej o formatach w artykule Kwantyzacja LLM (GGUF, AWQ, GPTQ).

Dobór GPU to decyzja o tym, ile VRAM (i ile GPU) potrzebujesz dla danego modelu i obciążenia. To odrębna kalkulacja: VRAM dla wag modelu + KV cache dla przewidywanej liczby jednoczesnych requestów × długość kontekstu. Zły serving stack na właściwym sprzęcie nadal nie będzie wydajny; właściwy serving stack na niedoszacowanym sprzęcie również nie. Więcej o konkretnych kalkulacjach VRAM w artykule Jakiego GPU do inferencji LLM.

Kolejność decyzji w praktyce: najpierw model (rozmiar, możliwości), następnie kwantyzacja (zmniejsza wymagania pamięciowe), potem dobór GPU (ile VRAM potrzeba), na końcu serving stack (jak obsłużyć obciążenie). Wiele zespołów robi to w odwrotnej kolejności, a potem dziwi się, że optymalizacje nie wystarczają.

KV cache i długi kontekst: ukryte obciążenie pamięciowe

Jedna liczba, która jest niedoceniana przy porównywaniu serving stacków: KV cache rośnie liniowo z długością kontekstu. Dla modelu 70B przy kontekście 128K sama KV cache może zajmować około 40 GB — ponad wagami modelu. Dla czterech równoległych requestów z takim kontekstem to ~160 GB ekstra.

Nowoczesne modele z Grouped Query Attention (GQA) drastycznie redukują to obciążenie w porównaniu z klasycznym multi-head attention — większość aktualnych modeli (Llama 4, Qwen 3, Mistral Large) ma GQA. Kolejna optymalizacja to kwantyzacja KV cache do INT8/FP8, która zmniejsza jej rozmiar o połowę przy minimalnej utracie jakości.

W przypadku workloadów z długim kontekstem — na przykład przetwarzanie długich dokumentów przemysłowych, wiele rund konwersacji w wsparciu technicznym — ta liczba jest krytyczna przy decyzjach o konfiguracji GPU. vLLM przez PagedAttention zarządza KV cache dynamicznie i wydajniej niż naiwna implementacja; SGLang przez RadixAttention dodatkowo dzieli KV cache dla powtarzających się prefiksów.

Praktyczny wniosek: „kontekstowe okno 1M tokenów" brzmi dla klienta świetnie. W praktyce każdy request z 1M tokenów żąda dziesiątek gigabajtów KV cache. Dla większości produkcyjnych przypadków użycia RAG jest ekonomicznie efektywniejszy niż ładowanie całego dokumentu do kontekstu — nawet jeśli model technicznie długi kontekst obsługuje.

Monitoring i observability w produkcji

Niezależnie od wybranego serving stacku, produkcyjne wdrożenie bez monitoringu to lot na ślepo. Trzy metryki do śledzenia od pierwszego dnia:

TTFT (Time to First Token) — ile czasu upływa, zanim model wyprodukuje pierwszy token. Bezpośrednio wpływa na postrzeganie szybkości w aplikacjach interaktywnych. Dla konwersacyjnych UI TTFT poniżej 300–500 ms to granica, przy której użytkownik odczuwa odpowiedź jako „natychmiastową."

Throughput (tokeny/sekundę) — globalny i per-request. Ważne dla workloadów wsadowych i przy planowaniu pojemności.

Głębokość kolejki i latencja kolejki — gdy kolejka rośnie, to sygnał albo do skalowania poziomego, albo do rewizji konfiguracji batchowania. Rosnąca kolejka przy stabilnym TTFT wskazuje, że problem leży w pojemności, nie w wydajności serwowania.

vLLM i SGLang eksportują metryki Prometheus natywnie — dashboard Grafana to kwestia godziny pracy. Dla zespołów, które rozwiązują również stronę kosztową, interesującym podejściem jest LLM routing: kierowanie prostych requestów do mniejszego, tańszego modelu, a złożonych do większego. Więcej na ten temat w artykule LLM routing i cascading.

Najczęstsze pytania

Czy mogę używać Ollama w produkcji, jeśli mam tylko jednego–dwóch jednoczesnych użytkowników?

Tak, przy naprawdę małych obciążeniach — jeden zespół, kilka osób, niska częstotliwość requestów — Ollama sprawdza się w produkcji. Problem pojawia się przy wzroście. Gdy obciążenie się podwoi i Ollama nie nadąża, migracja na vLLM nie jest trywialną zmianą: inny model konfiguracyjny, inne zarządzanie procesami, inne wzorce deployment. Jeśli spodziewasz się wzrostu obciążenia, opłaca się zbudować serving stack właściwie od początku.

Który jest lepszy do aplikacji RAG — vLLM czy SGLang?

Zależy od konkretnej architektury RAG. Jeśli każdy request zaczyna się od tego samego promptu systemowego z małą zmiennością, a krótkie dokumenty zmieniają się przy każdym żądaniu, vLLM i SGLang są porównywalne. Jeśli architektura dzieli długi kontekst dokumentu między wieloma requestami w jednej sesji (na przykład analiza długiego podręcznika z wieloma pytaniami), RadixAttention w SGLang może zaoszczędzić znaczną ilość pamięci i zmniejszyć latencję. Więcej o architekturach RAG w artykule Agentic RAG.

Czym vLLM różni się od TensorRT-LLM?

TensorRT-LLM od NVIDIA osiąga wyższy peak wydajności na sprzęcie NVIDIA (szczególnie Blackwell) dzięki fuzji kerneli i kwantyzacji NVFP4. Ceną jest znacznie wyższa złożoność: modele trzeba kompilować przed wdrożeniem, pipeline jest mniej elastyczny, setup trwa dłużej. vLLM jest w większości produkcyjnych scenariuszy bardziej pragmatycznym wyborem — dostajesz 80–90% wydajności TensorRT-LLM przy ułamku złożoności operacyjnej. TensorRT-LLM ma sens przy ekstremalnych wymaganiach throughputu lub gdy optymalizujesz konkretny model na konkretnym sprzęcie.

Czy te frameworki działają z kwantyzowanymi modelami?

Tak, wszystkie trzy obsługują kwantyzowane modele. vLLM i SGLang natywnie obsługują formaty AWQ i GPTQ oraz mają wsparcie FP8/NVFP4 dla GPU Blackwell. Ollama pracuje głównie z formatem GGUF (llama.cpp). Dla produkcyjnych wdrożeń na GPU NVIDIA AWQ lub GPTQ są zazwyczaj korzystniejsze niż GGUF, ponieważ korzystają ze zoptymalizowanych kerneli CUDA. Do wdrożeń cross-platform lub CPU GGUF jest praktyczniejszy.

Jak szybko mogę przeprowadzić migrację z Ollama na vLLM?

Jeśli Twoja aplikacja komunikuje się przez REST API kompatybilne z OpenAI (co dotyczy większości wdrożeń Ollama), migracja na vLLM z perspektywy kodu aplikacji to tylko zmiana base URL i klucza API. Większa praca czeka po stronie infrastruktury: deployment, monitoring, konfiguracja pojemności. Dla zespołu robiącego to po raz pierwszy, zakładaj jeden do dwóch dni pracy na funkcjonalne wdrożenie produkcyjne.

*W MP Industrial Solutions pomagamy firmom zaprojektować i wdrożyć infrastrukturę LLM dopasowaną do realnego obciążenia i zespołu — nie tylko do demo. Jeśli zastanawiasz się, który serving stack jest właściwy dla Twojego przypadku użycia, lub jeśli Ollama zaczyna zawodzić pod obciążeniem, chętnie ocenimy to razem.*