FluidPD: Echtzeit-Ressourcenumschichtung zur Ausbalancierung von Prefill und Decode im LLM-Serving

Das Ungleichgewicht zwischen Prefill und Decode

Die Architektur für das Serving von Sprachmodellen (LLM) hat sich in Richtung der Trennung der Phasen Prefill und Decode entwickelt. Diese Disaggregation ermöglicht es, jede Phase unabhängig zu optimieren, da sie sehr unterschiedliche Ausführungsmuster und Service-Level-Objektive (SLO) aufweisen.

Allerdings sind reale Workloads nicht statisch. Kurze Lastspitzen und anhaltende Verschiebungen im Verhältnis der Nachfrage zwischen Prefill und Decode können eine zunächst gut dimensionierte Konfiguration schnell aus dem Gleichgewicht bringen. Diese Fehlanpassung führt zu SLO-Verletzungen bei der Latenz, selbst wenn andernorts im System ungenutzte Kapazität vorhanden ist.

Die Trennung von Prefill und Decode schafft zwar die Grundlage dafür, beide Phasen gezielt zu optimieren, beseitigt aber nicht die Abhängigkeit zwischen ihrer Auslastung. Entscheidend ist, ob die jeweils verfügbare Kapazität zur aktuellen Nachfrage passt: Eine Konfiguration kann für ein bestimmtes Verhältnis gut ausgelegt sein und dennoch an Leistungsgrenzen stoßen, sobald sich dieses Verhältnis verändert. Das im Ausgangstext beschriebene Problem betrifft daher nicht nur die Gesamtmenge an Rechenressourcen, sondern auch deren Verteilung auf die beiden Phasen.

Dabei unterscheiden sich kurzfristige Spitzen von länger anhaltenden Verschiebungen. Eine kurze Spitze kann die vorhandene Zuordnung vorübergehend überfordern, während eine dauerhafte Änderung ein anderes Verhältnis von Prefill- zu Decode-Kapazität verlangt. Werden beide Fälle ausschließlich mit derselben langsamen Reaktion behandelt, bleibt die Anpassung entweder zu träge oder ist für eine kurzfristige Abweichung unnötig umfangreich. Die Unterscheidung zwischen transitorischem und anhaltendem Ungleichgewicht bildet deshalb den Ausgangspunkt für die zwei getrennten Mechanismen von FluidPD.

In-Place-Elastizitätsmechanismen von FluidPD

FluidPD ist ein P/D-disaggregiertes Serving-System, das zwei komplementäre Mechanismen zur Bewältigung dieses Ungleichgewichts einführt. Der erste, FluidToken, adressiert transitorisches Ungleichgewicht, indem er einen begrenzten Teil der Prefill-Berechnung auf Decode-Worker auslagert, wenn dort freie Kapazität verfügbar ist.

Der zweite Mechanismus, FluidRole, verwaltet anhaltendes Ungleichgewicht, indem er laufende Worker zwischen den Rollen Prefill und Decode umschichtet. Diese Umschichtung erfolgt in-place, was das Neuladen des Modells und den Neustart der Inferenz-Engine vermeidet und eine viel schnellere Anpassung an Laständerungen ermöglicht.

FluidToken und FluidRole setzen an unterschiedlichen Zeitskalen des Ungleichgewichts an, statt dieselbe Art von Anpassung in zwei Varianten anzubieten. Bei FluidToken bleibt die bestehende Rollenzuordnung grundsätzlich bestehen: Ein begrenzter Anteil der Prefill-Berechnung wird auf Decode-Worker verlagert, sofern diese freie Kapazität haben. Der Mechanismus ist damit auf Situationen ausgerichtet, in denen eine vorübergehende Entlastung möglich ist, ohne die Rollen der Worker dauerhaft neu festzulegen. Die beschriebene Begrenzung der ausgelagerten Berechnung ist dabei wesentlich: FluidToken wird nicht als vollständige Verlagerung der Prefill-Last dargestellt.

FluidRole greift tiefer in die Zuordnung ein, indem laufende Worker zwischen Prefill und Decode umgeschichtet werden. Weil die Umschichtung in-place erfolgen soll, müssen dafür weder das Modell neu geladen noch die Inferenz-Engine neu gestartet werden. Das unterscheidet den Ansatz von der im Text beschriebenen traditionellen Skalierung über neue oder entfernte GPUs und erklärt, weshalb FluidPD die Rollenverteilung innerhalb der vorhandenen Worker anpassen kann. Daraus folgt jedoch nicht, dass jede Umschichtung ohne Aufwand oder für jede Infrastruktur verfügbar wäre: Die Architektur des Inferenzsystems muss die erforderlichen Operationen unterstützen.

