Lokálna prevádzka LLM už dávno nie je iba hračka pre experimenty. Firmy riešia interné chatboty, API pre aplikácie, automatizáciu podpory aj dávkové spracovanie textu. V tej chvíli ale nestačí vedieť, ako rýchlo model odpovie jednému používateľovi. Dôležité je, čo sa stane vo chvíli, kedy začne model obsluhovať 8, 16 alebo 32 aktívnych používateľov súčasne.
Práve tu je najväčší rozidiel medzi riešením, ktoré je príjemné na prvé spustenie, a riešením, ktoré zvládne reálnu produkčnú záťaž. Ollama je výborná pre rýchly lokálny štart, zatiaľ čo vLLM je navrhnuté ako inference engine pre vysoký výkon a škálovanie.
Ollama je jednoduchý runtime pre lokálne spsstenie modelov. Silnou stránkou je rýchle nasadenie, pripravené modely a možnosť prevádzky aj na slabšom hardware alebo iba na CPU. Pokiaľ si chcete model rýchlo vyskúšať, urobiť interný prototyp alebo lokálny experiment, je to veľmi pohodlná cesta.
vLLM naopak cieli na situácie, kde rozhoduje throughput, nízka latencia a obsluha väčšieho množstva požiadaviek. Nejde len o to, že odpoveď príde rýchlejšie. Ešte dôležitejšie je, že sa výkon pri viac užívateľoch nerozpadá tak rýchlo ako u jednodušších runtime riešení.
Rozdieľ vo filozofií je teda jasný: Ollama = jednoduchosť a flexibilita, vLLM = maximálne využitie GPU pre API a produkciu.
Všetky testy prebehli na rovnakom systéme s NVIDIA RTX PRO 6000 Blackwell a 96 GB VRAM. Vďaka tomu porovnávame správanie oboch riešení na identickom hardwary bez vplivu rozdielnej konfigurácie. Testovali sme rovnaké modely, rovnaký limit MAX_TOKENS = 2000 a rovnakú záťaž v podobe 1, 2, 4, 8, 16 a 32 aktívnych používateľov súčasne.
U Ollamy sme pri testovaní nastavili len 10000 tokenov contextu, aby sa všetky modely bezpečne vošli do pamäte aj pri väčšom počte paralelných požiadaviek. vLLM tento problém rieši výrazne elegantnejšie, pretože používa dynamickú alokáciu KV cache podľa aktuálnych potrieb konkrétneho requestu.
Inými slovami: benchmark neukazuje len hrubú rýchlosť jedného modelu, ale aj to, ako efektívne obe riešenia pracujú s dostupnou pamäťou a ako dobre si poradia s rastom záťaže na jednom GPU.
Benchmark bežal na jednom dlhom testovacom prompte, ktorý mal model donútiť generovať súvislú a dostatečne dlhú odpoveď. Prompt bol navrhnutý tak, aby vyžadoval minimálne 3000 tokenov výstupu, bol rozdelený do 10 sekcií a nútil model pokračovať bez predčasného ukončenia.
slovenčina 
čeština 
english You are in a benchmarking environment. Your goal is to generate a LONG, CONTINUOUS response of at least 3000 tokens.
Do NOT stop early. Do NOT summarize. Do NOT conclude until the minimum length is reached.
Write a highly detailed, exhaustive explanation of Artificial Intelligence.
STRICT RULES:
- The response MUST be at least 3000 tokens long.
- Divide the response into at least 10 sections.
- Each section must be at least 200–300 words.
- If you finish a section, immediately continue to the next.
- Do not produce a conclusion until the total length exceeds 3000 tokens.
- If you are about to stop, continue expanding with more detail, examples, and subtopics.
STRUCTURE:
1. Definition and history
2. Types of AI (narrow, general, superintelligence)
3. Machine learning foundations
4. Neural networks in depth
5. Training processes and optimization
6. Data and feature engineering
7. Real-world applications across industries
8. Limitations and challenges
9. Ethical considerations
10. Future of AI
IMPORTANT:
If the output is cut off due to limits, continue exactly where you left off when prompted.
Begin now.tokenov v prompte sme počítali pomocou jednoduchej aproximácie max(1, len(text) // 4). Implementovať samostatný tokenizer pre každý model by bolo pri porovnaní viacerých rôznych modelov zbytočne zložité a nepraktické. Pre účely benchmarku je táto aproximácia bezproblémová, pretože na všetky testované modely bola použitá úplne rovnaká metóda výpočtu, takže porovnanie zostáva férové.
>V praxi to znamená, že jeden token sme približne odhadovali ako štyri znaky textu. Nie je to presný tokenizer konkrétneho modelu, ale pre porovnanie viacerých systémov nad rovnakým zadaním je táto matematická skratka dostatočne konzistentná a dobre použiteľná.
Ešte pred začiatkom každého merania prebehol aj warmup. Každý model najprv vygeneroval WARMUP_TOKENS = 500 tokenov a až bezprostredne potom začal samotný benchmark. Vďaka tomu sú výsledky konzistentnejšie a menej skreslené prvotnou inicializáciou modelu alebo prostredia.
>Pre úplnosť je dobré doplniť aj konkrétne varianty modelov a kvantizácií. V prípade GPT OSS 120B sme pri vLLM použili openai/gpt-oss-120b vo variante MXFP4, zatiaľ čo v Ollame bežal model gpt-oss:120b s kvantizáciou Q4_K_M. Pre Gemma 3 27B sme pri vLLM testovali gaunernst/gemma-3-27b-it-int4-awq s kvantizáciou int4-awq, zatiaľ čo v Ollame bežal gemma3:27b opäť s kvantizáciou Q4_K_M.
Prvé porovnanie patrí modelu GPT OSS 120B. Ide o dostatočne veľký model na to, aby sa rozdiely v práci s GPU, plánovaní požiadaviek aj latencii prejavili veľmi výrazne. Práve tu je najlepšie vidieť, že medzi jednoduchým lokálnym runtime a produkčne orientovaným enginom existuje zásadný rozdiel.
TTFT je jedna z najdôležitejších metrík pre reálny používateľský dojem. Ak je vysoká, používateľ má pocit, že systém dlho čaká, aj keď následné generovanie môže byť rýchle.
Pri vLLM sa TTFT drží aj pri raste záťaže veľmi nízko. Pri jednom aktívnom používateľovi sme namerali približne 29 ms, pri 16 používateľoch 63 ms a dokonca aj pri 32 používateľoch len 67 ms. To je stále odozva, ktorá v API prevádzke pôsobí svižne.
Ollama začína už pri jednom používateľovi na 229 ms, pri 8 používateľoch je na 834 ms a pri 32 používateľoch stúpa na 2 931 ms. V praxi to znamená, že zatiaľ čo vLLM stále reaguje takmer okamžite, Ollama už pri vyššej záťaži pôsobí ako služba, ktorá pred odpoveďou dlho čaká.
Metrika TPS na používateľa ukazuje, ako sa mení kvalita obsluhy jednotlivých requestov so zvyšujúcou sa záťažou.
vLLM síce s rastom počtu používateľov logicky stráca časť výkonu na jedného klienta, ale zvyšný výkon na jedného klienta zostáva stále dobre využiteľný. Z približne 218 tokenov za sekundu pri jednom používateľovi sa dostáva na 53 tokenov za sekundu pri 32 používateľoch. To je stále hodnota, s ktorou sa dá prevádzkovať svižné API.
Ollama naopak klesá z 183 tokenov za sekundu na iba 20 tokenov za sekundu pri 32 aktívnych používateľoch. Rozdiel je teda znateľný nielen na celkovej priepustnosti, ale aj na tom, ako rýchlo sa generuje odpoveď pre každého jednotlivého klienta.
Celkový overall throughput najlepšie ukazuje, ako dobre je využité GPU ako celok.
Pri vLLM rastie celkový výkon veľmi presvedčivo: z približne 217 TPS pri jednom používateľovi až na 1 603 TPS pri 32 používateľoch. To znamená, že GPU je zaťažované efektívne a systém dokáže paralelné požiadavky skladať dohromady tak, aby z dostupného výkonu vyťažil maximum.
Ollama sa z 179 TPS dostane len na 588 TPS. Inými slovami, pri 32 aktívnych používateľoch dáva vLLM zhruba 2,7× vyšší celkový výkon. Pre produkčné API je to rozdiel, ktorý sa premietne do ceny za jeden obslúžený request aj do počtu používateľov, ktorých zvládnete obslúžiť na jednom GPU.
Otestujte výkon NVIDIA RTX PRO 6000 Blackwell pre vLLM, firemné AI API aj viac používateľov súčasne.
Bez investície do vlastného hardvéru si overíte, koľko výkonu skutočne dostanete z jedného GPU.
Druhý test ukazuje, že nejde len o špecifikum jedného veľkého modelu. Aj pri Gemma 3 27B je trend veľmi podobný. Menší model síce pracuje s inými absolútnymi číslami, ale rozdiel v tom, ako obe platformy škálujú s počtom používateľov, zostáva rovnako výrazný.
vLLM drží TTFT aj tu v desiatkach milisekúnd. Z hodnoty 38 ms pri jednom používateľovi rastie na 124 ms pri 32 používateľoch. To je nárast, ktorý je pri bežnom API použití stále veľmi dobre akceptovateľný.
Ollama ide z 212 ms na extrémnych 16 244 ms pri 32 aktívnych používateľoch. To už nie je len vyššia latencia, ale úplne iná používateľská skúsenosť. Vo chvíli, keď jeden request čaká na prvý token vyše 16 sekúnd, začína byť služba pre interaktívne použitie problematická.
vLLM klesá z 89 tokenov za sekundu na 52 tokenov za sekundu, čo je pri 32 používateľoch stále veľmi solídny výsledok. Znamená to, že aj pri vysokej súbežnosti si každý klient udrží rozumnú rýchlosť generovania.
Ollama spadne z 85 tokenov za sekundu na 23 tokenov za sekundu. Aj tu teda platí, že s rastúcim počtom aktívnych používateľov degraduje výrazne rýchlejšie a celkový dojem z odpovedí sa zhoršuje oveľa skôr.
Pri Gemma 3 27B dochádza k rovnakému efektu ako pri GPT OSS 120B. vLLM rastie z 89 TPS na 1 619 TPS, zatiaľ čo Ollama zostáva na 541 TPS. To znamená, že vLLM pri 32 používateľoch doručuje približne 3× vyšší celkový výkon.
Pre praktické nasadenie je to dôležité zistenie: nejde len o to, že vLLM zvláda obrie modely. Rovnaký princíp škálovania funguje aj pri menších modeloch, kde by niekto mohol čakať, že rozdiely budú menšie. Nie sú.
Zistite na vlastných dátach, aký rozdieľ urobí vLLM pri vyššej záťaži a viac používateľoch súčasne.
Naše GPU servery sú pripravené pre rýchle nasadenie aj reálné benchmarky.
Výsledok je konzistentný naprieč oboma modelmi. vLLM výrazne lepšie škáluje s počtom aktívnych používateľov, zatiaľ čo Ollama má pri vyššej záťaži výrazne horšiu latenciu aj nižší celkový výkon.
Na GPT OSS 120B je pri 32 používateľoch rozdiel zhruba 1 603 TPS vs 588 TPS. Pri Gemma 3 27B je to 1 619 TPS vs 541 TPS. V oboch prípadoch teda vLLM využije jedno GPU podstatne efektívnejšie. Ak prevádzkujete interný AI endpoint, firemného asistenta alebo verejné API, znamená to viac obslúžených používateľov na rovnakom hardvéri.
Rovnako zásadný je rozdiel v latencii Zatiaľ čo vLLM drží čas do prvého tokenu aj pri vysokej súbežnosti v desiatkach alebo nižších stovkách milisekúnd, Ollama ide pri vyššej záťaži do stoviek milisekúnd, sekúnd a v niektorých scenároch aj výrazne vyššie. V produkcii to znamená pomalšiu odozvu aplikácie, horší používateľský dojem a menšiu využiteľnosť GPU.
Hlavným dôvodom je architektúra. vLLM používa continuous batching, efektívne plánuje requesty a dynamicky prideľuje KV cache podľa skutočnej potreby jednotlivých používateľov. Vďaka tomu dokáže držať GPU vyťažené blízko maxima a zároveň dobre pracovať s viacerými paralelnými požiadavkami.
Ollama je navrhnutá skôr ako pohodlný lokálny runtime než ako inference engine pre vysoký paralelizmus. Výhodou sú GGUF modely a nízke nároky na hardvér, ale pri väčšom množstve súbežných requestov sa jej architektúra prejaví ako limitujúca. Jednoducho povedané: funguje výborne pre lokálnu prácu, ale menej presvedčivo pre multi-user produkciu.
Pokiaľ riešite lokálny vývoj, experimenty alebo slabší hardvér, dáva Ollama veľmi dobrý zmysel. Je rýchla na rozbehnutie, pohodlná pre prototypy a nevyžaduje tak výkonnú GPU ani robustnú infraštruktúru.
Ak však chcete prevádzkovať produkčné API, obslúžiť viac aktívnych používateľov súčasne a využiť GPU naozaj naplno, vLLM je výrazne lepšia voľba. Presne v takomto scenári sa ukazuje, že rozdiel medzi jednoduchým spustením a skutočne efektívnou inferenciou je zásadný.
Ollama znamená jednoduchosť, flexibilitu a nízku vstupnú bariéru. vLLM znamená výkon, škálovanie a výrazne lepšie využitie GPU.
Namerané dáta ukazujú, že akonáhle do hry vstúpi viac aktívnych používateľov súčasne, rozdiel medzi oboma prístupmi rýchlo narastie. vLLM si drží nízku latenciu, výrazne vyšší celkový throughput a lepšie škáluje naprieč modelmi. Ak teda chcete z GPU dostať maximum a obslúžiť viac používateľov súčasne, vLLM je jasná voľba – objednajte tu.
Napište nám a pripravíme vám vhodné riešenie pre rýchle nasadenie vLLM, veľkých jazykových modelov aj vlastného AI API.