By Tri Mario Michael Krell, koneoppimisen pääjohtaja Graphcoressa & Matej Kosec, Graphcoren tekoälysovellusten asiantuntija

Kuva tekijältä.

 

Uuden pakkausalgoritmin avulla olemme nopeuttaneet luonnollisen kielen käsittelyä yli 2 kertaa BERT-Largen koulutuksen aikana. Uusi pakkaustekniikkamme poistaa pehmusteet, mikä mahdollistaa huomattavasti tehokkaamman laskennan.

Epäilemme, että tätä voitaisiin soveltaa myös genomiikkaan ja proteiinien laskostumismalleihin ja muihin malleihin, joissa on vino pituusjakaumat, jotta niillä olisi paljon laajempi vaikutus eri teollisuudenaloilla ja sovelluksissa.

Esittelimme Graphcoren erittäin tehokkaan Non-Negative Least Squares Histogram-Packing -algoritmin (tai NNLSHP:n) sekä BERT-algoritmimme, jota sovelletaan pakattuihin sekvensseihin uudessa paperissa [1].

Laskennallinen hukka NLP:ssä sekvenssipehmusteesta johtuen

 
 
Aloimme tutkia uusia tapoja optimoida BERT-koulutusta työskennellessämme äskettäin vertaa MLPerf™-lähetyksiä. Tavoitteena oli kehittää hyödyllisiä optimointeja, jotka voitaisiin helposti ottaa käyttöön tosielämän sovelluksissa. BERT oli luonnollinen valinta yhdeksi malleista, johon näihin optimointiin keskittyä, sillä sitä käytetään laajasti teollisuudessa ja monien asiakkaidemme keskuudessa.

Olimme todella yllättyneitä kuullessamme, että omassa Wikipedia-tietoaineistoa käyttävässä BERT-Large-koulutussovelluksessamme 50 % tietojoukon tunnuksista oli täytettyjä, mikä johti paljon hukkaan laskemiseen.

Täytesekvenssien kohdistaminen samaan pituuteen on yleinen lähestymistapa, jota käytetään GPU:iden kanssa, mutta ajattelimme, että kannattaa kokeilla erilaista lähestymistapaa.

Sekvensseillä on suuri pituusvaihtelu kahdesta syystä:

1. Wikipedian taustalla olevat tiedot osoittavat suuren vaihtelun asiakirjan pituudessa
2. Itse BERT-esikäsittely pienentää satunnaisesti poimittujen asiakirjojen kokoa, jotka yhdistetään harjoitusjakson luomiseksi

Pituuden täyttäminen 512:n enimmäispituuteen johtaa siihen, että 50 % kaikista tokeneista on täytetokeneita. 50 prosentin täytön korvaaminen todellisella tiedolla voi johtaa siihen, että dataa käsitellään 50 prosenttia enemmän samalla laskentateholla ja näin ollen kaksinkertainen nopeus optimaalisissa olosuhteissa.

Kuva 1: Wikipedia-tietojoukon jakaumat. Kuva tekijältä.

 

Onko tämä vain Wikipediassa? Ei.

No, onko se sitten kielikohtaista? Ei.

Itse asiassa vinoja pituusjakaumia löytyy kaikkialta: kielessä, genomiikassa ja proteiinien taittumisessa. Kuvat 2 ja 3 esittävät SQuAD 1.1 -tietojoukon ja GLUE-tietojoukon jakaumia.

Kuva 2: SQuAD 1.1 BERT:n esikoulutustietojoukon sekvenssin pituushistogrammi sekvenssin enimmäispituudelle 384. Kuva tekijältä.

 


Kuva 3: GLUE-tietojoukon sekvenssipituuden histogrammit sekvenssin enimmäispituudelle 128. Kuva tekijältä.

 

Kuinka voimme käsitellä eri pituuksia samalla kun vältetään laskennallinen hukka?

Nykyiset lähestymistavat vaativat erilaisia ​​laskentaytimiä eri pituuksille tai insinöörin poistamaan ohjelmallisesti täyte ja lisäämään sen sitten takaisin toistuvasti jokaista huomionesto- ja menetyslaskelmaa varten. Laskennan säästäminen puhaltamalla koodia ja tekemällä siitä monimutkaisempi ei houkutellut, joten etsimme jotain parempaa. Emmekö voisi vain laittaa useita sarjoja yhteen pakkaukseen, jonka pituus on maksimi, ja käsitellä ne kaikki yhdessä? Osoittautuu, että voimme!

