Wydajność i opóźnienie

W tym artykule omówiono sposób działania opóźnienia i przepływności z usługą Azure OpenAI oraz sposób optymalizacji środowiska w celu zwiększenia wydajności.

Informacje o przepływności a opóźnieniach

Istnieją dwie kluczowe pojęcia, które należy wziąć pod uwagę podczas określania rozmiaru aplikacji: (1) Przepływność na poziomie systemu mierzona w tokenach na minutę (TPM) i (2) czasy odpowiedzi na wywołanie (znane również jako opóźnienie).

Przepływność na poziomie systemu

Obejmuje to ogólną pojemność wdrożenia — liczbę żądań na minutę i łączną liczbę tokenów, które można przetworzyć.

W przypadku wdrożenia standardowego przydział przypisany do wdrożenia częściowo określa ilość przepływności, którą można osiągnąć. Jednak limit przydziału określa tylko logikę przyjmowania wywołań do wdrożenia i nie wymusza bezpośrednio przepływności. Ze względu na różnice opóźnienia poszczególnych wywołań możesz nie być w stanie osiągnąć przepływności tak wysokie, jak limit przydziału.

W ramach aprowizowanego wdrożenia do punktu końcowego jest przydzielana określona ilość mocy obliczeniowej na przetwarzanie modelu. Ilość przepływności, którą można osiągnąć w punkcie końcowym, jest czynnikiem kształtu obciążenia, w tym ilości tokenu wejściowego, ilości danych wyjściowych, szybkości wywołań i współczynnika dopasowania pamięci podręcznej. Liczba współbieżnych wywołań i łączna liczba przetworzonych tokenów może się różnić w zależności od tych wartości.

W przypadku wszystkich typów wdrożeń zrozumienie przepływności na poziomie systemu jest kluczowym składnikiem optymalizacji wydajności. Ważne jest, aby wziąć pod uwagę przepływność na poziomie systemu dla danego modelu, wersji i kombinacji obciążenia, ponieważ przepływność będzie się różnić w zależności od tych czynników.

Szacowanie przepływności na poziomie systemu

Szacowanie modułu TPM za pomocą metryk usługi Azure Monitor

Jedną z metod szacowania przepływności na poziomie systemu dla danego obciążenia jest użycie historycznych danych użycia tokenu. W przypadku obciążeń usługi Azure OpenAI dostęp do wszystkich historycznych danych użycia można uzyskać i zwizualizować za pomocą natywnych funkcji monitorowania oferowanych w ramach usługi Azure OpenAI. Do oszacowania przepływności na poziomie systemu dla obciążeń usługi Azure OpenAI potrzebne są dwie metryki: (1) Przetworzone tokeny monitu i (2) Wygenerowane tokeny ukończenia.

W połączeniu Przetworzone Tokeny Monitu (input TPM) i Wygenerowane Tokeny Ukończenia (wyjściowe TPM) zapewniają szacowany widok przepływności na poziomie systemu na podstawie rzeczywistego ruchu roboczego. Takie podejście nie uwzględnia korzyści z buforowania zapytań, dlatego będzie to konserwatywne oszacowanie przepływności systemu. Te metryki można analizować przy użyciu minimalnej, średniej i maksymalnej agregacji w 1-minutowych oknach w wielotygodniowym horyzoncie czasu. Zaleca się analizowanie tych danych w wielotygodniowym horyzoncie czasu w celu zapewnienia wystarczającej ilości punktów danych do oceny. Poniższy zrzut ekranu przedstawia przykład metryki Przetworzone tokeny monitu wizualizowane w usłudze Azure Monitor, która jest dostępna bezpośrednio za pośrednictwem witryny Azure Portal.

Szacowanie TPM na podstawie danych dotyczących żądań

Drugie podejście do szacowanej przepływności na poziomie systemu obejmuje zbieranie informacji o użyciu tokenu z danych żądania interfejsu API. Ta metoda zapewnia bardziej szczegółowe podejście do zrozumienia kształtu obciążenia na żądanie. Połączenie informacji o użyciu tokenu żądania z woluminem żądania mierzonym w żądaniach na minutę (RPM) zapewnia oszacowanie przepływności na poziomie systemu. Należy pamiętać, że wszelkie założenia dotyczące spójności informacji o użyciu tokenu w żądaniach i woluminie żądań będą mieć wpływ na szacowanie przepływności systemu. Dane wyjściowe dotyczące użycia tokenu można znaleźć w szczegółach odpowiedzi interfejsu API dla określonego modelu Azure OpenAI w żądaniu uzupełniania czatów w Microsoft Foundry Models.

