Parallelization Strategies for Dense LLM Deployment: Navigating Through Application-Specific Tradeoffs and Bottlenecks

Dit artikel onderzoekt parallelisatiestrategieën voor de implementatie van dichte grote taalmodellen, waarbij het aantoont dat Tensor Parallelism de latentie verbetert terwijl Pipeline Parallelism beter geschikt is voor doorvoeroptimalisatie, en hoe een hybride aanpak de afweging tussen deze twee prestatie-indicatoren kan sturen.

De kern

Stel je voor dat je een gigantische, superintelligente robot hebt die verhalen kan schrijven, code kan programmeren en vragen kan beantwoorden. Dit is een Groot Taalmodel (LLM), zoals de Llama-modellen waar dit onderzoek over gaat. Deze robots zijn zo groot dat ze niet in één computer passen; ze zijn te zwaar voor het geheugen van één enkele videokaart (GPU).

Om deze robot te laten werken, moeten we hem op een speciale manier "opsplitsen" over meerdere computers die samenwerken. Dit artikel onderzoekt hoe we dat het beste kunnen doen, zodat de robot snel reageert (laag vertraging) én veel mensen tegelijk kan bedienen (hoge doorvoer).

Hier is de uitleg in simpele taal, met wat creatieve vergelijkingen:

1. Het Probleem: De Te Zware Koffer

De robot (het model) is als een enorme koffer vol met kennis. Deze koffer is te zwaar voor één persoon (één videokaart) om te dragen. Als je hem probeert te tillen, breekt je rug (het geheugen is vol).

Om dit op te lossen, moeten we de koffer openmaken en de inhoud verdelen over een team van dragers (meerdere videokaarten). Maar hoe je die koffer verdeelt, maakt een enorm verschil voor hoe snel het team werkt.

2. De Twee Strategieën: Het Teamwerk

De auteurs van dit artikel kijken naar twee hoofdmanieren om dit team te organiseren: Tensor Parallelism (TP) en Pipeline Parallelism (PP).

Strategie A: Tensor Parallelism (TP) – "Het Snelheidsduo"

Stel je voor dat je een gigantisch puzzelstuk moet snijden. Bij TP nemen alle dragers tegelijk deel aan het snijden van één enkel stuk.

• Hoe het werkt: Elke drager houdt een klein stukje van hetzelfde puzzelstuk vast. Ze werken razendsnel samen om dat ene stuk te maken, en dan zetten ze het weer samen.
• Voordeel: Het is ontzettend snel voor één vraag. De robot denkt heel snel na. Dit is perfect als je wilt dat de robot direct reageert (bijvoorbeeld in een chat).
• Nadeel: Omdat ze constant met elkaar moeten praten om hun stukjes te synchroniseren, kost het veel energie als je te veel mensen tegelijk wilt bedienen. Het is als een groepje dat constant schreeuwt om te overleggen; dat remt de totale productie af als de groep te groot wordt.

Strategie B: Pipeline Parallelism (PP) – "De Assemblagelijn"

Stel je nu voor dat je een fabriek hebt. Bij PP verdelen we de puzzel in verschillende stations.

• Hoe het werkt: Drager 1 doet de eerste stap, geeft het door aan Drager 2, die de tweede stap doet, enzovoort. Terwijl Drager 2 werkt aan vraag A, begint Drager 1 al met vraag B.
• Voordeel: Je kunt veel vragen tegelijk afhandelen. Het is als een assemblagelijn in een autofabriek: er is altijd iemand aan het werk. Dit is geweldig voor doorvoer (veel tokens per seconde).
• Nadeel: Voor de eerste vraag duurt het even voordat hij klaar is, omdat die vraag door alle stations moet reizen. Het is alsof je wacht tot het eerste stukje de fabriek uitkomt voordat je het hebt.

3. De Grote Ontdekking: Snelheid vs. Aantal Klanten

De onderzoekers hebben ontdekt dat je niet kunt winnen op beide fronten tegelijk zonder compromissen:

• Wil je snelheid (lage vertraging)? Kies dan voor TP. Het is alsof je een Formule 1-auto hebt: hij is razendsnel, maar je kunt er maar één in zetten.
• Wil je capaciteit (veel klanten tegelijk)? Kies dan voor PP. Het is als een bus: hij is misschien niet zo snel als de Formule 1, maar hij kan 50 mensen tegelijk vervoeren.

De verrassing:
Als je te veel mensen probeert te bedienen met TP (te veel dragers die samenwerken aan één ding), begint de communicatie (het schreeuwen) zo veel tijd te kosten dat het juist weer trager wordt.
Bij PP kun je heel veel vragen tegelijk verwerken, maar als de vragen te complex worden, stopt de fabriek ook wel eens met versnellen omdat de machines (de rekenkracht) hun maximale snelheid bereiken.

