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