DOPD: A Dynamic PD-Disaggregation Architecture for Maximizing Goodput in LLM Inference Serving

DOPD is een dynamisch systeem voor het uitvoeren van LLM-inferentie dat de verhouding tussen voorafvul- en decoderingsinstanties aanpast op basis van real-time belasting om onbalans in heterogene werklasten op te lossen en zo de goodput en SLO-ervaring aanzienlijk verbetert ten opzichte van bestaande oplossingen.

De kern

De Probleemstelling: Een Restaurant met twee Keukens

Stel je voor dat je een groot restaurant runt dat alleen Grote Taalmodellen (LLMs) serveert. Dit zijn slimme AI's die vragen beantwoorden, net als een zeer beleefde, maar soms traag denkende kok.

In de wereld van AI bestaat er een probleem: het bereiden van een vraag heeft twee heel verschillende fases:

1. Het "Voorbereiden" (Prefill): De AI leest je hele vraag in. Dit is zwaar werk voor de rekenkracht (zoals het snijden van groenten en het opwarmen van de oven).
2. Het "Antwoorden" (Decoding): De AI schrijft woord voor woord het antwoord op. Dit is minder rekenwerk, maar vereist veel geheugen (zoals het bewaren van de ingrediënten in de koelkast).

Huidige situatie:
Veel restaurants proberen dit op één grote keuken (één GPU) te doen. Maar dat werkt slecht. Terwijl de kok groenten snijdt (rekenwerk), staat de koelkast leeg, en andersom. Het is alsof je één persoon vraagt om zowel te koken als te serveren; hij raakt in de war en het eten komt te laat.

De oplossing van anderen (PD-Disaggregatie):
Om dit op te lossen, hebben andere systemen (zoals DistServe) besloten om de keuken te splitsen in twee aparte ruimtes:

• De "Voorbereidings-keuken" (P-instances): Alleen maar groenten snijden en oven opwarmen.
• De "Servering-keuken" (D-instances): Alleen maar het eten op de borden leggen en naar de gasten brengen.

Dit klinkt slim, maar er zit een addertje onder het gras: De balans.

Het Dilemma: Te veel koks, te weinig serveerders (of andersom)

Stel je voor dat je 10 koks hebt in de voorbereidingskeuken, maar maar 1 serveerder in de servering-keuken.

• De koks snijden razendsnel groenten.
• De serveerder kan maar één bord per minuut afleveren.
• Resultaat: De koks staan urenlang te wachten met hun snijplanken (verspilde energie en geld), terwijl de serveerder overbelast raakt en gasten wachten.

Omgekeerd: Als je 10 serveerders hebt maar maar 1 kok, dan staan de serveerders te wachten op eten.

Het probleem: De hoeveelheid werk verandert voortdurend. Soms krijgen ze 100 korte vragen ("Wat is de weer?"), soms 10 lange vragen ("Schrijf een roman").

• Korte vragen zijn snel klaar in de voorbereidingskeuken.
• Lange vragen kosten daar veel tijd.

De meeste systemen zijn statisch. Ze hebben een vast aantal koks en serveerders. Als de situatie verandert, blijven ze vastzitten in hun oude verdeling. Dat is inefficiënt en duur.

De Oplossing: DOPD (De Slimme Restaurantmanager)

Het paper introduceert DOPD (Dynamic Optimal Prefill/Decoding). Dit is een slimme manager die dynamisch ingrijpt.

1. De Voorspeller (De Weerbericht-App)

DOPD kijkt niet alleen naar wat er nu gebeurt, maar probeert te voorspellen wat er binnenkort gaat gebeuren.

• Vergelijking: Het is alsof de manager naar de weersvoorspelling kijkt. Als er storm aankomt (veel vragen), schakelt hij extra personeel in voordat de gasten binnenstormen.
• Hij gebruikt historische data om te weten: "Over 5 minuten komen er waarschijnlijk veel korte vragen, of juist één hele lange."

2. De Optimale Verdeling (Het Aantal Koks en Serveerders)

Op basis van die voorspelling berekent DOPD precies hoeveel koks en serveerders er nodig zijn.

• Als er veel korte vragen komen, heeft hij minder koks nodig (want die zijn snel klaar) en meer serveerders.
• Als er lange vragen komen, heeft hij meer koks nodig.
• Het doel: Zorg dat niemand inactief staat en niemand overbelast is. Dit noemen ze de "Optimale P/D Ratio".

