Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
W tym artykule przedstawiono kluczowy proces testowania wydajności punktów końcowych usługi Mosaic AI Model w celu zapewnienia skutecznego radzenia sobie z obciążeniami produkcyjnymi. Zawiera również praktyczne przykłady, rzeczywiste analogie i instrukcje krok po kroku przy użyciu frameworka testowania obciążenia Locust, aby zademonstrować, jak mierzyć kluczowe metryki wydajności, takie jak żądania na sekundę i limity współbieżności, dzięki czemu można prawidłowo i pewnie określić rozmiar punktów końcowych i wdrażać modele, spełniając potrzeby biznesowe.
Wskazówka
Testowanie obciążenia jest istotnym składnikiem optymalizacji produkcyjnej. Aby zapoznać się z kompleksowym przewodnikiem dotyczącym strategii optymalizacji, w tym optymalizacji infrastruktury, modelu i optymalizacji po stronie klienta, zobacz Optymalizowanie punktów końcowych obsługujących model dla środowiska produkcyjnego.
Co to jest test obciążeniowy?
Test obciążeniowy to test, który symuluje rzeczywiste użycie modelu sztucznej inteligencji Mosaic obsługującego punkty końcowe, zapewniając spełnienie wymagań produkcyjnych, takich jak opóźnienie lub liczba żądań na sekundę. Test obciążeniowy mierzy wydajność punktu końcowego na różnych poziomach ruchu, ułatwiając poprawne ustawianie rozmiaru punktu końcowego, aby nie powodować opóźnień.
Wyobraź sobie: Jest ósma rano w dzień powszedni, a popularna kawiarnia w samym sercu miasta właśnie otwiera. Aromat świeżej kawy wypełnia powietrze. Barista jest gotowy, maszyny są rozgrzane, a kolejka spragnionych kofeiny klientów już się tworzy.
Na początku sprawy działają płynnie. Kilku klientów podchodzi, składają zamówienia, a barista zaczyna przygotowywać ich napoje. Niektóre napoje zajmują 30 sekund, a inne zajmują minutę — w zależności od złożoności. Barista żongluje wieloma zamówieniami z wprawną wydajnością.
Ale wkrótce przybywa więcej osób. Pięciu klientów zamienia się w dziesięć, a następnie dwadzieścia. Każdy składa zamówienie, czeka na drinka, a może rozmawia trochę przy ladzie. Barista jest teraz pod presją. Nawet gdy dołącza drugi barista, system zaczyna się przeciążać, kolejka się wydłuża, zamówienia się piętrzą, a klienci zaczynają czekać dłużej.
Teraz wyobraź sobie, że próbujesz zmierzyć liczbę napojów, które kawiarnia może podać na minutę, zanim klienci zaczną odchodzić sfrustrowani. To jest testowanie obciążenia.
W tej analogii:
- Każdy klient jest klientem wysyłającym żądanie.
- Barista(y) reprezentują serwer(y), które przetwarzają wnioskowanie modelu pojedynczo lub równolegle.
- Czas realizacji zamówienia i podania napoju to czas implementacji modelu.
- Opóźnienia w rozmowie, płaceniu lub znajdowaniu zamówienia są obciążeniem sieci.
- Gdy więcej klientów przybywa jednocześnie, mamy do czynienia z współbieżnością klientów.
- Dodanie większej liczby barista lub większej liczby maszyn przypomina zwiększenie współbieżności serwera.
Podobnie jak w każdej dobrej kawiarni, istnieje ograniczenie do tego, ile pracownicy mogą sobie poradzić jednocześnie. Jeśli nie planujesz wcześniej — na przykład zatrudniając więcej baristów w godzinach szczytu — ludzie odchodzą niezadowoleni. To samo dotyczy systemów pod obciążeniem. Testowanie obciążenia pomaga określić, gdzie znajdują się wąskie gardła, jaki ruch może obsłużyć system i jakie zmiany należy wprowadzić w celu zapewnienia bezproblemowej usługi.
Przed uruchomieniem testu obciążeniowego w punkcie końcowym należy wykonać następujące działania:
- Zapoznaj się ze składnikami i pojęciami związanymi z testowaniem obciążenia.
- Zdecyduj i zdefiniuj wymagania produkcyjne.
- Znajdź reprezentatywny ładunek dla frameworku do testowania obciążenia, który będzie używany podczas benchmarkingu punktu końcowego.
Pojęcia i definicje dotyczące testowania obciążenia
W poniższej tabeli zdefiniowano pojęcia związane z testowaniem obciążenia:
| Pojęcie | Opis |
|---|---|
| Współbieżność klientów (liczba klientów) | Całkowita liczba klientów, którzy jednocześnie wysyłają żądania równolegle do punktu końcowego. Są to twoi klienci do kawiarni w powyższym przykładzie. Produkcja: łączna liczba wystąpień klientów wysyłających ruch do punktu końcowego obsługującego model. Test obciążeniowy: W Locust jest to liczba utworzonych użytkowników, którzy wysyłają ruch do punktu końcowego obsługującego model będącego poddawanego testowi obciążeniowemu. |
| Współbieżność punktu końcowego | Liczba procesów wnioskowania lub wystąpień modelu, które mogą obsługiwać żądania przychodzące. Można również wyrazić jako liczbę żądań, które mogą być jednocześnie obsługiwane przez punkt końcowy. Jest to liczba baristów w powyższym przykładzie. Serwowanie Modeli Mosaic AI: Punkty końcowe serwowania modeli można skonfigurować pod kątem skalowania poziomego obliczeń. Na przykład użycie Small rozmiaru punktów końcowych procesora CPU powoduje utworzenie czterech wystąpień modelu w punkcie końcowym. |
| Opóźnienie | Czas (w milisekundach) potrzebny na pełne zrealizowanie żądania zwrotnego. Miara całkowitego czasu od wysłania żądania przez klienta do momentu otrzymania odpowiedzi, w tym czas działania punktu końcowego oraz opóźnienie sieci. |
| Opóźnienie PXX (P50,P90,P99) | Opóźnienie (w milisekundach), w którym XX percentyl żądań zakończył się szybciej niż pozostałe. Na przykład P90 wynoszące 30 ms oznacza, że 90% wszystkich żądań zakończyło się w 30 ms lub mniej. |
| Żądania na sekundę (RPS) | Liczba zakończonych żądań na sekundę. Ukończono oznacza, że odpowiedź jest zwracana z punktu końcowego do klienta. |
Wymagania dotyczące opóźnienia
Na podstawie wymagań biznesowych i klientów zdefiniuj idealną wydajność systemu. W przypadku punktu końcowego obsługującego model opóźnienie zawiera czas podróży, który klient odczuwa podczas wysyłania danych do wnioskowania. Obejmuje to opóźnienie sieci, a także czas wnioskowania. Ważne jest, aby upewnić się, że wymagania są realistyczne. Na przykład, jeśli model zajmuje 15 ms na wykonanie wnioskowania, gdy jest załadowany do pamięci, musisz zezwolić na dodatkowy czas na opóźnienia sieci podczas serwowania modelu na punkcie końcowym.
Jak są powiązane RPS, opóźnienia i współbieżność?
Firma ma pewne zdefiniowane kryteria sukcesu systemu. W przypadku systemów uczenia maszynowego kryteria biznesowe zazwyczaj obejmują wysoką jakość wyników, niskie opóźnienia oraz wysoką przepływność. Jakość wyników jest w szczególności związana z samym modelem, podczas gdy kompleksowe opóźnienie i przepływność są cechami systemu obsługującego. Kompleksowe opóźnienie składa się z czasu wykonywania modelu i obciążenia sieciowego. Przepływność (lub żądania lub zapytania na sekundę) jest odwrotnie związana z opóźnieniem i bezpośrednio związana ze współbieżnością.
- Im większa współbieżność, tym większa przepływność.
- Im większe opóźnienie, tym mniejsza przepustowość.
Ogólnie rzecz biorąc, istnieje optymalny stosunek współbieżności po stronie klienta do współbieżności po stronie serwera dla każdej danej aplikacji. Na przykład "ile hamburgerów może jednocześnie przygotować kucharz". Ponieważ w procesie gotowania może być wiele wspólnych kroków, szef kuchni linii może być w stanie bardziej optymalnie gotować cztery hamburgery w tym samym czasie, a nie gotować tylko jeden naraz. Istnieje ograniczenie równoleglenia; w pewnym momencie wykonywanie wielu równoległych operacji dodaje zbyt dużo opóźnienia, tak jak gdyby szef kuchni musiał dodać ser do 1000 burgerów.
Jednym z głównych celów testu obciążeniowego jest określenie optymalnego współczynnika dla aplikacji. Optymalny współczynnik maksymalizuje rpS, spełnia wymagania dotyczące opóźnień i unikaj kolejkowania. Ten współczynnik może służyć do dokładnego rozmiarowania punktu końcowego, aby sprostać najbardziej wymagającym obciążeniom.
Jeśli punkt końcowy nie może przetworzyć żądań wystarczająco szybko, wiersz zaczyna się formować. To nazywa się kolejką. Tworzenie kolejki zwykle powoduje znacznie dłuższe opóźnienie od początku do końca, ponieważ każde żądanie spędza dodatkowy czas, czekając na przetworzenie. Jeśli żądania będą nadal dostarczane szybciej niż żądania mogą być przetwarzane, kolejka rośnie, co dodatkowo zwiększa opóźnienie. Z tego powodu ważne jest, aby zrozumieć, jakiego rodzaju szczytowe zapotrzebowanie może wystąpić w punkcie końcowym i upewnić się, że ma on prawidłowy rozmiar przy użyciu testu obciążeniowego.
Przykłady scenariuszy testu obciążeniowego
W testach obciążeniowych, a także w rzeczywistych systemach relacja między współbieżnością klienta, współbieżnością serwera i opóźnieniem jest dynamiczna i współzależna. Zobaczmy tę relację z prostym przykładem:
Scenariusz 1. Prosta konfiguracja
W tej konfiguracji pojedynczy klient wysyła żądania sekwencyjnie — czeka na odpowiedź przed wysłaniem następnego żądania. Zmierzone opóźnienie końcowe wynosi 50 ms, ponieważ łączny czas na żądanie jest sumą wykonania modelu i narzutowego czasu opóźnienia (40 ms + 10 ms).
- Liczba klientów: 1
- Aprowizowana współbieżność: 1
- Opóźnienie narzutu: 10 ms
- Czas wykonywania modelu 40 ms
W rezultacie klient wykonuje jedno żądanie co 50 ms, co odpowiada 20 żądań na sekundę lub zapytania na sekundę.
Scenariusz 2. Zwiększenie aprowizowanej współbieżności
W takim przypadku masz dwukrotnie przydzieloną współbieżność oraz jednego klienta wysyłającego żądania sekwencyjnie. Oznacza to, że całkowite opóźnienie nadal wynosi 50 ms (40 ms + 10 ms), a system widzi tylko 20 żądań na sekundę (QPS).
- Liczba klientów: 1
- Aprowizowana współbieżność: 1–> 2
- Opóźnienie narzutu: 10 ms
- Czas wykonywania modelu 40 ms
Scenariusz 3. Dodawanie innego klienta do systemu.
Teraz masz dwóch klientów wysyłających żądania do punktu końcowego z dwiema przydzielonymi współbieżnościami. W takim przypadku każde żądanie klienta może być przetwarzane niezależnie przez punkt końcowy jednocześnie (przy założeniu idealnego równoważenia obciążenia). Mimo że całkowite opóźnienie nadal wynosi 50 ms (40 ms + 10 ms), system obserwuje 40 żądań na sekundę, ponieważ każdy klient wysyła 20 qps.
- Liczba klientów: 1–> 2
- Aprowizowana współbieżność: 2
- Opóźnienie narzutu: 10 ms
- Czas wykonywania modelu 40 ms
Zwiększenie przydzielonej współbieżności oraz liczby klientów wysyłających żądania zwiększa całkowitą liczbę zapytań na sekundę (QPS) obserwowanych w systemie, bez wpływu na opóźnienia.
Scenariusz 4. Pozwala zmniejszyć aprowizowaną współbieżność
W tym ostatnim scenariuszu liczba klientów jest większa niż aprowizowana współbieżność. Ta konfiguracja wprowadza inną zmienną, kolejkowanie w systemie i jej wpływ na QPS i opóźnienia.
- Liczba klientów: 2
- Aprowizowana współbieżność: 2–> 1
- Opóźnienie narzutu: 10 ms
- Czas wykonywania modelu: 40 ms
W tym miejscu masz dwóch klientów wysyłających żądania jednocześnie. Punkt końcowy może jednak przetwarzać tylko jedno żądanie jednocześnie. Drugie żądanie musi czekać, aż pierwsze żądanie zostanie przetworzone. Oczekiwanie lub bardziej poprawne kolejkowanie drugiego żądania może negatywnie wpłynąć na opóźnienie systemu. Zakładając, że serwer zezwala na kolejkowanie (domyślnie włączone w Model Serving Databricks), drugi klient widzi opóźnienie 90 ms: 10 ms (narzut sieciowy) + 40 ms (czas oczekiwania kolejkowania) + 40 ms (czas wykonywania modelu). Jest to znacznie gorsze niż 50 ms widziane wcześniej.