Важни врски
Контролна табла за состојба на услугата (моментално достапна само за Enterprise API корисници)
Започнете со вистинските стандардни поставки
Кога ќе ја отворите контролната табла за состојба на услугата, таа стандардно прикажува:
Сите проекти
Последните 30 дена
Часовна резолуција
Овој приказ е корисен само за ориентација. Значајното решавање проблеми секогаш бара филтрирање.
Филтрирајте пред да истражувате
Правилното филтрирање е најважниот чекор. Повеќето погрешни толкувања произлегуваат од мешање модели, нивоа или проекти.
Филтрирајте по модел (еден по еден)
Секогаш филтрирајте на еден модел.
Зошто:
Проблемите кај модели со мал сообраќај може да бидат скриени од сообраќај со поголем обем
Моделите со голем обем може да направат локализираните проблеми да изгледаат глобални
Различни модели имаат различни цели за перформанси
Забелешка: избирањето повеќе модели ги агрегира — не префрла меѓу нив.
Филтрирајте по ниво на услуга
Ако користите повеќе од едно ниво (стандардно, priority, scale), секогаш филтрирајте на нивото што го истражувате.
Зошто:
Нивоата имаат различни карактеристики на перформанси
Priority и scale нивоата имаат дефинирани SLA-и
Мешањето нивоа ги замаглува перформансите на платеното ниво
Ова е особено важно за анализа на латентноста.
Филтрирајте по проект
Стандардно, Состојбата на услугата ги прикажува сите проекти.
За решавање проблеми, филтрирајте на проектот/проектите каде што е забележан проблемот.
Зошто:
Еден проект со голем обем може да доминира во метриките.
Помалите засегнати проекти може да бидат прикриени од неповрзан сообраќај.
Оставете „Сите проекти“ избрано само ако верувате дека проблемот навистина ја засега целата организација.
Решавање проблеми со грешки
Користете го приказот за HTTP барања
За да истражите грешки:
Филтрирајте по модел и ниво на услуга.
Отворете го јазичето HTTP барања наместо јазичето Време на работа.
Овој приказ ги покажува вкупните барања и бројот на грешки според HTTP статусниот код. Зумирајте до резолуција на ниво на минута за да идентификувате детални скокови или промени.
Толкувајте ги стапките на грешки, не бројките
Некои грешки се очекувани во секој продукциски систем. Фокусирајте се на процентот на грешки, не на необработените вкупни бројки.
Колку е поголем вашиот вкупен обем, толку е поголем потенцијалниот број грешки дури и со екстремно ниска стапка на грешки.
Кога грешките недостасуваат од Состојбата на услугата
Ако гледате грешки на клиентската страна, но нема соодветни податоци во Состојбата на услугата:
Барањата веројатно не стигнале до OpenAI.
Проблемот обично е нагоре во текот (истек на време, проксија, мрежа).
Ова е често кај агресивни истекувања на време на клиентската страна.
Решавање проблеми со латентност
Анализата на латентноста е најзначајна на нивоата priority и scale, кои имаат дефинирани SLA-и. Стандардното ниво може да покаже поголеми варијации во латентноста и нема гарантирана латентност.
Клучни метрики
За да ја видите секоја метрика, кликнете на соодветното јазиче:
Брзина на токени: токени генерирани во секунда; независно од големината на промптот.
Време на барање: вкупно времетраење на барањето; силно зависи од големината на излезот и расудувањето.
Време до прв токен (TTFT): време додека не се генерира првиот токен; силно зависи од големината на некешираниот влезен промпт и расудувањето.
Секогаш прегледувајте ги P50 / P75 / P95 процентилите. Просеците можат да го скријат влијанието врз реалните корисници.
6. Корелација на латентноста со користењето токени
Состојбата на услугата покажува кога се променило однесувањето. Податоците за користење помагаат да се објасни зошто.
Во контролната табла за користење, направете го следново за да се осигурите дека ги гледате податоците релевантни за вашиот приказ во контролната табла за состојба на услугата:
Филтрирајте на истиот проект и модел.
Групирајте по ниво на услуга, ако е применливо.
Фокусирајте се на излезните токени, кои најсилно влијаат на латентноста.
За подлабока анализа, извезете ги податоците за активност и прегледајте ги токените по барање со текот на времето.
7. Што да споделите со поддршката (ако е потребно)
Ако контактирате со поддршката, вклучете:
Засегнати ID-а на организации (важно)
Засегнати крајни точки, како Chat Completions или Responses (важно)
Засегнати модели (важно)
Дали ова е на Scale или Priority ниво (важно)
Временски опсези со временска зона за латентност или грешки (важно)
Релевантен x-request-id или X-Client-Request-Id, ако е достапно
Временски ознаки со временска зона, или барем датумот, за барањата што ги доставувате
Ако е достапно, вклучете и:
ID на проект поврзан со барањата
Дали се засегнати барања за место на чување на податоците и кои
Описи на трендовите што ги гледате
За типот на проблем, вклучете:
Грешки: приближен процент на неуспешни барања или барања со грешки, кодови на одговор, пораки за грешки и колку време било потребно да се прими одговорот со грешка.
Латентност: кои процентили се засегнати (P50 / P90 / P95 / P99), колку се високи во споредба со основната вредност на клиентот и примери на бавни барања со временски ознаки за испраќање и прием.
Двете: снимки од екранот или табела со податоци за грешки или латентност, плус како утврдивте дека стапките на грешки или латентноста биле повисоки од очекуваното.
Вообичаени сценарија за решавање проблеми
Се случуваат истекувања на време, но Состојбата на услугата изгледа нормално
Можна причина: барањата истекуваат пред да стигнат до OpenAI.
Проверете:
Поставки за истек на време на клиентот или проксито
Промени во локалната мрежа или балансерот на оптоварување
Присуство на 499 грешки во контролната табла за состојба на услугата (тие може да се прикажат како 5xx грешки во вашите системи).
Латентноста се зголеми без распоредување
Можна причина: се зголемила големината на излезните токени или користењето на расудување и/или сообраќајот се префрлил меѓу нивоата на услуга.
Проверете:
Просечни излезни токени по барање во контролната табла за користење (потребно е преземање на податоците и делење на излезните токени со вкупниот број барања).
Процентили за времето на барање и TTFT во контролната табла за состојба на услугата.
Priority или Ниво на скалирање изгледа бавно
Можна причина: метриките се измешани меѓу нивоата, што значи дека сообраќајот од стандардното ниво ги прикрива перформансите на платеното ниво.
Проверете:
Филтрите се ограничени на едно ниво и модел.
Споредба на брзината на токени меѓу нивоата.
Нагло зголемување на 5XX грешки
Веројатна причина: привремени неуспеси што влијаат на мал процент од сообраќајот.
Проверете:
Процент на стапка на грешки
Дали обемот на сообраќај се променил во исто време
Проблемот влијае само на еден проект
Веројатна причина: конфигурација или шема на користење специфична за проектот.
Проверете:
Филтрирање на ниво на проект
Споредба со незасегнати проекти
Крајни заклучоци
Филтрирајте по модел, ниво и проект каде што е релевантно пред да ги толкувате метриките.
Користете процентили, не просеци, за анализа на латентноста.
Се очекуваат мали стапки на грешки.
Недостигот на податоци обично укажува на проблеми нагоре во текот.
Податоците за користење можат да помогнат да се објасни зошто се променила латентноста; Состојбата на услугата покажува кога се променило однесувањето.