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

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

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

Dieser Artikel ergänzt den konzeptionellen Überblick zur Latenz. Während diese Seite erklärt, was Latenz ist, behandelt dieser Artikel Architektur und Messung. So erhalten Sie ein messbares Latenzbudget und konkrete Maßnahmen.

Zusammenfassung

• Time-to-first-audio bildet die gesamte Pipeline ab, nicht nur die Inferenzzeit eines einzelnen Modells.
• Die Time-to-first-token des LLM und Endpointing sind die beiden größten Posten.
• Das Überlappen von Phasen statt ihrer sequenziellen Ausführung gewinnt den Großteil des Budgets zurück.
• Streaming, Codec-Auswahl und die Abstimmung des Player-Puffers sparen jeweils messbare Millisekunden.
• Sie sollten für jede Region in Ihrer eigenen Bereitstellung messen und P50 sowie P95 ausweisen.

Das Latenzbudget für Voice Agents definieren

Ein Latenzbudget ist ein Zielwert für die gesamte Time-to-first-audio über alle Pipeline-Phasen hinweg. Jede Phase erhält einen Anteil, und die Summe muss unter Ihrem Zielwert liegen. Die Definition ist der erste Schritt und zugleich ein häufiger Fehlerpunkt, weil Entwickler zwei ähnlich aussehende, aber unterschiedliche Kennzahlen verwechseln können.

Die erste ist die Modell-Inferenzlatenz: 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. Das ist eine interne Kennzahl und nützlich, um Modelle zu vergleichen. Ihre Nutzer erleben sie jedoch nicht direkt.

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

Ein kaskadierter Voice Agent besteht aus fünf Phasen:

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

Audio wird über das Mikrofon aufgenommen, in Text transkribiert, an ein Sprachmodell gesendet, dessen Text wieder in Sprache synthetisiert und anschließend gepuffert und wiedergegeben. Jede Phase fügt Latenz hinzu. In mehreren Phasen ist der größte Aufwand 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 illustrative Bereiche, keine Garantien.

Die beiden größten Latenzposten sind in der Regel die Time-to-first-token des LLM und die Endpointing-Verzögerung am Anfang der Kette. 

Die Tabelle visualisiert die Pipeline zwar gut, erweckt aber den Eindruck, die Phasen liefen strikt sequenziell ab. Das tun sie nicht. Mehrere der wichtigsten Optimierungen für die Latenz von Voice Agents entstehen durch ihr Überlappen. Dadurch wird der Großteil des folgenden Budgets zurückgewonnen.

Speech to Text: Optimierung von Transkriptions- und Endpointing-Latenz

Die Transkription ist die zweite Phase der Pipeline. Ihr eigentlicher Aufwand liegt nicht in der Transkription selbst, sondern in der Entscheidung, wann der Nutzer aufgehört hat zu sprechen. Dieser Abschnitt behandelt beide Aspekte, damit Sie die Latenz von Voice Agents optimieren können.

Die Transkription erfolgt, bevor sie das LLM erreicht. Scribe v2 Realtime (scribe_v2_realtime) liefert Teiltranskriptionen in etwa 150 ms und streamt Audio-Chunks. So entsteht das Transkript, während der Nutzer noch spricht. Es unterstützt PCM mit 8 kHz bis 48 kHz und mu-law-Kodierung, was für den folgenden Abschnitt zu Codecs relevant ist. Die 150-ms-Teilergebnisse sind kostengünstig.

Der größere Latenzaufwand entsteht durch Endpointing: den Zeitpunkt, an dem Ihr System entscheidet, dass der Nutzer seine Eingabe tatsächlich beendet hat.

Voice Activity Detection (VAD) segmentiert Sprache anhand von Stille. Hier summiert sich die Zeit. Wenn Sie beispielsweise 700 ms Stille abwarten, bevor Sie eine Eingabe für beendet erklären, fügen Sie jeder Eingabe zusätzlich zur Transkription 700 ms hinzu. Diese Verzögerung ist in einem Benchmark zur Transkriptionsgenauigkeit unsichtbar, in einer realen Unterhaltung jedoch deutlich spürbar. Sie ist oft die größte steuerbare Latenz in der gesamten Pipeline und daher ein guter Ausgangspunkt.

Endpointing ist ein Kompromiss zwischen Reaktionsfähigkeit und Unterbrechungen. Ein kurzer Stille-Schwellenwert lässt den Agent schnell antworten, kann aber Nutzer 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 niedrigsten Wert, der natürliche Sprechpausen Ihrer Nutzer nicht abschneidet. Messen Sie anschließend die Unterbrechungsrate in der Produktion, statt zu raten.
2. Ein physisches Steuerereignis einbinden: Verwenden Sie eine manuelle Commit-Steuerung, wenn Ihre Anwendung über ein anderes Signal weiß, dass die Eingabe beendet ist, etwa durch Loslassen einer Push-to-talk-Taste oder ein UI-Ereignis. So müssen Sie nicht auf den VAD-Timer warten.
3. Mit LLM-Prozessen überlappen: Leiten Sie Teilergebnisse frühzeitig weiter. Geben Sie stabile Teilergebnisse an das LLM und korrigieren Sie sie, falls das finale Transkript abweicht. Diese Form der spekulativen Ausführung verbirgt die Endpointing-Verzögerung hinter der LLM-Prompt-Verarbeitung.

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

