Nastavenie inferenčného servera: vLLM, llama.cpp, SGLang

Hardvér dorazí, ovládač funguje, nvidia-smi zobrazuje každú kartu. Otázkou teraz je, čo vlastne poskytuje tokeny. Odpoveďou je jeden zo štyroch alebo piatich otvorených obslužných zásobníkov a nesprávna voľba vás bude stáť 2× nižšiu priepustnosť, 3× latenciu alebo tri dni ladenia. Tento článok úprimne vyberá medzi nimi a ukazuje nastavenie toho, ktorý by si väčšina zákazníkov Kentina mala vybrať ako prvý: vLLM v Dockeri s obrazom overeným NGC na koncovom bode kompatibilnom s OpenAI.

Publikum: niekto, kto čítal L02, môže bežať docker run --gpus all nvidia-smia teraz potrebuje ďalšiu vrstvu.

Rozhodovacia matica

Päť stackov, ktoré stoja za zváženie v máji 2026. Všetko ostatné je buď obal okolo jedného z nich, alebo výskumný projekt.

Stručná verzia s tvrdým názorom: ak si nie ste istí, spustite vLLM v kontajneri NGC. Ak je vaša pracovná záťaž náročná na štruktúrovaný výstup alebo zdieľané systémové výzvy, spustite SGLang. Ak používate Jetson alebo jeden vývojový systém 4090, spustite llama.cpp. Všetko ostatné je len okrajový prípad.

vLLM je predvolená hodnota – a dôvod

vLLM (v0.20+ od mája 2026) je najpoužívanejší otvorený obslužný stack pre transformátorové LLM a VLM. Tri veci mu dávajú vedenie:

1. Kontinuálne dávkovanie — prichádzajúce požiadavky sa pri ďalšom prechode dopredu pridajú k prebiehajúcej dávke. Využitie GPU na koncovom bode so zmiešanou prevádzkou sa v porovnaní s naivnou dávkovou inferenciou HuggingFace zvýši zo 40 % na 85 %+.
2. PagedAttention plus ukladanie prefixov do vyrovnávacej pamäte — Vyrovnávacia pamäť KV je spravovaná v blokoch s pevnou veľkosťou, ako sú napríklad stránky virtuálnej pamäte operačného systému. Dve požiadavky zdieľajúce systémovú výzvu zdieľajú bloky KV pre danú predponu. Pre pracovné postupy agentov s 2 KB zdieľanými systémovými výzvami je miera úspešnosti vyrovnávacej pamäte prefixov 80 – 95 %.
3. Blackwellove prvé jadrá — Natívne funkcie FlashAttention 3, FP8 attention, MXFP4 weight-only quant a cieľová cesta matmul založená na CUTLASS sm_120 (5090, RTX Pro 6000 Blackwell) a sm_100 (B200).

CUDA 13 je predvolená pre kolesá PyPI v0.20+ a vllm/vllm-openai:latest obrázok. Kolesá CUDA 12.8 sa stále dodávajú ako záložný model sm_120.

Inštalácia vLLM: pip vs Docker

Dve inštalačné cesty. Vyberte si Docker, pokiaľ nemáte konkrétny dôvod, prečo ho neinštalovať.

