Varför ser latensgenomsnitten bra ut medan interaktiv AI känns långsam?

Eva Wong

IceWhale author

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Why Do Latency Averages Look Healthy While Interactive AI Feels Slow? - Zima Store Online

Genomsnittlig latens kan se bra ut samtidigt som interaktiv AI känns långsam, eftersom sällsynta långa väntetider och seriella pauser dominerar de turer som användarna minns.

Nio lokala promptförfrågningar kan börja på 300 millisekunder, medan den tionde väntar fem sekunder på att en modell eller ett verktyg ska laddas. Medelvärdet förblir under en sekund, men konversationen känns ändå upprepade gånger avbruten. Interaktionskvaliteten följer fördelningen och sekvensen av fördröjningar, inte ett enda centralmått över obesläktade förfrågningstyper för den specifika interaktion som personen minns.

Medelvärdet döljer fördröjningsfördelningens form

Ett aritmetiskt medelvärde kombinerar alla förfrågningar till ett enda tal. Några mycket långsamma turer kan jämnas ut av många cacheträffar eller korta promptar. Percentiler visar hur ofta användarna överskrider en fördröjningströskel, även om p95 kan dölja den värsta procenten.

Fördröjningssvansen förklarar att en liten andel långsamma komponenter kan dominera hela förfrågningens latens i system med parallella delanrop. Interaktiv AI väntar på motsvarande sätt på sitt långsammaste obligatoriska steg.

Arbetsbelastningens sammansättning spelar också roll. Hälsokontroller och cachade statusanrop bör inte dela latensgenomsnitt med röstturer, RAG-hämtning eller verktygsåtgärder. Ett lågt aggregerat värde kan vara matematiskt korrekt men operativt irrelevant.

Användarna upplever milstolpar och stopp, inte bara slutförande

En chattur har flera klockor: köväntan, hämtning, tid till första token, tokenintervall, verktygsväntan och slutligt slutförande. En kort total tid med en lång tyst inledning kan kännas sämre än ett något längre svar som börjar direkt och strömmas jämnt.

En latensanalys skiljer tid till första token från den fullständiga svarstiden, eftersom dessa mått representerar olika delar av modellens beteende. Båda behövs för att beskriva en interaktiv tur.

Synliga pauser har också en ordning. Ett verktygsstopp efter flera token avbryter uppmärksamheten på ett annat sätt än samma väntetid före den första token. Ett genomsnitt över faser suddar ut denna interaktionsstruktur och riktar optimeringen mot fel komponent.

När percentiler fortfarande vilseleder

Percentiler blir missvisande när mätverktyget slutar skicka arbete under stopp, bara samplar slutförda förfrågningar eller aggregerar obesläktade tidsfönster. Denna samordnade utelämning kan underskatta exakt de fördröjningar som användarna möter under belastning.

Gil Tenes genomgång av samordnad utelämning visar varför belastningstester måste bevara det avsedda förfrågningsschemat i stället för att sakta ner inskickningen när systemet blir långsammare. Annars ser latensfördelningarna konstgjort hälsosamma ut.

Förklaringen av latenssvansen gäller inte heller om varje fas i spåret är snabb men användarna ändå rapporterar långsamhet. Gränssnittsrendering, nätverksbuffring eller fördröjd återkoppling kan ligga utanför den uppmätta servergränsen. Fler percentilepaneler hjälper inte när klockan startar för sent eller stoppar för tidigt.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

Spåra de milstolpar som användarna faktiskt väntar på

Instrumentera köläggning, start av körning, slutförd hämtning, första token, varje verktygsanrop, sista token och klientrendering med en gemensam monoton spårningsidentifierare. Rapportera p50, p95, p99, maximum och andelen som överskrider tröskeln per interaktionstyp och tillståndet kall kontra varm.

Använd spårningar av AI-kallstarter för att skilja kall laddning från inferens i stabilt läge. Behåll misslyckade och avbrutna turer i datamängden i stället för att utesluta deras väntetider.

Spela upp förfrågningar enligt ett fast avsett schema och jämför milstolpar som är synliga för klienten med dem som är synliga på servern. Optimera den fas som ansvarar för den långsamma percentilen. Om server- och klientspår skiljer sig åt, följ transport och rendering. Om bara kalla turer får toppar, åtgärda laddningen i stället för genereringen i stabilt läge.