Show HN: Ein Sprach-Bot mit 500 ms Antwortzeit

• Sprach-KI muss wie ein normales Gespräch sofort reagieren, um natürlich zu wirken; diese Demo zielt daher auf 500 ms Sprach-zu-Sprach-Antwortzeit ab
• Die zentrale Herausforderung ist die Verringerung der vom Nutzer wahrgenommenen Latenz, wobei sowohl Netzwerk- als auch Modellverarbeitungszeit eine Rolle spielen
• Die Demo zeigt anhand von Optimierungs- und Deployment-Methoden, wie weit LLM-Interaktionen mit niedriger Latenz möglich sind
• Für die Umsetzung wurde das Open-Source-Framework Pipecat für Sprach- und multimodale dialogorientierte KI verwendet
• Um einen interaktiven Sprach-Bot auf echtem Produktniveau zu bauen, ist nicht nur die Modellleistung wichtig, sondern auch das Latenzmanagement entlang des gesamten Aufrufpfads

---

Demo mit Zielwert von 500 ms Sprachantwort

• The World's Fastest Voice Bot Demo ist eine Demo, die zeigt, wie schnell ein sprachbasierter KI-Chatbot reagieren kann
• Das Ziel ist das Erreichen einer Sprach-zu-Sprach-Antwortzeit von 500 ms
• Menschen erwarten in normalen Gesprächen schnelle Antworten, daher ist Geschwindigkeit bei Sprach-KI-Schnittstellen ein zentraler Qualitätsfaktor

Implementierungsansatz zur Verringerung der Latenz

• Die Demo ist auf LLM-Interaktionen mit niedriger Latenz ausgerichtet
• Sie zeigt das Potenzial eines Sprach-KI-Chatbots, der so optimiert und bereitgestellt wurde, dass Netzwerk- und Modelllatenz minimiert werden
• Der Bot wurde mit Pipecat erstellt
  • Pipecat ist ein Open-Source-Framework für Sprach- und multimodale dialogorientierte KI

[GN⁺]

Hacker-News-Kommentare

• Wirklich schnell. Großartig und sauber. Es fühlt sich an, als würde Geschwindigkeit alles andere schlagen. Erst nachdem ich die Kommentare gelesen hatte, habe ich die roboterhafte Stimme überhaupt bemerkt
  Ich habe einmal eine KI für den Kundensupport gebaut, und die durchschnittliche Antwortzeit wurde von 24–48 Stunden auf ein paar Sekunden reduziert
  An einen Kunden wurde einmal eine Nachricht wie „Hello Bitch, your package will be picked up by USPS today...“ geschickt, und der Kunde antwortete mit „thank you so much“ und vergab die volle CSAT-Punktzahl. Selbst bei so einem gravierenden Fehler schlägt Geschwindigkeit offenbar alles

  • Ich glaube nicht, dass alle so reagieren würden. Für manche Menschen könnte es zur alltäglichen Ausdrucksweise gehören, sich gegenseitig bitch zu nennen, und deshalb könnte es in den Trainingsdaten gelandet sein, für andere aber überhaupt nicht
  • Lustig ist, dass wir dieses Problem behoben haben, indem wir das #profanity-Tag hinzugefügt und die Nachricht an den nächsten Support-Mitarbeiter weitergeleitet haben
    Allerdings konnte unser aktivster Sales Engineer danach keine Demos mehr für potenzielle Kunden machen. Es gab viele peinliche Anrufe, in denen die KI einfach nicht antwortete, weil sein Nachname Dick war
  • Eine Lösung könnte sein, die Nachricht noch durch ein weiteres LLM zu schicken, um Schimpfwörter zu entfernen und sie so höflich wie möglich zu machen. Das würde allerdings vermutlich mehr als doppelt so viel in der Ausführung kosten
  • Vielleicht war das ja der Name des Kunden. Zumindest könnte es der Name gewesen sein, den der Kunde so eingegeben hat