Cesta A — pip vo venv (iba pre 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 rýchlejší pri iterovaní príznakov enginu. Taktiež pripína váš interpret Pythonu, runtime CUDA a kompatibilitu medzi runtime ovládačom a runtime k jednej konfigurácii hostiteľa. Používajte ho na vývoj, nie na produkciu.

Cesta B – Docker s obrazom z upstreamu (predvolená produkčná konfigurácia)

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, ktoré štípu ľudí, ktorí ich preskočia:

• --ipc=host je vyžadované pre viacero GPU. Pracovníci vLLM komunikujú cez zdieľanú pamäť; predvolený menný priestor Docker IPC je 64 MB a nemôže obsahovať vyrovnávacie pamäte NCCL.
• Pripojte vyrovnávaciu pamäť HuggingFace. Inak každý docker run znova stiahne 75 GB váh.
• Pripnúť značku pre produkciu: vllm/vllm-openai:v0.20.2 nie :latest.

NGC nvcr.io/nvidia/vllm:25.09-py3 dodáva CUDA 13.0, testovanú zostavu vLLM, NCCL a pečiatku QA od NVIDIA. Väčšia (~12 GB), mesiac alebo dva meškajúca oproti upstreamu. Použite ju, ak na tom istom hostiteľovi spúšťate aj TensorRT-LLM alebo Triton a chcete mať jeden CUDA/NCCL stack naprieč všetkými. Inak je obraz Docker Hub menší, novší a ekvivalentný.

Vlajky, na ktorých skutočne záleží

vLLM sprístupňuje približne dvesto CLI príznakov. Väčšina z nich je situačných. Tie, ktorých sa budete dotýkať zakaždým:

--gpu-memory-utilization je najvyladený príznak. vLLM ho používa na rozhodnutie, koľko VRAM sa má predalokovať po načítaní váh; zvyšok sa stane vyrovnávacou pamäťou KV. Príliš nízke → predčasné preempcie KV pri záťaži. Príliš vysoké → OOM pri prvej požiadavke s dlhým kontextom. 0.92 je rozumný východiskový bod pre vyhradený inferenčný box. Ak zdieľate GPU, znížte ho na 0.85.

Tri betónové príkazy na spustenie

Toto sú konfigurácie, ktoré zákazníci Kentina skutočne používajú. Všetky predpokladajú CUDA 13.0, ovládač 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

Približne 36 GB váh pri INT4, 4 karty s kapacitou 96 GB. Pri TP=4 každá karta vidí 1/4 KV na požiadavku, takže 32 K kontextu pri 64 súbežných používateľoch sa plne zmestí do rozpočtu. Pri nízkej súbežnosti sa očakáva 40 – 60 tok/s na požiadavku, celkovo ~600 – 900 tok/s pri 32 súbežných používateľoch.

Inštrukcia 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

Všimnite si TP=4 × PP=2, nie TP=8. Karty 5090 majú 32 GB; hmotnosti FP8 pre 70B sú ~75 GB, čo je pohodlne menej ako 128 GB na štyroch kartách. Rozdelenie kanála zabraňuje zväčšeniu pamäte TP=8 pri všetkých redukciách, ktoré by stálo viac ako PCIe (pozri K03, N03). TP=8 na PCIe sa pri súbežnom dávkovaní pri súbežnosti nad 8 zhoršuje ako TP=4 × PP=2.

Qwen 2.5 VL 32B na duálnom 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 obvody 5090, váhy INT4 s kapacitou ~20 GB, miesto pre obrazový enkodér + KV. Variant 72B VL to nerobí. nie zmestí sa na dva 5090 aj na INT4; na to použite 4× 5090 alebo jeden Pro 6000. --limit-mm-per-prompt obmedzenie počtu obrázkov na požiadavku – jedna požiadavka s 20 obrázkami môže OOM kodéra videnia na 5090. Koncový bod je kompatibilný s OpenAI (POST /v1/chat/completions s image_url časti).

SGLang — keď jeho router prekoná vLLM

Hlavnou myšlienkou SGLangu je RadixAttention: opätovné použitie prefixovej vyrovnávacej pamäte implementované ako radixový strom naprieč požiadavkami, nielen porovnávanie blokovej rovnosti. Pri úlohách, kde väčšina požiadaviek zdieľa dlhé systémové výzvy, miera úspešnosti prevyšuje prefixovú vyrovnávaciu pamäť vLLM. Verejné benchmarky ukazujú, že SGLang dosahuje ~16k tok/s oproti vLLM ~12k tok/s na H100 pri úlohách so zdieľanými prefixmi, s oveľa väčšími rozdielmi v prevádzke so štruktúrovaným výstupom.

Kde SGLang vyhráva:

• Štruktúrovaný JSON cez xGrammar. Rýchlejšie a kompatibilnejšie s predpismi ako obmedzené dekódovanie vLLM. Pre API JSON-out s miliónmi požiadaviek je to dôležité.
• DeepSeek-V3 a ďalšie veľké MoE. Široká expertná paralelná a preddopĺňacia/dekódovacia disagregácia bola dodaná skôr; stále vpredu v multi-uzlovom meradle.
• Pracovné postupy agentov so zdieľanými systémovými výzvami. Koncové body RAG, kopiloti, systémové výzvy s veľkosťou 2 – 4 KB zdieľané vo väčšine požiadaviek.

Kde vLLM vyhráva: dávkové spracovanie s jedinečnými výzvami (zbalenie okraja RadixAttention), šírka modelu (viac architektúr ihneď po vybalení) a čas do prvého spustenia 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 sprístupňuje koncový bod kompatibilný s OpenAI na svojom vlastnom porte (predvolene 30000). Pridáva rovnaký klientsky kód a koncové body štruktúrovaného generovania s natívnym SGLangom. Úprimné odporúčanie: najskôr vyskúšajte vLLM. Ak je miera úspešnosti vášho zdieľaného prefixu vyššia ako ~60 % a záleží vám na latencii chvosta, znova otestujte s SGLang a vyberte si ten, ktorý vyhrá.

llama.cpp — keď malé a jednotné vyhráva

llama.cpp je inferencia v C++ bez runtime prostredia Pythonu, bez závislosti od CUDA a s formátom váh GGUF, ktorý do súboru vkladá metadáta kvantizácie. Beží na CPU, jednej GPU, Mac radu M, Jetson alebo čiastočne na každej z nich. Nevykonáva tenzorové paralelné výpočty tak, ako to robí vLLM. Jeden model, jedna inferenčná slučka, rýchlo.

Keď je llama.cpp správna odpoveď:

• Jetson Orin. vLLM sa na Jetsona dobre neorientuje; llama.cpp áno. Pre palubný model na Unitree G1 je to štandardná odpoveď.
• Jeden vývojový box 5090 / 4090. Jeden vývojár iteruje, žiadna súbežnosť, najrýchlejšia cesta inštalácie.
• Zmiešané rozdelenie CPU a GPU. 70B na 5090 (32 GB) sa nehodí. S -ngl 4040 z 80 vrstiev ide na GPU, zvyšok beží na CPU rýchlosťou prijateľnou pre jedného používateľa.
• Vstavaný spotrebič. Žiadny Docker, žiadne problémy s nesúladom ovládačov, žiadny Python.

Možnosti kvantizácie GGUF v poradí podľa veľkosti a kvality:

Q4_K_M je správna predvolená hodnota. Q5_K_M, ak máte dostatok priestoru. Q8_0 iba na overenie „žiadnej straty kvantovania“. i-kvantovanie (IQ4_XS a kol.) je evolúcia pre roky 2025/2026, ktorá stojí za vyskúšanie pri vtesnávaní 70B na jednu 32 GB 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ží toľko vrstiev, koľko sa zmestí. Koncový bod je kompatibilný s OpenAI na adrese :8080/v1/chat/completionsPre viacpoužívateľské načítanie je to nesprávny nástroj – použite vLLM. Pre jedného používateľa na jednom 5090 alebo Jetsone je to ten správny.

TensorRT-LLM a Triton – ťažká možnosť

TensorRT-LLM je optimalizačný kompilátor od spoločnosti NVIDIA pre inferenciu LLM. Vopred vloží model do enginu TensorRT, spojí jadrá a vyberie najlepšie rozloženie pre každú GPU. Zvyčajne ide o 10 – 25 % zlepšenie priepustnosti a 15 – 30 % zlepšenie latencie oproti vLLM na rovnakom hardvéri, viac na H100/B200. Náklady predstavujú krok zostavenia (minúty až hodiny na model + konfigurácia GPU), enginy, ktoré nie sú prenosné medzi generáciami CUDA / ovládačov / GPU, a náročnejšia prevádzka. docker run.

Triton Inference Server je vrstva pre viacero modelov, ktorá hostuje enginy TensorRT-LLM (plus PyTorch, ONNX, TensorFlow, Python, vLLM-as-backend) na jednom serveri. Vzor úložiska modelov umožňuje načítať LLM A, LLM B, model vízie, model ASR a pipeline Pythonu za jednou URL adresou s verziovaním, A/B smerovaním a súborovými grafmi.

Stojí to za tie náklady, keď: obsluhuje viacero heterogénnych modelov na jednom serveri; mesiace stabilnej produkcie so stabilným výberom modelu; minimalizuje latenciu p99 na grafických procesoroch Hopper/Blackwell pre dátové centrá.

Neoplatí sa to, keď: si stále vyberáte model (každá výmena je zostavenie nového enginu); používate GPU pre spotrebiteľov/pracovné stanice (zrýchlenie TRT-LLM sa zmenšuje oproti H100 a vLLM vydá model na budúci týždeň šesť týždňov pred TRT-LLM); ste malý tím bez prevádzkovej kapacity.

NVIDIA NIM – predpripravená cesta

NIM (NVIDIA Inference Microservices) združuje „Triton + TensorRT-LLM + optimálnu konfiguráciu pre tento konkrétny model + podnikovú licenciu“ do jedného kontajnera. docker pull nvcr.io/nim/meta/llama-3.3-70b-instruct:latest, nastavte kľúč NGC, spustite a máte otestovaný koncový bod kompatibilný s OpenAI bez nutnosti vyberania kvantifikačných alebo ladiacimi príznakmi.

Vhodné, keď: ste si zakúpili NVIDIA AI Enterprise (alebo ju vyžaduje zákazník); chcete najrýchlejší čas do dosiahnutia známeho dobrého koncového bodu (hodiny, nie dni); model, ktorý chcete, je v katalógu (Llama, Mistral, Mixtral, Gemma, Nemotron a rastúca skupina partnerov). Po skončení GTC 2026 bezplatná úroveň pokrýva až 16 GPU pre členov Developer Program – dosť na vyskúšanie na väčšine inštalácií Kentina na jednom serveri; pred kúpou si overte aktuálne licenčné podmienky.

Nepasuje, keď: model nie je v katalógu (otvorené závažia prichádzajú s týždňovým oneskorením); chcete ho naladiť (NIM väčšinu gombíkov zámerne skrýva).

Reverzná proxy, autorizácia, obmedzenie rýchlosti

Nevystavujte vLLM priamo na verejnom internete. Predň umiestnite nginx (alebo Caddy, alebo Traefik). Minimálna konfigurácia 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;
    }
}

