Szybka demonstracja, wolna kolejka. Jak sprawdzić AI pod obciążeniem

Na pokazie odpowiedź zaczyna się niemal od razu. Kilka osób otwiera narzędzie jednocześnie i nagle pierwszy akapit każe na siebie czekać. Później pojawia się szybko, ale cała lista nadal nie jest gotowa. Zdanie „AI odpowiada w dwie sekundy” okazuje się zbyt pojemnym skrótem.

Pod obciążeniem trzeba osobno zobaczyć oczekiwanie przed wysłaniem, czas do pierwszej treści i czas do odebrania kompletnego wyniku. Potrzebny jest także rozkład pomiarów, bo dobra średnia nie opowie, jak długo czekają najwolniejsze sprawy. Próba ma dotyczyć konkretnego zadania i uzgodnionego środowiska, bez urządzania niespodziewanego testu wydolności działającej firmie.

Posłużmy się fikcyjnym asystentem przygotowującym podsumowania kart wyposażenia. Pracownik przesyła dokument i otrzymuje listę pięciu ustalonych informacji. Chcemy sprawdzić pracę jednej osoby oraz kilku osób wysyłających podobne zadania w tym samym czasie. Nie przedstawiamy tu wyniku pomiaru dostawcy. Przygotowujemy zakres próby, który wykonawca może przeprowadzić na uprawnionym środowisku.

Od którego momentu uruchamiasz stoper?

Zapisz drogę pojedynczego zadania. Pracownik wybiera materiał, aplikacja przyjmuje zlecenie, być może czeka na możliwość wysłania, a potem przekazuje żądanie do usługi. Dopiero później wraca pierwsza treść oraz reszta wyniku. Jeżeli zegar zaczyna się przy wywołaniu zewnętrznego API, nie obejmuje wcześniejszego oczekiwania w lokalnej kolejce.

Dokumentacja metryk GenAI-Perf rozdziela czas od wysłania żądania do pierwszej odpowiedzi oraz czas do odpowiedzi końcowej. Pokazuje również rozkłady i przepustowość. NVIDIA oznacza narzędzie jako stopniowo wycofywane, wskazując AIPerf dla nowych potrzeb; wykorzystujemy tu definicje pomiaru, nie zalecenie instalacji.

Na potrzeby naszego odbioru nazwij cztery chwile: przyjęcie zadania przez aplikację, wysłanie do usługi, odebranie pierwszej użytecznej treści oraz odebranie pełnej odpowiedzi. Zdefiniuj każdą z nich tak, żeby osoba mierząca wiedziała, co zapisuje. Pierwsza odpowiedź techniczna bez treści nie musi być momentem, w którym użytkownik ma już co czytać.

Własny pomiar widoku może dodatkowo objąć pokazanie treści na ekranie. Odbiór pierwszego fragmentu przez zaplecze i jego wyświetlenie nie są tą samą obserwacją. Jeżeli oceniasz doświadczenie pracownika, ustal także ten zakres. Nie porównuj czasu usługi z jednego raportu z czasem całej aplikacji w drugim i nie przypisuj różnicy samemu modelowi.

Microsoft w opisie wydajności i opóźnień Azure OpenAI wskazuje zależność czasu od modelu, długości wejścia, długości wyjścia i obciążenia. Zaleca wiązanie obserwacji czasu z liczbą tokenów. Token to jednostka tekstu używana przez model; nie należy utożsamiać jej z polskim słowem.

Dlatego przy każdym zadaniu zachowaj rozmiar wejścia i wyjścia w jednostce odpowiedniej dla pomiaru, dostępną konfigurację oraz status wykonania. W naszym przykładzie lista pięciu pól powinna mieć podobny zakres. Jeżeli po zmianie instrukcji asystent zamiast niej pisze wielostronicowy esej, dłuższy czas nie wyjaśnia jeszcze, czy zmieniła się sprawność wykonania tego samego zadania.

Granice kompletności rozwija odbiór strumienia odpowiedzi AI. Pierwszy tekst może pojawić się szybko i pozostać niepełny po przerwaniu. Nie wpisuj takiej próby do kolumny „wynik gotowy” na podstawie momentu pojawienia się pierwszego zdania. Czas i status muszą odwoływać się do tego samego etapu.

Jak zwiększać obciążenie, zachowując porównywalność?

Wybierz zestaw niepoufnych dokumentów o opisanym zakresie. Zadbaj o różne przypadki odpowiadające rzeczywistej pracy, lecz zachowaj ten sam materiał przy porównywaniu wariantów obciążenia. Przesyłanie jednego krótkiego zdania dla jednej osoby i długich plików dla większej grupy sprawdza dwie zmiany naraz.

