Optimera latens för röstagent: Steg-för-steg-guide

Hur snabbt en röstagent svarar beror på den totala fördröjningen mellan att en användare slutar prata och att agenten börjar svara. Den fördröjningen beror sällan på en enda långsam komponent. Den byggs upp över flera oberoende steg, där varje steg bidrar med några tiotals eller hundratals millisekunder. För att minska latensen behöver du veta hur mycket tid varje steg tar.

Att optimera latens för röstagent handlar om att hitta var tiden försvinner och ta tillbaka den steg för steg.

Den här artikeln är ett komplement till översikt om latens. Där förklaras vad latens är, här går vi igenom arkitektur och mätning, så att du får en latensbudget att mäta mot och konkreta åtgärder att ta.

Sammanfattning

• Time-to-first-audio gäller hela pipeline:en, inte bara en modells inferenstid.
• LLM:ens time-to-first-token och endpointing är de två största posterna.
• Att överlappa steg, istället för att köra dem i serie, sparar mest tid.
• Streaming, val av codec och justering av spelarens buffert sparar mätbara millisekunder.
• Du bör mäta per region mot din egen driftsättning och rapportera P50 och P95.

Definiera latensbudget för röstagent

En latensbudget är ett mål för total time-to-first-audio, uppdelat på pipeline:ens olika steg. Varje steg får en tilldelning som tillsammans ska hamna under ditt mål. Att definiera budgeten är första steget, och det är ofta här det blir fel, eftersom utvecklare kan blanda ihop två siffror som ser lika ut men betyder olika saker.

Den första är modellens inferenslatens: tiden det tar för modellen att generera ett svar. För våra Flash-modeller är det ungefär 75 ms för typiskt korta indata, exklusive nätverks- och applikationsöverhead. Det är en intern siffra och bra för att jämföra modeller, men det är inte den tid användaren upplever.

Ur användarens perspektiv fokuserar du på time-to-first-audio (TTFA): tiden från att användaren slutar prata till att de hör första svaret från agenten. TTFA är alltid längre än någon enskild modells inferenslatens, eftersom hela pipeline:en räknas in.

En kaskad röstagent består av fem steg:

• inspelning (mikrofon) -> STT -> LLM -> TTS -> uppspelning

Ljud spelas in från mikrofonen, transkriberas till text, skickas till en språkmodell, modellens text omvandlas till tal igen och det talet buffras och spelas upp. Varje steg lägger till latens, och i flera steg är den största kostnaden inte alltid där du tror.

Här är ett exempel för en engelskspråkig agent med servrar nära användaren. Siffrorna är ungefärliga och inte garantier.

Oftast är de två största latensposterna LLM:ens time-to-first-token och endpointing-fördröjningen i början av kedjan.

Tabellen är ett bra sätt att visualisera pipeline:en, men den antyder att stegen körs strikt i serie, vilket de inte gör. Flera av de viktigaste latensoptimeringarna för röstagent handlar om att överlappa stegen, och det är där största delen av budgeten sparas.

Speech to Text: optimera transkribering och endpointing-latens

Transkribering är det andra steget i pipeline:en, och den verkliga kostnaden är inte själva transkriberingen utan att avgöra när användaren har slutat prata. Det här avsnittet täcker båda delarna för att hjälpa dig optimera latensen.

Transkribering sker innan det når LLM.Scribe v2 Realtime (scribe_v2_realtime) returnerar deltranskriberingar på cirka 150 ms och streamar i ljudbitar, så transkriberingen byggs upp medan användaren fortfarande pratar. Den stöder PCM på 8kHz till 48kHz och mu-law-kodning, vilket är relevant för codec-delen nedan. 150 ms-delarna är billiga.

Den större latenskostnaden är endpointing: när systemet bestämmer att användaren verkligen är klar med sin tur.

Voice Activity Detection (VAD) delar upp talet vid tystnad, och det är där tiden byggs på. Om du väntar t.ex. 700 ms tystnad innan du avslutar turen, har du lagt till 700 ms till varje tur, utöver själva transkriberingen. Den fördröjningen syns inte i ett transkriberingsbenchmark men märks tydligt i en riktig konversation. Det är ofta den största påverkbara latensen i hela pipeline:en, och eftersom den går att styra är det en bra startpunkt.

