A Proximális Policy Optimization (PPO) egy fontos megerősítő tanulási algoritmus, amely számos elosztott és aszinkron ízzel rendelkezik.

Bevezetés

Mi az a PPO?

Ez a cikk feltételezi, hogy ismeri a megerősítő tanulást (RL) és konkrétan a PPO-t, de röviden összefoglalva: a „PPO” egy irányelv-gradiens módszer, amely megpróbálja egymáshoz közel tartani az egymást követő modellfrissítéseket a képzési instabilitás elkerülése érdekében. Ez lett a de facto RL algoritmus a jobb minta hatékonyság és stabilitás érdekében.

Az elosztott megerősítéses tanulás áttekintése

Mielőtt belevágnánk az összehasonlításokba, beszéljük meg az elosztott RL fontos magas szintű fogalmait (amelyek közül sok általában az elosztott rendszerekre is vonatkozik).

A normál RL általában a következő sémát követi: 1) a közzététel összegyűjtése, 2) a gradiens kiszámítása és 3) a súlyok frissítése. Ezután ismételje meg. Általában a gradiens számítását GPU-n kell elvégezni. A közzétételi gyűjtés a modell méretétől függően mindkét irányba haladhat, de sok esetben elegendő egy CPU. A súlyfrissítés pedig elvégezhető a CPU-n, mivel ez egyszerű mátrix-összeadás.

Az elosztott RL ugyanazokat az összetevőket tartalmazza, de különböző „munkások” keveredését is tartalmazhatja, akik ezek közül egyet vagy többet végeznek. Ezek a dolgozók különböző gépeken vagy folyamatokon dolgozhatnak. A cikk hátralévő részében azonban főként egyetlen gépen futó különböző folyamatokra fogok hivatkozni.

Először is, ez a különbség a szinkron és az aszinkron között. A szinkron azt jelenti, hogy a súlyfrissítés előtt minden dolgozónak el kell végeznie a megfelelő gradiens kiszámítását. Ez azért van így, hogy az ÖSSZES gradienst össze lehessen vonni (összeg vagy átlag) a frissítés előtt. Az aszinkron nem igényli, hogy ez így legyen.

Másodszor, ez a különbség a centralizált és a decentralizált között. A központosított általában egy paraméterkiszolgálót jelent, amely egyetlen eszközön vagy gépen van tárolva, átveszi a gradienseket, és elvégzi az összesítést és frissítést. A decentralizált nem igényel egyetlen szervert a súlyok frissítéséhez. Ez lehetővé teszi az „AllReduce” nevű népszerű algoritmus működését, ami csak azt jelenti, hogy minden dolgozó megkapja a többi dolgozó összes gradiensét, és összesíti/frissíti a modell saját példányát.

Vizualizált algoritmusok

A 3 fő különböző verzió a következő: Aszinkron PPO , Elosztott PPO és Decentralizált Elosztott PPO. Ezenkívül megvalósítottam egy verziót, amelyet Resource Flexible Distributed PPO-nak neveztem el, és ez szintén megjelenik.

Mindegyik vizualizációhoz 2 diagram látható. A felső a „dolgozói nézet”, ahol minden cella külön folyamatot jelez. Az élek jelzik az erőforrásokat, amelyeket általában megosztott memórián keresztül küldenek más folyamatoknak. Az alsó diagram a „kitekert nézet”, amely az algoritmus lépésről lépésére körvonalazza (fentről lefelé). Az egyes rétegeken belüli kis cellák (nagy szürke sejtek) egyidejűleg futnak egymással. A rétegek között a szinkronizálás pillanatai vannak. Ha egy cella kék színű, akkor saját példánya van a modellnek. Egyébként nincs rajta modell tárolva (inkább egy egyszerű funkcionális művelet).

"Aszinkron PPO (APPO)"

Az APPO nem igazán „elosztott” abban az értelemben, hogy nem igényel több GPU-t, mivel nincs több dolgozó, aki egyszerre számítja a gradienst. Mindazonáltal kihasználja a több CPU előnyeit, így a multiprocessing segítségével több dolgozó aszinkron módon gyűjtheti össze a kibocsátásokat. MEGJEGYZÉS: az aszinkron ebben az esetben nem ugyanaz, mint amire fentebb a „szinkron” és az „aszinkron” közötti különbségként hivatkoztam, hanem csak egy név, amelyet ennek az algoritmusnak adnak, hogy jelezze a gradiens többfeldolgozás hiányát. .

