Důležité odkazy
Řídicí panel stavu služby (aktuálně dostupný jen zákazníkům Enterprise API)
Začněte se správnými výchozími hodnotami
Když otevřete řídicí panel stavu služby, výchozí nastavení je:
Všechny projekty
Posledních 30 dní
Hodinové rozlišení
Toto zobrazení je užitečné jen pro orientaci. Smysluplné řešení potíží vždy vyžaduje filtrování.
Před zkoumáním filtrujte
Správné filtrování je nejdůležitější krok. Většina chybných interpretací vzniká smícháním modelů, úrovní nebo projektů.
Filtrujte podle modelu (vždy po jednom)
Vždy filtrujte na jeden model.
Proč:
Problémy u modelů s nízkým provozem může skrýt provoz s vyšším objemem
Modely s vysokým objemem mohou způsobit, že lokální problémy vypadají jako globální
Různé modely mají různé výkonnostní cíle
Poznámka: výběr více modelů je agreguje — nepřepíná mezi nimi.
Filtrování podle úrovně služeb
Pokud používáte více než jednu úroveň (standardní, Rychlý režim, dříve Prioritní zpracování, nebo úroveň škálování), vždy filtrujte podle úrovně, kterou prověřujete.
Proč:
Jednotlivé úrovně mají odlišné výkonnostní charakteristiky
Rychlý režim a úroveň škálování mají definované smlouvy SLA
Směšování úrovní zakrývá výkon placené úrovně
To je zvlášť důležité při analýze latence.
U stávajících modelů se provoz Rychlého režimu na řídicím panelu Využití stále zobrazuje jako prioritní.
Filtrujte podle projektu
Ve výchozím nastavení Service Health zobrazuje všechny projekty.
Při řešení potíží filtrujte na projekty, ve kterých byl problém pozorován.
Proč:
Jeden projekt s vysokým objemem může dominovat metrikám.
Menší ovlivněné projekty může zakrýt nesouvisející provoz.
Možnost „Všechny projekty“ nechte vybranou jen tehdy, pokud se domníváte, že problém skutečně zasahuje celou organizaci.
Řešení potíží s chybami
Použijte zobrazení požadavků HTTP
Chcete-li prozkoumat chyby:
Filtrujte podle modelu a úrovně služeb.
Otevřete kartu HTTP Requests místo karty Uptime.
Toto zobrazení ukazuje celkový počet požadavků a počty chyb podle stavového kódu HTTP. Přibližte zobrazení na minutové rozlišení, abyste identifikovali podrobné špičky nebo změny.
Interpretujte míry chyb, ne počty
V každém produkčním systému se očekávají určité chyby. Zaměřte se na procento chyb, ne na hrubé součty.
Čím větší je celkový objem, tím větší může být počet chyb i při extrémně nízké chybovosti.
Když ve Service Health chybí chyby
Pokud vidíte chyby na straně klienta, ale žádná odpovídající data ve Service Health:
Požadavky se pravděpodobně nedostaly k OpenAI.
Problém je obvykle upstream (časové limity, proxy servery, síť).
To je běžné u agresivních časových limitů na straně klienta.
Řešení problémů s latencí
Analýza latence má největší vypovídací hodnotu u úrovní Rychlý režim a úroveň škálování, které mají definované smlouvy SLA. U standardní úrovně může latence více kolísat a není u ní zaručena.
Klíčové metriky
Každou metriku zobrazíte kliknutím na příslušnou kartu:
Rychlost tokenů: Tokeny generované za sekundu; nezávisí na velikosti promptu.
Doba požadavku: Celková doba trvání požadavku; výrazně ji ovlivňuje velikost výstupu a uvažování.
Čas do prvního tokenu (TTFT): Doba do vygenerování prvního tokenu; výrazně ji ovlivňuje velikost neuloženého vstupního promptu v mezipaměti a uvažování.
Vždy kontrolujte percentily P50 / P75 / P95. Průměry mohou skrývat dopad na skutečné uživatele.
Souvislost mezi latencí a využitím tokenů
Přehled stavu služby ukazuje, kdy se chování změnilo. Údaje o využití pomáhají vysvětlit proč.
Na panelu využití postupujte následovně, abyste zobrazili data odpovídající vašemu zobrazení na panelu stavu služby:
Vyfiltrujte stejný projekt a model.
Je-li to relevantní, seskupte data podle úrovně služeb.
Zaměřte se na výstupní tokeny, které mají na latenci největší vliv.
Pro podrobnější analýzu exportujte data o aktivitě a prozkoumejte, jak se počet tokenů na požadavek mění v čase.
Co v případě potřeby sdělit podpoře
Pokud kontaktujete podporu, uveďte:
ID dotčených organizací (důležité)
Dotčené koncové body, například Chat Completions nebo Responses (důležité)
Dotčené modely (důležité)
Zda k problému dochází v Rychlém režimu nebo na úrovni škálování (důležité)
Časové intervaly výskytu problémů s latencí nebo chyb včetně časového pásma (důležité)
Příslušné x-request-id nebo X-Client-Request-Id, pokud je máte k dispozici
Časová razítka včetně časového pásma, nebo alespoň datum, u požadavků, které uvádíte
Pokud máte k dispozici i následující údaje, připojte je:
ID projektu, ke kterému požadavky patří
Zda jsou dotčeny požadavky s datovou rezidencí a které konkrétně
Popis trendů, které pozorujete
Podle typu problému uveďte:
Chyby: Přibližné procento požadavků, které selhaly nebo skončily chybou, kódy odpovědí, chybové zprávy a dobu, za kterou přišla chybová odpověď.
Latence: Které percentily jsou ovlivněny (P50 / P90 / P95 / P99), o kolik jsou vyšší oproti běžným hodnotám zákazníka a příklady pomalých požadavků s časovými razítky odeslání a přijetí.
Obojí: Snímky obrazovky nebo tabulku s údaji o chybách či latenci a popis toho, jak jste zjistili, že chybovost nebo latence byly vyšší, než se očekávalo.
Běžné scénáře řešení potíží
Dochází k časovým limitům, ale Service Health vypadá normálně
Možná příčina: požadavky překračují časový limit ještě před dosažením OpenAI.
Zkontrolujte:
Nastavení časových limitů klienta nebo proxy serveru
Změny v místní síti nebo nástroji pro vyrovnávání zátěže
Přítomnost chyb 499 v řídicím panelu Service Health (ve vašich vlastních systémech se mohou zobrazovat jako chyby 5xx).
Latence se zvýšila bez nasazení
Možná příčina: zvýšila se velikost výstupu v tokenech nebo využití uvažování a/nebo se provoz přesunul mezi úrovněmi služeb.
Zkontrolujte:
Průměrný počet výstupních tokenů na požadavek v řídicím panelu využití (vyžaduje stažení dat a vydělení výstupních tokenů celkovým počtem požadavků).
Percentily Request Time a TTFT v řídicím panelu stavu služby.
Rychlý režim nebo úroveň škálování se zdají být pomalé
Možná příčina: metriky jsou smíšené napříč úrovněmi, takže provoz standardní úrovně zakrývá výkon placené úrovně.
Zkontrolujte:
Filtry jsou omezeny na jedinou úroveň a model.
Porovnání rychlosti tokenů mezi úrovněmi.
Nárůst chyb 5XX
Pravděpodobná příčina: přechodné výpadky ovlivňující malé procento provozu.
Zkontrolujte:
Procento chybovosti
Zda se současně změnil objem provozu
Problém ovlivňuje jen jeden projekt
Pravděpodobná příčina: konfigurace nebo vzor využití specifický pro projekt.
Zkontrolujte:
Filtrování na úrovni projektu
Porovnání s neovlivněnými projekty
Závěrečná shrnutí
Před interpretací metrik filtrujte podle modelu, úrovně a projektu, pokud je to relevantní.
Pro analýzu latence používejte percentily, ne průměry.
Nízké míry chyb jsou očekávané.
Chybějící data obvykle ukazují na problémy upstream.
Data o využití mohou pomoci vysvětlit, proč se latence změnila; Service Health ukazuje, kdy se chování změnilo.