Przedstawiamy pakiety BERT dla 2-krotnego przyspieszenia treningu w przetwarzaniu języka naturalnego

Węzeł źródłowy: 1062065

Przedstawiamy pakiety BERT dla 2-krotnego przyspieszenia treningu w przetwarzaniu języka naturalnego

Sprawdź ten nowy algorytm pakowania BERT, aby uzyskać bardziej efektywne szkolenie.


By dr Mario Michael Krell, główny lider ds. uczenia maszynowego w Graphcore & Matej Kosek, Specjalista ds. aplikacji AI w Graphcore


obraz nagłówka
Zdjęcie autora.

 

Używając nowego algorytmu pakowania, przyspieszyliśmy przetwarzanie języka naturalnego ponad 2-krotnie podczas szkolenia BERT-Large. Nasza nowa technika pakowania eliminuje dopełnienie, umożliwiając znacznie wydajniejsze obliczenia.

Podejrzewamy, że można to również zastosować do modeli genomiki i fałdowania białek oraz innych modeli o skośnym rozkładzie długości, aby wywrzeć znacznie szerszy wpływ na różne branże i zastosowania.

W nowej pracy wprowadziliśmy wysoce wydajny algorytm pakowania histogramu metodą nieujemnych najmniejszych kwadratów (ang. Non-Negative Least Squares Histogram-Packing) firmy Graphcore (lub NNLSHP), a także nasz algorytm BERT zastosowany do upakowanych sekwencji [1].

Straty obliczeniowe w NLP z powodu wypełniania sekwencji

 
 
Zaczęliśmy badać nowe sposoby optymalizacji szkoleń BERT podczas pracy nad naszym ostatnim przesyłanie testów porównawczych do MLPerf™. Celem było opracowanie użytecznych optymalizacji, które można by łatwo zastosować w rzeczywistych zastosowaniach. BERT był naturalnym wyborem jako jeden z modeli, na których należy się skoncentrować w przypadku tych optymalizacji, ponieważ jest szeroko stosowany w przemyśle i przez wielu naszych klientów.

Naprawdę zaskoczyło nas, gdy dowiedzieliśmy się, że w naszej własnej aplikacji szkoleniowej BERT-Large korzystającej z zestawu danych Wikipedii 50% tokenów w zbiorze danych było wypełnianych — co skutkowało dużą ilością zmarnowanych zasobów obliczeniowych.

Sekwencje dopełniania w celu wyrównania ich wszystkich do równej długości to powszechne podejście stosowane w przypadku procesorów graficznych, ale pomyśleliśmy, że warto spróbować innego podejścia.

Sekwencje mają dużą zmienność długości z dwóch powodów:

  1. Bazowe dane Wikipedii pokazują duże różnice w długości dokumentu
  2. Samo wstępne przetwarzanie BERT losowo zmniejsza rozmiar wyodrębnionych dokumentów, które są łączone w celu wygenerowania sekwencji szkoleniowej

Wypełnienie długości do maksymalnej długości 512 powoduje, że 50% wszystkich tokenów to tokeny wypełniające. Zastąpienie 50% dopełnienia rzeczywistymi danymi może skutkować przetwarzaniem o 50% więcej danych przy takim samym wysiłku obliczeniowym, a tym samym 2-krotnym przyspieszeniem w optymalnych warunkach.



Rysunek 1: Dystrybucja zbiorów danych Wikipedii. Obraz autorstwa autora.

 

Czy dotyczy to Wikipedii? NIE.

Cóż, w takim razie jest to specyficzne dla języka? NIE.

W rzeczywistości skośne rozkłady długości można znaleźć wszędzie: w języku, genomice i fałdowaniu białek. Ryciny 2 i 3 przedstawiają rozkłady dla zestawu danych SQuAD 1.1 i zestawów danych GLUE.



Rysunek 2: Histogram długości sekwencji zestawu danych przed treningiem SQuAD 1.1 BERT dla maksymalnej długości sekwencji 384. Zdjęcie autorstwa autora.

 


Rysunek 3: Histogramy długości sekwencji zestawu danych GLUE dla maksymalnej długości sekwencji 128. Zdjęcie autorstwa autora.

 

Jak możemy poradzić sobie z różnymi długościami, unikając marnotrawstwa obliczeniowego?

