SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference

Diese Arbeit schlägt einen hybriden Ansatz vor, der theoretische Modellierung mit empirischem Benchmarking kombiniert, um die optimale Anzahl von Prefill- und Decode-Ressourcen für die LLM-Inferenz unter Berücksichtigung von Durchsatzanforderungen, SLOs und Anfragecharakteristika zu bestimmen.

Das Wesentliche

Stellen Sie sich vor, Sie betreiben eine riesige, hochmoderne Bäckerei, die spezielle, komplexe Brotrezepte (die sogenannten "Large Language Models" oder LLMs) für Kunden backt.

In der alten Art der Bäckerei gab es nur einen einzigen Bäcker pro Ofen. Dieser Bäcker musste zwei Dinge tun:

1. Den Teig kneten und vorbereiten (das ist das "Prefill"-Phase, wo das Modell den Prompt des Kunden liest und versteht).
2. Das Brot backen und aus dem Ofen holen (das ist die "Decode"-Phase, wo das Modell Wort für Wort antwortet).

Das Problem war: Wenn der Teig kneten muss, kann er nicht gleichzeitig backen. Und wenn er backt, kann er nicht kneten. Wenn viele Kunden gleichzeitig kommen, staut sich alles. Entweder wartet der Kunde ewig auf den ersten Bissen (zu lange Wartezeit), oder das Brot kommt zu langsam aus dem Ofen (zu langsame Antwort).

Die neue Lösung: Die getrennte Bäckerei (P/D Disaggregation)

Die Autoren dieses Papiers schlagen vor, diese Bäckerei aufzuteilen. Man hat jetzt zwei verschiedene Teams:

• Team Teig (Prefill): Spezialisiert darauf, den Teig schnell zu kneten.
• Team Backen (Decode): Spezialisiert darauf, das Brot schnell zu backen.

Das ist super effizient, aber es bringt ein neues Problem mit sich: Wie viele Mitarbeiter braucht man in welchem Team?

• Wenn Sie zu viele "Teig-Kneter" und zu wenige "Bäcker" haben, warten die fertigen Teige nur rum, und die Bäcker sind überlastet.
• Wenn Sie zu viele Bäcker und zu wenige Kneter haben, stehen die Bäcker nur herum und warten auf Teig.

Das Ziel ist es, genau die richtige Anzahl an Mitarbeitern zu finden, damit:

1. Der Kunde nicht zu lange auf den ersten Bissen wartet (SLO: Time-To-First-Token).
2. Die Antwort schnell genug fließt (SLO: Time-Per-Output-Token).
3. Niemand unnötig Geld für überflüssige Mitarbeiter ausgegeben wird.

Die Magie der Berechnung (Die Methode des Papiers)

Bisher mussten Bäckereibesitzer raten oder einfach alles ausprobieren, bis es passte. Dieses Papier liefert eine kluge Formel, die Theorie und Praxis verbindet, um die perfekte Anzahl zu berechnen.

Hier ist, wie sie es machen, einfach erklärt:

1. Die Theorie (Der Bauplan)

Zuerst schauen sie sich an, wie viel Brot insgesamt verkauft werden soll (der "Durchsatz"). Sie wissen, wie viel Teig pro Kunde nötig ist (Eingabelänge) und wie groß das fertige Brot sein soll (Ausgabelänge).

• Analogie: Wenn Sie wissen, dass 100 Kunden kommen, jeder 500g Teig braucht und 200g Brot will, wissen Sie grob, wie viel Gesamtarbeit zu erledigen ist.

2. Das "Teig-Team" (Prefill) und die Wartezeit

Das Team Teig muss schnell arbeiten, damit der Kunde nicht wartet. Aber: Wenn das Team zu schnell arbeiten soll, müssen sie oft pausieren oder warten, bis der nächste Kunde kommt.
Die Autoren nutzen eine mathematische Theorie (M/M/1-Warteschlangen), um zu berechnen: "Wenn der Kunde maximal 2 Sekunden warten darf, wie viel Teig kann das Team in dieser Zeit wirklich verarbeiten, ohne dass es chaotisch wird?"

• Analogie: Es ist wie an der Kasse im Supermarkt. Wenn die Kasse zu schnell bedient sein soll, aber die Kunden nur alle 10 Minuten kommen, ist die Kasse 90% der Zeit leer. Die Theorie hilft zu berechnen, wie viel "echte" Arbeit bei einer bestimmten Wartezeit möglich ist.

3. Das "Back-Team" (Decode) und die Geschwindigkeit

