Nastavení inferenčního serveru: vLLM, llama.cpp, SGLang

Hardware dorazil, ovladač funguje, nvidia-smi vypisuje všechny karty. Teď je otázka, co bude vlastně servírovat tokeny. Odpovědí je jeden ze čtyř až pěti otevřených serving stacků a špatná volba Vás bude stát 2× propustnost, 3× latenci nebo tři dny ladění. Tento článek mezi nimi vybírá bez přikrašlování a provede Vás nastavením toho, po kterém by většina zákazníků Kentino měla sáhnout první: vLLM v Dockeru, s NGC validovaným image, na endpointu kompatibilním s OpenAI.

Pro koho to je: pro toho, kdo přečetl L02, umí spustit docker run --gpus all nvidia-smi a teď potřebuje o patro výš.

Rozhodovací matice

Pět stacků, které v květnu 2026 stojí za zvážení. Všechno ostatní je buď nadstavba nad některým z nich, nebo výzkumný projekt.

Názorová zkratka: pokud si nejste jistí, spusťte vLLM v NGC kontejneru. Pokud je Váš workload postavený na strukturovaném výstupu nebo sdílených systémových promptech, spusťte SGLang. Pokud jste na Jetsonu nebo na jedné 4090 ve vývojářském stroji, spusťte llama.cpp. Všechno ostatní je okrajový případ.

vLLM je výchozí volba — a proč

vLLM (v0.20+ ke květnu 2026) je nejnasazovanější otevřený serving stack pro transformerové LLM a VLM. Náskok mu dávají tři věci:

1. Continuous batching — příchozí požadavky se připojí k běžící dávce při dalším forward passu. Využití GPU na endpointu se smíšeným provozem jde ze 40 % na 85 %+ oproti naivní dávkované inferenci v HuggingFace.
2. PagedAttention plus prefix caching — KV cache se spravuje v blocích pevné velikosti jako stránky virtuální paměti OS. Dva požadavky sdílející systémový prompt sdílejí i KV bloky tohoto prefixu. U agentních workflow se systémovými prompty o 2 KB se úspěšnost prefix cache pohybuje na 80–95 %.
3. Jádra primárně pro Blackwell — FlashAttention 3, FP8 attention, MXFP4 kvantizace jen vah a matmul cesta postavená na CUTLASS cílí nativně na sm_120 (5090, RTX Pro 6000 Blackwell) a sm_100 (B200).

CUDA 13 je výchozí pro PyPI wheely verze v0.20+ i pro image vllm/vllm-openai:latest. Wheely pro CUDA 12.8 se stále dodávají jako záloha pro sm_120.

Instalace vLLM: pip vs. Docker

Dvě cesty instalace. Volte Docker, pokud nemáte konkrétní důvod to nedělat.

Cesta A — pip ve venv (pouze pro vývoj)

python3.12 -m venv ~/venvs/vllm && source ~/venvs/vllm/bin/activate
pip install --upgrade pip && pip install vllm   # CUDA 13.0 wheels by default

vllm serve meta-llama/Llama-3.3-70B-Instruct-FP8 --tensor-parallel-size 4 --port 8000

Pip funguje a je rychlejší pro iterování nad přepínači enginu. Zároveň Vám ale sváže interpret Pythonu, CUDA runtime a kompatibilitu ovladače s runtime do jediné konfigurace hostitele. Používejte ho pro vývoj, ne pro produkci.

Cesta B — Docker s upstream image (výchozí pro produkci)

docker run --gpus all --runtime nvidia \
  --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --tensor-parallel-size 4 \
  --gpu-memory-utilization 0.92 \
  --max-model-len 8192 \
  --enable-prefix-caching

Poznámky, které se vymstí každému, kdo je přeskočí:

• --ipc=host je u více GPU nutnost. Workery vLLM spolu komunikují přes sdílenou paměť; výchozí IPC namespace Dockeru má 64 MB a NCCL buffery se do něj nevejdou.
• Připojte cache HuggingFace. Jinak si každé docker run znovu stáhne 75 GB vah.
• V produkci zafixujte tag: vllm/vllm-openai:v0.20.2, ne :latest.

