How Portable Are LLM-Serving Scheduler Rankings Across Workloads, Operating Regions, and Metrics?

In het moderne digitale landschap zijn large language models de motoren geworden achter een breed scala aan intelligente applicaties, van schrijfassistenten tot complexe programmeertools. Om deze systemen soepel te laten functioneren voor miljoenen gebruikers, vertrouwen ze op geavanceerde serverparken waar krachtige grafische processoren als het brein fungeren. Echter, deze processoren zijn dure en beperkte middelen. Wanneer duizenden mensen tegelijkertijd verzoeken versturen, moet de server beslissen welk verzoek het eerst wordt verwerkt, hoe ze gegroepeerd moeten worden en hoe het geheugen beheerd moet worden zodat geen enkele gebruiker het systeem verstopt terwijl anderen moeten wachten. Dit besluitvormingsproces wordt afgehandeld door een "scheduler", een stuk software dat fungeert als een verkeersregelaar, die constant de datastroom herstructureert om alles efficiënt te laten verlopen.

Jarenlang hebben onderzoekers nieuwe manieren voorgesteld om deze schedulers te verbeteren, waarbij ze beweerden dat hun methoden sneller of eerlijker zijn dan de bestaande. Maar deze claims zijn bijna altijd getest onder zeer specifieke omstandigheden: met gebruik van één specifiek type gebruikersverkeer, op één specifiek niveau van serverbelasting, en het succes gemeten met slechts één metriek. Dit creëert een blinde vlek. Een scheduler die perfect lijkt wanneer deze getest wordt op een rustige, voorspelbare stroom verzoeken, kan rampzalig falen wanneer deze wordt geconfronteerd met een plotselinge, chaotische uitbarsting van activiteit. De fundamentele vraag is onbeantwoord gebleven: als een scheduler als de beste wordt verklaard op basis van één specifieke dataset, blijft die rangschikking dan overeind wanneer het verkeer verandert, de belasting verschuift of de definitie van succes verandert?

Om dit te beantwoorden, ontwierp een onderzoeker van het New Jersey Institute of Technology een rigoureuze test genaamd de LLM-Serving Scheduler Portability Benchmark. In plaats van te vragen welke enkele scheduler de absolute beste is, stelde de studie een subtielere vraag: hoe draagbaar zijn de rangschikkingen van deze schedulers? Met andere woorden: als je de bron van het gebruikersverkeer, de intensiteit van de belasting of de manier waarop prestaties worden gemeten verandert, blijft de volgorde van de beste en slechtste schedulers dan hetzelfde, of kantelt deze? De onderzoeker bouwde een simulatie om dertien verschillende schedulingstrategieën te draaien tegen een enorme, bevroren collectie van 120 verschillende workload-vensters. Deze vensters waren afkomstig van drie onafhankelijke bronnen van real-world data: de cloudverkeer van Microsoft Azure, het Bailian/Qwen-platform van Alibaba en een grote dataset van Microsoft Azure-traces genaamd BurstGPT. Het systeem werd getest over zes verschillende operationele regio's, variërend van licht verkeer tot zware overbelasting, en werd geëvalueerd met meerdere prestatie-metrieken.

De resultaten onthulden dat het antwoord geen simpel ja of nee is. De rangschikkingen zijn niet universeel stabiel, noch zijn ze volledig chaotisch; ze hangen sterk af van welke specifieke combinatie van factoren je bekijkt. Bij het vergelijken van de rangschikkingen over de verschillende databronnen heen, vond de studie dat het verkeer van Microsoft Azure en Alibaba's Bailian/Qwen bijna perfect met elkaar overeenkwam. Als een scheduler de beste was op Azure, was hij vrijwel zeker ook de beste op Bailian/Qwen. Echter, de derde bron, BurstGPT, vertelde een ander verhaal. Wanneer BurstGPT in de vergelijking werd opgenomen, daalde de overeenstemming aanzienlijk, waarbij correlatiecoëfficiënten tot zo laag als 0,55 zakten. Dit suggereert dat een scheduler die alleen gevalideerd is op Azure-achtig verkeer, mogelijk niet naar verwachting presteert op BurstGPT-achtig verkeer, en vice versa.