Beim Backen ist es anders. Hier kann man mehrere Brote gleichzeitig in den Ofen schieben (Batching). Aber je mehr Brote gleichzeitig im Ofen sind, desto länger dauert es, bis das erste fertig ist.
Die Autoren haben einfach gemessen: "Wie viele Brote können wir gleichzeitig backen, damit das erste Brot immer noch innerhalb von 20 Millisekunden fertig ist?"

• Analogie: Wie viele Pizza-Steine passen in den Ofen, bevor die Pizza so lange braucht, dass der Kunde ungeduldig wird? Sie messen das einfach und finden den perfekten Punkt.

4. Das Ergebnis: Der perfekte Mix

Sobald sie wissen, wie viel das Teig-Team und wie viel das Back-Team unter diesen strengen Zeitregeln schaffen können, setzen sie die Zahlen in ihre Formel ein.
Das Ergebnis sagt ihnen genau: "Für 5 Millionen Brote pro Stunde brauchen Sie genau 3 Teig-Teams und 4 Back-Teams."

Warum ist das wichtig?

Ohne diese Methode würden Unternehmen entweder:

• Zu viel Geld ausgeben: Sie kaufen zu viele teure Grafikkarten (die "Mitarbeiter"), die nur herumstehen.
• Zufriedenheitsprobleme haben: Sie haben zu wenige Mitarbeiter, die Kunden warten zu lange oder bekommen schlechte Antworten.

Die Autoren haben ihre Methode in der echten Welt getestet (mit einer echten KI namens DeepSeek). Das Ergebnis war beeindruckend: Ihre Berechnung sagte genau voraus, wie viele Ressourcen man braucht, um die Versprechen an die Kunden (SLOs) einzuhalten, ohne einen einzigen Euro für unnötige Hardware zu verschwenden.

Zusammenfassend:
Dieses Papier ist wie ein perfekter Rezeptplan für KI-Bäckereien. Es sagt Ihnen nicht nur, wie man den Teig knetet oder das Brot backt, sondern genau, wie viele Köche Sie in jeder Station brauchen, damit die Küche fließt, die Kunden glücklich sind und der Chef kein Geld verbrennt.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „SLO-Aware Compute Resource Allocation for Prefill-Decode Disaggregated LLM Inference" auf Deutsch:

Problemstellung

Die Inferenz von Large Language Models (LLMs) wird zunehmend durch die Prefill-Decode (P/D) Disaggregation optimiert. Dabei werden die rechenintensiven Prefill-Phase (Verarbeitung des Eingabe-Inputs) und die speicherbandbreitenlimitierte Decode-Phase (Generierung von Tokens) auf separate Hardware-Instanzen ausgelagert. Dies ermöglicht eine unabhängige Optimierung von Service Level Objectives (SLOs) wie der Time-To-First-Token (TTFT) und der Time-Per-Output-Token (TPOT).

Trotz der Verfügbarkeit von Frameworks wie vLLM, SGLang oder TensorRT-LLM fehlt es der Industrie an einer etablierten Methodik, um die optimale Anzahl an Hardware-Ressourcen (d.h. das genaue Verhältnis von Prefill- zu Decode-GPUs) für eine gegebene Arbeitslast zu bestimmen. Eine falsche Zuordnung führt entweder zu einer Unterauslastung der Ressourcen (hohe Kosten) oder zum Verfehlen der SLO-Anforderungen. Bestehende Tools wie NVIDIAs AIConfigurator nutzen suchbasierte Ansätze, liefern aber keine umfassende, analytische Methode zur Berechnung der Ressourcenmenge unter Berücksichtigung von Durchsatz und SLOs.

Methodik

Die Autoren schlagen einen hybriden Ansatz vor, der theoretische Modellierung mit empirischen Benchmarks kombiniert, um die optimale P/D-Ressourcenzuweisung präzise zu berechnen. Der Prozess gliedert sich in drei Hauptschritte:

1. Theoretisches Ressourcenmodell:
   Basierend auf den vom Benutzer spezifizierten Anforderungen (Gesamtdurchsatz, mittlere Eingabe- und Ausgabelängen) wird ein mathematisches Modell entwickelt, um die Anzahl der Prefill- ($N_{prefill}$) und Decode-Instanzen ($N_{decode}$) zu bestimmen.

   • Die Gesamtzeit $T_{total}$ wird durch die maximale der beiden Phasen bestimmt. Um Leerlauf zu vermeiden, müssen die Berechnungszeiten für Prefill und Decode gleich sein.
   • Daraus wird ein Verhältnis $R_{P/D}$ abgeleitet, das nur von den Eingabe-/Ausgabelängen und den jeweiligen Durchsätzen der Instanzen abhängt.

