Važni linkovi
Kontrolna tabla stanja usluge (trenutno dostupno samo Enterprise API korisnicima)
Počnite s pravim zadanim postavkama
Kada otvorite kontrolnu tablu stanja usluge, ona se zadano postavlja na:
Sve projekte
Posljednjih 30 dana
Rezoluciju po satima
Ovaj prikaz je koristan samo za orijentaciju. Smisleno rješavanje problema uvijek zahtijeva filtriranje.
Filtrirajte prije istraživanja
Ispravno filtriranje je najvažniji korak. Većina pogrešnih tumačenja nastaje zbog miješanja modela, nivoa ili projekata.
Filtrirajte prema modelu (jedan po jedan)
Uvijek filtrirajte na jedan model.
Zašto:
Problemi na modelima s malim prometom mogu biti skriveni prometom većeg obima
Modeli velikog obima mogu učiniti da lokalizirani problemi izgledaju globalno
Različiti modeli imaju različite ciljeve performansi
Napomena: odabir više modela ih agregira — ne prebacuje između njih.
Filtrirajte prema nivou usluge
Ako koristite više od jednog nivoa (standardni, prioritetni, scale), uvijek filtrirajte na nivo koji istražujete.
Zašto:
Nivoi imaju različite karakteristike performansi
Prioritetni i scale nivoi imaju definisane SLA-ove
Miješanje nivoa prikriva performanse plaćenog nivoa
Ovo je posebno važno za analizu latencije.
Filtrirajte prema projektu
Stanje usluge zadano prikazuje sve projekte.
Za rješavanje problema filtrirajte na projekat/projekte gdje je problem uočen.
Zašto:
Jedan projekat velikog obima može dominirati metrikama.
Manji pogođeni projekti mogu biti prikriveni nepovezanim prometom.
Ostavite odabrano „Svi projekti” samo ako smatrate da je problem zaista na nivou cijele organizacije.
Rješavanje problema s greškama
Koristite prikaz HTTP zahtjeva
Za istraživanje grešaka:
Filtrirajte prema modelu i nivou usluge.
Otvorite karticu HTTP zahtjevi umjesto kartice Vrijeme rada.
Ovaj prikaz prikazuje ukupan broj zahtjeva i broj grešaka prema HTTP statusnom kodu. Zumirajte na rezoluciju po minutama da biste prepoznali detaljne skokove ili promjene.
Tumačite stope grešaka, ne brojeve
Neke greške se očekuju u svakom produkcijskom sistemu. Fokusirajte se na procenat grešaka, a ne na sirove ukupne vrijednosti.
Što je veći vaš ukupni obim, to je veći potencijalni broj grešaka čak i uz izuzetno nisku stopu grešaka.
Kada greške nedostaju u Stanju usluge
Ako vidite greške na strani klijenta, ali nema odgovarajućih podataka u Stanju usluge:
Zahtjevi vjerovatno nisu stigli do OpenAI-ja.
Problem je obično uzvodno (isteci vremena, proksiji, mreža).
Ovo je uobičajeno kod agresivnih isteka vremena na strani klijenta.
Rješavanje problema s latencijom
Analiza latencije je najkorisnija na prioritetnim i scale nivoima, koji imaju definisane SLA-ove. Standardni nivo može pokazivati veće varijacije latencije i nema zagarantovanu latenciju.
Ključne metrike
Za prikaz svake metrike kliknite relevantnu karticu:
Brzina tokena: tokeni generisani u sekundi; nezavisno od veličine upita.
Vrijeme zahtjeva: ukupno trajanje zahtjeva; snažno zavisi od veličine izlaza i rezonovanja.
Vrijeme do prvog tokena (TTFT): vrijeme do generisanja prvog tokena; snažno zavisi od veličine nekeširanog ulaznog upita i rezonovanja.
Uvijek pregledajte percentile P50 / P75 / P95. Prosjeci mogu sakriti uticaj na stvarne korisnike.
6. Koreliranje latencije s korištenjem tokena
Stanje usluge pokazuje kada se ponašanje promijenilo. Podaci o korištenju pomažu objasniti zašto.
Na kontrolnoj tabli korištenja uradite sljedeće kako biste osigurali da gledate podatke relevantne za vaš prikaz na kontrolnoj tabli stanja usluge:
Filtrirajte na isti projekat i model.
Grupišite prema nivou usluge, ako je primjenjivo.
Fokusirajte se na izlazne tokene, koji najviše utiču na latenciju.
Za dublju analizu izvezite podatke o aktivnostima i pregledajte tokene po zahtjevu tokom vremena.
7. Šta podijeliti s podrškom (ako je potrebno)
Ako kontaktirate podršku, uključite:
ID-ove pogođenih organizacija (važno)
Pogođene krajnje tačke, kao što su Chat Completions ili Responses (važno)
Pogođene modele (važno)
Da li je ovo na Scale ili Priority nivou (važno)
Vremenske raspone s vremenskom zonom za latenciju ili greške (važno)
Relevantan x-request-id ili X-Client-Request-Id, ako je dostupan
Vremenske oznake s vremenskom zonom, ili barem datum, za zahtjeve koje dostavljate
Ako je dostupno, uključite i:
ID projekta povezan sa zahtjevima
Da li su pogođeni zahtjevi za rezidentnost podataka i koji
Opise trendova koje vidite
Za vrstu problema uključite:
Greške: približan procenat neuspjelih zahtjeva ili zahtjeva s greškom, kodove odgovora, poruke o greškama i koliko je trebalo da se primi odgovor s greškom.
Latencija: koji percentili su pogođeni (P50 / P90 / P95 / P99), koliko su visoki u poređenju s korisnikovom osnovnom vrijednošću i primjere sporih zahtjeva s vremenskim oznakama slanja i primanja.
Oboje: snimke ekrana ili tabelu podataka o greškama ili latenciji, uz objašnjenje kako ste utvrdili da su stope grešaka ili latencija više od očekivanog.
Uobičajeni scenariji rješavanja problema
Dolazi do isteka vremena, ali Stanje usluge izgleda normalno
Mogući uzrok: zahtjevi ističu prije nego što stignu do OpenAI-ja.
Provjerite:
Postavke isteka vremena klijenta ili proksija
Promjene lokalne mreže ili balansera opterećenja
Prisustvo 499 grešaka na kontrolnoj tabli stanja usluge (one se u vašim sistemima mogu prikazati kao 5xx greške).
Latencija se povećala bez implementacije
Mogući uzrok: povećala se veličina izlaznih tokena ili korištenje rezonovanja i/ili se promet premjestio između nivoa usluge.
Provjerite:
Prosječan broj izlaznih tokena po zahtjevu na kontrolnoj tabli korištenja (zahtijeva preuzimanje podataka i dijeljenje izlaznih tokena ukupnim brojem zahtjeva).
Percentili vremena zahtjeva i TTFT-a na kontrolnoj tabli stanja usluge.
Priority ili Nivo skale izgleda sporo
Mogući uzrok: metrike su pomiješane između nivoa, što znači da promet standardnog nivoa prikriva performanse plaćenog nivoa.
Provjerite:
Filteri su ograničeni na jedan nivo i model.
Poređenje brzine tokena između nivoa.
Porast 5XX grešaka
Vjerovatni uzrok: privremeni kvarovi koji utiču na mali procenat prometa.
Provjerite:
Procenat stope grešaka
Da li se obim prometa promijenio u isto vrijeme
Problem utiče samo na jedan projekat
Vjerovatni uzrok: konfiguracija ili obrazac korištenja specifičan za projekat.
Provjerite:
Filtriranje na nivou projekta
Poređenje s projektima koji nisu pogođeni
Završni zaključci
Prije tumačenja metrika filtrirajte prema modelu, nivou i projektu gdje je relevantno.
Za analizu latencije koristite percentile, a ne prosjeke.
Male stope grešaka su očekivane.
Nedostajući podaci obično ukazuju na uzvodne probleme.
Podaci o korištenju mogu pomoći objasniti zašto se latencija promijenila; Stanje usluge pokazuje kada se ponašanje promijenilo.