Die Tabelle beschreibt somit nicht drei gleichartige Verfahren mit bloß unterschiedlichen Bezeichnungen, sondern drei unterschiedliche Eingriffe. FluidToken verschiebt vorübergehend einen begrenzten Rechenanteil, FluidRole ändert die Rolle vorhandener Worker, und traditionelles Autoscaling verändert die bereitgestellte GPU-Kapazität. Die angegebenen Unterschiede bei Reserve-GPUs und Modellneuladung beziehen sich auf diese beschriebenen Mechanismen; sie belegen für sich genommen weder, dass FluidPD in jedem Betrieb ohne zusätzliche Ressourcen auskommt, noch, dass eine konkrete Einsatzumgebung die nötigen In-place-Operationen bereits unterstützt.

Metriken und Evaluationsbedingungen

Die Autoren des Preprints berichten, dass FluidPD die globale SLO-Einhaltung gegenüber statischem SGLang um bis zu 94,6 Prozentpunkte verbessert. Diese Verbesserung wird unter Verwendung von Produktions-Workload-Traces von Azure evaluiert, was auf eine praktische Relevanz für Umgebungen im großen Maßstab hindeutet.

Es ist wichtig zu beachten, dass diese Metriken aus der Zusammenfassung des Preprints stammen und nicht unabhängig verifiziert wurden. Die Evaluation konzentriert sich auf die Fähigkeit des Systems, die SLOs einzuhalten, ohne zusätzliche Worker bereitzustellen, ein zentrales Ziel für die operative Effizienz.

Die berichteten 94,6 Prozentpunkte sind als Ergebnis der im Preprint beschriebenen Evaluation zu lesen, nicht als allgemeine Garantie für eine beliebige Serving-Konfiguration. Der Vergleich bezieht sich auf FluidPD und statisches SGLang in den untersuchten Szenarien mit Produktions-Workload-Traces von Azure. Aus dieser Angabe allein lässt sich weder ableiten, dass alle Arten von Anfragen denselben Vorteil erzielen, noch, dass sich der Wert auf andere Workloads oder Konfigurationen übertragen lässt. Die Formulierung „bis zu“ kennzeichnet zudem einen Höchstwert und nicht zwingend eine Verbesserung, die in jedem getesteten Fall erreicht wurde.

Auch die Einheit ist für die Einordnung wichtig: Eine Veränderung um Prozentpunkte beschreibt einen Unterschied zwischen Anteilen, nicht eine relative Steigerung um denselben Prozentsatz. Gemeint ist hier, dass der Anteil der Anfragen, die ihre jeweiligen Latenz-SLOs einhalten, in den berichteten Szenarien höher ausfiel als bei der statischen SGLang-Konfiguration. Der Preprint-Auszug liefert jedoch keine unabhängige Bestätigung dieses Befunds. Die Zahl sollte deshalb zusammen mit ihrem Vergleichspunkt, den verwendeten Azure-Traces und dem Vorbehalt zum nicht unabhängig geprüften Status gelesen werden.

Dass die Evaluation auf das Einhalten von SLOs ohne zusätzliche Worker zielt, macht sie für die Frage nach der Ressourcennutzung relevant. Es ersetzt aber keine umfassende Bewertung des Betriebsaufwands oder der Übertragbarkeit: Aus dem genannten Ergebnis allein geht nicht hervor, unter welchen weiteren Konfigurationen es erzielt wird oder welche Grenzen die Elastizität hat. Solche offenen Punkte sind von der berichteten Messgröße zu trennen, statt sie aus dem Ergebnis abzuleiten.

Operative Kosten und Abhängigkeiten

Die Strategie von FluidPD hängt von der Fähigkeit der Decode-Worker ab, einen Teil der Prefill-Last zu absorbieren (FluidToken) und von der Möglichkeit, Rollen ohne Neustart der Engine umzuschichten (FluidRole). Dies impliziert, dass die Architektur des Inferenzsystems diese Operationen nativ unterstützen muss.

Obwohl das System die Notwendigkeit von Reserve-GPUs vermeidet, sind die Geschwindigkeit der Umschichtung und die Effizienz der Berechnungsauslagerung kritische Faktoren. Wenn die Umschichtung nicht schnell genug erfolgt, könnte das Ungleichgewicht bestehen bleiben und SLO-Verletzungen verursachen, bevor sich das System stabilisiert.