Tämä lähestymistapa vaatii kolme keskeistä ainesosaa:

1. Tehokas algoritmi päättää, mitkä näytteet koota, jotta täytettä olisi mahdollisimman vähän jäljellä
2. BERT-mallin säätäminen käsittelemään paketteja sekvenssien sijaan
3. Ja hyperparametrien säätäminen

Pakkaus

 
 
Aluksi tuntui epätodennäköiseltä, että pystyisit pakata suuren tietojoukon, kuten Wikipedian, erittäin tehokkaasti. Tämä ongelma tunnetaan yleisesti roskapakkauksena. Vaikka pakkaus on rajoitettu kolmeen sekvenssiin tai vähemmän, tuloksena oleva ongelma olisi silti vahvasti NP-täydellinen, ilman tehokasta algoritmista ratkaisua. Nykyiset heuristiset pakkausalgoritmit eivät olleet lupaavia, koska niiden monimutkaisuus oli vähintään O(n loki(n)), missä n on sekvenssien lukumäärä (~16M Wikipediassa). Olimme kiinnostuneita lähestymistavoista, jotka skaalautuisivat hyvin miljooniin sekvensseihin.

Kaksi temppua auttoivat meitä vähentämään monimutkaisuutta dramaattisesti:

1. Pakkauksen sekvenssien määrän rajoittaminen kolmeen (ensimmäisen ratkaisumallimme mukaan)
2. Toimii yksinomaan sekvenssin pituuden histogrammilla, jossa on yksi laatikko jokaista esiintyvää pituutta kohti

Sekvenssin maksimipituus oli 512. Joten histogrammiin siirtyminen pienensi ulottuvuutta ja monimutkaisuutta 16 miljoonasta sekvenssistä 512 pituuteen. Enintään kolmen sekvenssin salliminen pakkauksessa pienensi sallittujen pituusyhdistelmien lukumäärää 22 4:een. Tähän sisältyi jo temppu vaatia sekvenssien lajittelua pituuden mukaan pakkauksessa. Joten miksi et kokeilisi 22 jaksoa? Tämä lisäsi yhdistelmien määrää 940 3:sta XNUMX XNUMX:een, mikä oli liikaa ensimmäiselle mallinnusmenetelmällemme. Lisäksi syvyys XNUMX saavutti jo huomattavan korkean pakkaustehokkuuden.

Alun perin ajattelimme, että useamman kuin kolmen sekvenssin käyttäminen pakkauksessa lisäisi laskennallista kustannuksia ja vaikuttaisi konvergenssikäyttäytymiseen harjoittelun aikana. Kuitenkin tukeaksemme sovelluksia, kuten päättelyä, jotka vaativat vielä nopeampaa, reaaliaikaista pakkausta, kehitimme erittäin tehokkaan Non-Negative Least Squares Histogram-Packing (NNLSHP) -algoritmin.

Ei-negatiivinen pienimmän neliösumman histogrammipakkaus (NNLSHP)

 
 
Säiliön pakkaus muotoillaan melko usein matemaattiseksi optimointiongelmaksi. 16 miljoonalla (tai useammalla) sekvenssillä tämä ei kuitenkaan ole käytännöllistä. Pelkästään ongelmamuuttujat ylittäisivät useimpien koneiden muistin. Histogrammiin perustuvan lähestymistavan matemaattinen ohjelma on varsin siisti. Yksinkertaisuuden vuoksi päätimme käyttää pienimmän neliösumman lähestymistapaa (Ax=b) histogrammivektorilla b. Laajensimme sitä pyytämällä strategiavektoria x olla ei-negatiivisia ja lisätä painoja vähäisen pehmusteen mahdollistamiseksi.

