Multi-GPU-inferensparallellism: Tensor- kontra pipelineuppdelning lokalt

När en enda GPU inte räcker

De största modellerna med öppna vikter som finns tillgängliga idag överstiger minneskapaciteten hos vilken enskild GPU som helst. En modell med 70 miljarder parametrar i FP16 kräver ungefär 140 GB GPU-minne bara för modellvikterna, innan man räknar in KV-cache, aktiveringsminne och ramverksoverhead. Även med kvantisering som reducerar detta till 35-70 GB beroende på metod, ryms många modeller helt enkelt inte på en enda enhet. Multi-GPU-inferens är inte valfritt för dessa modeller utan en förutsättning.

Men även när en modell ryms på en enda GPU finns det genomströmnings- och latensanledningar att dela den över flera enheter. En enda GPU som servar en 13B-parametermodell kan hantera cirka 20 samtidiga förfrågningar innan genomströmningen mättas. Att distribuera modellen över två GPU:er kan öka genomströmningen genom att möjliggöra mer parallell bearbetning av förfrågningar, eller minska latensen per förfrågan genom att bearbeta olika delar av modellen samtidigt.

Lokala driftsättningar möter specifika begränsningar som gör valet av parallellismstrategi mer avgörande än i molnmiljöer. GPU-sammankopplingens bandbredd varierar dramatiskt mellan hårdvarukonfigurationer: NVLink ger 600-900 GB/s mellan GPU:er i samma nod, medan PCIe 4.0 x16 bara ger 32 GB/s och InfiniBand mellan noder ger 25-50 GB/s. Parallellismstrategin måste matcha din hårdvarutopologi, annars eliminerar kommunikationsoverheaden alla fördelar med att använda flera GPU:er.

Tensorparallellism: uppdelning av lager mellan GPU:er

Tensorparallellism (TP) delar individuella lager i modellen över flera GPU:er. Varje GPU håller en skiva av varje lager, och de samarbetar för att beräkna utdatan från varje lager parallellt. För en transformermodell innebär detta att uppmärksamhetshuvudena och framåtmatningsmatriserna partitioneras kolumn- eller radvis över GPU:erna, där varje GPU beräknar sin del och sedan kommunicerar partiella resultat för att producera den slutliga utdatan.

Nyckeloperationerna i tensorparallell inferens är all-reduce- och all-gather-kommunikationer som sker efter varje lagers beräkning. Denna kommunikation sker vid varje transformerlager, vilket innebär att TP genererar högfrekvent kommunikation med måttlig storlek mellan GPU:erna genom hela inferensen.

Fördelen med TP är reducerad latens. Eftersom alla GPU:er bearbetar varje token samtidigt (var och en hanterar sin skiva av beräkningen) minskas tiden för att bearbeta en enskild token jämfört med att köra hela modellen på en GPU. För latenskänsliga applikationer som interaktiv chatt gör detta TP till den föredragna strategin. Med 2-vägs TP på NVLink-anslutna GPU:er är latensminskningar per token på 30-40% typiska för stora modeller.

Nackdelen är kravet på kommunikationsbandbredd. All-reduce-operationerna vid varje lager kräver sammankopplingar med hög bandbredd och låg latens. På NVLink är kommunikationsoverheaden liten relativt beräkningstiden. På PCIe blir overheaden betydande och den kumulativa kommunikationskostnaden kan förbruka halva den totala inferenstiden. Tensorparallellism över PCIe-anslutna GPU:er rekommenderas generellt inte för latenskänsliga arbetsbelastningar.

Pipelineparallellism: uppdelning av modellen i steg

Pipelineparallellism (PP) tilldelar olika lager i modellen till olika GPU:er. GPU 0 kan hålla lager 0-19, GPU 1 håller lager 20-39, GPU 2 håller lager 40-59 och GPU 3 håller lager 60-79. En förfrågan kommer in vid GPU 0, flödar genom varje steg sekventiellt och lämnar GPU 3 med den färdiga utdatan.

Kommunikationsmönstret i PP skiljer sig fundamentalt från TP. Istället för all-reduce-operationer vid varje lager utför PP punkt-till-punkt-överföringar av det dolda tillståndet mellan steg. Dessa överföringar är mindre frekventa och mindre i storlek. Detta gör PP mycket mer tolerant mot begränsad sammankopplingsbandbredd.

PP är rätt val när GPU:er är anslutna via PCIe eller när de spänner över flera noder via nätverkssammankopplingar. Kommunikationsvolymen är tillräckligt låg för att till och med PCIe 3.0-bandbredd räcker för de flesta modeller.

Den primära nackdelen med PP för inferens är pipelinebubblor. Vid bearbetning av en enskild förfrågan är bara ett steg aktivt åt gången medan de andra GPU:erna väntar. Detta innebär att PP för en enskild förfrågan inte ger någon latensfördel utan bara distribuerar minnet. Genomströmningsfördelen med PP kommer från att fylla pipelinen med flera förfrågningar: medan GPU 3 bearbetar förfrågan 1, bearbetar GPU 2 förfrågan 2, GPU 1 bearbetar förfrågan 3 och så vidare. Med tillräckligt med samtidiga förfrågningar hålls alla steg sysselsatta.