De studie keek ook hoe vaak de rangschikkingen daadwerkelijk omdraaiden, wat betekent dat een scheduler die in het ene scenario beter was, in een ander scenario slechter werd. Van bijna duizend vergelijkingen vertoonden er slechts ongeveer 3,6 procent een omkering die zowel statistisch significant als groot genoeg was om in de praktijk van belang te zijn. Deze omkeringen waren niet gelijkmatig verspreid over alle condities; ze waren geconcentreerd in specifieke gebieden, met name wanneer het systeem onder zware belasting stond. Bovendien betrof elke een van deze significante omkeringen precies hetzelfde paar schedulingstrategieën en bevatte het altijd de BurstGPT-data aan de ene zijde. Dit geeft aan dat de instabiliteit geen algemeen gebrek aan het systeem is, maar een specifieke interactie tussen bepaalde schedulingmechanismen en de unieke kenmerken van die specifiekel verkeersbron.

Misschien wel de meest verrassende bevinding betrof de metrieken die gebruikt werden om prestaties te beoordelen. De onderzoekers testten of een scheduler die het hoogst rangschikte op één metriek, zoals het aantal voltooide verzoeken, ook het hoogst zou rangschikken op andere metrieken, zoals snelheid of eerlijkheid. Ze ontdekten dat de rangschikkingen verrassend fragiel waren wanneer de metriek veranderde. Gemiddeld was de overeenstemming tussen verschillende metrieken slechts matig, en in 68,1% van de testcondities veranderde de best presterende scheduler afhankelijk van de gebruikte metriek. Dit betekent dat een claim van "beste scheduler" vaak zwijgt over het specifieke doel dat wordt nagestreefd; een scheduler die geoptimaliseerd is voor snelheid, kan de slechtste keuze zijn voor eerlijkheid, en de rangschikking hangt er volledig vanaf wat de operator het meest waardeert.

Om er zeker van te zijn dat deze simulatieresultaten niet slechts artefacten waren van een computermodel, selecteerde de onderzoeker de meest dramatische omkering die in de simulatie werd gevonden en testte deze op echte fysieke hardware met behulp van een standaard grafische processor. De simulatie had voorspeld dat één scheduler zou winnen op het ene type verkeer en zou verliezen op het andere, een verschuiving in de rangschikking. Op de echte hardware gebeurde deze specifieke omkering echter niet; één scheduler won beide keren. Echter, een aparte test van een stabiele rangschikking, waarbij de simulatie geen verandering voorspelde, hield stand op de echte hardware. Dit suggereert dat hoewel de simulatie goed is in het identificeren van stabiele trends, het mogelijk niet elke specifieke omkering in de echte wereld perfect kan voorspellen, wat de grens aangeeft waar de getrouwheid van het model eindigt.

Uiteindelijk concludeert de studie dat er geen enkele, universele "beste" scheduler bestaat die in elke situatie werkt. De prestaties van een schedulingstrategie zijn voorwaardelijk. Het hangt af van de specifieke bron van het gebruikersverkeer, de huidige belasting van het systeem, de metriek die wordt gebruikt om succes te meten, en de specifieke definitie van een service-doel. Een rangschikking die solide lijkt op de ene dataset, kan niet zonder verificatie als waar worden aangenomen voor een andere. Voor ingenieurs en onderzoekers betekent dit dat het vergelijken van schedulers een veel bredere en zorgzamiger aanpak vereist dan simpelweg testen op een enkele dataset. De bevindingen verklaren geen winnaar, maar bieden eerder een kaart van waar de rangschikkingen betrouwbaar zijn en waar ze waarschijnlijk zullen veranderen, om ervoor te zorgen dat toekomstige evaluaties met de nodige context en voorzichtigheid worden gelezen.