Hankalin osa oli strategiamatriisi. Jokaisen sarakkeen enimmäissumma on kolme ja se koodaa, mitkä sekvenssit pakataan yhteen vastaamaan tarkasti haluttua kokonaispituutta. 512 meidän tapauksessamme. Rivit koodaavat jokaisen mahdollisen yhdistelmän kokonaispituuden saavuttamiseksi. Strategian vektori x on se mitä etsimme, mikä kuvaa kuinka usein valitsemme minkä tahansa 20 600 yhdistelmästä. Mielenkiintoista on, että vain noin XNUMX yhdistelmää valittiin lopussa. Tarkan ratkaisun saamiseksi strategia on tärkeä x pitäisi olla positiivisia kokonaislukuja, mutta ymmärsimme, että likimääräinen pyöristetty ratkaisu, jossa vain ei-negatiivi x oli riittävä. Likimääräisen ratkaisun saamiseksi voidaan käyttää yksinkertaista käyttövalmis ratkaisijaa, jolla saadaan tulos 30 sekunnissa.

Kuva 4: Esimerkki strategiamatriisista sekvenssin pituudelle 8 ja pakkaussyvyydelle 3. Rivit tarkoittavat pituudeltaan 1–8 olevia sekvenssejä, jotka pakataan yhteen ja sarakkeet kaikkia mahdollisia pituusyhdistelmiä pakkauksessa ilman erityistä järjestystä. Kuva tekijältä.

 

Lopuksi jouduimme korjaamaan joitakin näytteitä, joille ei annettu strategiaa, mutta ne olivat minimaalisia. Kehitimme myös muunnelman ratkaisijan, joka varmistaa, että jokainen sekvenssi pakataan, mahdollisesti pehmusteella, ja jonka painotus riippuu täytteestä. Se kesti paljon kauemmin, eikä ratkaisu ollut paljon parempi.

Lyhyin pakkaus-ensin histogrammipakkaus

 
 
NNLSHP toimitti meille riittävän pakkaustavan. Mietimme kuitenkin, voisimmeko teoriassa saada nopeamman online-kykyisen lähestymistavan ja poistaa vain 3 sekvenssin yhdistämisen rajoituksen.

Siksi otimme inspiraatiota olemassa olevista pakkausalgoritmeista, mutta keskityimme silti histogrammeihin.

Ensimmäisessä algoritmissamme, Shortest-pack-first histogram-pakkauksessa (SPFHP), on neljä ainesosaa:

1. Käytä histogrammin lukumääriä pisimmistä sarjoista lyhimpiin
2. Jos nykyinen sarjan pituus ei mahdu mihinkään pakettiin, aloita uusi pakettisarja
3. Jos osumia on useita, ota paketti, jossa sarjan pituuden summa on lyhin, ja muokkaa lukuja vastaavasti
4. Tarkista uudelleen jäljellä olevien lukujen yhteensopivuus

Tämä lähestymistapa oli yksinkertaisin toteuttaa ja kesti vain 0.02 sekuntia.

Eräs muunnelma oli ottaa sarjan pituuden suurin summa lyhimmän ja jaetun määrän sijaan täydellisemmän istuvuuden saamiseksi. Kaiken kaikkiaan tämä ei muuttanut tehokkuutta paljon, mutta lisäsi koodin monimutkaisuutta paljon.

Kuinka lyhyin pakkaus ensin -histogrammipakkaus toimii. Animaatio kirjoittajalta.

 

Wikipedia, SQuAD 1.1, GLUE-pakkaustulokset

 
 
Taulukot 1, 2 ja 3 esittävät kahden ehdottamamme algoritmimme pakkaustulokset. Pakkaussyvyys kuvaa pakattujen sekvenssien enimmäismäärää. Pakkaussyvyys 1 on BERT-toteutus. Suurin esiintyvä pakkaussyvyys, wen no limit on merkitty ylimääräisellä "max". The pakkausten määrä kuvaa uuden pakatun tietojoukon pituuden. Tehokkuus on todellisten tokenien prosenttiosuus pakatussa tietojoukossa. The pakkaustekijä kuvaa tuloksena saatavaa mahdollista nopeutta verrattuna pakkaussyvyyteen 1.

Meillä oli neljä päähavaintoa:

1. Mitä vinoutuisempi jakelu on, sitä suuremmat ovat pakkaamisen edut.
2. Kaikki tietojoukot hyötyvät pakkaamisesta. Jotkut jopa enemmän kuin kaksinkertaisesti.
3. SPFHP tehostuu, kun pakkaussyvyys ei ole rajoitettu.
4. Mitä monimutkaisempi NNLSHP on, sitä tehokkaampi se on (3 vs. 99.75).

Taulukko 1: Ehdotettujen pakkausalgoritmien (SPFHP ja NNLSHP) tärkeimmät suorituskykytulokset Wikipediassa. Kuva tekijältä.

 


