Microbatch, achterwaartse doorgang en update scheiden
Het microbatch is de groep voorbeelden die door een voorwaartse doorgang op één replica wordt verwerkt. De achterwaartse doorgang berekent de bijdrage aan de gradiënten. De update van de optimalisator gebruikt de beschikbare gradiënten om de parameters te wijzigen. Met accumulatie gaan meerdere voorwaartse/achterwaartse doorgangen aan die update vooraf; de parameters blijven ongewijzigd tijdens de groep.
In PyTorch accumuleren gradiënten in de daarvoor bestemde tensoren. De gradiënten na elk microbatch wissen zou dus de gewenste accumulatie tenietdoen. Omgekeerd zou vergeten ze tussen twee groepen op nul te zetten, voorbeelden van de vorige update laten bijdragen.
Definieer je logeenheid: nummer van het microbatch, update van de optimalisator, geziene voorbeelden of tokens. Het woord "step" alleen is dubbelzinnig. Een loss-curve is niet correct te vergelijken als de as in een van de experimenten acht keer zoveel voorbeelden voorstelt.
Technische bronnen: PyTorch — accumulatie en op nul zetten van gradiënten
De effectieve batch berekenen zonder GPU's dubbel te tellen
Noteer m als het aantal voorbeelden per microbatch en per replica, A als het aantal geaccumuleerde microbatches, D als het aantal replica's van dataparallelisme. Als deze groottes constant zijn en de voorbeelden correct verdeeld, is het aantal voorbeelden dat bijdraagt aan een globale update m × A × D.
De factor D verwijst niet noodzakelijk naar alle kaarten van de machine. GPU's die hetzelfde model delen via tensor- of pipeline-parallelisme worden niet evenveel datareplica's. Noteer de werkelijk geconfigureerde groepen, niet simpelweg de commerciële hoeveelheid van de batch.
Rekenvoorbeeld: twee voorbeelden per microbatch, acht accumulaties en twee replica's geven 32 voorbeelden per globale update. Elke replica verwerkt zestien voorbeelden in deze groep. De tabel vergelijkt aantallen; hij rangschikt niet hun geheugen of snelheid.
| m | A | D | Voorbeelden per globale update |
|---|---|---|---|
| 2 | 8 | 2 | 32 |
| 1 | 16 | 2 | 32 |
| 4 | 4 | 2 | 32 |
| 2 | 8 | 1 | 16 |
Technische bronnen: PyTorch — effectieve batch en accumulatie in gemengde precisie · PyTorch — gedrag van DistributedDataParallel-replica's
De verliesfunctie normaliseren op basis van de daadwerkelijk geëvalueerde elementen
Voor een gemiddeld verlies over microbatches met hetzelfde aantal relevante elementen geeft het delen van elke bijdrage door A het gemiddelde van de groep. Deze regel veronderstelt dat het framework deze normalisatie niet al uitvoert. Bij een tool die de accumulatie afhandelt, lees je contract opnieuw voordat je handmatig een deling toevoegt.
Voor een gemiddeld verlies per token veranderen verschillende lengtes de noemer. Je moet de som van de verliezen delen door de daadwerkelijk gesuperviseerde tokens van de groep, exclusief padding en genegeerde posities. Het gemiddelde van de microbatches-gemiddelden geeft doorgaans niet hetzelfde doel.
Theoretisch voorbeeld: een microbatch telt 512 gesuperviseerde tokens met een gemiddeld verlies van 2; een andere telt er 1.536 met een gemiddelde van 4. Het gewogen gemiddelde is (512 × 2 + 1.536 × 4) ÷ 2.048 = 3,5. Het ongewogen gemiddelde is 3 en overwogen het kleine groep. Deze waarden illustreren alleen de berekening.
Technische bronnen: Hugging Face Accelerate — accumulatie met voorbeelden van variabele grootte
Een volledige accumulatiegroep organiseren
Bepaal eerst de grenzen van de groep en de noemer ervan. Bereken voor elke microbatch de output, het genormaliseerde verlies en de achterwaartse doorgang zonder tussentijdse update. Geef outputs vrij die je niet meer nodig hebt; het bewaren van verliezen die aan hun graaf vastzitten in een lijst kan de levensduur van de toewijzingen verlengen.
Pas na de laatste bijdrage de voorziene bewerkingen toe op de volledige gradiënt en daarna de update. Reset vervolgens de gradiënten voor de volgende groep. Als een ronde eindigt met minder dan A microbatchs, kies dan expliciet om deze gedeeltelijke groep te verwerken met de werkelijke noemer of om die over te slaan; noteer de betrokken voorbeelden.
Bij gemengde precisie met GradScaler blijft de schaalfactor constant tijdens de accumulatie. De werkelijke herschaling en een eventuele clipping vinden plaats na de bijdragen; de update van de scaler volgt de stap-poging. Controles op niet-eindige waarden kunnen verhinderen dat de parameters worden gewijzigd.
De scheduler moet de eenheid volgen die je lus aankondigt. Als hij is gedefinieerd per optimizer-update, zou het aanroepen bij elke microbatch het schema wijzigen. Registreer pogingen en daadwerkelijk toegepaste updates afzonderlijk wanneer je systeem er kan overslaan.
Technische bronnen: PyTorch — autograd-grafen en tensoren die voor backward worden bewaard · PyTorch — accumulatie, unscale, clipping en GradScaler
Bij multi-GPU de reductie en verdeling van voorbeelden controleren
DistributedDataParallel synchroniseert de gradiënten tussen replica's. In zijn gebruikelijke gedrag middelt de reductie ze; een lokaal gesommeerd verlies en een lokaal gemiddeld verlies hebben dus niet dezelfde schaal. Bij verschillende aantallen tokens per replica moeten de globale noemer en deze reductie samen worden bekeken.
Controleer de daadwerkelijk verwerkte IDs: dezelfde voorbeelden onbedoeld op alle kaarten dupliceren verhoogt de informatie van de groep niet evenredig. Om tussentijdse communicatie uit te stellen kan no_sync worden gebruikt op de microbatches vóór de definitieve synchronisatie; zijn context moet ook de voorwaartse doorgang omvatten.
Pas deze regel niet toe op alle gedistribueerde systemen. Sharding van states, pipeline, communicatiehooks en frameworks kunnen de effectieve bewerkingen veranderen. Begin met de configuratie die je tool ondersteunt, en controleer dan een volledige groep op elke replica.
Technische bronnen: PyTorch — gradiëntreductie en reikwijdte van no_sync in DDP
Waarom dezelfde effectieve batch niet dezelfde ervaring garandeert
De gelijkheid m × A × D is een telling. Om een gradiënt van een grote batch terug te vinden, zijn onder meer correct gewogen bijdragen nodig, dezelfde parameterstatus tijdens de groep en bewerkingen die verenigbaar zijn met deze decompositie. De numerieke nabijheid wordt geverifieerd met een passende tolerantie; ze volgt niet uit het product alleen.
BatchNorm berekent statistieken op basis van de invoer van zijn doorgang: meerdere kleine microbatches bieden hem niet dezelfde groepen als één grote batch. Toevalsbewerkingen, de volgorde van berekeningen en afrondingen kunnen eveneens variëren. Beloof geen bit-voor-bit identieke eindgewichten.
Een wijziging van de globale batch kan ook het aantal updates voor eenzelfde aantal geziene voorbeelden veranderen. Leg vooraf de vergelijkingsas en je kwaliteitsregel vast. Verander niet tegelijkertijd de leersnelheid, de scheduler en de duur zonder deze nieuwe hypotheses te documenteren.
Technische bronnen: PyTorch — statistieken van BatchNorm1d · PyTorch — grenzen van reproduceerbaarheid
Het geheugen beheren en beslissen over het vervolg
Instrumenteer een groep met inbegrip van de achterwaartse doorgangen en de eerste update, en daarna de volgende groepen. Een geslaagde forward valideert de gradiënten of de door de optimizer gecreëerde toestanden niet. De tellers moeten hun bereik per device behouden. Het geheugendossier biedt de methode voor het lezen van de baselines en pieken.
Als een groep faalt, verklein dan de microbatch en herbereken A om de beoogde effectieve batch te behouden wanneer die keuze relevant blijft. Deze wijziging garandeert noch een proportionele verdeling van de piek noch een betere duur. Als de gewichten of de toestanden domineren, kan accumulatie alleen onvoldoende zijn.
Controleer vóór een campagne één update op een kleine, beheerste set: dezelfde voorbeelden, gewogen verlies, eindige gradiënten, groepsgrens en aantal stappen. Evalueer daarna de kwaliteit met het gekozen protocol. Het kleine inferentie-MLP uit het downloadbare dossier voert dit trainingsrecept niet uit; het vervangt deze controle niet.
Je eindfiche bundelt m, A, D, de gesuperviseerde tokens, de precisie, de normalisatie, de behandeling van de laatste groep en de waargenomen pieken. Keer daarna terug naar de configuratiekeuze en het experimentenbudget, met een scheiding tussen voorbereiding, proeven en werkelijk aanvaarde resultaten.
- Abnormaal klein verlies: zoek naar een dubbele deling door de accumulatie.
- Resultaat dat varieert met de opdeling: controleer genegeerde tokens en het gemiddelde van de gemiddelden.
- Accumulatie zonder effect: controleer zero_grad en optimizer.step.
- Groeiend geheugen: zoek naar referenties die tussen microbatches behouden blijven.
- Verschoven schema: onderscheid achterwaartse doorgangen en updates.
Technische bronnen: Hugging Face — geheugenposten van een training
Praktische vragen
Vermenigvuldigt het accumuleren van zestien microbatches het geheugen met zestien?
Niet noodzakelijk: de bijdragen worden na elkaar verwerkt. De gradiënten blijven bestaan, terwijl onnodige activaties kunnen worden vrijgegeven. De piek hangt echter af van het model, de behouden referenties en de optimizer-toestanden; meet de volledige groep.
Verdubbelen twee GPU's altijd de effectieve batch?
Alleen als die GPU's deelnemen als twee datareplica's met de aangekondigde microbatch. Kaarten die eenzelfde model delen, vormen niet automatisch twee replica's. Controleer de gedistribueerde groepen en de verwerkte voorbeelden.
Kan ik alle verliezen delen door het aantal accumulaties?
Deze eenvoudige regel komt overeen met microbatches van gelijk gewicht, zonder normalisatie die al door het framework wordt beheerd. Gebruik bij variabele aantallen gesuperviseerde tokens of een onvolledige laatste groep de werkelijke noemer van de doelstelling.