Latenz bei Sprach-KI: Warum die 800-ms-Schwelle zählt und wie man sie misst

Sie stellen am Telefon eine Frage, und die Gegenseite schweigt: eine Sekunde, anderthalb Sekunden ... In dem Moment, in dem Sie „Sind Sie noch dran?“ sagen, ist der natürliche Rhythmus des Gesprächs gebrochen. Bei Sprach-KI-Assistenten heißt diese Wartezeit Turn-Latenz (turn latency), und sie ist eines der wichtigsten technischen Kriterien dafür, ob ein Assistent sich menschlich anfühlt oder nicht.

Dieser Beitrag behandelt die Forschungsergebnisse zum natürlichen Rhythmus menschlicher Gespräche, die Latenzschwellen der Telekommunikationsstandards sowie die Frage, woher Latenz bei Sprach-KI kommt und wie man sie misst; am Ende zeigen wir, wie ein Anbieterwert samt seinen Bedingungen zu lesen ist.

Warum ist Latenz bei Sprach-KI wichtig?

Weil menschliche Gespräche mit einem erstaunlich schnellen Sprecherwechsel funktionieren. In der 2009 in PNAS veröffentlichten Studie von Stivers und Kollegen über 10 Sprachen lag der dichteste Bereich der Sprecherwechsel in allen Sprachen bei 0–200 ms; die sprachspezifischen Mittelwerte blieben innerhalb von etwa 250 ms um den sprachübergreifenden Mittelwert [1]. Dieselbe Studie zeigte, dass das Vermeiden von Überlappungen und das Minimieren der Stille zwischen Gesprächsbeiträgen ein sprachunabhängiges Universal ist [1].

Die Arbeit von Levinson und Torreira aus dem Jahr 2015 vervollständigt das Bild: Die Lücke zwischen Beiträgen liegt in der Größenordnung von 200 ms, und der Großteil der Übergänge fällt zwischen −100 und 500 ms; die Latenz der Sprachproduktion selbst ist dagegen deutlich länger, über 600 ms [2]. Menschen beginnen ihre Antwort also zu planen, während die andere Person noch spricht; das Verstehen ist prädiktiv [2]. Für Sprach-KI ist die Folge klar: Ein System, das erst auf das Verstummen des Anrufers wartet und dann zu denken beginnt, erreicht den menschlichen Rhythmus nicht.

Die Telekommunikationswelt setzt hierzu seit Jahrzehnten Regeln. Laut ITU-T-Empfehlung G.114 erleben die meisten Anwendungen eine „im Wesentlichen transparente Interaktivität“, wenn die Einwegverzögerung („Mund zu Ohr“) unter 150 ms gehalten werden kann; über 400 ms gilt für die allgemeine Netzplanung als inakzeptabel [3]. Dasselbe Dokument betont, dass hochinteraktive Aufgaben wie Sprachanrufe schon von deutlich geringeren Verzögerungen beeinträchtigt werden können [3]. Das E-Modell in ITU-T G.107 berücksichtigt die Verzögerung als eigenen Beeinträchtigungsfaktor (Id), der den Qualitätswert R senkt; nach der vorläufigen Richttabelle in Anhang B des Dokuments (übernommen aus G.109) wird ein R-Wert von 90 und mehr als „sehr zufrieden“, die 80er als „zufrieden“, die 70er als „einige Nutzer unzufrieden“ und die 60er als „viele Nutzer unzufrieden“ gelesen [4].

Kurz: Der menschliche Rhythmus liegt bei ~200 ms; das Telefonnetz selbst beansprucht in eine Richtung bis zu ~400 ms, und das kommt zur Turn-Latenz noch hinzu. Sprach-KI landet meist über beiden Werten, weil zur Netzverzögerung noch die „Denkzeit“ hinzukommt.

Wie schnell sollte ein KI-Telefonassistent antworten?

Die Definition im eigenen Engineering-Beitrag von Vapi lautet: Latenz ist die Zeit zwischen dem Ende des Satzes des Nutzers und dem Beginn des Satzes des Agenten [5]. Demselben Beitrag zufolge bricht der Gesprächsfluss, sobald diese Zeit 1.200 ms überschreitet; das ist ungefähr die Zeit, die der Nutzer braucht, um einen abschweifenden Gedanken zu fassen [5]. Als ähnliche Anbieterbeobachtung schreibt Telnyx, dass Anrufer oberhalb von 1.500 ms das Gespräch als „gebrochen“ empfinden [6].

