vLLM in productie op Kubernetes: een patroon voor soevereine deployment

Een modelserver starten is makkelijk; hem beheren als zakelijke dienst is het engineeringwerk. Dit artikel geeft een referentiearchitectuur voor vLLM op Kubernetes zonder willekeurige egress: GPU-workers, een interne gateway, een netwerk dat standaard alles weigert, monitoring, modelrollouts die als softwarereleases worden behandeld, en reservecapaciteit zonder piekcapaciteit in de publieke cloud. Het verbindt die werkwijzen met onderzoek naar containerorkestratie, LLM-serving en productierijpheid.

Trefwoorden vLLM · Kubernetes · model serving · egresscontrole · monitoring · rollouts

vllm serve draaien is makkelijk. Het beheren als zakelijke dienst is het echte engineeringwerk.

Een productiedeployment van vLLM heeft controles nodig voor de levenscyclus van modellen, authenticatie, observability, veilige uitrol, capaciteitsbeheer en foutafhandeling. In een soevereine omgeving is ook expliciete controle nodig over egress, modelopslag en bevoorrechte toegang.

Kubernetes bevat ontwerplessen uit meer dan tien jaar containerbeheer op grote schaal bij Google, verdeeld over drie opeenvolgende systemen^[1]; modelservers draaien als gewone, declaratief beheerde workloads is hier de reden om het te gebruiken. De servinglaag zelf komt uit systeemonderzoek: PagedAttention in vLLM beheert de key-value-cache als virtueel geheugen en meldt 2–4× hogere doorvoer dan eerdere systemen bij dezelfde latency^[2]. Voor het netwerk begint een houding die standaard alles weigert bij de zero-trust-architectuur zoals NIST die definieert^[3].

Onderzoek naar ML-operaties voegt twee waarschuwingen toe. ML-systemen bouwen verborgen technische schuld op buiten de modelcode^[4], en productierijpheid laat zich beter beoordelen met een expliciete rubric van tests en monitoring dan met een geslaagde demo^[5]. De werkwijzen voor uitrol en monitoring hieronder passen die ideeën toe op model serving.

Een praktisch patroon heeft vijf lagen:

1. GPU-workerlaag — vLLM-pods of -workloads op aparte acceleratornodes.
2. Interne gateway — authenticatie, rate limits, verzoekbeleid, streaming en modelroutering.
3. Modelopslag — objectopslag of persistente volumes die de organisatie beheert.
4. Observability — vLLM-metrics, gatewaytraces, applicatielogs en alerting.
5. Control plane — scheduling in Kubernetes, secrets, uitrolstrategie en infrastructuurbeleid.

De inferentiepods mogen geen willekeurige internettoegang nodig hebben om een verzoek te beantwoorden.

vLLM onderhoudt richtlijnen voor deployment op Kubernetes in CPU- en GPU-omgevingen en kan ook via verschillende stacks uit het ecosysteem worden geïntegreerd.

Houd de eerste versie van een eenvoudig soeverein ontwerp saai:

• een aparte GPU-nodepool;
• expliciete resource-requests en -limits;
• vastgezette versies van model en container;
• readiness- en startupchecks die rekening houden met de laadtijd van het model;
• services die alleen intern bereikbaar zijn;
• instellingen voor pod-disruption en uitrol die de capaciteit beschermen.

Het doel is voorspelbare werking, niet maximale platformcomplexiteit.

Stel de modelserver niet direct open voor elke interne applicatie.

Een interne gateway kan bieden:

• API-sleutels of workloadidentiteit;
• quota per team;
• audit logging;
• request-ID's en doorgifte van traces;
• modelaliassen en beheerste versiewissels;
• streamingbeleid;
• limieten voor promptgrootte en context;
• optionele DLP- of contentcontroles.

Zo wordt de levenscyclus van inferentie losgekoppeld van die van applicaties. Teams kunnen van model wisselen zonder elke client te herschrijven.

Soevereiniteit is makkelijker te overzien als inferentie kan draaien zonder uitgaande internettoegang.

Een gebruikelijk patroon is:

• containerimages intern spiegelen;
• modelgewichten vooraf klaarzetten in beheerde opslag;
• onnodige telemetrie uitschakelen;
• alleen expliciet goedgekeurde interne bestemmingen toestaan;
• een aparte, beheerste workflow gebruiken voor modelupdates.

Daardoor is het datapad te auditen en hangt u tijdens een verzoek minder af van een externe modelleverancier.

vLLM biedt productiemetrics via /metrics. Combineer die met telemetrie van de gateway en Kubernetes.

Let op:

• TTFT en generatielatency;
• wachtrijen van verzoeken;
• tokendoorvoer;
• geheugendruk en benutting van de GPU;
• aantal actieve reeksen;
• fouten bij het laden van modellen;
• herstarts van pods en OOM-gebeurtenissen;
• foutpercentage per modelversie.

Autoscaling moet een signaal volgen dat met echte verzadiging samenhangt — bijvoorbeeld de diepte van de queue of de gelijktijdigheid — en niet alleen het ruwe CPU-gebruik.

Een modelupdate kan de stijl van de output, de betrouwbaarheid van tools, de geldigheid van JSON of het veiligheidsgedrag veranderen, ook als het API-contract precies gelijk blijft.

Gebruik een beheerste uitrol:

1. registreer het nieuwe checkpoint;
2. draai offline evaluaties;
3. zet een canary-replica neer;
4. vergelijk latency en taakmetrics;
5. verschuif een klein percentage van het verkeer;
6. promoveer of draai terug;
7. bewaar het vorige artefact tot de acceptatie is afgerond.

Leg bij gekwantiseerde modellen zowel het basismodel als de kwantisatiepipeline vast.

Als een deployment niet kan uitwijken naar een publieke cloud, telt reserve voor onderhoud.

Ontwerp minstens voor de storingen die in uw omgeving aannemelijk zijn: één pod, één GPU, één node, een onderbreking van de opslag of een mislukte modeluitrol. Het juiste niveau van redundantie hangt af van hoe bedrijfskritisch de dienst is.

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

• Soevereine vLLM-deployment + checklist voor leveranciers
• GPU-dimensionering met vLLM voor soevereine inferentie
• Kwantisatie in vLLM: AWQ, GPTQ, FP8 en INT4
• Veelgestelde vragen over soevereine AI
• Soevereine LLM-deployment