vLLM Productie-Deployment: Architectuur voor High-Throughput Inference Serving

Bijgewerkt 11 december 2025

December 2025 Update: Stripe realiseert 73% kostenreductie op inferentie door migratie naar vLLM (50 miljoen dagelijkse API-calls op 1/3 van de GPU-vloot). PagedAttention elimineert 60-80% geheugenverspilling door KV-cache fragmentatie. vLLM levert 2-24x throughput vergeleken met conventionele serving. Draait in productie bij Meta, Mistral AI, Cohere en IBM. OpenAI-compatibele API's vereenvoudigen adoptie.

Het ML-platformteam van Stripe zag hun inferentiekosten met 73% dalen na de migratie van Hugging Face Transformers naar vLLM, waarbij dezelfde 50 miljoen dagelijkse API-calls werden verwerkt op een derde van de GPU-vloot.¹ Het geheim achter vLLM's efficiëntie ligt in PagedAttention, een algoritme dat GPU-geheugen behandelt als virtueel geheugen in besturingssystemen, waardoor de fragmentatie wordt geëlimineerd die 60-80% van het geheugen verspilt in traditionele inferentiesystemen.² Organisaties die productie-LLM-workloads draaien ontdekken dat vLLM 2-24x throughputverbeteringen levert ten opzichte van conventionele serving-frameworks, wat de economie van het deployen van large language models op schaal transformeert.³

Het landschap van inference serving is gefragmenteerd in tientallen opties: TensorRT-LLM belooft maximale NVIDIA-optimalisatie, Hugging Face TGI biedt vertrouwde integratie, en Ollama vereenvoudigt lokale deployment. Toch is vLLM de dominante keuze geworden voor productie-workloads en draait het inference bij Meta, Mistral AI, Cohere en IBM.⁴ De combinatie van PagedAttention, continuous batching en OpenAI-compatibele API's creëert een deployment-ervaring die ruwe prestaties balanceert met operationele eenvoud. Het begrijpen van vLLM's architectuur en deployment-patronen scheidt organisaties die kosteneffectieve inferentie bereiken van degenen die verdrinken in GPU-rekeningen.

PagedAttention transformeert geheugenbeheer

Traditionele LLM-inferentie wijst een aaneengesloten geheugenblok toe voor de key-value (KV) cache van elke sequentie, waarbij ruimte wordt gereserveerd voor de maximaal mogelijke sequentielengte ongeacht het werkelijke gebruik. Een systeem geconfigureerd voor 4.096 tokens wijst dat volledige geheugen toe, zelfs voor responses van 100 tokens, wat 97% van de gereserveerde capaciteit verspilt. Vermenigvuldig dit met honderden gelijktijdige verzoeken en GPU-geheugen raakt vol met lege reserveringen terwijl werkelijke sequenties in de wachtrij staan voor resources.

PagedAttention herdenkt deze architectuur door GPU-geheugen te verdelen in pagina's van vaste grootte, typisch 16 tokens elk.⁵ Elke sequentie houdt een lijst van paginareferenties bij in plaats van een aaneengesloten toewijzing, wat verschillende baanbrekende mogelijkheden mogelijk maakt:

Niet-aaneengesloten opslag staat toe dat KV-cache blokken verspreid worden over beschikbaar GPU-geheugen. Het systeem heeft niet langer grote aaneengesloten regio's nodig, waardoor de fragmentatie wordt geëlimineerd die traditionele allocators plaagt. Een sequentie van 2.000 tokens slaat zijn cache op over 125 pagina's verdeeld waar ruimte bestaat.

Dynamische allocatie voorziet geheugen alleen naarmate sequenties groeien. Het eerste token wijst één pagina toe. Het zeventiende token triggert een tweede pagina-allocatie. Geheugenverbruik volgt werkelijk gebruik in plaats van theoretische maxima, wat de effectieve capaciteit dramatisch verbetert.

Geheugen delen maakt het mogelijk dat identieke prompt-prefixen KV-cache pagina's delen tussen verzoeken. Tien gebruikers die variaties van dezelfde systeemprompt vragen, delen een enkele gecachte kopie van die prefix, wat geheugenverbruik met 90% vermindert voor veelvoorkomende patronen. Productiesystemen met gestandaardiseerde prompts zien gebruiksverbeteringen van meer dan 400%.⁶

Bijna nul verspilling elimineert interne fragmentatie die gebruikelijk is bij statische allocatie. Traditionele systemen verspillen gemiddeld 4,1 tokens per sequentie in gedeeltelijk gevulde blokken. PagedAttention's granulariteit op paginaniveau vermindert verspilling tot fracties van een pagina, typisch minder dan 8 tokens per sequentie ongeacht de lengte.