In diesem Beitrag schlagen wir 800 ms als praktische Obergrenze vor; sie ist weder ein ITU-Standard noch ein begutachtetes Forschungsergebnis, sondern eine Ingenieursentscheidung. Die Begründung: Die 400-ms-Toleranz von G.114 gilt allein für die Einwegverzögerung des Netzes [3]; die Turn-Latenz addiert dazu die Zeit für STT, Sprachmodell und TTS. Der menschliche Rhythmus ist damit nicht zu erreichen, dennoch muss man mit sicherem Abstand unter dem Bruchpunkt von 1.200 ms [5] bleiben. Wir schlagen 800 ms als Arbeitsschwelle vor, von der wir annehmen, dass Anrufer sie tolerieren, ohne das Gefühl „es kommt keine Antwort“ zu bekommen, und die technisch erreichbar ist; auch der Vergleichsbeitrag von Telnyx beschreibt alles über 800 ms als „spürbar verzögert“ [6]. Darüber wird das Warten hörbar, weit darüber kommt die Frage „Sind Sie noch dran?“.

Latenz kommt nicht aus einem einzelnen Teil; sie ist die Summe einer Kette:

• Sprache-zu-Text (STT): Für Streaming-Erkennung definiert Deepgram die „Transkript-Latenz“ (wie weit das Transkript dem Audio hinterherhinkt) und die „End-of-Turn-Latenz (EOT)“ (die Zeit vom Verstummen des Nutzers bis zum Empfang des End-of-Turn-Ereignisses) als getrennte Metriken und nennt die zweite als für Sprachagenten meist entscheidend [7].
• Sprachmodell (LLM): Laut den Ingenieuren von Vapi fast immer der Engpass der Kette; zu messen ist die „Zeit bis zum ersten sinnvollen Satz“ [5].
• Sprachsynthese (TTS): ElevenLabs gibt für seine Flash-Modelle rund 75 ms Inferenzzeit an und weist darauf hin, dass Streaming-Endpunkte das Audio stückweise während der Erzeugung liefern und so die Zeit bis zum ersten Byte verkürzen [8].
• Telefonie: Codec, Jitter-Puffer, Echounterdrückung und die eigene Verzögerung des SIP-/Carrier-Pfads. Die 150/400-ms-Schwellen der ITU [3] messen genau diese Schicht.

Komponentenwerte auf Anbieterseiten sind keine Produktversprechen, sondern Beispiele dafür, dass „jedes Glied seine eigenen Kosten hat“; die Latenz, die der Anrufer spürt, ist die Summe aller Glieder.

Wie misst man die Latenz von Sprach-KI?

Für eine vergleichbare Messung muss zuerst die Metrik definiert sein. Die Dokumentation von Retell definiert es genauso: „End-to-End-Latenz“ ist die Gesamtzeit vom Moment, in dem der Nutzer zu sprechen aufhört, bis zu dem Moment, in dem der Agent zu antworten beginnt [9]. Manche Quellen nennen das „Time-to-first-Audio“; gemessen wird dasselbe: der Abstand zwischen dem Beginn der Stille und der ersten Silbe aus dem Lautsprecher.

Eine einzelne Zahl ist irreführend. Deepgram weist darauf hin, dass Latenz natürlicherweise schwankt und statt mit einer Einzelmessung mit Perzentil-Statistiken über repräsentative Stichproben verfolgt werden sollte [7]. Die Dokumentation von Retell schlüsselt die Latenz pro Anruf ebenfalls in Komponenten wie STT, LLM, TTS und Wissensdatenbank auf und berichtet p50-, p90-, p95- und p99-Werte [9]. Ist die Zahl, die Sie vom Anbieter bekommen, ein p50, fragen Sie gesondert nach der p90-Erfahrung, die jeder zehnte Anruf haben wird.

Ein einfaches Protokoll zum Testen eines Anbieters:

• Führen Sie mindestens 20 echte Anrufe von derselben Telefonleitung im selben Zeitfenster; schreiben Sie Ihre Testsätze vorab und verwenden Sie bei jedem Anbieter dieselben Sätze.
• Halten Sie bei jedem Anruf den Moment fest, in dem der Anrufer verstummt, und den Moment, in dem die erste Silbe des Agenten zu hören ist (ein Audiorekorder auf Ihrem eigenen Gerät und ein Wellenform-Viewer genügen); messen Sie über das echte Telefonnetz, nicht über eine Browser-Demo.
• Berechnen Sie statt des Durchschnitts den Median (p50) und p90; die Spanne zwischen beiden zeigt, wie stabil das System ist.
• Notieren Sie, mit welcher Audioqualität und welcher Kontextlänge Sie gemessen haben: Eine mit kurzem System-Prompt gemessene Latenz muss nicht mit dem langen Prompt Ihres echten Szenarios übereinstimmen.
• Machen Sie mitten in einem langen Satz eine Sekunde Pause und notieren Sie, ob der Agent Ihnen ins Wort fällt; das ist ein ebenso wichtiges Qualitätskriterium wie die Geschwindigkeit.

Wie viele Sekunden sollte die KI am Telefon warten, bevor sie ins Wort fällt?

Diese Frage lautet eigentlich: „Nach wie viel Stille sollte das System entscheiden, dass es an der Reihe ist?“ Einen einzig richtigen Wert gibt es nicht; der Ansatz ist, mit rund einer halben Sekunde zu beginnen und den Wert an das Szenario anzupassen. In der Dokumentation von Vapi beträgt diese Wartezeit standardmäßig 0,4 Sekunden; empfohlen wird, sie zu erhöhen, wenn der Assistent zu früh spricht, und zu verringern, wenn die Verzögerung zu groß ist [10]. Das intelligente Endpointing in demselben Dokument versucht zu erkennen, ob der Nutzer wirklich fertig ist, auch wenn er mitten im Gedanken pausiert; für den audiobasierten Anbieter Krisp wird eine Schwelle zwischen 0 und 1 (Standard 0,5) definiert, wobei ein niedrigerer Wert eine flinkere und ein höherer Wert eine vorsichtigere Erkennung bedeutet [10].

Das Dilemma ist klar: Eine kürzere Wartezeit senkt die Latenz, erhöht aber die Wahrscheinlichkeit, dass das System dem Anrufer ins Wort fällt. Pausen innerhalb eines Beitrags sind in menschlicher Sprache normal; Übergänge haben eine natürliche Verteilung bis zu 500 ms [2]. Eine feste, sehr kurze Stilleschwelle wird einen Anrufer, der eine Adresse nennt, eine Ausweisnummer vorliest oder beim Sprechen nachdenkt, immer wieder unterbrechen; jede Unterbrechung kostet mehr, als die gewonnene Latenz einbringt.

Die andere Seite der Frage ist das Barge-in: Fällt der Anrufer dem Agenten ins Wort, sollte der Agent verstummen, zuhören und dem Anrufer das Wort überlassen. Auch hier wird eine Dauer eingestellt: Die Dokumentation von Vapi definiert getrennt, wie viele Wörter der Anrufer sagen (Standard 0) oder wie viele Sekunden er sprechen muss (Standard 0,2 s), bevor der Assistent verstummt, und wie lange der Assistent nach einer Unterbrechung wartet, bevor er wieder zu sprechen beginnt (Standard 1 s) [10]. Die Schwierigkeit besteht darin, eine echte Unterbrechung von Bestätigungslauten wie „mhm“ oder „ja“ zu unterscheiden [10]; ein Agent, der bei jedem Bestätigungslaut verstummt, bringt keinen Satz zu Ende, und einer, der nie verstummt, wirkt, als höre er nicht zu.

Eine zweite Beschleunigungsfalle ist das Kürzen des Kontexts. Wer den Gesprächsverlauf und den System-Prompt, die an das Sprachmodell gehen, aggressiv beschneidet, kann die Zeit bis zum ersten Satz senken; doch der Agent vergisst den Namen, das Datum oder die Beschwerde von vor drei Beiträgen, und der Anrufer muss dieselbe Information erneut geben. Eine Verbesserung, die auf dem Messblatt gut aussieht, erzeugt im echten Gespräch einen längeren und ärgerlicheren Anruf. Deshalb wird jede Latenzzahl erst zusammen mit der Frage „bei welcher Audioqualität und ohne gekürzten Kontext?“ aussagekräftig.

Ein Assistent, der schnell, aber vergesslich ist oder einem ins Wort fällt, ist schlechter als ein langsamer; Latenz zu senken lohnt sich nur, wenn Kontext und Höflichkeit erhalten bleiben.