2. Ermittlung des Prefill-Durchsatzes unter TTFT-Beschränkungen:
   Um den tatsächlich erreichbaren Prefill-Durchsatz unter Einhaltung der TTFT-SLO zu bestimmen, wird der Prefill-Prozess als M/M/1-Warteschlangenmodell modelliert.

   • Zuerst wird der maximale Prefill-Durchsatz ($\tilde{TP}_{prefill}$) durch Benchmarks ohne Leerlauf ermittelt.
   • Unter Berücksichtigung der Ziel-TTFT und der Overhead-Zeiten (Netzwerk, KV-Cache-Transfer) wird die Systemauslastung ($\rho$) berechnet.
   • Der effektive Durchsatz wird dann als $TP_{prefill} = \tilde{TP}_{prefill} \times \rho$ abgeleitet. Dies zeigt, dass strengere TTFT-Anforderungen zu einer niedrigeren effektiven Auslastung führen.

3. Ermittlung des Decode-Durchsatzes unter TPOT-Beschränkungen:
   Für die Decode-Phase wird der Zusammenhang zwischen Batch-Größe, Durchsatz und TPOT empirisch ermittelt.

   • Da TPOT und Durchsatz positiv mit der Batch-Größe korrelieren, wird eine Benchmark-Kurve erstellt.
   • Die maximale Batch-Größe, die die TPOT-SLO einhält, wird identifiziert, woraus sich der effektive Decode-Durchsatz ergibt.

Wesentliche Beiträge

• Theoretisches Modell: Entwicklung einer Formel zur Berechnung der P/D-Instanzanzahl basierend auf Gesamtdurchsatz, SLOs, Request-Längen und den erzielbaren Durchsätzen der einzelnen Phasen.
• Warteschlangenmodellierung: Anwendung der M/M/1-Theorie auf den Prefill-Prozess, um den effektiven Durchsatz unter TTFT-Zwängen aus dem maximalen Benchmarkedurchsatz abzuleiten.
• Empirische Validierung: Nutzung von Messdaten zur Bestimmung des optimalen Decode-Batch-Größen, um den TPOT-Durchsatz zu maximieren, ohne SLOs zu verletzen.
• Präzise Vorhersage: Nachweis, dass diese Methode in realen Szenarien die optimale Ressourcenverteilung genau vorhersagen kann, was sowohl Kosteneffizienz als auch strikte SLO-Einhaltung sicherstellt.

Ergebnisse

Die Methode wurde in einem realistischen Inferenz-Szenario mit dem Modell DeepSeek-V3.1-Terminus auf NVIDIA H200 GPUs validiert.

• Szenario: Ziel war ein Gesamtdurchsatz von 5 Millionen Tokens pro Minute (M TPM) bei einer TTFT von 2 Sekunden und einer TPOT von 20 ms.
• Berechnung: Basierend auf den gemessenen Durchsätzen und den SLOs berechnete das Modell ein Verhältnis von Prefill zu Decode von 0,82:1.
• Empfohlene Konfiguration: Das Modell schlug eine 3P4D-Konfiguration (3 Prefill-Instanzen, 4 Decode-Instanzen) vor.
• Validierung:
  • Die 3P4D-Konfiguration erreichte den Ziel-Durchsatz von ~4,8 M TPM, wobei beide SLOs (TTFT und TPOT) gleichzeitig eingehalten wurden.
  • Zum Vergleich führte eine 3P3D-Konfiguration nur bis ~3,6 M TPM, da die TPOT-SLO hier zum Engpass wurde, obwohl die TTFT noch Spielraum hatte.
  • Die Effizienz pro Node lag bei 3P4D bei 0,69 M TPM im Vergleich zu 0,6 M TPM bei 3P3D.

Bedeutung und Ausblick

Dieses Paper schließt eine kritische Lücke im Betrieb von disaggregierten LLM-Systemen. Es bietet Cloud-Anbietern und Entwicklern eine wissenschaftlich fundierte, berechenbare Methode zur Dimensionierung ihrer Infrastruktur, anstatt sich auf grobe Schätzungen oder zeitaufwändige Suchverfahren zu verlassen.

Die vorgeschlagene Methode maximiert die Ressourcennutzung bei garantierter Einhaltung der Service-Level-Agreements. Zukünftig könnte dieser Ansatz mit Tools wie AIConfigurator integriert werden, um nicht nur die Anzahl, sondern auch die optimale Konfiguration einzelner Instanzen zu bestimmen. Zudem besteht Potenzial für eine Erweiterung auf multimodale Systeme mit EPD-Disaggregation (Encoder-Prefill-Decode).