Gyorsabb a vLLM az SGLangnél vagy a TensorRT-LLM-nél?

Nem általánosan, és a legtöbb közzétett összehasonlítás nem összevethető. A vLLM 2023-as bemutatkozó bejegyzése legfeljebb 24-szeres átvitelt jelentett a Hugging Face Transformershez és 2,2–3,5-szöröst a TGI-hez képest, LLaMA-7B és LLaMA-13B mellett, ShareGPT-ből származó kéréshosszakkal. Ez még a versenytársak lapozott cache-einek átvétele előtti idő, ezért a saját kéréshossz-eloszlást érdemes mérni.

Kell GPU a vLLM futtatásához?

A dokumentált cél Linux CUDA-val vagy ROCm-mel, Python 3.10-től 3.13-ig. Az Intel XPU és a Google TPU külön támogatott, az Apple Silicont pedig egy másik, MLX-alapú projekt fedi le, nem maga a vLLM. A tisztán CPU-s inferencia a llama.cpp területe.

Mennyi VRAM kell a vLLM-nek?

A vLLM a VRAM egy beállítható hányadát foglalja le a súlyoknak és a KV-cache-nek, majd induláskor egy profiling forward passzal méri a maradékot, és jelenti, hány blokk fér bele. Gyakorlatban a szűk keresztmetszet a modell súlya a választott kvantálás mellett; a többi a KV-cache, és annak mérete szabja meg a párhuzamosságot.

Egy vLLM szerver több modellt is kiszolgálhat?

Natívan nem. Egy szerverprocessz egyszerre egy modellt tart, ezért a többmodelles telepítések modellenként egy processzt futtatnak egy router mögött, vagy adat párhuzamossággal replikálják ugyanazt a modellt több GPU-ra. Kivétel a LoRA adapterek: ezek futásidőben betölthetők és leválaszthatók, a dokumentáció azonban ezt helyi fejlesztésre korlátozza.

Hogyan marad reprodukálható a vLLM kimenete frissítések után?

Rögzítsd az engine verzióját, mert a minor kiadásokként körülbelül két hetente érkeznek, és adj --generation-config vllm opciót, hogy a szerver ne alkalmazza a Hugging Face repóban lévő generation_config.json fájlt, és ezzel ne írja felül csendben a sampling alapértékeket. Determinisztikus futásokhoz állítsd a hőmérsékletet nullára, és rögzítsd a modell revízióját is.

vLLM áttekintve: inferencia saját hardveren

A vLLM egy nyílt forráskódú inféziós engine, amely Hugging Face checkpointból OpenAI API-t beszélő HTTP-szervert épít. Ez a réteg a modell és minden hívó között van, és az egyetlen feladata, hogy a GPU-t folyamatosan dolgoztassa. Az ítélet előre: NVIDIA- vagy AMD-hardveren, nyílt súlyú modellekkel ez az alapértelmezett választás, mert másik projekt sem fed le ennyi felület ennyi ragasztó kóddal. Laptopon, tisztán CPU-s gépen, vagy egy modellel és egy felhasználóval messzire túl nagy gépezet.

A kiszolgálási rétegben verseng, nem a modellrétegben. A versenytársak a SGLang, amely a design nagy részét osztja; az NVIDIA TensorRT-LLM, amely a szélességet cseréli a csúcseredményekért az NVIDIA alkatrészeken; a llama.cpp, amely ott kezdődik, ahol a vLLM feladja; és a Hugging Face TGI, amelynek utolsó kiadása a v3.3.7 volt 2025 decemberében. A szokásos helyettesítője a hosztolt API-nak is, mert ugyanaz az OpenAI klienskód, amely szolgáltatót hív, egy helyi processzhez is irányítható.

Mi ez valójában

A kiszolgáló engine kiválasztásánál számító tények, mind a projekt saját dokumentációjából, nem szolgáltatói oldalról:

Apache-2.0, fizetős szint és a szolgáltató által hosztolt vezérlőréteg nélkül.
A UC Berkeley Sky Computing Lab laboratóriumában indult; a dokumentáció több mint 2000 közreműködőt említ, és az egyik legaktívabb nyílt forráskódú AI-projektnek nevezi.
Több mint 200 modellarchitektúra a Hugging Face-en, köztük decoder-only, mixture-of-experts, hibrid attention, multimodális, embedding-, rerank- és reward-modellek.
OpenAI-kompatibilis szerver, plusz Anthropic Messages és Cohere embed, illetve rerank végpontok, továbbá beszéd és strukturált kimenet. Egy processz egy modellt szolgál ki.
A CUDA és a ROCm első osztályú cél, az Intel XPU és a Google TPU támogatott, hardverpluginekkel az Ascend NPU-hoz, Gaudihoz, Spyre-hez, Apple Siliconhoz, MetaX-hez és továbbiakhoz.
Kvantálás FP8, NVFP4, MXFP4, INT8 és INT4 szinten, továbbá GPTQ-, AWQ-, GGUF- és compressed-tensors checkpointok.
Körülbelül kéthetente egy minor kiadás: a v0.24.0 2026. június 29-én jelent meg, hat héttel a v0.20.2 május 10-i kiadása után.

Hogyan működik

Két gondolat hordozza az átvitel nagy részét. A PagedAttention fix méretű blokkokban tárolja a key-value cache-t, és egy blokktáblán keresztül nem összefüggő GPU-memóriára képezi le, ugyanúgy, ahogy egy operációs rendszer a lapokat; a 2023-as tanulmány a korábbi rendszerekben 60–80 százalékos KV-cache pazarlást mért töredezettség és túlreszerválás miatt, a lapozott allokációval szemben 4 százalék alatt. A folyamatos batching ezután minden dekódolási lépésnél befogad új kéréseket ahelyett, hogy megvárná a batch feltöltését, és innen származik a késleltetésjavulás nagy része.

A vLLM V1 processzekre bontja a munkát: HTTP és tokenizálás az API-kiszolgálóban, ütemezés és cache-kezelés az engine core-ban, GPU-nként egy worker.

A V1 engine, amely 2025-ben váltotta fel a V0-át, egy lépésben keveri a prefillet és a dekódolást, és a dekódolásnak ad prioritást, így egy hosszú prompt már nem fékezi le a streamelt forgalmat. A chunked prefill alapértelmezetten be van kapcsolva. A prefix caching is alapértelmezett, és tokenblokkokat hashel, így az ismétlődő rendszerprompt csak egyszer prefilletődik fel; a projekt dokumentációja külön kiemeli, hogy ez csak a prefillet rövidíti, a dekódolásra nem hat, tehát közös prefix nélküli hosszú generálásnál alig hoz valamit. A spekulatív dekódolás n-gram, EAGLE és DFlash javaslatkiválasztókkal érhető el, nem külön kis draft modellel.

Kiszolgáló felállítása

A telepítés egy parancs, a dokumentált platform Linux Python 3.10-től 3.13-ig. Egy modell kiszolgálása így néz ki:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

# Prefix caching and chunked prefill are on by default in V1.
vllm serve Qwen/Qwen3-8B \
  --served-model-name qwen3-8b \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9 \
  --tensor-parallel-size 2 \
  --api-key "$VLLM_TOKEN"

A flagek lényegében kapacitási döntések. A --max-model-len korlátozza a kontextust, és ezzel az egy kérés által tartható KV-cache méretét, ezért a termék által valóban igényelt leghosszabb promptra állítsd, nem a modell maximumára. A --gpu-memory-utilization a VRAM azon hányada, amelyet előre a súlyoknak és a cache-nek foglal le; ami a súlyok után marad, azt méri az indulási profiling futás, és ebből lesznek blokkok. A -O0 és -O3 szabályozza, mennyire erősen fordít és rögzít CUDA grafikonokat, -O2 az alapértelmezett; a --enforce-eager mindkettőt kihagyja. A megszólításhoz nem kell új kliens:

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
)

stream = client.chat.completions.create(
    model="qwen3-8b",
    messages=[
        {"role": "system", "content": "Answer in one sentence."},
        {"role": "user", "content": "Why beat a contiguous KV cache?"},
    ],
    max_tokens=200,
    temperature=0,
    stream=True,
)

for chunk in stream:
    print(chunk.choices[0].delta.content or "", end="", flush=True)

Mit ér az átviteli állítás