Die gemessene Turn-Latenz von AvaritCall und ihre Bedingungen

Die folgenden Werte sind AvaritCalls eigene interne Messungen und verwenden dieselbe Metrik wie oben definiert: die Zeit vom Ende der Äußerung des Anrufers bis zum Beginn der gesprochenen Antwort des Agenten. Alle wurden in Opus-Audioqualität und ohne Kürzung des Kontexts erhoben; es sind Durchschnittswerte, und Messdatum, Anzahl der Anrufe sowie eine p50/p95-Verteilung werden nicht veröffentlicht. Der Wert für die Türkei entspricht der Angabe „0,8 s durchschnittliche Antwortzeit“ auf der türkischen Preisseite; die Werte für Europa und die USA sind ausschließlich interne Messungen.

• Türkei: ~0,8 s
• Europa: ~0,6 s
• USA: 0,45–0,5 s

AvaritCall entwickelt seine Telefonieschicht selbst (Codec-Management einschließlich Opus, Echounterdrückung, Kanal- und Concurrency-Management; SIP-Trunk- und DID-Unterstützung). So lässt sich der gesamte Audiopfad Ende-zu-Ende optimieren. Der Preis ist nutzungsbasiert: 0,08 $ pro Gesprächsminute (STT, LLM und TTS inklusive, ein Posten), 5 $ Guthaben bei der Registrierung, keine Bindung. Mit dem Startguthaben von 5 $ können Sie das obige Protokoll von Ihrer eigenen Leitung aus durchführen und diese Werte selbst prüfen (avaritcall.com/de/pricing).

Lärm und lange Antworten: wo die Schwelle nicht hält

• Die ~0,8 s in der Türkei (unter denselben Bedingungen) sind noch immer das Vierfache des menschlichen Rhythmus von ~200 ms (sprachübergreifender Mittelwert) [1][2]; die Erwartung sollte nicht „so schnell wie ein Mensch“ lauten, sondern „schnell genug, dass es sich nicht wie Warten anfühlt“.
• In sehr lauten Umgebungen (Werkstatt, Straße, Auto mit Freisprecheinrichtung) sinkt die Erkennungsgenauigkeit; das Endpointing kann Lärm für Sprache halten, und auch die Latenz wird instabil. Das gilt auch für AvaritCall.
• Lange Antworten: Muss der Agent vor der Antwort eine Wissensdatenbank oder ein Tool abfragen, wächst die Zeit bis zum ersten Satz; in der Aufschlüsselung von Retell ist die Wissensdatenbank eine eigene Latenzkomponente [9]. Spricht der Agent selbst lange, entscheidet nicht die Latenz, sondern ob der Anrufer ins Wort fallen kann. 800 ms sind eine sinnvolle Schwelle für kurze, einsätzige Beiträge.
• Die gemessene Latenz bedeutet nicht, dass der Agent das Richtige gesagt hat. Entscheidungen mit rechtlichen, medizinischen oder finanziellen Folgen müssen an einen Menschen übergeben werden; AvaritCall ist nicht dafür ausgelegt, Notrufleitungen zu ersetzen.
• Die Auswahl von STT/LLM/TTS auf Komponentenebene ist bei AvaritCall eingeschränkter als auf Entwicklerplattformen; für Teams, die jedes Glied selbst wählen wollen, ist das ein Nachteil.
• Die gleichzeitige Kapazität hängt vom Paket ab; sehr hohe Concurrency erfordert das Enterprise-Paket. Bildet sich an der Kapazitätsgrenze eine Warteschlange, entsteht eine Wartezeit, die von der Turn-Latenz unabhängig ist.

Zusammengefasst: Menschen wechseln sich in ~200 ms ab [1][2], das Netz selbst beansprucht in eine Richtung bis zu ~400 ms, und das kommt zur Turn-Latenz noch hinzu [3], und laut dem Engineering-Beitrag von Vapi bricht das Gespräch bei Sprach-KI bei 1.200 ms [5]. Die 800 ms dazwischen sind kein Standard und kein Versprechen, sondern eine Messdisziplin: echte Leitung, p50 und p90, gleiche Audioqualität, ungekürzter Kontext. Die Werte aus Anbieterdokumentationen stammen von Seiten, die am 30. August 2026 abgerufen wurden; Anbieter können sie ändern.