By Dr. Mario Michael Krell, vezető gépi tanulási vezető a Graphcore-nál és Matej Kosec, AI alkalmazások szakértője a Graphcore-nál

Kép szerzőtől.

 

Egy új csomagoló algoritmus használatával több mint kétszeresére gyorsítottuk a természetes nyelvi feldolgozást a BERT-Large betanítása során. Új csomagolási technikánk eltávolítja a párnázást, ami jelentősen hatékonyabb számítást tesz lehetővé.

Azt gyanítjuk, hogy ez a genomikai és fehérjehajtogatási modellekre, valamint más, ferde hosszeloszlású modellekre is alkalmazható, hogy sokkal szélesebb hatást fejtsenek ki a különböző iparágakban és alkalmazásokban.

Bemutattuk a Graphcore rendkívül hatékony, nem negatív legkisebb négyzetek hisztogram-csomagoló algoritmusát (vagy NNLSHP-t), valamint a csomagolt sorozatokra alkalmazott BERT algoritmusunkat egy új cikkben [1].

Számítási veszteség az NLP-ben a szekvencia kitöltése miatt

 
 
A BERT képzés optimalizálásának új módjait vizsgálni kezdtük, miközben nemrégiben dolgoztunk benchmark beküldések az MLPerf™-hez. A cél az volt, hogy olyan hasznos optimalizációkat fejlesszünk ki, amelyek könnyen alkalmazhatók a valós alkalmazásokban. A BERT természetes választás volt, mint az egyik olyan modell, amelyre ezeknek az optimalizálásoknak a középpontjában áll, mivel széles körben használják az iparban és sok ügyfelünk.

Igazán meglepett minket, amikor megtudtuk, hogy a Wikipédia-adatkészletet használó saját BERT-Large képzési alkalmazásunkban az adatkészletben lévő tokenek 50%-a kitöltés volt, ami sok elpazarolt számítást eredményezett.

A szekvenciák kitöltése, hogy mindegyiket egyenlő hosszúságúra igazítsa, egy általános megközelítés a GPU-k esetében, de úgy gondoltuk, hogy érdemes egy másik megközelítést kipróbálni.

A sorozatok hossza két okból is nagy eltérést mutat:

1. Az alapul szolgáló Wikipédia-adatok nagy eltéréseket mutatnak a dokumentum hosszában
2. Maga a BERT-előfeldolgozás véletlenszerűen csökkenti a kinyert dokumentumok méretét, amelyeket kombinálva generál egy tanítási sorozatot.

A hossz 512-es maximális hosszra való kitöltése azt eredményezi, hogy az összes tokenek 50%-a padding token lesz. A kitöltés 50%-ának valós adatokkal való helyettesítése 50%-kal több adat feldolgozását eredményezheti ugyanazzal a számítási ráfordítással, és így optimális körülmények között kétszeres sebességgel.

1. ábra: Wikipédia-adatkészlet-eloszlások. Kép szerzőtől.

 

Ez konkrétan a Wikipédiára vonatkozik? Nem.

Nos, akkor ez a nyelvre jellemző? Nem.

Valójában ferde hosszeloszlások mindenhol megtalálhatók: a nyelvben, a genomikában és a fehérjehajtogatásban. A 2. és 3. ábra a SQuAD 1.1 adatkészlet és a GLUE adatkészletek eloszlását mutatja.

2. ábra: SQuAD 1.1 BERT előképzési adatkészlet szekvencia hossz hisztogramja a 384 maximális sorozathosszhoz. A kép szerzője.

 


3. ábra: GLUE adatkészlet sorozathosszúság hisztogramja 128 maximális sorozathosszhoz. A kép szerzője.

 

Hogyan kezelhetjük a különböző hosszúságokat, miközben elkerüljük a számítási pazarlást?

A jelenlegi megközelítések különböző hosszúságú számítási rendszermagokat igényelnek, vagy hogy a mérnök programozottan távolítsa el a kitöltést, majd ismételten hozzáadja azt minden figyelemblokk és veszteségszámításhoz. A számítások mentése a kód felrobbantásával és bonyolultabbá tételével nem volt vonzó, ezért valami jobbat kerestünk. Nem tudnánk egyszerűen több sorozatot összerakni egy maximális hosszúságú csomagban, és az egészet együtt feldolgozni? Kiderült, megtehetjük!

