Jak skalować wnioskowanie uczenia maszynowego dla przypadków użycia SaaS dla wielu dzierżawców

Opublikowane ponownie przez Plato

Obserwuje: 0

Ten post został napisany wspólnie z Sowmyą Manusani, starszym inżynierem ds. uczenia maszynowego w firmie Zendesk

Zendesk to firma SaaS, która buduje oprogramowanie wspierające, sprzedaż i angażujące klientów dla wszystkich, z prostotą jako podstawą. Rozwija się dzięki temu, że ponad 170,000 XNUMX firm na całym świecie skutecznie obsługuje setki milionów klientów. Zespół Machine Learning w Zendcaesk jest odpowiedzialny za wzmacnianie zespołów Customer Experience, aby osiągnąć jak najlepsze wyniki. Łącząc moc danych i ludzi, Zendesk dostarcza inteligentne produkty, które zwiększają produktywność ich klientów poprzez automatyzację ręcznej pracy.

Zendesk buduje produkty ML od 2015 roku, w tym: Odpowiedz Bot, Przewidywanie satysfakcji, Wskazówki dotyczące treści, Sugerowane makra, i wiele więcej. W ciągu ostatnich kilku lat, wraz z rozwojem głębokiego uczenia, zwłaszcza w NLP, dostrzegli wiele możliwości automatyzacji przepływów pracy i pomocy agentom we wspieraniu swoich klientów rozwiązaniami Zendesk. Zendesk obecnie używa TensorFlow i PyTorch do budowania modeli głębokiego uczenia.

Klienci, tacy jak Zendesk, zbudowali odnoszące sukcesy, duże firmy związane z oprogramowaniem jako usługą (SaaS) na Amazon Web Services (AWS). Kluczowym czynnikiem sukcesu modelu biznesowego SaaS jest możliwość zastosowania wielu dzierżawców w aplikacji i infrastrukturze. Zapewnia to oszczędność kosztów i kosztów operacyjnych, ponieważ aplikację trzeba zbudować tylko raz, ale można jej używać wiele razy, a infrastrukturę można współużytkować. Widzimy, jak wielu klientów buduje bezpieczne, ekonomiczne, wielodostępne systemy na AWS we wszystkich warstwach stosu, od obliczeń, pamięci masowej, bazy danych po sieci, a teraz widzimy, że klienci muszą zastosować to do uczenia maszynowego (ML ).

Dokonanie trudnego kompromisu między ponownym wykorzystaniem modeli a hiperpersonalizacją

Wielodostępność dla firm SaaS zazwyczaj oznacza, że pojedyncza aplikacja jest ponownie używana przez wielu użytkowników (klientów SaaS). Stwarza to oszczędność kosztów i obniża koszty operacyjne. Jednak modele uczenia maszynowego czasami muszą być spersonalizowane do wysokiego stopnia szczegółowości (hiperpersonalizowane), aby móc tworzyć dokładne prognozy. Oznacza to, że paradygmat SaaS „buduj raz, używaj wiele razy” nie zawsze może być zastosowany do ML, jeśli modele mają specyficzność. Weźmy na przykład przypadek użycia platform obsługi klienta. Język, który użytkownicy uwzględniają w zgłoszeniu do pomocy technicznej, różni się w zależności od tego, czy chodzi o udział w przejazdach („przejazd trwał zbyt długo”), czy o zakup odzieży („odbarwienie po praniu”). W tym przypadku użycia poprawa dokładności przewidywania najlepszego działania naprawczego może wymagać przeszkolenia modelu przetwarzania języka naturalnego (NLP) na zestawie danych specyficznym dla domeny biznesowej lub branży branżowej. Zendesk mierzy się dokładnie z tym wyzwaniem, próbując wykorzystać ML w swoich rozwiązaniach. Musieli stworzyć tysiące wysoce spersonalizowanych modeli ML, z których każdy był dostosowany do konkretnego klienta. Aby rozwiązać to wyzwanie polegające na efektywnym kosztowo wdrażaniu tysięcy modeli, Zendesk zwrócił się do Amazon SageMaker.

W tym poście pokazujemy, jak korzystać z niektórych nowszych funkcji Amazon Sage Maker, w pełni zarządzaną usługę uczenia maszynowego, umożliwiającą tworzenie wielodostępnej funkcji wnioskowania ML. Dzielimy się również rzeczywistym przykładem tego, jak firma Zendesk z powodzeniem osiągnęła ten sam wynik, wdrażając szczęśliwy środek między możliwością obsługi hiperpersonalizacji w swoich modelach ML a oszczędnym, współdzielonym wykorzystaniem infrastruktury przy użyciu wielomodelowych punktów końcowych SageMaker ( MME).