Het algoritme put directe inspiratie uit virtueel geheugen van besturingssystemen en past decennia van geheugenbeheersonderzoek toe op GPU-inferentie. Net zoals moderne besturingssystemen virtuele adressen mappen naar fysieke geheugenpagina's, mapt PagedAttention logische KV-cache posities naar fysieke GPU-geheugenblokken. De vertaaloverhang voegt microseconden toe aan elke attention-berekening maar bespaart gigabytes aan geheugencapaciteit.

Continuous batching maximaliseert GPU-benutting

Statische batching wacht op een vast aantal verzoeken voordat ze samen worden verwerkt, wat latency-pieken creëert wanneer batches gedeeltelijk gevuld zijn en throughput daalt wanneer verzoeken ongelijkmatig binnenkomen. Een batchgrootte van 32 betekent dat het 31e verzoek wacht op nog één aankomst voordat verwerking begint, wat mogelijk seconden latency toevoegt tijdens periodes met weinig verkeer.

Continuous batching in vLLM elimineert batchgrenzen volledig.⁷ De scheduler opereert op iteratieniveau in plaats van verzoeksniveau en neemt beslissingen bij elke forward pass in plaats van elke batch. Wanneer een sequentie generatie voltooit, accepteert zijn slot onmiddellijk een nieuw verzoek zonder te wachten tot zuster-sequenties klaar zijn. De GPU verwerkt welk werk er op elk moment bestaat en vult gaten die statische batching leeg laat.

De implementatie vereist zorgvuldige coördinatie tussen geheugenbeheer en scheduling:

Scheduling op iteratieniveau evalueert de verzoekenwachtrij bij elke decoder-stap. Voltooide sequenties geven hun slots vrij, wachtende verzoeken claimen beschikbare capaciteit, en de volgende iteratie gaat verder met een optimaal gevulde batch. Latency-variantie tussen verzoeken wordt geabsorbeerd in plaats van versterkt.

Preemption-afhandeling beheert situaties waarin geheugendruk sequentie-evacuatie forceert. Verzoeken met lagere prioriteit maken een checkpoint van hun KV-cache status en geven GPU-geheugen vrij aan sequenties met hogere prioriteit. Wanneer capaciteit terugkeert, hervatten gepreëmpteerde sequenties vanaf hun checkpoints in plaats van opnieuw te starten.

Prefix caching identificeert verzoeken die gemeenschappelijke prefixen delen en routeert ze naar instanties die al relevante KV-cache pagina's bevatten. Een klantenservicesysteem waar elk verzoek begint met dezelfde context van 500 tokens serveert volgende tokens vanuit gecachte staat, wat redundante prefix-berekening elimineert.

Benchmarks demonstreren de impact: vLLM bereikt een throughput van 793 tokens per seconde vergeleken met Ollama's 41 tokens per seconde bij equivalente configuraties, met P99 latency van 80ms versus 673ms.⁸ De continuous batching-architectuur handhaaft deze voordelen over concurrency-niveaus van 1 tot 256 gelijktijdige gebruikers.

Productie-architectuur schaalt over clusters

Single-node vLLM-deployments verwerken substantieel verkeer, maar productiesystemen vereisen cluster-brede orchestratie voor betrouwbaarheid, schaal en efficiëntie. De vLLM production-stack transformeert de inference-engine in een compleet serving-systeem met vier kritieke toevoegingen.⁹

Request routing stuurt inkomende queries naar geschikte backend-instanties op basis van routing keys, sessie-ID's of prefix matching. Intelligente routing maximaliseert KV-cache hergebruik door gerelateerde verzoeken te sturen naar instanties die al relevante context bevatten. Een conversatie met meerdere beurten routeert consistent naar dezelfde backend, wat redundante prefix-berekening over instanties vermijdt.

KV-cache delen breidt PagedAttention's geheugenefficiëntie uit over meerdere vLLM-instanties via het LMCache-project. Backends delen berekende KV-cache blokken over high-speed interconnects, wat cache hits mogelijk maakt zelfs wanneer verzoeken naar verschillende instanties routeren. Systemen met repetitieve workloads zien 3-10x latency-reductie en 2-5x throughput-verbetering door cross-instance cache sharing.¹⁰

Observability-integratie stelt metrics beschikbaar via Prometheus en visualisatie via Grafana-dashboards. Per-request metrics leggen time-to-first-token (TTFT), time-between-tokens (TBT) en end-to-end latency vast. Per-instance metrics volgen GPU-benutting, geheugendruk, wachtrijdiepte en cache hit rates. Operations-teams krijgen inzicht in performance-bottlenecks en capaciteitsplanningsdata.

