Ważne linki
*Pulpit Kondycja usługi jest obecnie dostępny tylko dla klientów Enterprise API.
Zacznij od właściwych ustawień domyślnych
Po otwarciu pulpitu Kondycja usługi domyślnie ustawione są:
Wszystkie projekty
Ostatnie 30 dni
Rozdzielczość godzinowa
Ten widok jest przydatny tylko do orientacji. Skuteczne rozwiązywanie problemów zawsze wymaga filtrowania.
Filtruj przed rozpoczęciem analizy
Prawidłowe filtrowanie to najważniejszy krok. Większość błędnych interpretacji wynika z mieszania modeli, poziomów lub projektów.
Filtruj według modelu (po jednym naraz)
Zawsze filtruj do jednego modelu.
Dlaczego:
Problemy w modelach o małym ruchu mogą zostać ukryte przez ruch o większym wolumenie
Modele o dużym wolumenie mogą sprawiać, że lokalne problemy wyglądają na globalne
Różne modele mają różne cele wydajnościowe
Uwaga: wybranie wielu modeli agreguje je — nie przełącza między nimi.
Filtruj według poziomu usługi
Jeśli używasz więcej niż jednego poziomu (standard, priority, scale), zawsze filtruj do poziomu, który analizujesz.
Dlaczego:
Poziomy mają różne charakterystyki wydajności
Poziomy priority i scale mają zdefiniowane umowy SLA
Mieszanie poziomów zaciemnia wydajność płatnych poziomów
Jest to szczególnie ważne przy analizie opóźnień.
Filtruj według projektu
Domyślnie Kondycja usługi pokazuje wszystkie projekty.
Podczas rozwiązywania problemów filtruj do projektu lub projektów, w których zaobserwowano problem.
Dlaczego:
Pojedynczy projekt o dużym wolumenie może dominować w metrykach
Mniejsze projekty, których dotyczy problem, mogą zostać ukryte przez niezwiązany ruch
Pozostaw wybrane tylko "Wszystkie projekty", jeśli uważasz, że problem rzeczywiście dotyczy całej organizacji.
Rozwiązywanie problemów z błędami
Użyj widoku Żądania HTTP
Aby przeanalizować błędy:
Filtruj według modelu i poziomu
Aby przełączyć z Czasu działania na Żądania HTTP, kliknij kartę Żądania HTTP
Ten widok pokazuje łączną liczbę żądań i liczbę błędów według kodu statusu HTTP. Przybliż do rozdzielczości minutowej, aby zidentyfikować szczegółowe skoki lub zmiany.
Interpretuj wskaźniki błędów, a nie liczby
Niektóre błędy są oczekiwane w każdym systemie produkcyjnym. Skup się na procentowym poziomie błędów, a nie na surowych sumach.
Im większy całkowity wolumen, tym większa potencjalna liczba błędów nawet przy bardzo niskim wskaźniku błędów.
Gdy w Kondycji usługi brakuje błędów
Jeśli widzisz błędy po stronie klienta, ale nie ma odpowiadających im danych w Kondycji usługi:
Żądania prawdopodobnie nie dotarły do OpenAI
Problem zwykle leży po stronie upstream (limity czasu, proxy, sieć)
Jest to częste przy agresywnych limitach czasu po stronie klienta.
Rozwiązywanie problemów z opóźnieniami
Analiza opóźnień jest najbardziej miarodajna w poziomach priority i scale, które mają zdefiniowane umowy SLA. Poziom standard może wykazywać większe zróżnicowanie opóźnień i nie ma gwarantowanego opóźnienia.
Kluczowe metryki
Aby wyświetlić każdą z tych metryk, kliknij odpowiednią kartę:
Prędkość tokenów
Tokeny generowane na sekundę.
Niezależna od rozmiaru polecenia.
Czas żądania
Łączny czas trwania żądania.
Silnie zależny od rozmiaru danych wyjściowych i rozumowania.
Czas do pierwszego tokena (TTFT)
Czas do wygenerowania pierwszego tokena.
Silnie zależny od rozmiaru niebuforowanego wejściowego polecenia i rozumowania.
Zawsze sprawdzaj percentyle P50 / P75 / P95. Średnie mogą ukrywać wpływ na rzeczywistych użytkowników.
6. Korelowanie opóźnień z użyciem tokenów
Kondycja usługi pokazuje, kiedy zmieniło się zachowanie. Dane użycia pomagają wyjaśnić, dlaczego.
Na pulpicie Użycie wykonaj poniższe czynności, aby upewnić się, że patrzysz na dane istotne dla widoku na pulpicie Kondycja usługi:
Filtruj według tego samego projektu i modelu
Grupuj według poziomu usługi , jeśli dotyczy
Skup się na tokenach wyjściowych, które najsilniej wpływają na opóźnienie
Aby przeprowadzić głębszą analizę, wyeksportuj dane aktywności i przeanalizuj liczbę tokenów na żądanie w czasie.
7. Co przekazać zespołowi wsparcia (w razie potrzeby)
Jeśli skontaktujesz się ze wsparciem, podaj:
Identyfikatory organizacji, których dotyczy problem (to ważne)
Punkty końcowe, których dotyczy problem (Chat Completions, Responses itp.) (to ważne)
Modele, których dotyczy problem (to ważne)
Czy dotyczy to poziomu scale czy priority? (to ważne)
Zakresy czasu ze strefą czasową dla opóźnień lub błędów (to ważne)
Odpowiednie x-request-id lub X-Client-Request-Id (często ważne; dołącz, jeśli to możliwe)
Znaczniki czasu ze strefą czasową (lub przynajmniej data) podanych żądań
Opóźnienie — jeśli podajesz przykłady wolnych żądań, podaj, ile to trwało po Twojej stronie. Najlepiej dołącz także znaczniki czasu wysłania i odebrania żądania.
Błędy — podaj przybliżony procent nieudanych/błędnych żądań, kody odpowiedzi, komunikaty o błędach oraz czas potrzebny na otrzymanie odpowiedzi z błędem
Identyfikator projektu powiązany z żądaniami
Czy ma to wpływ na żądania związane z rezydencją danych? Jeśli tak, które?
Opisy obserwowanych trendów
Błędy: Przybliżony % nieudanych/błędnych żądań
Opóźnienie: Które percentyle są dotknięte problemem (p50 / p90 / p95 / p99) i jak wysokie są w porównaniu z poziomem bazowym klienta
Oba: Zrzuty ekranu lub tabela z danymi o błędach albo opóźnieniach (Jak ustalono, że wskaźniki błędów lub opóźnienie są wyższe niż oczekiwano?)
Typowe scenariusze rozwiązywania problemów
Występują limity czasu, ale Kondycja usługi wygląda normalnie
Możliwa przyczyna: żądania przekraczają limit czasu, zanim dotrą do OpenAI.
Sprawdź:
Ustawienia limitu czasu klienta lub proxy
Lokalną sieć lub zmiany w load balancerze
Obecność błędów 499 na pulpicie Kondycja usługi (mogą one pojawiać się jako błędy 5xx w Twoich własnych systemach).
Opóźnienie wzrosło bez wdrożenia
Możliwa przyczyna: wzrósł rozmiar tokenów wyjściowych lub użycie rozumowania i\or ruch przesunął się między poziomami usługi
Sprawdź:
Średnią liczbę tokenów wyjściowych na żądanie na pulpicie Użycie (wymaga pobrania danych i podzielenia liczby tokenów wyjściowych przez łączną liczbę żądań).
Percentyle czasu żądania i TTFT na pulpicie Kondycja usługi.
Poziom Priority lub Scale wydaje się wolny
Możliwa przyczyna: metryki są mieszane między poziomami (co oznacza, że ruch poziomu standard maskuje wydajność płatnego poziomu)
Sprawdź:
Filtry są ograniczone do jednego poziomu i modelu
Porównanie prędkości tokenów między poziomami
Skok liczby błędów 5XX
Prawdopodobna przyczyna: przejściowe awarie wpływające na niewielki procent ruchu.
Sprawdź:
Procentowy wskaźnik błędów
Czy wolumen ruchu zmienił się w tym samym czasie
Problem dotyczy tylko jednego projektu
Prawdopodobna przyczyna: konfiguracja projektu lub wzorzec użycia specyficzny dla projektu.
Sprawdź:
Filtrowanie na poziomie projektu
Porównanie z projektami, których problem nie dotyczy
Najważniejsze wnioski
Filtruj według modelu, poziomu i — tam, gdzie to istotne — projektu przed interpretacją metryk
W analizie opóźnień używaj percentyli, a nie średnich
Niewielkie wskaźniki błędów są oczekiwane
Brak danych zwykle wskazuje na problemy upstream
Dane użycia mogą pomóc wyjaśnić, dlaczego opóźnienie się zmieniło; Kondycja usługi pomaga pokazać, kiedy