Optimierung der Latenz von Sprachagenten: Schritt-für-Schritt-Anleitung

Die Reaktionsfähigkeit eines Voice Agents wird durch die Gesamtverzögerung zwischen dem Ende der Nutzereingabe und dem Beginn der Antwort des Agents bestimmt. Diese Verzögerung wird selten durch eine einzelne langsame Komponente verursacht. Sie summiert sich über mehrere unabhängige Stufen, die jeweils einige zehn oder hundert Millisekunden beitragen. Um sie zu reduzieren, müssen Sie wissen, wie viel Zeit jede Stufe benötigt.

Bei der Optimierung der Latenz von Voice Agents geht es darum, versteckte Zeitverluste zu finden und sie Stufe für Stufe zurückzugewinnen.

Dieser Artikel ergänzt den konzeptionellen Überblick zur Latenz. Dort wird erklärt, was Latenz ist; hier geht es um Architektur und Messung. So erhalten Sie ein messbares Latenzbudget und konkrete Maßnahmen.

Zusammenfassung

• Time-to-first-audio bildet die gesamte Pipeline ab, nicht die Inferenzzeit eines einzelnen Modells.
• Die Time-to-first-token des LLM und das Endpointing sind die zwei größten Posten.
• Durch überlappende statt serielle Stufen gewinnen Sie den größten Teil des Budgets zurück.
• Streaming, die Codec-Wahl und die Abstimmung des Player-Puffers sparen jeweils messbare Millisekunden.
• Messen Sie pro Region in Ihrer eigenen Bereitstellung und berichten Sie P50 und P95.

Das Latenzbudget für Voice Agents definieren

Ein Latenzbudget ist ein Zielwert für die gesamte Time-to-first-audio über alle Pipelinestufen hinweg. Jede Stufe erhält einen Anteil, und die Summe muss unter Ihrem Zielwert liegen. Die Definition ist der erste Schritt – und hier geht Latenzoptimierung oft schief, weil Entwickler zwei ähnlich wirkende, aber unterschiedliche Kennzahlen verwechseln.

Die erste ist die Modellinferenzlatenz: die Zeit, die ein Modell für die Ausgabeerzeugung benötigt. Bei unseren Flash-Modellen beträgt sie bei typischen kurzen Eingaben etwa 75 ms, ohne Netzwerk- und Anwendungs-Overhead. Dies ist ein interner Wert und nützlich, um Modelle miteinander zu vergleichen. Es ist nicht der Wert, den Ihre Nutzer erleben.

Aus Nutzersicht konzentrieren Sie sich auf Time-to-first-audio (TTFA): die Zeit vom Ende der Nutzereingabe bis zum ersten Sample der Agent-Antwort. TTFA ist immer höher als die Inferenzlatenz eines einzelnen Modells, da sie die gesamte Pipeline summiert.

Ein kaskadierter Voice Agent besteht aus fünf Stufen:

• Erfassung (Mikrofon) -> STT -> LLM -> TTS -> Wiedergabe

Audio wird über das Mikrofon erfasst, in Text transkribiert, an ein Sprachmodell gesendet, dessen Text wieder in Sprache synthetisiert und anschließend gepuffert und wiedergegeben. Jede Stufe erhöht die Latenz. In mehreren Stufen ist der größte Kostenfaktor nicht der, den Sie erwarten würden.

Hier ist ein Beispiel für einen englischsprachigen Agent mit Servern in angemessener Nähe zum Nutzer. Die Zahlen sind beispielhafte Bereiche, keine Garantien.

Typischerweise sind die zwei größten Latenzposten die Time-to-first-token des LLM und die Endpointing-Verzögerung zu Beginn der Kette. 

Die Tabelle veranschaulicht die Pipeline gut, impliziert aber, dass die Stufen strikt seriell laufen. Das tun sie nicht. Mehrere der wichtigsten Latenzoptimierungen für Voice Agents entstehen durch ihre Überlappung. Dort wird der größte Teil des folgenden Budgets zurückgewonnen.

Speech to Text: Transkriptions- und Endpointing-Latenz optimieren

