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

Hardware dorazí, ovladač funguje, nvidia-smi ukazuje každou kartu. Otázkou nyní je, co tokeny skutečně obsluhuje. Odpověď zní jeden ze čtyř nebo pěti otevřených obslužných zásobníků a špatná volba vás bude stát 2× nižší propustnost, 3× nižší latenci nebo tři dny ladění. Tento článek poctivě vybírá mezi nimi a prochází nastavením toho, který by si většina zákazníků Kentina měla vybrat jako první: vLLM v Dockeru s ověřeným obrazem NGC na koncovém bodě kompatibilním s OpenAI.

Publikum: někdo, kdo četl L02, může běžet docker run --gpus all nvidia-smia nyní je potřeba nanést další vrstvu.

Rozhodovací matice

Pět balíčků, které stojí za zvážení v květnu 2026. Všechno ostatní je buď obalem kolem jednoho z nich, nebo výzkumným projektem.

Stručná verze s omezeným názorem: pokud si nejste jisti, spusťte vLLM v kontejneru NGC. Pokud je vaše pracovní zátěž zaměřena na strukturovaný výstup nebo sdílené systémové výzvy, spusťte SGLang. Pokud používáte Jetson nebo jeden vývojový systém 4090, spusťte llama.cpp. Všechno ostatní je spíše zanedbatelný případ.

vLLM je výchozí – a důvod

vLLM (v0.20+ k květnu 2026) je nejvíce nasazený otevřený obslužný stack pro transformátorové LLM a VLM. Tři věci mu dávají navrch:

1. Kontinuální dávkování — příchozí požadavky se při dalším průchodu dopředu připojují k dávkové aplikaci. Využití GPU na koncovém bodě se smíšeným provozem se oproti naivní dávkové inferenci HuggingFace zvyšuje ze 40 % na 85 %+.
2. PagedAttention plus ukládání prefixů do mezipaměti — Mezipaměť KV je spravována v blocích pevné velikosti, jako jsou stránky virtuální paměti operačního systému. Dva požadavky sdílející systémový výzvu sdílejí bloky KV pro daný prefix. U pracovních postupů agentů se sdílenými systémovými výzvami o velikosti 2 KB je míra úspěšnosti v mezipaměti prefixů 80–95 %.
3. Blackwellova první jádra — FlashAttention 3, FP8 attention, MXFP4 quant pouze založený na vahách a CUTLASS-based matmul path target sm_120 (5090, RTX Pro 6000 Blackwell) a sm_100 (B200) nativně.

CUDA 13 je výchozí pro PyPI kola v0.20+ a vllm/vllm-openai:latest obrázek. Kola CUDA 12.8 se stále dodávají pro záložní verzi sm_120.

Instalace vLLM: pip vs. Docker

Dvě instalační cesty. Vyberte Docker, pokud nemáte konkrétní důvod, proč byste ho neměli používat.

