Jak Amazon Search M5 zaoszczędził 30% na kosztach szkolenia LLM, korzystając z AWS Trainium | Usługi internetowe Amazona

Od dziesięcioleci Amazon jest pionierem i wprowadza innowacje w zakresie uczenia maszynowego (ML), zapewniając swoim klientom wspaniałe doświadczenia. Od samego początku Amazon wykorzystywał ML do różnych zastosowań, takich jak rekomendowanie książek, wyszukiwanie i wykrywanie oszustw. Podobnie jak w pozostałej części branży, postęp w zakresie przyspieszonego sprzętu umożliwił zespołom Amazon tworzenie architektur modelowych z wykorzystaniem sieci neuronowych i głębokiego uczenia się (DL).

Program M5 w ramach Amazon Search jest właścicielem strategii uczenia się poprzez odkrywanie dla Amazon i buduje wielkoskalowe modele w oparciu o rozwiązania wielojęzyczne, wielolokalne, wielopodmiotowe, wielozadaniowe i wielomodalne, takie jak tekst, obraz i wideo. Program M5 zapewnia uniwersalne osadzanie i wielkoskalowe modele fundamentów setkom zespołów ML w całej firmie Amazon, przy jednoczesnym zachowaniu ścisłej kontroli optymalizacji kosztów. Aby to osiągnąć, zespół M5 regularnie ocenia nowe techniki w celu zmniejszenia kosztów.

Podobnie jak wiele organizacji ML, akceleratory są w dużej mierze wykorzystywane do przyspieszania szkolenia i wnioskowania DL. Kiedy AWS uruchomił specjalnie zaprojektowane akceleratory wraz z pierwszą wersją Inferencja AWS w 2020 roku zespół M5 szybko zaczął wykorzystać je do efektywniejszego wdrażania obciążeń produkcyjnych, oszczędzając zarówno koszty, jak i zmniejszając opóźnienia. W zeszłym roku AWS uruchomił swoją platformę Szkolenie AWS akceleratory, które optymalizują wydajność w stosunku do kosztu na potrzeby opracowywania i budowania modeli DL nowej generacji. W tym poście omawiamy, w jaki sposób firmie M5 udało się obniżyć koszty uczenia swoich modeli o 30%, i dzielimy się najlepszymi praktykami, których nauczyliśmy się po drodze.

Instancje Trainium

Wraz z postępem w zakresie specjalnie zaprojektowanych akceleratorów, Amazon udostępnia także atrakcyjne akceleratory w postaci AWS Inferentia i Trainium. Jak wskazują ich nazwy, chipy te są zoptymalizowane tak, aby przekraczać potrzeby odpowiednio obciążeń wnioskowania i szkolenia. Do szkolenia na dużą skalę modeli podstawowych, które osiągają miliardy parametrów, Trainium Instancje Trn1 i Trn1n są idealnym wyborem ze względu na swoje właściwości. Instancje Trn1 są obsługiwane przez najnowocześniejsze rozwiązania NeuronCore-v2i mają dużą ilość mocy obliczeniowej i pamięci akceleratora. Instancje Trn1n można również wybrać ze względu na większą przepustowość sieci (1,600 Gb/s), dzięki czemu idealnie nadają się do wydajnego szkolenia z myślą o optymalizacji kosztów.

Aby korzystać z akceleratorów, potrzebna jest warstwa oprogramowania, która je obsługuje. Dzięki chipom Trn i Inf, SDK AWS Neuron odblokowuje specjalnie zaprojektowane akceleratory Amazon za pomocą PyTorch XLA. PyTorch XLA konwertuje tryb chętny PyTorch na implementację opartą na grafach w trybie leniwym. Wykresy te są następnie wykorzystywane i kompilowane w celu wykorzystania ich w akceleratorze. PyTorch Neuron (część pakietu Neuron SDK) umożliwia użytkownikom PyTorch trenowanie swoich modeli na Trainium NeuronCores za pomocą kilku linijek kodu.

Model i obciążenie

Zespół M5 szkoli i wdraża podstawowe modele i uniwersalne reprezentacje, aby pomóc różnym zespołom w całym Amazonie w sprawianiu radości Amazon.com klienci. Jednym z takich modeli jest model kodera tekstu, po którym następuje perceptron wielowarstwowy (MLP) z jawnymi lub ukrytymi interakcjami cech zdefiniowanymi przez architekturę sieci neuronowej z setkami milionów możliwych do wytrenowania parametrów. Ten model jest szkolony na miliardach tokenów i służy do generowania milionów osadzania w ustawieniu wnioskowania wsadowego w trybie offline. Te osady stanowią dane wejściowe dla usługi Amazon pierwszego poziomu skierowanej do klienta.