Endpointing är en avvägning mellan snabbhet och avbrott. Ett kort tystnadsintervall gör att agenten svarar snabbt men riskerar att avbryta användaren vid naturliga pauser. Ett långt intervall är säkert men långsamt. I praktiken är de tre viktigaste sätten att optimera latensen i speech to text:

1. Finjustera tystnadsgränsen:Sätt tystnadsgränsen så lågt som möjligt utan att klippa användarens naturliga pauser, och mät avbrottsfrekvensen i produktion istället för att gissa.
2. Lägg till en fysisk kontrollhändelse: Använd manuell commit-kontroll när din app vet att turen är slut via en annan signal (t.ex. släpp av push-to-talk, ett UI-event), istället för att vänta på VAD-timern.
3. Överlappa med LLM-processer:Skicka deltranskriberingar vidare tidigt. Skicka stabila delar till LLM och justera om sluttranskriberingen skiljer sig – en sorts spekulativ exekvering som döljer endpointing-fördröjningen bakom LLM-bearbetningen.

För mer information finns Scribe v2 Realtime beskriven mer i detalj på sidan om speech to text-funktioner och på produktsidan för realtids speech to text.

LLM:ens latensbidrag

Språkmodellen är oftast den största enskilda posten i TTFA, så det är också där överlappning ger mest effekt vid latensoptimering. Den viktiga insikten är att agenten inte behöver hela svaret innan den börjar prata.

Det mönster som sparar mest latens är att streama tokens från LLM och skicka dem till TTS direkt, uppdelat vid menings- eller satsgränser. Logiken är att buffra tokens till en mening är klar, sedan syntetisera den medan nästa genereras:

const SENTENCE_END = /(?<=[.!?])\s+/;

async function* speakLlmStream(tokens: AsyncIterable<string>) {
  let buffer = "";
  for await (const token of tokens) {
    buffer += token;
    const parts = buffer.split(SENTENCE_END);
    buffer = parts.pop() ?? ""; // keep the incomplete fragment
    for (const sentence of parts) {
      if (sentence.trim()) yield* synthesize(sentence.trim());
    }
  }
  if (buffer.trim()) yield* synthesize(buffer.trim());
}

async function* synthesize(text: string) {
  const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
    text,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  yield* stream;
}

För längre samtal, använd helst TTS WebSocket så att en öppen anslutning kan ta emot text stegvis utan att behöva sätta upp anslutningen på nytt för varje mening. Endast tiden då modellen faktiskt genererar ljud räknas mot din samtidighetsgräns, så en öppen men inaktiv WebSocket är i princip gratis.

Text to Speech: streaming och röstval

Text to speech är steget där du kan mäta latensen mest exakt. Här finns två huvudfaktorer: hur du streamar ut ljudet och vilken röst du väljer.

Flash v2.5 (eleven_flash_v2_5) är modellen att använda i en agent. Den ger cirka 75 ms inferens för korta indata, stöder 32 språk och tar emot upp till 40 000 tecken per förfrågan.

75 ms gäller bara inferensen. TTS TTFA-posten i budgeten ovan är större eftersom nätverksrundtur och serverschemaläggning tillkommer.

Den största faktorn här är streaming. Om du begär hela ljudet och väntar, får användaren vänta på hela klippet innan något hörs. Om du streamar hör användaren första delen direkt när den är klar, och resten kommer medan de redan lyssnar. Streaming gör inte modellen snabbare, men användaren får ljudet medan det fortfarande genereras.

streaming-guiden går igenom HTTP-streaming, och realtids WebSocket-guiden visar WebSocket-flödet du vill använda när du skickar tokens från en LLM.

Initiera klienten en gång och återanvänd den för varje anrop nedan:

import { ElevenLabsClient } from "@elevenlabs/elevenlabs-js";

const elevenlabs = new ElevenLabsClient({ apiKey: process.env.ELEVENLABS_API_KEY });

Sätt sedan upp en stream och vidarebefordra den direkt:

const stream = await elevenlabs.textToSpeech.stream("JBFqnCBsd6RMkjVDRZzb", {
  text: "Your call is connected. How can I help today?",
  modelId: "eleven_flash_v2_5",
  outputFormat: "mp3_44100_128",
});

for await (const chunk of stream) {
  // forward each chunk to your audio sink as it arrives
}

