Защо стандартният мониторинг е безполезен за LLM приложения

Да си призная честно: ако следиш LLM-базираното си приложение по същия начин, по който следиш обикновените си API endpoints, всъщност не виждаш нищо.

Виждам това непрекъснато. Екипи пуснат AI услугата си, свържат я със съществуващата си система за наблюдение, гледат зелените лампички — и после ги удря гръм, когато потребителите започнат да се оплакват от качеството на отговорите или когато месечната сметка се окаже три пъти по-висока от очакваното. Инструментите им показват, че всичко е наред. А то не е.

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

Моделът за уеб услуги просто не пасва

Традиционният мониторинг разчита на чист сигнал: идва заявка, случва се работа, излиза отговор. Успех или провал — черно или бяло. Лутенцията е лутенция. Твоят 99-и перцентил ти дава смислена информация.

LLM-ите разбиват всяко едно от тези предположения.

Отговорът не пристига наведнъж — генерира се токен по токен, което означава, че "лутенцията" всъщност са поне три различни числа в зависимост от това къде се намираш във времето на генериране. Един HTTP 200 отговор не означава нищо за качеството на изхода. Цената расте с токените, не със заявките. И най-разрушителните грешки са напълно безмълвни: моделът връща уверена безсмислица с перфектен HTTP статус код.

Time to First Token: Числото, което потребителите реално усещат

Когато някой изпрати prompt към твоята AI функция, първото нещо, което изпитва, е чакане. По-точно — чака първия токен да се появи на екрана. Това е Time to First Token (TTFT) и е най-близкото нещо до "усещана лутенция", което съществува в света на LLM-ите.

Ето какво прави TTFT коварно: времето расте с дължината на prompt-а. Ако разработваш RAG система, която пълни огромни context windows във всяка заявка, за да подобри точността — едновременно с това влошаваш възприеманата производителност. Това е фундаментален компромис, който традиционният мониторинг изобщо няма да ти покаже.

Inter-Token Latency: Факторът "поток"

След като стриймингът започне, потребителите започват да си формират очаквания за скоростта на четене. Inter-Token Latency (ITL) — паузата между последователните токени — определя дали изходът се усеща плавен или накъсан.

Потребителите са доста толерантни към бавен, но стабилен поток. Мразят по-бърз поток, който замръзва и заеква. Твоят мониторинг трябва да прави разлика между тези две преживявания, дори когато суровата производителност изглежда приемлива.

Крайна лутенция: Контекстът е всичко

Метриката p99, която работи прекрасно за твоя REST API, ще те подведе напълно за AI заявки. Защо? Защото задача за класификация с 50 токена и генериране на доклад с 2000 токена имат коренно различни лутенционни профили, а когато ги осредниш заедно, получаваш число, което не представлява нищо.

Следи лутенцията за всеки конкретен случай на употреба. Всяка метрика трябва да отговаря на една работна натовареност с последователни характеристики. В противен случай оптимизираш за абстракция, която не съществува.

Проблемът с безмълвните грешки

Ето най-страшната част: най-сериозните production проблеми с AI системите често не генерират никакви алерти.

Моделът ти започва да генерира уверени халюцинации. Prompt drift-ът въвежда неусетно пристрастие. Изтегленият контекст се пренебрегва в полза на спомени от обучението. Всичко това връща HTTP 200, завършва в приемливо време и изглежда напълно здравословно в твоя dashboard.

Няма да хванеш тези неща с uptime проверки. Нуждаеш се от мониторинг на качеството на изхода — по-трудно е за имплементация, но абсолютно задължително.

Какво всъщност има значение

Групирай AI метриките си около въпросите, на които отговарят:

• Бързо ли е? TTFT, ITL, перцентили на лутенцията за всеки случай
• Мащабира ли се? Пропускателна способност на токените, дълбочина на опашките, използване на контекста
• Вярно ли е? Процент на успешно завършени задачи, модели на грешки в изходите
• Издържа ли натоварване? Цена на задача, ефективност на токените, консистентност на модела
• Как се държи? (За агенти) Завършване на задачи, брой стъпки, детекция на цикли

Някои от тези числа ще получиш безплатно от инфраструктурата. Повечето — не. Изграждането на персонализирана инструментация за AI работни натоварвания не е опция — то е единственият начин да видиш какво всъщност се случва.

Екипите, които се справят правилно, не използват по-добри dashboard-и. Те задават по-добри въпроси.