Der Latenzbeitrag des LLM

Das Sprachmodell ist meist der größte einzelne Faktor für die TTFA. Deshalb zahlt sich Überlappung hier bei der Optimierung der Latenz 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 das meiste Latenzbudget zurückgewinnt, streamt Tokens aus dem LLM und übergibt sie bei Satz- oder Teilsatzgrenzen an TTS. 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;
}

Für länger laufende Gespräche sollten Sie den TTS-WebSocket bevorzugen. Eine offene Verbindung kann Text inkrementell empfangen, ohne den Verbindungsaufbau bei jedem Satz erneut zu verursachen. Nur die Zeit, in der das Modell aktiv Audio erzeugt, zählt für Ihr Parallelitätslimit. Ein offener, inaktiver WebSocket ist daher nahezu kostenlos.

Text to Speech: Streaming und Stimmenauswahl

Text to Speech ist die Phase, in der Sie die Latenz am präzisesten steuern können. Dafür gibt es zwei wesentliche Hebel: wie Sie Audio streamen und welche Stimme Sie auswählen.

Flash v2.5 (eleven_flash_v2_5) ist das Modell für einen Agent. Es liefert bei kurzen Eingaben 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. Die TTS-TTFA im obigen Budget ist höher, da sie zusätzlich Netzwerk-Roundtrip und Server-Scheduling umfasst.

Der größte Hebel ist hier Streaming. Wenn Sie das vollständige Audio anfordern und darauf warten, wartet der Nutzer, bis der gesamte Clip synthetisiert ist. Beim Streaming hört der Nutzer den ersten Chunk, sobald er erzeugt wurde, während der Rest eintrifft, während er bereits zuhört. Streaming macht das Modell nicht schneller. Es beginnt lediglich mit der Ausgabe an den Nutzer, während das Modell noch erzeugt.

Der Leitfaden für Streaming behandelt HTTP-Streaming, und der Leitfaden für Echtzeit-WebSockets behandelt den WebSocket-Weg für die Übergabe von Tokens aus einem LLM.

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 Hebel ist die Stimmenauswahl, die ebenfalls Latenzkosten verursacht. Standardstimmen, synthetische Stimmen und Instant Voice Clones (IVCs) synthetisieren schneller als Professional Voice Clones (PVCs), da PVCs zusätzliche Modellkomplexität mit Overhead pro Generierung haben. Für einen Agent mit strikten Latenzanforderungen bietet Flash in Kombination mit einem IVC oder einer Standardstimme die geringste Latenz.

Streaming-Chunk-Größen auswählen

Wenn Tokens in TTS fließen und Audio zurückkommt, entscheidet sich als Nächstes, wie groß die Einheiten sein sollen und wie viel der Player vor dem Start puffert.

Kleinere Chunks erreichen den Player früher und verringern die First-byte-Latenz, verursachen aber mehr Nachrichten und etwas mehr Overhead pro Chunk. Größere Chunks lassen sich effizienter übertragen, verlängern jedoch die Wartezeit auf den ersten Chunk. Bei interaktiven Agents sollten Sie zu Beginn einer Äußerung kleinere Chunks bevorzugen, denn auf den ersten Chunk wartet der Nutzer. Spätere Chunks treffen ein, während Audio bereits läuft, sodass ihre Größe weniger wichtig ist.

Der Player macht einen wesentlichen Teil der verbleibenden Latenz aus. Die meisten Audioplayer beginnen nicht beim ersten Byte mit der Wiedergabe. Sie puffern eine kleine Menge, um Stottern bei kurzzeitig langsamerem Stream zu vermeiden. Ein Standardpuffer von 500 ms ist üblich und wird direkt zur wahrgenommenen Latenz addiert. Eine Verringerung erhöht das Risiko von Stottern leicht, senkt aber die TTFA. Der richtige Wert hängt vom Netzwerk-Jitter zwischen Ihrem Server und dem Client ab:

• Bei einer stabilen Verbindung (serverseitige Wiedergabe, ko-lokalisierter Client) ist ein Puffer von 50 bis 150 ms in der Regel sicher und reduziert die TTFA spürbar.
• Bei einer instabilen Mobilfunk- oder regionsübergreifenden Verbindung verhindert ein größerer Puffer hörbare Aussetzer, die schlimmer sind als die dadurch verursachte Latenz.

Die genaue Konfiguration hängt von Ihrem konkreten 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 Latenz von Voice Agents optimiert.

Für Telefonie, etwa mit Twilio und ähnlichen Anbietern, verwenden Sie ulaw_8000. Das Telefonnetz nutzt durchgängig 8-kHz-mu-law. Wenn Sie dieses Format 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 heruntersampelt. Sie würden nur Latenz hinzufügen, ohne hörbar etwas zu gewinnen.