Rozróżnij liczbę jednocześnie wykonywanych zadań od tempa nowych zleceń. W pierwszym wariancie próba utrzymuje określoną liczbę aktywnych żądań: nowe rozpoczyna się po zakończeniu poprzedniego. W drugim nowe zadania przychodzą według ustalonego rytmu niezależnie od tego, czy poprzednie zdążyły się zakończyć. Odpowiada to innym warunkom pracy.

Dla asystenta można przygotować stopniowe poziomy, na przykład jedną, trzy i sześć równoległych spraw. Są to robocze wartości przykładu, nie rekomendowana pojemność konkretnego konta. Osoba odpowiedzialna za środowisko uzgadnia dopuszczalny zakres, koszty, czas trwania i warunek przerwania. Test nie powinien zmieniać danych ani blokować zwykłej obsługi.

Zapisz również ruch z innych procesów korzystających z tej samej usługi lub limitu. Nocny import może zużywać wspólną przepustowość, choć na ekranie asystenta widać tylko kilku pracowników. Jeśli nie da się go odseparować, potraktuj go jako znany warunek próby. Bez tej informacji wynik trudno później porównać.

Rozgrzewkę i warunki pierwszego uruchomienia oznacz osobno. Część zadań może korzystać z wcześniej przygotowanych zasobów albo powtarzanego materiału. Nie usuwaj wolnych pierwszych prób tylko dlatego, że psują wykres, ani nie przedstawiaj serii identycznych wejść jako pełnego obrazu codziennej pracy. Zachowaj opis tego, co celowo powtarzano.

Sprawdź też, czy narzędzie wysyłające próbne zadania samo utrzymuje założony rytm. Jeśli nie nadąża tworzyć żądań, serwer dostaje mniejsze obciążenie od zaplanowanego. Raport powinien pokazać faktyczne momenty wysłania, nie wyłącznie ustawioną wartość. To kontrola wykonania próby, którą łatwo przeoczyć przy oglądaniu gotowej tabeli wyników.

Przy większej paczce pilnuj powiązania odpowiedzi z rekordami. Spóźnione zakończenie powinno nadal należeć do właściwego wejścia i próby. Szybki pomiar z zamienionymi odpowiedziami niczego użytecznego nie potwierdzi. Wymagania jakości pozostają aktywne także przy sprawdzaniu czasu.

Zachowaj powrót do mniejszego obciążenia po zakończeniu większej serii. Jeśli pierwsza próba dla jednej osoby była szybka, a późniejsza pojedyncza nadal czeka w zaległościach, raport powinien pokazać ten stan. Nie łącz jej bez opisu ze spokojnym początkiem. Kolejność serii i czas na rozliczenie wcześniejszych zadań są częścią warunków pomiaru. W przeciwnym razie dwa pozornie identyczne poziomy równoległości mogą odnosić się do innej sytuacji całego procesu.

Nie zwiększaj jednocześnie długości dokumentu, liczby narzędzi i obciążenia, jeżeli chcesz ustalić przyczynę różnicy. Możesz później sprawdzić realistyczne połączenie tych warunków jako osobny scenariusz. Na początku zmiana jednej rzeczy ułatwia zrozumienie, gdzie pojawia się kolejka i co faktycznie ogranicza odbiór.

Jak przeczytać czasy, żeby nie zgubić najwolniejszych spraw?

Zachowaj pojedyncze pomiary oraz podsumowania. Mediana pokazuje środek uporządkowanego zestawu, a odpowiednio zdefiniowany wysoki percentyl jego wolniejszą część. Podaj liczbę prób i metodę liczenia. Przy kilku obserwacjach pozornie precyzyjny percentyl nie daje wiedzy o stabilnym zachowaniu dużej usługi.

Prosty, wymyślony rachunek pokazuje ograniczenie średniej. Siedem zadań trwa po dwie sekundy, jedno osiemnaście. Średnia wynosi cztery sekundy. Nikt nie otrzymał wyniku właśnie po czterech sekundach, a jedna osoba czekała dziewięć razy dłużej od pozostałych. Zachowanie jej pomiaru pomaga zapytać o przyczynę, zamiast zagłaskać wyjątek przeciętną wartością.

Nie mieszaj różnych etapów w jednym rozkładzie. Osobno pokaż lokalną kolejkę, czas do pierwszej treści i czas do pełnej odpowiedzi. Może się okazać, że generowanie po rozpoczęciu pozostaje podobne, a rośnie oczekiwanie przed wysłaniem. To inny kierunek naprawy niż pogorszenie samego dopływu kolejnych fragmentów.