Wykorzystywana jest infrastruktura rurociągu produkcyjnego Partia AWS w strategie kolejkowania w ramach sprawiedliwego podziału, używając wielowęzłowego klastra trn1.32xlarge z obsługą EFA jako obliczeń na potrzeby uczenia modelu. Funkcjonalnie potok produkcyjny wykonuje przyrostowe szkolenie modelu, ocenę wyszkolonego modelu i wnioskowanie wsadowe w trybie offline na wyuczonym modelu, a wszystko to przy użyciu PyTorch jako podstawowej biblioteki DL.

Gole

Zachwycanie naszych klientów to najważniejsza zasada. Biorąc pod uwagę charakter rurociągu skierowany do klienta, niezwykle ważne jest, aby wszystkie umowy dotyczące poziomu usług (SLA) były dotrzymywane bez pogorszenia jakości usług. Zidentyfikowaliśmy dwa krytyczne kryteria akceptacji, aby dostosować nasz istniejący proces produkcji procesorów graficznych i przenieść go do Trainium:

• Jakość modelu – Jakość naszych modeli bezpośrednio wpływa na doświadczenie klienta. Wymagamy, aby różnica w jakości modelu pomiędzy procesorem graficznym a Trainium wynosiła mniej niż 0.1%.
• Przepustowość treningowa – Okresowo szkolimy nasze modele iteracyjnie, aby zapewnić naszym klientom najświeższe doświadczenia. Wymagamy, aby zbieżność modeli została osiągnięta w określonym czasie (np. w ciągu tygodnia), aby spełnić nasze produkcyjne umowy SLA.

W kolejnych sekcjach dzielimy się naszą podróżą wstecz, wychodząc od tych kryteriów, oraz zdobytymi doświadczeniami, jak wspierać obciążenia produkcyjne na skalę Amazona.

Skrypt szkoleniowy

Przed rozpoczęciem uczenia modelu musimy wprowadzić zmiany w skrypcie szkoleniowym, aby był zgodny z XLA. Biorąc pod uwagę rozmiar modelu, do uczenia modelu używamy równoległego przetwarzania danych rozproszonych (DDP). DDP pozwala nam zwiększyć przepustowość uczenia modeli poprzez skalowanie liczby maszyn używanych do uruchamiania uczenia modeli, bez żadnych zmian w kodzie. Postępowaliśmy zgodnie z instrukcjami zawartymi w Poradnik szkoleniowy Neuron PyTorch MLP aby dodać konstrukcje specyficzne dla XLA do naszych skryptów szkoleniowych. Te zmiany w kodzie są łatwe do wdrożenia. Poniżej przedstawiono kilka istotnych wniosków technicznych wynikających z ćwiczenia, które znacznie poprawiły wydajność naszego modelu:

• Umiejscowienie xm.mark_step() - xm.mark_step() kompiluje i uruchamia leniwie zebrane wykresy obliczeniowe. Inwokowanie mark_step zbyt wiele razy spowoduje powstanie większej liczby małych wykresów, natomiast zbyt rzadkie wywołanie spowoduje powstanie kilku, ale dużych wykresów. W zależności od aplikacji wydajność i wdrożenie szkolenia modelowego będą się różnić w zależności od umiejscowienia xm.mark_step(). Nasza implementacja umieszcza jeden xm.mark_step() po przejściu do przodu i do tyłu oraz po kroku optymalizatora.
• Zawijanie modułu ładującego dane za pomocą modułu ładującego urządzenie wieloprocesorowe XLA – To kluczowy krok, który można łatwo przeoczyć. Program ładujący urządzenia wieloprocesorowe torch_xla.distributed.parallel_loader.MpDeviceLoader ładuje dane szkoleniowe na każdym urządzeniu XLA z opcjami wstępnego ładowania i nakładania się ładowania danych z przebiegami urządzeń w celu poprawy przepustowości. Program ładujący urządzenie również wywołuje xm.mark_step() i dlatego jest w stanie budować wykresy ładowania danych do urządzenia z hosta.

Kompilacja dla Trainium

