CapordiaDe werkeenheid bepalen die kan worden gescheiden
Schrijf op wat een geaccepteerd resultaat vormt: een afbeelding, een verwerkt document, een reeks simulaties of een eindtoestand van een training. Vraag je vervolgens af of een eenheid kan worden berekend zonder op de andere te wachten. Twee documenten kunnen onafhankelijk zijn tijdens hun verwerking en daarna afhangen van een gemeenschappelijke stap voor het opbouwen van de index. De opdeling moet die tweede stap beschrijven in plaats van die te vergeten in een belofte van parallellisme.
Onderscheid technische onafhankelijkheid van zakelijke onafhankelijkheid. Een uitvoer kan worden geproduceerd zonder technische uitwisseling en toch onbruikbaar blijven voordat de volledige batch is gevalideerd. Benoem dus de rekeneenheid, de leveringseenheid en de assemblageregel. Die gemeenschappelijke woordenschat voorkomt dat inkoop kaarten telt terwijl het applicatieteam instanties of fragmenten van hetzelfde model telt.
Kiezen tussen onafhankelijke taken en nauwe samenwerking
Voor onafhankelijke taken krijgt elk proces zijn eigen invoer en produceert een identificeerbare uitvoer. Een andere kaart kan een andere taak uitvoeren zonder synchronisatie bij elke stap. Deze modus is interessant wanneer het doel draait om de hoeveelheid die binnen een venster wordt afgerond. Het versnelt niet automatisch een geïsoleerde taak en er moet nog worden gecontroleerd op contentie op gegevens, opslag of licenties.
Voor samenwerkend werk wisselen de apparaten gegevens uit of wachten ze op een tussenresultaat. Het programma moet die verdeling beheren. De CUDA-gids legt uit dat het benutten van meerdere GPU's contexten, gegevensdistributie, lanceringen en communicatie met zich meebrengt. Dat zijn eigenschappen van het softwaretraject en van het waargenomen systeem; de naam van een kaart uit de catalogus bewijst niet dat dat traject al bestaat.
| Vraag | Onafhankelijke taken | Samenwerkend werk |
|---|---|---|
| Wat ontvangt een kaart? | Een volledige, afzonderlijke taak | Een deel of een replica van het werk |
| Wat moet worden gecoördineerd? | Toewijzing van invoer en verzameling van uitvoer | Uitwisselingen, volgorde en synchronisaties |
| Welk voordeel moet worden geverifieerd? | Aantal geaccepteerde resultaten per venster | Identiek resultaat met aangepaste duur of capaciteit |
| Welke fout moet worden voorzien? | Een geïsoleerde taak of publicatie | Het effect van een niet-beschikbare deelnemer op de groep |
Replicatie en geheugenverdeling niet verwarren
Meerdere kopieën van een model betekenen niet dat de parameters ervan over de kaarten zijn verdeeld. PyTorch DistributedDataParallel synchroniseert de gradiënten tussen processen die hun lokale modellen trainen. Met deze aanpak kun je dus niet louter op basis van de naam concluderen dat een model dat te groot is voor één kaart op meerdere kaarten past. Een partitiemechanisme vereist zijn eigen documentatie en zijn eigen validatie.
Het geheugen van elke kaart moet dekken wat de software er daadwerkelijk in plaatst: gegevens, modelstatus, tijdelijke ruimtes en eventuele uitwisselingen. De piek kan variëren met de instellingen en de verwerkingsfase. Noteer die per apparaat. Een som van nominale capaciteiten verbergt een onevenwicht waarbij één kaart geheugen tekortkomt terwijl de andere overhouden. De totale capaciteit van de batch volstaat niet om het scenario te accepteren.
Fictief voorbeeld: acht onafhankelijke conversies verdelen
Het fictieve team "Index van de werken" bereidt acht documentconversies voor. In hun werkhypothese bezet elke conversie twaalf minuten lang een kaart, inclusief laden en uitvoer. Een taak past alleen op de kaart en er is geen uitwisseling nodig vóór de uiteindelijke assemblage. Deze duren dienen uitsluitend om de redenering op te bouwen: ze beschrijven geen enkele uitvoering of GPU-prestatie die Capordia aanbiedt.
Met één kaart vertegenwoordigen acht opeenvolgende taken 8 × 12 = 96 minuten. Met twee kaarten en een evenwichtige verdeling van vier taken per kaart duurt het parallelle deel theoretisch 48 minuten. Als de eindassemblage tien minuten vergt op een aparte machine, wordt het volledige traject respectievelijk 106 of 58 minuten, exclusief wachttijd voor de start. Deze berekening veronderstelt dat de twee kaarten elkaars laadtijden niet vertragen.
| Organisatie | Paralleliseerbaar deel | Assemblage | Berekende duur |
|---|---|---|---|
| Eén kaart, acht taken | 96 min | 10 min | 106 min |
| Twee kaarten, vier taken elk | 48 min | 10 min | 58 min |
Zichtbaar maken wat deze theoretische winst kan tenietdoen
In hetzelfde voorbeeld zijn de documenten misschien niet even groot. Als je de vier langste aan één kaart toewijst, moet de andere op het einde wachten. Een verdeling op basis van beschikbaarheid kan het evenwicht verbeteren, maar vereist een betrouwbaar toewijzingsmechanisme en een toelatingsbeleid. De gids over de wachtrij behandelt deze organisatie; deze berekening bewijst niet dat ze al is ingevoerd.
Ook opslag kan de dominante gemeenschappelijke resource worden. Twee processen die dezelfde gegevens lezen of tegelijk grote resultaten wegschrijven, beschikken niet noodzakelijk over tweemaal de doorvoer. Controleer ook de gelijktijdigheidslimieten van tools en licenties. Als het niet-paralleliseerbare deel toeneemt, maak dan de volledige planning opnieuw. De tijd die je in één fase wint, mag een vertraging elders niet verbergen.
Voor verdeeld werk: ontvang de werkelijke topologie
Vraag welke kaarten zichtbaar zijn, hoe ze communiceren en welke hostresources hun processen delen. Controleer de apparaten die toegankelijk zijn vanuit de gebruikte omgeving, niet alleen vanuit een beheerdersconsole. CUDA geeft aan dat toegang tot het geheugen van een andere GPU onder meer afhangt van de topologie en de mogelijkheden van het systeem. Dat een model een functie ondersteunt, bewijst niet dat de verwachte verbinding op de machine aanwezig is.
Houd een eenvoudig schema bij van de gegevensstroom: invoer, betrokken kaart of proces, uitwisselingen, eindverzameling en uitvoer. Bepaal voor elke pijl of die via het hostgeheugen, een verbinding tussen GPU's of het netwerk loopt. Dit overzicht helpt bij het kiezen van de ontvangstcontroles. Het legt geen specifieke technologie op en verandert een multi-GPU-aanvraag niet in een belofte van een bepaalde topologie.
Twee organisaties vergelijken zonder het verwachte resultaat te veranderen
Bereid een kleine representatieve corpus voor en voer op je toegestane doel eerst een referentieorganisatie uit en daarna de kandidaat-organisatie. Behoud versies, instellingen, verwachte kwaliteit en assemblagereregels. Vergelijk de tijd tot het aanvaarde resultaat, de geheugenpiek van elke kaart, de fouten en het verbruik van gemeenschappelijke resources. Scheid waarnemingen van schattingen; een voorgestelde opdracht is geen reeds behaald resultaat.
Controleer in het bijzonder dat het aantal aanvaarde uitvoer gelijk blijft en dat geen enkele invoer wordt weggelaten. Kies voor een berekening die gevoelig is voor de volgorde van bewerkingen een onderbouwde tolerantie in plaats van een willekeurige gelijkheid. Een organisatie die sneller klaar is met een andere kwaliteit beantwoordt een ander probleem. Bewaar ook een geval waarin het delen niet voordelig is: deze grens verklaart de keuze beter dan een rangschikking van kaarten zonder gemeenschappelijke belasting.
De keuze omzetten in de gevraagde capaciteit
Schrijf ten slotte het aantal gelijktijdige taken op, de kaarten die voor elk nodig zijn en de essentiële voorwaarden. Een taak verdeeld over twee kaarten en twee taken van één kaart vormen twee verschillende organisaties, zelfs als het totale aantal kaarten gelijk is. De gekozen configuratie moet de vereiste organisatie mogelijk maken; vertrek niet van het nominale totaal om er vervolgens een gebruik bij te verzinnen.
De catalogus vermeldt kaartbundels. Een B200-bundel bevat twee GPU's van elk 180 GB; deze samenstelling garandeert niet dat software ze als één geheugen benut. De volgende stap is het benodigde vermogen op de bundel af te stemmen en vervolgens de eigenschappen te ontvangen die daadwerkelijk nodig zijn. De planning, de kosten en de beslissing blijven voorlopig zolang de doorslaggevende voorwaarden niet zijn geverifieerd.
Vragen om te beslissen
Zijn twee GPU's altijd sneller dan één?
Nee. De winst hangt af van het paralleliseerbare deel, de uitwisseling en de gedeelde resources. Voor een geïsoleerde taak die niet kan worden opgesplitst, kan een tweede kaart ongebruikt blijven. Vergelijk de tijd tot hetzelfde geaccepteerde resultaat, volgens een expliciet protocol.
Verdubbelt een bundel van twee kaarten het beschikbare geheugen voor mijn programma?
Niet automatisch. Elk apparaat heeft zijn eigen geheugen en het programma moet zijn toestand of gegevens verdelen. Het repliceren van een model kan daarentegen een groot deel van die toestand dupliceren. Controleer het softwaremechanisme en de piek per kaart.
Wanneer beginnen met onafhankelijke taken?
Wanneer elke eenheid afzonderlijk kan worden berekend en het nagestreefde voordeel is om meer eenheden af te ronden. Toch moeten de toewijzing, de belastingverdeling en de eindsamenstelling worden gevalideerd, zonder aan te nemen dat opslag en licenties automatisch meevolgen.