Opsætning af en inferensserver: vLLM, llama.cpp, SGLang

Hardwaren ankommer, driveren arbejder, nvidia-smi viser hvert kort. Nu er spørgsmålet, hvad der rent faktisk serverer tokens. Svaret er en af ​​fire eller fem åbne serveringsstakke, og det forkerte valg vil koste dig 2x gennemløb, 3x latenstid eller tre dages fejlfinding. Denne artikel vælger ærligt mellem dem og gennemgår opsætningen af ​​den, de fleste Kentino-kunder bør vælge først: vLLM i Docker, med det NGC-validerede billede, på et OpenAI-kompatibelt endpoint.

Målgruppe: en person, der har læst L02, kan løbe docker run --gpus all nvidia-smi, og nu trænger det næste lag til.

Beslutningsmatricen

Fem stakke værd at overveje i maj 2026. Alt andet er enten en indpakning omkring en af ​​disse eller et forskningsprojekt.

Den korte, selvsikre version: Hvis du ikke er sikker, så kør vLLM i NGC-containeren. Hvis din arbejdsbyrde er stor på struktureret output eller delte systemprompter, så kør SGLang. Hvis du bruger en Jetson eller en enkelt 4090-udviklingsboks, så kør llama.cpp. Alt andet er et hjørnespark.

vLLM er standardindstillingen – og årsagen

vLLM (v0.20+ pr. maj 2026) er den mest anvendte open serving-stak til transformer LLM'er og VLM'er. Tre ting giver den føringen:

1. Kontinuerlig batching — indgående anmodninger slutter sig til en in-flight batch på den næste forward pass. GPU-udnyttelsen på et blandet trafik-slutpunkt går fra 40% til 85%+ i forhold til naiv batchbaseret HuggingFace-inferens.
2. PagedAttention plus præfiks-caching — KV-cache administreres i blokke med fast størrelse, f.eks. virtuelle hukommelsessider i operativsystemet. To anmodninger, der deler en systemprompt, deler KV-blokkene for det pågældende præfiks. For agentworkflows med 2 KB delte systemprompter ligger præfiks-cache-hitraten på 80-95 %.
3. Blackwell-første kerner — FlashAttention 3, FP8 attention, MXFP4 weight-only quant og det CUTLASS-baserede matmul-stimål sm_120 (5090, RTX Pro 6000 Blackwell) og sm_100 (B200) native.

CUDA 13 er standarden for v0.20+ PyPI-hjul og vllm/vllm-openai:latest billede. CUDA 12.8 hjul leveres stadig som sm_120 fallback.

Installation af vLLM: pip vs Docker

To installationsstier. Vælg Docker, medmindre du har en specifik grund til ikke at gøre det.

Sti A — pip i en venv (kun udvikling)

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 fungerer og er hurtigere til iterering på engine-flag. Det fastgør også din Python-fortolker, CUDA-runtime og driver-runtime-kompatibilitet til én værtkonfiguration. Brug det til udvikling; ikke til produktion.

Sti B — Docker med upstream-billedet (produktionsstandard)

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

Noter, der bider folk, der springer dem over:

• --ipc=host er påkrævet for multi-GPU. vLLM-arbejdere kommunikerer over delt hukommelse; standardnavneområdet for Docker IPC er 64 MB og kan ikke indeholde NCCL-bufferne.
• Monter HuggingFace-cachen. Ellers hver docker run downloader 75 GB vægte igen.
• Fastgør et tag til produktion: vllm/vllm-openai:v0.20.2 ikke :latest.

NGC'er nvcr.io/nvidia/vllm:25.09-py3 Leverer CUDA 13.0, en testet vLLM-build, NCCL og NVIDIAs QA-stempel. Større (~12 GB), en måned eller to bagud i forhold til upstream. Brug den, hvis du også kører TensorRT-LLM eller Triton på den samme vært og ønsker én CUDA/NCCL-stak på tværs af dem alle. Ellers er Docker Hub-billedet mindre, nyere og tilsvarende.

De flag, der rent faktisk betyder noget

vLLM eksponerer cirka to hundrede CLI-flag. De fleste er situationsbestemte. Dem du vil røre ved hver gang:

--gpu-memory-utilization er det mest indstillede flag. vLLM bruger det til at bestemme, hvor meget VRAM der skal forudallokeres efter indlæsning af vægte; den resterende mængde bliver KV-cachepuljen. For lav → for tidlig KV-forudindtagelse under belastning. For høj → OOM på den første langkontekstanmodning. 0.92 er et rimeligt udgangspunkt for en dedikeret inferensboks. Fald til 0.85, hvis du deler GPU'en.

Tre konkrete startkommandoer

Dette er de konfigurationer, som Kentinos kunder rent faktisk kører. Alle forudsætter CUDA 13.0, driver 570+, Docker-aftrykket og --ipc=host.

Qwen 2.5 72B Instruct INT4 (AWQ) på 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

Omtrent 36 GB vægt ved INT4, 4 × 96 GB kort. Ved TP=4 ser hvert kort 1/4 af KV pr. anmodning, så 32 K kontekst ved 64 samtidige brugere ligger godt inden for budgettet. Forvent 40-60 tok/s pr. anmodning ved lav samtidighed, samlet ~600-900 tok/s ved 32 samtidige.

Llama 3.3 70B Instruktion FP8 på 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

Bemærk TP=4 × PP=2, ikke TP=8. 5090'ere har 32 GB hver; FP8-vægte for 70B er ~75 GB, komfortabelt under 128 GB på fire kort. Pipeline-opdelingen undgår den reduktion af omkostningerne, som TP=8 ville medføre i forhold til PCIe (se K03 , N03 ). TP=8 på PCIe skalerer dårligere end TP=4 × PP=2 med kontinuerlig batching ved samtidighed over 8.

Qwen 2.5 VL 32B på dobbelt 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

To 5090'ere, ~20 GB INT4-vægte, plads til vision-encoder + KV. 72B VL-varianten gør det ikke passer på dobbelt 5090 selv ved INT4; brug 4× 5090 eller en enkelt Pro 6000 til det. --limit-mm-per-prompt begrænser billeder pr. anmodning — en enkelt anmodning med 20 billeder kan OOM-e vision-encoderen på en 5090. Endpointen er OpenAI-kompatibel (POST /v1/chat/completions med image_url dele).

SGLang — når dens router slår vLLM

SGLangs pitch er RadixAttention: genbrug af præfiks-cache implementeret som et radix-træ på tværs af anmodninger, ikke kun bloklighedsmatchning. For arbejdsbelastninger, hvor de fleste anmodninger deler lange systemprompter, slår hitraten vLLMs præfiks-cache. Offentlige benchmarks viser SGLang på ~16k tok/s vs. vLLM ~12k tok/s på H100 for arbejdsbelastninger med delte præfikser, med meget større huller i struktureret outputtrafik.

Hvor SGLang vinder:

• Struktureret JSON via xGrammar. Hurtigere og mere kompatibel end vLLM's begrænsede afkodning. For en JSON-out API ved millioner af anmodninger er dette vigtigt.
• DeepSeek-V3 og andre store MoE. Bred ekspert-parallel og præudfyldnings-/afkodningsopdeling blev leveret tidligere; stadig foran på multi-node-skala.
• Agentarbejdsgange med delte systemprompter. RAG-slutpunkter, copiloter, 2-4 KB systemprompter deles på tværs af de fleste anmodninger.

Hvor vLLM vinder: batchbehandling med unikke prompts (RadixAttentions kant kollapser), modelbredde (flere arkitekturer lige fra starten) og tid til første kørende slutpunkt.

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 eksponerer et OpenAI-kompatibelt endpoint på sin egen port (30000 som standard). Drop-in for den samme klientkode plus SGLang-native strukturerede generationsendpoints. Den ærlige anbefaling: prøv vLLM først. Hvis din hitrate for delte præfikser er over ~60%, og du er interesseret i haleforsinkelse, så test igen med SGLang og vælg den, der vinder.

llama.cpp — når små og entydige vindere

llama.cpp er en C++-inferens uden Python-runtime, ingen CUDA-afhængighed og et GGUF-vægtformat, der samler kvantiseringsmetadata i filen. Den kører på CPU, enkelt GPU, Mac M-serie, Jetson eller delvist på hver. Den udfører ikke tensorparallel på samme måde som vLLM gør. Én model, én inferensløjfe, hurtigt.

Når llama.cpp er det rigtige svar:

• Jetson Orin. vLLM er ikke god til at målrette Jetson; det gør llama.cpp. For en indbygget model på en Unitree G1 er dette standardsvaret.
• Enkelt 5090 / 4090 udviklingsboks. Én udvikler itererer, ingen samtidighed, hurtigste installationssti.
• Blandet CPU+GPU-opdeling. En 70B på en 5090 (32 GB) passer ikke. Med -ngl 40, 40 ud af 80 lag går til GPU'en, resten kører på CPU'en med en hastighed, der er acceptabel for enkeltbrugere.
• Indbygget apparat. Ingen Docker, ingen problemer med drivermatchning, ingen Python.

GGUF-kvantiseringsvalg, i rækkefølge efter størrelse vs. kvalitet:

Q4_K_M er den rigtige standard. Q5_K_M hvis du har pladsen. Q8_0 kun for at bekræfte "intet kvantitetstab". I-kvanterne (IQ4_XS et al.) er en 2025/2026-udvikling, der er værd at prøve, når man presser en 70B ned på et enkelt 32 GB-kort.

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 aflaster så mange lag som der er plads til. Endpointen er OpenAI-kompatibel kl. :8080/v1/chat/completionsTil flerbrugerbelastning er dette det forkerte værktøj — brug vLLM. Til én bruger på en 5090 eller en Jetson er det det rigtige.

TensorRT-LLM og Triton — den tunge mulighed

TensorRT-LLM er NVIDIAs optimerende compiler til LLM-inferens. Den bygger en model ind i en TensorRT-motor på forhånd, fusionerer kerner og vælger det bedste layout pr. GPU. Typisk 10-25% gennemløb og 15-30% latenstidsforbedring i forhold til vLLM på den samme hardware, mere på H100/B200. Omkostningerne er et byggetrin (minutter til timer pr. model + GPU-konfiguration), motorer, der ikke er bærbare på tværs af CUDA/driver/GPU-generationer, og en operationel historie, der er sværere end docker run.

Triton Inference Server er det multimodel-serverlag, der hoster TensorRT-LLM-motorer (plus PyTorch, ONNX, TensorFlow, Python, vLLM-as-backend) på én server. Modelrepository-mønsteret giver dig mulighed for at indlæse LLM A, LLM B, en visionsmodel, en ASR-model og en Python-pipeline bag én URL med versionsstyring, A/B-routing og ensemblegrafer.

Det er prisen værd, når det gælder: servering af flere heterogene modeller på én server; måneders steady-state produktion med stabilt modelvalg; og den sidste smule p99-latens på Hopper/Blackwell-datacenter-GPU'er.

Ikke det værd, når: du stadig vælger din model (hver swap er en ny engine-build); du bruger forbruger-/arbejdsstations-GPU'er (TRT-LLM-hastighedsforøgelsen krymper vs. H100, og vLLM sender næste uges model seks uger før TRT-LLM); du er et lille team uden driftsbåndbredde.

NVIDIA NIM — den præbyggede sti

NIM (NVIDIA Inference Microservices) samler "Triton + TensorRT-LLM + en optimal konfiguration til denne specifikke model + en virksomhedslicens" i én container. docker pull nvcr.io/nim/meta/llama-3.3-70b-instruct:latest, indstil en NGC-nøgle, kør, og du har et testet OpenAI-kompatibelt slutpunkt uden at vælge kvante- eller tuning-flag.

Passer når: du har købt NVIDIA AI Enterprise (eller en kunde kræver det); du ønsker den hurtigste tid til et kendt, fungerende slutpunkt (timer, ikke dage); den model du ønsker er i kataloget (Llama, Mistral, Mixtral, Gemma, Nemotron og et voksende partnersæt). Efter GTC 2026 dækker et gratis niveau op til 16 GPU'er for medlemmer af Developer Program - nok til at evaluere på de fleste Kentino-enkeltserverinstallationer; verificer aktuelle licensvilkår, før du satser på det.

Passer ikke når: modellen ikke er i kataloget (åbne vægte ankommer med ugers forsinkelse); du vil finjustere (NIM skjuler de fleste knapper per design).

Omvendt proxy, godkendelse, hastighedsbegrænsning

Vis ikke vLLM direkte på det offentlige internet. Sæt nginx (eller Caddy eller Traefik) foran det. En minimal nginx-konfiguration:

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;
    }
}

