Waarom je LLM-applicaties anders moet monitoren dan je API's

Er is iets mis met hoe we AI-systemen in de gaten houden. En nee, dit is geen niche-probleem voor de early adopters.

Ik zie het keer op keer gebeuren. Teams bouwen hun AI-feature, pluggen het in hun bestaande monitoring-stack, zien groene lampjes, en dan komt de verrassing: klachten over antwoordkwaliteit of een factuur die drie keer hoger is dan begroot. De dashboards zeggen dat alles prima is. Maar dat is het niet.

Het echte probleem zit dieper dan verkeerde metrics kiezen. Onze monitoringsystemen zijn gebouwd op aannames die AI gewoon niet deelt.

Het Traditionele Model Werkt Niet Meer

Bij gewone API-monitoring is alles lekker simpel: request erin, werk doen, response eruit. Succes of falen, aan of uit. Latency is latency. Je p99 zegt iets zinvols.

Met LLMs valt dat allemaal uit elkaar.

Een antwoord komt niet in één keer binnen—het wordt token voor token gegenereerd. Dus "latency" is eigenlijk minstens drie verschillende getallen, afhankelijk van waar je in die timeline naar kijkt. Een 200 OK zegt niets over de kwaliteit. Kosten worden bepaald door tokens, niet door requests. En de ergste storingen zijn volledig onzichtbaar: je model serves overtuigende onzin met een perfecte HTTP-statuscode.

Time to First Token: Wat Je Gebruiker Echt Voelt

Wanneer iemand een prompt verstuurt, is het eerste wat ze ervaren: wachten. Specifiek: wachten tot het eerste token verschijnt. Dat is je Time to First Token (TTFT), en het is de beste proxy voor hoe snel je applicatie aanvoelt.

Het lastige aan TTFT? Het groeit met de lengte van je prompt. Bouw je een RAG-systeem dat enorme context windows in elke request propt voor betere nauwkeurigheid? Gefeliciteerd, je bent tegelijkertijd je perceived performance aan het verpesten. Dit is een fundamentele afweging die traditionele monitoring niet voor je zichtbaar maakt.

Inter-Token Latency: De Vloeiendheidsfactor

Zodra de stream op gang komt, ontwikkelen gebruikers verwachtingen over leessnelheid. Inter-Token Latency (ITL)—de ruimte tussen opeenvolgende tokens—bepaalt of de output soepel aanvoelt of schokkerig.

Gebruikers zijn verrassend tolerant voor een trage maar constante stroom. Ze haten een snellere stream die bevriest en hikt. Je monitoring moet dit onderscheid maken, zelfs wanneer de ruwe throughput acceptabel lijkt.

End-to-End Latency: Context Is Alles

Die p99-metric die perfect werkt voor je REST API? Die leidt je volledig mis bij AI-requests. Waarom? Omdat een 50-token classificatietaak en een 2.000-token rapportgeneratie totaal verschillende latency-profielen hebben. Als je die bij elkaar optelt, krijg je een getal dat niets voorstelt.

Monitor latency per use case. Elke metric hoort bij één werklast met consistente eigenschappen. Anders optimaliseer je voor een abstractie die niet bestaat.

Het Stille-Storingen-Probleem

Dit is misschien wel het engste deel: de ergste productieproblemen met AI-systemen genereren vaak nul alerts.

Je model begint overtuigende hallucinaties te serveren. Prompt drift introduceert subtiele bias. De opgehaalde context wordt genegeerd ten gunste van trainingsherinneringen. Al dit soort dingen returnt HTTP 200, voltooit binnen acceptabele tijd, en ziet er gezond uit in je dashboard.

Met uptime checks vang je dit niet af. Je hebt output quality monitoring nodig, en dat is lastiger te instrumenteren maar absoluut essentieel.

Wat Echt Belangrijk Is

Groep je AI-metrics rond de vragen die ze beantwoorden:

• Is het snel? TTFT, ITL, latency percentiles per use case
• Kan het schalen? Token throughput, queue depths, context utilization
• Is het correct? Task completion rates, foutpatronen in outputs
• Houdt het stand? Cost per task, token efficiency, model consistency
• Hoe gedraagt het zich? (Voor agents) Task completion, step counts, loop detection

Sommige van deze cijfers krijg je gratis van je infrastructuur. De meeste niet. Custom instrumentation bouwen voor AI-workloads is geen optie—het is de enige manier om te zien wat er echt gebeurt.

De teams die dit goed doen, gebruiken geen betere dashboards. Ze stellen betere vragen.