{
  "body": {
    "id": "chatcmpl-7R1nGnsXO8n4oi9UPz2f3UHdgAYMn",
    "created": 1686676106,
    "choices": [...],
    "usage": {
      "completion_tokens": 557,
      "prompt_tokens": 33,
      "total_tokens": 590
    }
  }
}

Zakładając, że wszystkie żądania dla danego obciążenia są jednolite, tokeny zapytań i tokeny uzupełnień z danych odpowiedzi API można mnożyć przez szacowaną wartość RPM, aby określić wejściowy i wyjściowy TPM dla danego obciążenia.

Jak używać oszacowań przepływności na poziomie systemu

Po oszacowaniu przepływności na poziomie systemu dla danego obciążenia, te oszacowania mogą służyć do określenia rozmiaru wdrożeń standardowych i aprowizowanych. W przypadku wdrożeń w warstwie Standardowa wartości wejściowe i wyjściowe TPM można połączyć, aby oszacować całkowitą wartość TPM, którą należy przypisać do danego wdrożenia. W przypadku wdrożeń aprowizowanych dane użycia tokenu żądania lub wartości wejściowe i wyjściowe modułu TPM mogą służyć do oszacowania liczby jednostek PTU wymaganych do obsługi danego obciążenia przy użyciu środowiska kalkulatora wydajności wdrożenia.

Oto kilka przykładów dla mini modelu GPT-4o:

Liczba jednostek PTU skaluje się w przybliżeniu liniowo z współczynnikiem wywołań, gdy rozkład obciążenia pozostaje stały.

Opóźnienie: czas odpowiedzi na pojedyncze wywołanie

Wysoka definicja opóźnienia w tym kontekście to czas potrzebny na odzyskanie odpowiedzi z modelu. W przypadku żądań ukończenia i ukończenia czatu opóźnienie jest w dużej mierze zależne od typu modelu, liczby tokenów w wierszu polecenia i liczby wygenerowanych tokenów. Ogólnie rzecz biorąc, każdy token monitu dodaje niewiele czasu w porównaniu do każdego wygenerowanego tokenu przyrostowego.

Szacowanie oczekiwanego opóźnienia poszczególnych wywołań może być trudne w przypadku tych modeli. Opóźnienie żądania ukończenia może się różnić w zależności od czterech podstawowych czynników: (1) model, (2) liczba tokenów w wierszu polecenia, (3) liczba wygenerowanych tokenów i (4) całkowite obciążenie wdrożenia i systemu. Jeden i trzy są często głównymi składnikami całkowitego czasu. W następnej sekcji przedstawiono bardziej szczegółowe informacje na temat anatomii wywołania inferencji dużego modelu językowego.

Poprawa wydajności

Istnieje kilka czynników, które można kontrolować, aby zwiększyć opóźnienie poszczególnych wywołań aplikacji.

Wybór modelu

Opóźnienie zależy od używanego modelu. W przypadku identycznego żądania należy oczekiwać, że różne modele mają różne opóźnienia w realizacji czatu. Jeśli twój przypadek użycia wymaga najniższych modeli opóźnień z najszybszym czasem odpowiedzi, zalecamy najnowszy model GPT-4o mini.

Rozmiar generacji i maksymalne tokeny

Po wysłaniu żądania ukończenia do punktu końcowego usługi Azure OpenAI tekst wejściowy jest konwertowany na tokeny, które następnie są wysyłane do wdrożonego modelu. Model odbiera tokeny wejściowe, a następnie rozpoczyna generowanie odpowiedzi. Jest to iteracyjny proces sekwencyjny, jeden token naraz. Innym sposobem myślenia o tym jest pętla for z n tokens = n iterations. W przypadku większości modeli generowanie odpowiedzi jest najwolniejszym krokiem w procesie.

W momencie żądania żądany rozmiar generacji (max_tokens parametr) jest używany jako początkowe oszacowanie rozmiaru generacji. Czas obliczeniowy generowania pełnego rozmiaru jest zarezerwowany przez model podczas przetwarzania żądania. Gdy generowanie zostanie zakończone, pozostały limit zostanie zwolniony. Sposoby zmniejszenia liczby tokenów:

• Ustaw parametr max_tokens na jak najmniejszą wartość dla każdego wywołania.
• Uwzględnij sekwencje zatrzymania, aby zapobiec generowaniu dodatkowej zawartości.
• Generuj mniej odpowiedzi: parametry best_of i n mogą znacznie zwiększyć opóźnienie, ponieważ generują wiele danych wyjściowych. Aby uzyskać najszybszą odpowiedź, nie należy określać tych wartości ani ustawiać ich na 1.

Podsumowując, zmniejszenie liczby tokenów generowanych na żądanie zmniejsza opóźnienie każdego żądania.

Przesyłanie strumieniowe

Ustawienie stream: true w żądaniu powoduje, że usługa zwraca tokeny, gdy tylko są dostępne, zamiast czekać na wygenerowanie pełnej sekwencji tokenów. Nie zmienia czasu na pobranie wszystkich tokenów, ale skraca czas pierwszej odpowiedzi. Takie podejście zapewnia lepsze doświadczenie użytkownika, ponieważ użytkownicy końcowi mogą odczytywać odpowiedź w miarę jak jest generowana.

Przesyłanie strumieniowe jest również przydatne przy rozbudowanych rozmowach, które trwają długo. Wiele klientów i warstw pośredniczących ma limity czasu na poszczególne wywołania. Wywołania długiej generacji mogą zostać anulowane z powodu przekroczenia limitu czasu po stronie klienta. Przesyłając strumieniowo dane z powrotem, możesz upewnić się, że dane przyrostowe są odbierane.

Przykłady użycia przesyłania strumieniowego:

Czatboty i interfejsy konwersacyjne.

Przesyłanie strumieniowe ma wpływ na postrzegane opóźnienie. Po włączeniu przesyłania strumieniowego tokeny są odbierane z powrotem we fragmentach natychmiast po ich udostępniniu. Dla użytkowników końcowych takie podejście często sprawia wrażenie, że model reaguje szybciej, mimo że ogólny czas ukończenia żądania pozostaje taki sam.

Przykłady, gdy przesyłanie strumieniowe jest mniej ważne:

Analiza tonacji, tłumaczenie języka, generowanie zawartości.

Istnieje wiele przypadków użycia, w których wykonujesz kilka zadań zbiorczych, w których zależy tylko na gotowym wyniku, a nie odpowiedzi w czasie rzeczywistym. Jeśli przesyłanie strumieniowe jest wyłączone, nie otrzymasz żadnych tokenów, dopóki model nie zakończy całej odpowiedzi.

Filtrowanie zawartości

Usługa Azure OpenAI zawiera system filtrowania zawartości, który działa wraz z podstawowymi modelami. System ten działa poprzez uruchomienie zarówno komendy, jak i odpowiedzi przez grupę modeli klasyfikacyjnych mających na celu wykrywanie i zapobieganie generowaniu szkodliwych treści.

System filtrowania zawartości wykrywa i podejmuje działania dotyczące określonych kategorii potencjalnie szkodliwej zawartości w monitach wejściowych i kompletacjach danych wyjściowych.

Dodanie filtrowania zawartości wiąże się ze wzrostem bezpieczeństwa, ale także opóźnieniami. Istnieje wiele aplikacji, w których taki kompromis w wydajności jest konieczny, jednak istnieją pewne przypadki użycia o niższym ryzyku, gdzie wyłączenie filtrów zawartości w celu poprawy wydajności może być warte rozważenia.

Dowiedz się więcej o żądaniu modyfikacji domyślnych zasad filtrowania zawartości.

Rozdzielenie obciążeń

Mieszanie różnych obciążeń w tym samym punkcie końcowym może negatywnie wpłynąć na opóźnienie. Jest to spowodowane tym, że (1) są one grupowane razem podczas przetwarzania, a krótkie wywołania mogą czekać na dłuższe ukończenie i (2) mieszanie wywołań może zmniejszyć liczbę trafień w pamięci podręcznej, ponieważ oba konkurują o to samo miejsce. Jeśli to możliwe, zaleca się utrzymywanie oddzielnych wdrożeń dla każdego zadania roboczego.

Rozmiar zapytania

Chociaż rozmiar podpowiedzi ma mniejszy wpływ na opóźnienie niż rozmiar generacji, wpływa na całkowity czas przetwarzania, zwłaszcza gdy rozmiar staje się większy.

Pakietowanie

