Latenz entscheidet: Warum Voice-KI ohne Sub-Sekunden-Antworten scheitert

Anrufer entscheiden innerhalb weniger Sekunden, ob sie mit einem Menschen, einem akzeptablen Assistenten oder einer Bandansage sprechen. Diese Einordnung hängt nicht an der Stimme, sondern an der Zeit, die zwischen Satzende und Antwort vergeht. Wer hier oberhalb der Wahrnehmungsschwelle liegt, wirkt sofort mechanisch, auch wenn die Sprachsynthese erstklassig ist. Voice-KI, die produktiv Termine bucht, Leads qualifiziert oder Servicefälle aufnimmt, muss diese Schwelle unterbieten. Und das ist eine Architekturfrage, keine Modellfrage.

Das Problem im Detail

Die Sprachforschung hat das natürliche Turn-Taking sehr präzise vermessen. Die bekannteste Arbeit stammt von Stivers und Kollegen, veröffentlicht 2009 in den Proceedings of the National Academy of Sciences. Über zehn Sprachen hinweg, von Japanisch bis Dänisch, liegt die modale Pause zwischen Sprecherwechseln bei rund 200 Millisekunden. Deutsche und englische Muttersprachler reagieren im Schnitt zwischen 0 und 300 Millisekunden, teilweise mit leichter Überlappung. Das ist der Rhythmus, den unser Gehirn als Gespräch erkennt.

Alles, was darüber liegt, fühlt sich zunehmend unangenehm an. Bereits 500 bis 600 Millisekunden Pause signalisieren Zögern, Unverständnis oder Ablehnung. Jenseits von 800 Millisekunden empfinden Anrufer die Gegenseite als nicht präsent. Für produktive Voice-Assistenten bedeutet das eine harte Obergrenze: Die Zeit zwischen dem letzten Phonem der Nutzeräußerung und dem ersten hörbaren Laut der Antwort darf 800 Millisekunden nicht überschreiten. Realistisches Ziel für ein Gespräch, das nicht auffällt, liegt bei 500 bis 700 Millisekunden.

Das Latenz-Budget einer Voice-Pipeline

Eine klassische Voice-Pipeline besteht aus vier Verarbeitungsschritten: End-of-Speech-Erkennung, Spracherkennung (ASR beziehungsweise STT), Sprachmodell-Inferenz und Sprachsynthese (TTS). Jeder Schritt kostet Zeit, und diese Zeiten addieren sich, wenn die Architektur seriell arbeitet.

Realistische Werte für einen Cloud-First-Stack sehen aus wie folgt. Die Endpointing-Erkennung, also die Entscheidung „der Nutzer ist fertig mit Sprechen", dauert typischerweise 200 bis 500 Millisekunden. Eine Cloud-STT mit Batch-Modus, etwa Whisper ohne Streaming, braucht für einen mittellangen Satz weitere 300 bis 800 Millisekunden. Das Sprachmodell selbst, sofern man einen größeren General-Purpose-LLM in der Cloud anspricht, liefert seinen ersten Token meist nach 400 bis 900 Millisekunden, der vollständige Satz folgt oft erst nach 1,5 Sekunden oder mehr. Eine Cloud-TTS wie ein hochqualitativer neuronaler Stimm-Service benötigt zusätzliche 200 bis 400 Millisekunden bis zum ersten hörbaren Audiochunk. Dazu kommen Netzwerk-Roundtrips zwischen Telefonanbindung, STT-Provider, LLM-Provider und TTS-Provider.

Addiert man diese Werte naiv, landet man zwischen 1,5 und 3,5 Sekunden. Das ist genau der Wert, bei dem Anrufer zum ersten Mal prüfen, ob die Leitung noch steht. Wer eine Voice-KI auf dieser Architektur baut, verliert das Gespräch vor dem ersten echten Inhalt.

Warum serielle Pipelines scheitern

Der Fehler liegt nicht in den einzelnen Komponenten, sondern in der Reihenschaltung. Viele Standardimplementierungen warten, bis der Nutzer zu Ende gesprochen hat, dann bis die vollständige Transkription vorliegt, dann bis das Sprachmodell seine Antwort vollständig generiert hat, und schicken diese Antwort erst dann an die Sprachsynthese. Dieses Muster maximiert jede einzelne Wartezeit.