Für WebRTC und die Browserwiedergabe verwenden Sie PCM (pcm_24000 oder pcm_16000) oder ein MP3-Format. PCM ist unkomprimiert, daher ist auf dem Client kein Dekodierungsschritt erforderlich. Das reduziert die Latenz pro Chunk 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, jedoch eine leichte clientseitige Dekodierung erfordert.

Geografie und Netzwerkdistanzen

Alle obigen Optimierungen setzen voraus, dass die Bytes nur eine kurze Strecke zurücklegen. Die Geografie legt die Untergrenze Ihres Latenzbudgets fest. 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 reduzieren, ohne den Standort Ihrer Infrastruktur zu ändern.

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

Die Lösung besteht darin, Ihre Anwendungsserver bei Ihren Nutzern zu ko-lokalisieren, nicht nur bei uns. Wenn sich Ihre Nutzer in Europa befinden, betreiben Sie Ihr Agent-Backend in Europa, damit der Weg vom Nutzer zu Ihrem Server kurz ist. Unser Routing übernimmt dann den Weg von Ihrem Server zum Modell über einen nahegelegenen Cluster.

Latenz von Voice Agents selbst messen

Die Werte in der obigen Latenzbudget-Tabelle sind illustrative Bereiche zur Planung. Die Werte, nach denen Sie ausliefern, sollten aus einem Script wie diesem stammen, das Sie in Ihrer eigenen Bereitstellung ausführen.

Die folgende Instrumentierung misst die TTFA für die isolierte TTS-Phase – die Zeit von der Anfrage bis zum ersten Audio-Chunk – ü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 verwendeten 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 ausweisen: Konzentrieren Sie sich auf diese Werte statt auf den Mittelwert. Der Mittelwert verdeckt den langen Ausläufer, der einen Agent unzuverlässig wirken lässt. P95 entspricht der Erfahrung bei einer von zwanzig Eingaben. 
• Tests nach Standort: Führen Sie dasselbe Script aus jeder Region aus, die Sie bedienen, und halten Sie die Ergebnisse getrennt.
• Anfragen für Genauigkeit staffeln: Verteilen Sie Ihre Anfragen zeitlich (das obige setTimeout). Wenn Sie alle gleichzeitig senden, messen Sie Ihre eigene Warteschlange statt des Dienstes. Wird das Parallelitätslimit überschritten, werden Anfragen nach Priorität eingereiht, was typischerweise etwa 50 ms hinzufügt. Bei Überschreitung der Kapazität erhalten Sie HTTP 429.
• Die gesamte Latenzkette messen: Erweitern Sie dasselbe Timing-Muster auf die anderen Phasen. Setzen Sie Ihre STT-Finalisierung, den ersten LLM-Token und den Start des Players in dieselben performance.now()-Klammern. So können Sie die vollständige Budgettabelle mit Ihren eigenen Werten füllen und erkennen, welche Phase 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 schnelle Maßnahmen priorisieren möchten, sind dies die Änderungen mit dem größten Hebel.

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

• Starten Sie die LLM-Verarbeitung mit stabilen STT-Teilergebnissen, um die Endpointing-Verzögerung zu verbergen.
• Streamen Sie LLM-Tokens an Satzgrenzen in TTS, sodass die Synthese des ersten Satzes die Generierung des zweiten überlappt.
• Streamen Sie TTS-Audio an den Player und reduzieren Sie den Player-Puffer auf den kleinsten Wert, den Ihr Netzwerk-Jitter zulässt.
• Verwenden Sie Flash mit einer Standardstimme oder einem 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).
• Ko-lokalisieren Sie Ihre Server mit Ihren Nutzern und messen Sie je Region, denn die Netzwerkstrecken sind real und unterschiedlich.

Vertiefende spezifische Techniken finden Sie im Entwicklerleitfaden zur Latenzoptimierung. Einen vollständigen ausführbaren Einstiegspunkt mit Beispielen bieten der API-Quickstart und der Streaming-Leitfaden. 

Sie möchten schneller auf fein abgestimmte Agent-Kaskaden zugreifen? ElevenAgents implementiert diese Pipeline bereits mit Optimierungen für überlappende Phasen.

Voice Agents mit geringer Latenz mit ElevenAgents erstellen

Die Optimierung der Latenz von Voice Agents erfordert, jede Phase zu messen und Phasen anschließend so zu überlappen, dass die langsamsten im Hintergrund bereits laufender Arbeit ausgeführt werden. Sie können diese Kaskade über mehrere Iterationen manuell erstellen und abstimmen, die obigen Muster nutzen oder mit einer Pipeline starten, die bereits Latenzoptimierungen enthält.

ElevenAgents implementiert die 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 anzufangen, stimmen Sie Schwellenwerte auf die Leistung ab, die für Sie am wichtigsten ist.

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

FAQ zur Latenzoptimierung von Voice Agents