Obecne podejścia wymagają różnych jąder obliczeniowych dla różnych długości lub inżyniera, aby programowo usuwał dopełnienie, a następnie wielokrotnie je dodawał dla każdego bloku uwagi i obliczania strat. Oszczędzanie mocy obliczeniowej poprzez rozbudowę kodu i uczynienie go bardziej złożonym nie było atrakcyjne, więc szukaliśmy czegoś lepszego. Czy nie możemy po prostu połączyć wielu sekwencji w paczkę o maksymalnej długości i przetworzyć to wszystko razem? Okazuje się, że możemy!

Takie podejście wymaga trzech kluczowych składników:

  1. Wydajny algorytm do decydowania, które próbki połączyć, aby pozostało jak najmniej wypełnienia
  2. Dostosowanie modelu BERT do przetwarzania paczek zamiast sekwencji
  3. I dostosowanie hiperparametrów

Uszczelka

 
 
Na początku wydawało się mało prawdopodobne, że będziesz w stanie bardzo wydajnie spakować duży zbiór danych, taki jak Wikipedia. Ten problem jest powszechnie znany jako bin-packing. Nawet jeśli upakowanie jest ograniczone do trzech sekwencji lub mniej, wynikowy problem byłby nadal silnie NP-zupełny, pozbawiony wydajnego rozwiązania algorytmicznego. Istniejące algorytmy pakowania heurystycznego nie były obiecujące, ponieważ miały złożoność co najmniej O(n dziennik(n)), Gdzie n to liczba sekwencji (~16 mln dla Wikipedii). Interesowały nas podejścia, które dobrze skalowałyby się do milionów sekwencji.

Dwie sztuczki pomogły nam drastycznie zmniejszyć złożoność:

  1. Ograniczenie liczby sekwencji w paczce do trzech (dla naszego pierwszego rozwiązania)
  2. Operowanie wyłącznie na histogramie długości sekwencji z jednym przedziałem dla każdej występującej długości

Nasza maksymalna długość sekwencji wynosiła 512. Tak więc przejście do histogramu zmniejszyło wymiar i złożoność z 16 milionów sekwencji do 512 zliczeń długości. Zezwolenie na maksymalnie trzy sekwencje w paczce zmniejszyło liczbę dozwolonych kombinacji długości do 22 4. Zawierało to już sztuczkę polegającą na wymaganiu sortowania sekwencji według długości w paczce. Dlaczego więc nie spróbować 22 sekwencji? Zwiększyło to liczbę kombinacji z 940 3 do XNUMX XNUMX, co było zbyt dużą liczbą w przypadku naszego pierwszego podejścia do modelowania. Dodatkowo głębokość XNUMX osiągnęła już niezwykle wysoką wydajność pakowania.

Początkowo myśleliśmy, że użycie więcej niż trzech sekwencji w paczce zwiększy obciążenie obliczeniowe i wpłynie na zachowanie konwergencji podczas treningu. Jednak w celu obsługi aplikacji, takich jak wnioskowanie, które wymagają jeszcze szybszego pakowania w czasie rzeczywistym, opracowaliśmy wysoce wydajny algorytm Non-Negative Least Squares Histogram-Packing (NNLSHP).

Nieujemne pakowanie histogramu metodą najmniejszych kwadratów (NNLSHP)

 
 
Pakowanie pojemników jest dość często formułowane jako problem optymalizacji matematycznej. Jednak przy 16 milionach sekwencji (lub więcej) nie jest to praktyczne. Same zmienne problemowe przekraczałyby pamięć większości maszyn. Program matematyczny dla podejścia opartego na histogramie jest całkiem zgrabny. Dla uproszczenia zdecydowaliśmy się na metodę najmniejszych kwadratów (topór=b) z wektorem histogramu b. Rozszerzyliśmy go, prosząc o wektor strategii x być nieujemne i dodawać wagi, aby umożliwić niewielkie wypełnienie.