Tradycyjnie cykl opracowywania modelu z wykorzystaniem procesorów graficznych obejmuje wprowadzanie zmian w modelu lub skrypcie szkoleniowym i bezpośrednie uruchamianie go na urządzeniu GPU. Akceleratory, takie jak Trainium, które korzystają z XLA, wymagają dodatkowego kroku, zanim będzie można uruchomić szkolenie modelu w akceleratorze. Wykresy obliczeniowe XLA można uruchomić dopiero po ich skompilowaniu. Ogólnie rzecz biorąc, istnieją dwa sposoby przeprowadzenia tej kompilacji: z wyprzedzeniem (AOT), gdzie najpierw śledzi się i kompiluje wszystkie wykresy, a następnie je uruchamia, lub Just In Time (JIT), gdzie wykresy są śledzone, kompilowane i uruchamiane w miarę ich pojawiania się. spotykane. Zestaw Neuron SDK zapewnia oba rozwiązania od razu po wyjęciu z pudełka. Zwykle najpierw wykonywana jest kompilacja AOT. Wykresy są następnie uruchamiane po tej kompilacji. Jeśli zostaną napotkane nowe wykresy, środowisko wykonawcze Neuron wywołuje kompilację JIT przed ich uruchomieniem. Aby wykonać kompilację AOT, zapewnia Neuron SDK kompilacja_neurorównoległa, narzędzie do kompilacji, które wyodrębnia wykresy z próbnego uruchomienia skryptu szkoleniowego i wykonuje równoległą kompilację AOT.

Ważnym aspektem kompilacji AOT jest zapewnienie, że w trakcie szkolenia nie zostaną utworzone żadne nowe wykresy obliczeniowe. Jednym ze źródeł nowych wykresów obliczeniowych (a tym samym rekompilacji) są dynamiczne kształty partii szkoleniowych podczas uczenia modelu. Odkryliśmy, że używanie statycznych kształtów i partii o stałym rozmiarze eliminuje kompilacje czasu szkolenia i znacznie poprawia wydajność uczenia bez żadnego wpływu na dokładność modelu. Narzucając takie ograniczenia na szkoleniu, zaobserwowaliśmy, że do prześledzenia wszystkich wykresów podczas kompilacji AOT wymagane jest tylko 4–5 kroków uczenia modelu, jeden etap walidacji modelu i jednorazowe sprawdzenie modelu. Należy zauważyć, że pakiet Neuron SDK stale się rozwija i w przyszłości będzie obsługiwał także dynamiczne kształty.

Ponadto skompilowane wykresy są przechowywane w pliku Trwała pamięć podręczna neuronów na dysku lub w pliku Usługa Amazon Simple Storage Łyżka (Amazon S3). Jest to szczególnie przydatne w przypadku obciążeń produkcyjnych, w których architektura modelu i konfiguracja szkoleniowa nie ulegają zmianie. Dlatego też narzut związany z kompilacją jest ponoszony tylko raz. Korzystanie z pamięci podręcznej jest tak proste, jak ustawienie flagi środowiska:

export NEURON_COMPILE_CACHE_URL="s3://BUCKET/KEY"

Kompilator Neuron zapewnia również trzy opcje optymalizacji na poziomie kompilatora (O1, O2, O3), aby zrównoważyć czas kompilacji i przepustowość przebiegu modelu. O1 umożliwia podstawowe optymalizacje na wykresie obliczeniowym i minimalizuje czas kompilacji, O3 zapewnia lepszą przepustowość przebiegu modelu kosztem dłuższego czasu kompilacji, a O2 (opcja domyślna) stanowi równowagę między nimi. W naszym przypadku zastosowaliśmy optymalizację O1 i zaobserwowaliśmy 86% skrócenie czasu kompilacji bez zmian w metrykach dokładności modelu, jednocześnie obserwując około 5–7% zmniejszenie przepustowości w porównaniu z domyślną optymalizacją (O2). W zależności od przypadku użycia możesz wybrać różne poziomy optymalizacji.

Podsumowując, do kompilacji użyliśmy następujących flag:

NEURON_CC_FLAGS="--target trn1 --auto-cast all --auto-cast-type bf16 --model-type transformer --optlevel O1"

Zgodność punktu kontrolnego

Po pomyślnym zakończeniu kompilacji możemy przystąpić do uczenia naszych modeli w Trainium. Jak wspomniano wcześniej, nasze modele trenujemy przyrostowo, co oznacza, że ​​ładujemy wcześniej przeszkolony punkt kontrolny modelu i kontynuujemy szkolenie z nowymi danymi. PyTorch i PyTorch XLA umożliwiają płynne przełączanie między akceleratorami dzięki interoperacyjności punktów kontrolnych. Elastyczność przełączania między procesorem graficznym a Trainium umożliwiła nam bezproblemowe ładowanie poprzedniego modelu procesora graficznego i trenowanie na maszynach Trainium. Miało to kluczowe znaczenie, abyśmy mogli zainicjować nasz model przy użyciu najlepszego, wcześniej wyszkolonego modelu, bez przestojów w produkcji lub utraty dokładności modelu.

