Latentieoptimalisatie voor stemagenten: stapsgewijze handleiding

De reactiesnelheid van een spraakagent wordt bepaald door de totale vertraging tussen het moment waarop een gebruiker is uitgesproken en het moment waarop de agent begint te reageren. Die vertraging wordt zelden veroorzaakt door één traag onderdeel. Ze stapelt zich op in verschillende onafhankelijke fasen, die elk enkele tientallen of honderden milliseconden bijdragen. Om deze te verkorten, moet je weten hoeveel tijd elke fase kost.

Latentieoptimalisatie voor spraakagenten draait om vinden waar die tijd verborgen zit en die fase voor fase terugwinnen.

Dit artikel vormt een aanvulling op het conceptuele overzicht van latentie. Die pagina legt uit wat latentie is, terwijl dit artikel architectuur en metingen behandelt. Zo krijg je een latentiebudget waaraan je kunt meten en een reeks concrete acties die je kunt nemen.

Samenvatting

• Time-to-first-audio omvat de volledige pipeline, niet alleen de inferentietijd van één model.
• De time-to-first-token van het LLM en endpointing zijn de twee grootste posten.
• Door fasen te overlappen in plaats van ze serieel uit te voeren, win je het grootste deel van het budget terug.
• Streaming, de codec-keuze en het afstemmen van de playerbuffer besparen elk meetbare milliseconden.
• Meet per regio op basis van je eigen deployment en rapporteer P50 en P95.

Het latentiebudget voor een spraakagent bepalen

Een latentiebudget is een doel voor de totale time-to-first-audio, verdeeld over de fasen van de pipeline. Elke fase krijgt een limiet en de som daarvan moet onder je doel blijven. Het bepalen ervan is de eerste stap, maar hier gaat het bij latentieoptimalisatie ook vaak mis: engineers kunnen twee getallen verwarren die op elkaar lijken, maar iets anders betekenen.

De eerste is de inferentielatentie van het model: de tijd die een model besteedt aan het genereren van output. Voor onze Flash-modellen is dit ongeveer 75 ms voor gebruikelijke korte invoer, exclusief overhead van netwerk en applicatie. Dit is een interne waarde die nuttig is om modellen met elkaar te vergelijken. Het is niet de waarde die je gebruiker ervaart.

Vanuit het perspectief van de gebruiker richt je je op time-to-first-audio (TTFA): de verstreken tijd vanaf het moment waarop de gebruiker stopt met spreken tot die de eerste sample van het antwoord van de agent hoort. TTFA is altijd groter dan de inferentielatentie van elk afzonderlijk model, omdat het de hele pipeline optelt.

Een gecascadeerde spraakagent bestaat uit vijf fasen:

• opname (microfoon) -> STT -> LLM -> TTS -> afspelen

Audio wordt opgenomen via de microfoon, getranscribeerd naar tekst, naar een taalmodel gestuurd, de tekst van het model wordt weer omgezet in spraak, en die spraak wordt gebufferd en afgespeeld. Elke fase voegt latentie toe, en in meerdere fasen is de grootste kostenpost niet wat je zou verwachten.

Hier volgt een uitgewerkt voorbeeld voor een Engelstalige agent met servers die redelijk dicht bij de gebruiker staan. De getallen zijn illustratieve bereiken, geen garanties.

Doorgaans zijn de twee grootste latentieposten de time-to-first-token van het LLM en de endpointingvertraging aan het begin van de keten. 

De tabel is nuttig om de pipeline te visualiseren, maar suggereert dat de fasen strikt serieel verlopen, wat niet zo is. Enkele van de belangrijkste optimalisaties voor latentie van spraakagenten komen voort uit het overlappen ervan. Die overlap is waar het grootste deel van het onderstaande budget wordt teruggewonnen.

Speech to Text: latentieoptimalisatie voor transcriptie en endpointing

Transcriptie is de tweede fase in de pipeline. De werkelijke kosten zitten niet in de transcriptie zelf, maar in het bepalen wanneer de gebruiker is uitgesproken. Dit gedeelte behandelt beide aspecten om je te helpen de latentie van je spraakagent te optimaliseren.

Transcriptie vindt plaats voordat deze het LLM bereikt. Scribe v2 Realtime (scribe_v2_realtime) levert gedeeltelijke transcripties in ongeveer 150 ms en streamt audioblokken, waardoor het transcript al wordt opgebouwd terwijl de gebruiker nog spreekt. Het ondersteunt PCM van 8 kHz tot 48 kHz en mu-law-codering, wat belangrijk is voor het codec-gedeelte hieronder. De partials van 150 ms zijn goedkoop.