Wielomodelowe punkty końcowe SageMaker

Wielomodelowe punkty końcowe programu SageMaker umożliwiają wdrażanie wielu modeli za pojedynczym punktem końcowym wnioskowania, który może zawierać jedną lub więcej instancji. Każda instancja jest zaprojektowana do ładowania i obsługi wielu modeli, z uwzględnieniem pojemności pamięci i procesora. Dzięki tej architekturze firma SaaS może przełamać liniowo rosnący koszt hostowania wielu modeli i osiągnąć ponowne wykorzystanie infrastruktury zgodne z modelem wielodostępności stosowanym w innym miejscu stosu aplikacji.

Poniższy diagram ilustruje architekturę wielomodelowego punktu końcowego programu SageMaker.

Wielomodelowy punkt końcowy SageMaker dynamicznie ładuje modele z Usługa Amazon Simple Storage (Amazon S3) po wywołaniu, zamiast pobierania wszystkich modeli przy pierwszym utworzeniu punktu końcowego. W rezultacie początkowe wywołanie modelu może mieć większe opóźnienie wnioskowania niż kolejne wnioskowania, które są kończone z małym opóźnieniem. Jeśli model jest już załadowany do kontenera po wywołaniu, krok pobierania jest pomijany, a model zwraca wnioski z małym opóźnieniem. Załóżmy na przykład, że masz model, który jest używany tylko kilka razy dziennie. Jest automatycznie ładowany na żądanie, a często używane modele są zachowywane w pamięci i wywoływane z konsekwentnie niskim opóźnieniem.

Przyjrzyjmy się bliżej, w jaki sposób firma Zendesk wykorzystała SageMaker MME, aby osiągnąć opłacalne, hiperskalowe wdrażanie ML dzięki funkcji Suggested Macros ML.

Dlaczego Zendesk zbudował hiperspersonalizowane modele

Klienci Zendesk są rozproszeni po całym świecie w różnych branżach z różną semantyką zgłoszeń do pomocy technicznej. Dlatego, aby jak najlepiej służyć swoim klientom, często muszą tworzyć spersonalizowane modele, które są szkolone na podstawie danych zgłoszeń do pomocy technicznej specyficznych dla klienta, aby poprawnie identyfikować intencje, makra i nie tylko.

W październiku 2021 r. wydali nową funkcję NLP ML, Sugerowane makra, która zaleca makra (wstępnie zdefiniowane działania) na podstawie tysięcy prognoz modelu specyficznych dla klienta. Zespół ML firmy Zendesk zbudował model klasyfikatora NLP oparty na TensorFlow, wyszkolony na podstawie wcześniejszej historii zawartości i makr biletów na klienta. Dzięki dostępnym modelom, prognoza makro jest zalecana za każdym razem, gdy agent wyświetla zgłoszenie (jak pokazano na poniższym zrzucie ekranu), co pomaga agentowi w szybkiej obsłudze klientów. Ponieważ makra są specyficzne dla klientów, Zendesk potrzebuje modeli specyficznych dla klienta, aby obsługiwać dokładne prognozy.

Pod maską sugerowanych makr Zendesk

Sugerowane modele makr to sieci neuronowe oparte na NLP, które mają rozmiar około 7–15 MB. Głównym wyzwaniem jest wprowadzenie do produkcji tysięcy takich modeli z ekonomicznymi, niezawodnymi i skalowalnymi rozwiązaniami.

Każdy model ma różne wzorce ruchu, z co najmniej dwoma żądaniami na sekundę i szczytem setek żądań na sekundę, obsługującymi miliony prognoz dziennie z opóźnieniem modelu wynoszącym około 100 milisekund, gdy model jest dostępny w pamięci. Punkty końcowe SageMaker są wdrażane w wielu regionach AWS, obsługując tysiące żądań na minutę na punkt końcowy.

Dzięki możliwości hostowania wielu modeli na jednym punkcie końcowym firma SageMaker pomogła firmie Zendesk zmniejszyć koszty wdrożenia i stworzyć opłacalne rozwiązanie w porównaniu z wdrażaniem jednego modelu punktu końcowego na klienta. Kompromisem jest tutaj mniejsza kontrola nad zarządzaniem według modelu; jest to jednak obszar, w którym Zendesk współpracuje z AWS w celu poprawy wielomodelowych punktów końcowych.

