Почему ваш мониторинг API бесполезен для AI-приложений

Буду откровенен: если вы следите за своим LLM-приложением так же, как за обычными API-эндпоинтами — вы ничего не видите.

Я сталкиваюсь с этим постоянно. Команды разворачивают AI-сервис, подключают его к существующей системе мониторинга, радуются зелёным индикаторам, а потом получают шквал жалоб от пользователей на качество ответов или счёт, который в три раза превышает ожидания. Инструменты показывают, что всё в порядке. Но это не так.

Проблема глубже, чем просто выбор других метрик. AI-системы ломают базовые предположения, на которых построена наша инфраструктура наблюдения.

Модель веб-сервисов здесь не работает

Классический мониторинг веб-приложений опирается на простую модель: запрос пришёл — работа выполнена — ответ отдан. Успех или провал, всё чётко. Задержка есть задержка. P99 показывает реальную картину.

LLM разрушает все эти допущения.

Ответ приходит не целиком — токен за токеном, а значит «задержка» — это минимум три разных числа в зависимости от того, где вы находитесь в процессе генерации. Статус 200 OK ничего не говорит о качестве вывода. Оплата считается токенами, а не запросами. А самые опасные сбои вообще невидимы: модель выдаёт уверенную чушь с идеальным HTTP-статусом.

Time to First Token: то, что ощущает пользователь

Когда кто-то отправляет промпт в вашу AI-функцию, первое, что он чувствует — ожидание. А точнее, ожидание появления первого токена на экране. Это Time to First Token (TTFT) — ближайший аналог «воспринимаемой задержки» в мире LLM.

Вот что делает TTFT коварным: время растёт вместе с длиной промпта. Если вы строите RAG-систему и набиваете огромные контекстные окна ради точности — вы одновременно убиваете воспринимаемую скорость. Это фундаментальный компромисс, который штатный мониторинг вам не покажет.

Inter-Token Latency: фактор плавности

Когда потоковая передача началась, у пользователей формируются ожидания относительно скорости чтения. Inter-Token Latency (ITL) — промежуток между соседними токенами — определяет, кажется ли вывод плавным или рваным.

Люди удивительно терпеливы к медленному, но стабильному потоку. Но они ненавидят быстрый поток, который постоянно замирает и дёргается. Ваш мониторинг должен различать эти ощущения, даже когда общая пропускная способность выглядит приемлемой.

End-to-End Latency: контекст решает всё

Метрика p99, которая отлично работает для REST API, полностью введёт вас в заблуждение для AI-запросов. Почему? Потому что задача классификации на 50 токенов и генерация отчёта на 2000 токенов имеют совершенно разные профили задержки, а усреднение даёт число, которое не описывает ничего.

Считайте задержку для каждого сценария отдельно. Каждая метрика должна соответствовать одной рабочей нагрузке с предсказуемыми характеристиками. Иначе вы оптимизируете абстракцию, которая не существует.

Проблема тихих сбоев

Самая пугающая часть: худшие проблемы с AI-системами в продакшене часто не генерируют никаких алертов.

Ваша модель начинает выдавать уверенные галлюцинации. Дрейф промптов вносит незаметное смещение. Извлечённый контекст игнорируется в пользу тренировочных данных. Всё это возвращает HTTP 200, укладывается в допустимое время и выглядит идеально на дашборде.

Аптайм-проверки здесь бессильны. Нужно отслеживать качество вывода — это сложнее настроить, но совершенно необходимо.

Что действительно важно

Группируйте метрики вокруг вопросов, на которые они отвечают:

• Быстро ли? TTFT, ITL, перцентили задержки по сценариям
• Масштабируется? Пропускная способность по токенам, глубина очередей, использование контекста
• Правильно ли? Успешность выполнения задач, паттерны ошибок в выводе
• Эффективно ли? Стоимость на задачу, эффективность по токенам, стабильность модели
• Как ведёт себя? (Для агентов) Завершение задач, количество шагов, обнаружение зацикливаний

Часть этих цифр вы получите бесплатно от инфраструктуры. Большинство — нет. Кастомная инструментация для AI-нагрузок — не опция, а единственный способ увидеть реальную картину.

Команды, которые решают эту задачу правильно, используют не более красивые дашборды. Они задают более правильные вопросы.