De grotere latentiepost is endpointing: het moment waarop je systeem besluit dat de gebruiker zijn beurt daadwerkelijk heeft beëindigd.

Voice Activity Detection (VAD) segmenteert spraak op basis van stilte, en daar loopt de tijd op. Als je bijvoorbeeld 700 ms stilte afwacht voordat je de beurt als beëindigd beschouwt, voeg je boven op de transcriptie zelf 700 ms toe aan elke beurt. Die vertraging is onzichtbaar in een benchmark voor transcriptienauwkeurigheid, maar duidelijk aanwezig in een echt gesprek. Dit is vaak de grootste regelbare latentie in de hele pipeline en juist daarom een goed beginpunt.

Endpointing is een afweging tussen reactiesnelheid en onderbreking. Een korte stiltedrempel laat de agent snel reageren, maar kan ertoe leiden dat een gebruiker tijdens een natuurlijke pauze midden in een zin wordt onderbroken. Een lange drempel is veilig, maar traag. In de praktijk optimaliseren deze drie wijzigingen de latentie in speech to text:

1. Stem de stiltedrempel nauwkeurig af: Verlaag de stiltedrempel tot de kleinste waarde die de natuurlijke pauzes van je gebruikers niet afkapt. Meet vervolgens de onderbrekingsfrequentie in productie in plaats van te gokken.
2. Gebruik een fysieke besturingsgebeurtenis: Gebruik handmatige commitbesturing wanneer je applicatie via een ander signaal weet dat de beurt voorbij is, zoals het loslaten van push-to-talk of een UI-gebeurtenis, in plaats van op de VAD-timer te wachten.
3. Overlap met LLM-processen: Stuur partials vroeg door naar volgende fasen. Voer stabiele partials aan het LLM en corrigeer ze als het definitieve transcript afwijkt: een vorm van speculatieve uitvoering die de endpointingvertraging verbergt achter de promptverwerking van het LLM.

Meer informatie over Scribe v2 Realtime vind je op de pagina over mogelijkheden van speech to text en op de productpagina voor realtime speech to text.

De bijdrage van het LLM aan latentie

Het taalmodel is doorgaans de grootste afzonderlijke bijdrage aan TTFA. Daarom levert overlap daar ook het meeste op bij de optimalisatie van latentie voor spraakagenten. Het belangrijkste inzicht is dat de agent niet het volledige antwoord nodig heeft voordat die begint te spreken.

Het patroon waarmee je het meeste latentiebudget terugwint, is tokens uit het LLM streamen en ze bij aankomst aan TTS doorgeven, opgedeeld bij zins- of zinsdeelgrenzen. Buffer tokens tot een zinsgrens en synthesizeer vervolgens die zin terwijl de volgende nog wordt gegenereerd:

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;
}

Gebruik voor langdurige gesprekken bij voorkeur de TTS WebSocket zodat een open verbinding incrementeel tekst kan ontvangen zonder voor elke zin opnieuw de verbinding op te zetten. Alleen de tijd waarin het model actief audio genereert, telt mee voor je concurrencylimiet. Een inactieve open WebSocket is dus vrijwel gratis.

Text to Speech: streaming en stemkeuze

Text to Speech is de fase waarin je latentie het nauwkeurigst kunt bepalen. Er zijn twee belangrijke hefbomen: hoe je audio uitstreamt en welke stem je kiest.

Flash v2.5 (eleven_flash_v2_5) is het model dat je in een agent kunt gebruiken. Het levert ongeveer 75 ms modelinferentie voor korte invoer, ondersteunt 32 talen en accepteert maximaal 40.000 tekens per request.

De waarde van 75 ms betreft alleen inferentie. De TTS-TTFA-post in het budget hierboven is groter, omdat daar boven op de inferentie de netwerk-roundtrip en serverscheduling komen.

De grootste hefboom hier is streaming. Als je de volledige audio opvraagt en daarop wacht, wacht de gebruiker tot de hele clip is gesynthetiseerd voordat die iets hoort. Bij streaming hoort de gebruiker het eerste blok zodra dit wordt gegenereerd, terwijl de rest binnenkomt terwijl die al luistert. Streaming maakt het model niet sneller; het begint alleen al output naar de gebruiker te sturen terwijl het model nog genereert.

De how-to-handleiding voor streaming behandelt HTTP-streaming, en de handleiding voor realtime WebSocket behandelt het WebSocket-pad dat je nodig hebt wanneer je tokens uit een LLM doorgeeft.

Initialiseer de client één keer en hergebruik deze voor elke onderstaande aanroep:

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

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