Jedną z funkcji wielu modeli programu SageMaker jest leniwe ładowanie modeli, co oznacza, że modele są ładowane do pamięci przy pierwszym wywołaniu. Ma to na celu optymalizację wykorzystania pamięci; jednak powoduje to skoki czasu odpowiedzi przy pierwszym obciążeniu, co może być postrzegane jako problem z zimnym startem. Dla sugerowanych makr było to wyzwanie; jednak Zendesk przezwyciężył ten problem, implementując funkcję wstępnego ładowania w uzupełnieniu obsługi punktu końcowego SageMaker w celu załadowania modeli do pamięci przed obsługą ruchu produkcyjnego. Po drugie, MME usuwa z pamięci rzadko używane modele, więc aby osiągnąć spójne niskie opóźnienia we wszystkich modelach i uniknąć „hałaśliwych sąsiadów” wpływających na inne mniej aktywne modele, Zendesk współpracuje z AWS, aby dodać nowe funkcje, omówione w dalszej części wpisu, aby umożliwić bardziej wyraźne zarządzanie według modelu. Dodatkowo, jako rozwiązanie tymczasowe, Zendesk odpowiednio dobrał wielkość floty MME, aby zminimalizować rozładunek zbyt wielu modeli. Dzięki temu Zendesk jest w stanie dostarczać prognozy wszystkim swoim klientom z niskim opóźnieniem, około 100 milisekund, i nadal osiągać 90% oszczędności w porównaniu z dedykowanymi punktami końcowymi.

W przypadku odpowiedniego rozmiaru MME firma Zendesk zauważyła podczas testowania obciążenia, że większa liczba mniejszych instancji (odchylenie przy skalowaniu poziomym) za MME była lepszym wyborem niż posiadanie mniejszej liczby większych instancji pamięci (skalowanie pionowe). Zendesk zauważył, że pakowanie zbyt wielu modeli (ponad 500 modeli TensorFlow w ich przypadku) na pojedynczą instancję o dużej pamięci nie działało dobrze, ponieważ pamięć nie jest jedynym zasobem instancji, który może być wąskim gardłem. Mówiąc dokładniej, zaobserwowali, że TensorFlow tworzył wiele wątków (3 x łączna liczba procesorów wirtualnych instancji) na model, więc ładowanie ponad 500 modeli na jedną instancję powodowało przekroczenie limitów na poziomie jądra dla maksymalnej liczby wątków, które mogą zostać wygenerowane w instancji. Kolejny problem związany z używaniem mniejszej liczby, większych instancji wystąpił, gdy Zendesk doświadczył ograniczania przepustowości (jako mechanizmu bezpieczeństwa) w niektórych instancjach za MME, ponieważ częstotliwość unikalnych wywołań modelu na sekundę przekraczała Serwer wielu modeli (MMS) w jednej instancji może bezpiecznie obsłużyć bez brązowienia instancji. To był kolejny problem, który został rozwiązany przy użyciu coraz mniejszych instancji.

Z perspektywy obserwowalności, która jest kluczowym elementem każdej aplikacji produkcyjnej, Amazon Cloud Watch metryki, takie jak wywołania, procesor, wykorzystanie pamięci i metryki specyficzne dla wielu modeli, takie jak załadowane modele w pamięci, czas ładowania modelu, czas oczekiwania na ładowanie modelu i trafienie w pamięć podręczną modelu, mają charakter informacyjny. W szczególności podział opóźnień modelu pomógł firmie Zendesk zrozumieć problem zimnego startu i jego wpływ.

Pod maską automatycznego skalowania MME

Za każdym wielomodelowym punktem końcowym znajdują się wystąpienia hosta modelu, jak pokazano na poniższym diagramie. Te instancje ładują i eksmitują wiele modeli do iz pamięci na podstawie wzorców ruchu do modeli.

SageMaker kontynuuje kierowanie żądań wnioskowania dla modelu do instancji, w której model jest już załadowany, tak że żądania są obsługiwane z buforowanej kopii modelu (patrz poniższy diagram, który pokazuje ścieżkę żądania dla pierwszego żądania predykcji w porównaniu z buforowanym żądaniem predykcji ścieżka). Jeśli jednak model otrzymuje wiele żądań wywołań i istnieją dodatkowe instancje dla wielomodelowego punktu końcowego, SageMaker kieruje niektóre żądania do innej instancji, aby uwzględnić wzrost. Aby skorzystać z automatycznego skalowania modeli w programie SageMaker, upewnij się, że: konfiguracja automatycznego skalowania instancji udostępnienie dodatkowej pojemności instancji. Skonfiguruj zasady skalowania na poziomie punktu końcowego za pomocą parametrów niestandardowych lub wywołań na minutę (zalecane), aby dodać więcej wystąpień do floty punktów końcowych.

