Wat is latency bij AI? De tijd tussen vraag en antwoord. Waarom het voor een chatassistent anders ligt dan voor een nachtelijke batch, en hoe je ontwerpt.
Latency is de tijd tussen een vraag en het antwoord van een AI-model: de som van netwerk, wachtrij en rekenwerk. Die tijd is voor elke toepassing anders waard. Een chatassistent moet direct voelen, een nachtelijke batch mag uren doen. EIGHTY8 ontwerpt daarom eerst welke wachttijd een werkstroom aankan, en kiest daarna pas het model.
Wie een chatassistent gebruikt, voelt direct of een systeem traag is. Eerder dan hij een fout kan zien. Die voelbare tijd is latency: alles tussen het indrukken van enter en het begin van het antwoord. Netwerk, wachtrij bij de aanbieder, de grootte van je instructie en het rekenwerk van het model stapelen zich daar op. Geen enkele stap is op zichzelf groot; samen bepalen ze of een antwoord 'meteen' of 'even wachten' heet.
Het principe dat erbij hoort: latency is een ontwerpkeuze, geen eigenschap van een model. Dezelfde taak kan als live-antwoord dienen of 's nachts in een bulk-loop draaien, met precies dezelfde kwaliteit maar een heel ander gevoel. Een assistent die een brief samenvat terwijl de beller wacht, heeft een ander ontwerp nodig dan een systeem dat alvast de morgen voorbereidt terwijl het bureau leeg is.
Twee voorbeelden naast elkaar. Bij een klantenservice-chat telt elke seconde: het antwoord moet binnen enkele ogenblikken beginnen, anders typt de klant weg. Daar hoort een klein, vlot model en een gestreamde weergave. Bij het nachtelijk verwerken van inkomende facturen is een uur stilte irrelevant: daar wint een grootschalige run die alles in één keer, netjes en herhaalbaar, afhandelt.
Latency is de moeite waard om te bestrijden waar een mens op het antwoord zit te wachten in een interactie: chat, bellen, een medewerker die op een voorstel wacht. Daar is de investering in rekenkracht en streaming het echt waard. Elke keer dat iemand 'hij hangt' zegt over een systeem, is een ontwerpfout met een naam.
Het is niet de moeite waard bij achtergrondtaken waar niemand op wacht: daar is de juiste lat niet 'snel' maar 'voorspelbaar en voltooid voor de volgende ochtend'. En er is een grens aan wat optimalisatie oplevert. Een model dat grondig nadenkt, doet dat in tijd. Wie die grondigheid nodig heeft, kiest bewust de langere weg in taken die het toelaten, en versnelt alleen wat live moet.
EIGHTY8 begint elk ontwerp met de vraag: wie wacht er op dit antwoord, en hoe lang mag dat duren? Vanuit die lat kiezen we model, grootte van de invoer en manier van tonen. Live met streaming waar iemand wacht, in batch waar dat kan. Wachttijden worden gemeten per werkstroom, niet op gevoel, zodat een verslechtering zichtbaar is voordat een klant hem meldt.
Zodra hij voelbaar is in een interactie die doorloopt: een chat die blijft hangen, een telefoonassistent die stilvalt, een medewerker die op een voorstel wacht om verder te kunnen. In zulke momenten kost elke extra seconde klanten. De klant typt weg of belt opnieuw. In een nachtelijke verwerking daarentegen merkt niemand een uur stilte; daar is voorspelbaarheid belangrijker dan vaart.
Deels, en vaak minder dan verwacht. Meer rekenkracht helpt bij het rekenwerk zelf, maar niet bij een netwerk-route, een volle wachtrij of een instructie die te lang is. In de praktijk haal je de meeste winst door minder tokens te sturen, antwoorden te streamen, herhaalde vragen te cachen en taken die niet live hoeven te verschuiven. Meer hardware is de duurste van de vier en komt pas daarna.
Dat hangt volledig af van de context, en daarom beloven we het niet los van een werkstroom. Richtlijn: in een dialoog moet het antwoord binnen enkele ogenblikken beginnen en dan zichtbaar doorlopen; in een achtergrondtaak telt alleen dat het klaar is vóór de volgende ochtend. We meten de werkelijke tijd per toepassing en sturen daarop. Een algemeen getal zegt niets over jouw situatie.
Omdat het eerste deel eerder verschijnt, terwijl de totale berekening even lang duurt. De gebruiker leest mee terwijl het model nog schrijft en ervaart de wachttijd als klein, ook al is de complete tekst pas later volledig. Dat is geen truc maar een ontwerp: streaming verplaatst de wachttijd van 'stilte vooraf' naar 'doorloop tijdens'. Voor dialoogtaken is dat verschil de moeite waard; voor achtergrondtaken is het zinloos.
EIGHTY8