Tri veci, v ktorých sa ľudia mýlia:

• proxy_buffering off je povinný pre streamované odpovede. V opačnom prípade sa tokeny hromadia v proxy a klient uvidí jednorazové doručenie.
• proxy_read_timeout Predvolená hodnota je 60 s. Dlhé multimodálne predbežné naplnenia pri rýchlosti 4 takty/s túto hodnotu presiahnu. Nastavte ju na 5 – 10 minút.
• if blok je presná zhoda. Pre skutočné overenie použite Lua, oauth2-proxy alebo bránu ako Kong.

Monitorovanie

Dva zdroje metrík, dva ciele scrape.

• vLLM /metrics koncový bod. Kompatibilné s Prometheus, rovnaký port ako 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žitie vyrovnávacej pamäte KV je to, čo zachytí preempciu skôr, ako zníži latenciu.
• Vývozca DCGM (nvcr.io/nvidia/k8s/dcgm-exporter, port 9400). Exportuje údaje o využití GPU SM, využití pamäte, napájaní, teplote, šírke pásma PCIe a počítadlách ECC.

Oba do Prometheus, oba do Grafany. Prvý dashboard: requests-running, KV-cache-usage, GPU-util, GPU-temp, P95 TTFT, P95 TPOT. Ak KV-cache-usage dosiahne saturáciu, zatiaľ čo requests-waiting stúpa, preempujete – zrušíte. --max-num-seqs, zvýšiť --gpu-memory-utilizationalebo pridajte repliku.

