Die Frage
Stellen Sie sich vor, Sie rufen bei einem Unternehmen an. Sie stellen eine Frage. Und dann: Stille.
Eine Sekunde. Anderthalb. Zwei.
Sie wissen nicht, ob die Leitung steht. Ob Ihr Gegenüber nachdenkt. Ob das System abgestürzt ist.
Jetzt stellen Sie sich vor, das Gegenüber antwortet in einer halben Sekunde — schneller als die meisten menschlichen Gesprächspartner. Die Antwort kommt, bevor Sie anfangen, an der Verbindung zu zweifeln.
Zwischen diesen beiden Szenarien liegen 1.000 Millisekunden. Und diese 1.000 Millisekunden entscheiden darüber, ob Ihr Anrufer den KI-Telefonassistenten als kompetenten Assistenten wahrnimmt — oder als kaputtes System.
Die meisten Voicebot-Vergleiche bewerten Features: Wie viele Sprachen? Welche Integrationen? Wie teuer? Der einzige KPI, der darüber entscheidet, ob ein Anrufer dranbleibt oder auflegt, wird dabei selten gemessen: Latenz.
Was unter der Haube passiert
Das menschliche Maß: 200 Millisekunden
Eine Studie von Stivers, Enfield und Kollegen (2009) hat Turn-Taking in Gesprächen über 10 Sprachen und Kulturen hinweg analysiert. Das Ergebnis: Menschen antworten sich im Median in 208 Millisekunden.
Das ist kein Zielwert. Das ist das biologische Substrat menschlicher Konversation. Unser Gehirn ist darauf kalibriert. Alles, was deutlich darüber liegt, fühlt sich zunehmend unnatürlich an.
Die 500ms-Schwelle: Wo Natürlichkeit beginnt
Unter 200ms ist für aktuelle KI-Systeme nicht erreichbar. Aber unter 500ms — das ist der Bereich, in dem ein Gespräch sich noch natürlich anfühlt. Nicht perfekt menschlich, aber flüssig genug, dass der Anrufer nicht ins Grübeln kommt.
Ab 800ms beginnt die Erosion. Industry-Benchmarks von Deepgram, AssemblyAI und SignalWire dokumentieren: Jenseits dieser Schwelle steigt das Abbruchrisiko signifikant. Jede zusätzliche Sekunde Verzögerung korreliert mit bis zu 16% niedrigerer Kundenzufriedenheit.
Warum die kaskadierende Pipeline 500ms nie erreicht
Die meisten Voicebots am Markt arbeiten mit einer dreistufigen Pipeline: Anrufer spricht → STT wandelt in Text → LLM generiert Antwort → TTS liest vor. Drei separate Systeme. Drei Netzwerk-Roundtrips. Selbst bei optimaler Konfiguration mit Streaming dauert das 2–3 Sekunden.
Audio-native Verarbeitung: Ein Roundtrip statt drei
Die OpenAI Realtime API arbeitet anders. Das Modell verarbeitet Audio direkt — ohne Umweg über Text. Ein einziger Roundtrip statt drei. Gemessene Time-to-First-Voice: 450–900ms (Skywork.ai Benchmark, 2025). Das ist der Bereich, in dem 500ms Antwortzeit erstmals technisch möglich wird.
Was die meisten übersehen
Der blinde Fleck: Voice Activity Detection
Die reine Modell-Antwortzeit ist nur ein Teil der Geschichte. Bevor das Modell antwortet, muss ein vorgelagertes System entscheiden, wann der Anrufer fertig gesprochen hat: die Voice Activity Detection (VAD).
Die VAD wartet auf Stille. Der Default der OpenAI Realtime API: 500 Millisekunden. Erst wenn 500ms Stille vergangen sind, gilt der Turn als abgeschlossen.
Entscheidend ist, was in dieser Zeit passiert: Das audio-native Modell wartet nicht untätig. Es verarbeitet den Audio-Stream inkrementell— jeder gesprochene Satz wird sofort in interne Repräsentationen überführt. Wenn die VAD den Turn bestätigt, muss das Modell nicht mehr "verstehen" — es muss nur noch antworten.
Die 500ms VAD-Stille empfindet der Anrufer als natürliche Gesprächspause. Die gefühlte Antwortzeit ist das, was danach kommt: die Decoding-Latenz. In Sontor messen wir genau diese Zeitspanne — vom speech_stopped-Event bis zum ersten Audio-Chunk — und sehen typisch 250–800ms.
Der VAD-Trade-off
Warum nicht einfach die VAD auf 200ms stellen? Weil dann der Bot den Anrufer mitten im Satz unterbricht. Jede Atempause, jedes "ähm" wird als Ende des Turns interpretiert.
Es gibt keinen perfekten Wert. Es gibt nur den Wert, der für Ihr spezifisches Szenario die wenigsten Fehler produziert. In Sontor nutzen wir den OpenAI-Default von 500ms — und messen die resultierende Latenz in jedem einzelnen Gespräch.
Drei Fehler, die ich in der Praxis sehe
Fehler 1: TTFB statt TTFA messen
Das Problem: Time-to-First-Byte (TTFB) misst, wann der erste Datenpunkt beim Client ankommt. Das ist oft ein WAV-Header oder Container-Metadaten — kein hörbares Audio (Gradium.ai, 2025). TTFB kann 50ms betragen, während der Anrufer noch 200ms auf den ersten hörbaren Ton wartet.
Richtig: Time-to-First-Audio (TTFA) messen — den Moment, in dem der Anrufer tatsächlich etwas hört. In Sontor messen wir die Zeitspanne zwischen dem speech_stopped-Event und dem ersten Audio-Chunk, das an den Anrufer gestreamt wird.
Fehler 2: Latenz nur in der Demo messen
Das Problem: Die ersten drei Gespräche in der Demo sind schnell. Nach 15 Minuten wird das Modell langsamer — dokumentiert als "progressive Latenz" im OpenAI Developer Forum. Ursache: Context-Accumulation im Modell.
Richtig: Latenz in jedem einzelnen Turn loggen und über die Lebensdauer der Session tracken. In Sontor wird der Latenz-Wert pro Turn im Transkript gespeichert — nicht nachträglich getestet, sondern produktiv in Echtzeit.
Fehler 3: Am Modell sparen, um am Preis zu gewinnen
Das Problem: Ein günstigeres, langsameres Modell spart Kosten pro Minute — und verliert Anrufer in Sekunde zwei. Die Abbruchrate liegt bei 40%.
Richtig: Kosten pro erfolgreichem Gespräch rechnen, nicht pro Minute. Ein Gespräch, das nach 5 Sekunden abgebrochen wird, ist nicht billig — es ist verschwendet.
Die Latenz-Checkliste
Fünf Fragen, die Sie Ihrem Voicebot-Anbieter stellen sollten:
Wenn die Antwort "TTFB" ist oder das Gegenüber die Unterscheidung nicht kennt: kritisch hinterfragen.
Wenn nicht, addieren Sie 500ms zu jeder genannten Zahl.
Wenn darauf keine datenbasierte Antwort kommt: Der Anbieter hat es nicht gemessen.
Nicht für jeden Turn in der Demo — für jeden Turn in jedem Gespräch mit echten Anrufern.
Wenn der Anbieter die Frage nicht versteht, verarbeitet sein System Audio nicht in Echtzeit.
Fazit
Die meisten Voicebot-Vergleiche scheitern an einer einfachen Frage: Wie schnell antwortet das System?
Die Antwort erfordert Präzision: Time-to-First-Audio, inklusive VAD-Wartezeit, gemessen in Produktion, nicht in der Demo. Der Unterschied zwischen einer halben Sekunde und zwei Sekunden Antwortzeit ist nicht inkrementell — er ist existenziell. Er entscheidet darüber, ob der Anrufer dranbleibt oder auflegt.
500 Millisekunden. Das ist die Zielgröße, die mit audio-nativer Verarbeitung erstmals erreichbar wird — und die mit einer klassischen Pipeline aus STT, LLM und TTS physikalisch unmöglich ist.
Lassen Sie sich direkt mit den Gründern verbinden.
Kostenlos. Ohne Registrierung. Ihr Gespräch wird nicht aufgezeichnet.