Przy wyniku błędnym zachowaj status i czas do jego rozpoznania. Nie licz szybkiej odmowy lub błędu limitu jako sprawnie zakończonego zadania. Jeśli pomiary sukcesów wykluczają niepowodzenia, pokaż to jawnie oraz podaj ich liczbę. Inaczej przeciążone rozwiązanie może wyglądać szybciej, bo na wiele pytań natychmiast przestaje odpowiadać.

Dokumentacja NVIDIA o goodput opisuje liczbę zakończonych żądań na sekundę spełniających wskazane ograniczenia metryk. To odrębny wynik od ogólnej przepustowości. Progi w przykładach dokumentacji są demonstracyjne; firma musi ustalić własne warunki użyteczności.

W naszym zadaniu taki warunek może obejmować odebranie pełnej listy w uzgodnionym czasie. Nadal osobno sprawdzamy, czy pięć pól ma poprawną treść. Sam warunek czasu nie ustanawia merytorycznej jakości. Raport może więc pokazać zakończenia w terminie, zakończenia spóźnione i wyniki odrzucone po kontroli.

Przy odpowiedzi API 429, oznaczającej ograniczenie liczby żądań, przejdź do wspólnego budżetu API i działania kolejki. W tym przeglądzie zapisz odpowiedź oraz dalsze oczekiwanie, bez automatycznego mnożenia prób dla poprawienia wyniku. Próba wydajności i projekt obsługi ograniczeń są powiązane, lecz nie powinny ukrywać wzajemnie swoich kosztów.

Nie porównuj samego tempa tokenów, jeśli zmieniła się użyteczność odpowiedzi. Krótszy, lecz niekompletny tekst może powstać szybciej. Właściciel zadania potrzebuje czasu do właściwego wyniku. W pomiarze pracy z AI dochodzi potem czas kontroli i poprawek; nie jest on zawarty w samym pomiarze usługi.

Co zrobić z wynikiem próby?

Jeżeli kolejka rośnie przy wybranym napływie, opisz ten zakres zamiast ogłaszać jedną pojemność całego AI. Wynik dotyczy materiału, konfiguracji i warunków, które rzeczywiście sprawdzono. Zmiana długości odpowiedzi, modelu lub wspólnego ruchu może zmienić obserwację. Zachowaj dane potrzebne do odtworzenia porównania.

Przygotuj decyzję operacyjną: ograniczyć równoległość, przesunąć mniej pilne paczki, zmienić zakres odpowiedzi albo skierować określone zadania inną drogą. Każda propozycja wymaga własnego sprawdzenia. Nie wnioskuj z jednego przeciążenia, że wymiana modelu jest jedynym rozwiązaniem, ani że dodatkowe ponowienia same rozładują kolejkę.

Sprawdź zachowanie po ustaniu napływu. Jak długo pozostają zaległości? Czy nowe, krótkie sprawy czekają za długimi? Czy użytkownik widzi, że jego zadanie nadal jest przyjęte? Przy planowaniu reakcji przyda się ciągłość pracy po awarii AI. Nadmierne oczekiwanie także może wymagać świadomego przejęcia pracy.

Do odbioru dodaj zlecenie, z którego użytkownik rezygnuje podczas czekania. Ustal, czy znika tylko widok, czy faktycznie zatrzymano dalsze wykonanie. Oczekująca w tle praca może nadal zużywać dostępne zasoby i wpływać na pozostałe pomiary. Zachowaj jej status w liczniku zleceń. Usunięcie takiej pozycji wyłącznie z raportu nie usuwa jej z procesu. Po zakończeniu próby rozlicz również te zadania, żeby kolejne uruchomienie nie zaczęło się od nieopisanych zaległości.

Do rozmowy z Aeneia Audit przygotuj opis jednego zadania, typowy materiał i informację o innych procesach używających tej samej usługi. Taki zestaw pozwala nazwać pytanie, które warto zmierzyć. Nie trzeba zaczynać od obietnicy obsłużenia dowolnej liczby pracowników.

Raport zakończ wynikami dla poszczególnych warunków, liczbą niepowodzeń, ograniczeniami pomiaru i wybraną następną czynnością. Dwie sekundy z demonstracji mogą nadal być poprawną obserwacją jednej próby. Firma potrzebuje jeszcze wiedzieć, co dzieje się, kiedy do pokoju wchodzi reszta zespołu.