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

Die Reaktionsfähigkeit eines Sprachagenten wird durch die Gesamtdauer zwischen dem Ende der Nutzereingabe und dem Beginn der Antwort bestimmt. Diese Verzögerung entsteht selten durch eine einzelne langsame Komponente. Sie summiert sich über mehrere unabhängige Stufen, die jeweils einige Dutzend oder Hundert Millisekunden beitragen. Um sie zu reduzieren, muss man wissen, wie viel Zeit jede Stufe benötigt.

Die Optimierung der Latenz von Sprachagenten besteht darin, diese Zeitverluste in jeder Stufe zu identifizieren und schrittweise zu minimieren.

Dieser Artikel ergänzt die konzeptionelle Latenzübersicht. Während dort erklärt wird, was Latenz ist, behandelt dieser Artikel Architektur und Messung. Sie erhalten ein messbares Latenzbudget und konkrete Maßnahmen.

Kurzfassung

• Time-to-first-audio umfasst die gesamte Pipeline, nicht nur die Inferenzzeit eines einzelnen Modells.
• Die Time-to-first-token des LLM und das Endpointing sind die größten Einzelposten.
• Durch Überlappung der Stufen, statt sie seriell auszuführen, lässt sich der Großteil des Budgets zurückgewinnen.
• Streaming, Codec-Auswahl und Player-Buffer-Optimierung sparen jeweils messbare Millisekunden.
• Sie sollten pro Region an Ihrer eigenen Implementierung messen und P50 sowie P95 berichten.

Definition des Latenzbudgets für Sprachagenten

Ein Latenzbudget ist ein Zielwert für die Time-to-first-audio, verteilt auf die Pipeline-Stufen. Jede Stufe erhält ein Zeitkontingent, das insgesamt unter Ihrem Zielwert liegen muss. Die Definition ist der erste Schritt und oft die Stelle, an der Fehler passieren, da Ingenieure zwei ähnlich aussehende, aber unterschiedlich bedeutende Zahlen verwechseln.

Die erste ist die Modell-Inferenzlatenz: die Zeit, die ein Modell zur Generierung benötigt. Für unsere Flash-Modelle beträgt sie etwa 75 ms für typische kurze Eingaben, ohne Netzwerk- und Anwendungs-Overhead. Das ist ein interner Wert, nützlich zum Modellvergleich, aber nicht das, was der Nutzer erlebt.

Aus Nutzersicht zählt die Time-to-first-audio (TTFA): die Zeit vom Ende der Nutzereingabe bis zum ersten hörbaren Sample der Agentenantwort. TTFA ist immer größer als die Inferenzlatenz eines einzelnen Modells, da sie die gesamte Pipeline umfasst.

Ein kaskadierter Sprachagent besteht aus fünf Stufen:

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

Audio wird vom Mikrofon aufgenommen, in Text transkribiert, an ein Sprachmodell gesendet, dessen Text wieder in Sprache umgewandelt und dann gepuffert und abgespielt. Jede Stufe fügt Latenz hinzu, und in mehreren Stufen ist der größte Kostenfaktor nicht immer der erwartete.

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

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

Die Tabelle visualisiert die Pipeline, suggeriert aber, dass die Stufen strikt seriell ablaufen – das ist nicht der Fall. Viele wichtige Latenzoptimierungen entstehen durch Überlappung, wodurch der Großteil des Budgets eingespart wird.

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

Transkription ist die zweite Stufe der Pipeline. Die eigentlichen Kosten entstehen weniger durch die Transkription selbst, sondern durch die Entscheidung, wann der Nutzer aufgehört hat zu sprechen. Dieser Abschnitt behandelt beide Aspekte zur Optimierung der Latenz.

Die Transkription erfolgt, bevor das LLM erreicht wird.Scribe v2 Echtzeit (scribe_v2_realtime) liefert Teiltranskripte in etwa 150 ms und streamt in Audio-Chunks, sodass das Transkript bereits während des Sprechens entsteht. Unterstützt werden PCM von 8 kHz bis 48 kHz und mu-law-Encoding, was für die Codec-Auswahl unten relevant ist. Die 150 ms für Teiltranskripte sind vernachlässigbar.

Der größere Latenzanteil entsteht beim Endpointing: dem Moment, in dem Ihr System entscheidet, dass der Nutzer seinen Beitrag beendet hat.

