Wie schnell sollte Ihr AI Voice Agent antworten?

Ein produktiver AI Voice Agent sollte innerhalb von 800ms–1,2 Sekunden nach dem Ende eines Satzes des Anrufers zu sprechen beginnen. Ab 2 Sekunden gehen Anrufer davon aus, dass die Leitung unterbrochen ist – sie wiederholen sich oder legen auf. Wenn Sie Anbieter evaluieren oder das System selbst entwickeln: Latenz ist keine nice-to-have-Metrik, sondern der Unterschied zwischen einem Agent, dem Menschen vertrauen, und einem, den sie umgehen.

Warum Latenz darüber entscheidet, ob Menschen dem Agent vertrauen

Menschliche Gespräche haben einen Rhythmus. Forschungen zum Sprecherwechsel über verschiedene Sprachen hinweg ergaben, dass der durchschnittliche Abstand zwischen dem Ende einer Aussage und dem Beginn der Antwort bei etwa 200 Millisekunden liegt – oft sogar bevor der erste Sprecher fertig ist (Stivers et al., PNAS). Niemand erwartet heute, dass eine KI 200ms erreicht – aber der Maßstab, an dem sie gemessen wird, ist dieser, nicht die 3–5 Sekunden, die ein Kunde vielleicht bei einer langsamen Webseite tolerieren würde.

Auf der Interface-Seite sind die Reaktionszeitschwellen der Nielsen Norman Group die klassische Referenz: Unter 0,1s fühlt sich alles sofortig an, bis 1s bleibt der Gedankenfluss des Nutzers ungestört, und ab 10s ist er gedanklich bereits abgehängt. Sprache komprimiert diese Skala zusätzlich – es gibt keinen Spinner, keinen Fortschrittsbalken, nur Stille. Eine 2-Sekunden-Pause in einem Anruf fühlt sich deshalb wesentlich länger an als dieselbe Pause auf einer Webseite.

Das ist besonders relevant für transaktionale Anwendungen: Buchungsänderungen, Bestellstatus, Support-Triage, Outbound-Sales. Wenn Sie das mit einem textbasierten Kanal vergleichen: Die Latenzanforderungen für einen AI WhatsApp Sales Agent sind deutlich weniger streng – ein paar Sekunden wirken dort wie normale Tippzeit. Bei Sprache gibt es diesen Puffer nicht.

Wo die Millisekunden tatsächlich verloren gehen

Eine typische Voice-Agent-Pipeline hat drei Stufen, und die meisten Implementierungen führen sie sequenziell aus:

1. Speech-to-Text (STT), das Transkribieren des Anrufer-Audios. 150–500ms, je nachdem ob Streaming oder Batch.
2. LLM-Generierung, also die Entscheidung, was gesagt werden soll, und die Erzeugung der vollständigen Antwort. 500ms–2s+, abhängig von Modellgröße, Prompt-Länge und davon, ob vor der Antwort noch Tools aufgerufen werden (Bestellung nachschlagen, Kalender prüfen).
3. Text-to-Speech (TTS), die Umwandlung der vollständigen Textantwort in Audio. 200ms–1s.

Sequenziell addiert ergibt das problemlos 1,5–3,5 Sekunden, bevor der Anrufer irgendetwas hört – noch ohne Netzwerk-Roundtrips. Das ist die Lücke, die einen Agent kaputt wirken lässt.

Die Lösung ist kein schnelleres Modell, sondern nicht auf die vollständige Antwort zu warten, bevor man zu sprechen beginnt. Den LLM-Output Token für Token in TTS zu streamen und zu sprechen, sobald der erste Satz fertig ist – statt auf die komplette Antwort zu warten – ist es, was die wahrgenommene Verzögerung tatsächlich zusammenfallen lässt. Das ist eine Pipeline-Entscheidung, kein Modell-Upgrade, und in der Regel der wirkungsvollste verfügbare Hebel.