Trudną częścią była macierz strategii. Każda kolumna ma maksymalną sumę trzech i koduje, które sekwencje są pakowane razem, aby dokładnie odpowiadały pożądanej całkowitej długości; W naszym przypadku 512. Wiersze kodują każdą z potencjalnych kombinacji, aby osiągnąć długość całkowitą. Wektor strategii x jest tym, czego szukaliśmy, co opisuje, jak często wybieramy dowolną z 20 600 kombinacji. Co ciekawe, na koniec wybrano tylko około XNUMX kombinacji. Aby uzyskać dokładne rozwiązanie, liczy się strategia x musiałyby być dodatnimi liczbami całkowitymi, ale zdaliśmy sobie sprawę, że przybliżone zaokrąglone rozwiązanie z liczbą nieujemną x było wystarczające. Aby uzyskać przybliżone rozwiązanie, można użyć prostego, gotowego rozwiązania, aby uzyskać wynik w ciągu 30 sekund.



Rysunek 4: Przykład macierzy strategii dla długości sekwencji 8 i głębokości upakowania 3. Wiersze oznaczają sekwencje o długości 1–8, które są spakowane razem, a kolumny oznaczają wszystkie możliwe kombinacje długości w paczce bez określonej kolejności. Obraz autorstwa autora.

 

Na koniec musieliśmy naprawić kilka próbek, którym nie przypisano strategii, ale były one minimalne. Opracowaliśmy również wariant solwera, który wymusza, aby każda sekwencja była spakowana, potencjalnie z dopełnieniem, i ma wagę zależną od dopełnienia. Trwało to znacznie dłużej, a rozwiązanie nie było dużo lepsze.

Pakowanie histogramu w najkrótszym pakiecie

 
 
Firma NNLSHP zapewniła nam wystarczające podejście do pakowania. Zastanawialiśmy się jednak, czy teoretycznie moglibyśmy uzyskać szybsze podejście online i usunąć ograniczenie polegające na połączeniu tylko 3 sekwencji.

Dlatego zainspirowaliśmy się istniejącymi algorytmami pakowania, ale nadal skupiliśmy się na histogramach.

Istnieją cztery składniki naszego pierwszego algorytmu, najkrótsza paczka-pierwsze histogram-pakowanie (SPFHP):

  1. Działaj na liczbach histogramu od najdłuższych sekwencji do najkrótszych
  2. Jeśli bieżąca długość sekwencji nie pasuje do żadnej paczki, rozpocznij nowy zestaw paczek
  3. Jeśli istnieje wiele dopasowań, weź pakiet, w którym suma długości sekwencji jest najkrótsza i odpowiednio zmodyfikuj liczby
  4. Sprawdź ponownie, czy pasuje do pozostałych zliczeń

To podejście było najłatwiejsze do wdrożenia i zajęło tylko 0.02 sekundy.

Wariantem było wzięcie największej sumy długości sekwencji zamiast najkrótszej i podzielonej liczby, aby uzyskać bardziej idealne dopasowanie. Ogólnie rzecz biorąc, nie zmieniło to zbytnio wydajności, ale znacznie zwiększyło złożoność kodu.



Jak działa pakowanie histogramu z najkrótszą paczką. Animacja autorstwa autora.

 

Wikipedia, SQuAD 1.1, wyniki pakowania GLUE

 
 
Tabele 1, 2 i 3 przedstawiają wyniki upakowania naszych dwóch proponowanych algorytmów. Głębokość pakowania opisuje maksymalną liczbę spakowanych sekwencji. Głębokość pakowania 1 to podstawowa implementacja BERT. Maksymalna występująca głębokość upakowania, gdy nie jest ustawiony limit, oznaczana jest dodatkowym „max”. The liczba paczek opisuje długość nowego spakowanego zestawu danych. Wydajność jest procentem rzeczywistych tokenów w spakowanym zbiorze danych. The współczynnik pakowania opisuje wynikające z tego potencjalne przyspieszenie w porównaniu z głębokością upakowania 1.

Mieliśmy cztery główne uwagi:

  1. Im bardziej skośny rozkład, tym większe korzyści z pakowania.
  2. Pakowanie przynosi korzyści wszystkim zestawom danych. Niektóre nawet ponad dwukrotnie.
  3. SPFHP staje się bardziej wydajny, gdy głębokość upakowania nie jest ograniczona.
  4. Dla maksymalnej liczby 3 upakowanych sekwencji, im bardziej złożony jest NNLSHP, tym jest bardziej wydajny (99.75 vs. 89.44).



