Dôležité odkazy
Informačný panel stavu služby (momentálne dostupný iba pre podnikových zákazníkov API)
Začnite so správnymi predvolenými nastaveniami
Keď otvoríte informačný panel Service Health, predvolene zobrazuje:
Všetky projekty
Posledných 30 dní
Hodinové rozlíšenie
Toto zobrazenie je užitočné iba na orientáciu. Zmysluplné riešenie problémov vždy vyžaduje filtrovanie.
Filtrujte pred vyšetrovaním
Správne filtrovanie je najdôležitejší krok. Väčšina nesprávnych interpretácií vzniká miešaním modelov, úrovní alebo projektov.
Filtrovať podľa modelu (po jednom)
Vždy filtrujte na jeden model.
Prečo:
Problémy pri modeloch s nízkou prevádzkou môže skryť prevádzka s vyšším objemom
Modely s vysokým objemom môžu spôsobiť, že lokálne problémy vyzerajú ako globálne
Rôzne modely majú rôzne výkonnostné ciele
Poznámka: výber viacerých modelov ich agreguje – neprepína medzi nimi.
Filtrovanie podľa úrovne služby
Ak používate viac než jednu úroveň (štandardnú, rýchly režim – predtým Priority processing – alebo úroveň škálovania), vždy filtrujte podľa úrovne, ktorú skúmate.
Prečo:
Úrovne majú odlišné výkonnostné charakteristiky
Rýchly režim a úroveň škálovania majú stanovené SLA
Miešanie úrovní skresľuje výkon platenej úrovne
Je to obzvlášť dôležité pri analýze latencie.
Pri existujúcich modeloch sa prevádzka rýchleho režimu na paneli Usage naďalej zobrazuje ako „priority“.
Filtrovať podľa projektu
Service Health predvolene zobrazuje všetky projekty.
Pri riešení problémov filtrujte na projekt(y), v ktorých bol problém pozorovaný.
Prečo:
Jeden projekt s vysokým objemom môže dominovať metrikám.
Menšie ovplyvnené projekty môžu byť zakryté nesúvisiacou prevádzkou.
Výber „Všetky projekty“ nechajte iba vtedy, ak sa domnievate, že problém sa skutočne týka celej organizácie.
Riešenie problémov s chybami
Použite zobrazenie požiadaviek HTTP
Na preskúmanie chýb:
Filtrujte podľa modelu a úrovne služby.
Otvorte kartu Požiadavky HTTP namiesto karty Dostupnosť.
Toto zobrazenie ukazuje celkový počet požiadaviek a počty chýb podľa stavového kódu HTTP. Priblížte zobrazenie na rozlíšenie po minútach, aby ste identifikovali podrobné špičky alebo zmeny.
Interpretujte mieru chýb, nie počty
V každom produkčnom systéme sa niektoré chyby očakávajú. Zamerajte sa na percento chýb, nie na hrubé súčty.
Čím väčší je váš celkový objem, tým väčší môže byť počet chýb aj pri mimoriadne nízkej miere chýb.
Keď v Service Health chýbajú chyby
Ak vidíte chyby na strane klienta, ale v Service Health nie sú žiadne zodpovedajúce údaje:
Požiadavky pravdepodobne nedorazili do OpenAI.
Problém je zvyčajne upstream (časové limity, proxy servery, sieťové pripojenie).
Je to bežné pri agresívnych časových limitoch na strane klienta.
Riešenie problémov s latenciou
Analýza latencie má najväčšiu výpovednú hodnotu pri úrovniach rýchly režim a úroveň škálovania, ktoré majú stanovené SLA. Štandardná úroveň môže vykazovať väčšie rozdiely v latencii a nemá garantovanú latenciu.
Kľúčové metriky
Ak chcete zobraziť jednotlivé metriky, kliknite na príslušnú kartu:
Rýchlosť tokenov: tokeny generované za sekundu; nezávisí od veľkosti príkazu.
Čas požiadavky: celkové trvanie požiadavky; výrazne ho ovplyvňuje veľkosť výstupu a uvažovanie.
Čas do prvého tokenu (TTFT): čas, kým sa vygeneruje prvý token; výrazne ho ovplyvňuje veľkosť neuloženého vstupného príkazu a uvažovanie.
Vždy kontrolujte percentily P50 / P75 / P95. Priemery môžu skryť vplyv na skutočných používateľov.
Súvislosť medzi latenciou a využitím tokenov
Stav služby ukazuje, kedy sa správanie zmenilo. Údaje o využití pomáhajú vysvetliť, prečo.
Ak chcete na paneli Využitie zobraziť údaje zodpovedajúce vášmu zobrazeniu na paneli Stav služby, postupujte takto:
Filtrujte podľa rovnakého projektu a modelu.
V prípade potreby zoskupte údaje podľa úrovne služby.
Zamerajte sa na výstupné tokeny, ktoré najviac ovplyvňujú latenciu.
Ak chcete vykonať podrobnejšiu analýzu, exportujte údaje o aktivite a preskúmajte, ako sa počet tokenov na požiadavku mení v čase.
Čo poskytnúť podpore (v prípade potreby)
Ak kontaktujete podporu, uveďte:
ID dotknutých organizácií (dôležité)
Dotknuté koncové body, napríklad Chat Completions alebo Responses (dôležité)
Dotknuté modely (dôležité)
Či sa problém vyskytuje v rýchlom režime alebo na úrovni škálovania (dôležité)
Časové intervaly výskytu latencie alebo chýb vrátane časového pásma (dôležité)
Príslušné x-request-id alebo X-Client-Request-Id, ak sú k dispozícii
Časové pečiatky s časovým pásmom, alebo aspoň dátum, pre požiadavky, ktoré uvádzate
Ak máte k dispozícii aj nasledujúce informácie, priložte ich:
ID projektu, s ktorým požiadavky súvisia
Či sa problém týka požiadaviek s rezidenciou údajov, a ak áno, ktorých
Opis trendov, ktoré pozorujete
Podľa typu problému uveďte:
Chyby: Približné percento požiadaviek, ktoré zlyhávajú alebo vracajú chybu, kódy odpovedí, chybové hlásenia a čas, za ktorý ste dostali chybovú odpoveď.
Latencia: Ktoré percentily sú ovplyvnené (P50 / P90 / P95 / P99), o koľko sú vyššie oproti bežným hodnotám zákazníka a príklady pomalých požiadaviek s časovými pečiatkami odoslania a prijatia.
Oba typy: Snímky obrazovky alebo tabuľku s údajmi o chybách či latencii a vysvetlenie, ako ste zistili, že miera chybovosti alebo latencia bola vyššia, než sa očakávalo.
Bežné scenáre riešenia problémov
Vyskytujú sa časové limity, ale Service Health vyzerá normálne
Možná príčina: požiadavky prekračujú časový limit skôr, než dorazia do OpenAI.
Skontrolujte:
Nastavenia časového limitu klienta alebo proxy servera
Zmeny v lokálnej sieti alebo vyvažovači záťaže
Prítomnosť chýb 499 v informačnom paneli Service Health (vo vašich vlastných systémoch sa môžu zobrazovať ako chyby 5xx).
Latencia sa zvýšila bez nasadenia
Možná príčina: zvýšila sa veľkosť výstupných tokenov alebo používanie uvažovania a/alebo sa prevádzka presunula medzi úrovňami služby.
Skontrolujte:
Priemerný počet výstupných tokenov na požiadavku v informačnom paneli používania (vyžaduje stiahnutie údajov a vydelenie výstupných tokenov celkovým počtom požiadaviek).
Percentily Času požiadavky a TTFT v informačnom paneli Service Health.
Rýchly režim alebo úroveň škálovania sa zdajú byť pomalé
Možná príčina: metriky z rôznych úrovní sú zmiešané, takže prevádzka štandardnej úrovne skresľuje výkon platenej úrovne.
Skontrolujte:
Filtre sú obmedzené na jednu úroveň a jeden model.
Porovnanie rýchlosti tokenov medzi úrovňami.
Nárast chýb 5XX
Pravdepodobná príčina: dočasné zlyhania ovplyvňujúce malé percento prevádzky.
Skontrolujte:
Percento chybovosti
Či sa v rovnakom čase zmenil objem prevádzky
Problém ovplyvňuje iba jeden projekt
Pravdepodobná príčina: konfigurácia alebo vzor používania špecifický pre projekt.
Skontrolujte:
Filtrovanie na úrovni projektu
Porovnanie s neovplyvnenými projektmi
Záverečné odporúčania
Pred interpretáciou metrík filtrujte podľa modelu, úrovne a projektu, ak je to relevantné.
Pri analýze latencie používajte percentily, nie priemery.
Malé miery chýb sú očakávané.
Chýbajúce údaje zvyčajne naznačujú upstream problémy.
Údaje o používaní môžu pomôcť vysvetliť, prečo sa latencia zmenila; Service Health ukazuje, kedy sa správanie zmenilo.