"Elosztott PPO (DPPO)"

A DPPO (aszinkron és központosított) a PPO elsődlegesen használt elosztott verziója. Központi paraméterkiszolgálót (gradiens-aggregátort/súlyfrissítőt) alkalmaz, amely lehetővé teszi, hogy a bevezetést végző dolgozók aszinkronabban küldjék el a megfelelő gradienseiket a szervernek (szaggatott vonallal jelezve). Emiatt a gradienseknek csak egy bizonyos százalékát (ami egy hiperparaméter) kell összegyűjteni, mielőtt a paraméterkiszolgáló frissíteni tudja a globális modellt.

"Decentralizált elosztott PPO (DD-PPO)"

A DD-PPO (szinkron és decentralizált) az AllReduce technikát használja, hogy elkerülje a paraméterkiszolgáló használatát. Ez kiküszöböli a sok gradiens egyetlen gépre vagy folyamatra történő küldésével kapcsolatos lehetséges szűk keresztmetszeti problémákat. A „Gradient Distributor” az AllReduce különböző megvalósításai lehet, mindaddig, amíg mindegyik dolgozó a másik dolgozó gradiensével végződik.

Erőforrások rugalmas elosztott PPO (RF-DPPO)

Az RF-DPPO (szinkron és központosított) bonyolultabb, de lehetővé teszi a dolgozók számára, hogy elkötelezettek legyenek a közzétételi gyűjtés (CPU) VAGY a gradiensszámítás (GPU) számára. Tehát ha gépének nagyon korlátozott GPU-ja, de sok CPU-ja van, akkor ez segít az összes rendelkezésre álló erőforrás kihasználásában. A „Rollout Divvier” dolgozó összegyűjti az összes közzétételt, és külön darabokat küld az egyes színátmenet-kalkulátoroknak.

Az opciók mérlegelése

A problémától és az erőforrás-korlátoktól függ, hogy melyik verzió teljesíthet a legjobban az Ön számára. De sok esetben nem tudhatná biztosan, hacsak nem próbált ki több verziót, és nem hasonlította össze a sebességet/teljesítményt.

Ha egyetlen GPU-ja van, vagy nincs GPU-ja, akkor a kézenfekvő választás az APPO. Mindazonáltal az APPO is lehet a legjobb, mivel a gradiensek összesítése általában információ- és így teljesítményvesztéssel jár.

Ha rugalmasabb szeretne lenni dolgozói szerepkörében, akkor az RF-DPPO lehet a legjobb. A DD-PPO jó lehet, ha a modellje nagy, és aggódik a szűk keresztmetszetek miatt, amelyek egy központi paraméterkiszolgálóval kapcsolatban merülhetnek fel (különösen, ha több gépen keresztül csatlakozik a hálózathoz). A DPPO jó választás, de néha a teljesítmény romolhat az aszinkron frissítések miatt.

Az alábbi táblázat leírja az osztott memória használatát (amely lassú lehet a többfeldolgozási többletterhelés miatt), az egyes rétegek végrehajtási idejét (a kibontott diagramok ismeretében), valamint azt, hogy elkerüli-e a több gradiens összesítését.

Figyelje meg, hogy az RF-DPPO több szinkronizálási pillanattal rendelkezik, ami lelassíthatja az általános képzési folyamatot, de növelheti a stabilitást is.

Az APPO egyértelműen sokkal lassabb, mivel nem párhuzamosítja a gradiens-számítást.

Következtetés

Ez a cikk remélhetőleg segít kitalálni egy jó kiindulási architektúrát, amelyet kipróbálhat, de előfordulhat, hogy másokkal kell kísérleteznie, hogy megtudja, melyik a legjobb az Ön konkrét problémájához. Ezenkívül próbáljon új módszereket kitalálni egy elosztott PPO-algoritmus megtervezésére, amely hasznos a korlátozásokhoz.