Важливі посилання
Панель стану сервісу (зараз доступна лише клієнтам Enterprise API)
Почніть із правильних стандартних налаштувань
Коли ви відкриваєте панель Service Health, за замовчуванням установлено:
Усі проєкти
Останні 30 днів
Погодинна роздільна здатність
Це подання корисне лише для орієнтації. Для змістовного усунення проблем завжди потрібне фільтрування.
Фільтруйте перед дослідженням
Правильне фільтрування — найважливіший крок. Більшість хибних тлумачень виникає через змішування моделей, рівнів або проєктів.
Фільтруйте за моделлю (по одній)
Завжди фільтруйте до однієї моделі.
Чому:
Проблеми на моделях із низьким трафіком можуть приховуватися трафіком більшого обсягу
Моделі з високим обсягом трафіку можуть створювати враження, що локальні проблеми є глобальними
Різні моделі мають різні цілі продуктивності
Примітка: вибір кількох моделей агрегує їх — він не перемикає між ними.
Фільтруйте за рівнем обслуговування
Якщо ви використовуєте більше ніж один рівень (стандартний, пріоритетний, масштабування), завжди фільтруйте до рівня, який досліджуєте.
Чому:
Рівні мають різні характеристики продуктивності
Пріоритетний рівень і рівень масштабування мають визначені SLA
Змішування рівнів приховує продуктивність платного рівня
Це особливо важливо для аналізу затримки.
Фільтруйте за проєктом
За замовчуванням 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 показує, коли змінилася поведінка.