Image nvcr.io/nvidia/vllm:25.09-py3 od NGC přináší CUDA 13.0, otestovaný build vLLM, NCCL a QA razítko od NVIDIA. Je větší (~12 GB) a měsíc či dva pozadu za upstreamem. Sáhněte po něm, pokud na stejném hostiteli provozujete i TensorRT-LLM nebo Triton a chcete nad vším jeden CUDA/NCCL stack. Jinak je image z Docker Hubu menší, čerstvější a rovnocenný.

Přepínače, na kterých opravdu záleží

vLLM nabízí zhruba dvě stě přepínačů příkazové řádky. Většina z nich je situační. Ty, kterých se dotknete pokaždé:

--gpu-memory-utilization je nejčastěji laděný přepínač. vLLM podle něj rozhoduje, kolik VRAM si po načtení vah předalokuje; zbytek se stane poolem KV cache. Příliš nízko → předčasná preempce KV pod zátěží. Příliš vysoko → OOM při prvním požadavku s dlouhým kontextem. 0.92 je rozumný výchozí bod pro vyhrazený inferenční stroj. Snižte na 0.85, pokud GPU sdílíte.

Tři konkrétní spouštěcí příkazy

Tohle jsou konfigurace, které zákazníci Kentino reálně provozují. Všechny počítají s CUDA 13.0, ovladačem 570+, Docker image a --ipc=host.

Qwen 2.5 72B Instruct INT4 (AWQ) na 4× RTX Pro 6000 Blackwell

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-72B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 4 \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.92 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --port 8000

Zhruba 36 GB vah v INT4, 4× karta s 96 GB. Při TP=4 vidí každá karta 1/4 KV na požadavek, takže kontext 32 K při 64 souběžných uživatelích se do rozpočtu pohodlně vejde. Počítejte se 40–60 tok/s na požadavek při nízké souběžnosti a agregovaně ~600–900 tok/s při 32 souběžných.

Llama 3.3 70B Instruct FP8 na 8× RTX 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -e HUGGING_FACE_HUB_TOKEN=$HF_TOKEN \
  vllm/vllm-openai:v0.20.2 \
  --model meta-llama/Llama-3.3-70B-Instruct-FP8 \
  --quantization fp8 \
  --tensor-parallel-size 4 \
  --pipeline-parallel-size 2 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --max-num-seqs 64 \
  --swap-space 4 \
  --port 8000

Všimněte si TP=4 × PP=2, nikoli TP=8. Každá 5090 má 32 GB; váhy FP8 pro 70B mají ~75 GB, tedy pohodlně pod 128 GB na čtyřech kartách. Rozdělení do pipeline se vyhne nárůstu all-reduce, který by TP=8 přes PCIe stálo (viz K03, N03). TP=8 na PCIe škáluje hůř než TP=4 × PP=2 s continuous batchingem při souběžnosti nad 8.

Qwen 2.5 VL 32B na dvou 5090

docker run --gpus all --runtime nvidia --ipc=host \
  -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:v0.20.2 \
  --model Qwen/Qwen2.5-VL-32B-Instruct-AWQ \
  --quantization awq \
  --tensor-parallel-size 2 \
  --max-model-len 16384 \
  --limit-mm-per-prompt '{"image": 4, "video": 0}' \
  --gpu-memory-utilization 0.90 \
  --enable-prefix-caching \
  --port 8000

Dvě karty 5090, ~20 GB vah v INT4, prostor pro vision encoder + KV. Varianta 72B VL se na dvě 5090 nevejde ani v INT4; na to použijte 4× 5090 nebo jednu Pro 6000. --limit-mm-per-prompt omezuje počet obrázků na požadavek — jediný požadavek s 20 obrázky může na 5090 shodit vision encoder na OOM. Endpoint je kompatibilní s OpenAI (POST /v1/chat/completions s částmi image_url).

SGLang — kdy jeho router porazí vLLM