Stel vervolgens een stream in en stuur deze door zodra deze binnenkomt:

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
}

De andere hefboom is de stemkeuze, die ook latentie kost. Standaardstemmen, synthetische stemmen en Instant Voice Clones (IVC's) synthetiseren sneller dan Professional Voice Clones (PVC's), omdat PVC's extra modelcomplexiteit hebben die overhead per generatie toevoegt. Voor een agent met strikte latentievereisten is Flash gecombineerd met een IVC of standaardstem de optie met de laagste latentie.

Keuzes voor de grootte van streamingblokken

Nu tokens naar TTS stromen en audio terugkomt, is de volgende beslissing hoe groot je de blokken maakt en hoeveel de player buffert voordat deze start.

Kleinere blokken bereiken de player sneller en verlagen de first-byte-latentie, maar kosten meer berichten en iets meer overhead per blok. Grotere blokken zijn efficiënter te transporteren, maar laten de gebruiker langer op het eerste blok wachten. Kies voor interactieve agenten vroeg in de uiting liever kleinere blokken, omdat de gebruiker op het eerste blok wacht. Latere blokken komen binnen terwijl audio al wordt afgespeeld, waardoor hun omvang minder belangrijk is.

De player is verantwoordelijk voor een aanzienlijk deel van de resterende latentie. De meeste audiospelers beginnen niet met afspelen bij de eerste byte. Ze bufferen een kleine hoeveelheid om haperingen te voorkomen als de stream kort vertraagt. Een standaardbuffer van 500 ms komt vaak voor en wordt rechtstreeks aan de ervaren latentie toegevoegd. Door die te verlagen, ruil je een klein verhoogd risico op haperingen in voor een lagere TTFA. De juiste waarde hangt af van de netwerkjitter tussen je server en de client:

• Op een stabiele verbinding, zoals server-side afspelen of een client op dezelfde locatie, is een buffer van 50 tot 150 ms doorgaans veilig en verlaagt deze TTFA merkbaar.
• Op een mobiele verbinding met veel jitter of een verbinding tussen regio's voorkomt een grotere buffer hoorbare onderbrekingen die erger zijn dan de latentie die ze kosten.

De exacte configuratie die je hier kiest, hangt af van je actieve use case en je prioriteiten.

Codec-keuzes

Waar de audio naartoe gaat, moet bepalend zijn voor de codec die je aanvraagt. We leveren formaten zoals mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 en ulaw_8000. Door het native formaat van het transport te gebruiken, vervalt een transcoderingsstap, wat helpt bij het optimaliseren van de latentie van spraakagenten.

Gebruik voor telefonie, zoals Twilio en vergelijkbare providers, ulaw_8000. Het telefonienetwerk gebruikt end-to-end 8 kHz mu-law, dus door dit rechtstreeks aan te vragen, voorkom je een transcoderingsstap in je pipeline en sluit je aan op wat de provider verwacht. Het heeft geen voordeel om audio met hogere kwaliteit te synthetiseren die het telefoonnetwerk direct weer downsamplet. Je voegt alleen latentie toe zonder hoorbaar verlies te voorkomen.

Gebruik voor WebRTC en afspelen in de browser PCM (pcm_24000 of pcm_16000) of een MP3-formaat. PCM is ongecomprimeerd, dus de client hoeft niet te decoderen. Dat verwijdert een kleine hoeveelheid latentie per blok en is handig als je rechtstreeks een Web Audio-pipeline voedt. MP3 is compacter tijdens transport, wat helpt bij beperkte verbindingen, ten koste van een lichte decodering aan de clientzijde.

Geografie en netwerkafstanden

Bij elke optimalisatie hierboven wordt ervan uitgegaan dat de bytes maar een korte afstand afleggen. Geografie bepaalt de ondergrens van je latentiebudget. Het is dus de moeite waard dit te onderzoeken voordat je iets anders afstemt.

We verwerken requests vanuit clusters in Noord-Amerika, Europa en Zuidoost-Azië en routeren elke request automatisch naar het dichtstbijzijnde cluster. De netwerk-roundtrip via het openbare internet bedraagt doorgaans 20 tot 200 ms, afhankelijk van de geografische nabijheid. Die is niet te verkorten zonder te veranderen waar je infrastructuur draait.

Een agent die direct aanvoelt in San Francisco, op korte afstand van een Noord-Amerikaans cluster, kan traag aanvoelen voor een gebruiker in Zuid-Azië, wiens verkeer per beurt twee keer een oceaan oversteekt.