Rozcvička modelu, chápem

Prvá požiadavka na čerstvo spustený vLLM je 5–30× pomalšia ako v ustálenom stave. Grafy CUDA sa zachytávajú pre každý dávkový tvar, vyrovnávacia pamäť prefixov je prázdna, plánovač sa kalibruje. Spustite malý /v1/chat/completions požiadavka pri spustení pred pripojením k vyrovnávaču záťaže; bez nej dostane prvý skutočný používateľ 15-sekundovú odpoveď na model, ktorý zvyčajne odpovie za 1. V prípade modrých/zelených nasadení zahrejte novú repliku pred vyprázdnením starej. Vynechanie zahrievania je najčastejšou príčinou problému „nasadenie vyzeralo dobre, ale používatelia sa desať minút sťažovali“.

Viacero modelov na jednom serveri

vLLM je v podstate server s jedným modelom. Tri možnosti, ak ich potrebujete viacero:

1. Jeden kontajner na model, rôzne porty. Každý má vlastnú VRAM. 70B a 7B zdieľajú 4-GPU skrinku cez... CUDA_VISIBLE_DEVICES krájanie a párovanie --gpu-memory-utilizationPlánovanie rozpočtu pamäte je vašou úlohou.
2. Načítanie na požiadanie. Front-end načítava/uvoľňuje požiadavky podľa príchodu. Načítanie trvá 30 – 120 sekúnd pre 70B; latencia prvého zásahu je pre interaktívne použitie neprijateľná. Pre dávkové použitie je to v poriadku.
3. Tritonov repozitár modelov. Triton vlastní životný cyklus N modelov na jednom serveri, smeruje podľa názvu modelu. Na čo prejdete, keď sa prestane škálovať možnosť 1.

