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

Hur snabbt en röstagent reagerar avgörs av den totala fördröjningen mellan att en användare slutar tala och att agenten börjar svara. Fördröjningen orsakas sällan av en enda långsam komponent. Den byggs upp över flera oberoende steg, där vart och ett bidrar med några tiotal eller hundratal millisekunder. För att minska den behöver du veta hur mycket tid varje steg tar.

Att optimera röstagenters latens handlar om att hitta var tiden försvinner och återvinna den steg för steg.

Den här artikeln fungerar som ett komplement till den konceptuella översikten över latens. Där den sidan förklarar vad latens är, tar den här upp arkitektur och mätning. Du får en latensbudget att mäta mot och konkreta åtgärder att vidta.

Sammanfattning

• Tid till första ljudet omfattar hela pipelinen, inte bara ett enskilt modells inferenstid.
• LLM:ets tid till första token och endpointing är de två största posterna.
• Genom att överlappa stegen i stället för att köra dem i serie återvinner du större delen av budgeten.
• Streaming, val av codec och justering av spelarens buffert sparar var för sig mätbara millisekunder.
• Du bör mäta per region mot din egen driftsättning och rapportera P50 och P95.

Definiera latensbudgeten för röstagenten

En latensbudget är ett mål för total tid till första ljudet, fördelat mellan pipelinens steg. Varje steg får ett utrymme, och summan måste hamna under ditt mål. Att definiera den är första steget, och det är också här latensarbetet oftast går fel eftersom utvecklare kan blanda ihop två siffror som liknar varandra men betyder olika saker.

Den första är modellens inferenslatens: tiden en modell lägger på att generera utdata. För våra Flash-modeller är den cirka 75 ms för typiska korta indata, exklusive nätverks- och applikationsomkostnader. Det är en intern siffra som är användbar för att jämföra modeller med varandra. Det är inte siffran användaren upplever.

Ur användarens perspektiv fokuserar du på tid till första ljudet (TTFA): tiden från att användaren slutar tala tills hen hör det första ljudprovet i agentens svar. TTFA är alltid större än en enskild modells inferenslatens, eftersom den summerar hela pipelinen.

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

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

Ljud hämtas från mikrofonen, transkriberas till text, skickas till en språkmodell, modellens text syntetiseras tillbaka till tal och talet buffras och spelas upp. Varje steg tillför latens, och i flera steg är den största kostnaden inte den du förväntar dig.

Här är ett genomarbetat exempel för en engelskspråkig agent med servrar på rimligt avstånd från användaren. Siffrorna är illustrativa intervall, inte garantier.

Vanligtvis är LLM:ets tid till första token och endpointingfördröjningen i början av kedjan de två största latensposterna. 

Tabellen är ett bra sätt att visualisera pipelinen, men den antyder att stegen körs strikt i serie, vilket de inte gör. Flera av de viktigaste optimeringarna av röstagenters latens bygger på att överlappa stegen, och det är där större delen av budgeten nedan återvinns.

Speech to Text: optimera latens för transkribering och endpointing

Transkribering är det andra steget i pipelinen, och dess verkliga kostnad är inte själva transkriberingen utan att avgöra när användaren har slutat tala. Det här avsnittet tar upp båda aspekterna för att hjälpa dig optimera röstagentens latens.

Transkribering sker innan den når LLM:et. Scribe v2 Realtime (scribe_v2_realtime) returnerar partiella transkriberingar på cirka 150 ms och strömmar ljud i segment, så transkriptet skapas medan användaren fortfarande talar. Den har stöd för PCM från 8 kHz till 48 kHz och mu-law-kodning, vilket är relevant för codec-avsnittet nedan. De partiella resultaten på 150 ms är billiga.

Den större latenskostnaden är endpointing: ögonblicket då systemet avgör att användaren faktiskt har avslutat sin tur.

Voice Activity Detection (VAD) segmenterar tal utifrån tystnad, och det är där tiden byggs upp. Om du till exempel väntar på 700 ms tystnad innan du förklarar turen avslutad, har du lagt till 700 ms på varje tur utöver själva transkriberingen. Fördröjningen syns inte i ett riktmärke för transkriberingsnoggrannhet, men märks tydligt i ett riktigt samtal. Den är ofta den största styrbara latensen i hela pipelinen, och eftersom den går att styra är den en bra startpunkt.

Endpointing är en avvägning mellan snabb respons och avbrott. En kort tystnadströskel får agenten att svara snabbt, men riskerar att avbryta användaren mitt i en mening under en naturlig paus. En lång tröskel är säker men långsam. I praktiken finns det tre ändringar som optimerar latensen i Speech to Text:

1. Finjustera tystnadströskeln: Sänk tystnadströskeln till det lägsta värde som inte kapar användarnas naturliga pauser. Mät sedan avbrottsfrekvensen i produktion i stället för att gissa.
2. Lägg in en fysisk kontrollhändelse: Använd manuell commit-kontroll när applikationen vet att turen är slut från en annan signal, till exempel att push-to-talk släpps eller en UI-händelse, i stället för att vänta på VAD-timern.
3. Överlappa med LLM-processer: Skicka partiella resultat vidare tidigt. Mata in stabila partialer i LLM:et och revidera om det slutliga transkriptet skiljer sig. Det är en form av spekulativ körning som döljer endpointingfördröjningen bakom LLM:ets promptbearbetning.

Mer information om Scribe v2 Realtime finns på sidan om funktioner för Speech to Text och på produktsidan för Speech to Text i realtid.

LLM:ets bidrag till latensen

Språkmodellen är oftast den enskilt största bidragsgivaren till TTFA, så det är också här överlappning ger mest vid optimering av röstagenters latens. Den viktiga insikten är att agenten inte behöver hela svaret innan den börjar tala.

Mönstret som återvinner mest av latensbudgeten är att strömma tokens från LLM:et och mata dem till TTS allt eftersom de kommer, uppdelade vid menings- eller satsgränser. Principen är att buffra tokens fram till en meningsgräns och sedan syntetisera meningen medan nästa fortfarande 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ångvariga samtal bör du använda TTS WebSocket så att en öppen anslutning kan ta emot text stegvis utan att du behöver betala kostnaden för anslutningsupprättande för varje mening igen. Endast tiden då modellen aktivt genererar ljud räknas mot din samtidighetsgräns, så en inaktiv öppen WebSocket är i stort sett kostnadsfri.

Text to Speech: streaming och val av röst

Text to Speech är steget där du kan fastställa latensen mest exakt. Det har två huvudsakliga reglage: hur du strömmar 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 modellinferens för korta indata, har stöd för 32 språk och accepterar upp till 40 000 tecken per begäran.

Siffran 75 ms gäller endast inferens. TTS-raden för TTFA i budgeten ovan är större eftersom den lägger till nätverksrundresan och serverschemaläggning ovanpå inferensen.

Det största reglaget här är streaming. Om du begär hela ljudet och väntar på det, måste användaren vänta tills hela klippet har syntetiserats innan hen hör något. Med streaming hör användaren det första segmentet så snart det genereras, och resten kommer medan hen redan lyssnar. Streaming gör inte modellen snabbare; den börjar bara skicka utdata till användaren medan den fortfarande genererar.

Guiden för hur du använder streaming beskriver HTTP-streaming, och guiden för WebSocket i realtid beskriver den WebSocket-väg du vill använda när du matar tokens från ett 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 });

Konfigurera sedan en ström och vidarebefordra den när den kommer in:

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
}

Det andra reglaget ä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 ytterligare modellkomplexitet som ger omkostnader per generering. För en agent med strikta latenskrav är Flash tillsammans med en IVC eller standardröst alternativet med lägst latens.

Val av storlek på streamingsegment

När tokens flödar in i TTS och ljud flödar tillbaka är nästa beslut hur stora segmenten ska vara och hur mycket spelaren ska buffra innan den börjar.

Mindre segment når spelaren snabbare och minskar latensen till första byten, men medför fler meddelanden och något större omkostnader per segment. Större segment är effektivare att transportera men får användaren att vänta längre på det första. För interaktiva agenter bör du prioritera mindre segment i början av yttrandet, eftersom det första segmentet är det användaren väntar på. Senare segment kommer medan ljudet redan spelas upp, och deras storlek spelar mindre roll.

Spelaren står för en betydande del av den återstående latensen. De flesta ljudspelare börjar inte spela upp vid första byten. De buffrar en liten mängd för att undvika hack om strömmen tillfälligt saktar ned. En standardbuffert på 500 ms är vanlig och läggs direkt till den upplevda latensen. Att minska den innebär en liten ökning av risken för hack i utbyte mot lägre TTFA, och rätt värde beror på nätverksjitter mellan din server och klienten:

• På en stabil anslutning, till exempel uppspelning på serversidan eller en samlokaliserad klient, är en buffert på 50 till 150 ms vanligtvis säker och minskar TTFA märkbart.
• På en mobil anslutning eller anslutning mellan regioner med mycket jitter förhindrar en större buffert hörbara glapp, som är värre än latensen de kostar.

Den exakta konfigurationen du väljer beror på ditt aktuella användningsfall och vad du prioriterar.

Val av codec

Vart ljudet ska skickas bör avgöra vilken codec du begär. Vi returnerar format som mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 och ulaw_8000. Genom att matcha transportens ursprungliga format slipper du ett transkodningssteg, vilket hjälper till att optimera röstagenters latens.

För telefoni, som Twilio och liknande leverantörer, använder du ulaw_8000. Telefonnätet använder 8 kHz mu-law hela vägen, så om du begär det direkt slipper du ett transkodningssteg i pipelinen och matchar vad operatören förväntar sig. Det finns ingen fördel med att syntetisera ljud med högre kvalitet som telefonnätet omedelbart kommer att nedsampla. Du skulle bara öka latensen utan att förlora något hörbart.