Der zweite Fehler ist Geografie. Ein Gespräch, das über einen deutschen SIP-Trunk läuft, dann Audio zu einem US-STT-Endpoint schickt, von dort Text zu einem US-LLM, von dort zu einem TTS-Provider und zurück, sammelt schnell 150 bis 300 Millisekunden reine Netzwerklatenz. Diese Zeit ist verloren, bevor auch nur ein Modell etwas gerechnet hat. Und sie ist in gängigen Managed-Service-Stacks kaum sichtbar, weil die Anbieter ihre Latenz nur für die eigene Komponente ausweisen.

Streaming-Inference als Grundbedingung

Die erste Antwort auf das Latenzproblem heißt Streaming. Moderne STT-Engines wie Deepgram Nova, Azure Speech Streaming oder AssemblyAI Universal-Streaming liefern Interim-Transkripte während der Nutzer noch spricht, typischerweise mit 150 bis 300 Millisekunden Verzögerung zum gesprochenen Wort. Das bedeutet: In dem Moment, in dem die Endpointing-Logik „Ende der Äußerung" erkennt, liegt die Transkription bereits vor. Die STT-Zeit verschwindet aus dem kritischen Pfad.

Dasselbe Prinzip gilt für das Sprachmodell. Statt zu warten, bis der komplette Antworttext generiert ist, nutzen wir Token-Streaming und geben jeden Token sofort an die TTS weiter. Damit verschiebt sich die relevante Metrik von der Gesamt-Inferenzzeit auf die Time-to-First-Token. Kompakte Modelle wie Llama 3.1 8B auf einer GPU-Instanz, GPT-4o-mini oder Mistral Small liefern den ersten Token oft in 200 bis 400 Millisekunden. Die verbleibende Generation läuft parallel zur Sprachausgabe.

Die TTS selbst muss auf das Token-Streaming ausgelegt sein. Anbieter wie ElevenLabs mit ihrem Flash-Modell, Cartesia Sonic oder lokale Modelle auf Basis von Kokoro und XTTS erzeugen Audio in Chunks von 20 bis 80 Millisekunden und beginnen zu sprechen, sobald das erste Token eintrifft. Damit reduziert sich die effektive First-Audio-Latenz auf 80 bis 200 Millisekunden.

Partial-Response und Back-Channels

Selbst mit vollständigem Streaming bleiben Szenarien, in denen das Modell für die eigentliche Antwort Recherche oder Tool-Calls benötigt. Eine Datenbankabfrage, ein CRM-Lookup, eine Terminprüfung. Diese Operationen dauern leicht 500 bis 1.500 Millisekunden. Wer in dieser Zeit schweigt, reißt den Gesprächsrhythmus ab.

Die Lösung sind Partial-Responses und Back-Channels. Der Assistent reagiert zunächst mit einer inhaltlich leichten, aber konversationell passenden Überbrückung („einen Moment, ich sehe das kurz nach", „ja, klar, lassen Sie mich das prüfen"). Diese Phrasen werden innerhalb von 200 bis 400 Millisekunden nach Ende der Nutzeräußerung ausgelöst, noch bevor die eigentliche Antwort fertig ist. Parallel läuft im Hintergrund die Tool-Call-Kette, und die inhaltliche Antwort schließt nahtlos an. Aus UX-Sicht entsteht ein einziges flüssiges Gespräch.

Barge-In: Der Anrufer unterbricht

Natürliche Gespräche enthalten Unterbrechungen. Der Anrufer ergänzt eine Information, korrigiert sich, stellt eine Rückfrage, während die KI noch spricht. Ein Assistent, der in dieser Situation stur weiterredet, wirkt unhöflich und oft inkompetent. Korrektes Barge-In-Handling erfordert drei Dinge: kontinuierliche Stimmaktivitätserkennung während der eigenen Ausgabe, sofortiges Stoppen der TTS-Synthese bei erkannter Nutzerstimme, und ein Dialog-State, der weiß, was bereits ausgesprochen wurde und was nicht.