Voice Activity Detection (VAD) segmentiert Sprache anhand von Pausen. Hier summiert sich die Zeit. Wenn Sie z. B. 700 ms Stille abwarten, bevor Sie das Ende eines Beitrags feststellen, fügen Sie jeder Runde 700 ms hinzu – zusätzlich zur Transkription. Diese Verzögerung ist in Transkriptions-Benchmarks unsichtbar, aber in echten Gesprächen sehr präsent. Sie ist oft die größte steuerbare Latenz in der Pipeline und daher ein guter Ansatzpunkt.

Endpointing ist ein Kompromiss zwischen Reaktionsgeschwindigkeit und Unterbrechung. Ein kurzer Schwellenwert sorgt für schnelle Antworten, riskiert aber, Nutzer bei natürlichen Pausen zu unterbrechen. Ein langer Schwellenwert ist sicher, aber träge. In der Praxis optimieren drei Maßnahmen die Latenz bei Speech to Text:

1. Feinabstimmung des Stille-Schwellenwerts:Reduzieren Sie den Schwellenwert auf das kleinste Maß, das natürliche Pausen nicht abschneidet, und messen Sie die Unterbrechungsrate im Live-Betrieb statt zu schätzen.
2. Physikalisches Steuersignal einbinden: Verwenden Sie eine manuelle Bestätigung, wenn Ihre Anwendung das Ende des Beitrags aus einem anderen Signal erkennt (z. B. Push-to-Talk-Release, UI-Ereignis), statt auf den VAD-Timer zu warten.
3. Überlappung mit LLM-Prozessen:Leiten Sie stabile Teiltranskripte frühzeitig weiter. Geben Sie diese ins LLM und passen Sie ggf. an, falls das finale Transkript abweicht – eine Form von spekulativer Ausführung, die die Endpointing-Verzögerung hinter die LLM-Verarbeitung legt.

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

Der Latenzbeitrag des LLM

Das Sprachmodell ist meist der größte Einzelbeitrag zur TTFA. Hier zahlt sich Überlappung besonders aus. Der entscheidende Punkt: Der Agent benötigt nicht die komplette Antwort, bevor er zu sprechen beginnt.

Das Muster mit dem größten Latenzgewinn ist das Streaming von Tokens aus dem LLM und deren Übergabe an TTS, sobald sie eintreffen – jeweils an Satz- oder Satzteilgrenzen. Die Logik: Tokens bis zur Satzgrenze puffern, dann diesen Satz synthetisieren, während der nächste schon generiert 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ängere Gespräche empfiehlt sich der TTS WebSocket, damit eine offene Verbindung Text schrittweise empfangen kann, ohne für jeden Satz eine neue Verbindung aufzubauen. Nur die Zeit, in der das Modell tatsächlich Audio generiert, zählt für Ihr Parallelitätslimit. Eine offene, aber inaktive WebSocket-Verbindung ist nahezu kostenlos.

Text to Speech: Streaming und Stimmauswahl

Text to Speech ist die Stufe, bei der Sie die Latenz am präzisesten bestimmen können. Es gibt zwei Haupthebel: Wie Sie das Audio streamen und welche Stimme Sie wählen.

Flash v2.5 (eleven_flash_v2_5) ist das empfohlene Modell für Agenten. Es liefert etwa 75 ms Modell-Inferenz für kurze Eingaben, 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-Zeile im obigen Budget ist größer, da Netzwerk-Roundtrip und Server-Scheduling hinzukommen.

Der größte Hebel ist hier das Streaming. Wenn Sie das komplette Audio anfordern und abwarten, wartet der Nutzer auf die gesamte Synthese. Beim Streaming hört der Nutzer das erste Stück, sobald es generiert ist, der Rest folgt während des Abspielens. Streaming macht das Modell nicht schneller, sondern gibt das Audio schon während der Generierung aus.

Die Streaming-Anleitung beschreibt HTTP-Streaming, und die Echtzeit-WebSocket-Anleitung behandelt den WebSocket-Weg, den Sie beim Token-Streaming aus einem LLM benötigen.

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

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 direkt 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 Stimmauswahl, die ebenfalls Latenz kostet. Standardstimmen, synthetische Stimmen und Instant Voice Clones (IVCs) werden schneller synthetisiert als Professional Voice Clones (PVCs), da PVCs zusätzliche Modellkomplexität mitbringen. Für Agenten mit strengen Latenzanforderungen ist die Kombination aus Flash und IVC oder Standardstimme die Option mit der geringsten Latenz.

