Čím servovať LLM v produkcii: vLLM vs SGLang vs Ollama

Firma nasadí lokálny model cez Ollama, napíše interný chatbot, tím ho miluje. O tri mesiace pribúdajú ďalší používatelia, fronta rastie, odozva sa predlžuje z dvoch sekúnd na pätnásť. Niekto povie: "kupíme silnejší GPU." Kúpi. Odozva klesne na osem sekúnd. Problém nie je hardware — problém je serving stack, ktorý nebol navrhnutý pre produkčné záťaže.

Toto je scenár, ktorý vídame opakovane. Nie preto, že by tímy robili niečo hlúpe — Ollama je skvelý nástroj pre to, na čo bol navrhnutý. Problém nastáva, keď sa vývojový nástroj dostane do produkcie bez toho, aby niekto položil otázku: "čo vlastne od serving stacku potrebujeme?" Tento článok ponúka rozhodovacie kritériá namiesto paušálneho odporúčania — pretože správna voľba závisí od záťaže, tímu a infraštruktúry.

Prečo na serving stacku záleží viac, ako sa zdá

Serving framework nie je len "wrapper okolo modelu." Je to orchestrátor, ktorý rozhoduje o tom, ako sa paralelné požiadavky batujú, ako sa spravuje KV cache, a ako sa alokuje pamäť pri viacerých súbežných požiadavkách.

Klasický statický batching čaká, kým sa naplní dávka, a potom odošle všetky requesty naraz — model beží, výsledky sa vrátia, čaká sa na ďalšiu dávku. To je jednoduché, ale efektivita padá, keď mávate krátke aj dlhé requesty namiešané. Continuous batching (implementovaný vo vLLM, SGLang aj TGI) rieši tento problém inak: každý vygenerovaný token je príležitosť pridať do dávky nový request, ktorý práve prišiel. Výsledok je 2–3× vyšší throughput bez zmeny hardware.

Ďalší kritický rozmer je správa pamäte KV cache — medzivýsledkov pozornosti (attention), ktoré sa ukladajú pre každý token v kontexte. Naivná implementácia rezervuje pamäť pre maximálnu možnú dĺžku kontextu dopredu, aj keď väčšina requestov je oveľa kratšia. PagedAttention (vLLM) riešia tento problém stránkovaním KV cache podobne, ako OS stránkuje RAM — bez rezervácie vopred, s dynamickou alokáciou. Výsledok je dramatické zníženie fragmentácie: z typických 60–80 % plytvania na pod 4 %.

Tieto rozdiely sa v produkčnom prostredí s desiatkami súbežných requestov prejavia násobne viac, než ukazujú jednoduché benchmarky na jednom requeste.

vLLM: throughput ako primárna priorita

vLLM je de facto štandard pre produkčný LLM serving, keď je primárnou prioritou maximálny throughput na NVIDIA GPU. Vznikol na UC Berkeley, má najširší ekosystém integrácií a je aktívne vyvíjaný.

Kľúčové technické vlastnosti:

• PagedAttention — správa KV cache cez virtuálne stránky, dramaticky znižuje pamäťovú fragmentáciu a umožňuje vyšší paralelizmus
• Continuous batching — dynamické pridávanie requestov do aktuálnej dávky bez čakania
• OpenAI-kompatibilné API — migrácia z cloud API na self-hosted je väčšinou otázka zmeny URL a API kľúča
• Podpora NVIDIA, AMD (ROCm), Google TPU, Intel Gaudi
• Natívna podpora pre GPTQ, AWQ, FP8 a NVFP4 kvantizácie
• XGrammar backend pre štruktúrovaný výstup (JSON mode) s overhead-om pod 40 µs per token

Kedy vLLM jasne vyhráva:

Keď prevádzkujete API endpoint, ku ktorému pristupuje viac používateľov alebo procesov súbežne — interný firemný chatbot, RAG backend s vyšším volumom, API server pre production aplikáciu. Ak robíte benchmarky na single-request latencii, rozdiel oproti konkurencii je menší. Ale pri 8, 16 alebo 32 súbežných requestoch sa diferencia výrazne prejaví.

Na Blackwell GPU s NVFP4 kvantizáciou benchmarky ukazujú až ~16× vyšší throughput oproti Ollama pri rovnakom hardware — čo je rozdiel, ktorý zmení ekonomiku celého projektu.

Obmedzenia:

vLLM má strmšiu krivku učenia. Konfigurácia pre produkčné nasadenie vyžaduje rozumieť parametrom ako --tensor-parallel-size, --max-model-len, --gpu-memory-utilization. Pre tím bez LLM infraštruktúrnych skúseností je úvodný setup netriviálny. Pre čisto CPU alebo spotrebiteľský hardware bez NVIDIA GPU je ekosystém slabší.