Tabela 1: Kluczowe wyniki wydajności proponowanych algorytmów pakowania (SPFHP i NNLSHP) w Wikipedii. Obraz autorstwa autora.

 


Tabela 2: Wyniki działania proponowanych algorytmów pakowania dla szkolenia wstępnego SQUAD 1.1 BERT. Obraz autorstwa autora.

 


Tabela 3: Wyniki wydajności proponowanych algorytmów upakowania dla zbioru danych GLUE. Wyświetlana jest tylko linia bazowa i wyniki upakowania SPFHP bez ograniczania głębokości upakowania. Obraz autorstwa autora.

 

Korekta przetwarzania BERT

 
 
Interesujące w architekturze BERT jest to, że większość przetwarzania odbywa się na poziomie tokena, co oznacza, że ​​nie koliduje to z naszym pakowaniem. Istnieją tylko cztery elementy, które wymagają korekty: maska ​​uwagi, strata MLM, strata NSP i dokładność.

Kluczem dla wszystkich czterech podejść do obsługi różnych liczb sekwencji była wektoryzacja i użycie maksymalnej liczby sekwencji, które można połączyć. Aby zwrócić na siebie uwagę, mieliśmy już maskę do wypełnienia. Rozszerzenie tego na wiele sekwencji było proste, jak widać w poniższym pseudo kodzie TensorFlow. Koncepcja polega na tym, że upewniliśmy się, że uwaga jest ograniczona do oddzielnych sekwencji i nie może wykraczać poza to.

Przykładowy kod maski uwagi.


 


Rysunek 5: Przykładowa maska ​​zero-jedynkowa

 

W celu obliczenia strat zasadniczo rozpakowujemy sekwencje i obliczamy oddzielne straty, ostatecznie uzyskując średnią strat w sekwencjach (zamiast paczek).

W przypadku utraty MLM kod wygląda następująco:

Przykład kodu obliczania strat.


 

W przypadku strat NSP i dokładności zasada jest taka sama. W naszych publicznych przykładach możesz znaleźć odpowiedni kod w naszej firmie ramy PopART.

Oszacowanie kosztów i przyspieszenia Wikipedii

 
 
Wraz z naszą modyfikacją BERT, mieliśmy dwa pytania:

  1. Ile narzutów to ze sobą niesie?
  2. Ile narzutów zależy od maksymalnej liczby sekwencji, które są łączone w paczkę?

Ponieważ przygotowanie danych w BERT może być uciążliwe, użyliśmy skrótu i ​​skompilowaliśmy kod dla wielu różnych głębokości upakowania i porównaliśmy odpowiednie (zmierzone) cykle. Wyniki przedstawiono w Tabeli 4. Z nad głową, oznaczamy procentowy spadek przepustowości ze względu na zmiany w modelu umożliwiające pakowanie (takie jak schemat maskowania uwagi i zmieniona kalkulacja strat). The zrealizowane przyspieszenie jest kombinacją przyspieszenia spowodowanego pakowaniem (tzw współczynnik pakowania) oraz spadek przepustowości z powodu nad głową.



Tabela 4: Szacowane przyspieszenie porównania proponowanych algorytmów pakowania (SPFHP i NNLSHP) w Wikipedii. Obraz autorstwa autora.

 

Dzięki technice wektoryzacji narzut jest zaskakująco mały i nie ma wad związanych z pakowaniem wielu sekwencji razem.

Korekty hiperparametrów

 
 
Dzięki pakowaniu podwajamy efektywną wielkość partii (średnio). Oznacza to, że musimy dostosować hiperparametry treningu. Prostą sztuczką jest zmniejszenie liczby akumulacji gradientu o połowę, aby zachować taką samą efektywną średnią wielkość partii, jak przed treningiem. Używając ustawienia wzorcowego ze wstępnie wytrenowanymi punktami kontrolnymi, możemy zobaczyć, że krzywe dokładności idealnie do siebie pasują.



Rysunek 6: Porównanie krzywych uczenia się dla przetwarzania z pakietem i bez pakietu zmniejszona wielkość partii za pełne podejście. Obrazy autorstwa autora.

 

