Важливі посилання
Панель стану сервісу (зараз доступна лише клієнтам Enterprise API)
Почніть із правильних стандартних налаштувань
Коли ви відкриваєте панель Service Health, за замовчуванням установлено:
Усі проєкти
Останні 30 днів
Погодинна роздільна здатність
Це подання корисне лише для орієнтації. Для змістовного усунення проблем завжди потрібне фільтрування.
Фільтруйте перед дослідженням
Правильне фільтрування — найважливіший крок. Більшість хибних тлумачень виникає через змішування моделей, рівнів або проєктів.
Фільтруйте за моделлю (по одній)
Завжди фільтруйте до однієї моделі.
Чому:
Проблеми на моделях із низьким трафіком можуть приховуватися трафіком більшого обсягу
Моделі з високим обсягом трафіку можуть створювати враження, що локальні проблеми є глобальними
Різні моделі мають різні цілі продуктивності
Примітка: вибір кількох моделей агрегує їх — він не перемикає між ними.
Фільтрування за Рівнем обслуговування
Якщо ви використовуєте кілька рівнів (стандартний, Швидкий режим (раніше — пріоритетна обробка), Рівень масштабування), завжди вибирайте у фільтрі рівень, який досліджуєте.
Чому:
Рівні мають різні характеристики продуктивності
Для Швидкого режиму й Рівня масштабування визначено SLA
Змішування рівнів приховує продуктивність платного рівня
Це особливо важливо під час аналізу затримки.
Для наявних моделей трафік Швидкого режиму на панелі використання досі позначається як priority.
Фільтруйте за проєктом
За замовчуванням Service Health показує всі проєкти.
Для усунення проблем фільтруйте до проєкту(-ів), де спостерігалася проблема.
Чому:
Один проєкт із великим обсягом трафіку може домінувати в метриках.
Менші уражені проєкти можуть бути приховані непов’язаним трафіком.
Залишайте вибраним «Усі проєкти» лише якщо вважаєте, що проблема справді стосується всієї організації.
Усунення помилок
Використовуйте подання HTTP-запитів
Щоб дослідити помилки:
Фільтруйте за моделлю та рівнем обслуговування.
Відкрийте вкладку HTTP-запити замість вкладки Час безвідмовної роботи.
У цьому поданні показано загальну кількість запитів і кількість помилок за кодом стану HTTP. Збільште масштаб до похвилинної роздільної здатності, щоб виявити детальні сплески або зміни.
Інтерпретуйте частоту помилок, а не їх кількість
У будь-якій виробничій системі деякі помилки очікувані. Зосередьтеся на відсотку помилок, а не на необроблених загальних значеннях.
Що більший загальний обсяг, то більшою може бути кількість помилок навіть за надзвичайно низької частоти помилок.
Коли помилки відсутні в Service Health
Якщо ви бачите помилки на боці клієнта, але немає відповідних даних у Service Health:
Запити, імовірно, не дійшли до OpenAI.
Проблема зазвичай виникає вище за потоком (тайм-аути, проксі, мережа).
Це часто трапляється за надто агресивних тайм-аутів на боці клієнта.
Усунення проблем із затримкою
Аналіз затримки найдоцільніше проводити для рівнів Швидкий режим і Рівень масштабування, для яких визначено SLA. На стандартному рівні затримка може коливатися в ширшому діапазоні й не гарантується.
Ключові метрики
Щоб переглянути кожну метрику, натисніть відповідну вкладку:
Швидкість токенів: токени, згенеровані за секунду; не залежить від розміру запиту.
Час запиту: загальна тривалість запиту; сильно залежить від розміру вихідних даних і міркування.
Час до першого токена (TTFT): час до генерування першого токена; сильно залежить від розміру некешованого вхідного запиту та міркування.
Завжди переглядайте перцентилі P50 / P75 / P95. Середні значення можуть приховувати вплив на реальних користувачів.
6. Кореляція затримки з використанням токенів
Service Health показує, коли змінилася поведінка. Дані про використання допомагають пояснити, чому.
На панелі використання виконайте наведені нижче дії, щоб переконатися, що ви переглядаєте дані, релевантні вашому поданню на панелі Service Health:
Відфільтруйте за тим самим проєктом і моделлю.
Згрупуйте за рівнем обслуговування, якщо застосовно.
Зосередьтеся на вихідних токенах, які найсильніше впливають на затримку.
Для глибшого аналізу експортуйте Activity Data й дослідіть кількість токенів на запит із часом.
7. Які дані надати службі підтримки (за потреби)
Звертаючись до служби підтримки, зазначте:
Ідентифікатори постраждалих організацій (важливо)
Постраждалі кінцеві точки, як-от Chat Completions або Responses (важливо)
Постраждалі моделі (важливо)
Чи виникає проблема у Швидкому режимі або на Рівні масштабування (важливо)
Періоди часу із зазначенням часового поясу для затримок або помилок (важливо)
Відповідні x-request-id або X-Client-Request-Id, якщо доступні
Позначки часу із часовим поясом або принаймні дати наданих вами запитів
Якщо можливо, також зазначте:
Ідентифікатор проєкту, пов’язаного із запитами
Чи зачеплено запити, до яких застосовуються вимоги до локалізації даних, і які саме
Опис спостережуваних тенденцій
Залежно від типу проблеми зазначте:
Помилки: приблизний відсоток невдалих запитів або запитів із помилками, коди відповіді, повідомлення про помилки й час очікування відповіді з помилкою.
Затримка: на які процентилі це впливає (P50 / P90 / P95 / P99), наскільки вони перевищують базові показники клієнта, а також приклади повільних запитів із позначками часу надсилання й отримання.
Обидві проблеми: знімки екрана або таблицю з даними про помилки чи затримку, а також пояснення того, як ви визначили, що частота помилок або затримка перевищує очікуваний рівень.
Поширені сценарії усунення проблем
Тайм-аути виникають, але Service Health виглядає нормально
Можлива причина: час очікування запитів минає до того, як вони досягають OpenAI.
Перевірте:
Налаштування тайм-ауту клієнта або проксі
Зміни в локальній мережі або балансувальнику навантаження
Наявність помилок 499 на панелі Service Health (у ваших власних системах вони можуть відображатися як помилки 5xx).
Затримка зросла без розгортання
Можлива причина: збільшився розмір вихідних токенів або використання міркування та/або трафік змістився між рівнями обслуговування.
Перевірте:
Середню кількість вихідних токенів на запит на панелі використання (потрібно завантажити дані й поділити вихідні токени на загальну кількість запитів).
Перцентилі Request Time і TTFT на панелі Service Health.
Швидкий режим або Рівень масштабування працює повільно
Можлива причина: показники різних рівнів змішано, тому трафік стандартного рівня приховує продуктивність платного рівня.
Перевірте:
У фільтрах вибрано лише один рівень і одну модель.
Порівняння швидкості обробки токенів між рівнями.
Сплеск помилок 5XX
Імовірна причина: тимчасові збої, що впливають на невеликий відсоток трафіку.
Перевірте:
Відсоток помилок
Чи змінився обсяг трафіку в той самий час
Проблема впливає лише на один проєкт
Імовірна причина: конфігурація або шаблон використання, специфічні для проєкту.
Перевірте:
Фільтрування на рівні проєкту
Порівняння з неураженими проєктами
Підсумкові висновки
Перш ніж інтерпретувати метрики, фільтруйте за моделлю, рівнем і проєктом, де це доречно.
Для аналізу затримки використовуйте перцентилі, а не середні значення.
Невеликі показники помилок очікувані.
Відсутні дані зазвичай указують на проблеми на попередніх етапах.
Дані про використання можуть допомогти пояснити, чому змінилася затримка; Service Health показує, коли змінилася поведінка.