SGLang: komplexné workloady a štruktúrovaný výstup

SGLang (Structured Generation Language) vznikol vo výskumnom prostredí so zameraním na iný class problémov: multi-turn konverzácie, agentické workloady s dlhými prefixmi a štruktúrovaný výstup (JSON schémy, gramatiky).

Kľúčová inovácia je RadixAttention — LRU cache KV hodnôt organizovaná do radixového stromu. Keď viac requestov zdieľa rovnaký prefix (napríklad rovnaký systémový prompt alebo rovnakú kontext dokumentu), SGLang tento prefix vypočíta raz a zdieľa ho medzi requestmi. V agentic RAG scenároch, kde každý request začína rovnakým dlhým kontextom dokumentu, to môže byť obrovský rozdiel.

Kde SGLang prekonáva vLLM:

Na prefix-heavy workloadoch benchmarky ukazujú ~29 % vyšší throughput na H100 a ~23 % nižší TTFT (Time to First Token) — 79 ms vs 103 ms. Toto nie sú zanedbateľné čísla pri interaktívnych aplikáciách, kde TTFT priamo ovplyvňuje percepciu rýchlosti.

Pre štruktúrovanú dekódovanie (JSON mode, gramatiky) je SGLang rýchlejší: constraintovaná dekódovanie prebieha ~3× rýchlejšie oproti starším implementáciám, pretože kompilácia gramatiky prebieha efektívnejšie.

Typické use casy, kde SGLang svieti:

• Multi-turn agentické workloady, kde každé kolo zdieľa dlhý históriový prefix
• Batch inference nad veľkým korpusom dokumentov s rovnakým systémovým promptom
• Aplikácie s intenzívnym JSON výstupom (extrakcia štruktúrovaných dát, klasifikácia)
• RAG pipelines kde sa rovnaký dokument pýta viac krát v jednej relácii

Obmedzenia:

SGLang má o niečo menší ekosystém ako vLLM a community je menšia, čo sa prejavuje v rýchlosti opravy okrajových bugov a dostupnosti dokumentácie. Pre štandardné inference workloady bez prefixových optimalizácií je rozdiel voči vLLM menší a voľba závisí skôr od preferencie tímu.

Ollama: developer experience na prvom mieste

Ollama je iná kategória nástroja. Nie je to produkčný serving framework — je to vývojársky desktop nástroj, ktorý robí jednu vec výborne: umožní vám spustiť lokálny model za päť minút, bez konfigurácie, na akomkoľvek hardware vrátane Mac, Linux a Windows.

Pod kapotou beží llama.cpp, ktorý je optimalizovaný pre CPU inferenciu a efektívnu prácu s GGUF kvantizovanými modelmi. Pre single-user experimentovanie a vývoj je toto dokonalý stack.

Kde Ollama dáva zmysel:

• Developer desktop — lokálne experimenty, prototypovanie, testovanie modelov
• Single-user interné nástroje s nízkou záťažou (jeden až dvaja súbežní používatelia)
• Tímy bez DevOps skúseností, ktoré potrebujú niečo funkčné rýchlo
• Mac alebo Windows prostredí, kde vLLM/SGLang nemajú natívnu GPU podporu (alebo je obmedzená)
• On-device nasadenie na laptopoch vývojárov

Prečo Ollama nestačí pre produkciu:

llama.cpp, ktorý beží pod Ollama, nie je navrhnutý pre concurrent requests. Keď príde 8 paralelných requestov, fronta sa spracúva sériovo — bez continuous batching-u. Benchmarky konzistentne ukazujú, že na rovnakom hardware je vLLM pri 8 súbežných requestoch ~2,3× rýchlejší. Pri 16 requestoch je rozdiel ešte väčší.

Toto nie je bug Ollama — je to dôsledok dizajnových rozhodnutí, ktoré uprednostňujú jednoduchosť a kompatibilitu pred throughput-om. Pre developer desktop je to správny trade-off. Pre produkčný endpoint s desiatkimi používateľmi je to problém.

Rozhodovanie podľa záťaže a tímu

Namiesto paušálneho odporúčania ponúkame rozhodovaciu maticu:

Malý tím (2–5 ľudí), začiatky s lokálnymi LLM, experimentovanie: Začnite s Ollama. Naučíte sa prácu s modelmi bez infraštruktúrnej záťaže. Keď narazíte na výkonnostné limity (a narazíte), bude jasné, prečo treba migrovať.