Ponieważ model GPU został zapisany przy użyciu standardowych narzędzi do zapisywania modeli PyTorch, mogliśmy użyć narzędzia do ładowania punktu kontrolnego PyTorch w celu załadowania modelu GPU na urządzenia Trainium.

Na przykład na GPU/CPU możesz zapisać model za pomocą następującego kodu:

torch.save(model.state_dict(), PATH)

Następnie ładujesz model z powrotem do Trainium:

import torch_xla.core.xla_model as xm
xla_device = xm.xla_device()
model = MyModel(*args, **kwargs)
model.load_state_dict(torch.load(PATH))
model.to(xla_device)

Podobnie możesz zapisać model w Trainium za pomocą następującego kodu:

import torch_xla.core.xla_model as xm
# automatically moves the data to CPU for the master device
xm.save(model.state_dict(), PATH) 

I załaduj model ponownie na GPU/CPU:

model = MyModel(*args, **kwargs)
model.load_state_dict(torch.load(PATH))
model.to(device) # can be any device

W rzeczywistości, ponieważ używamy DDP do uczenia modeli, ładowanie modelu jest niezależne od liczby maszyn używanych do uczenia poprzedniego punktu kontrolnego. Pozwala nam to poziomo skalować flotę Trn1 bez zmian w kodzie i niekorzystnych skutków dla szkolenia modeli. Tych punktów kontrolnych opartych na PyTorch można używać bezpośrednio lub nawet za pomocą skryptu latarki do przypadków użycia wnioskowania w AWS Inferentia2 lub innych akceleratorach.

Stabilność operacyjna

Nie można wystarczająco podkreślić, że uruchamianie obciążeń w środowisku produkcyjnym wymaga spełnienia wielu umów SLA. W naszym przypadku użycia, poza umowami SLA dotyczącymi jakości modelu i przepustowości szkolenia, konieczne jest, aby rurociąg produkcyjny był stabilny operacyjnie, co oznacza minimalne przestoje i zakłócenia podczas uczenia, oceny i wnioskowania modelu.

Podobnie jak w przypadku istniejącego potoku opartego na GPU, dodaliśmy wiele mechanizmów, aby potok działał stabilnie. Przed rozpoczęciem uczenia modeli przeprowadzamy wiele testów poprawności, aby ocenić stan maszyn. Testy te zazwyczaj obejmują proste operacje na tensorach w celu sprawdzenia stanu urządzeń akceleracyjnych. Zaobserwowaliśmy, że w przypadku szkoleń rozproszonych ważne jest uruchamianie testów w celu sprawdzenia również zbiorowej komunikacji między instancjami. Korzystaliśmy z Zestaw testów NCCOM z pakietu Neuron SDK, aby to osiągnąć, uruchamiając różne operacje, takie jak zbieranie wszystkiego, redukcja wszystkich i redukcja rozproszenia.

Nawet po zastosowaniu się do sugestii, o których wspomnieliśmy, zaobserwowaliśmy, że przejściowe problemy są nieuniknione w każdym potoku, niezależnie od podstawowego akceleratora. Aby zbudować odporność w dowolnym procesie szkoleniowym, zalecamy wbudowanie mechanizmów ponawiania prób w celu rozwiązania potencjalnych problemów. Używamy Automatyczne ponowne próby AWS Batch aby ponowić próbę zadań, które napotkały przejściową awarię podczas uczenia modelu. Te ponowne uruchomienia mogą być kosztowne, jeśli pod koniec szkolenia wystąpi awaria. Aby przeciwdziałać temu problemowi, dostosowaliśmy nasze skrypty szkoleniowe tak, aby ładowały wcześniej przeszkolony punkt kontrolny modelu i kontynuowały szkolenie od tego punktu. Dzięki tej funkcjonalności jesteśmy w stanie agresywnie ponownie uruchamiać nieudane zadania szkoleniowe przy minimalnych kosztach ogólnych.

Dzięki tym mechanizmom odporności udało nam się osiągnąć 98.5% współczynnika powodzenia dla naszych obciążeń na Trn1, co jest porównywalne z naszymi obecnymi wskaźnikami powodzenia potoków GPU.

Efekt

