💻 computer science

DriftSched: Adaptive QoS-Aware Scheduling under Runtime Token Drift for Multi-Tenant GPU Inference

Dit artikel presenteert DriftSched, een QoS-bewust planningsframework voor multi-tenant LLM-inferentie dat gebruikmaakt van een online feedbackmechanisme om fouten in de runtime-tokenestimatie te corrigeren, waarbij wordt aangetoond dat hoewel adaptieve kalibratie de estimatienauwkeurigheid aanzienlijk verbetert, het Shortest-Job-First (SJF) planningsbeleid de meest substantiële reducties in end-to-end en tail-latentie oplevert.

Oorspronkelijke auteurs: Kathiravan Palaniappan

Gepubliceerd 2026-06-03

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Kathiravan Palaniappan

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 een zeer populair restaurant runt met slechts één keuken (de GPU) en één chef. Je hebt drie soorten klanten:

VIP's (Premium): Die hun eten snel willen en bereid zijn extra te betalen.
Reguliere klanten (Standaard): Die gewoon een normale maaltijd willen.
Bulk Kopers (Batch): Die enorme cateringplaten bestellen en het niet erg vinden om te wachten.

Het probleem? De keuken raakt overbelast. Bestellingen stapelen zich op. Sommige mensen wachten eeuwig, terwijl anderen snel worden bediend. De chef moet beslissen wie er als volgende wordt bediend. Dit wordt "scheduling" genoemd.

Het kernprobleem: De werklast raden

Om te beslissen wie de volgende is, moet de scheduler weten hoeveel werk een bestelling hoeveelheid heeft.

Is het een eenvoudige salade (kort werkstuk)?
Of is het een complex 5-gangenmenu (lang werkstuk)?

Als de scheduler het fout raadt, ontstaat er chaos. Als de scheduler denkt dat een enorme cateringbestelling klein is, kan hij deze serveren vóór een snelle appetizer van een VIP, waardoor de VIP te lang moet wachten. Dit wordt "Workload Misclassification" genoemd.

De twee manieren om te raden

De paper, DriftSched, test twee manieren om te raden hoe groot een bestelling is:

De "Luie Gok" (Whitespace Proxy): Stel je voor dat je het aantal woorden op de bestelbon telt. Als er 10 woorden staan, is het waarschijnlijk klein. Als er 100 woorden staan, is het groot. Dit is snel en makkelijk voor de gastheer om te doen, maar het is onnauwkeurig. Een korte zin kan complex zijn om te bereiden, en een lange zin kan simpel zijn.
De "Expert Gok" (Tokenizer-Aware): Stel je voor dat de gastheer daadwerkelijk het recept leest en precies weet hoeveel ingrediënten en stappen erbij komen kijken. Dit is nauwkeurig, maar het kost de gastheer wat meer tijd en moeite om dit te berekenen.

De oplossing: DriftSched

DriftSched is een slim systeem dat dit restaurant beheert. Het heeft een speciale functie genaamd "Adaptive Calibration" (of EMA).

Denk er zo over na: Als de gastheer de "Luie Gok" gebruikt en merkt dat hij consequent de tijd die een "Technisch Rapport"-maaltijd kost onderschat, leert DriftSched van zijn fouten. Het zegt: "Ah, elke keer dat we een Technisch Rapport als klein inschatten, duurt het in werkelijkheid 20% langer. De volgende keer voeg ik 20% toe aan de schatting."

Na verloop van tijd wordt de "Luie Gok" bijna net zo goed als de "Expert Gok", omdat het systeem zijn eigen fouten corrigeert op basis van wat er daadwerkelijk in de keuken gebeurde.

De vijf scheduling-strategieën

De paper testte vijf regels om te beslissen wie er als volgende eet:

FIFO (First-In, First-Out): Zoals een standaard wachtrij. Wie het eerst komt, wordt het eerst bediend. Eerlijk, maar als een Bulk Koper voor je staat met een enorme bestelling, wacht je eeuwig.
Priority (Prioriteit): VIP's springen altijd voor in de rij. Reguliere klanten en Bulk Kopers moeten wachten. Geweldig voor VIP's, verschrikkelijk voor de rest.
Weighted (Gewogen): Een compromis. VIP's worden 50% van de tijd bediend, Reguliere klanten 30% en Bulk Kopers 20%. Iedereen krijgt een beurt, maar VIP's krijgen meer.
SJF (Shortest-Job-First): De chef kiest altijd de kleinste, snelste bestelling als volgende, ongeacht wie de bestelling plaatste. Als een Bulk Koper een klein bijgerecht heeft, wordt dit gekookt vóór het hoofdgerecht van een VIP.
Aging Priority (Verouderingsprioriteit): Zoals Priority, maar als een Bulk Koper te lang wacht, krijgt zijn bonnetje een "stempel" die zijn prioriteit verhoogt, zodat hij niet verhongert.

Wat hebben ze gevonden?

1. Nauwkeurigheid doet ertoe, maar de strategie is belangrijker
Het gebruik van de "Expert Gok" (Tokenizer) is beter dan de "Luie Gok" (Whitespace). Echter, de regel die je gebruikt om de volgende klant te kiezen (de Scheduling Policy) heeft een veel grotere impact op de wachttijden dan hoe nauwkeurig je de grootte van de bestelling hebt geraden.

