Deel:𝕏LinkedInRedditFacebookKopieer link

vLLM configureren voor hoge doorvoer op Linux

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026

Het draaien van een lokaal taalmodel vereist een duidelijke keuze voor de juiste inferentiesoftware. Wie een model gebruikt voor persoonlijk gebruik of lokaal testen, heeft vaak voldoende aan een eenvoudige runner die is geoptimaliseerd voor een enkele stroom aan tekst. Zodra een model echter dient als backend voor meerdere gebruikers, interne API-koppelingen of geautomatiseerde werkstromen, veranderen de technische eisen ingrijpend.

In deze situatie is de totale doorvoer — het aantal verwerkte tokens per seconde over alle actieve gebruikers heen — belangrijker dan de minimale latentie van één individuele interactie. De inferentie-engine vLLM is specifiek ontworpen voor scenario's waarin meerdere verzoeken gelijktijdig binnenkomen en verwerkt moeten worden. In deze gids behandelen we de architectuur, de installatie op Linux, de configuratieparameters en de beveiliging van een vLLM-serveromgeving.

Wanneer kies je voor vLLM?

In het landschap van AI-software bestaan diverse hulpprogramma's om modellen in te laden. Veel gangbare toepassingen richten zich op het snel genereren van antwoorden voor één actieve gebruiker. Deze engines verwerken verzoeken sequentieel of met beperkte parallelle ondersteuning. Dit werkt uitstekend op een werkstation, maar vormt een knelpunt zodra meerdere applicaties tegelijkertijd API-verzoeken insturen.

vLLM levert voordeel op zodra er sprake is van gelijktijdige belasting. De engine is ontworpen om de grafische processor (GPU) zo continu mogelijk bezet te houden. Waar traditionele toepassingen wachten tot een complete tekstgeneratie is afgerond voordat een nieuw verzoek aan de batch wordt toegevoegd, gebruikt vLLM technieken voor dynamische samenvoeging van verzoeken (geavanceerde batching). Voor enkelvoudig gebruik levert vLLM weinig extra snelheid op en vraagt het meer instelwerk. Bij een constante stroom van tientallen of honderden gelijktijdige verzoeken voorkomt het dat de hardware onnodig stilstaat.

Kernregel voor softwarekeuze: Gebruik lichte runners voor individueel ontwikkelwerk of interactieve chatsessies op één apparaat. Kies voor vLLM wanneer je een centrale server inricht die meerdere clients of geautomatiseerde processen parallel moet bedienen.

Het werkingsprincipe: PagedAttention en geheugenbeheer

Om te begrijpen waarom vLLM effectief omgaat met gelijktijdige verzoeken, is inzicht in het GPU-geheugenbeheer noodzakelijk. Tijdens het genereren van tekst bouwt een Large Language Model een intern geheugen op van eerdere tokens, de zogenaamde Key-Value (KV) cache. Wil je precies weten hoe het Key-Value geheugen exact wordt opgebouwd, bekijk dan de verdiepende uitleg over de interne werking van de Transformer-architectuur.

In conventionele inferentie-engines wordt voor elk verzoek vooraf een aaneengesloten blok geheugen gereserveerd dat groot genoeg is voor de maximaal denkbare contextlengte. Omdat de werkelijke lengte van een gesprek van tevoren zelden bekend is, blijft een groot deel van dit vooraf toegewezen geheugen ongebruikt. Dit verschijnsel, interne fragmentatie, leidt ertoe dat de GPU-geheugencapaciteit snel volloopt, waardoor er maar weinig verzoeken tegelijk verwerkt kunnen worden.

vLLM lost dit probleem op met de PagedAttention-techniek, geïnspireerd op virtueel geheugenbeheer in besturingssystemen. Het KV-geheugen wordt opgedeeld in kleine, vaste geheugenblokken (pages). Geheugen wordt pas toegewezen op het moment dat er tijdens de generatie nieuwe tokens bijkomen. Blokken hoeven in het fysieke VRAM niet aan elkaar te grenzen; een interne tabel houdt bij welke virtuele blokken bij welk verzoek horen. Hierdoor vervalt de noodzaak om vooraf enorme geheugenruimtes te reserveren. De geheugenverspilling daalt tot een verwaarloosbaar niveau, waardoor er aanzienlijk meer verzoeken gelijktijdig in het geheugen passen.