Tre punkter, folk tager fejl af:

• proxy_buffering off er påkrævet for streaming af svar. Ellers akkumuleres tokens i proxyen, og klienten ser en engangslevering.
• proxy_read_timeout Standardindstillingen er 60 sekunder. Lange multimodale præfyldninger med 4 tok/s går længere end det. Indstil den til 5-10 minutter.
• if blokken er præcis match. Brug Lua, oauth2-proxy eller en gateway som Kong for at få ægte godkendelse.

Overvågning

To metriske kilder, to scrape-mål.

• vLLM'er /metrics slutpunkt. Prometheus-kompatibel, samme port som OpenAI API'en (:8000/metricsUdgiver vllm:num_requests_running, vllm:num_requests_waiting, vllm:gpu_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:time_per_output_token_secondsKV-cacheudnyttelse er den, der fanger præemption, før den dræber latenstid.
• DCGM-eksportør (nvcr.io/nvidia/k8s/dcgm-exporter, port 9400). Eksporterer GPU SM-udnyttelse, hukommelsesudnyttelse, strøm, temperatur, PCIe BW og ECC-tællere.

Begge i Prometheus, begge i Grafana. Første dashboard: requests-running, KV-cache-usage, GPU-util, GPU-temp, P95 TTFT, P95 TPOT. Hvis KV-cache-usage mættes, mens requests-waiting stiger, så forebygger du — drop. --max-num-seqs, hæve --gpu-memory-utilizationeller tilføj en replika.

Modelopvarmningen fik fat i dig

Den første anmodning til en friskstartet vLLM er 5-30 gange langsommere end steady-state. CUDA-grafer registreres for hver batchform, præfikscachen er tom, og scheduleren kalibrerer. Udfør en lille /v1/chat/completions anmodning ved opstart før tilslutning til load balancer; uden den får den første rigtige bruger et svar på 15 sekunder på en model, der normalt svarer med 1. For blå/grønne installationer skal den nye replika varmes op, før den gamle drænes. At springe opvarmning over er den mest almindelige årsag til "installationen så fin ud, men brugerne klagede i ti minutter".

Multimodel på én server

vLLM er grundlæggende en server med én model. Tre muligheder, hvis du har brug for flere:

1. Én container pr. model, forskellige porte. Hver har sin egen VRAM. En 70B og en 7B deler en 4-GPU boks via CUDA_VISIBLE_DEVICES udskæring plus matchning --gpu-memory-utilizationDet er din opgave at planlægge et hukommelsesbudget.
2. Indlæs efter behov. En frontend indlæses/aflæses, når anmodninger ankommer. Indlæsningen tager 30-120 sekunder for en 70B; latenstid ved første hit er uacceptabel til interaktiv brug. Fin til batch.
3. Tritons modelarkiv. Triton ejer livscyklussen for N-modeller på én server, rutes efter modelnavn. Hvad du opgraderer til, når mulighed 1 stopper med at skalere.

For de fleste Kentino-installationer er mulighed 1 den rigtige, indtil du har fire eller flere modeller, hvorefter Tritons driftsafgift er værd at betale.

Den ærlige holdning

95 procent af Kentino-kunderne bør starte med vllm/vllm-openai i Docker, bag nginx, på én model, med Prometheus + DCGM eksportør scraping, og ikke kigge på noget andet de første tre måneder. SGLang fortjener sin plads til struktureret output eller trafik med delte præfikser i stor skala. llama.cpp fortjener sin plads på en Jetson, en Mac eller en enkeltbrugerudviklingsboks. Triton og TensorRT-LLM fortjener deres plads, når du har måneders stabil produktion med flere modeller. NIM fortjener sin plads, når modellen er i kataloget, og licensen er i hånden.

Omkostningerne ved at starte for komplekst er reelle. Vi har set laboratorieinstallationer bruge tre uger på at få Triton + TensorRT-LLM til at betjene en enkelt Llama 70B, som vLLM ville have haft på tyve minutter. Vælg det simple først. Tilføj kompleksitet, når du har bevis for, at du har brug for det.

---

Dette er en del af Kentino Wiki, en referenceserie om AI-beregning, robotteknologi og de systemer, der forbinder dem. Kommentarer og rettelser er velkomne på info@kentino.com.