Aby zweryfikować dokładność naszych modeli, zainicjowaliśmy dwa modele z tego samego punktu kontrolnego GPU i trenowaliśmy jeden na Trainium, a drugi na porównywalnym GPU. Obydwa modele trenowano przy użyciu tych samych hiperparametrów treningowych. Zbiór danych używany do obliczania metryk jest zbiorem danych wstrzymanym i oceniamy dokładność modelu na tym zbiorze danych co N globalnych kroków. Oś X to krok globalny, a oś Y to dokładność modelu. Zaobserwowaliśmy mniej niż 0.1% różnicy w dokładności modelu w każdym punkcie poniższego wykresu.

Ponadto, aby ocenić opłacalność uczenia modelu, wolimy porównać czas zegara ściennego potrzebny do osiągnięcia zbieżności modelu. Wierzymy, że zapewnia to bardziej praktyczny pogląd na oszczędności w porównaniu do miar takich jak koszt na token, osiągnięte FLOPS/dolar i inne czynniki. Biorąc pod uwagę czas szkolenia trn1.32xl i porównywalny Elastyczna chmura obliczeniowa Amazon (Amazon EC2) zaobserwowaliśmy, że Trainium oferuje do 30% niższy koszt konwergencji modelu.

Wnioski

Oceniając różne akceleratory dla obciążeń DL, należy wziąć pod uwagę wiele czynników. Do najważniejszych należą: jakość modelu, przepustowość, koszt i dostępność. Niezwykle istotne jest, aby jakość i przepustowość modelu nie uległy pogorszeniu w zależności od wybranego akceleratora.

Dzięki naszemu partnerstwu i współpracy z zespołem Annapurna Neuron zespół Amazon Search M5 mógł zaoszczędzić nawet 30% kosztów, przechodząc na Trainium. Zespół jest w stanie wykorzystać Trainium i osiągnąć jakość modelu oraz przepustowość z porównywalnymi akceleratorami dostępnymi na rynku. Interoperacyjność punktów kontrolnych i minimalne zmiany w kodzie przy obsłudze XLA umożliwiły M5 wybór pomiędzy wieloma akceleratorami dostosowanymi do ich obciążeń. Umożliwiło to zespołowi M5 wykorzystanie dużej mocy obliczeniowej Trainium i tworzenie rozwiązań niezależnych od akceleratorów, aby zachwycić klientów Amazon.com. Z operacyjnego punktu widzenia Trainium udowodniło, że jest w stanie wspierać usługi poziomu 1 w skali Amazon. Zespół M5 w dalszym ciągu przenosi więcej zadań do Trainium, aby zapewnić Amazonowi najlepsze modele przy najniższych kosztach.

Podsumowując, zespół M5 był w stanie przeprowadzić opłacalne szkolenie ML na poziomie produkcyjnym, dodając Trainium do floty akceleratorów. Zachęcamy do zapoznania się z Trainium i innymi urządzeniami Neuron, takimi jak AWS Inferentia, aby czerpać korzyści ze specjalnie zaprojektowanego krzemu Amazon do obciążeń ML. Rozpocznij łatwo, korzystając z jednego z wielu samouczków przedstawiających różne modele, np Lama 2, dostępna na Trainium.

O autorach

Abhinandana Patniego jest starszym inżynierem oprogramowania w Amazon Search. Koncentruje się na budowaniu systemów i narzędzi do skalowalnego rozproszonego szkolenia głębokiego uczenia i wnioskowania w czasie rzeczywistym.

James Park jest architektem rozwiązań w Amazon Web Services. Współpracuje z Amazon.com przy projektowaniu, budowaniu i wdrażaniu rozwiązań technologicznych w AWS, a szczególnie interesuje się sztuczną inteligencją i uczeniem maszynowym. W wolnym czasie lubi szukać nowych kultur, nowych doświadczeń i być na bieżąco z najnowszymi trendami technologicznymi. Znajdziesz go na LinkedIn.

Jerry'ego Mannila jest inżynierem oprogramowania w Amazon Search. Pracuje nad poprawą wydajności, solidności i skalowalności rozproszonej infrastruktury szkoleniowej.

Ken Su jest inżynierem oprogramowania w Amazon Search. Pracuje nad poprawą efektywności szkoleń i skalowalnym rozproszonym przepływem szkoleń. Poza pracą lubi piesze wędrówki i tenis.

RJ jest inżynierem w firmie Amazon. Buduje i optymalizuje systemy dla systemów rozproszonych do celów szkoleniowych oraz pracuje nad optymalizacją adaptacji systemów w celu zmniejszenia opóźnień w przypadku wnioskowania ML. Poza pracą bada wykorzystanie generatywnej sztucznej inteligencji do tworzenia przepisów kulinarnych.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/machine-learning/how-amazon-search-m5-saved-30-for-llm-training-cost-by-using-aws-trainium/