Produkčný API endpoint s viacerými súbežnými používateľmi, NVIDIA GPU: vLLM je predvolená voľba. Najširší ekosystém, najlepšia dokumentácia, OpenAI-kompatibilné API. Ak tím nemá LLM infraštruktúrne skúsenosti, ráta s tým, že setup zaberie dni, nie hodiny.

Agentické aplikácie, RAG s dlhými opakujúcimi sa prefixmi, intenzívny JSON výstup: Zvážte SGLang — RadixAttention vám ušetrí GPU pamäť a latenciu pri prefix-heavy workloadoch. Pre tímy, ktoré už nasadili vLLM a funguje, nie je dôvod migrovať len pre marginálne zlepšenie. SGLang je relevantný vtedy, keď viete, že váš workload je prefix-heavy.

NVIDIA Blackwell (GB200/B200), maximálny výkon: vLLM alebo TensorRT-LLM — oba sú optimalizované pre NVFP4 kvantizáciu na Blackwell GPU. TensorRT-LLM má vyšší peak výkon, ale výrazne vyššiu zložitosť setupu a operácií.

Regulované prostredie, air-gapped sieť, žiadne cloud závislosti: Všetky tri bežia plne offline. Pre produkčné nasadenie v regulovanom prostredí odporúčame vLLM kvôli ekosystému a auditovateľnosti. Viac o špecifikách regulovaných nasadení v článku On-prem LLM pre regulované odvetvia.

Čo serving stack nie je: odlíšenie od kvantizácie a GPU sizing

Keď firmy začínajú riešiť "ako nasadiť LLM," tri témy sa pravidelne miešajú dokopy: serving stack, kvantizácia a GPU sizing. Sú to separátne rozhodnutia s rôznou prioritou.

Kvantizácia je rozhodnutie o numerickej presnosti váh modelu (FP16 vs Q8 vs Q4 vs GPTQ/AWQ). Ovplyvňuje veľkosť modelu v pamäti a rýchlosť inferencie pri prijateľnej strate kvality. Q4_K_M je do ~5–8 % od FP16 na väčšine benchmarkov — rozdiel, ktorý pri väčšine produkčných use casov nie je pozorovateľný. Kvantizácia je ortogonálna voči výberu serving stacku: môžete spúšťať kvantizovaný model cez vLLM aj cez Ollama. Hlbšie o formátoch v článku Kvantizácia LLM (GGUF, AWQ, GPTQ).

GPU sizing je rozhodnutie o tom, koľko VRAM (a koľko GPU) potrebujete pre daný model a záťaž. Toto je separátna kalkulácia: VRAM pre váhy modelu + KV cache pre predpokladaný počet súbežných requestov × dĺžku kontextu. Zlý serving stack na správnom hardware stále nebude výkonný; správny serving stack na podhodnotenom hardware tiež nie. Viac o konkrétnych VRAM kalkuláciách v článku Aká GPU na inferenciu LLM.

Poradie rozhodnutí v praxi: najprv model (veľkosť, schopnosti), potom kvantizácia (zmenší pamäťové nároky), potom GPU sizing (koľko VRAM treba), nakoniec serving stack (ako sa obsluží záťaž). Veľa tímov robí to v opačnom poradí a potom sa čudujú, prečo optimalizácia nestačí.

KV cache a dlhý kontext: skrytá pamäťová záťaž

Jedno číslo, ktoré sa pri porovnávaní serving stackov podceňuje: KV cache rastie lineárne s dĺžkou kontextu. Pre 70B model pri 128K kontexte môže samotná KV cache zabrať okolo 40 GB — navyše k váham modelu. Pre štyri paralelné requesty s takýmto kontextom je to ~160 GB navyše.

Moderné modely s Grouped Query Attention (GQA) túto záťaž dramaticky znižujú oproti klasickému multi-head attention — väčšina aktuálnych modelov (Llama 4, Qwen 3, Mistral Large) GQA má. Ďalšia optimalizácia je KV cache kvantizácia na INT8/FP8, ktorá zmenší jej veľkosť na polovicu s minimálnou stratou kvality.

Pre workloady s dlhým kontextom — napríklad spracovanie dlhých priemyselných dokumentov, viac kôl konverzácie v technickej podpore — je toto číslo kritické pri rozhodovaní o GPU konfigurácii. vLLM cez PagedAttention spravuje KV cache dynamicky a efektívnejšie ako naivná implementácia; SGLang cez RadixAttention ešte navyše zdieľa KV cache pre opakujúce sa prefixy.

Praktický dôsledok: "1M token context window" zákazníkovi znie skvele. V praxi si každý request s 1M tokenov žiada desiatky gigabajtov KV cache. Pre väčšinu produkčných use casov je RAG ekonomicky efektívnejší ako plnenie celého dokumentu do kontextu — aj keď model technicky dlhý kontext podporuje.

