Viktige lenker
Instrumentbord for tjenestetilstand (for øyeblikket bare tilgjengelig for Enterprise API-kunder)
Start med riktige standardinnstillinger
Når du åpner Instrumentbordet for tjenestetilstand, er standardvisningen:
Alle prosjekter
Siste 30 dager
Timeoppløsning
Denne visningen er bare nyttig for orientering. Meningsfull feilsøking krever alltid filtrering.
Filtrer før du undersøker
Riktig filtrering er det viktigste trinnet. De fleste feiltolkninger skyldes blanding av modeller, nivåer eller prosjekter.
Filtrer etter modell (én om gangen)
Filtrer alltid til én enkelt modell.
Hvorfor:
Problemer på modeller med lav trafikk kan skjules av trafikk med høyere volum
Modeller med høyt volum kan få lokale problemer til å virke globale
Ulike modeller har ulike ytelsesmål
Merk: Hvis du velger flere modeller, aggregeres de – du bytter ikke mellom dem.
Filtrer etter Tjenestenivå
Hvis du bruker mer enn ett nivå (standard, Hurtigmodus (tidligere prioritert behandling), Skaleringsnivå), må du alltid filtrere på nivået du undersøker.
Hvorfor:
Nivåene har ulike ytelsesegenskaper
Hurtigmodus og Skaleringsnivå har definerte SLA-er
Blanding av nivåer skjuler ytelsen på betalte nivåer
Dette er spesielt viktig ved analyse av ventetid.
For eksisterende modeller vises trafikk fra Hurtigmodus fortsatt som «priority» i dashbordet for bruk.
Filtrer etter prosjekt
Som standard viser Tjenestetilstand alle prosjekter.
Ved feilsøking filtrerer du til prosjektet/prosjektene der problemet ble observert.
Hvorfor:
Ett enkelt prosjekt med høyt volum kan dominere beregningene.
Mindre berørte prosjekter kan maskeres av urelatert trafikk.
La «Alle prosjekter» være valgt bare hvis du mener at problemet virkelig gjelder hele organisasjonen.
Feilsøking av feil
Bruk visningen for HTTP-forespørsler
Slik undersøker du feil:
Filtrer etter modell og tjenestenivå.
Åpne fanen HTTP-forespørsler i stedet for fanen Oppetid.
Denne visningen viser totalt antall forespørsler og feiltall etter HTTP-statuskode. Zoom inn til oppløsning på minuttnivå for å identifisere detaljerte topper eller endringer.
Tolk feilrater, ikke antall
Noen feil er forventet i alle produksjonssystemer. Fokuser på feilprosent, ikke råtotaler.
Jo større totalvolumet ditt er, desto større kan antallet feil være, selv med en ekstremt lav feilrate.
Når feil mangler i Tjenestetilstand
Hvis du ser feil på klientsiden, men ingen tilsvarende data i Tjenestetilstand:
Forespørslene nådde sannsynligvis ikke OpenAI.
Problemet er vanligvis oppstrøms (tidsavbrudd, proxyer, nettverk).
Dette er vanlig med aggressive tidsavbrudd på klientsiden.
Feilsøking av ventetid
Analyse av ventetid gir mest mening for Hurtigmodus og Skaleringsnivå, som har definerte SLA-er. Standardnivået kan ha større variasjon i ventetiden og har ingen garantert ventetid.
Nøkkelberegninger
For å se hver beregning klikker du på den relevante fanen:
Tokenhastighet: Tokener generert per sekund; uavhengig av promptstørrelse.
Forespørselstid: Total forespørselsvarighet; påvirkes sterkt av utdatastørrelse og resonnering.
Tid til første token (TTFT): Tid til første token genereres; påvirkes sterkt av størrelsen på ikke-hurtigbufret inndataprompt og resonnering.
Gå alltid gjennom P50 / P75 / P95-percentiler. Gjennomsnitt kan skjule påvirkning på reelle brukere.
6. Korrelering av latens med tokenbruk
Tjenestetilstand viser når atferden endret seg. Bruksdata bidrar til å forklare hvorfor.
I Bruksinstrumentbordet gjør du følgende for å sikre at du ser på dataene som er relevante for visningen din i Instrumentbordet for tjenestetilstand:
Filtrer til samme prosjekt og modell.
Grupper etter tjenestenivå, hvis aktuelt.
Fokuser på utdatatokener, som påvirker latens sterkest.
For dypere analyse kan du eksportere aktivitetsdata og undersøke tokener per forespørsel over tid.
7. Dette bør du dele med brukerstøtten (ved behov)
Hvis du kontakter brukerstøtten, må du ta med:
Berørte organisasjons-ID-er (viktig)
Berørte endepunkter, for eksempel Chat Completions eller Responses (viktig)
Berørte modeller (viktig)
Om dette gjelder Hurtigmodus eller Skaleringsnivå (viktig)
Tidsperioder med tidssone for ventetid eller feil (viktig)
Relevant x-request-id eller X-Client-Request-Id, hvis tilgjengelig
Tidsstempler med tidssone, eller minst datoen, for forespørslene du oppgir
Ta også med følgende hvis det er tilgjengelig:
Prosjekt-ID knyttet til forespørslene
Om forespørsler med dataresidens er berørt, og hvilke det gjelder
Beskrivelser av trendene du ser
Ta med følgende for den aktuelle problemtypen:
Feil: Omtrentlig prosentandel forespørsler som mislykkes eller gir feil, svarkoder, feilmeldinger og hvor lang tid det tok å motta feilsvaret.
Ventetid: Hvilke persentiler som er berørt (P50 / P90 / P95 / P99), hvor høye de er sammenlignet med kundens normalnivå, og eksempler på trege forespørsler med tidsstempler for sending og mottak.
Begge deler: Skjermbilder eller en tabell med feil- eller ventetidsdata, samt hvordan du fastslo at feilfrekvensen eller ventetiden var høyere enn forventet.
Vanlige feilsøkingsscenarioer
Tidsavbrudd oppstår, men Tjenestetilstand ser normal ut
Mulig årsak: forespørsler får tidsavbrudd før de når OpenAI.
Kontroller:
Innstillinger for tidsavbrudd på klient eller proxy
Endringer i lokalt nettverk eller lastbalanserer
Forekomst av 499-feil i Instrumentbordet for tjenestetilstand (disse kan vises som 5xx-feil i dine egne systemer).
Latensen økte uten en utrulling
Mulig årsak: antallet utdatatokener eller bruken av resonnering økte, og/eller trafikken flyttet seg mellom tjenestenivåer.
Kontroller:
Gjennomsnittlig antall utdatatokener per forespørsel i Bruksinstrumentbordet (krever nedlasting av data og deling av utdatatokener på totalt antall forespørsler).
Forespørselstid og TTFT-percentiler i Instrumentbordet for tjenestetilstand.
Hurtigmodus eller Skaleringsnivå virker tregt
Mulig årsak: Måledata fra ulike nivåer er blandet, slik at trafikk på standardnivået skjuler ytelsen på betalte nivåer.
Kontroller følgende:
Filtrene er avgrenset til ett enkelt nivå og én modell.
Sammenligning av tokenhastighet mellom nivåer.
Økning i 5XX-feil
Sannsynlig årsak: midlertidige feil som påvirker en liten prosentandel av trafikken.
Kontroller:
Feilrate i prosent
Om trafikkvolumet endret seg samtidig
Problemet påvirker bare ett prosjekt
Sannsynlig årsak: prosjektspesifikk konfigurasjon eller bruksmønster.
Kontroller:
Filtrering på prosjektnivå
Sammenligning med upåvirkede prosjekter
Viktigste punkter
Filtrer etter modell, nivå og prosjekt der det er relevant, før du tolker beregninger.
Bruk percentiler, ikke gjennomsnitt, til latensanalyse.
Små feilrater er forventet.
Manglende data indikerer vanligvis oppstrømsproblemer.
Bruksdata kan bidra til å forklare hvorfor latensen endret seg; Tjenestetilstand viser når atferden endret seg.