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ēšana pēc Pakalpojuma līmeņa
Ja izmantojat vairākus līmeņus (standarta, Ātro režīmu (iepriekš — prioritārā apstrāde), Mēroga līmeni), vienmēr atlasiet tikai analizējamo līmeni.
Kāpēc tas ir svarīgi:
Līmeņiem ir atšķirīgi veiktspējas raksturlielumi
Ātrajam režīmam un Mēroga līmenim ir noteikti SLA
Līmeņu apvienošana aizsedz maksas līmeņa veiktspēju
Tas ir īpaši svarīgi aizkaves analīzē.
Esošajiem modeļiem Ātrā režīma datplūsma Lietojuma informācijas panelī joprojām tiek rādīta kā prioritāra.
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ā.
Aizkaves problēmu novēršana
Aizkaves analīze ir visnoderīgākā Ātrā režīma un Mēroga līmeņa līmeņiem, kuriem ir noteikti SLA. Standarta līmenī aizkave var svārstīties vairāk un netiek garantēta.
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.
Aizkaves saistība ar tekstvienību lietojumu
Pakalpojuma stāvokļa panelis parāda, kad mainījās pakalpojuma darbība. Lietojuma dati palīdz izskaidrot, kāpēc.
Lietojuma informācijas panelī veiciet tālāk norādītās darbības, lai skatītu 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 attiecināms.
Pievērsiet uzmanību izvades tekstvienībām, jo tās visvairāk ietekmē aizkavi.
Lai veiktu padziļinātu analīzi, eksportējiet aktivitātes datus un izpētiet, kā laika gaitā mainās tekstvienību skaits vienā pieprasījumā.
Kādu informāciju sniegt atbalsta dienestam (ja nepieciešams)
Sazinoties ar atbalsta dienestu, norādiet:
Skarto organizāciju ID (svarīgi)
Skartos galapunktus, piemēram, Chat Completions vai Responses (svarīgi)
Skartos modeļus (svarīgi)
Vai tiek izmantots Ātrais režīms vai Mēroga līmenis (svarīgi)
Laika intervālus un laika joslu, kad novērota aizkave vai kļūdas (svarīgi)
Attiecīgo x-request-id vai X-Client-Request-Id, ja pieejams
Norādīto pieprasījumu laikspiedolus ar laika joslu vai vismaz datumu
Ja pieejams, iekļaujiet arī:
Ar pieprasījumiem saistītā projekta ID
Vai ir skarti pieprasījumi ar datu rezidences vietas prasībām un kuri tie ir
Novēroto tendenču aprakstus
Atkarībā no problēmas veida norādiet:
Kļūdas: aptuveno neveiksmīgo vai kļūdu izraisošo pieprasījumu īpatsvaru procentos, atbilžu kodus, kļūdu ziņojumus un to, cik ilgs laiks pagāja līdz kļūdas atbildes saņemšanai.
Aizkave: kuras procentiles ir ietekmētas (P50 / P90 / P95 / P99), cik augstas ir to vērtības salīdzinājumā ar klienta ierasto līmeni, kā arī lēnu pieprasījumu piemērus ar nosūtīšanas un saņemšanas laikspiedoliem.
Abos gadījumos: ekrānuzņēmumus vai tabulu ar kļūdu vai aizkaves datiem, kā arī to, kā noteicāt, ka kļūdu biežums vai aizkave pārsniedz gaidīto.
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ī.
Ātrais režīms vai Mēroga līmenis šķiet lēns
Iespējamais iemesls: dažādu līmeņu metrika ir apvienota, tāpēc standarta līmeņa datplūsma aizsedz maksas līmeņa veiktspēju.
Pārbaudiet:
Filtri attiecas tikai uz vienu līmeni un modeli.
Tekstvienību ģenerēšanas ātruma salīdzinājums 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.