Monitoring a observability v produkcii

Akýkoľvek serving stack zvolíte, produkčné nasadenie bez monitoringu je let naslepo. Tri metriky, ktoré sledovať od prvého dňa:

TTFT (Time to First Token) — ako dlho trvá, kým model vyprodukuje prvý token. Priamo ovplyvňuje percepciu rýchlosti pri interaktívnych aplikáciách. Pre konverzačné UI je TTFT pod 300–500 ms hranicou, kde používateľ cíti odozvu ako "okamžitú."

Throughput (tokeny/sekunda) — globálny aj per-request. Dôležité pre batch workloady a pri kapacitnom plánovaní.

Queue depth a latencia fronty — keď fronta rastie, je to signál buď na horizontálne škálovanie, alebo na revíziu batchovacej konfigurácie. Rastúca fronta pri stabilnom TTFT naznačuje, že problém je kapacita, nie serving efektivita.

vLLM aj SGLang exportujú Prometheus metriky natívne — Grafana dashboard je otázka hodiny práce. Pre tímy, ktoré riešia aj nákladovú stránku, zaujímavý prístup je LLM routing: posielanie jednoduchých requestov na menší, lacnejší model a komplexných na väčší. O tom podrobnejšie v článku LLM routing a cascading.

Časté otázky

Môžem Ollama použiť v produkcii, ak mám len jedného–dvoch súbežných používateľov?

Áno, pre naozaj malé záťaže — jeden tím, niekoľko ľudí, nízka frekvencia requestov — Ollama v produkcii funguje. Problém nastáva pri raste. Keď sa záťaž zdvojnásobí a Ollama nestačí, migrácia na vLLM nie je triviálna zmena: iný konfiguračný model, iná správa procesov, iné deployment patterny. Ak tušíte, že záťaž porastie, oplatí sa postaviť serving stack správne od začiatku.

Je vLLM alebo SGLang lepší pre RAG aplikácie?

Závisí od konkrétnej architektúry RAG. Ak každý request začína rovnakým systémovým promptom s malou variabilitou a krátke dokumenty sa menia pri každom requeste, vLLM a SGLang sú porovnateľné. Ak architektúra zdieľa dlhý kontext dokumentu naprieč viacerými requestmi v jednej relácii (napríklad analýza dlhého manuálu s viacerými otázkami), RadixAttention v SGLang môže ušetriť výraznú pamäť a latenciu. Pre viac o RAG architektúrach pozri Agentic RAG.

Ako sa líši vLLM od TensorRT-LLM?

TensorRT-LLM od NVIDIA dosahuje vyšší peak výkon na NVIDIA hardware (najmä Blackwell) vďaka fused kernelom a NVFP4 kvantizácii. Cena je výrazne vyššia zložitosť: modely treba kompilovať pred nasadením, pipeline je menej flexibilná, setup trvá dlhšie. vLLM je vo väčšine produkčných scenárov pragmatickejšia voľba — dostanete 80–90 % výkonu TensorRT-LLM pri zlomku operačnej zložitosti. TensorRT-LLM má zmysel pri extrémnych throughput požiadavkách alebo keď optimalizujete pre konkrétny model na konkrétnom hardware.

Fungujú tieto frameworky aj s kvantizovanými modelmi?

Áno, všetky tri podporujú kvantizované modely. vLLM a SGLang natívne spracujú AWQ a GPTQ formáty a majú FP8/NVFP4 podporu pre Blackwell GPU. Ollama pracuje primárne s GGUF formátom (llama.cpp). Pre produkčné nasadenie na NVIDIA GPU je AWQ alebo GPTQ zvyčajne výhodnejšie ako GGUF, pretože využíva optimalizované CUDA kernely. Pre cross-platform alebo CPU nasadenie je GGUF praktickejší.

Ako rýchlo zvládnem migrovať z Ollama na vLLM?

Ak vaša aplikácia komunikuje cez OpenAI-kompatibilné REST API (čo je prípad väčšiny Ollama nasadení), migrácia na vLLM je z pohľadu aplikačného kódu len zmena base URL a API kľúča. Väčšia práca je na strane infraštruktúry: deployment, monitoring, konfigurácia kapacity. Pre tím, ktorý to robí prvýkrát, počítajte s jedným až dvoma dňmi práce na funkčné produkčné nasadenie.

*V MP Industrial Solutions pomáhame firmám navrhnúť a nasadiť LLM infraštruktúru, ktorá zodpovedá reálnej záťaži a tímu — nie len demu. Ak riešite, ktorý serving stack je pre váš use case správny, alebo ak Ollama začína škrípať pod záťažou, radi to posúdime spolu.*