Ez a megközelítés három kulcsfontosságú összetevőt igényel:

1. Hatékony algoritmus annak eldöntésére, hogy mely mintákat állítsa össze, hogy a lehető legkevesebb kitöltés maradjon
2. A BERT modell beállítása úgy, hogy a sorozatok helyett csomagokat dolgozzon fel
3. És a hiperparaméterek beállítása

Csomagolás

 
 
Eleinte valószínűtlennek tűnt, hogy egy nagy adathalmazt, például a Wikipédiát nagyon hatékonyan tudjon csomagolni. Ezt a problémát általában szemetes-csomagolásnak nevezik. Még akkor is, ha a csomagolás három vagy kevesebb szekvenciára korlátozódik, a kapott probléma továbbra is erősen NP-teljes lenne, és hiányzik a hatékony algoritmikus megoldás. A meglévő heurisztikai csomagoló algoritmusok nem voltak kecsegtetők, mert legalább bonyolultságuk volt O(n log(n)), ahol n a sorozatok száma (~16M a Wikipédiában). Olyan megközelítések érdekeltek bennünket, amelyek több millió szekvenciára skálázhatók.

Két trükk segített drasztikusan csökkenteni a bonyolultságot:

1. A szekvenciák számának korlátozása egy csomagban háromra (az első megoldási megközelítésünkhöz)
2. Kizárólag a sorozathosszúság hisztogramján működik, minden előforduló hosszúsághoz egy bin

A maximális sorozathosszunk 512 volt. Tehát a hisztogramra való átállás a 16 millió szekvenciáról 512 hosszúságúra csökkentette a dimenziót és a bonyolultságot. Maximum három sorozat engedélyezése egy csomagban 22K-ra csökkentette a megengedett hosszkombinációk számát. Ez már magában foglalta azt a trükköt, hogy a sorozatokat hosszúság szerint kell rendezni a csomagban. Miért ne próbálhatna ki 4 sorozatot? Ez a kombinációk számát 22 940-ról 3 XNUMX-ra növelte, ami túl sok volt az első modellezési megközelítésünkhöz. Ezenkívül a XNUMX. mélység már kiemelkedően magas csomagolási hatékonyságot ért el.

Eredetileg úgy gondoltuk, hogy háromnál több sorozat használata egy csomagban növeli a számítási többletköltséget, és hatással lesz a konvergencia viselkedésére a képzés során. Azonban az olyan alkalmazások támogatására, mint például a következtetések, amelyek még gyorsabb, valós idejű csomagolást igényelnek, kifejlesztettük a rendkívül hatékony Non-Negative Least Squares Histogram-Packing (NNLSHP) algoritmust.

Nem negatív legkisebb négyzetek hisztogram-csomagolása (NNLSHP)

 
 
A ládacsomagolást gyakran matematikai optimalizálási problémaként fogalmazzák meg. 16 millió (vagy több) szekvencia esetén azonban ez nem praktikus. A problémás változók önmagukban meghaladnák a legtöbb gép memóriáját. A hisztogram alapú megközelítés matematikai programja meglehetősen ügyes. Az egyszerűség kedvéért a legkisebb négyzetek megközelítése mellett döntöttünk (Ax=b) hisztogram vektorral b. Kibővítettük a stratégia vektor lekérésével x hogy ne legyen negatív, és súlyokat adjon hozzá, hogy lehetővé tegye a kisebb párnázást.

A trükkös rész a stratégiai mátrix volt. Minden oszlop maximum három összeggel rendelkezik, és azt kódolja, hogy mely szekvenciák kerüljenek egymásba, hogy pontosan megfeleljenek a kívánt teljes hossznak; esetünkben 512. A sorok kódolják az egyes lehetséges kombinációkat, hogy elérjék a teljes hosszúságot. A stratégiai vektor x ez az, amit kerestünk, amely leírja, hogy milyen gyakran választjuk a 20 600 kombináció közül melyiket. Érdekes módon csak körülbelül XNUMX kombinációt választottak ki a végén. A pontos megoldáshoz a stratégia számít x pozitív egész számoknak kell lenniük, de rájöttünk, hogy egy közelítő kerekített megoldás csak nem negatív x elegendő volt. A hozzávetőleges megoldáshoz egy egyszerű, kész megoldással 30 másodpercen belül lehet eredményt elérni.