4. De Oplossing: De Mix (Hybride)

De beste oplossing is vaak een combinatie.
Stel je een restaurant voor:

• Je hebt een snelle chef (TP) die direct een gerecht voor een VIP-klant klaarmaakt.
• Je hebt een efficiënte keukenlijn (PP) die honderden maaltijden tegelijk voorbereidt voor de rest van de zaal.

Door de grootte van het team (TP) en het aantal stations (PP) slim te regelen, kun je precies bepalen of je meer wilt focussen op snelheid voor de ene klant of op het bedienen van een volle zaal.

5. Conclusie in Eén Zin

Dit artikel leert ons dat er geen "perfecte" manier is om een supergrote AI te laten werken. Je moet kiezen:

• Tensor Parallelism is je vriend als je snelheid wilt (minder wachttijd).
• Pipeline Parallelism is je vriend als je capaciteit wilt (meer mensen bedienen).
• De kunst is om een mix te vinden die past bij wat je precies nodig hebt, net zoals je een auto kiest die past bij je rit: een sportauto voor snelheid of een bus voor vervoer.

De onderzoekers hebben dit allemaal gemeten en geanalyseerd om te laten zien hoe je die "knoppen" draait om de beste resultaten te krijgen voor jouw specifieke situatie.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "Parallelization Strategies for Dense LLM Deployment: Navigating Through Application-Specific Tradeoffs and Bottlenecks", vertaald en samengevat in het Nederlands.

Probleemstelling

De snelle opkomst van generatieve AI en Large Language Models (LLM's) heeft geleid tot een explosie van toepassingen die gebaseerd zijn op transformer-architecturen. Hoewel dichte modellen (dense LLM's) waarin alle parameters voor elke token worden geactiveerd, nog steeds de toonaangevende keuze zijn vanwege hun generalisatievermogen en veelzijdigheid, stellen ze enorme eisen aan de hardware.

