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

In der modernen digitalen Landschaft sind große Sprachmodelle zu den Motoren hinter einer Vielzahl intelligenter Anwendungen geworden, von Schreibassistenten bis hin zu komplexen Codierungswerkzeugen. Damit diese Systeme für Millionen von Nutzern reibungslos funktionieren, verlassen sie sich auf hochentwickelte Serverfarmen, in denen leistungsstarke Grafikprozessoren als Gehirn fungieren. Diese Prozessoren sind jedoch teure und begrenzte Ressourcen. Wenn tausende Menschen gleichzeitig Anfragen senden, muss der Server entscheiden, welche Anfrage er zuerst bearbeitet, wie er sie gruppiert und wie er den Speicher verwaltet, damit kein einzelner Nutzer das System blockiert, während andere warten müssen. Dieser Entscheidungsprozess wird von einem „Scheduler“ gehandhabt, einem Stück Software, das wie ein Verkehrskontrolleur fungiert und ständig den Datenfluss neu ordnet, um alles effizient am Laufen zu halten.

Seit Jahren schlagen Forscher neue Wege vor, um diese Scheduler zu verbessern, und behaupten, ihre Methoden seien schneller oder fairer als bestehende. Doch diese Behauptungen wurden fast immer unter sehr spezifischen Bedingungen getestet: unter Verwendung einer einzigen Art von Nutzerverkehr, bei einem ganz bestimmten Niveau der Serverlast und unter Verwendung eines einzigen Metrik zur Erfolgsmessung. Dies schafft einen blinden Fleck. Ein Scheduler, der perfekt aussieht, wenn er an einem ruhigen, vorhersehbaren Strom von Anfragen getestet wird, könnte bei einem plötzlichen, chaotischen Ausbruch von Aktivität kläglich versagen. Die grundlegende Frage blieb unbeantwortet: Wenn ein Scheduler auf Basis eines bestimmten Datensatzes als der beste deklariert wird, bleibt dieses Ranking bestehen, wenn sich der Verkehr ändert, die Last verschiebt oder sich die Definition von Erfolg ändert?

Um dies zu beantworten, entwarf ein Forscher am New Jersey Institute of Technology einen strengen Test namens „LLM-Serving Scheduler Portability Benchmark“. Anstatt zu fragen, welcher einzelne Scheduler der absolut beste ist, stellte die Studie eine subtilere Frage: Wie portabel sind die Rankings dieser Scheduler? Mit anderen Worten: Wenn man die Quelle des Nutzerverkehrs, die Intensität der Last oder die Art und Weise, wie die Leistung gemessen wird, ändert, bleibt dann die Reihenfolge der besten und schlechtesten Scheduler gleich oder kehrt sie sich um? Der Forscher baute eine Simulation, um dreizehn verschiedene Scheduling-Strategien gegen eine massive, eingefrorene Sammlung von 120 verschiedenen Arbeitsfenstern (Workload Windows) zu testen. Diese Fenster stammten aus drei unabhängigen Quellen realer Daten: dem Cloud-Verkehr von Microsoft Azure, der Alibaba Bailian/Qwen-Plattform und einem großen Datensatz von Microsoft Azure-Traces namens BurstGPT. Das System wurde über sechs verschiedene Betriebsbereiche getestet, die von leichtem Verkehr bis hin zu schwerer Überlastung reichten, und unter Verwendung mehrerer Leistungsmetriken bewertet.

Die Ergebnisse zeigten, dass die Antwort kein einfaches Ja oder Nein ist. Die Rankings sind nicht universell stabil, aber auch nicht völlig chaotisch; sie hängen stark davon ab, welche spezifische Kombination von Faktoren man betrachtet. Beim Vergleich der Rankings über die verschiedenen Datenquellen hinweg stellte die Studie fest, dass der Verkehr von Microsoft Azure und Alibabas Bailian/Qwen fast perfekt übereinstimmte. Wenn ein Scheduler auf Azure der beste war, war er mit an Sicherheit grenzender Wahrscheinlichkeit auch auf Bailian/Qwen der beste. Die dritte Quelle, BurstGPT, erzählte jedoch eine andere Geschichte. Als BurstGPT in den Vergleich einbezogen wurde, sank die Übereinstimmung signifikant, wobei die Korrelationskoeffizienten auf bis zu 0,55 fielen. Dies deutet darauf hin, dass ein Scheduler, der nur auf Azure-ähnlichem Verkehr validiert wurde, auf BurstGPT-ähnlichem Verkehr möglicherweise nicht wie erwartet abschneidet und umgekehrt.

