Ważne linki
Panel stanu usługi (obecnie dostępny tylko dla klientów Enterprise API)
Zacznij od właściwych ustawień domyślnych
Po otwarciu panelu stanu usługi domyślnie ustawione są:
Wszystkie projekty
Ostatnie 30 dni
Rozdzielczość godzinowa
Ten widok jest przydatny tylko do orientacji. Sensowne rozwiązywanie problemów zawsze wymaga filtrowania.
Filtruj przed rozpoczęciem badania
Prawidłowe filtrowanie to najważniejszy krok. Większość błędnych interpretacji wynika z mieszania modeli, poziomów planu lub projektów.
Filtruj według modelu (pojedynczo)
Zawsze filtruj do pojedynczego modelu.
Dlaczego:
Problemy z modelami o niskim ruchu mogą być ukryte przez ruch o większym wolumenie
Modele o dużym wolumenie mogą sprawiać, że problemy lokalne 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 planu
Jeśli używasz więcej niż jednego poziomu planu (standardowego, priorytetowego, skalowanego), zawsze filtruj do poziomu, który badasz.
Dlaczego:
Poziomy planu mają różne charakterystyki wydajności
Poziomy priorytetowy i skalowany mają zdefiniowane umowy SLA
Mieszanie poziomów zaciemnia wydajność płatnego poziomu
Jest to szczególnie ważne przy analizie opóźnień.
Filtruj według projektu
Domyślnie stan usługi pokazuje wszystkie projekty.
Podczas rozwiązywania problemów filtruj do projektu lub projektów, w których zaobserwowano problem.
Dlaczego:
Jeden projekt o dużym wolumenie może zdominować metryki.
Mniejsze projekty, których dotyczy problem, mogą być maskowane przez niepowiązany ruch.
Pozostaw wybraną opcję „Wszystkie projekty” tylko wtedy, gdy uważasz, że problem rzeczywiście dotyczy całej organizacji.
Rozwiązywanie problemów z błędami
Użyj widoku żądań HTTP
Aby zbadać błędy:
Filtruj według modelu i poziomu planu.
Otwórz kartę Żądania HTTP zamiast karty Czas działania.
Ten widok pokazuje łączną liczbę żądań i liczbę błędów według kodu stanu HTTP. Powiększ do rozdzielczości minutowej, aby zidentyfikować szczegółowe skoki lub zmiany.
Interpretuj wskaźniki błędów, a nie liczby
W każdym systemie produkcyjnym należy spodziewać się pewnych błędów. Skup się na procentowym udziale błędów, a nie na surowych sumach.
Im większy łączny wolumen, tym większa potencjalna liczba błędów nawet przy wyjątkowo niskim wskaźniku błędów.
Gdy w stanie usługi brakuje błędów
Jeśli widzisz błędy po stronie klienta, ale brak odpowiadających im danych w stanie usługi:
Żądania prawdopodobnie nie dotarły do OpenAI.
Problem zwykle leży po stronie nadrzędnej (limity czasu, serwery proxy, sieć).
Jest to częste przy agresywnych limitach czasu po stronie klienta.
Rozwiązywanie problemów z opóźnieniami
Analiza opóźnień ma największe znaczenie na poziomach priorytetowym i skalowanym, które mają zdefiniowane umowy SLA. Poziom standardowy może wykazywać większą zmienność opóźnień i nie ma gwarantowanego opóźnienia.
Kluczowe metryki
Aby wyświetlić każdą metrykę, kliknij odpowiednią kartę:
Szybkość tokenów: tokeny generowane na sekundę; niezależna od rozmiaru polecenia.
Czas żądania: łączny czas trwania żądania; silnie zależy od rozmiaru danych wyjściowych i rozumowania.
Czas do pierwszego tokena (TTFT): czas do wygenerowania pierwszego tokena; silnie zależy od rozmiaru niebuforowanego polecenia wejściowego i rozumowania.
Zawsze sprawdzaj percentyle P50 / P75 / P95. Średnie mogą ukrywać rzeczywisty wpływ na użytkowników.
6. Korelowanie opóźnień z użyciem tokenów
Stan usługi pokazuje, kiedy zmieniło się zachowanie. Dane użycia pomagają wyjaśnić, dlaczego.
W panelu użycia wykonaj poniższe czynności, aby upewnić się, że oglądasz dane odpowiednie dla widoku w panelu stanu usługi:
Filtruj do tego samego projektu i modelu.
Grupuj według poziomu planu, jeśli ma to zastosowanie.
Skup się na tokenach wyjściowych, które najsilniej wpływają na opóźnienia.
Aby przeprowadzić głębszą analizę, wyeksportuj dane aktywności i sprawdź liczbę tokenów na żądanie w czasie.
7. Co udostępnić pomocy technicznej (w razie potrzeby)
Jeśli kontaktujesz się z pomocą techniczną, podaj:
Identyfikatory organizacji, których dotyczy problem (ważne)
Punkty końcowe, których dotyczy problem, takie jak Chat Completions lub Responses (ważne)
Modele, których dotyczy problem (ważne)
Czy dotyczy to oferty Skalowanej lub poziomu priorytetowego (ważne)
Zakresy czasu ze strefą czasową dla opóźnień lub błędów (ważne)
Odpowiednie x-request-id lub X-Client-Request-Id, jeśli są dostępne
Znaczniki czasu ze strefą czasową lub co najmniej data dla podanych żądań
Jeśli są dostępne, dołącz także:
Identyfikator projektu powiązany z żądaniami
Czy dotyczy to żądań rezydencji danych i których
Opisy obserwowanych trendów
Dla typu problemu podaj:
Błędy: przybliżony odsetek żądań zakończonych niepowodzeniem lub błędem, kody odpowiedzi, komunikaty o błędach oraz czas oczekiwania na odpowiedź z błędem.
Opóźnienie: których percentyli dotyczy problem (P50 / P90 / P95 / P99), jak wysokie są w porównaniu z poziomem bazowym klienta oraz przykłady wolnych żądań ze znacznikami czasu wysłania i odbioru.
Oba: zrzuty ekranu lub tabela danych błędów albo opóźnień, a także sposób ustalenia, że wskaźniki błędów lub opóźnienia były wyższe niż oczekiwano.
Typowe scenariusze rozwiązywania problemów
Występują limity czasu, ale stan usługi wygląda normalnie
Możliwa przyczyna: żądania przekraczają limit czasu przed dotarciem do OpenAI.
Sprawdź:
Ustawienia limitów czasu klienta lub serwera proxy
Zmiany w sieci lokalnej lub module równoważenia obciążenia
Obecność błędów 499 w panelu stanu usługi (w Twoich systemach mogą pojawiać się jako błędy 5xx).
Opóźnienie wzrosło bez wdrożenia
Możliwa przyczyna: zwiększył się rozmiar tokenów wyjściowych lub użycie rozumowania albo ruch przesunął się między poziomami planu.
Sprawdź:
Średnia liczba tokenów wyjściowych na żądanie w panelu użycia (wymaga pobrania danych i podzielenia tokenów wyjściowych przez łączną liczbę żądań).
Percentyle czasu żądania i TTFT w panelu stanu usługi.
Poziom priorytetowy lub oferta Skalowana wydaje się działać wolno
Możliwa przyczyna: metryki są mieszane między poziomami planu, co oznacza, że ruch z poziomu standardowego maskuje wydajność płatnego poziomu.
Sprawdź:
Filtry są ograniczone do jednego poziomu planu i modelu.
Porównanie szybkości tokenów między poziomami planu.
Wzrost liczby błędów 5XX
Prawdopodobna przyczyna: przejściowe awarie wpływające na niewielki odsetek ruchu.
Sprawdź:
Procentowy wskaźnik błędów
Czy w tym samym czasie zmienił się wolumen ruchu
Problem dotyczy tylko jednego projektu
Prawdopodobna przyczyna: konfiguracja lub wzorzec użycia specyficzne dla projektu.
Sprawdź:
Filtrowanie na poziomie projektu
Porównanie z projektami, których problem nie dotyczy
Najważniejsze wnioski
Przed interpretacją metryk filtruj według modelu, poziomu planu i projektu tam, gdzie ma to znaczenie.
Do analizy opóźnień używaj percentyli, a nie średnich.
Niewielkie wskaźniki błędów są oczekiwane.
Brakujące dane zwykle wskazują na problemy po stronie nadrzędnej.
Dane użycia mogą pomóc wyjaśnić, dlaczego opóźnienie się zmieniło; stan usługi pokazuje, kiedy zmieniło się zachowanie.