Technisch bedeutet das: Die TTS-Ausgabe läuft nicht als monolithischer Audio-Stream, sondern als Queue kleiner Chunks, die jederzeit verworfen werden können. Die Voice Activity Detection arbeitet parallel zur Ausgabe und hat eine eigene Latenz-Budget-Zeile von unter 100 Millisekunden. Sobald der Anrufer spricht, wird die laufende Ausgabe unterbrochen, der Dialog-Manager erhält die Information „bis hierhin gesagt, ab hier abgebrochen", und der LLM-Kontext wird entsprechend aktualisiert. Ohne dieses Verhalten fühlt sich auch ein technisch schneller Assistent starr an.

Edge-Deployment statt Cloud-Kette

Wer die 600-Millisekunden-Grenze dauerhaft unterbietet, kommt an einer Verlagerung von Komponenten auf Edge- oder Co-Location-Infrastruktur nicht vorbei. Konkret bedeutet das: STT, Dialog-Manager und TTS laufen im selben Rechenzentrum wie der SIP-Trunk, idealerweise in Frankfurt oder einem vergleichbaren deutschen Standort. Das spart die transatlantischen Roundtrips. Das Sprachmodell kann entweder als kompaktes lokales Modell mitlaufen oder über einen privaten Tunnel mit niedriger Latenz an einen europäischen Anbieter angebunden werden.

Bei Anwendungen mit hohem Volumen, etwa im Call-Center-Betrieb, rechnet sich zusätzlich ein eigenes Inference-Deployment für das Sprachmodell. Eine einzelne GPU-Instanz mit einem 7- bis 13-Milliarden-Parameter-Modell bedient problemlos ein Dutzend paralleler Gespräche und liefert reproduzierbar niedrige Time-to-First-Token-Werte, unabhängig von der Auslastung öffentlicher Cloud-Endpunkte.

Unser Vorgehen

Wir behandeln Voice-KI als Echtzeit-System, nicht als Aneinanderreihung von APIs. Am Anfang jedes Projekts steht ein Latenz-Budget pro Pipeline-Stufe, das sich aus dem gewünschten Nutzungsszenario ableitet. Für Inbound-Service-Bots mit hohem Volumen arbeiten wir typischerweise mit 500 Millisekunden Ziel, für Outbound-Qualifizierungs-Bots mit 700 Millisekunden, für beratende Assistenten mit komplexen Tool-Calls mit klaren Partial-Response-Regeln.

Unser Standard-Stack kombiniert Streaming-ASR mit niedriger Interim-Latenz, ein kompaktes LLM mit optimierter Time-to-First-Token, eine TTS mit Chunk-basiertem Streaming und ein Dialog-Management mit sauberem Barge-In. Deployed wird in europäischen Rechenzentren mit direkter Anbindung an den Telefonie-Trunk. Monitoring und Telemetrie messen nicht nur Gesamtlatenz, sondern jede einzelne Stufe und jede Unterbrechung, damit Regressionen sofort sichtbar werden. Wer tiefer einsteigen möchte, findet unseren Ansatz auf unserer Leistungsseite Voice-Assistenten für Unternehmen.

Messbare Hebel

• End-to-End-Latenz unter 700 Millisekunden als harte Zielmarke, gemessen vom letzten Phonem des Nutzers bis zum ersten Audio-Chunk der Antwort.
• Time-to-First-Token des Sprachmodells unter 400 Millisekunden, erreicht durch kompakte Modelle und dediziertes Inference-Deployment.
• Streaming-STT mit Interim-Transkripten im 200-Millisekunden-Fenster, wodurch die Transkription aus dem kritischen Pfad verschwindet.
• Barge-In-Reaktion in unter 150 Millisekunden nach Spracherkennung des Anrufers, inklusive sauberem Abbruch der laufenden TTS-Ausgabe.
• Partial-Response-Strategien für alle Tool-Calls über 500 Millisekunden, um Stille im Gespräch systematisch zu vermeiden.

Fazit

Voice-KI steht und fällt mit Millisekunden. Die akustische Qualität der Stimme ist heute ein gelöstes Problem, und Sprachmodelle mit ausreichender Kompetenz für strukturierte Gespräche sind breit verfügbar. Der entscheidende Unterschied zwischen einem Assistenten, der akzeptiert wird, und einem, der abgewürgt wird, liegt im Latenz-Budget und in einer Architektur, die dieses Budget einhält. Wer Voice-KI produktiv einsetzen will, sollte die 600- bis 800-Millisekunden-Grenze zum Designziel machen und jede Komponente danach auswählen.