Przypadki użycia najlepiej dopasowane do MME

Wielomodelowe punkty końcowe programu SageMaker dobrze nadają się do hostowania dużej liczby podobnych modeli, które można obsługiwać za pośrednictwem współdzielonego kontenera obsługi i nie trzeba uzyskiwać dostępu do wszystkich modeli jednocześnie. MME najlepiej nadaje się do modeli, które mają podobny rozmiar i opóźnienia wywołania. Dopuszczalne są pewne różnice w rozmiarze modelu; na przykład modele Zendesk mają zakres od 10 do 50 Mb, co działa dobrze, ale różnice w rozmiarze o współczynnik 10, 50 lub 100 razy większe nie są odpowiednie. Większe modele mogą powodować większą liczbę ładowań i rozładowań mniejszych modeli, aby pomieścić wystarczającą ilość miejsca w pamięci, co może skutkować dodatkowym opóźnieniem w punkcie końcowym. Różnice w charakterystyce wydajności większych modeli mogą również nierównomiernie zużywać zasoby, takie jak procesor, co może mieć wpływ na inne modele w instancji.

MME jest również przeznaczony do współhostowania modeli korzystających z tej samej struktury ML, ponieważ używają one udostępnionego kontenera do ładowania wielu modeli. Dlatego też, jeśli masz mieszankę platform ML we flocie modeli (takich jak PyTorch i TensorFlow), dedykowane punkty końcowe SageMaker lub hosting wielokontenerowy są lepszym wyborem. Wreszcie, MME nadaje się do aplikacji, które mogą tolerować sporadyczne kary za opóźnienie zimnego startu, ponieważ rzadko używane modele mogą zostać odciążone na rzecz często wywoływanych modeli. Jeśli masz długi ogon rzadko używanych modeli, wielomodelowy punkt końcowy może wydajnie obsługiwać ten ruch i zapewniać znaczne oszczędności.

Podsumowanie

W tym poście dowiedziałeś się, w jaki sposób SaaS i wielodostępność są powiązane z ML oraz jak wielomodelowe punkty końcowe SageMaker umożliwiają wielodostępność i opłacalność wnioskowania o ML. Dowiedziałeś się o przypadku użycia wielu dzierżawców modeli ML dla poszczególnych klientów firmy Zendesk oraz o tym, jak hostowali oni tysiące modeli ML w SageMaker MME w ramach funkcji sugerowanych makr i osiągnęli 90% oszczędności kosztów wnioskowania w porównaniu z dedykowanymi punktami końcowymi. Przypadki użycia hiperpersonalizacji mogą wymagać tysięcy modeli ML, a MME to opłacalny wybór dla tego przypadku użycia. Będziemy nadal wprowadzać ulepszenia w MME, aby umożliwić hostowanie modeli z małymi opóźnieniami i bardziej szczegółową kontrolą dla każdego spersonalizowanego modelu. Aby rozpocząć korzystanie z MME, zobacz Hostuj wiele modeli w jednym kontenerze za jednym punktem końcowym.

O autorach

Syeda Jaffry'ego jest starszym architektem rozwiązań w AWS. Współpracuje z wieloma firmami, od średnich organizacji po duże przedsiębiorstwa, od usług finansowych po niezależnych dostawców oprogramowania, pomagając im tworzyć i obsługiwać bezpieczne, odporne, skalowalne i wydajne aplikacje w chmurze.

Sowmya Manusani jest starszym inżynierem ds. uczenia maszynowego w firmie Zendesk. Pracuje nad produkcją funkcji uczenia maszynowego opartych na NLP, które koncentrują się na poprawie wydajności agentów dla tysięcy klientów Zendesk Enterprise. Ma doświadczenie w budowaniu zautomatyzowanych potoków szkoleniowych dla tysięcy spersonalizowanych modeli i obsłudze ich przy użyciu bezpiecznych, odpornych, skalowalnych i wydajnych aplikacji. W wolnym czasie lubi rozwiązywać zagadki i próbować malować.

Saurabha Trikande jest starszym menedżerem produktu w firmie Amazon SageMaker Inference. Pasjonuje go praca z klientami i zwiększanie dostępności uczenia maszynowego. W wolnym czasie Saurabh lubi wędrować, poznawać innowacyjne technologie, śledzić TechCrunch i spędzać czas z rodziną.

Deepti Ragha jest inżynierem rozwoju oprogramowania w zespole Amazon SageMaker. Jej obecna praca koncentruje się na budowaniu funkcji do efektywnego hostowania modeli uczenia maszynowego. W wolnym czasie lubi podróżować, wędrować i uprawiać rośliny.