Wie optimieren Sie die Latenz für Konversations-KI?

Für die meisten Anwendungen ist Latenz nur ein geringes Thema. Bei Konversations-KI ist sie jedoch entscheidend für die Qualität der Anwendung.

Das Ziel von Konversations-KI ist es, das Gefühl, den Ton und die Stimme eines echten Gesprächs zu vermitteln – und dabei intelligenter als ein Mensch zu sein. Dafür muss die Anwendung ohne lange Pausen antworten. Sonst geht die Realitätsnähe verloren.

Die Latenzherausforderung bei Konversations-KI wird durch ihren modularen Aufbau verstärkt. Sie besteht aus mehreren Teilprozessen, die jeweils Stand der Technik sind. Jeder dieser Schritte trägt zur Gesamtlatenz bei.

Als Unternehmen für generative Stimmen haben wir intensiv daran gearbeitet, die Latenz für Konversations-KI zu minimieren. Heute teilen wir unsere Erkenntnisse, um allen, die Konversations-KI-Anwendungen entwickeln, Hilfestellung zu geben.

Die vier Kernkomponenten

Jede Konversations-KI-Anwendung umfasst mindestens vier Schritte: Sprache zu Text, Turn-Taking, Textverarbeitung (z. B. LLMs) und Text zu Sprache. Diese Schritte laufen zwar parallel, aber jeder trägt zur Gesamtlatenz bei.

Die Latenzstruktur bei Konversations-KI ist besonders. In vielen Prozessen gibt es einen klaren Engpass. Bei einer Website etwa bestimmt die Netzwerklatenz die Gesamtlatenz. Bei Konversations-KI sind die Latenzanteile der einzelnen Komponenten jedoch ähnlich groß. Die Gesamtlatenz ergibt sich aus der Summe aller Teile.

Automatische Spracherkennung

Das „Ohr“ des Systems

Automatische Spracherkennung (ASR) – auch bekannt als Sprache zu Text (STT) – wandelt gesprochene Sprache in geschriebenen Text um.

Die Latenz der ASR ist nicht die Zeit, um Text zu generieren, da Sprache zu Text im Hintergrund läuft, während der Nutzer spricht. Entscheidend ist die Zeit zwischen dem Ende der Spracheingabe und dem Abschluss der Texterstellung.

Daher können kurze und lange Sprechintervalle ähnliche ASR-Latenzen verursachen. Die Latenz variiert je nach ASR-Implementierung (in manchen Fällen gibt es keine Netzwerklatenz, wenn das Modell direkt im Browser läuft, wie bei Chrome/Chromium). Das Standardmodell Whisper fügt 300 ms+ Latenz hinzu. Unsere eigene Lösung liegt bei unter 100 ms.

Turn-Taking / Unterbrechung

Der „Instinkt“ des Systems

Turn-Taking / Unterbrechung (TTI) ist ein Zwischenschritt, der erkennt, wann der Nutzer fertig gesprochen hat. Das zugrundeliegende Modell heißt Voice Activity Detector (VAD).

Turn-Taking folgt komplexen Regeln. Ein kurzes „Hm“ sollte keinen Gesprächswechsel auslösen, sonst wirkt das Gespräch abgehackt. Das System muss erkennen, wann der Nutzer wirklich die Aufmerksamkeit des Modells möchte und wann er fertig ist.

Ein gutes VAD wird nicht bei jedem Schweigen einen neuen Gesprächswechsel signalisieren. Es gibt Pausen zwischen Wörtern und Sätzen, und das Modell muss sicher sein, dass der Nutzer wirklich fertig ist. Dafür sucht es nach einer bestimmten Schwelle an Stille (bzw. fehlender Sprache). Dieser Prozess führt zu einer Verzögerung und trägt zur Gesamtlatenz bei.

Technisch gesehen wäre die durch TTI verursachte Latenz akzeptabel, wenn alle anderen Komponenten der Konversations-KI keine Latenz hätten. Menschen machen nach dem Sprechen eine kurze Pause. Eine ähnliche Verzögerung durch die Maschine erhöht die Natürlichkeit. Da aber auch andere Komponenten Latenz verursachen, sollte die TTI-Latenz möglichst gering sein.

Textverarbeitung

Das Gehirn des Systems

Im nächsten Schritt muss das System eine Antwort generieren. Heute geschieht das meist mit einem Large Language Model (LLM) wie GPT-4 oder Gemini Flash 1.5.

Die Wahl des Sprachmodells hat großen Einfluss. Modelle wie Gemini Flash 1.5 sind sehr schnell und liefern Ergebnisse in unter 350 ms. Leistungsfähigere Modelle wie GPT-4-Varianten oder Claude benötigen 700 bis 1000 ms.Die Wahl des passenden Modells ist meist der einfachste Weg, um die Latenz bei Konversations-KI zu optimieren.