Die Transkription ist die zweite Stufe der Pipeline. Ihr tatsächlicher Aufwand liegt nicht in der Transkription selbst, sondern darin zu entscheiden, wann der Nutzer aufgehört hat zu sprechen. Dieser Abschnitt behandelt beide Aspekte, damit Sie die Latenz Ihres Voice Agents optimieren können.

Die Transkription erfolgt vor dem LLM. Scribe v2 Realtime (scribe_v2_realtime) liefert partielle Transkriptionen in etwa 150 ms und streamt Audioblöcke. Das Transkript entsteht also, während der Nutzer noch spricht. Es unterstützt PCM mit 8 kHz bis 48 kHz sowie mu-law-Kodierung, was für den folgenden Codec-Abschnitt wichtig ist. Die 150-ms-Teilergebnisse sind kostengünstig.

Der größere Latenzfaktor ist das Endpointing: der Moment, in dem Ihr System entscheidet, dass der Nutzer seinen Zug tatsächlich beendet hat.

Sprachaktivitätserkennung (VAD) segmentiert Sprache anhand von Stille. Hier summiert sich die Zeit. Warten Sie beispielsweise 700 ms Stille ab, bevor Sie einen Zug als beendet erklären, fügen Sie jedem Zug zusätzlich zur Transkription 700 ms hinzu. Diese Verzögerung ist in einem Benchmark zur Transkriptionsgenauigkeit unsichtbar, in einem echten Gespräch aber deutlich spürbar. Sie ist oft die größte steuerbare Latenz der gesamten Pipeline und daher ein guter Startpunkt.

Endpointing ist ein Kompromiss zwischen Reaktionsfähigkeit und Unterbrechungen. Ein kurzer Stille-Schwellenwert lässt den Agent schnell antworten, kann Nutzer aber bei einer natürlichen Pause mitten im Satz unterbrechen. Ein langer Schwellenwert ist sicher, aber träge. In der Praxis optimieren diese drei Änderungen die Latenz bei Speech to Text:

1. Stille-Schwellenwert fein abstimmen: Senken Sie den Stille-Schwellenwert auf den kleinsten Wert, der die natürlichen Pausen Ihrer Nutzer nicht abschneidet. Messen Sie dann die Unterbrechungsrate in der Produktion, statt zu raten.
2. Physisches Steuerereignis einbinden: Nutzen Sie eine manuelle Commit-Steuerung, wenn Ihre Anwendung anhand eines anderen Signals erkennt, dass der Zug beendet ist – etwa durch Loslassen einer Push-to-Talk-Taste oder ein UI-Ereignis – statt auf den VAD-Timer zu warten.
3. Mit LLM-Prozessen überlappen: Leiten Sie Teilergebnisse frühzeitig weiter. Übergeben Sie stabile Teilergebnisse an das LLM und korrigieren Sie sie, falls sich das endgültige Transkript unterscheidet. Diese Form der spekulativen Ausführung verbirgt die Endpointing-Verzögerung hinter der Prompt-Verarbeitung des LLM.

Weitere Informationen zu Scribe v2 Realtime finden Sie auf der Seite zu den Speech-to-Text-Funktionen und auf der Produktseite zu Echtzeit-Spracherkennung.

Der Latenzbeitrag des LLM

Das Sprachmodell ist meist der größte einzelne Beitrag zur TTFA. Daher zahlt sich Überlappung hier bei der Latenzoptimierung von Voice Agents am meisten aus. Entscheidend ist: Der Agent benötigt nicht die vollständige Antwort, bevor er zu sprechen beginnt.

Das Muster, das den größten Teil des Latenzbudgets zurückgewinnt, streamt Tokens aus dem LLM und übergibt sie beim Eintreffen an TTS, aufgeteilt an Satz- oder Klauselgrenzen. Tokens werden bis zu einer Satzgrenze gepuffert. Dann wird dieser Satz synthetisiert, während der nächste noch erzeugt wird:

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