Pre väčšinu inštalácií Kentina je správna možnosť 1, až kým nemáte štyri alebo viac modelov, v takom prípade sa oplatí platiť prevádzkovú daň za Triton.

Úprimný pohľad

Deväťdesiatpäť percent zákazníkov spoločnosti Kentino by malo začať s vllm/vllm-openai v Dockeri, za nginxom, na jednom modeli, so scrapingom exportéra Prometheus + DCGM a prvé tri mesiace sa nepozerať na nič iné. SGLang si zaslúži svoje miesto pre štruktúrovaný výstup alebo prevádzku agentov so zdieľaným prefixom vo veľkom meradle. llama.cpp si zaslúži svoje miesto na Jetsone, Macu alebo vývojovom systéme pre jedného používateľa. Triton a TensorRT-LLM si zaslúžia svoje miesto, keď máte mesiace stabilnej produkcie s viacerými modelmi. NIM si zaslúži svoje miesto, keď je model v katalógu a licencia je k dispozícii.

Cena za príliš zložitý začiatok je reálna. Videli sme laboratórne inštalácie, ktoré strávili tri týždne inštaláciou Tritonu + TensorRT-LLM na obsluhu jedinej Llamy 70B, ktorú by vLLM obsluhoval za dvadsať minút. Najprv si vyberte jednoduchú vec. Zložitosť pridajte, keď máte dôkazy, že ju potrebujete.

---

Toto je súčasť Kentino Wiki, referenčnej série o umelej inteligencii, robotike a systémoch, ktoré ich spájajú. Komentáre a opravy sú vítané na info@kentino.com.