SGLang staví na RadixAttention: opakované využití prefix cache implementované jako radixový strom napříč požadavky, ne jen porovnávání shodných bloků. U workloadů, kde většina požadavků sdílí dlouhé systémové prompty, je úspěšnost vyšší než u prefix cache ve vLLM. Veřejné benchmarky ukazují SGLang na ~16k tok/s proti ~12k tok/s u vLLM na H100 u workloadů se sdíleným prefixem, s ještě většími rozdíly u provozu se strukturovaným výstupem.

Kde vítězí SGLang:

• Strukturovaný JSON přes xGrammar. Rychlejší a lépe dodržující schéma než constrained decoding ve vLLM. U API s výstupem v JSON a miliony požadavků to hraje roli.
• DeepSeek-V3 a další velké MoE. Široký expert-parallel a oddělení prefill/decode dorazily dřív; ve víceuzlovém měřítku si drží náskok.
• Agentní workflow se sdílenými systémovými prompty. RAG endpointy, copiloti, systémové prompty o 2–4 KB sdílené většinou požadavků.

Kde vítězí vLLM: dávkové zpracování s unikátními prompty (výhoda RadixAttention se vytrácí), šíře podpory modelů (více architektur rovnou z krabice) a čas k prvnímu běžícímu endpointu.

docker run --gpus all --runtime nvidia --ipc=host \
  -p 30000:30000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  lmsysorg/sglang:latest \
  python3 -m sglang.launch_server \
    --model-path Qwen/Qwen2.5-72B-Instruct-AWQ \
    --quantization awq \
    --tp 4 \
    --port 30000 \
    --host 0.0.0.0

SGLang vystavuje endpoint kompatibilní s OpenAI na vlastním portu (výchozí 30000). Pro stejný klientský kód jde o drop-in náhradu, plus nativní endpointy SGLang pro strukturovanou generaci. Upřímné doporučení: zkuste nejdřív vLLM. Pokud je Vaše úspěšnost sdíleného prefixu nad ~60 % a záleží Vám na tail latenci, přeměřte to se SGLang a vyberte, co vyjde lépe.

llama.cpp — kdy vyhraje malé a jedno

llama.cpp je inference v C++ bez Python runtime, bez závislosti na CUDA a s formátem vah GGUF, který nese metadata o kvantizaci přímo v souboru. Běží na CPU, na jednom GPU, na Macu s čipy řady M, na Jetsonu nebo částečně na každém z nich. Nedělá tensor parallel tak jako vLLM. Jeden model, jedna inferenční smyčka, rychle.

Kdy je llama.cpp správná odpověď:

• Jetson Orin. vLLM na Jetson pořádně necílí, llama.cpp ano. Pro model běžící přímo na Unitree G1 je to standardní odpověď.
• Jedna 5090 / 4090 ve vývojářském stroji. Jeden vývojář, který iteruje, žádná souběžnost, nejrychlejší instalace.
• Rozdělení mezi CPU a GPU. Model 70B se na 5090 (32 GB) nevejde. S -ngl 40 půjde 40 z 80 vrstev na GPU a zbytek poběží na CPU rychlostí, která je pro jednoho uživatele přijatelná.
• Vestavěné zařízení. Žádný Docker, žádné trápení s nesedícími ovladači, žádný Python.

Volby kvantizace GGUF, seřazené podle velikosti vs. kvality:

Q4_K_M je správná výchozí volba. Q5_K_M, pokud máte rezervu. Q8_0 jen pro ověření „žádná ztráta kvantizací“. I-kvantizace (IQ4_XS a spol.) jsou vývoj let 2025/2026 a stojí za vyzkoušení, když cpete 70B na jednu 32GB kartu.

git clone https://github.com/ggml-org/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON && cmake --build build --config Release -j

./build/bin/llama-server \
  --model models/qwen2.5-72b-instruct-q4_k_m.gguf \
  --n-gpu-layers 99 --ctx-size 32768 \
  --host 0.0.0.0 --port 8080 --api-key sk-localdev

-ngl 99 odloží na GPU tolik vrstev, kolik se vejde. Endpoint je kompatibilní s OpenAI na :8080/v1/chat/completions. Pro víceuživatelskou zátěž je to špatný nástroj — použijte vLLM. Pro jednoho uživatele na jedné 5090 nebo na Jetsonu je správný.