• Wirklich, wirklich gut. Wenn ich das richtig verstanden habe, wirkt es wie eine Teaser-App, um Cerebrium zu zeigen, hat aber das Potenzial für eine Killer-App. Als ich es auf dem iPad getestet habe, lag die gemeldete Latenz zwischen 1400 ms und 400 ms, und im unteren Bereich fühlte es sich sehr flüssig an
  Bei dieser Geschwindigkeit könnten in manchen Chat-Workflows mehrstufige Ansätze notwendig oder möglich werden. Man antwortet zuerst schnell und lässt parallel längere Daten-/Informations-/RAG-Abfragen laufen, danach übernimmt ein inhaltlich fundierteres Ergebnis
  Menschen funktionieren auch so. Sie beginnen zu antworten und verwenden dabei verschiedene Füllwörter, um ihre Gedanken zu ordnen
  Im Moment wirft man meist alles auf einmal in einen Prompt oder arbeitet im Hintergrund mit Parsen → Abfrage → Generierung, aber wenn Antworten mit niedriger Latenz möglich werden, dürfte ein besserer Ablauf eher ungefähr so aussehen: „[3 Sekunden Llama 8B ins Ohr] → Abfrage → [55 Sekunden Llama 70B/GPT-4 usw. mit den Abfrageergebnissen]“

  • Hier ist jemand von Cerebrium. Vielen Dank für das Feedback, und es freut uns, dass es eine gute Erfahrung war
    Diese Anwendung lässt sich leicht erweitern oder implementieren, sodass sie sich nach Wunsch anpassen lässt. Man kann sie auf andere LLMs, Speech-to-Text- oder Text-to-Speech-Modelle umstellen, den Prompt ändern oder auch Dinge wie RAG implementieren
    Zusammen mit Daily haben wir uns auf Engineers konzentriert. Wir wollten die Anwendung sehr flexibel anpassbar an Use Cases und Vorlieben machen und gleichzeitig den langweiligen Teil der Infrastruktur-Einrichtung abnehmen
    Mehr dazu, wie man sie erweitern kann, gibt es hier: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
  • Das habe ich mich auch gefragt. Könnte es ein kleines, effizientes LLM geben, das die allgemeine Aufgabenkomplexität abschätzen kann, ohne die tatsächliche vollständige Arbeitslast auszuführen?
    Wenn sich die Komplexität als kontinuierlicher Wert bewerten ließe, könnte man wissen, ob man statt auf einen langen Roundtrip zu warten zuerst etwas wie „Ja, einen Moment bitte. Ich schaue nach.“ senden sollte

