GPU-dimensionering met vLLM: dimensioneer de werklast, niet alleen het model

Het aantal parameters is slechts een ondergrens voor GPU-geheugen. Dit artikel dimensioneert vLLM-deployments op basis van verkeer, latencydoelen en de verdeling van contextlengtes, en behandelt de omvang van het model, de key-value-cache, gelijktijdigheid, de parallellismestrategie, kwantisatie en reservecapaciteit onder soevereiniteitseisen. Het steunt op het systeemonderzoek achter vLLM, dat laat zien dat cachebeheer en scheduling de doorvoer bepalen.

Trefwoorden vLLM · GPU-dimensionering · KV-cache · gelijktijdigheid · kwantisatie · soevereine inferentie

De snelste manier om te veel uit te geven aan soevereine LLM-infrastructuur is een cluster dimensioneren op alleen het aantal parameters.

Een model dat technisch in het GPU-geheugen past, kan productiedoelen voor latency toch missen zodra lange contexten, gelijktijdige gebruikers, KV-cache, retrievalpayloads en toolaanroepen in de werklast komen. Omgekeerd kan een sterk gekwantiseerd model op minder GPU's betere economie leveren als het verkeer gemiddeld is en het kwaliteitsverlies acceptabel.

Een nuttige dimensioneringsoefening begint bij de werklast en werkt terug naar de hardware.

Dimensionering volgt uit de manier waarop servingsystemen geheugen gebruiken. Voor elk verzoek houdt de server een key-value-cache bij die groot is en dynamisch groeit en krimpt; slecht beheerd verspilt die geheugen en beperkt hij de batchgrootte. PagedAttention in vLLM pakt dit aan en meldt 2–4× hogere doorvoer bij dezelfde latency dan eerdere systemen, met grotere winst bij langere reeksen en grotere modellen^[1]. Scheduling telt even zwaar als geheugen: bij batching per verzoek kunnen afgeronde verzoeken niet terugkeren en moeten nieuwe wachten, het probleem waarvoor scheduling per iteratie werd voorgesteld^[2]. Daarom bepalen gelijktijdigheid en de verdeling van contextlengtes de hardwarerekening, niet het aantal parameters.

Kwantisatie verandert de geheugenkant van de vergelijking. Een overzichtsstudie merkt op dat de overstap naar gehele getallen van vier bits of minder het geheugengebruik en de latency in theorie tot 16× kan verlagen, waarbij in de praktijk vaak 4× tot 8× wordt gehaald^[3]; AWQ is een gangbare 4-bitmethode voor taalmodellen die alleen de gewichten kwantiseert^[4]. Die cijfers komen uit de eigen opstellingen van de papers en moeten opnieuw worden gemeten op het doelmodel en de doelhardware.

Een ruwe ondergrens voor het geheugen van de gewichten is:

modelparameters × bits per gewicht ÷ 8

Dat is alleen het startpunt. Echte deployments hebben ook geheugen nodig voor KV-cache, runtimebuffers, CUDA-graphs of compilatieartefacten, en operationele marge.

Kwantisatie kan de omvang van de gewichten flink verkleinen, maar het effect op doorvoer en kwaliteit hangt af van het model, de hardware en het kwantisatieformaat.

Lange context is duur omdat de KV-cache meegroeit met actieve reeksen en het aantal tokens. Als een applicatie grote documenten of lange gespreksgeschiedenissen meestuurt, kan het cluster eerder door de KV-cache worden begrensd dan door rekenkracht.

Daarom moet een modellimiet van 200k tokens niet automatisch een productiestandaard van 200k tokens worden.

Meet de werkelijke verdeling van inputlengte, outputlengte en gelijktijdige verzoeken. Leg dan grenzen vast: maximale context, beleid voor afkappen of samenvatten, en limieten voor retrieval.

Voor zakelijke systemen is de belangrijke vraag meestal niet "Wat is het maximale aantal tokens per seconde?" maar "Hoeveel echte gebruikers kan de dienst bedienen binnen onze latency-SLO?"

Volg ten minste:

• tijd tot het eerste token (TTFT);
• latency tussen tokens / generatiesnelheid;
• wachttijd in de queue;
• gelijktijdige reeksen;
• verdeling van prompt- en completiontokens;
• GPU-benutting en geheugendruk;
• fout- en preemptionpercentages.

vLLM biedt productiemetrics via het endpoint /metrics, zodat deze signalen beschikbaar zijn voor monitoring die compatibel is met Prometheus.

De actuele richtlijnen van vLLM zijn helder:

• als het model ruim op één GPU past, vermijd dan gedistribueerde complexiteit;
• als het meerdere GPU's in één node nodig heeft, is tensorparallellisme de gebruikelijke volgende stap;
• als het groter is dan één node, combineer dan tensor- en pipelineparallellisme;
• voor meerdere onafhankelijke replica's of het opschalen van verkeer wordt data-parallelle deployment relevant.

Bij MoE-modellen kan ook expertparallellisme van belang zijn. De juiste topologie hangt af van waar de bottleneck zit: in attention, expertlagen, interconnect of geheugen.

INT4, INT8 en FP8 kunnen geheugeneisen verlagen en soms de doorvoer verbeteren, maar ze moeten worden behandeld als deploymentvarianten die dezelfde evaluatieset moeten halen als de basislijn met volledige precisie.

Een 32B-model in een geschikt laag-bitformaat past bijvoorbeeld mogelijk in een veel kleinere deployment dan de BF16-versie. Dat kan de hele businesscase veranderen als de werklast geen groter model nodig heeft.

Modelleer vóór de inkoop drie verkeersniveaus:

Basis — normaal gebruik tijdens kantooruren.

Piek — een vergadering, campagne of interne workflow veroorzaakt een korte piek in gelijktijdigheid.

Storing — één replica is niet beschikbaar en de resterende capaciteit moet kritieke verzoeken opvangen.

Schat per niveau de inputtokens, outputtokens, gelijktijdigheid en de beoogde TTFT. Benchmark het echte model met die vormen in plaats van te vertrouwen op een generiek leaderboard.

Een soevereine deployment ruilt soms bewust wat elasticiteit in voor controle. Als de omgeving geen piekcapaciteit in de publieke cloud heeft, heeft het cluster genoeg reserve nodig om onderhoud en uitval van een node te overleven.

De architectuur moet ook rekening houden met:

• opslagcapaciteit voor modellen en updatevensters;
• een lokale registry voor containers/images;
• bewaartermijnen voor observability;
• eisen voor egress die standaard alles weigert;
• een failoverstrategie;
• reservecapaciteit voor evaluatie- of canary-modellen.

We dimensioneren soevereine inferentie op verkeer + latency-SLO + verdeling van de context + kwaliteitsdoel voor het model, en kiezen dan de kleinste architectuur die de acceptatietests haalt.

Zo vermijden we beide gebruikelijke fouten: een cluster kopen dat te klein is voor echte gelijktijdigheid, of dure GPU's kopen die grotendeels stilstaan.

• vLLM — Parallelism and Scaling
• vLLM — Production Metrics
• LMXAI — Soevereine vLLM-deployment

• Soevereine vLLM-deployment + checklist voor leveranciers
• Kwantisatie in vLLM: AWQ, GPTQ, FP8 en INT4
• vLLM in productie op Kubernetes
• Veelgestelde vragen over soevereine AI
• Soevereine LLM-deployment