ByteDance oszczędza do 60% na kosztach wnioskowania, jednocześnie zmniejszając opóźnienia i zwiększając przepustowość dzięki AWS Inferentia

To jest gościnny wpis na blogu napisany wspólnie z Minghui Yu i Jianzhe Xiao z Bytedance.

ByteDance to firma technologiczna, która obsługuje szereg platform z treściami w celu informowania, edukowania, rozrywki i inspirowania ludzi w różnych językach, kulturach i regionach geograficznych. Użytkownicy ufają naszym platformom treści i cieszą się nimi ze względu na bogate, intuicyjne i bezpieczne doświadczenia, które zapewniają. Te doświadczenia są możliwe dzięki naszemu silnikowi zaplecza uczenia maszynowego (ML), z modelami ML stworzonymi do moderowania treści, wyszukiwania, rekomendacji, reklam i nowatorskich efektów wizualnych.

Zespół ByteDance AML (Applied Machine Learning) zapewnia wysoce wydajne, niezawodne i skalowalne systemy ML oraz kompleksowe usługi ML dla biznesu firmy. Badaliśmy sposoby optymalizacji naszych systemów wnioskowania ML w celu obniżenia kosztów bez wydłużania czasu reakcji. Kiedy uruchomiono AWS Inferencja AWS, wysokowydajny układ wnioskowania ML stworzony specjalnie przez AWS, nawiązaliśmy współpracę z naszym zespołem ds. kont AWS, aby sprawdzić, czy AWS Inferentia może osiągnąć nasze cele optymalizacyjne. Przeprowadziliśmy kilka weryfikacji koncepcji, co zaowocowało nawet o 60% niższym kosztem wnioskowania w porównaniu z instancjami EC4 G2dn opartymi na GPU T4 i nawet o 25% mniejszymi opóźnieniami wnioskowania. Aby zrealizować te oszczędności i ulepszenia wydajności, zdecydowaliśmy się wdrożyć modele oparte na AWS Inferentia Elastyczna chmura obliczeniowa Amazon (Amazon EC2) Instancje Inf1 w produkcji.

Poniższy wykres pokazuje poprawę opóźnienia dla jednego z naszych modeli wykrywania twarzy, który był wcześniej wdrożony na GPU z Tensor RT. Średnie opóźnienie zmniejszyło się o 20% (z 50 milisekund do 40 milisekund), a opóźnienie p99 zmniejszyło się o 25% (z 200 milisekund do 150 milisekund).

W tym poście dzielimy się tym, jak zaoszczędziliśmy na kosztach wnioskowania, jednocześnie zmniejszając opóźnienia i zwiększając przepustowość za pomocą AWS Inferentia.

W poszukiwaniu wydajnych, ekonomicznych mocy obliczeniowych

Zespół ByteDance AML koncentruje się na badaniach i wdrażaniu najnowocześniejszych systemów ML oraz wymaganych przez nie heterogenicznych zasobów obliczeniowych. Tworzymy systemy szkoleniowe i wnioskowania na dużą skalę dla szerokiej gamy modeli rekomendacji, przetwarzania języka naturalnego (NLP) i wizji komputerowej (CV). Modele te są bardzo złożone i przetwarzają ogromne ilości danych z wielu platform treści obsługiwanych przez ByteDance. Wdrażanie tych modeli wymaga znacznych zasobów GPU, zarówno w chmurze, jak i lokalnie. Dlatego koszty obliczeniowe dla tych systemów wnioskowania są dość wysokie.

Chcieliśmy obniżyć te koszty bez wpływu na przepustowość lub opóźnienia. Zależało nam na elastyczności chmury i szybszym cyklu dostarczania, który jest znacznie krótszy niż ten potrzebny do konfiguracji lokalnej. I chociaż byliśmy otwarci na odkrywanie nowych opcji przyspieszonego uczenia maszynowego, chcieliśmy również bezproblemowego środowiska programistycznego.