4. ábra: Példa stratégiai mátrixra a 8-as sorozathosszra és a 3-as csomagolási mélységre. A sorok az 1–8 hosszúságú sorozatokat jelölik, amelyek össze vannak csomagolva, az oszlopok pedig az összes lehetséges hosszkombinációt egy csomagban, különösebb sorrend nélkül. Kép szerzőtől.

 

A végén javítanunk kellett néhány mintát, amelyekhez nem rendeltek stratégiát, de ezek minimálisak voltak. Kifejlesztettünk egy variánsmegoldót is, amely kikényszeríti, hogy minden szekvencia be legyen csomagolva, esetleg kitöltéssel, és a kitöltéstől függő súlyozással rendelkezik. Sokkal tovább tartott, és a megoldás sem volt sokkal jobb.

Legrövidebb csomag-első hisztogram csomagolás

 
 
Az NNLSHP megfelelő csomagolási megközelítést biztosított számunkra. Mindazonáltal azon töprengtünk, hogy elméletileg sikerül-e gyorsabb online megközelítést elérni, és megszüntetni azt a korlátot, hogy csak 3 szekvenciát állítsunk össze.

Ezért némi ihletet merítettünk a meglévő csomagolási algoritmusokból, de továbbra is a hisztogramokra koncentráltunk.

Az első algoritmusunk, a legrövidebb csomag-első hisztogram-csomagolás (SPFHP) négy összetevőből áll:

1. Működtessen a hisztogram számlálásával a leghosszabb sorozattól a legrövidebbig
2. Ha az aktuális sorozathossz nem fér bele egyik csomagba sem, indítson új csomagkészletet
3. Ha több illesztés is van, vegye azt a csomagot, ahol a sorozathosszak összege a legrövidebb, és módosítsa a számokat ennek megfelelően
4. Ellenőrizze újra a fennmaradó számok illeszkedését

Ez a megközelítés volt a legegyszerűbb megvalósítani, és mindössze 0.02 másodpercig tartott.

Egy változat szerint a sorozathosszak legnagyobb összegét vették a legrövidebb és osztott számok helyett a tökéletes illeszkedés érdekében. Összességében ez nem sokat változtatott a hatékonyságon, de jelentősen megnövelte a kód bonyolultságát.

Hogyan működik a legrövidebb csomag-első hisztogram-csomagolás. Animáció a szerzőtől.

 

Wikipédia, SQuAD 1.1, GLUE csomagolási eredmények

 
 
Az 1., 2. és 3. táblázat bemutatja a két javasolt algoritmusunk csomagolási eredményeit. Csomagolási mélység a csomagolt sorozatok maximális számát írja le. Az 1. csomagolási mélység a BERT alap megvalósítása. A maximálisan előforduló csomagolási mélységet, ha nincs határérték beállítva, további „max”-tal jelöljük. A csomagok száma leírja az új csomagolt adatkészlet hosszát. Hatékonyság a valódi tokenek százalékos aránya a csomagolt adatkészletben. A csomagolási tényező leírja az ebből eredő potenciális gyorsulást az 1-es csomagolási mélységhez képest.

Négy fő észrevételünk volt:

1. Minél ferdebb az elosztás, annál nagyobb előnyökkel jár a csomagolás.
2. Minden adatkészletnek előnyös a csomagolás. Néhányan akár kétszeresnél is nagyobb mértékben.
3. Az SPFHP hatékonyabbá válik, ha a csomagolási mélység nincs korlátozva.
4. Maximum 3 csomagolt szekvencia esetén minél összetettebb az NNLSHP, annál hatékonyabb (99.75 vs. 89.44).

1. táblázat: A javasolt csomagolási algoritmusok (SPFHP és NNLSHP) fő teljesítményeredményei a Wikipédián. Kép szerzőtől.

 