Auswahl der Streaming-Chunk-Größe

Mit Tokens, die in TTS fließen, und Audio, das zurückkommt, stellt sich die Frage nach der Chunk-Größe und wie viel der Player puffert, bevor er startet.

Kleinere Chunks erreichen den Player schneller und senken die First-Byte-Latenz, verursachen aber mehr Nachrichten und etwas mehr Overhead pro Chunk. Größere Chunks sind effizienter zu übertragen, lassen den Nutzer aber länger auf das erste Stück warten. Für interaktive Agenten empfiehlt sich zu Beginn kleinere Chunks, da auf das erste Stück gewartet wird; spätere Chunks kommen während der Wiedergabe und deren Größe ist weniger relevant.

Der Player verursacht einen erheblichen Teil der verbleibenden Latenz. Die meisten Audioplayer starten nicht mit dem ersten Byte, sondern puffern, um Stottern bei kurzen Verzögerungen zu vermeiden. Ein 500-ms-Standardpuffer ist üblich und wird direkt zur wahrgenommenen Latenz addiert. Eine Reduzierung erhöht das Stotterrisiko leicht, senkt aber die TTFA. Der optimale Wert hängt vom Netzwerk-Jitter zwischen Server und Client ab:

• Bei stabiler Verbindung (Server-seitige Wiedergabe, co-lokalisierter Client) sind 50 bis 150 ms Puffer meist sicher und reduzieren die TTFA spürbar.
• Bei instabiler mobiler oder regionsübergreifender Verbindung verhindert ein größerer Puffer hörbare Lücken, die schlimmer sind als die verursachte Latenz.

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

Codec-Auswahl

Das Zielgerät bestimmt den gewünschten Codec. Wir liefern Formate wie mp3_44100_128, mp3_22050_32, pcm_16000, pcm_24000 und ulaw_8000. Die Wahl des nativen Formats des Transports vermeidet eine zusätzliche Transkodierung und hilft bei der Latenzoptimierung.

Für Telefonie, etwa Twilio und ähnliche Anbieter, verwenden Sie ulaw_8000. Das Telefonnetz arbeitet durchgehend mit 8 kHz mu-law, daher vermeiden Sie durch direkte Anforderung eine Transkodierung und entsprechen den Erwartungen des Netzbetreibers. Hochwertigeres Audio zu erzeugen bringt keinen Vorteil, da das Netz ohnehin sofort herunterrechnet – Sie würden nur Latenz hinzufügen, ohne hörbaren Gewinn.

Für WebRTC und Browser-Wiedergabe nutzen Sie PCM (pcm_24000 oder pcm_16000) oder ein MP3-Format. PCM ist unkomprimiert, sodass keine Decodierung auf dem Client nötig ist – das spart pro Chunk etwas Latenz und ist praktisch, wenn Sie direkt eine Web Audio-Pipeline speisen. MP3 ist auf der Leitung kompakter, was bei eingeschränkten Verbindungen hilft, erfordert aber eine leichte Decodierung auf dem Client.

Geografie und Netzwerkdistanzen

Alle oben genannten Optimierungen setzen kurze Übertragungswege voraus. Die Geografie bestimmt das Minimum Ihres Latenzbudgets – prüfen Sie dies, bevor Sie weiter optimieren.

Wir bedienen Anfragen aus Clustern in Nordamerika, Europa und Südostasien und routen jede Anfrage automatisch zum nächstgelegenen Cluster. Die Netzwerk-Roundtrip-Zeit über das öffentliche Internet liegt typischerweise zwischen 20 und 200 ms, abhängig von der Entfernung, und lässt sich nur durch Standortwechsel der Infrastruktur reduzieren.

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

Die Lösung ist, Ihre Anwendungsserver bei Ihren Nutzern zu betreiben, nicht nur bei uns. Sind Ihre Nutzer in Europa, betreiben Sie Ihr Backend ebenfalls dort, damit der Weg Nutzer-zu-Ihrem-Server kurz ist; unser Routing übernimmt dann den Weg Ihr-Server-zu-Modell aus einem nahegelegenen Cluster.

So messen Sie die Latenz Ihres Sprachagenten selbst

