Linkuri importante
Tabloul de bord Starea serviciului (disponibil în prezent doar pentru clienții Enterprise API)
Începeți cu setările implicite corecte
Când deschideți tabloul de bord Starea serviciului, acesta are implicit:
Toate proiectele
Ultimele 30 de zile
Rezoluție orară
Această vizualizare este utilă doar pentru orientare. Depanarea relevantă necesită întotdeauna filtrare.
Filtrați înainte de investigare
Filtrarea corectă este cel mai important pas. Cele mai multe interpretări greșite provin din amestecarea modelelor, nivelurilor sau proiectelor.
Filtrați după model (pe rând)
Filtrați întotdeauna la un singur model.
De ce:
Problemele de pe modelele cu trafic redus pot fi ascunse de traficul cu volum mai mare
Modelele cu volum mare pot face ca problemele localizate să pară globale
Modelele diferite au obiective de performanță diferite
Notă: selectarea mai multor modele le agregă — nu comută între ele.
Filtrarea după Nivel serviciu
Dacă utilizați mai multe niveluri (standard, mod rapid (fostul mod de procesare prioritară), Nivel de scalare), filtrați întotdeauna după nivelul pe care îl investigați.
De ce:
Nivelurile au caracteristici de performanță diferite
Modul rapid și Nivel de scalare au SLA-uri definite
Combinarea nivelurilor ascunde performanța nivelurilor cu plată
Acest lucru este deosebit de important pentru analiza latenței.
Pentru modelele existente, traficul din modul rapid apare în continuare ca priority în tabloul de bord Usage.
Filtrați după proiect
În mod implicit, Starea serviciului afișează toate proiectele.
Pentru depanare, filtrați la proiectul/proiectele unde a fost observată problema.
De ce:
Un singur proiect cu volum mare poate domina metricile.
Proiectele afectate mai mici pot fi mascate de trafic neasociat.
Lăsați selectat „Toate proiectele” doar dacă credeți că problema este cu adevărat la nivelul întregii organizații.
Depanarea erorilor
Utilizați vizualizarea Solicitări HTTP
Pentru a investiga erorile:
Filtrați după model și Nivel serviciu.
Deschideți fila Solicitări HTTP în locul filei Timp de funcționare.
Această vizualizare afișează numărul total de solicitări și numărul de erori după codul de stare HTTP. Măriți până la rezoluția la nivel de minut pentru a identifica vârfuri sau modificări granulare.
Interpretați ratele de eroare, nu numărul erorilor
Unele erori sunt de așteptat în orice sistem de producție. Concentrați-vă pe procentul de erori, nu pe totalurile brute.
Cu cât volumul total este mai mare, cu atât numărul potențial de erori este mai mare, chiar și cu o rată de eroare extrem de scăzută.
Când erorile lipsesc din Starea serviciului
Dacă vedeți erori pe partea clientului, dar nu există date corespunzătoare în Starea serviciului:
Solicitările probabil nu au ajuns la OpenAI.
Problema este de obicei în amonte (expirări, proxy-uri, rețelistică).
Acest lucru este frecvent în cazul expirărilor agresive pe partea clientului.
Depanarea latenței
Analiza latenței este cea mai relevantă pentru nivelurile mod rapid și Nivel de scalare, care au SLA-uri definite. Nivelul standard poate prezenta variații mai mari ale latenței și nu oferă o latență garantată.
Metrici cheie
Pentru a vedea fiecare metrică, faceți clic pe fila relevantă:
Viteza tokenilor: tokeni generați pe secundă; independentă de dimensiunea solicitării.
Timp solicitare: durata totală a solicitării; puternic afectată de dimensiunea ieșirii și de raţionament.
Timp până la primul token (TTFT): timpul până când este generat primul token; puternic afectat de dimensiunea solicitării de intrare nememorate în cache și de raţionament.
Analizați întotdeauna percentilele P50 / P75 / P95. Mediile pot ascunde impactul asupra utilizatorilor reali.
6. Corelarea latenței cu utilizarea tokenilor
Starea serviciului arată când s-a schimbat comportamentul. Datele de utilizare ajută la explicarea motivului.
În tabloul de bord Utilizare, faceți următoarele pentru a vă asigura că priviți datele relevante pentru vizualizarea dvs. din tabloul de bord Starea serviciului:
Filtrați la același proiect și model.
Grupați după Nivel serviciu, dacă se aplică.
Concentrați-vă pe tokenii de ieșire, care afectează cel mai puternic latența.
Pentru o analiză mai aprofundată, exportați Datele de activitate și examinați tokenii per solicitare în timp.
7. Ce informații să trimiteți echipei de asistență (dacă este necesar)
Dacă luați legătura cu echipa de asistență, includeți:
ID-urile organizațiilor afectate (important)
Endpointurile afectate, precum Chat Completions sau Responses (important)
Modelele afectate (important)
Dacă este vizat modul rapid sau Nivel de scalare (important)
Intervalele de timp, cu fusul orar, în care apar latențe sau erori (important)
Valorile x-request-id sau X-Client-Request-Id relevante, dacă sunt disponibile
Marcajele temporale cu fusul orar sau cel puțin data solicitărilor furnizate
Dacă sunt disponibile, includeți și:
ID-ul proiectului asociat solicitărilor
Dacă sunt afectate solicitările privind rezidența datelor și care dintre acestea
Descrieri ale tendințelor observate
În funcție de tipul problemei, includeți:
Erori: procentul aproximativ al solicitărilor care eșuează sau returnează erori, codurile răspunsurilor, mesajele de eroare și timpul până la primirea răspunsului de eroare.
Latență: percentilele afectate (P50 / P90 / P95 / P99), valorile acestora comparativ cu nivelul de referință al clientului și exemple de solicitări lente, cu marcajele temporale ale trimiterii și primirii.
Ambele: capturi de ecran sau un tabel cu date despre erori ori latență, precum și modul în care ați stabilit că ratele de eroare sau latența au fost mai mari decât valorile așteptate.
Scenarii frecvente de depanare
Apar expirări, dar Starea serviciului pare normală
Cauză posibilă: solicitările expiră înainte de a ajunge la OpenAI.
Verificați:
Setările de expirare ale clientului sau proxy-ului
Modificări ale rețelei locale sau ale balansatorului de încărcare
Prezența erorilor 499 în tabloul de bord Starea serviciului (acestea pot apărea ca erori 5xx în propriile dvs. sisteme).
Latența a crescut fără o implementare
Cauză posibilă: dimensiunea tokenilor de ieșire sau utilizarea raţionamentului a crescut și/sau traficul s-a mutat între niveluri de serviciu.
Verificați:
Numărul mediu de tokeni de ieșire per solicitare în tabloul de bord Utilizare (necesită descărcarea datelor și împărțirea tokenilor de ieșire la numărul total de solicitări).
Percentilele Timp solicitare și TTFT în tabloul de bord Starea serviciului.
Modul rapid sau Nivel de scalare pare lent
Cauză posibilă: valorile sunt combinate între niveluri, astfel încât traficul de nivel standard maschează performanța nivelurilor cu plată.
Verificați:
Filtrele sunt limitate la un singur nivel și model.
Comparația vitezei tokenurilor între niveluri.
Creștere bruscă a erorilor 5XX
Cauză probabilă: erori tranzitorii care afectează un procent mic din trafic.
Verificați:
Procentul ratei de eroare
Dacă volumul traficului s-a schimbat în același timp
Problema afectează un singur proiect
Cauză probabilă: configurație sau tipar de utilizare specific proiectului.
Verificați:
Filtrarea la nivel de proiect
Comparația cu proiectele neafectate
Concluzii finale
Filtrați după model, nivel și proiect, unde este relevant, înainte de a interpreta metricile.
Utilizați percentile, nu medii, pentru analiza latenței.
Ratele mici de eroare sunt așteptate.
Datele lipsă indică de obicei probleme în amonte.
Datele de utilizare pot ajuta la explicarea motivului pentru care s-a schimbat latența; Starea serviciului arată când s-a schimbat comportamentul.