Svarīgas saites
Pakalpojuma stāvokļa informācijas panelis (pašlaik pieejams tikai Enterprise API klientiem)
Sāciet ar pareizajiem noklusējumiem
Atverot Pakalpojuma stāvokļa informācijas paneli, pēc noklusējuma tiek rādīts:
Visi projekti
Pēdējās 30 dienas
Stundas izšķirtspēja
Šis skats ir noderīgs tikai orientācijai. Jēgpilnai problēmu novēršanai vienmēr ir nepieciešama filtrēšana.
Filtrējiet pirms izmeklēšanas
Pareiza filtrēšana ir vissvarīgākais solis. Lielākā daļa nepareizu interpretāciju rodas, sajaucot modeļus, līmeņus vai projektus.
Filtrējiet pēc modeļa (pa vienam)
Vienmēr filtrējiet līdz vienam modelim.
Kāpēc:
Problēmas modeļos ar mazu datplūsmu var paslēpties aiz lielāka apjoma datplūsmas
Liela apjoma modeļi var radīt iespaidu, ka lokalizētas problēmas ir globālas
Dažādiem modeļiem ir atšķirīgi veiktspējas mērķi
Piezīme: atlasot vairākus modeļus, tie tiek apkopoti — sistēma nepārslēdzas starp tiem.
Filtrējiet pēc pakalpojuma līmeņa
Ja izmantojat vairāk nekā vienu līmeni (standarta, prioritāro, mēroga), vienmēr filtrējiet līdz līmenim, kuru izmeklējat.
Kāpēc:
Līmeņiem ir atšķirīgas veiktspējas īpašības
Prioritārajam un mēroga līmenim ir definēti SLA
Līmeņu sajaukšana aizsedz maksas līmeņa veiktspēju
Tas ir īpaši svarīgi latentuma analīzei.
Filtrējiet pēc projekta
Pēc noklusējuma Pakalpojuma stāvoklis rāda visus projektus.
Problēmu novēršanai filtrējiet līdz projektam(-iem), kurā(-os) problēma tika novērota.
Kāpēc:
Viens liela apjoma projekts var dominēt metrikā.
Mazākus ietekmētos projektus var aizsegt nesaistīta datplūsma.
Atstājiet atlasītu “Visi projekti” tikai tad, ja uzskatāt, ka problēma patiešām skar visu organizāciju.
Kļūdu novēršana
Izmantojiet HTTP pieprasījumu skatu
Lai izmeklētu kļūdas:
Filtrējiet pēc modeļa un pakalpojuma līmeņa.
Atveriet cilni HTTP Requests, nevis cilni Uptime.
Šis skats rāda kopējo pieprasījumu skaitu un kļūdu skaitu pēc HTTP statusa koda. Pietuviniet līdz minūtes izšķirtspējai, lai noteiktu detalizētus pīķus vai izmaiņas.
Interpretējiet kļūdu rādītājus, nevis skaitu
Jebkurā ražošanas sistēmā dažas kļūdas ir sagaidāmas. Koncentrējieties uz kļūdu procentuālo īpatsvaru, nevis neapstrādātām kopējām vērtībām.
Jo lielāks ir kopējais apjoms, jo lielāks var būt kļūdu skaits pat ar ārkārtīgi zemu kļūdu rādītāju.
Kad kļūdas nav redzamas Pakalpojuma stāvoklī
Ja redzat klienta puses kļūdas, bet Pakalpojuma stāvoklī nav atbilstošu datu:
Pieprasījumi, visticamāk, nesasniedza OpenAI.
Problēma parasti ir augšupstraumē (taimauti, starpniekserveri, tīklošana).
Tas ir bieži sastopams agresīvu klienta puses taimautu gadījumā.
Latentuma problēmu novēršana
Latentuma analīze ir visjēgpilnākā prioritārajā un mēroga līmenī, kam ir definēti SLA. Standarta līmenī latentuma svārstības var būt lielākas, un tam nav garantēta latentuma.
Galvenās metrikas
Lai skatītu katru metriku, noklikšķiniet uz attiecīgās cilnes:
Tekstvienību ātrums: tekstvienības, kas ģenerētas sekundē; nav atkarīgs no uzvednes lieluma.
Pieprasījuma laiks: kopējais pieprasījuma ilgums; to būtiski ietekmē izvades lielums un spriestspēja.
Laiks līdz pirmajai tekstvienībai (TTFT): laiks līdz pirmās tekstvienības ģenerēšanai; to būtiski ietekmē kešatmiņā neglabātas ievades uzvednes lielums un spriestspēja.
Vienmēr pārskatiet P50 / P75 / P95 procentiles. Vidējās vērtības var slēpt ietekmi uz reāliem lietotājiem.
6. Latentuma korelācija ar tekstvienību lietojumu
Pakalpojuma stāvoklis rāda, kad uzvedība mainījās. Lietojuma dati palīdz izskaidrot, kāpēc.
Lietojuma informācijas panelī veiciet tālāk norādītās darbības, lai pārliecinātos, ka skatāt datus, kas atbilst jūsu skatam Pakalpojuma stāvokļa informācijas panelī:
Filtrējiet pēc tā paša projekta un modeļa.
Grupējiet pēc pakalpojuma līmeņa, ja piemērojams.
Koncentrējieties uz izvades tekstvienībām, kas visvairāk ietekmē latentumu.
Dziļākai analīzei eksportējiet darbību datus un laika gaitā pārbaudiet tekstvienības uz pieprasījumu.
7. Ko kopīgot ar atbalsta dienestu (ja nepieciešams)
Ja sazināties ar atbalsta dienestu, iekļaujiet:
Ietekmētos organizācijas ID (svarīgi)
Ietekmētos galapunktus, piemēram, Chat Completions vai Responses (svarīgi)
Ietekmētos modeļus (svarīgi)
Vai tas notiek Mēroga vai Prioritārajā līmenī (svarīgi)
Laika diapazonus ar laika joslu latentumam vai kļūdām (svarīgi)
Atbilstošo x-request-id vai X-Client-Request-Id, ja pieejams
Laikspiedolus ar laika joslu vai vismaz datumu pieprasījumiem, kurus sniedzat
Ja pieejams, iekļaujiet arī:
Ar pieprasījumiem saistīto projekta ID
Vai ir ietekmēti datu rezidences vietas pieprasījumi un kuri no tiem
Redzamo tendenču aprakstus
Problēmas tipam iekļaujiet:
Kļūdas: aptuveno neveiksmīgo vai kļūdaino pieprasījumu procentuālo īpatsvaru, atbildes kodus, kļūdu ziņojumus un laiku, kas bija nepieciešams, lai saņemtu kļūdas atbildi.
Latentums: kuras procentiles ir ietekmētas (P50 / P90 / P95 / P99), cik augstas tās ir salīdzinājumā ar klienta bāzes līmeni, un lēnu pieprasījumu piemērus ar nosūtīšanas un saņemšanas laikspiedoliem.
Abi: kļūdu vai latentuma datu ekrānuzņēmumus vai tabulu, kā arī to, kā noteicāt, ka kļūdu rādītāji vai latentums bija augstāki nekā gaidīts.
Bieži problēmu novēršanas scenāriji
Rodas taimauti, bet Pakalpojuma stāvoklis izskatās normāls
Iespējamais cēlonis: pieprasījumiem iestājas taimauts, pirms tie sasniedz OpenAI.
Pārbaudiet:
Klienta vai starpniekservera taimauta iestatījumus
Vietējā tīkla vai slodzes balansētāja izmaiņas
499 kļūdu esamību Pakalpojuma stāvokļa informācijas panelī (jūsu sistēmās tās var parādīties kā 5xx kļūdas).
Latentums palielinājās bez izvietošanas
Iespējamais cēlonis: palielinājās izvades tekstvienību apjoms vai spriestspējas izmantošana un/vai datplūsma pārvietojās starp pakalpojuma līmeņiem.
Pārbaudiet:
Vidējo izvades tekstvienību skaitu uz pieprasījumu Lietojuma informācijas panelī (nepieciešams lejupielādēt datus un dalīt izvades tekstvienības ar kopējo pieprasījumu skaitu).
Request Time un TTFT procentiles Pakalpojuma stāvokļa informācijas panelī.
Prioritārais vai Mēroga līmenis šķiet lēns
Iespējamais cēlonis: metrika ir sajaukta starp līmeņiem, tāpēc standarta līmeņa datplūsma aizsedz maksas līmeņa veiktspēju.
Pārbaudiet:
Filtri ir ierobežoti līdz vienam līmenim un modelim.
Tekstvienību ātruma salīdzinājumu starp līmeņiem.
5XX kļūdu pieaugums
Iespējamais cēlonis: īslaicīgas kļūmes, kas ietekmē nelielu datplūsmas daļu.
Pārbaudiet:
Kļūdu procentuālo īpatsvaru
Vai vienlaikus mainījās datplūsmas apjoms
Problēma ietekmē tikai vienu projektu
Iespējamais cēlonis: projektam specifiska konfigurācija vai lietojuma modelis.
Pārbaudiet:
Filtrēšanu projekta līmenī
Salīdzinājumu ar neskartiem projektiem
Galvenie secinājumi
Pirms metrikas interpretēšanas, kur tas ir būtiski, filtrējiet pēc modeļa, līmeņa un projekta.
Latentuma analīzei izmantojiet procentiles, nevis vidējās vērtības.
Nelieli kļūdu rādītāji ir sagaidāmi.
Trūkstoši dati parasti norāda uz augšupstraumes problēmām.
Lietojuma dati var palīdzēt izskaidrot, kāpēc latentums mainījās; Pakalpojuma stāvoklis rāda, kad uzvedība mainījās.