De oplossing is je applicatieservers dicht bij je gebruikers te plaatsen, niet alleen bij ons. Als je gebruikers in Europa zitten, draai je agent-backend dan in Europa, zodat het traject van gebruiker naar server kort is. Onze routing verzorgt vervolgens het traject van je server naar het model vanuit een nabijgelegen cluster.

Zelf de latentie van je spraakagent meten

De cijfers in de tabel met het latentiebudget hierboven zijn illustratieve bereiken om mee te plannen. De cijfers waarop je baseert wat je uitbrengt, moeten afkomstig zijn uit een script zoals dit, uitgevoerd op je eigen deployment.

De instrumentatie hieronder meet TTFA voor alleen de TTS-fase: de tijd van request tot eerste audioblok, over veel tests, en rapporteert de percentielen. Voer dit uit vanuit dezelfde regio waarin je servers draaien, niet vanaf je ontwikkelmachine. Het gaat uit van de elevenlabs-client van eerder:

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`);

Een paar punten om te onthouden:

• Rapporteer P50 en P95: Richt je hierop, niet op het gemiddelde. Het gemiddelde verbergt de staart, en die staart maakt een agent onbetrouwbaar. P95 is de ervaring van één beurt op de twintig. 
• Experimenteren op basis van locatie: Voer hetzelfde script uit vanuit elke regio die je bedient en houd de resultaten apart.
• Spreid requests voor nauwkeurigheid: Spreid je requests (met de setTimeout hierboven). Als je ze allemaal tegelijk uitvoert, meet je je eigen wachtrij in plaats van de service. Wanneer de concurrencylimiet wordt overschreden, komen requests op prioriteit in de wachtrij, wat doorgaans ongeveer 50 ms toevoegt. Boven de capaciteit ontvang je HTTP 429.
• Meet de volledige latentie-keten: Pas hetzelfde timingpatroon toe op de andere fasen. Plaats je STT-finalisatie, de eerste token van je LLM en het starten van je player tussen dezelfde performance.now()-haakjes. Zo kun je de volledige budgettabel vullen met je eigen cijfers en zien welke fase je het eerst moet aanpakken.

Door deze tips te volgen, kun je de latentie van je spraakagent zelf meten. Van daaruit heb je een duidelijk overzicht van de prioriteiten die je als eerste moet aanpakken.

Wat verlaagt de latentie van een spraakagent het meest?

Als je op zoek bent naar snelle actiepunten, zijn dit de wijzigingen met de grootste impact.

Ongeveer in volgorde van impact kun je de volgende methoden gebruiken om de latentie van agents te verlagen:

• Start LLM-werk op stabiele STT-partials om de endpointingvertraging te verbergen.
• Stream LLM-tokens op zinsgrenzen naar TTS, zodat de synthese van de eerste zin overlapt met het genereren van de tweede.
• Stream TTS-audio naar de player en verlaag de playerbuffer tot de kleinste waarde die je netwerkjitter aankan.
• Gebruik Flash met een standaardstem of IVC voor TTS met de laagste latentie, en stem de codec af op het transport: ulaw_8000 voor telefonie, PCM of MP3 voor browser/WebRTC.
• Plaats je servers dicht bij je gebruikers en meet per regio, want de netwerktrajecten zijn reëel en niet gelijk.

Bekijk voor specifiekere, diepgaande technieken de how-to-handleiding voor ontwikkelaars over latentieoptimalisatie. De API-quickstart en de streaming-how-to bevatten volledige voorbeelden als uitvoerbaar startpunt. 

Wil je sneller toegang tot afgestemde agentcascades? ElevenAgents implementeert deze pipeline met overlapoptimalisaties die al zijn ingesteld.

Bouw spraakagenten met lage latentie met ElevenAgents

Voor latentieoptimalisatie van spraakagenten moet je elke fase meten en fasen vervolgens overlappen, zodat de traagste fasen draaien naast werk dat al plaatsvindt. Je kunt die cascade handmatig opbouwen en afstemmen in meerdere iteraties met de patronen hierboven, of aan de slag gaan met een pipeline waarin latentieoptimalisaties al zijn toegepast.

ElevenAgents implementeert deze volledige cascade, van streaming STT via token-voor-token-overdracht van het LLM naar Flash TTS, met ingebouwde overlaptechnieken. In plaats van vanaf nul te beginnen, stem je drempels af op de prestaties die voor jou het belangrijkst zijn.

Ga aan de slag met ElevenAgents om vandaag een agent te maken of neem contact op met sales voor meer informatie.

Veelgestelde vragen over latentieoptimalisatie voor spraakagenten