Taulukko 2: SQUaD 1.1 BERT -esikoulutuksen ehdotettujen pakkausalgoritmien suorituskykytulokset. Kuva tekijältä.

 


Taulukko 3: GLUE-tietojoukon ehdotettujen pakkausalgoritmien suorituskykytulokset. Vain perusviiva ja SPFHP-pakkaustulokset pakkaussyvyyttä rajoittamatta näytetään. Kuva tekijältä.

 

BERT-käsittelyn säätö

 
 
Jotain mielenkiintoista BERT-arkkitehtuurissa on, että suurin osa käsittelystä tapahtuu token-tasolla, mikä tarkoittaa, että se ei häiritse pakkaamistamme. On vain neljä säätöä vaativaa osaa: huomiomaski, MLM-häviö, NSP-häviö ja tarkkuus.

Avain kaikissa neljässä lähestymistavassa erilaisten sekvenssien käsittelyyn oli vektorointi ja ketjutettavissa olevien sekvenssien enimmäismäärän käyttö. Huomion vuoksi meillä oli jo naamio pehmusteen käsittelemiseksi. Tämän laajentaminen useisiin sekvensseihin oli yksinkertaista, kuten voidaan nähdä seuraavasta TensorFlow-pseudokoodista. Ajatuksena on, että varmistimme, että huomio rajoittuu erillisiin sarjoihin, eikä se voi ulottua sen pidemmälle.

Huomiomaskin koodinäyte.

 


Kuva 5: Esimerkki nolla-yksi maskista

 

Häviölaskentaa varten periaatteessa puretaan sekvenssit ja lasketaan erilliset häviöt, jolloin saadaan lopulta sekvenssien häviöiden keskiarvo (pakkausten sijaan).

MLM-tappion koodi näyttää tältä:

Tappion laskentakoodinäyte.

 

NSP-häviön ja tarkkuuden osalta periaate on sama. Julkisissa esimerkeissämme löydät vastaavan koodin talomme kautta PopART-kehys.

Wikipedian yleiskustannukset ja nopeusarvio

 
 
BERT:n muutoksen yhteydessä meillä oli kaksi kysymystä:

1. Kuinka paljon yleiskustannuksia se tuo mukanaan?
2. Kuinka paljon yleiskustannukset riippuvat pakettiin koottujen sekvenssien enimmäismäärästä?

Koska tietojen valmistelu BERT:ssä voi olla hankalaa, käytimme pikakuvaketta ja käänsimme koodin useille eri pakkaussyvyyksille ja vertasimme vastaavia (mitattuja) syklejä. Tulokset näkyvät taulukossa 4. Kanssa yläpuolella, tarkoitamme suorituskyvyn prosentuaalista laskua, joka johtuu pakkaamisen mahdollistavan mallin muutoksista (kuten huomion peittokaavio ja muuttunut hävikkilaskenta). The toteutunut vauhti on yhdistelmä pakkaamisesta johtuvaa nopeutta ( pakkaustekijä) ja suorituskyvyn lasku, joka johtuu yläpuolella.

Taulukko 4: Ehdotettujen pakkausalgoritmien (SPFHP ja NNLSHP) arvioitu nopeusvertailu Wikipediassa. Kuva tekijältä.

 

Vektorisointitekniikan ansiosta lisäkustannus on yllättävän pieni, eikä monien sekvenssien pakkaamisesta ole haittaa.

Hyperparametrien säädöt

 
 
Pakkaamalla tuplaamme tehokkaan eräkoon (keskimäärin). Tämä tarkoittaa, että meidän on säädettävä koulutuksen hyperparametreja. Yksinkertainen temppu on leikata gradientin kertymismäärä puoleen, jotta keskimääräinen eräkoko pysyy samana kuin ennen harjoittelua. Käyttämällä benchmark-asetusta, jossa on esikoulutettuja tarkistuspisteitä, voimme nähdä, että tarkkuuskäyrät täsmäävät täydellisesti.

Kuva 6: Pakatun ja pakkaamattoman käsittelyn oppimiskäyrien vertailu pienennetty eräkoko täyteläistä lähestymistapaa varten. Kuvat tekijältä.

 