Installatie en afhankelijkheden op Linux

Een stabiele vLLM-omgeving op Linux vereist een gestructureerde aanpak bij het beheer van afhankelijkheden. Omdat de software nauw samenwerkt met specifieke GPU-drivers en rekenbibliotheken, is isolatie in een virtuele Python-omgeving noodzakelijk.

Voor algemene inzichten over de algemene basisprincipes van een lokale LLM op Linux kun je onze overzichtsgids raadplegen. Voor vLLM specifiek gelden de volgende uitgangspunten bij de installatie:

Het bouwen vanaf broncode is zelden nodig, tenzij er specifieke aanpassingen vereist zijn voor afwijkende hardware-architecturen. In de meeste gevallen volstaan de vooraf gecompileerde pakketten die zijn afgestemd op de corresponderende rekenplatform-versie.

De OpenAI-compatibele API-server starten

Een van de praktische voordelen van vLLM is de ingebouwde HTTP-server die de standaard OpenAI API-structuur volgt. Dit betekent dat bestaande software bibliotheken, frameworks en scripts zonder aanpassingen kunnen communiceren met het lokale vLLM-station door simpelweg de basis-URL aan te passen.

Bij het starten van de server is het belangrijk om een expliciete model-alias in te stellen. Standaard gebruikt de server het lokale bestandspad of de volledige repositorynaam als identificatiecode. Door via de serverconfiguratie een overzichtelijke naam toe te wijzen, ontkoppel je de interne opslagstructuur van de client-toepassingen. Clients roepen het model aan via deze logische naam, waardoor het onderliggende bestandspad op de server gewijzigd kan worden zonder dat externe applicaties gebroken worden.

Als je meer wilt lezen over hoe je lokale modellen veilig achter een API ontsluit, vind je op ons API-subdomein uitgebreide architectuurvoorbeelden.

De belangrijkste configuratieknoppen en hun afwegingen

Het standaardgedrag van vLLM is gericht op een balans tussen ondersteuning en stabiliteit, maar voor optimale prestaties moet de configuratie worden afgestemd op de beschikbare hardware en het verwachte gebruikspatroon. Hieronder staan de cruciale instellingen vermeld met de bijbehorende technische afwegingen.

Instelling / Concept Functie Afweging bij aanpassen
GPU Memory Fraction Bepaalt welk percentage van de totale VRAM gereserveerd wordt voor vLLM. Een te hoge waarde veroorzaakt Out-Of-Memory (OOM) fouten door randprocessen; een te lage waarde beperkt de beschikbare ruimte voor de KV-cache.
Max Model Length Stelt de maximale contextlengte (tokens) in die de server accepteert. Hogere waarden verbruiken per actief verzoek meer KV-geheugen, wat het maximaal aantal gelijktijdige verzoeken verlaagt.
Max Concurrent Sequences Begrenst het aantal reeksen dat gelijktijdig verwerkt mag worden in de batch. Voorkomt dat het geheugen overbelast raakt bij piekbelasting, maar verzoeken boven de limiet komen in een wachtrij te staan.
Tensor Parallel Size Splitst het model over meerdere fysieke GPU's binnen één systeem. Verhoogt het beschikbare geheugen en de rekencapaciteit, maar introduceert communicatie-overhead tussen de kaarten.

Concurrencie versus de maximale contextlengte

Een veelgemaakte fout bij het configureren van een vLLM-server is het automatisch instellen van de maximale contextlengte op de theoretische limiet van het model (bijvoorbeeld 32.000 of 128.000 tokens). Hoewel het model deze lengte ondersteunt, heeft het toewijzen van deze ruimte directe gevolgen voor de verwerkingscapaciteit.

De geheugenruimte die PagedAttention reserveert, schaalt met de ingestelde maximale lengte per verzoek. Als de server is geconfigureerd voor een extreme contextlengte, moet er per actieve sessie een grotere tabelstructuur worden bijgehouden. Dit gaat direct ten koste van de ruimte die beschikbaar is voor de KV-cache van ándere actieve sessies. Als de daadwerkelijke vragen van gebruikers gemiddeld slechts 2.000 tokens lang zijn, zorgt een instelling van 32.000 tokens voor onnodige geheugenclaims. Kies daarom een maximale lengte die aansluit bij het daadwerkelijke gebruik van de toepassing, zodat er VRAM vrijblijft om meer verzoeken parallel af te handelen.