För WebRTC och uppspelning i webbläsaren använder du PCM (pcm_24000 eller pcm_16000) eller MP3. PCM är okomprimerat, så klienten behöver inte avkoda det. Det tar bort en liten mängd latens per segment och är praktiskt när du matar en Web Audio-pipeline direkt. MP3 är mer kompakt över nätet, vilket hjälper vid begränsade anslutningar, men kräver lätt avkodning på klientsidan.

Geografi och nätverksavstånd

Alla optimeringar ovan förutsätter att byten inte behöver färdas långt. Geografin sätter golvet för din latensbudget, vilket innebär att det är värt att granska den innan du justerar något annat.

Vi hanterar begäranden från kluster i Nordamerika, Europa och Sydostasien och dirigerar automatiskt varje begäran till närmaste kluster. En nätverksrundresa över det offentliga internet är vanligtvis 20 till 200 ms beroende på geografisk närhet, och den går inte att minska utan att ändra var din infrastruktur körs.

En agent som känns omedelbar i San Francisco, ett kort hopp från ett nordamerikanskt kluster, kan kännas trög för en användare i Sydasien vars trafik korsar ett hav två gånger per tur.

Lösningen är att samlokalisera dina applikationsservrar med användarna, inte bara med oss. Om användarna finns i Europa kör du agentens backend i Europa så att sträckan mellan användaren och servern blir kort. Vår routning hanterar sedan sträckan från din server till modellen från ett närliggande kluster.

Mät röstagentens latens själv

Siffrorna i latensbudgettabellen ovan är illustrativa intervall att planera utifrån. Siffrorna du använder i produktion bör komma från ett skript som detta, kört mot din egen driftsättning.

Instrumenteringen nedan mäter TTFA för enbart TTS-steget, alltså tiden från begäran till första ljudsegmentet, över många försök och rapporterar percentilerna. Kör den från samma region som dina servrar körs i, inte från din utvecklingsdator. Den 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 komma ihåg:

• Rapportera P50 och P95: Fokusera på dessa i stället för medelvärdet. Medelvärdet döljer svansen, och det är svansen som får en agent att kännas opålitlig. P95 är upplevelsen för en av tjugo turer. 
• Experiment per plats: Kör samma skript från varje region du betjänar och håll resultaten separata.
• Sprid ut anropen för noggrannhet: Sprid ut dina begäranden (setTimeout ovan). Om du skickar alla samtidigt mäter du din egen köbildning i stället för tjänsten. När samtidighetsgränsen överskrids köas begäranden efter prioritet, vilket vanligtvis lägger till cirka 50 ms, och över kapaciteten får du HTTP 429.
• Mät hela latenskedjan: Utöka samma tidsmönster till de andra stegen. Omge din STT-slutbearbetning, LLM:ets första token och spelarens uppstart med samma performance.now()-anrop, så kan du fylla hela budgettabellen med egna siffror och se vilket steg du ska angripa först.

Genom att följa de här tipsen kan du själv mäta röstagentens latens. Därefter har du en tydlig prioriteringsordning för vad du ska ta tag i först.

Vad minskar röstagenters latens mest?

Om du vill ha några snabba åtgärder att fokusera på är det här ändringarna med störst effekt.

Ungefär i effektordning kan du använda följande metoder för att minska agentlatensen:

• Starta LLM-arbete på stabila STT-partialer för att dölja endpointingfördröjningen.
• Strömma LLM-tokens till TTS vid meningsgränser så att syntesen av den första meningen överlappar genereringen av den andra.
• Strömma TTS-ljud till spelaren och minska spelarens buffert till det lägsta värde som ditt nätverksjitter klarar.
• Använd Flash tillsammans med en standardröst eller IVC för TTS med lägst latens, och matcha codec med transporten (ulaw_8000 för telefoni, PCM eller MP3 för webbläsare/WebRTC).
• Samlokalisera dina servrar med användarna och mät per region, eftersom nätverkssträckorna är verkliga och olika långa.

För mer specifika och djupgående tekniker, se utvecklarguiden för hur du optimerar latens. API-snabbstarten och guiden för streaming innehåller kompletta exempel som går att köra direkt. 

Vill du snabbare få tillgång till finjusterade agentkaskader? ElevenAgents implementerar den här pipelinen med överlappningsoptimeringar redan på plats.

Bygg röstagenter med låg latens med ElevenAgents

Att optimera röstagenters latens kräver att du mäter varje steg och sedan överlappar stegen så att de långsammaste körs i bakgrunden medan annat arbete redan pågår. Du kan bygga och justera den kaskaden manuellt över flera iterationer med hjälp av mönstren ovan, eller börja med en pipeline som redan har latensoptimeringar på plats.

ElevenAgents implementerar hela den här kaskaden, från strömmande STT till token-för-token-överlämning från LLM till Flash TTS, med överlappningstekniker redan inbyggda. I stället för att börja från grunden justerar du tröskelvärden för den prestanda som är viktigast för dig.

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

Vanliga frågor om optimering av röstagenters latens