Die Latenz des LLM ist die Zeit, um mit der Erzeugung der Tokens zu beginnen. Diese Tokens können direkt an den nächsten Text zu Sprache Prozess gestreamt werden. Da Text zu Sprache durch das natürliche Sprechtempo begrenzt ist, ist das LLM meist schneller – entscheidend ist die Latenz bis zum ersten Token (Time to First Byte).

Weitere Faktoren beeinflussen die LLM-Latenz, etwa die Länge des Prompts und die Größe der Wissensbasis. Je mehr das LLM berücksichtigen muss, desto länger dauert es. Unternehmen müssen daher ein Gleichgewicht zwischen ausreichendem Kontext und Effizienz finden.

Text zu Sprache

Der „Mund“ des Systems

Die letzte Komponente der Konversations-KI ist Text zu Sprache (TTS). Die Latenz von Text zu Sprache ist die Zeit, bis nach Erhalt der Tokens mit dem Sprechen begonnen wird. Da weitere Tokens schneller bereitstehen als gesprochen werden kann, zählt nur die Zeit bis zum ersten Byte.

Früher war Text zu Sprache besonders langsam und benötigte 2–3 Sekunden für die Sprachausgabe. Moderne Modelle wie unsere Turbo-Engine erzeugen Sprache mit nur 300 ms Latenz, die neue Flash TTS Engine ist noch schneller. Flash hat eine Modellzeit von 75 ms und erreicht eine End-to-End-Latenz von 135 ms bis zum ersten Audio-Byte – der beste Wert im Feld.

Weitere Einflussfaktoren

Neben den vier Kernkomponenten gibt es weitere Faktoren, die die Gesamtlatenz der Konversations-KI beeinflussen.

Netzwerklatenz

Es gibt immer eine Latenz beim Übertragen von Daten zwischen Standorten. Für manche Konversations-KI-Anwendungen sollten ASR, TTI, LLM und TTS idealerweise am selben Ort laufen, sodass die einzige relevante Netzwerklatenz zwischen Sprecher und System entsteht.Das verschafft uns einen Vorteil, da wir durch eigene TTS- und Transkriptionslösungen zwei Serveranfragen einsparen können.

Function Calling

Viele Konversations-KI-Anwendungen dienen dazu, Funktionen auszuführen (z. B. Tools oder Dienste anzusteuern). Zum Beispiel kann ich die KI bitten, das Wetter zu prüfen. Dafür sind zusätzliche API-Aufrufe auf der Textverarbeitungsebene nötig, die je nach Anforderung mehr Latenz verursachen können.

Wenn ich zum Beispiel eine Pizza bestellen möchte, sind mehrere API-Aufrufe nötig, manche mit erheblicher Verzögerung (z. B. Kreditkartenprüfung).

Eine Konversations-KI kann Verzögerungen beim Function Calling abmildern, indem das LLM dem Nutzer schon vor Abschluss des Funktionsaufrufs antwortet (z. B. „Ich prüfe das Wetter für Sie“). Das entspricht einem echten Gespräch und hält den Nutzer im Kontakt.

Solche asynchronen Abläufe werden meist mit Webhooks umgesetzt, um lange Anfragen zu vermeiden.

Telefonie

Eine weitere Funktion von Konversations-KI-Plattformen ist die Möglichkeit, sich per Telefon einzuwählen (oder Anrufe im Namen des Nutzers zu tätigen). Telefonie verursacht zusätzliche Latenz, die stark von der Region abhängt.

Innerhalb einer Region entstehen durch Telefonie etwa 200 ms zusätzliche Latenz. Bei internationalen Gesprächen (z. B. Asien → USA) kann die Latenz auf etwa 500 ms steigen. Das ist relevant, wenn Nutzer Telefonnummern außerhalb ihrer Region verwenden und das Gespräch über das jeweilige Landesnetz geführt wird.

Abschließende Gedanken

Wir hoffen, dieser Überblick über Konversations-KI-Agenten war interessant. Anwendungen sollten eine Latenz von unter einer Sekunde anstreben. Das gelingt meist durch die Wahl des passenden LLM. Außerdem sollte der Nutzer eingebunden werden, wenn im Hintergrund komplexe Prozesse laufen, um lange Pausen zu vermeiden.

Am Ende geht es darum, Realismus zu schaffen. Der Nutzer soll das Gefühl haben, mit einem Menschen zu sprechen, und gleichzeitig die Vorteile eines Computerprogramms nutzen. Durch die Optimierung der Teilprozesse ist das heute möglich.

Bei ElevenLabs optimieren wir jede Komponente eines Konversations-KI-Stimmenagenten-Systems mit unseren modernen STT- und TTS-Modellen. Durch die Optimierung jedes Prozessschritts ermöglichen wir nahtlose Gesprächsabläufe. Dieser ganzheitliche Ansatz erlaubt es uns, an jeder Stelle etwas Latenz einzusparen – selbst 1 ms zählt.