Tarkkuus täsmää: MLM-harjoitteluhäviö voi olla hieman erilainen alussa, mutta se saavuttaa nopeasti. Tämä alkuperäinen ero saattoi johtua keskittymiskerrosten vähäisistä säädöistä, jotka ovat saattaneet olla suuntautuneet kohti lyhyitä sekvenssejä edellisessä harjoituksessa.

Hidastumisen välttämiseksi se auttaa toisinaan pitämään alkuperäisen erän koon samana ja säätämään hyperparametrit suurennetun tehollisen eräkoon mukaan (kaksinkertaistettu). Tärkeimmät huomioon otettavat hyperparametrit ovat beta-parametrit ja oppimisnopeudet. Yksi yleinen tapa on kaksinkertaistaa eräkoko, mikä meidän tapauksessamme heikensi suorituskykyä. LAMB-optimoijan tilastoja tarkasteltaessa voimme todistaa, että beeta-parametrin nostaminen pakkauskertoimen tehoon vastaa useiden erien harjoittelua peräkkäin, jotta liikemäärä ja nopeus ovat vertailukelpoisia.

Kuva 7: Pakatun ja pakkaamattoman käsittelyn oppimiskäyrien vertailu heuristiikka sovelletaan. Kuvat tekijältä.

 

Kokeilumme osoittivat, että beetan ottaminen kahden potenssiin on hyvä heuristiikka. Tässä skenaariossa käyrien ei odoteta täsmäävän, koska erän koon kasvattaminen yleensä vähentää konvergenssinopeutta näytteiden/jaksojen mielessä, kunnes tavoitetarkkuus saavutetaan.

Nyt kysymys kuuluu, saammeko käytännössä odotetun nopeuden?

Kuva 8: Pakatun ja pakkaamattoman käsittelyn oppimiskäyrien vertailu optimoitu asetus. Kuvat tekijältä.

 

Kyllä, me teemme! Saimme lisänopeutta, koska pakkaamme tiedonsiirron.

Yhteenveto

 
 
Lauseiden yhdistäminen voi säästää laskentatyötä ja ympäristöä. Tämä tekniikka voidaan toteuttaa missä tahansa kehyksessä, mukaan lukien PyTorch ja TensorFlow. Saimme selkeän kaksinkertaisen nopeuden ja samalla laajensimme pakkausalgoritmien huippua.

Muita kiinnostavia sovelluksia ovat genomiikka ja proteiinien laskostaminen, joissa voidaan havaita samanlaisia ​​datajakaumia. Näkömuuntajat voisivat myös olla mielenkiintoinen alue erikokoisten pakattujen kuvien levittämiseen. Mitkä sovellukset toimisivat mielestäsi hyvin? Haluaisimme kuulla sinusta!

Lue paperi

Käytä koodia GitHubissa

Kiitos

 
 
Kiitos kollegoillemme Graphcoren sovellusten suunnittelutiimistä Sheng Fu ja Mrinal Iyer heidän panoksestaan ​​tähän työhön ja kiitos Douglas Orrille Graphcoren tutkimustiimistä hänen arvokkaasta palautteestaan.

Viitteet

 
 
[1] M. Kosec, S. Fu, MM Krell, Pakkaus: Kohti 2x NLP BERT -kiihdytystä (2021), arXiv

 
Tri Mario Michael Krell on Graphcoren koneoppimisen pääjohtaja. Mario on tutkinut ja kehittänyt koneoppimisalgoritmeja yli 12 vuoden ajan ja luonut ohjelmistoja niinkin erilaisille toimialoille kuin robotiikka, autoteollisuus, tietoliikenne ja terveydenhuolto. Graphcorella hän vaikutti vaikuttamiseen MLPerf-lähetykset ja hänellä on intohimo nopeuttaa uusia ei-standardimalleja, kuten likimääräistä Bayesin laskentaa tilastollista COVID-19-dataanalyysiä varten.

Matej Kosec on tekoälysovellusten asiantuntija Graphcorella Palo Altossa. Hän on aiemmin työskennellyt tekoälytutkijana autonomisen ajamisen parissa NIO:ssa San Josessa, ja hänellä on maisterin tutkinto ilmailusta ja astronautiikasta Stanfordin yliopistosta.

Alkuperäinen. Postitettu luvalla.

Related:

• Tietokaavion luominen työnhakua varten BERT: n avulla
• BERT -mallin kouluttaminen tyhjästä
• Ymmärtäminen BERT halaavilla kasvoilla