Od naszego zespołu AWS dowiedzieliśmy się, że instancje EC2 Inf1 oparte na AWS Inferentia zapewniają wydajne wnioskowanie ML przy najniższym koszcie za wnioskowanie w chmurze. Byliśmy ciekawi ich eksploracji i stwierdziliśmy, że dobrze pasują do naszego przypadku użycia, ponieważ przeprowadzamy znaczące uczenie maszynowe na dużych ilościach obrazów, obiektów, mowy i danych tekstowych. Zdecydowanie pasowały do ​​naszych celów, ponieważ mogliśmy uzyskać ogromne oszczędności kosztów, biorąc pod uwagę złożoność naszych modeli i liczbę codziennych prognoz. Co więcej, AWS Inferentia oferuje dużą ilość pamięci na chipie, której można użyć do buforowania dużych modeli zamiast przechowywania ich poza chipem. Uznaliśmy, że może to mieć znaczący wpływ na zmniejszenie opóźnienia wnioskowania, ponieważ rdzenie przetwarzające AWS Inferentia, zwane NeuronCores, mają szybki dostęp do modeli przechowywanych w pamięci na chipie i nie są ograniczone przez pamięć poza chipem pasmo.

Ostatecznie, po ocenieniu kilku opcji, wybraliśmy instancje EC2 Inf1 ze względu na ich lepszy stosunek wydajności do ceny w porównaniu z instancjami G4dn i NVIDIA T4 lokalnie. Zaangażowaliśmy się w cykl ciągłych iteracji z zespołem AWS, aby odblokować korzyści cenowe i wydajnościowe Inf1.

Wdrażanie obciążeń wnioskowania w AWS Inferentia

Rozpoczęcie pracy z AWS Inferentia przy użyciu AWS Neuron SDK obejmowało dwie fazy: kompilację kodu modelu i wdrożenie na instancjach Inf1. Jak zwykle przy przenoszeniu modeli ML do jakiejkolwiek nowej infrastruktury, napotkaliśmy pewne wyzwania. Udało nam się przezwyciężyć te wyzwania dzięki staranności i wsparciu naszego zespołu AWS. W poniższych sekcjach dzielimy się kilkoma przydatnymi wskazówkami i obserwacjami opartymi na naszym doświadczeniu we wdrażaniu obciążeń wnioskowania w AWS Inferentia.

Model konformera do OCR

Nasz model konformatora optycznego rozpoznawania znaków (OCR) wykrywa i odczytuje tekst w obrazach. Pracowaliśmy nad kilkoma optymalizacjami, aby uzyskać wysoką wydajność (QPS) dla różnych rozmiarów wsadów, przy jednoczesnym utrzymaniu niskich opóźnień. Poniżej wymieniono niektóre kluczowe optymalizacje:

• Optymalizacje kompilatora – Domyślnie Inferentia działa najlepiej na danych wejściowych o stałej długości sekwencji, co stanowiło wyzwanie, ponieważ długość danych tekstowych nie jest stała. Aby temu zaradzić, podzieliliśmy nasz model na dwie części: koder i dekoder. Skompilowaliśmy te dwa modele podrzędne oddzielnie, a następnie połączyliśmy je w jeden model za pomocą TorchScript. Uruchamiając przepływ sterowania pętlą for na procesorach, podejście to umożliwiło obsługę zmiennych długości sekwencji w Inferentii.
• Wydajność splotu w głąb – Napotkaliśmy wąskie gardło DMA w operacji głębokiego splotu, która jest intensywnie wykorzystywana przez nasz model konformera. Ściśle współpracowaliśmy z zespołem AWS Neuron, aby zidentyfikować i rozwiązać wąskie gardło wydajności dostępu DMA, co poprawiło wydajność tej operacji i poprawiło ogólną wydajność naszego modelu OCR.

Stworzyliśmy dwa nowe warianty modeli, aby zoptymalizować nasze wdrożenie na Inferentii:

• Połączony i rozwinięty koder/dekoder – Zamiast używać niezależnie skompilowanego kodera i dekodera, połączyliśmy koder i w pełni rozwinięty dekoder w jeden model i skompilowaliśmy ten model jako pojedynczy NEFF. Rozwinięcie dekodera umożliwia uruchomienie całego przepływu sterowania dekoderem w Inferentii bez użycia jakichkolwiek operacji procesora. Przy takim podejściu każda iteracja dekodera wykorzystuje dokładnie tyle mocy obliczeniowej, ile jest potrzebne dla tego tokena. Takie podejście poprawia wydajność, ponieważ znacznie zmniejszamy nadmiar obliczeń, który był wcześniej wprowadzany przez wypełnianie danych wejściowych. Co więcej, nie jest konieczne przesyłanie danych z Inferentii do procesora pomiędzy iteracjami dekodera, co drastycznie skraca czas operacji we/wy. Ta wersja modelu nie obsługuje wczesnego zatrzymania.
• Rozwinięty dekoder podzielony na partycje – Podobnie jak połączony, w pełni rozwinięty model, ten wariant modelu rozwija wiele iteracji dekodera i kompiluje je jako pojedyncze wykonanie (ale nie obejmuje kodera). Na przykład, dla maksymalnej długości sekwencji 75, możemy rozwinąć dekoder na 3 partycje, które obliczają tokeny 1-25, 26-50 i 51-75. Pod względem I/O jest to również znacznie szybsze, ponieważ nie musimy przesyłać wyjścia enkodera raz na każdą iterację. Zamiast tego dane wyjściowe są przesyłane tylko raz na każdą partycję dekodera. Ta wersja modelu obsługuje wczesne zatrzymywanie, ale tylko na granicach partycji. Granice partycji można dostroić dla każdej konkretnej aplikacji, aby zapewnić, że większość żądań wykonuje tylko jedną partycję.

Aby jeszcze bardziej poprawić wydajność, wprowadziliśmy następujące optymalizacje w celu zmniejszenia wykorzystania pamięci lub poprawy wydajności dostępu:

• Deduplikacja tensorowa i kopie zredukowane – Jest to optymalizacja kompilatora, która znacznie zmniejsza rozmiar rozwiniętych modeli i liczbę instrukcji/dostępu do pamięci poprzez ponowne wykorzystanie tensorów w celu poprawy wydajności przestrzeni.
• Zredukowane instrukcje – Jest to optymalizacja kompilatora używana z niewypełnioną wersją dekodera w celu znacznego zmniejszenia całkowitej liczby instrukcji.
• Deduplikacja wielordzeniowa – Jest to optymalizacja środowiska uruchomieniowego będąca alternatywą dla deduplikacji tensorowej. Dzięki tej opcji wszystkie modele wielordzeniowe będą znacznie bardziej efektywne pod względem zajmowanej przestrzeni.

Model ResNet50 do klasyfikacji obrazów

ResNet-50 to wstępnie wyszkolony model głębokiego uczenia się do klasyfikacji obrazów. Jest to konwolucyjna sieć neuronowa (CNN lub ConvNet), która jest najczęściej stosowana do analizy obrazów wizualnych. Zastosowaliśmy następujące techniki, aby poprawić wydajność tego modelu w Inferentii:

• Transformacja modelu – Wiele modeli ByteDance jest eksportowanych w formacie ONNX, którego Inferentia obecnie nie obsługuje natywnie. Aby obsłużyć te modele ONNX, zespół AWS Neuron dostarczył skrypty do przekształcania naszych modeli z formatu ONNX do modeli PyTorch, które można bezpośrednio skompilować dla Inferentii za pomocą torch-neuron.
• Optymalizacja wydajności – Ściśle współpracowaliśmy z tzw Neuron AWS zespół, aby dostroić heurystykę planowania w kompilatorze, aby zoptymalizować wydajność naszych modeli ResNet-50.

Multimodalny model moderacji treści

Nasz multimodalny model głębokiego uczenia się jest połączeniem wielu oddzielnych modeli. Rozmiar tego modelu jest stosunkowo duży, co powodowało błędy wczytywania modelu na Inferentii. Zespół AWS Neuron z powodzeniem rozwiązał ten problem, wykorzystując podział wagi w celu zmniejszenia wykorzystania pamięci urządzenia. Zespół Neuron udostępnił tę funkcję deduplikacji wagi w bibliotece Neuron libnrt, a także ulepszył narzędzia Neuron Tools w celu uzyskania dokładniejszych wskaźników. Funkcję usuwania duplikatów wagi w czasie wykonywania można włączyć, ustawiając następującą zmienną środowiskową przed uruchomieniem wnioskowania:

NEURON_RT_MULTI_INSTANCE_SHARED_WEIGHTS=1

Zaktualizowany Neuron SDK zmniejszył ogólne zużycie pamięci przez nasze zduplikowane modele, co umożliwiło nam wdrożenie multimodalnego modelu do wnioskowania wielordzeniowego.

Migracja większej liczby modeli do AWS Inferentia

W ByteDance nadal wdrażamy innowacyjne modele głębokiego uczenia się, aby dostarczać wspaniałe doświadczenia prawie 2 miliardom aktywnych użytkowników miesięcznie. Biorąc pod uwagę ogromną skalę, na jaką działamy, nieustannie szukamy sposobów na obniżenie kosztów i optymalizację wydajności. Będziemy kontynuować migrację modeli do AWS Inferentia, aby czerpać korzyści z jej wysokiej wydajności i efektywności kosztowej. Chcemy również, aby AWS uruchamiał więcej typów instancji opartych na AWS Inferentia, takich jak te z większą liczbą procesorów wirtualnych do zadań przetwarzania wstępnego. Idąc dalej, ByteDance ma nadzieję zobaczyć więcej innowacji krzemowych od AWS, aby zapewnić najlepszą wydajność cenową dla aplikacji ML.

Jeśli chcesz dowiedzieć się więcej o tym, jak AWS Inferentia może pomóc Ci obniżyć koszty przy jednoczesnej optymalizacji wydajności aplikacji do wnioskowania, odwiedź stronę Instancje Amazon EC2 Inf1 strona produktu.

---

O autorach

Minghui Yu jest starszym kierownikiem zespołu uczenia maszynowego ds. wnioskowania w firmie ByteDance. Jego obszarem zainteresowania jest akceleracja AI Computing i system uczenia maszynowego. Bardzo interesuje się komputerami heterogenicznymi i architekturą komputerów w epoce post Moore'a. W wolnym czasie lubi koszykówkę i łucznictwo.

Jianzhe Xiao jest starszym liderem zespołu inżynierów oprogramowania w zespole AML w ByteDance. Jego obecna praca koncentruje się na pomocy zespołowi biznesowemu w przyspieszeniu procesu wdrażania modelu i poprawie wydajności wnioskowania modelu. Poza pracą lubi grać na pianinie.

Tian Shi jest starszym architektem rozwiązań w AWS. Specjalizuje się w analizie danych, uczeniu maszynowym i rozwiązaniach serverless. Z pasją pomaga klientom w projektowaniu i budowaniu niezawodnych i skalowalnych rozwiązań w chmurze. W wolnym czasie lubi pływać i czytać.

Jia Donga jest Customer Solutions Manager w AWS. Lubi poznawać usługi AWS AI/ML i pomagać klientom w osiąganiu wyników biznesowych poprzez tworzenie dla nich rozwiązań. Poza pracą Jia lubi podróżować, jogę i filmy.

Jonathana Lunta jest inżynierem oprogramowania w firmie Amazon i koncentruje się na rozwoju frameworków ML. W swojej karierze pracował w pełnym zakresie ról związanych z nauką o danych, w tym opracowywaniem modeli, wdrażaniem infrastruktury i optymalizacją pod kątem sprzętu.

Jozuego Hannana jest inżynierem uczenia maszynowego w Amazon. Pracuje nad optymalizacją modeli głębokiego uczenia się na potrzeby wielkoskalowych aplikacji do przetwarzania obrazu komputerowego i przetwarzania języka naturalnego.

Shruti Koparkar jest starszym menedżerem ds. marketingu produktów w AWS. Pomaga klientom odkrywać, oceniać i dostosowywać akcelerowaną infrastrukturę obliczeniową EC2 do ich potrzeb w zakresie uczenia maszynowego.