Die Zahlen in der obigen Latenztabelle sind Beispielwerte zur Planung. Die Werte für Ihre Anwendung sollten Sie mit einem eigenen Skript wie diesem an Ihrer eigenen Implementierung messen.

Die folgende Instrumentierung misst die TTFA für die TTS-Stufe isoliert – also die Zeit von der Anfrage bis zum ersten Audio-Chunk – über viele Durchläufe und gibt die Perzentile aus. Führen Sie sie aus der gleichen Region aus, in der Ihre Server laufen, nicht von Ihrem Entwicklungsrechner. Sie setzt den oben genannten 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 Hinweise:

• Berichten Sie P50 und P95:Konzentrieren Sie sich darauf, nicht auf den Mittelwert. Der Mittelwert verschleiert Ausreißer, und diese sorgen für ein unzuverlässiges Gefühl. P95 entspricht einer Runde von zwanzig.
• Regionale Messungen: Führen Sie das gleiche Skript aus jeder bedienten Region aus und halten Sie die Ergebnisse getrennt.
• Anfragen staffeln für Genauigkeit:Verteilen Sie Ihre Anfragen (siehe setTimeout oben). Wenn Sie alle gleichzeitig senden, messen Sie Ihre eigene Warteschlange statt den Service. Bei Überschreitung des Parallelitätslimits werden Anfragen nach Priorität eingereiht (typisch ca. 50 ms zusätzlich), bei Überlast erhalten Sie HTTP 429.
• Messen Sie die gesamte Latenzkette:Übertragen Sie das gleiche Timing-Muster auf die anderen Stufen. Messen Sie STT-Finalisierung, LLM-First-Token und Player-Start jeweils mit performance.now(), um die gesamte Budgettabelle mit Ihren eigenen Werten zu füllen und die kritischste Stufe zu identifizieren.

Mit diesen Tipps können Sie die Latenz Ihres Sprachagenten selbst messen und daraus klare Prioritäten ableiten.

Was reduziert die Latenz von Sprachagenten am stärksten?

Wenn Sie schnelle Maßnahmen suchen, sind dies die wichtigsten Hebel.

In etwa nach Wirkung sortiert, können Sie mit folgenden Methoden die Agentenlatenz senken:

• Starten Sie die LLM-Verarbeitung auf stabilen STT-Teiltranskripten, um die Endpointing-Verzögerung zu verbergen.
• Streamen Sie LLM-Tokens an Satzgrenzen in TTS, sodass die Synthese von Satz eins mit der Generierung von Satz zwei überlappt.
• Streamen Sie TTS-Audio zum Player und reduzieren Sie den Player-Puffer auf das Minimum, das Ihr Netzwerk-Jitter erlaubt.
• Nutzen Sie Flash plus eine Standardstimme oder IVC für die niedrigste TTS-Latenz und passen Sie den Codec an den Transport an (ulaw_8000 für Telefonie, PCM oder MP3 für Browser/WebRTC).
• Betreiben Sie Ihre Server in Nutzer-Nähe und messen Sie pro Region, da die Netzwerkwege real und unterschiedlich sind.

Für weitere spezifische Techniken siehe den How-to-Entwicklerleitfaden zur Latenzoptimierung. Für einen vollständigen Einstieg bieten API-Quickstart und die Streaming-Anleitung komplette Beispiele.

Sie möchten schnelleren Zugriff auf feinabgestimmte Agenten-Kaskaden?ElevenAgents implementiert diese Pipeline mit bereits integrierten Überlappungsoptimierungen.

Erstellen Sie latenzarme Sprachagenten mit ElevenAgents

Die Optimierung der Latenz von Sprachagenten erfordert die Messung jeder Stufe und das Überlappen der Stufen, sodass die langsamsten im Hintergrund laufen. Sie können diese Kaskade manuell über mehrere Iterationen aufbauen und anpassen oder direkt mit einer Pipeline starten, die bereits Latenzoptimierungen enthält.

ElevenAgents implementiert die gesamte Kaskade – vom Streaming-STT über Token-Übergabe ans LLM bis zu Flash TTS – mit integrierten Überlappungstechniken. Statt bei Null zu beginnen, passen Sie nur noch die Schwellenwerte für Ihre wichtigsten Leistungsziele an.

Starten Sie mit ElevenAgents, um heute einen Agenten zu erstellen oder Vertrieb zu kontaktieren für weitere Informationen.

FAQs zur Optimierung der Latenz von Sprachagenten