3. Slimme Invoer (De Wachtlijst)

Soms komen er vragen binnen die heel kort zijn (bijv. "Hallo").

• Huidig probleem: Als je zo'n korte vraag naar de "Voorbereidings-keuken" stuurt, duurt het transport van het bordje (de data) misschien langer dan het koken zelf. Dat is zonde.
• DOPD oplossing: DOPD is slim genoeg om te zeggen: "Deze korte vraag hoef je niet naar de aparte keuken te sturen. Laat de serveerder het direct doen." Of hij bundelt een paar korte vragen samen in één bakje (batching) zodat ze efficiënter worden verwerkt.

Wat levert dit op? (De Resultaten)

In de tests hebben ze DOPD vergeleken met de beste andere systemen (zoals vLLM en DistServe). Het resultaat was indrukwekkend:

• Snelheid: De tijd tot het eerste woord (TTFT) werd tot 67% sneller. Voor de gast betekent dit: je vraagt iets, en het antwoord komt er bijna direct.
• Efficiëntie: Het systeem haalt 1,5 keer meer werk uit dezelfde hoeveelheid hardware (GPU's). Dat is alsof je met 10 koks net zo veel eten maakt als met 15, maar dan sneller en goedkoper.
• Betrouwbaarheid: De kans dat een gast moet wachten of een foutmelding krijgt (SLO schendingen) daalde van 20% naar bijna 0%.

Samenvatting in één zin

DOPD is als een super-slimme restaurantmanager die voortdurend kijkt naar de aankomende gasten, precies het juiste aantal koks en serveerders inhuurt op het juiste moment, en korte bestellingen slim bundelt, zodat het restaurant altijd razendsnel werkt zonder dat er dure apparatuur stil staat.

Dit maakt het mogelijk om slimme AI's (zoals ChatGPT) veel goedkoper en sneller aan miljoenen mensen te leveren.

Technische samenvatting

Titel

DOPD: Een Dynamische PD-Disaggregatie Architectuur voor het Maximaliseren van Goodput bij LLM Inference Serving

1. Het Probleem

Grote Taalmodellen (LLMs) worden steeds complexer en vereisen zware GPU-resources. Om de verschillende reken- en geheugenvereisten van de twee fasen van inferentie (prefill en decoding) te hanteren, gebruiken state-of-the-art systemen een PD-Disaggregatie architectuur (Prefill-Decoding Disaggregation). Hierbij worden de berekeningen voor het "prefill"-stadium (rekenintensief) en het "decoding"-stadium (geheugenintensief) gescheiden op verschillende GPU-instanties (P-instanties en D-instanties).

Hoewel deze architectuur interferentie tussen de fasen vermindert, introduceert ze een kritiek probleem: ongebalanceerde productie en consumptie.

• Heterogeniteit van werklast: LLM-verzoeken variëren enorm in invoer- en uitvoerlengte.
• Statische toewijzing: Bestaande systemen gebruiken vaak statische verhoudingen tussen P- en D-instanties. Omdat de werklast dynamisch verandert, leidt dit tot:
  • Overprovisioning: GPU's staan stil (resource waste).
  • Onderprovisioning: SLO's (Service Level Objectives) worden geschonden en de gebruikerservaring verslechtert.
• Gemengde lengtes: Wanneer korte en lange verzoeken gemengd worden, kan een statische verdeling niet optimaal zijn voor beide, wat leidt tot wachtrijen en inefficiëntie.
• Voorspellingsmoeilijkheden: Het is moeilijk om de korte termijn werklast nauwkeurig te voorspellen vanwege bursts en variabele sequentielengtes.

2. Methodologie: DOPD

De auteurs stellen DOPD (Dynamic Optimal Prefill/Decoding) voor, een dynamisch inferentiesysteem dat de verhouding tussen P- en D-instanties continu aanpast op basis van real-time monitoring en voorspellingen.

Kerncomponenten en Technieken:

• Voorspelling van Werklast (ARIMA):
  DOPD gebruikt een ARIMA-model (AutoRegressive Integrated Moving Average) om op basis van historische telemetrie de toekomstige gemiddelde invoer/uitvoer-lengte en de concurrentie (aantal gelijktijdige verzoeken) te voorspellen. Een correctiefactor wordt toegepast om systematische bias tussen voorspelling en werkelijkheid te verminderen.

• Berekening van de Optimale P/D-Verhouding:
  Het systeem lost een optimalisatieprobleem op om de ideale verhouding te vinden die de totale GPU-gebruik minimaliseert terwijl SLO's (TTFT, TPOT, Goodput) worden gehaald.

  • Het modelleert de D-instantie als een consument die beperkt wordt door GPU-geheugenbandbreedte en capaciteit.
  • Het modelleert de P-instantie als een producent die beperkt wordt door rekencapaciteit.
  • Een analytische formule wordt gebruikt om het aantal P-instanties ($n_p$) en D-instanties ($n_d$) te berekenen zodat de productie van voltoorde prefill-verzoeken exact matcht met de consumptiecapaciteit van de D-instanties, waardoor wachttijden en idle tijd worden geminimaliseerd.

• Intelligente, Lengte-bewuste Scheduling:
  Om het probleem van gemengde verzoeklengtes aan te pakken, implementeert DOPD een slimme scheduler:

  • Korte verzoeken: Worden gebatcht tot een drempelwaarde (gebaseerd op de voorspelde gemiddelde lengte) om kernel-efficiëntie te maximaliseren.
  • Lange verzoeken: Worden direct verwerkt om wachttijden te voorkomen.
  • Ultra-korte verzoeken: Kunnen lokaal op de D-instantie worden verwerkt (PD-aggregatie) om de overdracht van KV-cache (Key-Value cache) tussen P- en D-instanties over te slaan, wat latentie verlaagt.

• Dynamische Schaalbaarheid:
  Het systeem past het aantal instanties elastisch aan zonder downtime. Als de voorspelde werklast toeneemt, worden instanties toegevoegd; bij afname worden ze verwijderd.

3. Belangrijkste Bijdragen

1. DOPD Framework: Een intelligent framework dat continu het aantal en de configuratie van P- en D-instanties afstemt op de werklast.
2. Analytisch Model: Een grondig systeemmodel dat de uitdagingen van PD-disaggregatie kwantificeert en een methode biedt om de optimale P/D-verhouding te berekenen.
3. Scheduling Algoritme: Een lengte-bewust algoritme dat resource-mismatchen door gemengde werklasten oplost.
4. Extensieve Validatie: Experimenten die aantonen dat DOPD significant beter presteert dan bestaande oplossingen onder realistische productieomstandigheden.

4. Resultaten

DOPD werd geëvalueerd op een cluster van 8 NVIDIA H100 GPU's met modellen zoals LLaMa-3.3-70B en OPT-30B, gebruikmakend van realistische werklasten (Microsoft Azure traces, BurstGPT).

• Goodput: DOPD verbeterde de algehele systeem-goodput met tot 1.5x vergeleken met vLLM (aggregatie) en DistServe (disaggregatie).
• Latentie:
  • P90 TTFT (Time To First Token) verlaagde met tot 67.5%.
  • P90 TPOT (Time Per Output Token) verlaagde met tot 22.8%.
• SLO Bereiking: DOPD behaalde een SLO-bereik van 99.4%, terwijl concurrente dynamische systemen (zoals DYN-LOAD en DYN-SLA) slechts 80.8% - 87.3% haalden.
• Resource Efficiency: Het systeem gebruikt minder GPU-resources om dezelfde SLO's te halen door het vermijden van overprovisioning en het maximaliseren van GPU-gebruik.

5. Betekenis en Impact

DOPD biedt een fundamentele oplossing voor het "producer-consumer" onbalansprobleem in gescheiden LLM-inferentiearchitecturen.

• Kostenefficiëntie: Organisaties kunnen LLM-diensten aanbieden met aanzienlijk lagere hardwarekosten door GPU-idle tijd te elimineren.
• Betrouwbaarheid: Door proactief te schalen op basis van voorspellingen, worden SLO-schendingen geminimaliseerd, wat cruciaal is voor productieomgevingen.
• Schaalbaarheid: De architectuur is ontworpen om naadloos te schalen naar grote clusters en is compatibel met bestaande frameworks (zoals Dynamo), wat de adoptie in industriële omgevingen vergemakkelijkt.

Kortom, DOPD bewijst dat dynamische, datagedreven resourcebeheer essentieel is om de volle potentie van PD-disaggregatie voor LLM's te benutten, vooral onder complexe en veranderlijke werklasten.