Slutt å overvåke AI-applikasjonene dine som vanlige API-er

La meg være direkte: hvis du overvåker LLM-applikasjonen din på samme måte som du overvåker API-endepunktene dine, opererer du uten blindsoner.

Jeg ser dette hele tiden. Team setter opp AI-tjenesten sin, kobler den til den eksisterende observabilitetsstacken, ser på de grønne statuslysene, og blir deretter tatt på sengen når brukerne klager på responskvalitet eller når regningen er 300 % høyere enn forventet. Verktøyene forteller dem at alt er fint. Det er det ikke.

Problemet ligger dypere enn bare å velge andre måltall. Det er at AI-systemer fundamentalt bryter med forutsetningene som overvåkningsinfrastrukturen ble bygget på.

Webservices-tenkningen fungerer ikke her

Tradisjonell web-overvåking antar et klart signal: en forespørsel kommer inn, arbeid skjer, en respons kommer ut. Suksess eller feil er binært. Latens er latens. Din 99. persentil forteller deg noe meningsfylt.

LLM-er knuser hver eneste av disse forutsetningene.

En respons leveres ikke på én gang – den genereres token for token, noe som betyr at «latens» egentlig er minst tre forskjellige tall avhengig av hvor du befinner deg i genereringstidslinjen. En 200 OK-respons sier ingenting om utdatakvalitet. Kostnaden skalerer med tokens, ikke forespørsler. Og de mest skadelige feilene er helt stille: modellen returnerer selvsikker tull med en perfekt HTTP-statuskode.

Time to First Token: Tallene brukerne faktisk merker

Når noen sender en prompt til AI-funksjonen din, er det første de opplever å vente. Spesifikt venter de på at det første tokenet skal vises på skjermen. Det er Time to First Token (TTFT), og det er det nærmeste vi kommer «opplevd latens» i LLM-verdenen.

Her er det som gjør TTFT vanskelig: det øker med prompt-lengden. Hvis du bygger et RAG-system som stapper massive kontekstvinduer inn i hver forespørsel for å forbedre nøyaktigheten, sender du samtidig den opplevde ytelsen rett i bakken. Dette er en fundamental avveining som tradisjonell overvåkning ikke vil avsløre for deg.

Inter-Token Latency: Flytfaktoren

Så snart streamingen starter, utvikler brukerne forventninger om lesehastighet. Inter-Token Latency (ITL) – gapet mellom påfølgende tokens – er det som avgjør om output føles jevn eller hakkete.

Brukere er overraskende tolerable overfor en treg men konsistent strøm. De hater en raskere strøm som fryser og stammer. Overvåkningen din bør skille mellom disse opplevelsene, selv når rå throughput ser akseptabel ut.

Ende-til-ende latens: Kontekst er alt

P99-metrikken som fungerer perfekt for REST-API-et ditt vil villede deg fullstendig for AI-forespørsler. Hvorfor? Fordi en 50-token klassifiseringsoppgave og en 2 000-token rapportgenerering har vidt forskjellige latensprofiler, og å slå dem sammen produserer et tall som ikke representerer noe som helst.

Spor latens per brukstilfelle. Hvert måltall bør tilsvare én arbeidslast med konsistente egenskaper. Ellers optimaliserer du for en abstraksjon som ikke eksisterer.

Stille feil-problemet

Her er den skumleste delen: de verste produksjonsproblemene med AI-systemer produserer ofte null varsler.

Modellen din begynner å generere selvsikre hallusinasjoner. Din prompt-drift introduserer subtil bias. Den hentede konteksten ignoreres til fordel for treningsminner. Alt dette returnerer HTTP 200, fullføres på akseptabel tid, og ser perfekt sunt ut i dashbordet ditt.

Du vil ikke fange disse med uptime-sjekker. Du trenger overvåkning av output-kvalitet, og det er vanskeligere å instrumentere men absolutt nødvendig.

Hva som faktisk betyr noe

Gruppeer AI-måltallene dine rundt spørsmålene de besvarer:

• Er det raskt? TTFT, ITL, per-use-case latens-persentiler
• Kan det skalere? Token throughput, kødybder, kontekstutnyttelse
• Er det korrekt? Oppgavegjennomføringsrater, feilmønstre i outputs
• Holder det? Kostnad per oppgave, token-effektivitet, modellkonsistens
• Hvordan oppfører det seg? (For agenter) Oppgavegjennomføring, stegtelling, loop-deteksjon

Noen av disse tallene får du gratis fra infrastrukturen din. De fleste får du ikke. Å bygge egendefinert instrumentering for AI-arbeidsbelastninger er ikke valgfritt – det er den eneste måten å se hva som faktisk skjer.

Teamene som får dette til, bruker ikke bedre dashbord. De stiller bedre spørsmål.