Dokładność pasuje: strata treningowa MLM może być na początku nieco inna, ale szybko nadrabia zaległości. Ta początkowa różnica mogła wynikać z niewielkich dostosowań warstw uwagi, które mogły być nastawione na krótkie sekwencje w poprzednim treningu.

Aby uniknąć spowolnienia, czasem pomaga utrzymanie pierwotnej wielkości partii i dostosowanie hiperparametrów do zwiększonej efektywnej wielkości partii (podwojona). Głównymi hiperparametrami, które należy wziąć pod uwagę, są parametry beta i współczynniki uczenia. Jednym z powszechnych podejść jest podwojenie wielkości partii, co w naszym przypadku obniżyło wydajność. Patrząc na statystyki optymalizatora LAMB, możemy udowodnić, że podniesienie parametru beta do potęgi współczynnika upakowania odpowiada trenowaniu wielu partii kolejno, aby zachować porównywalność pędu i prędkości.



Rysunek 7: Porównanie krzywych uczenia się dla przetwarzania z pakietem i bez pakietu heurystyka stosowany. Obrazy autorstwa autora.

 

Nasze eksperymenty pokazały, że podniesienie beta do potęgi dwóch jest dobrą heurystyką. W tym scenariuszu nie oczekuje się dopasowania krzywych, ponieważ zwiększenie wielkości partii zwykle zmniejsza szybkość konwergencji w sensie próbek/epok, aż do osiągnięcia docelowej dokładności.

Teraz pytanie brzmi, czy w praktycznym scenariuszu naprawdę uzyskamy oczekiwane przyspieszenie?



Rysunek 8: Porównanie krzywych uczenia się dla przetwarzania z pakietem i bez pakietu w zoptymalizowana konfiguracja. Obrazy autorstwa autora.

 

Tak! Zyskaliśmy dodatkowe przyspieszenie, ponieważ skompresowaliśmy transfer danych.

Wnioski

 
 
Pakowanie zdań razem może zaoszczędzić nakład pracy obliczeniowej i środowisko. Tę technikę można zaimplementować w dowolnym frameworku, w tym w PyTorch i TensorFlow. Uzyskaliśmy wyraźne 2x przyspieszenie, a przy okazji rozszerzyliśmy najnowocześniejsze algorytmy pakowania.

Inne zastosowania, które nas interesują, to genomika i fałdowanie białek, w których można zaobserwować podobne rozkłady danych. Transformatory wizyjne mogą być również interesującym obszarem do zastosowania spakowanych obrazów o różnych rozmiarach. Jak myślisz, które aplikacje będą dobrze działać? Chcielibyśmy usłyszeć od ciebie!

Przeczytaj artykuł

Uzyskaj dostęp do kodu na GitHub

Dziękuję Ci

 
 
Dziękujemy naszym kolegom z zespołu Graphcore Applications Engineering, Sheng Fu i Mrinalowi Iyerowi, za ich wkład w tę pracę, a także Douglasowi Orrowi z zespołu badawczego Graphcore za jego cenne uwagi.

Referencje

 
 
[1] M. Kosec, S. Fu, MM Krell, Pakowanie: w kierunku przyspieszenia 2x NLP BERT (2021), arXiv

 
dr Mario Michael Krell jest głównym kierownikiem ds. uczenia maszynowego w Graphcore. Mario od ponad 12 lat bada i rozwija algorytmy uczenia maszynowego, tworząc oprogramowanie dla tak różnych branż, jak robotyka, motoryzacja, telekomunikacja i opieka zdrowotna. W Graphcore przyczynił się do naszego imponującego wyniku Zgłoszenia MLPerf i ma pasję do przyspieszania nowatorskich niestandardowych modeli, takich jak przybliżone obliczenia bayesowskie do statystycznej analizy danych COVID-19.

Matej Kosek jest specjalistą ds. aplikacji AI w Graphcore w Palo Alto. Wcześniej pracował jako naukowiec AI nad autonomiczną jazdą w NIO w San Jose i posiada tytuł magistra aeronautyki i astronautyki na Uniwersytecie Stanforda.

Oryginalny. Przesłane za zgodą.

Związane z:

Źródło: https://www.kdnuggets.com/2021/08/packed-bert-training-speed-up-natural-language-processing.html

Znak czasu:

Więcej z Knuggety