Die Studie untersuchte auch, wie oft sich die Rankings tatsächlich umkehrten, das heißt, dass ein Scheduler, der in einem Szenario besser war, in einem anderen schlechter wurde. Von fast tausend Vergleichen zeigten nur etwa 3,6 Prozent eine Umkehrung, die sowohl statistisch signifikant als auch praktisch bedeutsam war. Diese Umkehrungen waren nicht gleichmäßig über alle Bedingungen verteilt; sie konzentrierten sich auf spezifische Bereiche, insbesondere wenn das System unter schwerer Last stand. Darüber hinaus beinhaltete jede einzelne dieser signifikanten Umkehrungen dasselbe Paar von Scheduling-Strategien und enthielt auf einer Seite immer die BurstGPT-Daten. Dies deutet darauf hin, dass die Instabilität kein allgemeiner Fehler des Systems ist, sondern eine spezifische Interaktion zwischen bestimmten Scheduling-Mechanismen und den einzigartigen Merkmalen dieser speziellen Verkehrsquelle.

Die überraschendste Erkenntnis betraf die Metriken, die zur Leistungsbewertung verwendet wurden. Die Forscher testeten, ob ein Scheduler, der in einer Metrik, wie etwa der Anzahl der abgeschlossenen Anfragen, am höchsten rangierte, auch in anderen Metriken wie Geschwindigkeit oder Fairness am höchsten rangierte. Sie fanden heraus, dass die Rankings überraschend fragil waren, wenn sich die Metrik änderte. Im Durchschnitt war die Übereinstimmung zwischen verschiedenen Metriken nur moderat, und in 68,1 % der Testbedingungen änderte sich der am besten abschneidende Scheduler, je nachdem, welche Metrik verwendet wurde. Dies bedeutet, dass die Behauptung des „besten Schedulers“ oft stumm darüber bleibt, welches spezifische Ziel verfolgt wird; ein auf Geschwindigkeit optimierter Scheduler könnte die schlechteste Wahl für Fairness sein, und das Ranking hängt ganz davon ab, was der Betreiber am meisten wertschätzt.

Um sicherzustellen, dass diese Simulationsergebnisse nicht bloß Artefakte eines Computermodells waren, wählte der Forscher die dramatischste Umkehrung aus der Simulation aus und testete sie auf echter Hardware unter Verwendung eines Standard-Grafikprozessors. Die Simulation hatte vorhergesagt, dass ein Scheduler bei einer Art von Verkehr gewinnen und bei einer anderen verlieren würde – eine Umkehrung im Ranking. Auf der echten Hardware trat diese spezifische Umkehrung jedoch nicht auf; ein Scheduler gewann in beiden Fällen. Ein separater Test eines stabilen Rankings, bei dem die Simulation keine Änderung vorhergesagt hatte, erwies sich hingegen auf der echten Hardware als korrekt. Dies deutet darauf hin, dass die Simulation zwar gut darin ist, stabile Trends zu identifizieren, aber nicht jeden spezifischen Umschwung in der realen Welt perfekt vorhersagen kann, was die Grenze der Treue des Modells aufzeigt.

Letztendlich kommt die Studie zu dem Schluss, dass es keinen einzelnen, universellen „besten“ Scheduler gibt, der in jeder Situation funktioniert. Die Leistung einer Scheduling-Strategie ist konditional. Sie hängt von der spezifischen Quelle des Nutzerverkehrs, der aktuellen Last des Systems, der verwendeten Metrik und der spezifischen Definition eines Serviceziels ab. Ein Ranking, das auf einem Datensatz solide aussieht, kann nicht ohne Verifizierung als für einen anderen Datensatz gültig angenommen werden. Für Ingenieure und Forscher bedeutet dies, dass der Vergleich von Schedulern einen viel breiteren und sorgfältigeren Ansatz erfordert, als lediglich einen einzelnen Datensatz zu testen. Die Ergebnisse proklamieren keinen Gewinner, sondern liefern vielmehr eine Karte darüber, wo die Rankings zuverlässig sind und wo sie sich wahrscheinlich ändern werden, um sicherzustellen, dass zukünftige Bewertungen mit dem notwendigen Kontext und der nötigen Vorsicht gelesen werden.