Hoe verplaatst pipeline-parallelisme modellagen over AI-accelerators voor thuisgebruik?
Pipelineparallellisme verplaatst een model over AI-versnellers voor thuis door verschillende groepen lagen toe te wijzen aan opeenvolgende apparaatfasen en activaties tussen die fasen door te geven.
Deze methode is nuttig wanneer een diep model te groot is voor één versneller, maar kan worden verdeeld in laaggroepen die over meerdere apparaten passen. In tegenstelling tot tensorparallellisme bezit elke fase volledige lagen in plaats van fragmenten van dezelfde matrix. De belangrijkste afweging is minder gewichtsgeheugen per apparaat tegenover activatieoverdrachten, fase-ongelijkheid en inactieve tijd in de pipeline.
Pipelineparallellisme verdeelt een diep model in opeenvolgende lagenfasen
Een transformer is van nature geordend: vroege lagen verwerken de invoer voordat latere lagen kunnen worden uitgevoerd. Pipelineparallellisme groepeert aaneengesloten delen van die diepte en wijst elk deel toe aan een andere versneller.
De pipelining-runtime van PyTorch verdeelt een model in partities die als opeenvolgende fasen op verschillende apparaten worden uitgevoerd. Elk apparaat slaat alleen de parameters op voor de toegewezen fase.
Dit kan het modelgeheugen per apparaat voldoende verlagen om een model uit te voeren dat niet op één GPU voor thuisgebruik zou passen.
Activaties bewegen van de ene fase naar de volgende
Nadat GPU 0 zijn lagen heeft uitgevoerd, stuurt deze de activatie van de verborgen toestand naar GPU 1. Dat apparaat past de volgende reeks lagen toe en stuurt vervolgens een nieuwe activatie door, totdat de laatste fase logits of een andere modeluitvoer produceert.
vLLM-Omni beschrijft pipelineparallellisme als het verdelen van transformerblokken in opeenvolgende fasen over GPU's. Alleen activaties op de fasegrenzen hoeven bij het basispad voorwaarts tussen aangrenzende fasen te worden overgedragen.
In tegenstelling tot tensorparallellisme berekenen de apparaten niet gezamenlijk één matrix binnen dezelfde laag. Ze bezitten verschillende lagen.
Eén verzoek doorloopt de fasen nog steeds in volgorde
Voor één token of één microbatch kunnen latere fasen pas beginnen zodra de vereiste activatie van de vorige fase is aangekomen. Vier laaggroepen op vier GPU's plaatsen maakt één sequentieel verzoek niet automatisch vier keer sneller.
De parallelle-verwerkingsgids van NVIDIA definieert PP als het verticaal verdelen van modellagen op basis van diepte. De seriële afhankelijkheid over de diepte blijft bestaan.
De directe winst ligt daarom mogelijk eerder in capaciteit dan in latentie. De doorvoer verbetert wanneer de runtime verschillende delen van het werk over de fasen heen kan overlappen.
Microbatches vullen de pipeline zodat meerdere fasen tegelijk werken
Een pipeline wordt efficiënt wanneer de invoer wordt verdeeld in microbatches of wanneer meerdere inferentie-items gelijktijdig verschillende fasen kunnen bezetten. Terwijl fase 2 één microbatch verwerkt, kan fase 1 aan de volgende beginnen.
De parallelismegids van Hugging Face legt uit dat pipeline-uitvoering microbatches gebruikt om inactieve pipelinetijd te beperken. Hetzelfde benuttingsprincipe geldt wanneer een inferentieruntime onafhankelijk werk kan overlappen.
Interactieve tokengeneratie voor één gebruiker biedt minder natuurlijke parallelliteit, omdat elke nieuwe token afhankelijk is van de uitvoer van het vorige token. Gebundelde verzoeken of verkeer van meerdere gebruikers kunnen meer mogelijkheden bieden om de fasen bezet te houden.
Ongelijke fasetijden veroorzaken bellen en maken de traagste fase dominant
Als één fase meer lagen bevat, tragere hardware gebruikt of bijzonder dure bewerkingen uitvoert, wacht de volgende fase op invoer en moet de vorige fase uiteindelijk op beschikbare ruimte wachten. Deze perioden van inactiviteit zijn pipelinebellen.
De pipeline-engine van DeepSpeed benadrukt het verdelen van modellagen over pipelinefasen. Het balanceren van de berekeningen per fase is daarom net zo belangrijk als het balanceren van het aantal parameterbytes.
Een gemengde opstelling met AI-versnellers voor thuis kan een tragere GPU bewust minder lagen geven, maar geheugencapaciteit, activatiegrootte en ondersteunde overdrachten tussen apparaten beperken die plaatsing.
Pipelineparallellisme ruilt gewichtscapaciteit in voor activatieoverdracht en planning
PP is aantrekkelijk wanneer het model diep is en kan worden verdeeld in laaggroepen die afzonderlijk op de apparaten passen. Het communiceert activaties op de fasegrenzen in plaats van de frequente collectieve bewerkingen binnen lagen die kenmerkend zijn voor tensorparallellisme, maar betaalt daarvoor met seriële afhankelijkheden en bellen.
De gids van ZimaSpace over AI-concurrency voor meerdere gebruikers thuis is relevant, omdat meer gelijktijdig werk kan helpen een pipeline te vullen, terwijl het ook de druk op KV-cache en planning verhoogt.
Meet het geheugen per fase, de uitvoeringstijd per fase, de tijd voor activatieoverdracht, de end-to-end-latentie, de doorvoer en het inactiviteitspercentage van elk apparaat. Een configuratie die het model kan bevatten maar de helft van de versnellers ongebruikt laat, heeft mogelijk een andere verdeling nodig.
De gids van ZimaSpace voor lokale AI-hardware biedt het uitgangspunt voor de capaciteitsvereisten. Pipelineparallellisme is een manier om de geheugengrens van één apparaat te overschrijden, maar het succes ervan hangt meer af van een goede fasebalans dan alleen van het aantal GPU's.
Aanbevolen producten
Tech & AI HUB
Meer om te lezen
Kunnen thuiscamera's gebeurtenissen synchroniseren zonder cloudtijdservices?
Een mechanismegerichte uitleg van cameratiijd zonder cloud, de afwegingen bij gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een lokale AI-service beschadigde modellagen detecteren vóór de inferentie?
Een mechanismegerichte uitleg van detectie van beschadigingen in modellagen, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
Kan een RAG-systeem worden hersteld zonder elke embedding opnieuw te genereren?
Een mechanismegerichte uitleg van RAG-herstel zonder opnieuw te embedden, de afwegingen rond gedeelde bronnen, drie veelgestelde vragen over query-fan-out en een praktisch verificatieprotocol.
