💻 computer science

Load Testing for Machine Learning Model Serving Systems at Scale

Dit artikel introduceert \sys, een industrieel load testing-framework dat een adaptieve, feedbackgestuurde zoekstrategie gebruikt om systematisch de GPU-capaciteit voor ML-serving systemen te schatten, waarbij het via 14 casestudies aantoont dat het de resource-efficiëntie en operationele betrouwbaarheid aanzienlijk verbetert door schattingsfouten te verminderen en SLO-schendingen te voorkomen.

Oorspronkelijke auteurs: Amr S. Abdelfattah, Nakul Tirumalai, Indu Mohanan, Xiao Li, Pengchao Wang, Dinakar Dhurjati, Eric Sung

Gepubliceerd 2026-06-23

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Amr S. Abdelfattah, Nakul Tirumalai, Indu Mohanan, Xiao Li, Pengchao Wang, Dinakar Dhurjati, Eric Sung

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je de manager bent van een enorme, high-tech restaurantkeuken. Deze keuken kookt geen eten; deze verwerkt miljoenen complexe wiskundige problemen per seconde met behulp van krachtige grafische kaarten (GPU's) om AI-modellen te draaien.

Het grote probleem? Je weet niet precies hoeveel chefs (GPU-bronnen) je nodig hebt.

Als je er te weinig aanneemt, raakt de keuken overbelast, lopen bestellingen vertraging op en worden klanten boos (dit wordt het schenden van "Service Level Objectives" of SLO's genoemd).
Als je er te veel aanneemt, betaal je voor lege stoelen en luie chefs, wat een enorme verspilling van geld en energie is.

Lange tijd was het bepalen van het juiste aantal chefs een gokspelletjes spelen. Dit artikel introduceert een nieuw systeem genaamd Vanguard, dat fungeert als een superintelligente "stress-test" manager om het perfecte aantal chefs te vinden.

Zo werkt Vanguard, uitgelegd via eenvoudige analogieën:

1. Het probleem met oude tools

Standaard stress-testing tools (zoals JMeter of k6) zijn als generieke fitnessinstructeurs. Ze zijn geweldig voor het testen van een mens die op een loopband rent, maar ze begrijpen de eigenaardigheden van een AI-keuken niet.

Het "Warmup"-probleem: Wanneer je een high-performance GPU aanzet, is het als een racewagenmotor. De motor moet een paar minuten opwarmen, onderdelen cachen en klaar worden. Als je het direct test, lijkt het traag en loom. Oude tools denken dat de motor kapot is; Vanguard weet dat de motor moet opwarmen voordat de snelheid beoordeeld kan worden.
Het "Batching"-probleem: AI-systemen groeperen vaak verzoeken samen (zoals een bus die passagiers oppikt) om efficiënt te zijn. Als de bus halfleeg is, is hij snel. Als hij vol is, kan hij misschien langzamer worden. Deze relatie is geen rechte lijn; het is een curve. Oude tools gaan uit van een rechte lijn; Vanguard begrijpt de curve.
Het "Hardware"-probleem: Een model kan perfect draaien op het ene type GPU, maar moeite hebben met een ander type. Vanguard test de specifieke hardware die je daadwerkelijk gebruikt.

2. Hoe Vanguard werkt: De "Smart Search"

In plaats van gewoon een getal te raden en te hopen op het beste, gebruikt Vanguard een feedbackgestuurde zoekstrategie. Denk aan het afstemmen van een radio om de duidelijkste zender te vinden.

De Adaptieve Zoekopdracht: Vanguard begint met een laag aantal verzoeken. Het draait het volume langzaam omhoog (voegt meer verzoeken toe).
Demping (De Schokdemper): Naarmate het dichter bij de limiet komt waarbij het systeem zou kunnen crashen, vertraagt het de stappen. Het trapt niet plotseling op de rem; het neemt de snelheid geleidelijk terug om te voorkomen dat het de limiet overschiet.
Spike Tolerance (Ruis negeren): Soms heeft het systeem een kleine, tijdelijke hik (een "spike"). Een dom systeem zou kunnen panikeren en de test stoppen. Vanguard negeert deze kleine schommelingen, wetende dat het slechts ruis is, en gaat door totdat het een echt, aanhoudend probleem ziet.
Convergentie (Weten wanneer te stoppen): Het blijft testen totdat het zeker weet dat het de "sweet spot" heeft gevonden—het maximale aantal verzoeken dat het systeem kan afhandelen zonder zijn beloftes aan de gebruiker te breken.

3. De "Health Check" Engine

Vanguard kijkt niet naar slechts één getal (zoals snelheid). Het kijkt naar een dashboard van vitale functies, vergelijkbaar met een arts die een patiënt controleert.

Het controleert of het systeem Gezond is (voldoende ruimte om te ademen).
Het controleert of het in Waarschuwing staat (dicht bij de limiet komen).
Het controleert of het in Kritieke toestand is (op het punt staan te crashen).
Om valse alarmen te voorkomen (zoals een glitch in een hartslagmonitor), gebruikt het een "hysteresis"-regel: het systeem moet enkele minuten in een "Waarschuwing"-toestand blijven voordat het systeem officieel verklaart dat het in de problemen zit. Dit voorkomt paniek over tijdelijke glitches.

4. Wat ze ontdekten (De Resultaten)

Het team heeft Vanguard getest op 14 verschillende AI-modellen (zoals aanbevelingsmotoren, beeldherkenners en tekstgeneratoren) bij Meta. Dit is wat ze leerden:

Echt verkeer is koning: De grootste fout die mensen maken, is het gebruik van nep, verzonnen data om te testen. Het paper vond dat het gebruik van opgenomen echt wereldverkeer (het herafspelen van werkelijke gebruikersverzoeken) de fouten verminderde van 30% naar slechts 2–6%. Het is het verschil tussen het testen van een auto op een glad circuit versus het testen van een auto op de werkelijke hobbelige weg waar hij op zal rijden.
Warmup is essentieel: Het negeren van de "warmup"-periode veroorzaakte een fout van 22% in de voorspellingen. Je kunt de topsnelheid van een auto niet beoordelen op het moment dat je de sleutel omdraait.
Het "Crowded Room"-effect: Wanneer meerdere modellen dezelfde GPU delen (co-locatie), interfereren ze met elkaar, zoals mensen die over elkaar heen praten in een drukke kamer. Dit is een belangrijke bron van fouten die moeilijk te voorspellen is.
Nauwkeurigheid: Met alle juiste instellingen voorspelde Vanguard de capaciteit met 94% nauwkeurigheid.
Impact in de echte wereld: Door Vanguard te gebruiken, kon het bedrijf de verspilling van GPU-bronnen verminderen met 15% tot 83% voor verschillende modellen en het aantal keren dat hun services crashten door onderbezetting aanzienlijk verminderen.

5. De Belangrijkste Conclusie

Het paper concludeert dat je niet zomaar generieke tools kunt gebruiken om AI te testen. Je hebt een gespecialiseerde aanpak nodig die begrijpt:

Warmup: Laat het systeem eerst opwarmen voordat je test.
Echte Data: Test met echt verkeer, niet met nepdata.
Slimme Geduld: Panikeer niet bij kleine glitches; kijk naar aanhoudende trends.

Door deze regels te volgen, kunnen bedrijven enorme hoeveelheden geld besparen op hardware terwijl ze hun services snel en betrouwbaar houden.

Technische Samenvatting: Belastingtesten voor Machine Learning Model Serving Systemen op Schaal

Probleemstelling

Het serveren van machine learning (ML) modellen is een dominante consument geworden van GPU-infrastructuur, maar capaciteitsplanning voor deze systemen blijft grotendeels ad hoc. Traditionele belastingtesttools (bijv. JMeter, Locust) en benchmark-suites (bijv. MLPerf) slagen er niet in de unieke kenmerken van ML-inferentie aan te pakken, wat leidt tot twee kritieke problemen:

Onder-provisionering: Resulteert in schendingen van Service-Level Objectives (SLO's), een verslechterde gebruikerservaring en productie-incidenten.
Over-provisioning: Verspilt aanzienlijke GPU-bronnen die voor andere workloads gebruikt kunnen worden.

Het artikel identificeert vier specifieke uitdagingen die algemene tools niet aanpakken:

Model Warmup: GPU-inferentie omvat JIT-compilatie, CUDA-kernel caching en het laden van gewichten, wat zorgt voor een transiënte prestatie die niet representatief is voor de steady state.
Dynamic Batching: Moderne serving-systemen batchen verzoeken, wat een niet-lineaire relatie creëert tussen gelijktijdige belasting en latency per verzoek.
Architecturale Heterogeniteit: Systemen moeten diverse modellen afhandelen (van sub-milliseconde lookups tot multi-seconde generatieve outputs), wat verschillende benaderingen voor testen vereist.
Hardwaregevoeligheid: Prestaties variëren significant over verschillende GPU-generaties, geheugenconfiguraties en co-locatiepatronen.

Methodologie: Het Vanguard Framework

De auteurs presenteren Vanguard, een industrieel belastingtestframework dat systematisch de serving-capaciteit schat via een adaptieve, feedbackgestuurde zoekstrategie.

Systeemarchitectuur

Vanguard is een gedistribueerd systeem bestaande uit tien kerncomponenten:

Orchestratie & Executie: Een Task Orchestrator beheert de levenscyclus van tests, terwijl een Load Replayer gecontroleerde verkeersstromen genereert met behulp van een open-loop ontwerp om 'coordinated omission' te voorkomen (waarbij verwerkingsvertragingen de nieuwe verzoekgeneratie onderdrukken, waardoor de werkelijke latency wordt gemaskeerd).
Strategy Engine: Implementeert het strategy pattern om zoekalgoritmen te ontkoppelen. Het ondersteunt baseline-strategieën (Multi-Rate Sweep, Binary Search, Constant-Rate Stability) en de kern: de Adaptive Feedback-Driven Search.
Health Assessment Engine: Brengt ruwe metrieken (latency, throughput, foutpercentages, GPU-utilisatie) in kaart naar vijf gezondheidstoestanden (Healthy, Warn, Unhealthy, Critical, Overloaded). Het maakt gebruik van multi-metric weighting en hysteresis (vereist dat toestanden gedurende opeenvolgende vensters aanhouden) om "flapping" nabij capaciteitsgrenzen te voorkomen.
Infrastructuur: Omvat een Model Registry voor versiebeheer van artefacten, een Capacity Allocator voor resource-provisioning en een Telemetry Logger voor reproduceerbaarheid.

Adaptieve Zoekstrategie

De kernbijdrage is een adaptief algoritme dat realtime metriek-feedback gebruikt om te convergeren naar de maximale duurzame throughput. Het hanteert drie mechanismen:

Dampening: Vermindert de stapgrootte naarmate de zoektocht de capaciteitsgrens nadert om overshooting te voorkomen.
Spike Tolerance: Negeert transiënte metriek-spikes onder een configureerbare drempelwaarde om voortijdige convergentie te voorkomen.
Convergence Detection: Monitort de variantie van recente schattingen; de zoektocht eindigt wanneer de coëfficiënt van variatie onder een drempelwaarde valt.

Experimenteel Ontwerp

De studie evalueert Vanguard over 14 industriële casestudies verspreid over vier architectuurklassen: Recommendation, Ranking, Vision en NLP.

Ground Truth: Gedefinieerd als de P90 Inference-Per-Second (IPS) gemeten in de steady state over een 7-daags venster na de lancering, waarbij incidentperioden en de initiële ramp-up zijn uitgesloten.
Variabelen: De studie vergelijkt synthetische versus opgenomen verkeersreplay, verschillende hardware (A100 vs. H100), en ablatie studies waarbij ML-specifieke functies (zoals warmup-afhandeling, batching-bewustzijn) zijn uitgeschakeld.
Statistische Analyse: Gebruikt non-parametrische tests, Bland-Altman analyse voor overeenstemming en multivariate lineaire regressie om foutfactoren te identificeren.

Belangrijkste Resultaten

1. Reproduceerbaarheid

Vanguard-metingen zijn zeer reproduceerbaar op identieke hardware (Intra-class Correlation Coefficient = 0,96, Coefficient of Variation = 2,9%). Echter, cross-hardware tests (A100 vs. H100) tonen een systematische positieve bias van 4,9%, wat wijst op de noodzaak van hardware-specifieke correctiefactoren.

2. Impact van ML-specifieke Ontwerbeslissingen (RQ1)

Een ablatie studie toonde aan dat specifieke ML-bewuste functies cruciaal zijn voor nauwkeurigheid:

Workload Calibration: Het overschakelen van synthetisch verkeer naar recorded traffic replay verminderde de schattingsfout van ~30% naar 2–6%. Dit was de grootste winst in nauwkeurigheid.
Warmup Handling: Het correct uitsluiten van de transiënte warmup-periode verminderde de fout met 22,2%.
Andere Factoren: GPU-gezondheidsmonitoring, multi-metric SLO's en batching-bewustzijn droegen ook significant bij aan verbeterde nauwkeurigheid (elk 7–14% foutreductie).

3. Nauwkeurigheid van Capaciteitsvoorspelling (RQ2)

Algehele Nauwkeurigheid: Vanguard-schattingen kwamen nauw overeen met de geobserveerde post-launch capaciteit met een gemiddelde bias van −2,1% (lichte onderschatting, wat operationeel wenselijk is) en 95% grenzen van overeenstemming van [−14,8%, +10,6%]. De correlatie was sterk ( $R^2 = 0,94$ ).
Foutvoorspellers: Regressieanalyse identificeerde Model Size (log-getransformeerd aantal parameters) en Co-location Density (aantal co-tenanted modellen) als de sterkste voorspellers van schattingsfout. Grotere modellen vertonen variabel warmup-gedrag, terwijl co-locatie workloads interferentie introduceren die niet wordt gevangen in geïsoleerde tests.

Betekenis en Bijdragen

Het artikel beweert de eerste empirische studie te zijn van belastingtesten specifiek voor ML-model serving op schaal. De betekenis ligt in:

Het overbruggen van de kloof: Het adresseert de disconnect tussen traditionele belastingtesten en de specifieke behoeften van ML-capaciteitsplanning, door een framework te bieden dat dynamic batching, warmup en hardwaregevoeligheid afhandelt.
Industriële Impact: In 14 casestudies leidde de inzet van Vanguard tot:
- Een reductie van de schattingsfout van 30% naar 2–6%.
- Reducties in GPU-resources van 49–83% voor individuele modellen door het elimineren van over-provisioning.
- Een substantiële vermindering van lancering-incidenten veroorzaakt door onder-provisioning.
Actiegerichte Richtlijnen: De auteurs distilleren zes lessen voor beoefenaars, waarbij ze benadrukken dat workload representativiteit (gebruik van opgenomen verkeer) en warmup-afhandeling impactvoller zijn dan algoritmische verfijning. Ze benadrukken ook de noodzaak van hysteresis in gezondheidsbeoordeling en het belang van het rekening houden met co-locatie effecten.

Het artikel concludeert dat hoewel de adaptieve strategie effectief is voor huidige architecturen, toekomstig werk nodig is om generatieve modellen (LLM's) aan te pakken, die unieke uitdagingen presenteren met betrekking tot variabele outputlengtes en KV-cache druk.