Horizontale schaling voegt vLLM-instanties toe en verwijdert ze op basis van vraagsignalen. Kubernetes-deployments gebruiken Horizontal Pod Autoscaler met custom metrics gericht op wachtrijdiepte of latency-percentielen. De router-laag ontdekt automatisch nieuwe instanties en herbalanceert verkeer, wat elastische capaciteit mogelijk maakt die werkelijke vraag volgt.

Deployment volgt standaard Kubernetes-patronen via Helm charts:

# values.yaml voor vLLM production-stack
replicaCount: 4
model:
  name: "meta-llama/Llama-3.1-70B-Instruct"
  tensorParallelism: 4
resources:
  limits:
    nvidia.com/gpu: 4
router:
  enabled: true
  prefixAwareRouting: true
observability:
  prometheus: true
  grafana: true

De gedeployde stack stelt een OpenAI-compatibele API beschikbaar via een Kubernetes-service, wat drop-in vervanging mogelijk maakt voor applicaties die momenteel OpenAI of Azure OpenAI endpoints aanroepen. Bestaande codebases vereisen alleen endpoint URL-wijzigingen om te migreren van cloud API's naar self-hosted inference.

Infrastructuurvereisten bepalen deployment-beslissingen

vLLM's geheugenefficiëntie maakt grotere modellen mogelijk op kleinere GPU-configuraties, maar hardwareselectie bepaalt nog steeds prestatiekenmerken. Het begrijpen van de relatie tussen modelgrootte, GPU-geheugen en throughput informeert aankoopbeslissingen.

GPU-geheugen beperkt maximale modelgrootte en gelijktijdige batchcapaciteit. Een model van 70B parameters in FP16 vereist 140GB alleen al voor weights, wat multi-GPU tensor parallelism noodzakelijk maakt op elke huidige hardware. Hetzelfde model in INT4-quantisatie past in 35GB, deploybaar op een enkele A100 80GB of H100 met substantiële ruimte voor KV-cache. Geheugenbandbreedte beperkt throughput vaak meer dan ruwe rekenkracht, waardoor GPU's met HBM3 disproportioneel effectief zijn.

Tensor parallelism splitst modellagen over meerdere GPU's binnen een node, essentieel voor modellen die single-GPU geheugen overschrijden. vLLM ondersteunt tensor parallel graden die overeenkomen met GPU-aantal en shardt automatisch attention en feed-forward lagen. Een node met 8 GPU's die tensor parallelism van 8 draait, serveert een model van 405B parameters dat anders meerdere nodes zou vereisen met tragere pipeline parallelism.

Netwerkfabric wordt kritiek voor multi-node deployments. Pipeline parallelism over nodes vereist low-latency, high-bandwidth interconnects tussen stages. InfiniBand of RoCE netwerken met 200-400Gbps bandbreedte ondersteunen efficiënte multi-node serving, terwijl standaard Ethernet latency introduceert die time-to-first-token substantieel verslechtert.

Storage throughput beïnvloedt cold start prestaties bij het laden van model weights. Een model van 70B in FP16 vereist het overdragen van 140GB van storage naar GPU-geheugen voordat de eerste verzoeken worden bediend. NVMe-storage die 7GB/s levert, laadt het model in 20 seconden; network-attached storage op 500MB/s duurt 5 minuten. Productiesystemen onderhouden ofwel warm standby-instanties of implementeren model caching-strategieën om cold start-impact te minimaliseren.

Introl helpt organisaties vLLM-infrastructuur te ontwerpen binnen ons wereldwijde dekkingsgebied, waarbij hardwareconfiguraties worden afgestemd op workload-vereisten terwijl wordt geoptimaliseerd voor kostenefficiëntie.¹¹ Onze engineers hebben inference-infrastructuur gedeployed die miljarden verzoeken per maand bedient en begrijpen de nuances die functionele deployments scheiden van sterk geoptimaliseerde systemen.

vLLM vergelijken met alternatieven

Het inference serving-ecosysteem biedt meerdere frameworks, elk met eigen sterke punten. Het selecteren van de juiste tool vereist het matchen van framework-mogelijkheden met workload-kenmerken.

TensorRT-LLM levert maximale prestaties op NVIDIA-hardware door agressieve kernel-optimalisatie en graph-compilatie. Benchmarks tonen TensorRT-LLM die 10.000+ output tokens per seconde bereikt op H100 met FP8-quantisatie, met time-to-first-token rond 100ms.¹² De afweging: complexe setup die checkpoint-conversie, engine building en uitgebreide configuratie vereist over TensorRT-LLM, tensorrtllm_backend en Triton Inference Server. Organisaties met toegewijde ML-infrastructuurteams en stabiele model-deployments profiteren het meest.

**Hugging Fa

[Content truncated for translation]