2. SJF is de koning van de snelheid
De Shortest-Job-First (SJF) regel was de snelste. Het verminderde de gemiddelde wachttijd met ongeveer 42% vergeleken met de standaard wachtrij (FIFO). Waarom? Omdat door eerst alle kleine, snelle bestellingen af te handelen, de keuken druk en efficiënt blijft, en minder mensen vast komen te zitten achter één grote bestelling.

3. Priority is de koning van de VIP's
Als je om de VIP's wilt geven, is Priority Scheduling het beste. VIP's wachtten slechts ~77 seconden, terwijl Bulk Kopers ~427 seconden wachtten. SJF daarentegen gaf niet om wie je was; het gaf alleen om hoe klein je bestelling was. Sterker nog, onder SJF werden Bulk Kopers soms sneller bediend dan VIP's omdat hun bestellingen toevallig kleiner waren.

4. De "Luie Gok" kan worden gerepareerd
De zelfcorrigerende functie van het systeem (EMA) werkte goed. Wanneer het systeem de onnauwkeurige "Luie Gok" gebruikte, leerde het de schattingen over tijd aan te passen, waardoor fouten met ongeveer 40% werden verminderd. Echter, als je al de "Expert Gok" (Tokenizer) gebruikt, helpt zelfcorrectie niet veel omdat de gokken al nauwkeurig waren.

De essentie

Als je de snelste algemene service wilt: Gebruik SJF (Shortest-Job-First). Dit lost de wachtrij het snelst op.
Als je je belangrijkste klanten wilt beschermen: Gebruik Priority Scheduling. Dit garandeert dat VIP's als eerste worden bediend, zelfs als dit anderen langer laat wachten.
Maak je niet te veel zorgen over een perfecte gok: Zelfs als je een ruwe schatting maakt van hoe lang een bestelling duurt, is de scheduling-regel die je kiest (SJF vs. Priority) veel belangrijker voor de uiteindelijke wachttijd. Maar als je nauwkeurig kunt raden (met de Tokenizer), draait het systeem soepeler.

Kortom: Hoe je de klanten in de rij zet, is belangrijker dan hoe perfect je de grootte van hun bestelling inschat.

Technische Samenvatting: DriftSched

