OpenAI
Оваа страница беше машински преведена. Погледнете ја оригиналната статија на англиски јазик.

Решавање проблеми со API грешки и латентност

Оваа статија објаснува како да ги користите контролните табли Service Health и Usage за решавање чести грешки и проблеми со латентност при користење на OpenAI API.

Ажурирано: 11 days ago

Важни врски

Започнете со вистинските стандардни поставки

Кога ќе ја отворите контролната табла за состојба на услугата, таа стандардно прикажува:

  • Сите проекти

  • Последните 30 дена

  • Часовна резолуција

Овој приказ е корисен само за ориентација. Значајното решавање проблеми секогаш бара филтрирање.

Филтрирајте пред да истражувате

Правилното филтрирање е најважниот чекор. Повеќето погрешни толкувања произлегуваат од мешање модели, нивоа или проекти.

Филтрирајте по модел (еден по еден)

Секогаш филтрирајте на еден модел.

Зошто:

  • Проблемите кај модели со мал сообраќај може да бидат скриени од сообраќај со поголем обем

  • Моделите со голем обем може да направат локализираните проблеми да изгледаат глобални

  • Различни модели имаат различни цели за перформанси

Забелешка: избирањето повеќе модели ги агрегира — не префрла меѓу нив.

Филтрирање според Ниво на услуга

Ако користите повеќе од едно ниво (стандардно, Брз режим (порано „Приоритетна обработка“), Ниво на скалирање), секогаш филтрирајте според нивото што го истражувате.

Зошто:

  • Нивоата имаат различни карактеристики на перформансите

  • Брз режим и Ниво на скалирање имаат дефинирани SLA

  • Мешањето на нивоата ги прикрива перформансите на платеното ниво

Ова е особено важно при анализа на латентноста.

Кај постојните модели, сообраќајот во Брз режим и натаму се прикажува како приоритетен на контролната табла за користење.

Филтрирајте по проект

Стандардно, Состојбата на услугата ги прикажува сите проекти.

За решавање проблеми, филтрирајте на проектот/проектите каде што е забележан проблемот.

Зошто:

  • Еден проект со голем обем може да доминира во метриките.

  • Помалите засегнати проекти може да бидат прикриени од неповрзан сообраќај.

Оставете „Сите проекти“ избрано само ако верувате дека проблемот навистина ја засега целата организација.

Решавање проблеми со грешки

Користете го приказот за HTTP барања

За да истражите грешки:

  1. Филтрирајте по модел и ниво на услуга.

  2. Отворете го јазичето HTTP барања наместо јазичето Време на работа.

Овој приказ ги покажува вкупните барања и бројот на грешки според HTTP статусниот код. Зумирајте до резолуција на ниво на минута за да идентификувате детални скокови или промени.

Толкувајте ги стапките на грешки, не бројките

Некои грешки се очекувани во секој продукциски систем. Фокусирајте се на процентот на грешки, не на необработените вкупни бројки.

Колку е поголем вашиот вкупен обем, толку е поголем потенцијалниот број грешки дури и со екстремно ниска стапка на грешки.

Кога грешките недостасуваат од Состојбата на услугата

Ако гледате грешки на клиентската страна, но нема соодветни податоци во Состојбата на услугата:

  • Барањата веројатно не стигнале до OpenAI.

  • Проблемот обично е нагоре во текот (истек на време, проксија, мрежа).

Ова е често кај агресивни истекувања на време на клиентската страна.

Решавање проблеми со латентноста

Анализата на латентноста е најрелевантна за нивоата Брз режим и Ниво на скалирање, за кои има дефинирани SLA. На стандардното ниво латентноста може повеќе да варира и не е загарантирана.

Клучни метрики

За да ја видите секоја метрика, кликнете на соодветното јазиче:

  • Брзина на токени: токени генерирани во секунда; независно од големината на промптот.

  • Време на барање: вкупно времетраење на барањето; силно зависи од големината на излезот и расудувањето.

  • Време до прв токен (TTFT): време додека не се генерира првиот токен; силно зависи од големината на некешираниот влезен промпт и расудувањето.

Секогаш прегледувајте ги P50 / P75 / P95 процентилите. Просеците можат да го скријат влијанието врз реалните корисници.