Tool-Calls machen das schwieriger. Wenn der Agent vor der Antwort eine Datenbank abfragen muss („ich sehe kurz nach Ihrer Bestellung"), muss diese Abfrage innerhalb der Pause stattfinden – und sie braucht eine eigene Überbrückungsstrategie: eine natürliche Bestätigung („einen Moment, ich rufe das gerade ab") statt toter Stille. Das ist einer der Gründe, warum agentische Voice-Systeme sorgfältigere Orchestrierung erfordern als ein einfacher Skript-IVR-Ersatz – der Agent erledigt mitten im Gespräch echte Arbeit, rezitiert nicht nur Text.

Wie Sie einen Anbieter auf Latenz prüfen

Nehmen Sie kein Demo-Video für bare Münze. Fordern Sie:

• Einen Live-Anruf ohne Skript in Ihrem eigenen Netzwerk, keine vorproduzierte Demo auf leerlaufender Infrastruktur.
• Time-to-First-Audio-Byte, gemessen – nicht „Response Time", den Anbieter manchmal als Time-to-First-Token des LLM angeben und dabei TTS ignorieren.
• Latenz unter paralleler Last. Ein einzelner Testanruf sagt nichts darüber aus, was bei 50 gleichzeitigen Anrufen passiert, wenn GPU-Queuing und Rate Limits greifen.
• Verhalten bei Tool-Calls. Bitten Sie sie, mitten im Anruf eine echte Abfrage auszulösen (CRM, Kalender, Bestellsystem), und messen Sie die Pause.
• Regionales Routing. Wenn Ihre Anrufer in der Golfregion oder anderswo außerhalb der Standard-Region des Anbieters sind: fragen Sie, wo Inference tatsächlich läuft. Ein Modell, das drei Kontinente entfernt gehostet wird, addiert physikalisch bedingte Roundtrip-Zeit, die kein Engineering-Aufwand der Welt wegoptimieren kann.

Dieser letzte Punkt verstärkt sich, wenn Sie es zusätzlich mit akzentbehafteter Sprache oder einer anderen Sprache als Englisch zu tun haben. Arabic ASR hat insbesondere echte Tradeoffs zwischen Genauigkeit und Latenz – hochgenaue Modelle für Golfregion-Dialekte sind oft langsamer und teurer als generisches englisches STT.

Wenn Sie das vertraglich absichern wollen, behandeln Sie Latenz genauso wie eine Genauigkeitskennzahl: definieren Sie sie, und halten Sie den Anbieter daran fest. Die gleiche Disziplin, die für Evals in AI-Anbieterverträgen gilt, greift hier direkt: Ohne ein messbares SLA bedeutet „schnell" das, was der Anbieter am Demo-Tag gerade für ausreichend hielt.

Warnsignale

• Der Anbieter kann Ihnen die p50/p95 Time-to-First-Audio-Byte nicht aus dem Stegreif nennen.
• Die Demo funktioniert nur bei Skript-Fragen einwandfrei – stellen Sie etwas Unvorhergesehenes, und beobachten Sie, wie die Pause größer wird.
• „Schnell genug" ist die einzige Antwort, die Sie erhalten, wenn Sie nach einer konkreten Zahl fragen.
• Kein Wort über Streaming in der Architektur – wer auf eine vollständige LLM-Antwort wartet, bevor TTS startet, steckt im langsamen Pfad fest, egal welches Modell ausgetauscht wird.

Fazit

Latenz ist eine Architekturentscheidung, keine Modell-Auswahl-Entscheidung. Eine gut konstruierte Pipeline mit einem Mid-Tier-Modell schlägt eine schlecht gestreamte Pipeline mit dem besten verfügbaren Modell konsistent. Bevor Sie einen Anbieter unter Vertrag nehmen oder einen eigenen Build freigeben: Holen Sie eine echte Zahl, kein Bauchgefühl – und wenn Sie KI in ein bestehendes Produkt integrieren, planen Sie Engineering-Zeit für das Streaming-Fundament von Anfang an ein. Das nachträglich einzubauen ist ein Rewrite, kein Patch.

Wenn Sie einen Voice Agent konzipieren und eine zweite Meinung dazu möchten, ob die Latenz-Versprechen eines Anbieters belastbar sind, sprechen Sie mit uns.