Varje leverantörsblogg om "röst-AI med låg latens" handlar egentligen om en enda ruta i pipelinen. En ny röstmodell som kapade 80 ms från syntesen. En justering av endpointing. Ett cache-trick. Vart och ett är verkligt — och vart och ett är värdelöst om de andra fem stegen i din samtalsväg äter 1 200 ms medan du firar de 80.
Latens är en budget, inte en funktion. Den som ringer hör ett enda tal: tystnaden mellan att de slutar tala och att din agent börjar. Det talet är summan av varje steg från mikrofon till högtalare, plus nätverket du inte kontrollerar. Det här är modellen från början till slut — vad varje steg kostar, var millisekunderna faktiskt gömmer sig, och var streaming, endpointing och cachning verkligen köper dig tid jämfört med var de bara flyttar problemet.
Därför är latens gränsen mellan "AI" och "ett riktigt samtal"
Mänskligt turtagande har en rytm. I naturliga samtal är pausen mellan talare i genomsnitt cirka 200 ms, och människor börjar planera sitt svar innan den andra personen talat färdigt. När en telefonagent lämnar 1,5 sekunders dödtid efter varje mening tänker den som ringer inte "imponerande AI". De tänker att linjen bröts, de talar i mun på agenten, eller så lägger de på.
De praktiska tröskelvärden vi utgår från i designen:
- Under ~500 ms svarstid känns som ett samtal. Den som ringer märker knappt pausen.
- 500–800 ms är acceptabelt men hörbart "assistentlikt". Fungerar bra för många användningsfall.
- Över ~1 000 ms bryter rytmen. Den som ringer avbryter, upprepar sig, och förtroendet urholkas.
Det där målet under en sekund är hela poängen. Och det är inte en enskild komponents uppgift — det är budgeten du fördelar över hela stacken.
Latensbudgeten: varje steg från mikrofon till högtalare
Så här ser rundturen ut för en enda samtalstur. Ungefärliga produktionsintervall för en välbyggd agent i ett telefonsamtal:
| Steg | Vad som händer | Typisk budget |
|---|---|---|
| Ljudingång / nätverk in | Ljudet från den som ringer når din STT (PSTN → SIP → din edge) | 50–150ms |
| STT (streaming) | Tal → partiell + slutlig transkription | 100–300ms |
| Endpointing | Att avgöra att den som ringer faktiskt slutade | 200–800ms |
| LLM TTFT | Prompt → första utdatatoken (time to first token) | 200–600ms |
| TTS första byte | Första textstycket → första ljudet ut | 80–300ms |
| Ljudutgång / nätverk ut | Syntetiserat ljud tillbaka till den som ringer | 50–150ms |
Lägg ihop dem så hamnar du på ungefär mellan 700 ms och 2,4 s. Spridningen är enorm — och lägg märke till vad som dominerar den: endpointing och LLM TTFT, inte de STT- eller TTS-modeller som alla benchmarkar.
Två regler följer direkt av den här tabellen:
- Optimera den största posten först. Att byta ut en TTS på 120 ms mot en på 90 ms är brus om din endpointer väntar 700 ms. Mät innan du optimerar.
- Stegen överlappar när du streamar. Budgeten ovan är det seriella värsta fallet. Streaming låter STT, LLM:en och TTS köra parallellt i stället för från början till slut — och det är där de flesta av dina verkliga vinster kommer ifrån (nedan).
Endpointing och tystnadsdetektering: de mest underskattade 500 millisekunderna
Endpointing är beslutet: har den som ringer avslutat sin tur, eller bara pausat för att andas? Det är den enskilt största påverkbara delen av latensen, och den svåraste avvägningen i stacken.
Naiv metod: vänta på N millisekunder av tystnad och kör sedan. Sätt N för lågt (säg 200 ms) och du avbryter folk mitt i meningen — brutalt när någon läser upp ett 16-siffrigt kortnummer eller säger "min adress är... Ekgatan 42". Sätt N för högt (900 ms) och varje tur känns trög.
Det som faktiskt fungerar i produktion är adaptiv, semantisk endpointing snarare än en fast tystnadstimer:
- VAD (voice activity detection) ger dig den råa signalen "finns det ljudenergi" — snabbt, men dumt när det gäller intention.
- Semantisk endpointing använder den partiella transkriberingen för att bedöma om yttrandet är komplett. "Mitt kontonummer är" är uppenbarligen oavslutat; "jag vill säga upp mitt konto" är en komplett tanke. En modell som läser den partiella texten kan reagera tidigare på kompletta yttranden och vänta längre mitt i ett nummer.
- Kontextmedvetna timeouts. När du precis har bett om ett telefonnummer, vidga tystnadsfönstret och behandla inte pauser mellan siffror som slut på turen. Koppla tröskelvärdet för endpointing till det fält du samlar in.
Får du det här rätt återvinner du 300–500 ms på de flesta turer utan att någonsin avbryta den som ringer. Får du det fel kommer inget modellbyte att rädda dig.
Streama allt: den gratis latensvinst du lämnar på bordet
Den största lögnen i den seriella budgettabellen är att stegen sker efter varandra. Det borde de inte. Streama vid varje gräns så kollapsar pipelinen:
- Partiella transkriberingar. Vänta inte på det slutgiltiga STT-resultatet. Mata partialerna till din endpointer och förvärm till och med LLM-kontexten så att du inte startar från kallt när den som ringer slutar prata.
- Token-streaming från LLM:en. Tid till första token är det som spelar roll, inte tid till fullständigt svar. Så snart den första satsen streamas ut, skicka den till TTS. Du behöver inte hela svaret för att börja tala.
- TTS-chunkning. Syntetisera och börja spela upp den första meningen medan LLM:en fortfarande genererar den tredje. Det är första ljudbyten, inte hela ljudklippet, som är siffran som räknas.
Gjort på rätt sätt hör den som ringer de första orden i svaret medan LLM:en fortfarande skriver resten av det. Det är så en stack vars seriella budget summerar till 1,8 s levererar ett upplevt svar på 600 ms. Streaming är inte en optimering du lägger till senare — det är arkitekturen du utgår från.
En reservation: att streama TTS mitt under generering innebär att du binder dig till ord innan hela svaret finns. Om din LLM kan komma att korrigera sig själv ("faktiskt, låt mig kolla det — nej, du har rätt") har du redan sagt fel halva. Begränsa modellen till svar som den binder sig till på en gång, eller buffra den första satsen tills meningsbyggnaden är stabil.
Ljudcachning och förvärmning: verkliga vinster, verkliga fallgropar
Cachning är där Vapi-liknande "vi gjorde det snabbare"-inlägg bor, och det är genuint användbart — med vassa kanter.
Vad som är säkert att cacha eller förvärma:
- Fasta prompter och standardfraser. Hälsningar, väntemeddelanden, upplysningar, "var god vänta medan jag tittar upp det". Syntetisera dessa i förväg en gång. Noll TTS-latens vid körning.
- Uppvärmning av anslutningar. Håll STT-/LLM-/TTS-socketarna öppna och modellerna varma så att samtalets första tur inte betalar kallstartsskatt. Bara detta kan spara hundratals millisekunder på tur ett.
- Förutsägbara utfyllnadsfraser. Ett kort, naturligt "låt mig kolla det åt dig" som spelas upp medan ett långsamt verktygsanrop körs maskerar backend-latens som den som ringer annars skulle höra som dödtid.
Vad som går sönder om du cachar det:
- Allt med dynamiska data. Cacha "Ditt saldo är [X]" som en mall och du kommer förr eller senare att läsa upp fel saldo för fel person. Cacha bärarfrasen, syntetisera det variabla fältet live.
- Personaliserat eller regelkänsligt ljud. Namn, kontouppgifter, offererade priser — syntetisera nytt, varje gång.
- Föråldrade röst-/modellversioner. Ett cachat klipp från en gammal TTS-röst intill ett live-genererat är skärande uppenbart mitt i en mening. Versionshantera dina cachenycklar mot röstmodellen.
Cachning ger dig mest på de förutsägbara delarna av ett samtal. Den gör ingenting för den dynamiska resonemangsturen — vilket är precis därför den inte kan vara hela din latensberättelse.
Telefoni och nätverksverklighet: den sista milen du inte äger
Du kan finjustera varje modell till perfektion och ändå leverera en trög agent, eftersom ett telefonsamtal går över infrastruktur du inte kontrollerar.
- PSTN och SIP lägger till verklig tid. Det publika telefonnätet och SIP-trunking introducerar transportfördröjning innan din STT ens ser ljudet. Kodektranskodning (t.ex. till/från G.711) lägger till lite mer.
- Jitter och paketförlust. Uppringare på mobilnät, dålig Wi-Fi och överbelastade operatörer levererar ljud ojämnt. Din jitterbuffert jämnar ut uppspelningen men lägger till latens för att göra det — ännu en avvägning att finjustera, inte eliminera.
- Geografi. Om din inferens körs i us-east medan din uppringare och telefonileverantör finns i Europa har du lagt till en transatlantisk tur och retur till varje tur i samtalet. Placera din mediaväg tillsammans med dina uppringare och dina modellendpoints.
- Mediavägen spelar lika stor roll som modellen. Bryggning mellan WebRTC och SIP, SBC-routing och var din mediaserver står kan kosta eller spara mer än ett modellbyte. Det här är infrastrukturteknik, inte prompt engineering.
Slutsatsen: budgetera 100–300 ms för nätverk och telefoni som du inte kan optimera bort, och se till att de millisekunder du kan styra över inte slösas bort på en mediaväg som studsar genom tre regioner.
Att mäta latens i turtagning i produktion (siffran som betyder något)
Du kan inte optimera det du inte mäter, och det mått som betyder något är inte någon enskild komponents benchmark. Det är slut på användarens tal till start av agentens ljud — mätt i produktion, på riktiga samtal, vid den percentil som gör ont.
- Instrumentera hela turen fram och tillbaka. Tidsstämpla: sista ljudramen från uppringaren → endpoint utlöst → första token från LLM → första byte från TTS → första ljudramen ut. Logga varje steg för varje tur så att du kan se vilken box som sprängde budgeten när ett samtal kändes långsamt.
- Titta på p95, inte på snittet. Din genomsnittliga latens kan ligga på fina 550 ms medan p95 är 1,8 s — och det är turerna vid p95 som får uppringare att lägga på. Genomsnitt döljer de samtal du förlorar.
- Följ barge-in / avbrottsfrekvens. Om uppringare ofta pratar över din agent utlöses din endpointer för sent eller så startar ditt svar för långsamt. Det är ett latenssymtom förklätt till ett UX-mått.
Skeppa instrumenteringen innan du finjusterar. Varje påstående om att "vi sänkte latensen" som inte backas upp av p95-mätning i produktion är en gissning.
Interna länkar
- Så byggde vi vår voice AI-pipeline — STT-val: Whisper vs Deepgram
- Åtgärda SIP-latens i AI-lösningar för callcenter
- Brygga WebRTC och SIP: överlämningar med låg latens för AI-röstagenter
- AI-röstagenter för företag: arkitektur och ROI
- Så hanterar du höga samtalsvolymer utan att anställa fler agenter (2026)
FAQ
Vad är ett bra latensmål för en voice AI-agent i produktion? Sikta på under 800 ms från början till slut (från att uppringaren slutar tala till att agentens ljud börjar), och betrakta under 500 ms som målet för en genuint konversationell känsla. Mät vid p95, inte snitt — det är den långsamma svansen som driver att folk lägger på.
Vilken del av voice AI-pipelinen orsakar mest latens? Vanligtvis endpointing och LLM:ens tid till första token, inte de STT- eller TTS-modeller som de flesta benchmarks fokuserar på. Endpointing kan lägga till 200–800 ms på egen hand, så det är det första stället att titta på innan du byter ut någon modell.
Minskar ljudcachning voice AI-latens? Ja, för fast innehåll — hälsningsfraser, upplysningar, väntemeddelanden och utfyllnadsfraser kan förhandssyntetiseras för nästan noll latens vid körning. Det gör ingenting för dynamiska resonemangsturer, och att cacha något med personlig eller variabel data riskerar att läsa upp fel information för en uppringare.
Varför känns min röstagent trög trots en snabb modell? För att latensen är summan av hela pipelinen plus telefoni som du inte styr över. En snabb TTS hjälper inte om din endpointer väntar 700 ms, din LLM streamar långsamt eller din mediaväg studsar mellan regioner. Instrumentera varje steg och åtgärda den största boxen först.
Finn är byggt latens-först — streamande STT, semantisk endpointing och överlämning från token till TTS finjusterad för att nå turtagning under en sekund på riktiga telefonsamtal, inte på benchmark-klipp. Se hur Finns röstagenter hanterar samtalsvolym i produktion utan död luft.
