TTFS frem for TTFT i voice ifølge kilderne
MarkTechPost skriver, at time to first token (TTFT) ofte bruges til at vælge inference-API til voice, men at det kan vildlede i taleapplikationer. Begrundelsen, som de angiver, er, at TTFT markerer, hvornår genereringen starter, mens text-to-speech typisk først leverer naturlig lyd, når der foreligger en fuld sætning eller et fuldt led. MarkTechPost henviser i den forbindelse til IBM’s TTFT-definition som et startøjeblik – nyttigt teknisk, men ikke nødvendigvis lig med det øjeblik, brugeren hører meningsfuld tale.
Pointen i MarkTechPosts læsning er forskellen mellem “første token” og “første hørbare sætning”. Ifølge deres artikel er det netop forskellen, der afgør, om en agent opleves som samtalende eller hakkende. Derfor er TTFT alene et ufuldstændigt mål, når formålet er naturlig voice-interaktion.
TTFS som brugerrelevant mål i Mark
TechPosts gengivelse
I samme artikel refererer MarkTechPost til LiveKit, der bruger time to first sentence (TTFS) som et mere brugerrelevant mål for voice. MarkTechPost beskriver adskillelsen sådan: TTFT angiver, hvornår generering begynder, mens tokens per second handler om, hvor hurtigt den første sætning fuldføres. Ifølge MarkTechPosts gengivelse kan en udbyder have lav TTFT og alligevel fremstå langsom for brugeren, hvis den første sætning afsluttes sent – og omvendt.
MarkTechPost placerer det brugerrelevante nulpunkt omkring første naturlige sætning, fordi stilheden først brydes her på en måde, der føles dialogisk. De fremhæver, at målingen er mere omstændelig, men mere retvisende for voice.
Latency-budgettet som Mark
TechPost gengiver det
MarkTechPost rapporterer, med henvisning til LiveKits materiale, et praktisk end-to-end mål for én voice-tur på cirka 700–1.200 ms. I deres gennemgang beskrives følgende typiske størrelsesordener pr. komponent: STT/ASR omkring 100–200 ms, LLM-streaming cirka 300–500 ms, TTS cirka 100–200 ms og netværk/WebRTC cirka 50–150 ms. Summen giver et pejlemærke for teams, forudsat samme målemetode, som MarkTechPost også påpeger har betydning for sammenlignelighed.
MarkTechPost sætter tallene i perspektiv ved at referere til Dailys arbejde om den hurtigste voice-bot med en menneskelig baseline omkring 500 ms og en mærkbar pause omkring 800 ms, samt til Kwindla Hultman Kramers anbefaling om at stile efter cirka 800 ms median voice-to-voice og acceptere omtrent 1.500 ms i tidlige proof-of-concepts. Disse tal gengives, som MarkTechPost citerer dem.
Hvad man kan generalisere – og hvad der skal måles
Udsagnet om, at TTS “kræver” en fuld sætning, gengives i MarkTechPosts afgrænsning: Det beskriver praksis for mange systemer og forklarer forskellen mellem TTFT og første hørbare sætning. MarkTechPost fremhæver ikke en fælles, offentlig dokumenteret standard på tværs af alle udbydere; derfor er deres anbefaling at måle TTFS i stedet for at antage universel adfærd.
MarkTechPost fremhæver også, at benchmarks kan blive skæve på grund af metodevalg: forskelle i workloads, hvor i kæden man starter/stopper uret, og om netværksrundtur regnes med. Når grafer og tal sammenlignes på tværs, bør læseren derfor kontrollere, hvordan målepunkter er defineret i den enkelte kilde – sådan som MarkTechPost selv gør opmærksom på.
Eksempel på forskel mellem TTFT og TTFS
Som en konceptuel illustration – ikke som måling – kan man forestille sig to profiler: En model A med lav TTFT men lav tokens per second og en model B med højere TTFT men høj tokens per second. For en kort åbningssætning vil B i praksis ofte levere første hele sætning hurtigere. Det er den skelnen, MarkTechPost lægger til grund for at vurdere TTFS som mere brugerrelevant.
MarkTechPosts hovedpointe her er, at en lav TTFT kan være et nyttigt diagnosetegn, men ikke i sig selv siger noget om, hvornår brugeren hører stabil tale. Derfor anbefales at se TTFT i sammenhæng med, hvor hurtigt den første sætning fuldføres.
Hvilke målinger kilderne fremhæver
For at afspejle brugerens oplevelse argumenterer MarkTechPost for en bredere målepakke. I deres artikel indgår blandt andet:
- TTFT som teknisk startmarkør – typisk målt som tidsrummet fra anmodning til første token, som de beskriver det.
- TTFS – tid til første hele, oplæselige sætning.
- Tokens per second for den første sætning/svar.
- ASR-, LLM- og TTS-latenser samt netværk/WebRTC-transport i et end-to-end-perspektiv.
MarkTechPost understreger, at testopsætning bør beskrives tydeligt, så målinger kan sammenlignes: hvor måles fra (klient/server), om netværk er medtaget, samt forskelle i workload/profil.
Implementeringsgreb som gengivet i MarkTechPost
MarkTechPost peger på praksisområder, der kan nedbringe TTFS i voice-oplevelsen, med kendte afvejninger. De fremhæver især:
- Pipelining, hvor TTS kan starte på sikre delklip, før hele svaret er genereret. Det kan reducere tiden til første sætning, men kræver præcise grænser for at undgå hakkende tale.
- Partiel syntese/chunking, som kan fungere forskelligt på tværs af modeller og stemmer. MarkTechPost betoner derfor behovet for egne målinger pr. sprog og stemme.
- Geografisk placering og netværksovervejelse for taleled (ASR/TTS) og transport, som afspejles i deres opdeling af latency-budgettet inkl. WebRTC.
Disse afvejninger er fremhævet som praksisområder i MarkTechPosts artikel og relaterede materiale, som de henviser til.
Kort metodenote om målepunkter
MarkTechPost gør specifikt opmærksom på, at målepunkter varierer mellem kilder: Nogle måler TTFT på serversiden, andre på klientsiden; nogle inkluderer netværksrundtur, andre ikke. Derudover kan forskellige workload-profiler og promptlængder påvirke både TTFT og tokens per second. Derfor anbefaler de at spore hvert tal til kilde og metode, før resultater sammenlignes.
I MarkTechPosts egen artikel fremgår, at de dækker hele stakken – LLM, STT/ASR, TTS og speech-to-speech – og åbent refererer til bagvedliggende materialer, herunder LiveKits beskrivelser samt Dailys menneskelige baseline og Kwindla Hultman Kramers tommelfingerregler, sådan som MarkTechPost gengiver det.
Sikkerhedsnote om gateways
VentureBeat beskriver, at gateways ofte er det første styringslag, teams vælger i agent-deployments, men også et lag mange ikke er klar til at drive. VentureBeat refererer i den sammenhæng til CISA’s katalog over kendt udnyttede sårbarheder, hvor en LiteLLM-sårbarhed blev tilføjet i juni efter udnyttelse i praksis. Ifølge VentureBeats dækning muliggjorde fejlen kommandoer på værten via gatewayen, og i en kædet variant uden legitimationsoplysninger. Det illustrerer risici i gateway-laget, som bør håndteres eksplicit.
Hvad læsere kan tage med – med kildeangivelse
På tværs af de citerede kilder i MarkTechPost er konklusionen, at TTFT alene ikke er tilstrækkeligt for voice. MarkTechPost gengiver LiveKits TTFS-ramme og et samlet budget i størrelsesordenen 700–1.200 ms for en voice-tur, sammen med per-lag-tal, som giver en praktisk referenceramme. Dailys baseline og Kwindla Hultman Kramers anbefalinger – gengivet i MarkTechPost – sætter tallet i relation til menneskelig samtale.
Næste skridt, som MarkTechPost argumenterer for, er at måle TTFS og tokens per second side om side med TTFT, dokumentere metode og netværk, og gennemføre end-to-end-målinger, der kan reproduceres. Så kan “lavest TTFS” give mening i en retvisende sammenligning, forudsat samme måleprofil.