Bevorzugen Sie bei langen Gesprächen den TTS-WebSocket, damit eine offene Verbindung Text inkrementell empfangen kann, ohne bei jedem Satz den Verbindungsaufbau erneut zu bezahlen. Nur die Zeit, in der das Modell aktiv Audio erzeugt, zählt für Ihr Parallelitätslimit. Ein ungenutzter offener WebSocket ist daher nahezu kostenlos.

Text to Speech: Streaming und Stimmenwahl

Text to Speech ist die Stufe, deren Latenz Sie am präzisesten bestimmen können. Sie hat zwei zentrale Stellhebel: wie Sie Audio streamen und welche Stimme Sie wählen.

Flash v2.5 (eleven_flash_v2_5) ist das Modell für einen Agent. Bei kurzen Eingaben liefert es etwa 75 ms Modellinferenz, unterstützt 32 Sprachen und akzeptiert bis zu 40.000 Zeichen pro Anfrage.

Die 75 ms beziehen sich nur auf die Inferenz. Der TTS-TTFA-Posten im obigen Budget ist höher, da er zusätzlich Netzwerk-Roundtrip und Server-Scheduling umfasst.

Der größte Stellhebel ist hier Streaming. Fordern Sie das vollständige Audio an und warten darauf, muss der Nutzer warten, bis der gesamte Clip synthetisiert ist. Beim Streaming hört der Nutzer den ersten Block, sobald er erzeugt wurde; der Rest trifft ein, während er bereits zuhört. Streaming macht das Modell nicht schneller, sondern gibt die Ausgabe aus, während sie noch erzeugt wird.

Der Streaming-Leitfaden behandelt HTTP-Streaming, und der Leitfaden für Echtzeit-WebSockets behandelt den WebSocket-Weg, den Sie nutzen sollten, wenn Sie Tokens aus einem LLM einspeisen.

Initialisieren Sie den Client einmal und verwenden Sie ihn für alle folgenden Aufrufe wieder:

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

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

Richten Sie dann einen Stream ein und leiten Sie ihn beim Eintreffen weiter:

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
}

Der andere Stellhebel ist die Stimmenwahl, die ebenfalls Latenzkosten verursacht. Standardstimmen, synthetische Stimmen und Instant Voice Clones (IVCs) synthetisieren schneller als Professional Voice Clones (PVCs), da PVCs eine zusätzliche Modellkomplexität mit Overhead pro Generierung mitbringen. Für einen Agent mit strikten Latenzanforderungen ist Flash in Kombination mit einer IVC oder Standardstimme die Option mit der geringsten Latenz.

Optionen für die Größe von Streaming-Blöcken

Während Tokens in TTS fließen und Audio zurückkommt, lautet die nächste Entscheidung, wie groß die Blöcke sein sollen und wie viel der Player vor dem Start puffert.

Kleinere Blöcke erreichen den Player früher und senken die Latenz bis zum ersten Byte, verursachen aber mehr Nachrichten und etwas mehr Overhead pro Block. Größere Blöcke sind effizienter zu übertragen, lassen Nutzer aber länger auf den ersten warten. Bei interaktiven Agents sollten Blöcke am Anfang der Äußerung kleiner sein, da der Nutzer auf den ersten Block wartet. Spätere Blöcke treffen ein, während Audio bereits läuft, und ihre Größe ist weniger wichtig.

Der Player verursacht einen erheblichen Teil der verbleibenden Latenz. Die meisten Audioplayer beginnen nicht beim ersten Byte mit der Wiedergabe. Sie puffern eine kleine Menge, um Ruckler zu vermeiden, wenn der Stream kurz langsamer wird. Ein Standardpuffer von 500 ms ist üblich und wird direkt zur wahrgenommenen Latenz addiert. Eine Verringerung tauscht ein leicht höheres Rucklerrisiko gegen eine niedrigere TTFA. Der richtige Wert hängt vom Netzwerk-Jitter zwischen Ihrem Server und dem Client ab:

• Bei einer stabilen Verbindung – serverseitige Wiedergabe oder ein lokal platzierter Client – ist ein Puffer von 50 bis 150 ms meist sicher und reduziert die TTFA spürbar.
• Bei einer mobilen Verbindung mit Jitter oder einer regionsübergreifenden Verbindung verhindert ein größerer Puffer hörbare Lücken, die schlimmer sind als die dadurch entstehende Latenz.

Die genaue Konfiguration hängt von Ihrem aktiven Anwendungsfall und Ihren Prioritäten ab.

Codec-Auswahl

Das Ziel des Audios sollte den angeforderten Codec bestimmen. Wir liefern Formate wie mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 und ulaw_8000. Wenn Sie das native Format des Transports verwenden, entfällt ein Transkodierungsschritt, was die Latenzoptimierung für Voice Agents unterstützt.

Für Telefonie, etwa mit Twilio und ähnlichen Anbietern, verwenden Sie ulaw_8000. Das Telefonienetz nutzt durchgängig 8-kHz-mu-law. Wenn Sie es direkt anfordern, vermeiden Sie einen Transkodierungsschritt in Ihrer Pipeline und entsprechen den Erwartungen des Netzbetreibers. Es bringt keinen Vorteil, Audio mit höherer Qualität zu synthetisieren, das das Telefonnetz sofort herunterskaliert. Sie würden nur Latenz hinzufügen und nichts Hörbares gewinnen.

Für WebRTC und die Browserwiedergabe verwenden Sie PCM (pcm_24000 oder pcm_16000) oder ein MP3-Format. PCM ist unkomprimiert, daher entfällt die Dekodierung auf dem Client. Das reduziert die Latenz pro Block geringfügig und ist praktisch, wenn Sie direkt eine Web-Audio-Pipeline speisen. MP3 ist bei der Übertragung kompakter, was bei eingeschränkten Verbindungen hilft, allerdings auf Kosten einer leichten clientseitigen Dekodierung.

Geografie und Netzwerkdistanzen

Alle obigen Optimierungen setzen voraus, dass die Daten nur eine kurze Strecke zurücklegen. Die Geografie bestimmt die Untergrenze Ihres Latenzbudgets. Prüfen Sie sie daher, bevor Sie etwas anderes abstimmen.

Wir bedienen Anfragen über Cluster in Nordamerika, Europa und Südostasien und leiten jede Anfrage automatisch an den nächstgelegenen Cluster weiter. Der Netzwerk-Roundtrip über das öffentliche Internet beträgt je nach geografischer Nähe typischerweise 20 bis 200 ms und lässt sich nicht verringern, ohne den Standort Ihrer Infrastruktur zu ändern.

Ein Agent, der sich in San Francisco nahe einem nordamerikanischen Cluster unmittelbar anfühlt, kann für Nutzer in Südasien träge wirken, deren Datenverkehr pro Zug zweimal einen Ozean überquert.

Die Lösung besteht darin, Ihre Anwendungsserver bei Ihren Nutzern zu platzieren, nicht nur bei uns. Befinden sich Ihre Nutzer in Europa, führen Sie Ihr Agent-Backend in Europa aus, damit die Strecke vom Nutzer zu Ihrem Server kurz ist. Unser Routing übernimmt dann die kurze Strecke von Ihrem Server zum Modell über einen nahen Cluster.

Latenz von Voice Agents selbst messen

Die Werte in der obigen Latenzbudget-Tabelle sind beispielhafte Bereiche zur Planung. Die Werte, auf deren Grundlage Sie ausliefern, sollten aus einem Skript wie diesem stammen, das Sie für Ihre eigene Bereitstellung ausführen.

Die folgende Instrumentierung misst die TTFA der TTS-Stufe isoliert – die Zeit von der Anfrage bis zum ersten Audioblock – über viele Durchläufe und gibt die Perzentile aus. Führen Sie sie in derselben Region aus, in der Ihre Server laufen, nicht auf Ihrem Entwicklungsrechner. Sie setzt den zuvor gezeigten elevenlabs-Client voraus:

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

Einige Punkte, die Sie beachten sollten:

• P50 und P95 berichten: Konzentrieren Sie sich auf diese Werte statt auf den Mittelwert. Der Mittelwert verdeckt den langen Ausläufer, und dieser lässt einen Agent unzuverlässig wirken. P95 entspricht der Erfahrung bei einem von zwanzig Zügen. 
• Regionsbasierte Tests: Führen Sie dasselbe Skript in jeder bedienten Region aus und halten Sie die Ergebnisse getrennt.
• Für Genauigkeit staffeln: Verteilen Sie Ihre Anfragen zeitlich (das setTimeout oben). Senden Sie sie alle gleichzeitig, messen Sie Ihre eigene Warteschlange statt des Dienstes. Wird das Parallelitätslimit überschritten, werden Anfragen nach Priorität eingereiht. Das fügt typischerweise etwa 50 ms hinzu. Oberhalb der Kapazität erhalten Sie HTTP 429.
• Die gesamte Latenzkette messen: Übertragen Sie dasselbe Zeitmessmuster auf die anderen Stufen. Klammern Sie Ihre STT-Finalisierung, das erste LLM-Token und den Start Ihres Players mit denselben performance.now()-Marken ein. So können Sie die vollständige Budgettabelle mit Ihren eigenen Werten füllen und sehen, welche Stufe Sie zuerst angehen sollten.

Mit diesen Tipps können Sie die Latenz von Voice Agents selbst messen. Danach haben Sie klare Prioritäten für die nächsten Schritte.

Was reduziert die Latenz von Voice Agents am stärksten?

Wenn Sie sich auf schnelle Maßnahmen konzentrieren möchten, sind dies die Änderungen mit dem größten Hebel.

In etwa nach Wirkung geordnet können Sie die folgenden Methoden zur Verringerung der Agent-Latenz einsetzen:

• Starten Sie die LLM-Verarbeitung mit stabilen STT-Teilergebnissen, um die Endpointing-Verzögerung zu verbergen.
• Streamen Sie LLM-Tokens an Satzgrenzen in TTS, damit die Synthese des ersten Satzes die Generierung des zweiten überlappt.
• Streamen Sie TTS-Audio an den Player und reduzieren Sie dessen Puffer auf den kleinsten Wert, den Ihr Netzwerk-Jitter zulässt.
• Verwenden Sie Flash mit einer Standardstimme oder IVC für TTS mit der geringsten Latenz und stimmen Sie den Codec auf den Transport ab (ulaw_8000 für Telefonie, PCM oder MP3 für Browser/WebRTC).
• Platzieren Sie Ihre Server bei Ihren Nutzern und messen Sie pro Region, denn die Netzwerkstrecken sind real und unterschiedlich.

Spezifischere Techniken finden Sie im Entwicklerleitfaden zur Latenzoptimierung. Einen vollständig ausführbaren Einstieg bieten der API-Quickstart und die Streaming-Anleitung mit vollständigen Beispielen. 

Möchten Sie schneller auf fein abgestimmte Agent-Kaskaden zugreifen? ElevenAgents implementiert diese Pipeline mit bereits integrierten Überlappungsoptimierungen.

Voice Agents mit niedriger Latenz mit ElevenAgents entwickeln

Die Latenzoptimierung von Voice Agents erfordert, jede Stufe zu messen und dann die Stufen zu überlappen, sodass die langsamsten parallel zu bereits laufender Arbeit ausgeführt werden. Sie können diese Kaskade über mehrere Iterationen selbst entwickeln und abstimmen, die obigen Muster nutzen oder mit einer Pipeline starten, die bereits Latenzoptimierungen enthält.

ElevenAgents implementiert diese vollständige Kaskade – von Streaming-STT über die Token-für-Token-Übergabe an das LLM bis zu Flash TTS – mit bereits integrierten Überlappungstechniken. Statt bei null zu beginnen, stimmen Sie Schwellenwerte für die Leistung ab, die Ihnen am wichtigsten ist.

Starten Sie mit ElevenAgents und erstellen Sie noch heute einen Agent oder kontaktieren Sie den Vertrieb für weitere Informationen.

FAQs zur Latenzoptimierung von Voice Agents