Die behauptete Effizienz hängt davon ab, dass die beiden Mechanismen im vorgesehenen Umfeld tatsächlich ausgeführt werden können. Für FluidToken muss ein Decode-Worker freie Kapazität haben und einen begrenzten Teil der Prefill-Berechnung übernehmen können. Eine solche Verlagerung setzt dem beschriebenen Ansatz nach voraus, dass die vorhandene Architektur die nötige Zusammenarbeit zwischen den Phasen unterstützt. Ist die Zielkapazität nicht verfügbar, folgt aus der Beschreibung nicht, dass FluidToken die zusätzliche Prefill-Last dennoch auffangen kann.

Bei FluidRole liegt die operative Herausforderung in der zeitlichen Abstimmung: Ein anhaltendes Ungleichgewicht muss erkannt, ein geeigneter Worker für die Umschichtung gefunden und die Rolle in-place geändert werden. Die im Prozess genannten Druck-Indizes dienen dabei der Erkennung; der Text legt jedoch keine Schwellenwerte oder zeitlichen Garantien fest. Daher lässt sich aus dem vereinfachten Ablauf nicht bestimmen, wie schnell das System eine Änderung bemerkt oder wie lange es bis zur Anpassung dauert. Genau diese Geschwindigkeit ist wichtig, weil sich SLO-Verletzungen fortsetzen können, solange die Kapazität nicht passend verteilt ist.

Beide Mechanismen vermeiden nach der beschriebenen Gegenüberstellung Reserve-GPUs, aber sie lösen das Ungleichgewicht auf unterschiedliche Weise. Die verfügbare Kapazität eines Workers bleibt eine Voraussetzung für die Berechnungsauslagerung, während die Umschichtung die vorhandenen Rollen verändert. Die Aussage, dass keine Reserve-GPUs erforderlich sind, ist deshalb nicht mit der Aussage gleichzusetzen, dass jede Lastspitze ohne Folgen bewältigt wird. Der Ausgangstext nennt die Geschwindigkeit der Anpassung und die Effizienz der Auslagerung ausdrücklich als kritische Faktoren; bleiben sie hinter der Veränderung der Nachfrage zurück, kann das Ungleichgewicht fortbestehen.

Externe Tests und Produktivbetrieb

Bevor der Einsatz von FluidPD in der Produktion empfohlen wird, ist es notwendig, seine Leistung mit realen und vielfältigen Workloads zu bewerten, nicht nur mit Azure-Traces. Dies würde Tests mit verschiedenen Sprachmodellen, Batch-Größen und Traffic-Mustern umfassen.

Darüber hinaus muss die Verfügbarkeit von Code und Konfigurationen zur Reproduktion der Ergebnisse sowie die Grenzen der Elastizität des Systems überprüft werden. Das Fehlen einer unabhängigen Peer-Review und die Natur des Werks als Preprint erfordern zusätzliche Vorsicht bei der Interpretation seiner Leistungsansprüche.

Die vorgeschlagenen externen Tests sollen klären, ob sich die im Preprint beschriebene Leistung über die dort verwendeten Azure-Traces hinaus beobachten lässt. Dafür nennt der Ausgangstext unterschiedliche Sprachmodelle, Batch-Größen und Traffic-Muster. Diese Variationen sind relevant, weil die berichtete Verbesserung an eine bestimmte Evaluation gebunden ist und der vorliegende Text keine unabhängige Bestätigung für andere Konfigurationen enthält. Bis solche Prüfungen vorliegen, sollte der Befund daher als Ergebnis der beschriebenen Szenarien und nicht als Nachweis einer allgemeinen Leistungssteigerung behandelt werden.

Für eine reproduzierbare Bewertung wären außerdem der verfügbare Code und die erforderlichen Konfigurationen zu prüfen. Der Ausgangstext hält fest, dass hierzu keine ausreichenden Informationen vorliegen; es sollte daher weder angenommen werden, dass alle Bestandteile verfügbar sind, noch, dass sich die Ergebnisse bereits unabhängig reproduzieren lassen. Ebenso bleiben die Grenzen der Elastizität offen. Eine Prüfung müsste diese Unsicherheiten berücksichtigen, ohne aus den bislang genannten Kennzahlen weitere Einsatzgrenzen oder garantierte Fähigkeiten abzuleiten.

Die fehlende unabhängige Peer-Review ist ein zusätzlicher Grund, die Leistungsansprüche vorsichtig einzuordnen, aber kein Beleg dafür, dass die berichteten Ergebnisse falsch sind. Maßgeblich ist vielmehr, dass die Zahlen aus einem Preprint stammen, nicht unabhängig verifiziert wurden und mit den im Text genannten Evaluationsbedingungen verbunden sind. Eine Empfehlung für den Produktivbetrieb lässt sich aus diesen Angaben allein nicht ableiten; dafür wären die Kompatibilität mit der bestehenden Infrastruktur sowie die Reproduzierbarkeit und die Grenzen der Anpassung gesondert zu prüfen.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.