Monitoring LLM aplikací: Co funguje pro API, selhává u umělé inteligence

Upřímně: když sledujete svou aplikaci poháněnou LLM stejným způsobem jako své API endpointy, létáte naslepo.

Vidím to pořád. Týmy nastaví svou AI službu, napojí ji na existující observability stack, sledují zelená světélka a pak jsou zaskočeni, když uživatelé stěžují na kvalitu odpovědí nebo když měsíční faktura přijde třikrát vyšší, než čekali. Nástroje jim říkají, že je všechno v pořádku. Ale není.

Problém je hlubší než jen výběr jiných metrik. AI systémy fundamentálně porušují předpoklady, na kterých byla naše monitorovací infrastruktura postavena.

Model webových služeb prostě nefunguje

Klasické webové monitorování počítá s čistým signálem: přijde požadavek, proběhne práce, vrátí se odpověď. Úspěch nebo selhání je binární. Latence je latence. Vaše 99. percentil vám řekne něco smysluplného.

LLM ale rozbíjejí každý z těchto předpokladů.

Odpověď nepřichází najednou — generuje se token po tokenu, což znamená, že „latence" je ve skutečnosti minimálně tři různá čísla podle toho, kde stojíte v časové ose generování. Stav 200 OK nic neříká o kvalitě výstupu. Náklady rostou s tokeny, ne s požadavky. A ty nejškodlivější selhání jsou zcela tichá: model vrací sebevědomý nesmysl s perfektním HTTP stavovým kódem.

Time to First Token: Číslo, které uživatelé skutečně pocítí

Když někdo pošle prompt do vaší AI funkce, první věc, kterou zažije, je čekání. Konkrétně čeká na první token, který se objeví na obrazovce. To je Time to First Token (TTFT) a je to nejbližší ekvivalent „vnímáné latence", jaký v světě LLM existuje.

Tady je háček: TTFT roste s délkou promptu. Když stavíte RAG systém, který nacpává obří kontextové okno do každého požadavku pro lepší přesnost, zároveň srážíte vnímaný výkon. Tohle je fundamentální kompromis, který tradiční monitoring před vámi neodhalí.

Inter-Token Latency: Faktor plynulosti

Jakmile se spustí streaming, uživatelé si vytvářejí očekávání ohledně rychlosti čtení. Inter-Token Latency (ITL) — mezera mezi po sobě jdoucími tokeny — rozhoduje o tom, jestli výstup působí plynule nebo trhaně.

Uživatelé jsou překvapivě tolerantní k pomalému, ale konzistentnímu streamu. Nesnášejí rychlejší stream, který zamrzá a zadrhává se. Vaše monitorování by mělo rozlišovat mezi těmito zážitky, i když surová propustnost vypadá dobře.

End-to-End Latence: Kontext je všechno

Metrika p99, která krásně funguje pro vaše REST API, vás u AI požadavků úplně zavede. Proč? Protože 50tokenový klasifikační úkol a generování 2000tokenové zprávy mají zcela odlišné latenční profily a jejich zprůměrování vytvoří číslo, které nic nepředstavuje.

Sledujte latenci podle用例. Každá metrika by měla odpovídat jednomu typu úlohy s konzistentními vlastnostmi. Jinak optimalizujete pro abstrakci, která neexistuje.

Problém tichých selhání

Tady je ta nejděsivější část: nejhorší produkční problémy s AI systémy často neprodukují žádné alerty.

Váš model začne generovat sebevědomé halucinace. Drift v promptu introduce subtle bias. Atributy kontext jsou ignorovány ve prospěch trénovacích vzpomínek. To všechno vrátí HTTP 200, dokončí se v přijatelném čase a vypadá naprosto zdravě na dashboardu.

Na tyhle věci nepřijdete pomocí uptime checků. Potřebujete monitorování kvality výstupu a to je sice těžší na instrumentaci, ale naprosto nezbytné.

Co ve skutečnosti záleží

Seskupejte své AI metriky podle otázek, na které odpovídají:

• Je to rychlé? TTFT, ITL, percentily latence podle用例
• Umí to škálovat? Propustnost tokenů, hloubka front, využití kontextu
• Je to správné? Míry dokončení úkolů, chybové vzorce ve výstupech
• Drží to náklady? Cena za úkol, efektivita tokenů, konzistence modelu
• Jak se chová? (Pro agenty) Dokončení úkolů, počty kroků, detekce smyček

Některá z těchto čísel dostanete zadarmo od infrastruktury. Většina ne. Budování vlastní instrumentace pro AI úlohy není volitelné — je to jediný způsob, jak vidět, co se skutečně děje.

Týmy, které tohle zvládnou správně, nepoužívají lepší dashboardy. Kladou lepší otázky.