A híres számok a 2023-as bemutatkozó bejegyzésből származnak, nem friss benchmarkokból: LLaMA-7B egy A10G-n és LLaMA-13B egy 40 GB-os A100-on, ShareGPT-ből származó kéréshosszakkal, legfeljebb 24-szeres átvitelt adtak a Hugging Face Transformershez képest és 2,2–3,5-szöröst a TGI-hez képest. Ezek az értékek már történelem, nem specifikáció, és a történet tartós része a memóriapazarlás, nem a szorzók. Azóta változott a szint: a komoly versenytársak mind átvették a lapozott cache-t és a repülés közbeni batchinget, így a hasznos kérdés már nem az, ki batchel jobban, hanem az, ki hangol és patchel gyorsabban.

Kapcsoló	Mit változtat	Mikor érdemes állítani
`--max-model-len`	Korlátozza a kontextust, és vele egy kérés által tartható KV-cache méretét	A leghosszabb valós prompt messze a modell maximuma alatt van
`--gpu-memory-utilization`	A VRAM azon hányada, amely előre a súlyoknak és a KV-cache-nek foglal le	Az indulási log kevés blokkot jelez, vagy a kérések kiszorulnak
`max_num_batched_tokens`	Prefill tokenek lépésenként: kisebb érték a tokenközi késleltetést, nagyobb az első token idejét javítja	Interaktív chat kontra offline batch munka
`--tensor-parallel-size`	Szétosztja a súlyokat több GPU-ra, így kártyánként több KV-cache hely felszabadul	A modell nem fér be, vagy a KV-cache a szűk keresztmetszet
`-O0`-tól `-O3`	Fordítás és CUDA grafik rögzítése; `-O2` az alapértelmezett	Az indulási idő fontosabb, mint a dekódolás állandósult állapotban
`--enforce-eager`	Teljesen kihagyja a fordítást és a grafikrögzítést	Fejlesztési ciklusok, vagy annak mérése, hogy egy indítás mennyi része a rögzítés

Az a hibaforma, amely valóban előfordul produkcióban, a preemption. Ha a KV-cache nem fér el minden futó szekvenciához, a vLLM kiszorítja a kéréseket, és újraszámolja őket a promptból, amikor lesz hely; az összesített átvitelben ez alig látszik, a faroklatenciában viszont dominál. A V1 alapértelmezés szerint újraszámításra vált a swappelés helyett, mert a swapelés többet fizetett, tehát a gyógyulat kapacitás, nem egy flag.

Üzemeltetés produkcióban

Először a megfigyelhetőség

Az engine a /metrics útvonalon Prometheus végpontot ad a vllm: előtaggal. A metrics design dokumentum szokatlanul egyértelmű a szándékról: a szerver szintű gauge-ok a kérés szintű hisztogramok magyarázatára valók, és a kérés szintű hisztogramok azok a sorok, amelyekre egy üzemeltetőnek riasztania kell.

vllm:time_to_first_token_seconds — a prefill költsége, amit a felhasználó hideg promptnál érzett
vllm:inter_token_latency_seconds — a dekódolás sebessége, amit a felhasználó a generálás megkezdése után érzett
vllm:e2e_request_latency_seconds az a sor, amelyre az időtúllapadási szabályt írni kell
vllm:kv_cache_usage_perc és vllm:num_requests_running — kapacitás; ha mindkettő egyszerre a határán áll, a sor nő
vllm:prefix_cache_queries és vllm:prefix_cache_hits arányához — ez mondja meg, valóban újrahasznosítják-e a közös promptokat, és tehát hogy illik-e a terhelés az engine-hez

Processzszám és CPU

A négy GPU-s telepítés nem egy processz. A V1 egy API-kiszolgáló processzt, egy engine core processzt és GPU-nként egy worker processzt futtat, tehát egyetlen csomóponton tenzoros párhuzamosság 4 mellett összesen hat processzt, és az adat párhuzamosság egy koordinátort tesz hozzá. A hangolási útmutató N GPU-hoz 2 plusz N fizikai magot ír elő, mert az engine core szoros ciklust futtat, és a CPU-éheztől láthatóan szenved.

Biztonsági helyzet

A hitelesítés egyetlen megosztott titok. A --api-key flag vagy a VLLM_API_KEY környezeti változó bekapcsol egy fejléc-ellenőrzést, és egyszerre több kulcsot is elfogad, hogy rotálhatók legyenek. Nincs felhasználómodell, nincs bérlőnkénti kvóta és nincs jogosultsági réteg, így ami eléri a portot, használhatja az egész GPU-t.

Hol fájik