6. Корелација на латентноста со користењето токени

Состојбата на услугата покажува кога се променило однесувањето. Податоците за користење помагаат да се објасни зошто.

Во контролната табла за користење, направете го следново за да се осигурите дека ги гледате податоците релевантни за вашиот приказ во контролната табла за состојба на услугата:

  • Филтрирајте на истиот проект и модел.

  • Групирајте по ниво на услуга, ако е применливо.

  • Фокусирајте се на излезните токени, кои најсилно влијаат на латентноста.

За подлабока анализа, извезете ги податоците за активност и прегледајте ги токените по барање со текот на времето.

7. Што да споделите со поддршката (ако е потребно)

Ако контактирате со поддршката, наведете ги:

  • ID-а на засегнатите организации (важно)

  • Засегнатите крајни точки, како Chat Completions или Responses (важно)

  • Засегнатите модели (важно)

  • Дали проблемот се јавува во Брз режим или Ниво на скалирање (важно)

  • Временските периоди со временска зона за латентноста или грешките (важно)

  • Релевантниот x-request-id или X-Client-Request-Id, ако е достапен

  • Временски ознаки со временска зона или барем датумот за барањата што ги доставувате

Ако се достапни, наведете ги и:

  • ID на проектот поврзан со барањата

  • Дали се засегнати барањата за место на чување на податоците и кои од нив

  • Описи на трендовите што ги забележувате

За соодветниот тип проблем, наведете:

  • Грешки: Приближниот процент на барања што се неуспешни или враќаат грешка, кодовите на одговор, пораките за грешка и времето потребно за да се добие одговорот со грешка.

  • Латентност: Кои перцентили се засегнати (P50 / P90 / P95 / P99), колку се повисоки од вообичаените вредности кај клиентот и примери за бавни барања со временски ознаки за испраќање и прием.

  • Двете: Слики од екранот или табела со податоци за грешките или латентноста, како и начинот на кој утврдивте дека стапката на грешки или латентноста е повисока од очекуваното.

Вообичаени сценарија за решавање проблеми

Се случуваат истекувања на време, но Состојбата на услугата изгледа нормално

Можна причина: барањата истекуваат пред да стигнат до OpenAI.

Проверете:

  • Поставки за истек на време на клиентот или проксито

  • Промени во локалната мрежа или балансерот на оптоварување

  • Присуство на 499 грешки во контролната табла за состојба на услугата (тие може да се прикажат како 5xx грешки во вашите системи).

Латентноста се зголеми без распоредување

Можна причина: се зголемила големината на излезните токени или користењето на расудување и/или сообраќајот се префрлил меѓу нивоата на услуга.

Проверете:

  • Просечни излезни токени по барање во контролната табла за користење (потребно е преземање на податоците и делење на излезните токени со вкупниот број барања).

  • Процентили за времето на барање и TTFT во контролната табла за состојба на услугата.

Бавни перформанси во Брз режим или Ниво на скалирање

Можна причина: метриките од различни нивоа се измешани, па сообраќајот од стандардното ниво ги прикрива перформансите на платеното ниво.

Проверете:

  • Филтрите се ограничени на само едно ниво и еден модел.

  • Споредба на брзината на токените меѓу нивоата.

Нагло зголемување на 5XX грешки

Веројатна причина: привремени неуспеси што влијаат на мал процент од сообраќајот.

Проверете:

  • Процент на стапка на грешки

  • Дали обемот на сообраќај се променил во исто време

Проблемот влијае само на еден проект

Веројатна причина: конфигурација или шема на користење специфична за проектот.

Проверете:

  • Филтрирање на ниво на проект

  • Споредба со незасегнати проекти

Крајни заклучоци

  • Филтрирајте по модел, ниво и проект каде што е релевантно пред да ги толкувате метриките.

  • Користете процентили, не просеци, за анализа на латентноста.

  • Се очекуваат мали стапки на грешки.

  • Недостигот на податоци обично укажува на проблеми нагоре во текот.

  • Податоците за користење можат да помогнат да се објасни зошто се променила латентноста; Состојбата на услугата покажува кога се променило однесувањето.

Дали оваа статија ви беше корисна?