Den andra faktorn är röstvalet, som också påverkar latensen. Standardröster, syntetiska röster och Instant Voice Clones (IVC) syntetiserar snabbare än Professional Voice Clones (PVC), eftersom PVC har mer komplex modell och därmed extra overhead. För en agent med strikta latenskrav är kombinationen Flash och IVC eller standardröst det snabbaste alternativet.

Val av storlek på streaming-delar

När tokens skickas till TTS och ljudet kommer tillbaka, är nästa beslut hur stora bitarna ska vara och hur mycket spelaren buffrar innan den startar.

Mindre delar når spelaren snabbare och minskar first-byte-latensen, men ger fler meddelanden och lite mer overhead per del. Större delar är effektivare att skicka men gör att användaren får vänta längre på första biten. För interaktiva agenter är det bäst att använda mindre delar i början av yttrandet, eftersom det är första delen användaren väntar på; senare delar kommer medan ljudet redan spelas och deras storlek spelar mindre roll.

Spelaren står för en stor del av återstående latens. De flesta ljudspelare börjar inte spela vid första byten, utan buffrar lite för att undvika hack om streamen saktar in. En buffert på 500 ms är vanligt och läggs direkt på upplevd latens. Att minska bufferten ger lite högre risk för hack men lägre TTFA, och rätt värde beror på nätverksjitter mellan server och klient:

• På en stabil anslutning (serveruppspelning, klient på samma plats) är en buffert på 50–150 ms oftast säkert och minskar TTFA märkbart.
• På en ostadig mobil- eller regionöverskridande anslutning förhindrar en större buffert hörbara glapp, vilket är värre än latensen de orsakar.

Exakt konfiguration här beror på ditt användningsområde och vad du prioriterar.

Val av codec

Vart ljudet ska skickas avgör vilken codec du ska välja. Vi returnerar format som mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 och ulaw_8000. Om du matchar transportens ursprungsformat slipper du transkoda, vilket hjälper till att minska latensen.

För telefoni, som Twilio och liknande, använd ulaw_8000. Telefonnätet är 8kHz mu-law hela vägen, så om du begär det direkt slipper du transkoda och matchar vad operatören förväntar sig. Det finns ingen vinst i att syntetisera ljud med högre kvalitet som ändå direkt nedsamplas av nätet – du lägger bara till latens utan att höra någon skillnad.

För WebRTC och uppspelning i webbläsare, använd PCM (pcm_24000 eller pcm_16000) eller ett MP3-format. PCM är okomprimerat, så det behövs ingen avkodning på klienten, vilket tar bort lite latens per del och är smidigt om du matar en Web Audio-pipeline direkt. MP3 är mer kompakt över nätet, vilket är bra på begränsade anslutningar, men kräver en lätt avkodning på klientsidan.

Geografi och nätverksavstånd

Alla optimeringar ovan förutsätter att datan inte har långt att resa. Geografin sätter lägstanivån för din latensbudget, så det är värt att titta på innan du justerar något annat.

Vi hanterar förfrågningar från kluster i Nordamerika, Europa och Sydostasien och dirigerar automatiskt varje förfrågan till närmaste kluster. Nätverksrundturen över internet är oftast 20–200 ms beroende på avstånd, och det går inte att minska utan att flytta infrastrukturen.

En agent som känns blixtsnabb i San Francisco, nära ett nordamerikanskt kluster, kan kännas långsam för en användare i Sydasien vars trafik korsar ett hav två gånger per tur.

Lösningen är att placera dina applikationsservrar nära användarna, inte bara nära oss. Om dina användare är i Europa, kör din agent-backend i Europa så att sträckan mellan användare och din server är kort; vår routing hanterar sedan sträckan mellan din server och modellen från ett närliggande kluster.

Mät latensen för röstagent själv

Siffrorna i latensbudgeten ovan är ungefärliga riktvärden. De siffror du ska använda bör komma från ett skript som detta, kört mot din egen driftsättning.

Instrumenteringen nedan mäter TTFA för TTS-steget isolerat, alltså tiden från förfrågan till första ljudbiten, över många försök, och rapporterar percentiler. Kör det från samma region som dina servrar, inte från din utvecklingsdator. Det förutsätter elevenlabs-klienten från tidigare:

const VOICE_ID = "JBFqnCBsd6RMkjVDRZzb";
const TEXT = "Thanks for waiting. I have pulled up your account and I can help with that now.";
const TRIALS = 50;

async function measureTtfa(): Promise<number | null> {
  const start = performance.now();
  const stream = await elevenlabs.textToSpeech.stream(VOICE_ID, {
    text: TEXT,
    modelId: "eleven_flash_v2_5",
    outputFormat: "mp3_44100_128",
  });
  for await (const _chunk of stream) {
    return performance.now() - start; // first chunk -> stop the clock
  }
  return null;
}

function percentile(values: number[], p: number): number {
  const v = [...values].sort((a, b) => a - b);
  const k = (v.length - 1) * (p / 100);
  const lo = Math.floor(k);
  const hi = Math.min(lo + 1, v.length - 1);
  return v[lo] + (v[hi] - v[lo]) * (k - lo);
}

const samples: number[] = [];
for (let i = 0; i < TRIALS; i++) {
  const ttfa = await measureTtfa();
  if (ttfa !== null) samples.push(ttfa);
  await new Promise((r) => setTimeout(r, 300)); // space requests, don't measure your own queueing
}

console.log(`trials: ${samples.length}`);
console.log(`P50:    ${percentile(samples, 50).toFixed(0)} ms`);
console.log(`P95:    ${percentile(samples, 95).toFixed(0)} ms`);

Några saker att tänka på:

• Rapportera P50 och P95:Fokusera på dessa istället för medelvärde. Medelvärdet döljer svansen, och det är svansen som gör att en agent känns opålitlig. P95 är upplevelsen av en tur på tjugo.
• Experimentera utifrån plats: Kör samma skript från varje region du betjänar och håll resultaten isär.
• Sprid ut förfrågningarna:Sprid ut dina förfrågningar (setTimeout ovan). Om du skickar alla samtidigt mäter du din egen kö, inte tjänsten. När samtidighetsgränsen överskrids köas förfrågningar efter prioritet, vilket oftast lägger till ca 50 ms, och över kapacitet får du HTTP 429.
• Mät hela latenskedjan:Använd samma mönster för att mäta övriga steg. Mät STT-slut, LLM first-token och spelarstart med performance.now(), så kan du fylla hela budgettabellen med dina egna siffror och se vilket steg du ska börja med.

Genom att följa dessa tips kan du själv mäta latensen för röstagenten. Då får du en tydlig lista på vad du ska prioritera först.

Vad minskar latensen för röstagent mest?

Vill du ha några snabba åtgärder att fokusera på? Här är de mest effektiva förändringarna.

Ungefär i ordning efter effekt kan du använda följande metoder för att minska agentens latens:

• Starta LLM-arbetet på stabila STT-delar för att dölja endpointing-fördröjningen.
• Streama LLM-tokens till TTS vid meningsgränser så att syntesen av mening ett överlappar genereringen av mening två.
• Streama TTS-ljud till spelaren och minska spelarens buffert till minsta möjliga som ditt nätverk klarar.
• Använd Flash plus standardröst eller IVC för lägsta TTS-latens, och matcha codec till transporten (ulaw_8000 för telefoni, PCM eller MP3 för webbläsare/WebRTC).
• Placera dina servrar nära användarna och mät per region, eftersom nätverkssträckorna är verkliga och olika långa.

För fler specifika tekniker, se utvecklarguiden för latensoptimering. För ett komplett exempel, se API-quickstart och streaming-guiden.

Vill du ha snabbare tillgång till finjusterade agentkedjor?ElevenAgents har denna pipeline med överlappande optimeringar redan på plats.

Bygg röstagenter med låg latens med ElevenAgents

Att optimera latens för röstagent kräver att du mäter varje steg och sedan överlappar stegen så att de långsammaste körs parallellt med annat arbete. Du kan bygga och justera den kedjan själv i flera steg med hjälp av mönstren ovan, eller börja direkt med en pipeline där latensoptimeringar redan finns.

ElevenAgents implementerar hela kedjan, från streaming STT till token-för-token LLM-handoff till Flash TTS, med överlappande tekniker inbyggda. Istället för att börja från noll kan du justera trösklar för den prestanda som är viktigast för dig.

Kom igång genom att använda ElevenAgents för att skapa en agent idag eller kontakta säljteamet för mer information.

Vanliga frågor om latensoptimering för röstagent