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, prioritet, skalering), må du alltid filtrere til nivået du undersøker.
Hvorfor:
Nivåer har ulike ytelsesegenskaper
Prioritets- og skaleringsnivåer har definerte SLA-er
Å blande nivåer skjuler ytelsen på betalte nivåer
Dette er særlig viktig for latensanalyse.
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 latens
Latensanalyse gir mest mening på prioritetsnivåer og skaleringsnivåer, som har definerte SLA-er. Standardnivået kan vise større latensvariasjon og har ingen garantert latens.
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. Hva du bør dele med brukerstøtte (om nødvendig)
Hvis du kontakter brukerstøtte, inkluder:
Berørte org-ID-er (viktig)
Berørte endepunkter, for eksempel Chat Completions eller Responses (viktig)
Berørte modeller (viktig)
Om dette gjelder skalerings- eller prioritetsnivået (viktig)
Tidsintervaller med tidssone for latens eller feil (viktig)
Relevant x-request-id eller X-Client-Request-Id, hvis tilgjengelig
Tidsstempler med tidssone, eller i det minste datoen, for forespørslene du oppgir
Hvis tilgjengelig, inkluder også:
Prosjekt-ID relatert til forespørslene
Om dataresidensforespørsler er berørt, og hvilke
Beskrivelser av trendene du ser
For problemtypen, inkluder:
Feil: Omtrentlig prosentandel forespørsler som mislykkes eller gir feil, svarkoder, feilmeldinger og hvor lang tid det tok å motta feilresponsen.
Latens: Hvilke percentiler 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: Skjermbilder eller en tabell med feil- eller latensdata, samt hvordan du fastslo at feilrater eller latens 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.
Prioritets- eller skaleringsnivå virker tregt
Mulig årsak: beregninger er blandet på tvers av nivåer, slik at trafikk på standardnivå skjuler ytelsen på betalte nivåer.
Kontroller:
Filtrene er begrenset 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.