Gekwantiseerde gewichten laden

Om grotere modellen op beperkte hardware te draaien, worden vaak gekwantiseerde gewichten toegepast. vLLM biedt ondersteuning voor diverse kwantisatiemethoden, waaronder formaten met 4-bit of 8-bit precisie, en gecomprimeerde FP8-representaties.

Het laden van gekwantiseerde gewichten verlaagt de geheugenafdruk van de modelparameters aanzienlijk. Hierdoor blijft er meer VRAM over voor de PagedAttention KV-cache, wat het aantal gelijktijdige verzoeken direct verhoogt. Er is echter een technische afweging: het decompileren of berekenen van gekwantiseerde gewichten vereist specifieke rekenondersteuning op de GPU. Voor een diepgaande uitleg over de voor- en nadelen van precisievermindering verwijzen we naar onze achtergrondgids over kwantisatie.

Let bij de instelling in vLLM op dat de gekozen kwantisatiemethode expliciet moet overeenkomen met het type gewichten dat is gedownload. Het meegeven van een onjuist kwantisatietype bij het starten kan leiden tot foutieve berekeningen of het mislukken van het opstartproces.

Meten in plaats van gokken: testen met belasting

Het optimaliseren van een vLLM-server kan niet plaatsvinden op basis van aannames. Omdat de prestaties afhangen van de interactie tussen de hardware, de modelgrootte en het type invoer, is een gestructureerde meetmethode noodzakelijk.

Om de capaciteit van de server vast te stellen, doorloop je de volgende stappen:

  1. Bepaal de basissnelheid (single-request): Stuur een enkel verzoek naar de server en meet de responstijd van het eerste token (Time to First Token of TTFT) en de verwerkingssnelheid per volgend token (Time per Output Token of TPOT). Dit vormt de Nulmeting.
  2. Schaal de belasting stapsgewijs op: Verhoog geleidelijk het aantal gelijktijdige verzoeken (concurrencie) met geautomatiseerde testscripts. Observeer het punt waarop de responstijden beginnen op te lopen.
  3. Analyseer percentielen: Kijk niet alleen naar het gemiddelde van de responstijden. Gemiddelden verbergen incidentele vertragingen. Richt je op het 95e en 99e percentiel (p95 en p99). Een stabiele server vertoont een lage spreiding tussen de mediaan (p50) en de p99-waarden onder normale belasting.

Voor een uitgebreid overzicht van evaluatiemethoden en hulpprogramma's raadpleeg je de gids over systematische methoden om inferentiesnelheid te meten.

Productie-inrichting als Linux-dienst

In een productie-omgeving moet de vLLM-server automatisch starten wanneer het systeem opstart en zichzelf herstellen bij eventuele crashes. Op Linux-systemen wordt dit ingericht via een systemd service-eenheid.

Een belangrijk aandachtspunt bij de productie-inrichting is de opstarttijd van het model. Omdat het inladen van tientallen gigabytes aan modelgewichten van de schijf naar het GPU-geheugen tijd kost, zal een nieuw gestarte vLLM-instantie niet direct verzoeken kunnen beantwoorden. Om te voorkomen dat het eerste verzoek van een gebruiker vastloopt op een opstarttijd van meerdere minuten, dient de opstartfase volledig te zijn afgerond voordat de server als 'gereed' wordt gemarkeerd.

Dit kan gerealiseerd worden door een zogenaamde 'warm-up call' op te nemen in de opstartprocedure. Nadat het proces gestart is, stuurt een lokaal script een minimaal testverzoek naar de interne interface. Pas wanneer dit verzoek een geldige respons oplevert, schakelt de overkoepelende netwerklaag het verkeer naar de vLLM-server door.

Beveiliging en netwerkarchitectuur

De ingebouwde HTTP-server van vLLM is ontworpen als een snelle inferentie-engine, niet als een geharde webserver voor het openbare netwerk. Het rechtstreeks blootstellen van de vLLM-poort aan het internet brengt serieuze veiligheidsrisico's met zich mee.

Hanteer de volgende principes bij het beveiligen van de serveromgeving:

Door de verwerkingslogica van vLLM te scheiden van de netwerkbeveiliging en het toegangsbeheer, ontstaat een infrastructuur die zowel hoge prestaties levert als voldoet aan standaard beveiligingseisen.

Lees ook