Először három dolog. Ez GPU-szerver, nem univerzális runtime: a dokumentált cél Linux CUDA-val vagy ROCm-mel, így a tisztán CPU-s gép vagy az Apple Silicon gép másik projektet és másik modellformátumot jelent. Az indulási idő valós, mert az alapértelmezett optimalizálási szint lefordítja a modellt és CUDA grafikonokat rögzít, és egy hideg konténer perceket tölthet a fordítóban, mielőtt az első token megjelenik. Az API pedig OpenAI-alakú, nem OpenAI-teljes: a suffix paraméter nem támogatott, a user paramétert figyelmen kívül hagyják, a párhuzamos tool hívások pedig modellfüggők és a legjobb esetben is csak részben adottak.

Engine	Licenc	Miben nyer	Mit fizet érte
vLLM	Apache-2.0	Szélesség: a legtöbb architektúra, a legszélesebb kvantálási és hardvercél halmaz, egy API a szövegre, embeddingre, rerankra, beszédre és strukturált kimenetre	Fordítás és grafikrögzítés minden indításkor, egy modell szerverenként, és egy szoros ciklus, amihez CPU kell mögötte
SGLang	Apache-2.0	Rádix-szerű prefix megosztás és többkörös állapot újrahasznosítás, ami az ugyanazt a hosszú kontextust újra és újra elérő agent- és retrieval-forgalmat kedvezményez	Kisebb modellzoo és vékonyabb kiszolgálási felület a chat kiegészítéseken túl
TensorRT-LLM	Apache-2.0, csak NVIDIA stack	Csúcseredmények a legújabb NVIDIA alkatrészeken, FP4 és FP8 kernelek, első osztályú integráció a Dynamo és a Triton rendszerrel	Csak NVIDIA, és újraépítés, valahányszor a modell, a kvantálás vagy a GPU-generáció változik
llama.cpp	MIT	CPU, Apple Silicon és edge hardver, GGUF kvantálás, egyetlen bináris fájl Python runtime nélkül	Más modellformátum, gyengébb batchelt kiszolgálási történet, nincs összemérhető felület embeddinghez vagy rerankhoz

A legtöbb csapat számára az igazi összehasonlítás az első és a második sor. A vLLM és az SGLang ugyanazt a problémát ugyanazokkal az elemekkel oldja meg, mindkettő Apache-2.0, mindkettő OpenAI-kompatibilis, és mindkettő jól szolgál ki egy szokásos chat terhelést. Az SGLang prefix-fája jobban illik oda, ahol ugyanaz a hosszú kontextus jön vissza újra és újra; a vLLM modelllefedettsége és kvantálási mátrixa jobban illik oda, ahol az új checkpointok gyorsabban érkeznek, mint a terhelések ismétlődnek.

Ítélet

A vLLM az alapértelmezett eszköz, és ennek oka nem a nyers sebesség, hanem a felület: a legtöbb modell, a legtöbb kvantálási forma, a legtöbb hardvercél, és egy API, amely lefedi a kiegészítéseket, a chatet, az embeddinget, a rerankot, a beszédet és a strukturált kimenetet. A költségek valósak és többnyire unalmasan javíthatók. Az indulási idő állítható, a preemption kapacitáskérdés, a kiéheztetett CPU telepítési hiba. Egyik sem ok arra, hogy mást válassz.

Válaszd, ha nyílt súlyú modelleket szolgálsz ki NVIDIA- vagy AMD GPU-ken, és a terhelés batchelt: sok egyidejű kérés, nem egyenként.
Válaszd, ha gyors a modellváltás, mert egy új checkpoint rendszerint már akkor fut, amikor a versenytársak még nem támogatják.
Válaszd, ha a körülvevő stack már OpenAI API-t beszél, mert a migráció egy base URL.
Ne válaszd laptophoz, edge dobozhoz vagy egy felhasználós eszközhöz; a llama.cpp vagy egy MLX runtime a töredékéért elvégzi.
Ne válaszd, ha egy modell egy NVIDIA generációhoz van kötve, és a csúcs token másodpercenként az egyetlen cél, mert a TensorRT-LLM megnyeri ezt a cserét a bezáródás árán.
Mérd be az SGLang-et, mielőtt elköteleződsz, ha a forgalom agentikus vagy retrieval-nehezes, és erősen újrahasznosítja a kontextust; a kettő olyan közel van egymáshoz, hogy általában az dönt, melyiket lehet reggel háromkor hibakeresni.