Probleemstelling
De snelle adoptie van Large Language Models (LLM's) heeft de vraag naar efficiënt multi-tenant GPU-scheduling in AI-datacenters geïntensiveerd. Hoewel moderne inference-runtimes zoals vLLM de doorvoer hebben geoptimaliseerd via continuous batching en geheugenbeheer, blijft het nauwkeurig schatten van de runtime-kosten van heterogene inference-verzoeken een aanzienlijke uitdaging. Bestaande scheduling-benaderingen vertrouwen doorgaans op statische tokenlimieten, door de gebruiker opgegeven output-restricties of vooraf gedefinieerde workload-aannames. Deze statische methoden slagen er niet in de dynamische aard van real-world LLM-workloads te vatten, waarbij de geobserveerde outputlengtes frequent afwijken van de verwachte waarden vanwege promptcomplexiteit, responskenmerken en modelgedrag.

Het paper identificeert deze discrepantie als runtime token drift. Dit fenomeen introduceert schattingsfouten die doorwerken in scheduling-beslissingen, wat leidt tot workload-misclassificatie, wachtrij-imbalans, opgeblazen tail-latency, oneerlijke toewijzing van resources aan tenants en gedegradeerde Quality-of-Service (QoS) onder GPU-contentie. Traditionele scheduling-algoritmen (bijv. FIFO, SJF), ontworpen voor systemen met voorspelbare executiekosten, worstelen in multi-tenant LLM-omgevingen waar runtime-gedrag afhankelijk is van dynamische factoren zoals KV-cache groei en batching-dynamiek.

Methodologie en Systeemarchitectuur
Om deze uitdagingen aan te pakken, stellen de auteurs DriftSched voor, een adaptief QoS-bewust scheduling framework ontworpen voor multi-tenant LLM-inference op NVIDIA L4 GPU's. De systeemarchitectuur integreert workload-classificatie, token-budget schatting, tenant-bewuste wachtrijbeheer en een runtime feedback-gestuurd drift-compensatiemechanisme.

Adaptieve Token Schatting: In tegenstelling tot statische benaderingen schat DriftSched de inference-kosten voorafgaand aan de GPU-executie door workload-classificatie, tenant-bewuste veiligheidsfactoren en promptcomplexiteit te combineren. Cruciaal is dat het een adaptieve bias-factor ( $B_{runtime}$ ) gebruikt die continu wordt bijgewerkt met behulp van execution feedback. Het geschatte output token aantal wordt berekend als:
$T_{estimated\_output} = T_{base} \times B_{runtime} \times S_{tenant} \times F_{input}$
waarbij $B_{runtime}$ wordt geleerd uit de ratio van geobserveerde outputlengtes ten opzichte van baseline-schattingen.
Workload Classificatie en Queuing: Inference-verzoeken worden geclassificeerd in semantische categorieën (short_qa, summary, technical, report) en toegewezen aan runtime scheduling-klassen (short, medium, long) op basis van het geschatte tokenbudget. Verzoeken worden toegewezen aan tenant-specifieke wachtrijen (Premium, Standard, Batch) die via Redis worden beheerd.
Scheduling Strategieën: Het framework evalueert vijf scheduling-policies: First-Come First-Serve (FIFO), Priority Scheduling, Weighted Scheduling, Shortest-Job-First (SJF) en Aging Priority Scheduling.
Feedback Loop: Het systeem werkt in twee fasen: een kalibratiefase (de eerste 1.000 verzoeken) om runtime feedback te verzamelen en bias-factoren te laten convergeren, en een stress-evaluatiefase (de resterende 2.000 verzoeken) waarbij de scheduler de geleerde bias-waarden gebruikt terwijl hij doorgaat met online adaptatie. De adaptieve update-regel gebruikt een Exponential Moving Average (EMA) om bias-factoren te verfijnen op basis van de afwijking tussen geschatte en geobserveerde token-aantallen.

Belangrijkste Bijdragen

Adaptieve Drift-Bewuste Architectuur: Een nieuw scheduling framework dat workload-schatting behandelt als een runtime token drift-compensatieprobleem, waarbij bias-factoren dynamisch worden bijgewerkt om voorspellingen af te stemmen op geobserveerd gedrag.
Runtime Token Drift Compensatiemechanisme: Een feedback-gestuurde methode die de schattingsfout vermindert door continu geschatte tokenbudgets te vergelijken met werkelijke outputlengtes, wat de nauwkeurigheid van de scheduling tijdens de admission-tijd verbetert.
Reproduceerbaar Benchmarking Framework: Een uitgebreide evaluatieopstelling met behulp van vLLM op NVIDIA L4 GPU's, die heterogene multi-tenant verkeer simuleert met variërende promptcomplexiteiten en aankomstfrequenties om eerlijkheid, latency en doorvoer te beoordelen.

Experimentele Resultaten
Experimenten werden uitgevoerd met 3.000 inference-verzoeken over drie tenant-tiers en vier semantische workload-typen op een NVIDIA L4 GPU.

Bestaan van Token Drift: De studie bevestigde meetbare runtime token drift over workload-categorieën heen. Statische token-budget schatting overschatte consistent het werkelijke generatiegedrag.
Schatting Nauwkeurigheid: Het adaptieve feedbackmechanisme verminderde de workload-schattingsfout met gemiddeld 38,8% (MAE) en 40,5% (RMSE) over alle geëvalueerde scheduling-policies vergeleken met statische baselines.
Latency Prestaties: Onder de scheduling-policies behaalde Shortest-Job-First (SJF) de beste algehele prestaties. Vergeleken met FIFO reduceerde SJF de mediane (P50) end-to-end latency met ongeveer 42% en de P99 latency met ongeveer 16%. Deze verbetering werd toegeschreven aan de prioritering van kortere workloads en een verminderde wachtrij-bezetting.
Trade-offs: Hoewel SJF de globale latency optimaliseerde, boden tenant-bewuste schedulers (Priority, Weighted, Aging) sterkere QoS-differentiatie voor Premium-tenants. Bijvoorbeeld, Priority scheduling reduceerde de latency voor Premium-tenants tot ~77 seconden, maar verhoogde de latency voor Batch-tenants naar ~427 seconden.
GPU Utilisatie: Analyse toonde aan dat GPU execution latency en geheugengebruik relatief constant bleven over alle scheduling-policies heen. Dit geeft aan dat de prestatieverschillen voortkwamen uit wachtrijbeheer en workload-ordening in plaats van veranderingen in de GPU-executie-efficiëntie.

Betekenis en Claims
Het paper claimt dat runtime token drift een meetbaar en praktisch significant fenomeen is in multi-tenant LLM-serving systemen. De primaire betekenis van DriftSched ligt in de demonstratie dat adaptieve feedback-gestuurde schatting de workload-karakterisering en scheduling-effectiviteit onder GPU-contentie aanzienlijk kan verbeteren.

De auteurs stellen dat hun bevindingen praktische inzichten bieden voor enterprise AI-serving platforms, waarbij ze benadrukken dat nauwkeurige runtime workload-schatting cruciaal is voor toekomstige adaptieve inference-runtimes. Het werk complementeert bestaande architecturen (bijv. Orca, Sarathi, vLLM) door adaptieve workload-schatting als een extra scheduling-signaal te introduceren. De studie concludeert dat hoewel workload-bewuste scheduling (zoals SJF) de tail-latency aanzienlijk vermindert, dit gepaard gaat met een trade-off met de fairness op tenant-niveau, wat suggereert dat toekomstige systemen een balans moeten vinden tussen globale efficiëntie en service-level garanties. Het paper merkt bescheiden op dat de evaluatie werd uitgevoerd op een enkel GPU-platform en model, en dat toekomstig werk multi-GPU scenario's en reinforcement learning-gebaseerde scheduling zal verkennen.