- Vorstellung eines selbst gebauten sprachbasierten KI-Systems mit auf etwa 400 ms reduzierter Latenz
- STT, LLM und TTS in einer Echtzeit-Pipeline verbunden und damit eine doppelt so schnelle Reaktionszeit wie bei bestehenden kommerziellen Plattformen (z. B. Vapi) erreicht
- Deepgram Flux übernimmt Sprecherkennung und Turn-Wechsel, während das Modell Groq llama-3.3-70b die Zeit bis zum ersten Token deutlich verkürzt
- Durch geografische Platzierung und Netzwerkoptimierung wurde die Latenz bei einem EU-Deployment auf weniger als die Hälfte gesenkt
- Der Kern von Sprachagenten ist Echtzeit-Orchestrierung und Pipeline-Design; bei einer Eigenimplementierung lassen sich Performance-Engpässe klar erkennen
Hintergrund zum Aufbau des Sprachagenten
- Basierend auf Erfahrungen mit der Entwicklung eines Sprachagent-Prototyps für einen Konsumgüterkonzern wurde ein Eigenbau versucht, um die Komplexität kommerzieller Plattformen direkt zu beherrschen
- Plattformen wie ElevenLabs und Vapi sind zwar komfortabel, aber ihre internen Abläufe sind schwer zu verstehen und eine feingranulare Kontrolle der Latenz ist nicht möglich
- Das Ziel war, Leistung auf Vapi-Niveau selbst umzusetzen — mit einem Tag Zeit und rund 100 US-Dollar an API-Credits
Die Komplexität von Sprachagenten
- Anders als textbasierte Chatbots benötigt Sprache Turn-Taking in Echtzeit
- Sobald der Nutzer spricht, muss das System die eigene Ausgabe sofort unterbrechen; wenn der Nutzer stoppt, muss die Antwort schnell starten
- Eine einfache Sprachaktivitätserkennung (VAD) reicht nicht aus, um das Ende einer Äußerung präzise zu bestimmen; es entstehen Latenz, überlappende Äußerungen und unnötige Stille
Erste Implementierung: Test auf VAD-Basis
- Empfang eines μ-law-Audiostreams über einen FastAPI-Server und Twilio WebSocket
- Mit Silero VAD wurde das Vorhandensein von Sprache erkannt, und nach Ende der Äußerung eine vorab aufgezeichnete WAV-Datei abgespielt
- Obwohl einfach, bestätigte dieser Ansatz sofortige Reaktionsfähigkeit und einen natürlichen Gesprächsfluss
- In dieser Phase wurde eine Referenz für die untere Grenze der Latenz gewonnen
Zweite Implementierung: Deepgram Flux und Echtzeit-Pipeline
- Deepgram Flux wurde eingeführt, um Streaming-Transkription und Turn-Erkennung zu integrieren
- Wenn Flux das Ende einer Äußerung erkennt, läuft die Verarbeitung in dieser Reihenfolge ab
- Transkriptionsergebnis und Gesprächsverlauf an das LLM senden
- Sobald das erste Token erzeugt wird, an TTS (WebSocket) streamen
- Das erzeugte Audio in Echtzeit an Twilio übertragen
- Durch ein vorgewärmtes TTS-Verbindungs-Pool wurden etwa 300 ms Latenz eingespart
- Sobald der Nutzer zu sprechen beginnt, werden LLM, TTS und Audioübertragung sofort abgebrochen, um natürliche Unterbrechungen zu ermöglichen
Latenzmessung und regionale Bereitstellung
- Bei lokaler Ausführung in der Türkei trat im Schnitt eine Latenz von 1,6 bis 1,7 Sekunden auf
- Nach dem Deployment in die Railway-EU-Region und der Abstimmung von Twilio, Deepgram und ElevenLabs auf EU-Regionen
- sank die durchschnittliche Latenz auf 690 ms (gesamt 790 ms), also etwa 50 ms schneller als Vapi
- Die geringere Latenz verbesserte die Gesprächsreaktion deutlich, auch Unterbrechungen während des Sprechens liefen flüssiger
Modellauswahl und Leistungssteigerung
- Anfangs wurde gpt-4o-mini verwendet, später erfolgte der Wechsel zu Groq llama-3.3-70b
- Tests zeigten, dass die Time to First Token (TTFT) des Groq-Modells gegenüber OpenAI bis zu dreimal schneller ist
- Es wurde eine durchschnittliche End-to-End-Latenz von unter 400 ms erreicht, wobei das erste Audio innerhalb von 500 ms ankam
- Auf diesem Niveau wirkt es so, als reagiere der Agent schneller als ein Mensch
Wichtige technische Erkenntnisse
- Für die Latenzoptimierung ist die Steuerung des gesamten Pfads vom Ende der Äußerung bis zur ersten Sprachausgabe entscheidend
- Da TTFT mehr als die Hälfte der Gesamtlatenz ausmacht, ist die Wahl eines Low-Latency-Modells wichtig
- STT→LLM→TTS darf nicht sequentiell verarbeitet werden, sondern muss als Streaming-Pipeline aufgebaut sein
- Bei Unterbrechungen müssen alle Komponenten sofort abgebrochen werden, damit das Gespräch natürlich bleibt
- Geografische Nähe zwischen den Diensten hat entscheidenden Einfluss auf die Latenz
Vergleich mit kommerziellen Plattformen
- Vapi und ElevenLabs bieten weiterhin zusätzliche Funktionen wie API, Stabilität und Observability und bleiben daher für die meisten Teams nützlich
- Dennoch hilft ein Eigenbau dabei, echte Engpässe und die Bedeutung einzelner Parameter zu verstehen, und ermöglicht
maßgeschneiderte Orchestrierung für spezifische Anforderungen
- Sprachsysteme sind letztlich ein Orchestrierungsproblem; betrachtet man die Struktur klar, ist es eine lösbare Engineering-Aufgabe
Quellcode
1 Kommentare
Hacker-News-Kommentare
Dieser Beitrag ist wirklich interessant. Früher hat das Amazon-Alexa-Team dieses Problem erforscht, und es gibt dazu auch Patente
In Gesprächen zwischen Menschen beträgt die durchschnittliche Verzögerung 0 ms, das heißt: Noch bevor der andere fertig gesprochen hat, beginnt die nächste Person bereits zu reden. Das liegt daran, dass das Gehirn die Aussage des Gegenübers vorhersagt und gleichzeitig die Antwort vorbereitet
Bei Sprachassistenten erwarten Menschen dagegen eine Verzögerung. Dafür gibt es zwei Gründe — die Annahme, dass der Computer erst „nachdenken“ muss, und die Verzögerung bei Mobiltelefonaten
Unter 500 ms liegt bei Alexa fast keine Antwort. Früher galten einfach 300 ms Stille als „Turn-Ende“, aber der eigentliche Kern ist das semantic end-of-turn
Heute stehen genug Rechenressourcen zur Verfügung, deshalb frage ich mich, wie weit sich dieser Bereich inzwischen entwickelt hat. Die geografisch nahe Verarbeitung (Edge Computing) war ein großer Wendepunkt
Sprache ist letztlich ein Turn-Taking-Problem. Es gibt eine einfache Verbesserung, die kaum jemand angefasst hat — nämlich Fülllaute und Temposteuerung
Wenn das LLM kurz Stille erkennt, könnte es kontextbezogene Fülllaute wie „hm“ oder „genau“ einstreuen, während die eigentliche Antwort generiert wird. Dadurch wirkt das Gespräch viel natürlicher
Hervorragender Beitrag. Der OpenAI Responses client nutzt seit Kurzem WebSockets, wodurch die Latenz gesunken ist.
Ein anderer Ansatz ist, ein sehr kleines LLM direkt lokal auszuführen. Ich habe über das ova-Projekt eine vollständig lokale Pipeline gebaut und selbst ohne Streaming Antwortzeiten von unter einer Sekunde erreicht
Die Streaming-Pipeline-Architektur des Beitrags und die schrittweise Latenzanalyse waren sehr nützlich. Beeindruckend fand ich vor allem, dass die Turn-Taking-Schleife selbst implementiert wurde
Der Vergleich „2x schneller als Vapi“ ist allerdings etwas ungenau. Vapi erledigt viel mehr, etwa Tool-Calls, Webhooks und Multi-Tenant-Routing
Der eigentliche Wert dieses Beitrags liegt in den Einsichten aus der selbst gebauten Orchestrierungsschleife. Als Zusammenfassung im Sinne von „Was ich beim Selberbauen gelernt habe“ wäre es perfekt gewesen
Ich baue ebenfalls einen produktiven Sprachagenten mit Twilio + Deepgram + ElevenLabs + LLM API
Entscheidend war nicht die STT-Genauigkeit, sondern die Turn-Taking-UX. Als wir von festen Stille-Schwellen auf semantic end-of-turn umgestellt haben, war der Unterschied sofort spürbar
Auch die Inter-Region-Latenz ist wichtig. Bei Verbindungen von Indien zu US-Servern kommen allein durch den Twilio-Edge-Hop 150–250 ms dazu. Mit regionsbasiertem Routing wurde es besser
Auch Barge-in ist komplex. Man muss nicht nur LLM und TTS abbrechen, sondern auch bereits ausgelöste automatisierte Workflows rückgängig machen. Wir hatten früher einen Bug, bei dem bei einer Unterbrechung während der Terminbestätigung die Buchung trotzdem tatsächlich abgeschlossen wurde
Soniox Real-time (mit Unterstützung für 60 Sprachen) behandelt Endpoint Detection auf Modellebene. Das ist deutlich präziser als VAD
Siehe technische Dokumentation, Benchmark von Daily und Demoseite
Ich habe früher bei Soniox gearbeitet. Es war der erste Dienst, der Real-Time-Endpoint-Detection umgesetzt hat
Persönlich halte ich die Struktur STT → LLM → TTS für begrenzt. Die Zukunft liegt bei End-to-End-Sprachmodellen
Ich habe vor zwei Jahren die Chirpy-Demo gebaut, aber um auf ein wirklich nutzbares Niveau zu kommen, wäre spezialisiertes Training nötig gewesen. Als Nebenprojekt war das nicht zu stemmen
Unternehmenskunden legen Wert auf Auditierbarkeit und Zuverlässigkeit. In regulierten Branchen wie Gesundheit oder Finanzen müssen STT- und LLM-Ausgaben jeweils separat geprüft werden
End-to-End-Sprachmodelle passen dagegen eher zu narrativen Anwendungsfällen wie Interviews oder Umfragen. Echte Kunden wollen eher technische Reife als einfach nur das neueste Modell
Dieser Ansatz erinnert mich an die frühe Entwicklung von Netcode in Game Engines. Latenz ist kein Modellproblem, sondern ein Orchestrierungsproblem
Auch in Carmacks VR-Paper von 2013 wurde dasselbe argumentiert — nur wenn man die gesamte Pipeline verfolgt, findet man Engpässe im Millisekundenbereich
Latency Mitigation Strategies ist dazu lesenswert. Das Beispiel mit einem vorab geöffneten TTS-WebSocket-Pool, der 300 ms spart, ist perfekt
Ich möchte die Open-Source-Spracherkennungs-App Handy erwähnen. Sie läuft vollständig offline und ist erweiterbar
Ich nutze sie täglich zusammen mit Claude, und sie funktioniert deutlich besser als die Standard-Diktierfunktion von macOS
Guter Beitrag, aber Gespräche nur über Turn-Taking zu erklären ist zu simpel
In realen Gesprächen gibt es überlappende Äußerungen, Bestätigungssignale, phatische Äußerungen zur Aufrechterhaltung des Zuhörens und sogar kooperative Vervollständigungen der Aussage des Gegenübers
Solche Elemente lassen sich mit einem einfachen Turn-Taking-Modell nicht gut abbilden, und das Modell muss sie sowohl erzeugen als auch verstehen können