Dlaczego tradycyjny monitoring API zawodzi w przypadku LLM

Problem, którego nie widać w panelu

Przyznajmy to sobie: jeśli obserwujesz swoją aplikację z LLM tak samo jak zwykłe endpointy API, działasz po omacku.

Widzę to bez przerwy. Zespoły stawiają swój serwis AI, podłączają go do istniejącego stacka observability, patrzą na zielone kontrolki statusu — a potem dostają zaporową fakturę za miesiąc albo fale skarg użytkowników na jakość odpowiedzi. Narzędzia pokazują, że wszystko gra. A nie gra.

Cały problem tkwi głębiej niż w wyborze innych metryk. Chodzi o to, że systemy AI fundamentalnie łamią założenia, na których zbudowaliśmy naszą infrastrukturę monitoringu.

Model webowy nie pasuje

Tradycyjne podejście do monitoringu zakłada prosty sygnał: przychodzi request, coś się dzieje, wychodzi response. Albo działa, albo nie. Latencja to latencja. Percentyl 99. mówi nam coś konkretnego.

LLM-y rozbijają każde z tych założeń na kawałki.

Odpowiedź nie przychodzi jednorazowo — generuje się token po tokenie. To oznacza, że „latencja" to tak naprawdę przynajmniej trzy różne liczby zależnie od tego, gdzie jesteśmy w procesie generowania. Status 200 OK nie mówi nic o jakości tego, co dostajemy. Koszt rośnie z tokenami, nie z requestami. A najbardziej bolesne błędy są całkowicie niewidoczne: model zwraca pewną siebie bzdurę z idealnym kodem HTTP.

TTFT — liczba, którą odczuwa użytkownik

Kiedy ktoś wysyła prompt do funkcji AI, pierwsze, czego doświadcza, jest czekanie. Konkretnie: czekanie na pojawienie się pierwszego tokena. To Time to First Token (TTFT) — najbliższy odpowiednik „odczuwalnej latencji" w świecie LLM.

Co sprawia, że TTFT jest podstępne? Rośnie wraz z długością promptu. Jeśli budujesz system RAG, który upycha ogromne okna kontekstowe w każde zapytanie po to, by poprawić dokładność — jednocześnie zabijasz odczuwalną wydajność. To fundamentalny tradeoff, którego tradycyjny monitoring ci nie pokaże.

ITL — płynność ma znaczenie

Kiedy stream już się zaczyna, użytkownicy wykształcają oczekiwania co do szybkości czytania. Inter-Token Latency (ITL) — odstęp między kolejnymi tokenami — decyduje o tym, czy output wydaje się płynny czy urywany.

Ciekawe jest to, że użytkownicy dość dobrze tolerują wolny, ale stały strumień. Nienawidzą szybszego strumienia, który zacina się i szarpie. Twój monitoring powinien rozróżniać te dwa doświadczenia, nawet jeśli surowa przepustowość wygląda w porządku.

Latencja end-to-end — kontekst jest wszystkim

Metric p99, która świetnie sprawdza się przy REST API, całkowicie wprowadzi cię w błąd w przypadku requestów AI. Dlaczego? Bo zadanie klasyfikacji generujące 50 tokenów i generowanie raportu z 2000 tokenów mają diametralnie różne profile latencji. Średnia z tych dwóch wartości daje liczbę, która nie reprezentuje absolutnie niczego.

Mierz latencję per przypadek użycia. Każda metryka powinna odpowiadać jednemu obciążeniu o spójnych charakterystykach. W przeciwnym razie optymalizujesz abstrakcję, która nie istnieje.

Problem cichych błędów

Najstraszniejsze jest jednak co innego: najgorsze problemy produkcyjne z systemami AI często generują zero alertów.

Twój model zaczyna produkować pewne siebie halucynacje. Dryft promptów wprowadza subtelne obciążenie. Ściągnięty kontekst jest ignorowany na rzecz pamięci treningowej. Wszystko to zwraca HTTP 200, kończy się w akceptowalnym czasie i wygląda idealnie zdrowo na dashboardzie.

Nie wyłapiesz tego kontrolkami uptime. Potrzebujesz monitoringu jakości outputu — trudniejszego do zinstrumentowania, ale absolutnie niezbędnego.

Co naprawdę ma znaczenie

Grupuj metryki AI wokół pytań, na które odpowiadają:

• Czy jest szybki? TTFT, ITL, percentyle latencji per przypadek użycia
• Czy skaluje się? Przepustowość tokenów, głębokość kolejek, wykorzystanie kontekstu
• Czy działa poprawnie? Wskaźniki ukończenia zadań, wzorce błędów w outputach
• Czy się opłaca? Koszt per zadanie, efektywność tokenowa, spójność modelu
• Jak się zachowuje? (Dla agentów) Ukończenie zadań, liczba kroków, wykrywanie pętli

Część z tych liczb dostaniesz za darmo od infrastruktury. Resztę — nie. Budowanie customowej instrumentacji dla obciążeń AI nie jest opcjonalne — to jedyny sposób, żeby zobaczyć, co naprawdę się dzieje.

Zespoły, które to ogarniają, nie mają lepszych dashboardów. Mają lepsze pytania.