TensorRT-LLM a Triton — těžká varianta

TensorRT-LLM je optimalizující kompilátor NVIDIA pro inferenci LLM. Model předem zkompiluje do TensorRT enginu, fúzuje jádra a vybere nejlepší rozložení pro dané GPU. Typicky o 10–25 % vyšší propustnost a o 15–30 % nižší latence oproti vLLM na stejném hardwaru, na H100/B200 i více. Cenou je build krok (minuty až hodiny na model a konfiguraci GPU), enginy nepřenositelné mezi verzemi CUDA, ovladači a generacemi GPU a provoz náročnější než docker run.

Triton Inference Server je vrstva pro provoz více modelů, která hostuje enginy TensorRT-LLM (plus PyTorch, ONNX, TensorFlow, Python i vLLM jako backend) v jednom serveru. Vzor model repository Vám dovolí mít za jednou URL LLM A, LLM B, vizuální model, ASR model i Python pipeline, a to s verzováním, A/B směrováním a ensemble grafy.

Vyplatí se, když: na jednom serveru obsluhujete více různorodých modelů; čeká Vás měsíce ustáleného provozu se stabilní volbou modelu; chcete vymáčknout poslední kousek p99 latence na datacentrových GPU Hopper/Blackwell.

Nevyplatí se, když: model teprve vybíráte (každá výměna znamená nový build enginu); jste na spotřebních či workstation GPU (zrychlení TRT-LLM se oproti H100 smrskne a vLLM vydá model příštího týdne o šest týdnů dřív než TRT-LLM); jste malý tým bez kapacity na provoz.

NVIDIA NIM — předpřipravená cesta

NIM (NVIDIA Inference Microservices) balí „Triton + TensorRT-LLM + optimální konfiguraci pro konkrétní model + enterprise licenci“ do jednoho kontejneru. docker pull nvcr.io/nim/meta/llama-3.3-70b-instruct:latest, nastavíte NGC klíč, spustíte a máte otestovaný endpoint kompatibilní s OpenAI, aniž byste vybírali kvantizaci nebo ladili přepínače.

Sedne, když: máte koupené NVIDIA AI Enterprise (nebo to zákazník vyžaduje); chcete co nejrychleji ověřeně funkční endpoint (hodiny, ne dny); požadovaný model je v katalogu (Llama, Mistral, Mixtral, Gemma, Nemotron a rostoucí sada partnerských). Po GTC 2026 pokrývá bezplatná úroveň až 16 GPU pro členy Developer Programu — na většinu jednoserverových instalací Kentino to na vyzkoušení stačí; aktuální licenční podmínky si ale před sázkou na ně ověřte.

Nesedne, když: model v katalogu není (otevřené váhy přicházejí s týdny zpoždění); chcete ladit (NIM většinu knoflíků záměrně skrývá).

Reverzní proxy, autentizace, rate limiting

Nevystavujte vLLM přímo do veřejného internetu. Postavte před něj nginx (nebo Caddy či Traefik). Minimální konfigurace nginx:

upstream vllm_backend {
    server 127.0.0.1:8000;
    keepalive 32;
}

limit_req_zone $binary_remote_addr zone=vllm:10m rate=20r/s;

server {
    listen 443 ssl http2;
    server_name infer.example.com;

    ssl_certificate     /etc/letsencrypt/live/infer.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/infer.example.com/privkey.pem;

    location /v1/ {
        if ($http_authorization != "Bearer sk-yourlongrandomtoken") {
            return 401;
        }
        limit_req zone=vllm burst=40 nodelay;

        proxy_pass http://vllm_backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_buffering off;             # streaming SSE
        proxy_read_timeout 600s;
        chunked_transfer_encoding on;
    }
}

Tři body, které lidé dělají špatně:

• proxy_buffering off je nutné pro streamované odpovědi. Jinak se tokeny hromadí v proxy a klient dostane všechno najednou.
• proxy_read_timeout má výchozí hodnotu 60 s. Dlouhé multimodální prefilly při 4 tok/s ji snadno překročí. Nastavte 5–10 minut.
• Blok if porovnává na přesnou shodu. Pro skutečnou autentizaci použijte Lua, oauth2-proxy nebo bránu typu Kong.