• Geheugennood: Modellen zoals Llama-3.1-405B vereisen honderden gigabytes aan geheugen, wat de capaciteit van een enkele GPU (zelfs high-end modellen zoals de MI325x of H200) overstijgt.
• Latentie vs. Throughput: Er bestaat een inherente afweging tussen latentie (reactietijd) en doorvoer (tokens per seconde). Optimalisatie voor de ene gaat vaak ten koste van de andere.
• Onvoldoende kennis: Bestaande parallelisatiestrategieën (zoals Tensor Parallelism en Pipeline Parallelism) worden vaak los van elkaar bestudeerd. Er ontbreekt een systematische evaluatie van hoe deze strategieën, in combinatie met batchgrootte, invoerkarakteristieken en modelgrootte, de prestaties beïnvloeden en waar de knelpunten liggen voor het voldoen aan Service Level Agreements (SLA's).

Methodologie

De auteurs hebben een uitgebreide empirische studie uitgevoerd met de volgende aanpak:

1. In-house Simulator: Ze hebben een eigen simulator ontwikkeld die de end-to-end inferentie van LLM-werklasten modelleert. Deze simulator is gevalideerd tegen echte hardware (AMD MI325x en MI355x GPUs) en toont een hoge nauwkeurigheid (>90% voor prefill, >86% voor decode op single-GPU; iets lager bij diepe parallelisatie door dynamische voltage-frequentie variaties).
2. Doelmodellen: De studie focust op twee representatieve dichte modellen: Llama-3.1-70B en Llama-3.1-405B (gekwantiseerd in respectievelijk FP8 en 4-bit).
3. Datasets: Er zijn diverse datasets gebruikt om zowel korte als lange contexten te simuleren:
   • Korte context: BBH, GSM8K, HumanEval.
   • Lange context: LongAlpaca, MLPerf (met prompts van Longbench, GovReport, Ruler).
4. Parallelisatiestrategieën: De auteurs hebben drie hoofdstrategieën en hun hybride varianten geanalyseerd:
   • Tensor Parallelism (TP): Splitsing van lagen (GEMM, attention) over meerdere GPUs binnen een node.
   • Pipeline Parallelism (PP): Splitsing van transformer-blokken over verschillende GPUs (inter-layer).
   • Hybride TP & PP: Een combinatie van beide.
5. Metingen: De prestaties zijn gemeten aan de hand van Time-to-First-Token (TTFT), Time-per-Output-Token (TPOT) en Throughput (Tokens Per Second - TPS).

Belangrijkste Bijdragen

• Kernel-level analyse: Een gedetailleerde mapping van hoe transformer-lagen worden toegewezen aan GPUs onder verschillende parallelisatieschema's.
• Kwantificering van trade-offs: Een systematische kwantificering van hoe batchgrootte, parallelisatiediepte en invoereigenschappen de latentie en doorvoer beïnvloeden.
• Identificatie van bottlenecks: Het blootleggen van de specifieke beperkingen die de prestaties bepalen, zoals de overhead van all-reduce operaties bij TP en de communicatiekosten bij PP.
• Hybride aanbevelingen: Het tonen van hoe het combineren van TP en PP een afstelbare balans biedt tussen latentie en doorvoer.

Resultaten en Bevindingen

1. Latentie (TTFT en TPOT)

• Tensor Parallelism (TP) is superieur voor latentie: TP reduceert zowel TTFT als TPOT aanzienlijk in vergelijking met PP of geen parallelisatie. Door rekenkracht te verdelen over meerdere GPUs, wordt de uitvoering van transformer-lagen versneld.
  • Voorbeeld: TP8 (8 GPUs) is aanzienlijk sneller dan TP4 of TP2.
• Pipeline Parallelism (PP) biedt geen latentie-voordeel: PP verdeelt de blokken over GPUs, maar vermindert niet de rekentijd per blok. De P2P-communicatie tussen pipeline-stadia voegt zelfs een kleine overhead toe, waardoor TTFT en TPOT vaak iets slechter zijn dan bij non-parallelle setups of TP.
• Communicatie-overhead: Bij TP is de all-reduce operatie een significant latentie-knelpunt. Hoewel diepere TP-setup (meer GPUs) de rekentijd verlaagt, neemt de communicatie- overhead toe. Bij multi-node systemen wordt dit een nog groter probleem.

2. Doorvoer (Throughput / TPS)

• Pipeline Parallelism (PP) is superieur voor doorvoer: PP staat toe dat grotere batches (nano-batches) tegelijkertijd worden verwerkt door verschillende pipeline-stadia. Dit maximaliseert de GPU-uitlast, vooral tijdens de decode-fase die vaak geheugen-bound is.
  • Voorbeeld: PP8 kan batches van 512 tokens verwerken, terwijl een data-parallelle setup zonder PP beperkt is tot veel kleinere batches door geheugenbeperkingen.
• Tensor Parallelism (TP) degradeert doorvoer: Hoewel TP de latentie verlaagt, introduceert het all-reduce operaties die de totale doorvoer verlagen, vooral bij grote batches. De winst in rekentijd wordt niet lineair gecompenseerd door de communicatiekosten.
• Hybride gebruik: Een combinatie van TP en PP biedt de beste flexibiliteit. TP kan worden gebruikt om de latentie te beheersen (door de TP-degree te verhogen), terwijl PP wordt gebruikt om de doorvoer te maximaliseren (door de PP-depth te verhogen).

3. Invloed van Invoer en Modelgrootte

• Lange context: Bij datasets met lange invoer (zoals LongAlpaca) domineert de prefill-fase de latentie. TP is hier essentieel.
• Modelgrootte: Bij het zeer grote 405B-model is het geheugen voor de KV-cache (Key-Value cache) zeer beperkt. PP helpt hier om meer geheugenruimte vrij te maken voor grotere batches, wat cruciaal is voor doorvoer.

Betekenis en Conclusie

De studie concludeert dat er geen "one-size-fits-all" oplossing is voor LLM-inferentie. De keuze voor parallelisatie moet worden gebaseerd op het specifieke doel van de applicatie:

• Voor lage latentie (bijv. chatbots, real-time interactie): Tensor Parallelism (TP) is de beste keuze. Het versnelt de token-generatie door meer rekenkracht per batch te gebruiken, ten koste van iets lagere doorvoer.
• Voor hoge doorvoer (bijv. batch-verwerking, offline analyse): Pipeline Parallelism (PP) is superieur. Het stelt het systeem in staat om veel grotere batches tegelijkertijd te verwerken, waardoor de totale output per seconde (TPS) wordt gemaximaliseerd.
• Hybride aanpak: Voor systemen die zowel lage latentie als hoge doorvoer nodig hebben, biedt een hybride configuratie (TP + PP) de mogelijkheid om de parameters af te stemmen op de eisen van de Service Level Agreement (SLA).

De auteurs benadrukken dat bij het schalen naar multi-node systemen de communicatie-overhead (vooral all-reduce bij TP) een nog grotere rol zal spelen als bottleneck, wat de noodzaak onderstreept van slimme parallelisatiestrategieën en geavanceerde netwerktopologieën.