Важливі посилання
Панель стану сервісу (зараз доступна лише клієнтам Enterprise API)
Почніть із правильних стандартних налаштувань
Коли ви відкриваєте панель Service Health, за замовчуванням установлено:
Усі проєкти
Останні 30 днів
Погодинна роздільна здатність
Це подання корисне лише для орієнтації. Для змістовного усунення проблем завжди потрібне фільтрування.
Фільтруйте перед дослідженням
Правильне фільтрування — найважливіший крок. Більшість хибних тлумачень виникає через змішування моделей, рівнів або проєктів.
Фільтруйте за моделлю (по одній)
Завжди фільтруйте до однієї моделі.
Чому:
Проблеми на моделях із низьким трафіком можуть приховуватися трафіком більшого обсягу
Моделі з високим обсягом трафіку можуть створювати враження, що локальні проблеми є глобальними
Різні моделі мають різні цілі продуктивності
Примітка: вибір кількох моделей агрегує їх — він не перемикає між ними.
Фільтрування за Рівнем обслуговування
Якщо ви використовуєте кілька рівнів (стандартний, Швидкий режим (раніше — пріоритетна обробка), Рівень масштабування), завжди вибирайте у фільтрі рівень, який досліджуєте.
Чому:
Рівні мають різні характеристики продуктивності
Для Швидкого режиму й Рівня масштабування визначено SLA
Змішування рівнів приховує продуктивність платного рівня
Це особливо важливо під час аналізу затримки.
Для наявних моделей трафік Швидкого режиму на панелі використання досі позначається як priority.
Фільтруйте за проєктом
За замовчуванням Service Health показує всі проєкти.
Для усунення проблем фільтруйте до проєкту(-ів), де спостерігалася проблема.
Чому:
Один проєкт із великим обсягом трафіку може домінувати в метриках.
Менші уражені проєкти можуть бути приховані непов’язаним трафіком.
Залишайте вибраним «Усі проєкти» лише якщо вважаєте, що проблема справді стосується всієї організації.
Усунення помилок
Використовуйте подання HTTP-запитів
Щоб дослідити помилки:
Фільтруйте за моделлю та рівнем обслуговування.
Відкрийте вкладку HTTP-запити замість вкладки Час безвідмовної роботи.
У цьому поданні показано загальну кількість запитів і кількість помилок за кодом стану HTTP. Збільште масштаб до похвилинної роздільної здатності, щоб виявити детальні сплески або зміни.
Інтерпретуйте частоту помилок, а не їх кількість
У будь-якій виробничій системі деякі помилки очікувані. Зосередьтеся на відсотку помилок, а не на необроблених загальних значеннях.
Що більший загальний обсяг, то більшою може бути кількість помилок навіть за надзвичайно низької частоти помилок.
Коли помилки відсутні в Service Health
Якщо ви бачите помилки на боці клієнта, але немає відповідних даних у Service Health:
Запити, імовірно, не дійшли до OpenAI.
Проблема зазвичай виникає вище за потоком (тайм-аути, проксі, мережа).
Це часто трапляється за надто агресивних тайм-аутів на боці клієнта.
Усунення проблем із затримкою
Аналіз затримки найдоцільніше проводити для рівнів Швидкий режим і Рівень масштабування, для яких визначено SLA. На стандартному рівні затримка може коливатися в ширшому діапазоні й не гарантується.
Ключові метрики
Щоб переглянути кожну метрику, натисніть відповідну вкладку:
Швидкість токенів: токени, згенеровані за секунду; не залежить від розміру запиту.
Час запиту: загальна тривалість запиту; сильно залежить від розміру вихідних даних і міркування.
Час до першого токена (TTFT): час до генерування першого токена; сильно залежить від розміру некешованого вхідного запиту та міркування.
Завжди переглядайте перцентилі P50 / P75 / P95. Середні значення можуть приховувати вплив на реальних користувачів.
Зв’язок між затримкою та використанням токенів
Стан сервісу показує, коли змінилася його робота. Дані про використання допомагають пояснити, чому.
На панелі використання виконайте наведені нижче дії, щоб переглядати дані, які відповідають вибраним параметрам на панелі стану сервісу:
Відфільтруйте дані за тим самим проєктом і моделлю.
Згрупуйте дані за рівнем обслуговування, якщо це доречно.
Зосередьтеся на вихідних токенах, які найбільше впливають на затримку.
Для глибшого аналізу експортуйте дані про активність і дослідіть, як із часом змінювалася кількість токенів на запит.
Що надати службі підтримки в разі звернення
Якщо звертаєтеся до служби підтримки, надайте:
Ідентифікатори організацій, яких стосується проблема (важливо)
Кінцеві точки, яких стосується проблема, наприклад 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 показує, коли змінилася поведінка.