2. táblázat: A SQUaD 1.1 BERT előképzéshez javasolt csomagolási algoritmusok teljesítményeredményei. Kép szerzőtől.

 


3. táblázat: A GLUE adatkészlethez javasolt csomagolási algoritmusok teljesítményeredményei. Csak az alapvonal és az SPFHP tömörítési eredmények jelennek meg a csomagolási mélység korlátozása nélkül. Kép szerzőtől.

 

A BERT feldolgozás beállítása

 
 
Érdekesség a BERT architektúrában, hogy a legtöbb feldolgozás token szinten történik, ami azt jelenti, hogy nem zavarja a csomagolásunkat. Csak négy összetevőt kell módosítani: a figyelemmaszk, az MLM veszteség, az NSP veszteség és a pontosság.

Mind a négy megközelítés kulcsa a különböző számú szekvencia kezeléséhez a vektorizálás és az összefűzhető szekvenciák maximális száma volt. A figyelem kedvéért már volt egy maszkunk a párnázás megszólítására. Ennek több szekvenciára való kiterjesztése egyszerű volt, amint az a következő TensorFlow pszeudokódból látható. A koncepció az, hogy gondoskodtunk arról, hogy a figyelem a különálló szekvenciákra korlátozódjon, és ne terjedhessen tovább.

Figyelem maszk kód minta.

 


5. ábra: Példa nulla-egy maszkra

 

A veszteségszámításhoz elvileg kicsomagoljuk a szekvenciákat és kiszámítjuk a különálló veszteségeket, végül megkapjuk a sorozatok (csomagok helyett) a veszteségek átlagát.

Az MLM elvesztése esetén a kód így néz ki:

Veszteségszámítási kódminta.

 

Az NSP veszteség és a pontosság tekintetében az elv ugyanaz. Nyilvános példáinkban a megfelelő kódot házon belül találhatja meg PopART keretrendszer.

Wikipédia általános és gyorsítási becslés

 
 
A BERT módosításával két kérdésünk volt:

1. Mennyi rezsi jár vele?
2. Mennyiben függ a rezsi a csomagban összeállított sorozatok maximális számától?

Mivel a BERT-ben az adatok előkészítése nehézkes lehet, egy parancsikont használtunk, és összeállítottuk a kódot több különböző csomagolási mélységhez, és összehasonlítottuk a megfelelő (mért) ciklusokat. Az eredmények a 4. táblázatban jelennek meg felső, az áteresztőképesség százalékos csökkenését jelöljük a csomagolást lehetővé tévő modell módosításai miatt (például a figyelem maszkolási sémája és a megváltozott veszteségszámítás). A megvalósított gyorsítás a csomagolás miatti gyorsulás kombinációja (a csomagolási tényező) és az áteresztőképesség csökkenése miatt felső.

4. táblázat: A javasolt csomagolási algoritmusok (SPFHP és NNLSHP) becsült gyorsítási összehasonlítása a Wikipédián. Kép szerzőtől.

 

A vektorizációs technikának köszönhetően meglepően kicsi a többletköltség, és nincs hátránya a sok szekvencia összecsomagolásának.

Hiperparaméter-beállítások

 
 
A csomagolással megduplázzuk a tényleges tételméretet (átlagosan). Ez azt jelenti, hogy módosítanunk kell a képzési hiperparamétereket. Egy egyszerű trükk az, hogy felére csökkenti a gradiens felhalmozási számot, hogy ugyanaz a tényleges átlagos adagméret maradjon, mint az edzés előtt. Az előre betanított ellenőrzőpontokkal rendelkező benchmark beállítás használatával láthatjuk, hogy a pontossági görbék tökéletesen egyeznek.

6. ábra: A betanulási görbék összehasonlítása csomagolt és kicsomagolt feldolgozás esetén csökkentett tételméret a tömött megközelítéshez. Képek szerzőtől.

 

A pontosság megegyezik: az MLM edzési veszteség kezdetben kissé eltérhet, de gyorsan utoléri. Ez a kezdeti különbség a figyelemrétegek enyhe módosításaiból származhat, amelyek az előző képzésben a rövid sorozatok felé torzulhattak.