Hybridparallellism och praktiska konfigurationer

Produktionsdriftsättningar kombinerar ofta båda strategierna i en hybridparallellismkonfiguration. Det typiska mönstret är att använda tensorparallellism inom en nod (där NVLink ger hög bandbredd) och pipelineparallellism mellan noder (där nätverksbandbredden är flaskhalsen).

Den optimala konfigurationen beror på din specifika hårdvara och arbetsbelastning. Här följer praktiska riktlinjer för vanliga lokala uppsättningar:

En nod, 2 GPU:er med NVLink: Använd 2-vägs TP. NVLink-bandbredden hanterar all-reduce-kommunikationen effektivt och TP ger bäst latens per enskild förfrågan.

En nod, 4-8 GPU:er med NVLink: Använd TP upp till NVLink-domänens storlek. På DGX-liknande system där alla GPU:er har full NVLink-anslutning, använd 4-vägs eller 8-vägs TP. På system där NVLink bara ansluter GPU-par, använd 2-vägs TP inom NVLink-par och PP mellan par.

En nod, GPU:er anslutna enbart via PCIe: Föredra PP framför TP. Om modellen ryms på en enda GPU med kvantisering, kör den på en GPU och använd de övriga för ytterligare modellrepliker för ökad genomströmning.

Flernodkluster: Använd alltid PP mellan noder. Använd TP inom varje nod baserat på den interna sammankopplingen (NVLink: TP, PCIe: PP eller ensamma GPU-repliker).

Mätning och optimering av parallellismprestanda

Efter att ha valt en parallellismstrategi, instrumentera din servingstack för att mäta faktisk prestanda och identifiera flaskhalsar. Nyckelmetrikerna att spåra är tid till första token (TTFT), intertokenlatens (ITL), genomströmning (tokens per sekund över alla samtidiga förfrågningar) och GPU-utnyttjande per enhet.

För TP-konfigurationer, övervaka tiden som spenderas i all-reduce-operationer med ditt inferensramverks profileringsverktyg. Om kommunikationstiden överstiger 20% av total tid per token är din sammankoppling flaskhalsen. Lösningar inkluderar att minska TP-graden, aktivera överlappning av kommunikation och beräkning, eller uppgradera till en snabbare sammankoppling.

För PP-konfigurationer, övervaka pipelinebubbelkvoten: andelen tid varje GPU spenderar inaktiv i väntan på input från föregående steg. En hög bubbelkvot innebär att du behöver fler samtidiga förfrågningar för att fylla pipelinen. Beräkna den minsta batchstorleken som krävs för att mätta pipelinen som ungefär lika med antalet pipelinesteg.

Jämför din uppmätta genomströmning mot det teoretiska maximumet. Om uppmätt genomströmning är under 70% av det teoretiska, undersök om flaskhalsen är kommunikation, minnesbandbredd eller belastningsobalans mellan steg.

Belastningsobalans mellan PP-steg är ett vanligt problem. Transformermodeller är inte perfekt enhetliga: inbäddningslagret och språkmodellhuvudet har andra beräkningsprofiler än transformerblocken. Tilldela inbäddningslagret och ett antal transformerblock till det första steget, och LM-huvudet och färre transformerblock till det sista steget, så att total beräkningstid per steg är ungefär lika.

Att göra rätt val för din driftsättning

Beslutet mellan TP, PP och hybridparallellism kokar ner till tre frågor. Först, vad är din sammankopplingstopologi? NVLink möjliggör TP; PCIe och nätverkssammankopplingar gynnar PP. Sedan, vad är ditt latenskrav? Interaktiva applikationer behöver TP för låg latens per förfrågan; batchbearbetning kan tolerera PP:s pipelinelatens. Slutligen, vad är din samtidighetsnivå? PP behöver samtidiga förfrågningar för att fylla pipelinen.

För de flesta lokala företagsdriftsättningar som kör modeller i storleksordningen 30B-70B parametrar på multi-GPU-servrar med NVLink är tensorparallellism över alla GPU:er i en enda nod standardvalet. Det ger bäst latens, skalar bra upp till 8 GPU:er med moderna NVLink-konfigurationer och stöds väl av ledande inferensramverk inklusive vLLM, TGI och TensorRT-LLM.

Vid skalning bortom en enda nod, lägg till pipelineparallellism mellan noder samtidigt som du behåller TP inom varje nod. Denna hybridansats matchar kommunikationsstrategin mot tillgänglig bandbredd på varje nivå i hårdvaruhierarkin och maximerar både genomströmning och latensprestanda.

Dokumentera din parallellismkonfiguration som en del av din modelldriftsättningsspecifikation. Inkludera TP-grad, PP-grad, GPU-till-steg-mappning och antaganden om hårdvarutopologin. När hårdvaran ändras, granska parallellismkonfigurationen. En strategi optimerad för en hårdvarukonfiguration kan vara suboptimal på en annan.

Utvald bild av Bill Fairs på Unsplash.