Cesta A — pip ve venv (pouze 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 iteraci s příznaky enginu. Také propojuje interpret Pythonu, běhové prostředí CUDA a kompatibilitu mezi běhovým prostředím a ovladačem v jedné konfiguraci hostitele. Používejte ho pro vývoj, nikoli pro produkční prostředí.

Cesta B — Docker s imagí pro upstream (výchozí produkční nastavení)

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é štípou lidi, kteří je přeskočí:

• --ipc=host je vyžadováno pro více GPU. Workery vLLM komunikují přes sdílenou paměť; výchozí jmenný prostor Docker IPC je 64 MB a nemůže obsahovat vyrovnávací paměti NCCL.
• Připojte mezipaměť HuggingFace. Jinak každý docker run znovu stáhne 75 GB závaží.
• Připnout štítek pro produkci: vllm/vllm-openai:v0.20.2 ne :latest.

NGC nvcr.io/nvidia/vllm:25.09-py3 Dodává CUDA 13.0, testovanou verzi vLLM, NCCL a certifikát QA od NVIDIA. Větší (~12 GB), měsíc nebo dva zpoždění oproti upstreamu. Použijte ji, pokud na stejném hostiteli provozujete také TensorRT-LLM nebo Triton a chcete jeden CUDA/NCCL stack napříč všemi. Jinak je obraz Docker Hubu menší, novější a ekvivalentní.

Vlajky, na kterých skutečně záleží

vLLM zpřístupňuje zhruba dvě stě příznaků CLI. Většina z nich je situačních. Ty, kterých se budete dotýkat pokaždé:

--gpu-memory-utilization je nejvíce vyladěný příznak. vLLM jej používá k rozhodnutí, kolik VRAM předalokovat po načtení vah; zbytek se stane fondem mezipaměti KV. Příliš nízké → předčasné preempce KV při zátěži. Příliš vysoké → OOM při prvním požadavku s dlouhým kontextem. 0.92 je rozumný výchozí bod pro vyhrazený inferenční box. Pokud sdílíte GPU, snižte hodnotu na 0.85.

Tři betonové příkazy ke spuštění

Toto jsou konfigurace, které zákazníci Kentina skutečně používají. Všechny předpokládají CUDA 13.0, ovladač 570+, obraz Dockeru 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 při INT4, 4 karty s kapacitou 96 GB. Při TP=4 každá karta vidí 1/4 KV na požadavek, takže 32 K kontextu při 64 souběžných uživatelích se dobře vejde do rozpočtu. Očekávejte 40–60 tok/s na požadavek při nízké souběžnosti, celkově ~600–900 tok/s při 32 souběžných uživatelích.

Instrukce pro Llama 3.3 70B 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

Poznámka: TP=4 × PP=2, nikoli TP=8. Karty 5090 mají 32 GB; váhy FP8 pro 70B jsou ~75 GB, což je pohodlně méně než 128 GB na čtyřech kartách. Rozdělení pipeline zabraňuje nafouknutí all-reduce, které by stálo TP=8 oproti PCIe (viz K03, N03). TP=8 na PCIe se při souběžnosti nad 8 hůře škáluje než TP=4 × PP=2 s kontinuálním dávkováním.

Qwen 2.5 VL 32B na duálním 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

Dva 5090, váhy INT4 ~20 GB, místo pro vizuální enkodér + KV. Varianta 72B VL to nedělá. ne vejde se na duální 5090 i na INT4; na to použijte 4× 5090 nebo jednu Pro 6000. --limit-mm-per-prompt omezuje počet obrázků na požadavek – jeden požadavek s 20 obrázky může OOM kodéru vidění na 5090. Koncový bod je kompatibilní s OpenAI (POST /v1/chat/completions s image_url části).

SGLang — když jeho router porazí vLLM

SGLang se zaměřuje na RadixAttention: opětovné použití prefixové mezipaměti implementované jako radixový strom napříč požadavky, nikoli pouze na porovnávání podle rovnosti bloků. U úloh, kde většina požadavků sdílí dlouhé systémové výzvy, míra úspěšnosti překonává prefixovou mezipaměť vLLM. Veřejné benchmarky ukazují, že SGLang dosahuje ~16k tok/s oproti vLLM ~12k tok/s na H100 pro úlohy se sdílenými prefixy, s mnohem většími rozdíly u strukturovaného výstupního provozu.

Kde SGLang vítězí:

• Strukturovaný JSON přes xGrammar. Rychlejší a kompatibilnější s předpisy než omezené dekódování vLLM. Pro API pro výstup JSON s miliony požadavků je to důležité.
• DeepSeek-V3 a další velké MoE. Široká expertní paralelní a předfill/dekódovací disagregace byla dodána dříve; v multi-uzlovém měřítku stále ve vývoji.
• Pracovní postupy agentů se sdílenými systémovými výzvami. Koncové body RAG, kopiloti a systémové výzvy o velikosti 2–4 KB sdílené ve většině požadavků.

Kde vLLM vítězí: dávkové zpracování s unikátními výzvami (sbalení okraje RadixAttention), šířka modelu (více architektur ihned po instalaci) a doba do prvního spuštění koncového bodu.

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 zpřístupňuje koncový bod kompatibilní s OpenAI na svém vlastním portu (standardně 30000). Drop-in pro stejný klientský kód plus koncové body strukturovaného generování s nativním SGLangem. Upřímné doporučení: nejprve vyzkoušejte vLLM. Pokud je míra úspěšnosti vašeho sdíleného prefixu vyšší než ~60 % a záleží vám na latenci ocasu, znovu otestujte pomocí SGLangu a vyberte si vítězný port.

llama.cpp — když malé a singulární vítězství

llama.cpp je inference v C++ bez běhového prostředí Pythonu, bez závislosti na CUDA a s formátem váh GGUF, který do souboru sdružuje kvantizační metadata. Běží na CPU, jedné GPU, Macu řady M, Jetsonu nebo částečně na obou. Neprovádí tenzorové paralelní operace jako vLLM. Jeden model, jedna inferenční smyčka, rychle.

Když je llama.cpp správnou odpovědí:

• Jetson Orin. vLLM se na Jetsona moc nehodí, llama.cpp ano. Pro palubní model na Unitree G1 je to standardní řešení.
• Jeden vývojový box 5090 / 4090. Jeden vývojář iteruje, žádná souběžnost, nejrychlejší cesta instalace.
• Smíšené rozdělení CPU a GPU. 70B na 5090 (32 GB) se nevejde. S... -ngl 4040 z 80 vrstev jde na GPU, zbytek běží na CPU rychlostí přijatelnou pro jednoho uživatele.
• Vestavěný spotřebič. Žádný Docker, žádné problémy s nesouladem ovladačů, žádný Python.

Možnosti kvantizace GGUF v pořadí podle velikosti a kvality:

Q4_K_M je správná výchozí hodnota. Q5_K_M, pokud máte dostatečnou rezervu. Q8_0 pouze pro ověření „bez ztráty kvantů“. i-kvanty (IQ4_XS a další) jsou evolucí pro rok 2025/2026, kterou stojí za vyzkoušení, pokud chcete vměstnat 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 odečte tolik vrstev, kolik se vejde. Koncový bod je kompatibilní s OpenAI na adrese :8080/v1/chat/completionsPro víceuživatelské načítání je to špatný nástroj – použijte vLLM. Pro jednoho uživatele na jednom 5090 nebo Jetsonu je to ten správný.

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

TensorRT-LLM je optimalizační kompilátor od NVIDIA pro inferenci LLM. Předem sestaví model do enginu TensorRT, spojí jádra a vybere nejlepší rozvržení pro každou GPU. Obvykle se jedná o 10–25% zlepšení propustnosti a 15–30% zlepšení latence oproti vLLM na stejném hardwaru, více na H100/B200. Náklady jsou spojeny s krokem sestavení (minuty až hodiny na model + konfigurace GPU), enginy, které nejsou přenositelné mezi generacemi CUDA / ovladačů / GPU, a složitějším provozním příběhem. docker run.

Triton Inference Server je vrstva pro obsluhu více modelů, která hostuje enginy TensorRT-LLM (plus PyTorch, ONNX, TensorFlow, Python, vLLM-as-backend) na jednom serveru. Vzor úložiště modelů umožňuje načíst LLM A, LLM B, model vizuální inteligence, model ASR a pipeline Pythonu za jednou URL adresou s verzováním, A/B směrováním a ensemble grafy.

Vyplatí se to, když: obsluhujete více heterogenních modelů na jednom serveru; máte měsíce stabilní produkce se stabilním výběrem modelu; minimalizujete poslední kámen latence p99 na grafických procesorech Hopper/Blackwell pro datová centra.

Nevyplatí se to, když: si stále vybíráte model (každá výměna je sestavení nového enginu); používáte GPU pro spotřebitele/pracovní stanice (zrychlení TRT-LLM se oproti H100 zmenšuje a vLLM dodává model pro příští týden o šest týdnů dříve než TRT-LLM); jste malý tým bez provozní kapacity.

NVIDIA NIM – předpřipravená cesta

NIM (NVIDIA Inference Microservices) spojuje „Triton + TensorRT-LLM + optimální konfiguraci pro tento konkrétní model + podnikovou licenci“ do jednoho kontejneru. docker pull nvcr.io/nim/meta/llama-3.3-70b-instruct:latest, nastavte klíč NGC, spusťte a máte otestovaný koncový bod kompatibilní s OpenAI bez nutnosti vybírat kvantitativní nebo ladící příznaky.

Hodí se, když: jste si zakoupili NVIDIA AI Enterprise (nebo ji zákazník vyžaduje); chcete nejrychlejší dosažení dobrého koncového bodu (hodiny, ne dny); požadovaný model je v katalogu (Llama, Mistral, Mixtral, Gemma, Nemotron a rostoucí počet partnerů). Po skončení GTC 2026 bezplatná úroveň pokrývá až 16 GPU pro členy Developer Program – dostatek k otestování na většině instalací Kentina na jednom serveru; před vsazením si ověřte aktuální licenční podmínky.

Nepasuje, když: model není v katalogu (otevřené závaží dorazí s týdenním zpožděním); chcete ladit (NIM většinu knoflíků designově skrývá).

Reverzní proxy, autorizace, omezení rychlosti

Nezveřejňujte vLLM přímo na veřejném internetu. Před něj umístěte nginx (nebo Caddy, nebo 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 věci, ve kterých se lidé mýlí:

• proxy_buffering off je vyžadováno pro streamování odpovědí. Jinak se tokeny hromadí v proxy a klient uvidí jednorázové doručení.
• proxy_read_timeout Výchozí nastavení je 60 s. Dlouhé multimodální předfilly rychlostí 4 takty/s tuto dobu překračují. Nastavte na 5–10 minut.
• Jedno if blok je přesná shoda. Pro skutečné ověření použijte Lua, oauth2-proxy nebo bránu jako Kong.

monitorování

Dva zdroje metrik, dva cíle pro scrape.

• vLLM /metrics koncový bod. Kompatibilní s Prometheus, stejný port 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_secondsVyužití mezipaměti KV je to, co zachytí preempci dříve, než se sníží latence.
• Vývozce DCGM (nvcr.io/nvidia/k8s/dcgm-exporter, port 9400). Exportuje využití GPU SM, využití paměti, napájení, teplotu, šířku pásma PCIe a čítače ECC.

Oba do Prometheusu, oba do Grafany. První dashboard: requests-running, KV-cache-usage, GPU-util, GPU-temp, P95 TTFT, P95 TPOT. Pokud KV-cache-usage dosáhne saturace, zatímco requests-waiting stoupá, preempujete – dropujete. --max-num-seqs, vyzdvihnout --gpu-memory-utilizationnebo přidat repliku.

Modelka, rozcvička, chápu

První požadavek na čerstvě spuštěný vLLM je 5–30× pomalejší než ustálený stav. CUDA grafy jsou zachyceny pro každý dávkový tvar, prefix cache je prázdná, plánovač se kalibruje. Spusťte malý /v1/chat/completions požadavek při spuštění před připojením k vyrovnávači zátěže; bez něj první skutečný uživatel dostane 15sekundovou odpověď na modelu, který obvykle odpoví za 1. U modrozelených nasazení zahřejte novou repliku před vyprázdněním staré. Vynechání zahřívání je nejčastější příčinou situace, kdy „nasazení vypadalo dobře, ale uživatelé si deset minut stěžovali“.

Více modelů na jednom serveru

vLLM je v podstatě server s jedním modelem. Pokud jich potřebujete více, máte tři možnosti:

1. Jeden kontejner na model, různé porty. Každá z nich má vlastní VRAM. Modely 70B a 7B sdílejí box se 4 grafickými kartami přes CUDA_VISIBLE_DEVICES krájení a párování --gpu-memory-utilizationPlánování rozpočtu paměti je vaším úkolem.
2. Načíst na požádání. Front-end načítá/uvolňuje požadavky podle příchodu. Načítání trvá 30–120 s pro 70B; latence prvního zásahu je pro interaktivní použití nepřijatelná. Pro dávkové použití je to v pořádku.
3. Tritonův repozitář modelů. Triton vlastní životní cyklus N modelů na jednom serveru, směruje podle názvu modelu. Na co přejdete, když přestanete škálovat možnost 1.

Pro většinu instalací Kentina je správná možnost 1, dokud nemáte čtyři nebo více modelů, v takovém případě se vyplatí zaplatit provozní daň za Triton.

Upřímný pohled

Devadesát pět procent zákazníků Kentina by mělo začít s vllm/vllm-openai v Dockeru, za nginx, na jednom modelu, s Prometheus + DCGM exportérem, a první tři měsíce se nedívat na nic jiného. SGLang si zaslouží své místo pro strukturovaný výstup nebo provoz agentů se sdíleným prefixem ve velkém měřítku. llama.cpp si zaslouží své místo na Jetsonu, Macu nebo vývojářském boxu pro jednoho uživatele. Triton a TensorRT-LLM si zaslouží své místo, když máte měsíce stabilní produkce s více modely. NIM si zaslouží své místo, když je model v katalogu a je k dispozici licence.

Cena za příliš složitý začátek je reálná. Viděli jsme, jak laboratorní instalace strávily tři týdny tím, že Triton + TensorRT-LLM obsluhovaly jednu Llamu 70B, kterou by vLLM obsluhoval za dvacet minut. Vyberte si nejdříve jednoduchou věc. Složitost zvyšte, až budete mít důkazy, že ji potřebujete.

---

Toto je součást Kentino Wiki, referenční série o výpočetní technologii s využitím umělé inteligence, robotice a systémech, které je propojují. Komentáře a opravy jsou vítány na adrese info@kentino.com.