A lassulás elkerülése érdekében néha segít megőrizni az eredeti kötegméretet, és a hiperparamétereket a megnövelt tényleges kötegmérethez (duplázva) igazítani. A fő hiperparaméterek, amelyeket figyelembe kell venni, a béta paraméterek és a tanulási sebességek. Az egyik általános megközelítés a köteg méretének megduplázása, ami esetünkben csökkentette a teljesítményt. A LAMB optimalizáló statisztikáit tekintve bebizonyosodott, hogy a béta paraméternek a tömörítési tényező hatványára emelése megfelel több adag egymás utáni betanításának, hogy a lendület és a sebesség összehasonlítható legyen.

7. ábra: A betanulási görbék összehasonlítása csomagolt és kicsomagolt feldolgozás esetén heurisztikus alkalmazott. Képek szerzőtől.

 

Kísérleteink azt mutatták, hogy a béta kettős hatványra adása jó heurisztika. Ebben a forgatókönyvben a görbék várhatóan nem egyeznek, mert a tétel méretének növelése általában csökkenti a konvergencia sebességét a minták/korszakok értelmében, amíg el nem érjük a célpontosságot.

Most az a kérdés, hogy a gyakorlati forgatókönyv szerint valóban elérjük-e a várt gyorsulást?

8. ábra: Tanulási görbék összehasonlítása csomagolt és kicsomagolt feldolgozás esetén a optimalizált beállítás. Képek szerzőtől.

 

Igen! További gyorsulást kaptunk, mert tömörítettük az adatátvitelt.

Következtetés

 
 
A mondatok összecsomagolása számítási erőfeszítést és környezetet takaríthat meg. Ez a technika bármely keretrendszerben megvalósítható, beleértve a PyTorch-ot és a TensorFlow-t. Egyértelmű 2-szeres gyorsítást kaptunk, és közben kiterjesztettük a csomagolási algoritmusok legkorszerűbb szintjét.

További alkalmazások, amelyekre kíváncsiak vagyunk, a genomika és a fehérjehajtogatás, ahol hasonló adateloszlás figyelhető meg. A Vision transzformátorok is érdekes területek lehetnek a különböző méretű csomagolt képek alkalmazására. Ön szerint mely alkalmazások működnének jól? Szeretnénk hallani Önről!

Olvassa el a Papírt

Hozzáférés a kódhoz a GitHubon

Köszönöm

 
 
Köszönet a Graphcore alkalmazásmérnöki csapatában dolgozó kollégáinknak, Sheng Fu-nak és Mrinal Iyernek, hogy hozzájárultak ehhez a munkához, és köszönet Douglas Orr-nak a Graphcore kutatócsapatától az értékes visszajelzésekért.

Referenciák

 
 
[1] M. Kosec, S. Fu, MM Krell, Csomagolás: 2x NLP BERT gyorsítás felé (2021), arXiv

 
Dr. Mario Michael Krell a Graphcore fő gépi tanulási vezetője. Mario több mint 12 éve kutat és fejleszt gépi tanulási algoritmusokat, szoftvereket hozva létre olyan változatos iparágak számára, mint a robotika, az autóipar, a távközlés és az egészségügy. A Graphcore-nál ő is hozzájárult ahhoz, hogy lenyűgöző MLPerf beadványok és szenvedélye az új, nem szabványos modellek felgyorsítása, például a közelítő Bayes-számítás a COVID-19 statisztikai adatelemzéséhez.

Matej Kosec a Palo Alto-i Graphcore mesterséges intelligencia-alkalmazások szakértője. Korábban mesterséges intelligencia-tudósként dolgozott az autonóm vezetéssel foglalkozó NIO-nál San Joséban, és a Stanford Egyetemen szerzett mesterfokozatot repülésből és asztronautikából.

eredeti. Engedéllyel újra közzétéve.

Kapcsolódó:

• Tudásgráf készítése álláskereséshez a BERT segítségével
• Hogyan képezzünk ki egy BERT-modellt a semmiből
• A BERT megértése ölelő arccal