Monitoring

Dva zdroje metrik, dva scrape targety.

• Endpoint /metrics ve vLLM. Kompatibilní s Prometheem, na stejném portu jako OpenAI API (:8000/metrics). Publikuje vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_seconds. Využití KV cache je ta metrika, která odhalí preempci dřív, než zabije latenci.
• DCGM exporter (nvcr.io/nvidia/k8s/dcgm-exporter, port 9400). Exportuje vytížení SM na GPU, vytížení paměti, příkon, teplotu, propustnost PCIe a čítače ECC.

Obojí do Promethea, obojí do Grafany. První dashboard: běžící požadavky, využití KV cache, vytížení GPU, teplota GPU, P95 TTFT, P95 TPOT. Pokud se využití KV cache zasytí a zároveň roste počet čekajících požadavků, dochází k preempci — snižte --max-num-seqs, zvyšte --gpu-memory-utilization nebo přidejte repliku.

Záludnost se zahřátím modelu

První požadavek na čerstvě nastartované vLLM je 5–30× pomalejší než ustálený stav. Zachytávají se CUDA grafy pro jednotlivé tvary dávek, prefix cache je prázdná, scheduler se kalibruje. Pošlete při startu malý požadavek na /v1/chat/completions ještě předtím, než se server připojí k load balanceru; bez toho dostane první skutečný uživatel patnáctisekundovou odpověď od modelu, který běžně odpovídá za sekundu. U blue/green nasazení zahřejte novou repliku dřív, než odpojíte starou. Vynechané zahřátí je zdaleka nejčastější příčina toho, že „nasazení vypadalo v pořádku, ale uživatelé si deset minut stěžovali“.

Více modelů na jednom serveru

vLLM je ze své podstaty server pro jeden model. Pokud potřebujete víc, máte tři možnosti:

1. Jeden kontejner na model, různé porty. Každý si drží vlastní VRAM. Model 70B a 7B se na stroji se 4 GPU podělí pomocí rozkrájení přes CUDA_VISIBLE_DEVICES a odpovídajícího --gpu-memory-utilization. Rozpočet paměti si musíte naplánovat sami.
2. Načítání na vyžádání. Front-end načítá a uvolňuje modely podle příchozích požadavků. Načtení 70B trvá 30–120 s; latence prvního zásahu je pro interaktivní použití nepřijatelná. Pro dávky v pořádku.
3. Model repository v Tritonu. Triton řídí životní cyklus N modelů v jednom serveru a směruje podle názvu modelu. Sem se posunete, až možnost 1 přestane stačit.

U většiny instalací Kentino je možnost 1 správná, dokud nemáte čtyři a více modelů; od té chvíle se provozní daň Tritonu vyplatí zaplatit.

Upřímný závěr

Devadesát pět procent zákazníků Kentino by mělo začít s vllm/vllm-openai v Dockeru, za nginxem, s jedním modelem a se scrapováním Prometheus + DCGM exporter — a první tři měsíce se po ničem jiném nedívat. SGLang si své místo zaslouží u strukturovaného výstupu nebo u agentního provozu se sdíleným prefixem ve velkém. llama.cpp si své místo zaslouží na Jetsonu, na Macu nebo na jednouživatelském vývojářském stroji. Triton a TensorRT-LLM si své místo zaslouží, až budete mít měsíce stabilní produkce s více modely. NIM si své místo zaslouží, když je model v katalogu a licence na stole.

Cena za zbytečně složitý start je reálná. Viděli jsme laboratorní instalace, které strávily tři týdny tím, aby Triton + TensorRT-LLM obsloužily jednu Llamu 70B, kterou by vLLM rozběhlo za dvacet minut. Zvolte nejdřív to jednoduché. Složitost přidávejte, až budete mít důkaz, že ji potřebujete.

---

Tohle je součást Kentino Wiki, referenční série o AI výpočtech, robotice a systémech, které je propojují. Komentáře a opravy uvítáme na info@kentino.com.