Jeśli wysyłasz wiele żądań do tego samego punktu końcowego, możesz podzielić żądania na pojedyncze wywołanie. Zmniejsza to liczbę żądań, które musisz złożyć i w zależności od scenariusza może poprawić ogólny czas odpowiedzi. Zalecamy przetestowanie tej metody, aby sprawdzić, czy pomaga.

Jak zmierzyć przepływność

Zalecamy pomiar ogólnej przepływności wdrożenia przy użyciu dwóch miar:

• Wywołania na minutę: liczba wywołań wnioskowania interfejsu API na minutę. Można to zmierzyć w Azure Monitor, korzystając z metryki Żądania Azure OpenAI i dzieląc według ModelDeploymentName.
• Łączna liczba tokenów na minutę: liczba tokenów przetwarzanych na minutę przez Twoje wdrożenie. Obejmuje to tokeny polecenia oraz wygenerowane. Często dzieli się to dalej, aby mierzyć oba aspekty dla dokładniejszego zrozumienia wydajności wdrożenia. Można to zmierzyć w Azure Monitor za pomocą metryki przetworzonych tokenów wnioskowania.

Aby dowiedzieć się więcej na temat monitorowania Azure OpenAI, zapoznaj się z materiałami.

Jak zmierzyć opóźnienie poszczególnych wywołań

Czas potrzebny na każde wywołanie zależy od tego, jak długo trwa odczytywanie modelu, generowanie danych wyjściowych i stosowanie filtrów zawartości. Sposób mierzenia czasu będzie się różnić, jeśli używasz przesyłania strumieniowego, czy nie. Sugerujemy inny zestaw miar dla każdego przypadku.

Aby dowiedzieć się więcej na temat monitorowania Azure OpenAI, zapoznaj się z materiałami.

Bez przesyłania strumieniowego:

• Końcowy czas przetwarzania żądania: łączny czas potrzebny na wygenerowanie całej odpowiedzi dla żądań bez strumieniowania, mierzony za pomocą bramy API. Ta liczba zwiększa się wraz ze wzrostem rozmiaru monitu i generowania.

Przesyłanie strumieniowe:

• Czas odpowiedzi: zalecana miara opóźnienia (czas odpowiedzi) dla żądań przesyłanych strumieniowo. Dotyczy PTU i wdrożeń zarządzanych przez PTU. Obliczono jako czas potrzebny na wyświetlenie pierwszej odpowiedzi po wysłaniu przez użytkownika monitu mierzonego przez bramę interfejsu API. Ta liczba zwiększa się wraz ze wzrostem rozmiaru monitu i/lub zmniejszeniem rozmiaru trafień.
• Średni czas generowania tokenu od pierwszego tokenu do ostatniego tokenu podzielony przez liczbę wygenerowanych tokenów mierzonych przez bramę interfejsu API. Mierzy to szybkość generowania odpowiedzi i zwiększa się wraz ze wzrostem obciążenia systemu. Zalecana miara opóźnienia dla żądań przesyłania strumieniowego.

Podsumowanie

• Opóźnienie modelu: jeśli opóźnienie modelu jest dla Ciebie ważne, zalecamy wypróbowanie modelu mini GPT-4o.

• Niższe maksymalne tokeny: OpenAI stwierdziło, że nawet w przypadkach, gdy łączna liczba wygenerowanych tokenów jest podobna, żądanie z wyższą wartością ustawioną dla parametru maksymalna liczba tokenów będzie miało większe opóźnienie.

• Mniejsza łączna liczba wygenerowanych tokenów: im mniej tokenów jest generowanych, tym szybsza będzie ogólna odpowiedź. Pamiętaj, że jest to tak, jakby pętla for miała wartość n tokens = n iterations. Obniż liczbę wygenerowanych tokenów i całkowity czas odpowiedzi poprawi się odpowiednio.

• Przesyłanie strumieniowe: włączenie przesyłania strumieniowego może być przydatne w zarządzaniu oczekiwaniami użytkowników w niektórych sytuacjach, umożliwiając użytkownikowi wyświetlanie odpowiedzi modelu podczas generowania zamiast czekać, aż ostatni token będzie gotowy.

• Filtrowanie zawartości zwiększa bezpieczeństwo, ale ma również wpływ na opóźnienie. Oceń, czy którekolwiek z obciążeń skorzystałoby ze zmodyfikowanych zasad filtrowania zawartości.