• Für Browser auf mehreren Plattformen gibt es als Modul zur Spracherkennungsaktivität https://github.com/ricky0123/vad. Es ist eine ONNX-Portierung von Sileros VAD-Netzwerk. Plattformübergreifend heißt hier auch, dass es in Firefox funktioniert. Es braucht nur Mikrofonzugriff und keine WebRTC-Session, also ist es einfacher. Ich frage mich auch, ob Browser so etwas als native Option anbieten sollten
  Es gibt auch browserbasierte Text-to-Speech-Engines, die immer schneller werden und deren Qualität steigt. Es wäre schön, wenn Browser standardmäßig ein hervorragendes TTS mitbringen würden
  GPT-4o hat für niedrige Latenz automatische Spracherkennung, Verständnis und Sprachantwort-Generierung in ein einziges Modell gepackt, was nach einer ziemlich guten Idee aussieht. Dass es noch nicht veröffentlicht wurde, deutet darauf hin, dass es in irgendeiner Form Skalierungs- oder Qualitätsprobleme gibt
  Ähnlich dürfte es auch Leute geben, die ein offenes integriertes multimodales Large Language Model mit Audio-Ein-/Ausgabe und sogar visuellem Input bauen
  Ich frage mich, wie notwendig und optimal ein einzelnes gekoppeltes Modell unter dem Gesichtspunkt von Latenz- und Kostenoptimierung wirklich ist
  Die gezeigte Aufschlüsselung ist interessant. Wenn möglich, wäre es wohl besser, mehr Modelle auf dem Gerät selbst laufen zu lassen, etwa für die Sprachgenerierung und vielleicht auch für den anfänglichen Teil der Spracherkennung oder des Sprachverständnisses. Wer will schon auf STUN warten?

  • Ich finde, Desktop-Umgebungen sollten Speech-to-Text als Dienst mit einer Standardschnittstelle anbieten. Etwa wie stdin, aber getrennt für Sprache
    Apps würden das standardmäßig ignorieren, weil sie nicht einfach dauerhaft zuhören, aber die Transkriptionslösung wäre austauschbar und in allen Apps nutzbar
  • Nach diesen Zahlen würde lokale Spracherkennung und Sprachsynthese nur 120 ms einsparen, wenn der Rest gleich bleibt. Die übrigen 639 ms entfallen auf Hardware- und Netzwerklatenz sowie auf das Bewegen der Daten in das und aus dem LLM. Das ist trotzdem langsamer als gewünscht
    Logisch betrachtet muss man in Phonemen denken. Der LLM-Output muss das letzte Phonem schnell genug einholen, um in dem Moment, in dem das Satzende erkannt wird, „sofort“ antworten zu können, und dafür braucht die gesamte Kette ungefähr 200 ms End-to-End-Latenz
    Um da hinzukommen, bräuchte es wahrscheinlich eine andere Architektur. Ähnlich wie bei der menschlichen Sprachverarbeitung würde man den Audiostream auf Basis vorhergesagter Phoneme vorauseilen lassen, noch bevor sie eintreffen, und das tatsächlich eingehende Audio nur als leichtgewichtiges Bestätigungssignal dafür verwenden, ob der aktuelle Ausgabepuffer geleert oder neu verarbeitet werden soll
    Mit spekulativem Decoding kommt man vielleicht ein Stück weit, aber mit einer gemischten Audio-/Text-Pipeline dürfte das schwierig sein. Es ist von vornherein viel besser, Audio nicht erst in Text umzuwandeln und dann wieder zurück in Audio
  • Diese Präsentation hat das, woran ich gebaut habe, zwar komplett in den Schatten gestellt, aber es gibt eine einfache Assistant-Implementierung mit rick0123/VAD und WebSocket
    https://github.com/charlesyu108/voiceai-js-starter

• Ich habe es selbst ausprobiert und fand es unterhaltsam. Anfang dieser Woche habe ich june-va getestet, aber die langen Antwortzeiten haben den praktischen Nutzen ziemlich beeinträchtigt. Schnelle Antworten sind ein großartiges Feature, und das hier fühlt sich viel mehr wie ein Gespräch an.
  Lustig war, dass ich um eine Geschichte bat und dann nur jeweils einen Satz auf einmal bekam, sodass ich „yes“, „aha“ oder „please continue“ sagen musste, um die nächste Zeile zu hören.
  Daraus ergab sich dann dieser Dialog: „Ah, ich glaube, ich habe dein Geheimnis herausgefunden!“ „Bitte sagen Sie es“ „Du hältst den Kontext kurz, um kurze Antwortzeiten zu erreichen“ „Genau richtig“

  • Ehrlich gesagt ist dieser Ansatz okay. Nicht nur kurzer Kontext, sondern auch kurze Antworten sind eindeutig gut. Im Gegensatz zum aktuellen ChatGPT-Sprachmodus, der bei einer Frage gefühlt einen einminütigen GPT-Monolog abliefert

• Sehr beeindruckend. Extrem schnell, vielleicht sogar zu schnell, aber genau das scheint der Punkt zu sein. Am beeindruckendsten ist, wie VAD und Interrupt-Handling aufeinander abgestimmt sind. Von allen Gesprächen, die ich bisher mit Agenten geführt habe, klang dieses mit Abstand am natürlichsten. Wenn es öffentlich verfügbar ist, möchte ich es unbedingt ausprobieren

