Waarom lijken de gemiddelde latentietijden gezond, terwijl interactieve AI traag aanvoelt?

Gemiddelde latentie kan er gezond uitzien terwijl interactieve AI traag aanvoelt, omdat zeldzame lange wachttijden en opeenvolgende pauzes de interacties domineren die gebruikers onthouden.

Negen lokale prompts kunnen in 300 milliseconden starten, terwijl de tiende vijf seconden wacht op het laden van een model of een tool. Het gemiddelde blijft onder één seconde, maar het gesprek voelt herhaaldelijk onderbroken. De kwaliteit van de interactie wordt bepaald door de verdeling en volgorde van vertragingen, niet door één centrale waarde over niet-gerelateerde verzoektypen voor de specifieke interactie die de gebruiker onthoudt.

Het gemiddelde verbergt de vorm van de vertragingsverdeling

Een rekenkundig gemiddelde combineert alle verzoeken tot één getal. Enkele zeer trage interacties kunnen worden afgezwakt door veel cache-hits of korte prompts. Percentielen laten zien hoe vaak gebruikers een vertragingsdrempel overschrijden, hoewel zelfs p95 de slechtste één procent kan verbergen.

De latentie-staart laat zien dat een klein aandeel trage componenten de latentie van volledige verzoeken in systemen met vertakkingen kan domineren. Interactieve AI wacht op vergelijkbare wijze op de traagste vereiste stap.

Ook de samenstelling van de werklast is belangrijk. Gezondheidscontroles en gecachete statusaanroepen horen geen latentie-gemiddelde te delen met spraakinteracties, RAG-opvragingen of toolacties. Een laag geaggregeerd gemiddelde kan wiskundig correct en operationeel irrelevant zijn.

Gebruikers ervaren mijlpalen en haperingen, niet alleen voltooiing

Een chatinteractie heeft meerdere klokken: wachttijd in de wachtrij, opvraging, eerste token, tokencadans, wachttijd op een tool en uiteindelijke voltooiing. Een korte totale tijd met een lange stille aanloop kan slechter aanvoelen dan een iets langer antwoord dat meteen begint en gelijkmatig wordt gestreamd.

Een latentieanalyse maakt onderscheid tussen tijd tot het eerste token en de volledige responstijd, omdat deze metingen verschillende aspecten van modelgedrag vertegenwoordigen. Beide zijn nodig om een interactieve beurt te beschrijven.

Zichtbare pauzes hebben ook een volgorde. Een hapering door een tool na meerdere tokens onderbreekt de aandacht anders dan dezelfde wachttijd vóór het eerste token. Een gemiddelde over verschillende fasen wist die interactiestructuur uit en stuurt optimalisatie naar de verkeerde component.

Waar percentielen nog steeds kunnen misleiden

Percentielen schieten tekort wanneer de meettool tijdens haperingen geen nieuw werk meer uitgeeft, alleen voltooide verzoeken meet of niet-gerelateerde tijdvensters samenvoegt. Deze gecoördineerde omissie kan precies de vertragingen onderschatten die gebruikers onder belasting ervaren.

Gil Tene’s bespreking van gecoördineerde omissie laat zien waarom belastingtests het beoogde aanvraagschema moeten behouden in plaats van het indienen van verzoeken te vertragen wanneer het systeem vertraagt. Anders lijken latentie­verdelingen kunstmatig gezond.

De uitleg over latentie in de staart is ook niet langer van toepassing als elke fasetrace snel is, maar gebruikers nog steeds traagheid melden. Het renderen van de interface, netwerkbuffering of vertraagde feedback kan buiten de gemeten servergrens vallen. Meer percentieldashboards helpen niet wanneer de klok te laat start of te vroeg stopt.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Traceer de mijlpalen waarop gebruikers daadwerkelijk wachten

Instrumenteer het in de wachtrij plaatsen, de start van de uitvoering, het voltooien van de opvraging, het eerste token, elke toolaanroep, het laatste token en het renderen door de client met één monotoon trace-ID. Rapporteer p50, p95, p99, maximum en het percentage overschrijdingen van de drempel per interactietype en voor koude versus warme toestand.

Gebruik traces van AI-koude starts om koud laden te onderscheiden van inferentie in stabiele toestand. Houd mislukte en geannuleerde interacties in de dataset in plaats van hun wachttijden uit te sluiten.

Herhaal verzoeken volgens een vast beoogd schema en vergelijk mijlpalen die de client ziet met mijlpalen die de server ziet. Optimaliseer de fase die verantwoordelijk is voor het trage percentiel. Als server- en clienttraces uiteenlopen, onderzoek dan transport en rendering; als alleen koude interacties pieken, pak dan het laden aan in plaats van generatie in stabiele toestand.