• Im Marketing steht 500, aber meine Rechnung kommt auf 759

  • Deshalb nennt man es Marketing
  • In meinem Test gab es einen Ausreißer mit 1400 ms, und ungefähr zehn Mal lag es zwischen 400 und 500 ms. Die Marketingzahl wirkte fair
  • Die 500 beziehen sich auf die Phasen Transkription/LLM/TTS, also auf die Zeit vom Eintreffen der Daten auf dem Server bis zum Zurücksenden der Antwort. Der Rest scheint aus verschiedenen nicht-AI-Zusatzlatenzen zu bestehen, etwa Encoding und Netzwerkverkehr
  • Die Latenzen in der Tabelle basieren auf beobachteten Heuristiken oder Durchschnittswerten. In der Praxis können einige der größeren Latenzkomponenten je nach Gespräch deutlich niedriger ausfallen

• Ich freue mich auch auf Voice Inference. Vor dem Release von OpenAIs GPT-4o habe ich selbst eine WebSocket-basierte Faster-Whisper-Implementierung gebaut. Mein Interview-Coach-Konzept https://intervu.trueforma.ai und mein Sales-Pitch-Coach https://sales.trueforma.ai wurden dann von ihnen verdrängt.
  Ich habe VAD nicht stabil zum Laufen bekommen und deshalb standardmäßig Push-to-Talk verwendet. Alles läuft auf einem LattePanda. Ich wollte Groqs gehostetes Whisper integrieren.
  Ich mag die Idee, für das LLM Groqs unzensiertes Llama3 zu verwenden, weil ich diese langweiligen Corporate-Gespräche leid bin. Ich würde gern die Latenz senken und aus den Beispielen lernen. Ich würde auch gern die Demo ausprobieren, aber offenbar ist sie so überlaufen, dass ich gar nicht in ein Gespräch mit dem Bot komme.
  Wenn auch nur drei Personen gleichzeitig Inference versuchen, schmilzt mein LattePanda wahrscheinlich dahin

• Ich persönlich nutze https://github.com/foges/whisper-dictation zusammen mit Groqs llama-70b.
  Ich beginne zu sprechen, wechsle zur Website, und bis sie geladen ist und ich llama-70b ausgewählt habe, bin ich auch schon fertig mit dem Sprechen, sodass die zusätzliche Wartezeit null ist. Lesen ist für mich viel schneller als Zuhören, daher passt das perfekt zu mir

• Ich benutze immer noch Firefox

  • Ich habe diese Client-UI gebaut und wollte Firefox wirklich gern unterstützen.
    Ich brauchte eine Möglichkeit, die End-to-End-Latenz von Sprache zu Sprache aus Sicht der Endnutzer zu messen, und hielt Silero Voice Activity Detection (https://github.com/snakers4/silero-vad) für die zuverlässigste Lösung, um zu erkennen, wann der Nutzer aufgehört hat zu sprechen und den Timer zu starten, und ihn wieder zu stoppen, sobald Audio vom Bot kommt.
    Silero läuft mit onnx-runtime und wasm. In Firefox funktioniert es zwar bis zu einem gewissen Grad, aber das VAD verhält sich öfter falsch als erwartet, wodurch die Latenzwerte ziemlich merkwürdig werden. Ich möchte es trotzdem unbedingt zum Laufen bringen und arbeite noch daran.
    Der UI-VAD-Code ist hier: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
  • Man muss den Warnhinweisen einfach nicht glauben. Im neuesten Firefox funktioniert es gut. Die Demo ist auch klasse
  • Ich mag es nicht, dass alle nur noch für Chromium entwickeln
  • Ich vermute, auf HN gibt es ziemlich viele Firefox-Nutzer
  • Unter Firefox 127 funktioniert es perfekt

• Wirklich beeindruckend
  Apples Siri schafft es immer noch nur, Gespräche zu führen, bei denen man sich dauernd ins Wort fällt, stoppt, scheitert und am Ende nur hofft, überhaupt eine minimale Antwort zu bekommen